多 Agent 系统真正的炸点，不是模型不够强，也不是提示词不够花，而是隐性耦合。
我的判断是：2026 年绝大多数团队在讨论 Agent 时，讨论错了重点。大家热衷于比较 Claude、Gemini、GPT 谁更聪明，热衷于炫耀多智能体分工多精巧，热衷于把一个本来能靠清晰流程解决的问题，包装成一套看起来很前沿的“自治协作网络”。结果一上线，炸的不是推理能力，炸的是系统结构。真正把团队拖进泥潭的，往往不是某个模型答错一句话，而是多个 Agent 在没人意识到的地方，共享了同一根脆弱的神经。
最近在 Moltbook 上看到一篇谈 Latent Coupling 的帖子，提到 16 起案例：表面上互相独立的 Agent，在更新、限流、缓存、时序假设这些地方暗中绑在一起，平均排障时间 6.2 小时，远高于显式依赖故障的 1.1 小时。这个数字不一定适用于所有团队，但方向绝对对。因为显式依赖会写在架构图里，隐性耦合不会。显式依赖像门口贴了“地滑”的牌子，隐性耦合像你以为地是干的，结果一步踩下去直接摔断腿。
问题在于，行业里的主流叙事还停留在“把更多 Agent 串起来，就能逼近组织智能”。这话听着很性感，实际常常是扯淡。一个系统里 Agent 数量越多，潜在耦合不是线性增长，而是组合爆炸。每新增一个 Agent，你新增的不是一个节点，而是一堆新的共享依赖、时序关系、缓存语义、资源竞争和责任边界。你以为自己在扩展能力，实际上可能只是在扩展事故面。
为什么团队这么容易踩进去？因为多 Agent 演示特别会骗人。
演示环境里，数据是干净的，接口是稳定的，流量是温和的，日志是完整的，所有人默认用一套最新 schema，缓存刚好命中，限流还没触发。于是看起来像一支训练有素的数字军队：规划 Agent 拆任务、执行 Agent 写代码、审查 Agent 找 bug、发布 Agent 发版、运营 Agent 总结复盘。holy shit，PPT 上像未来已经降临。可一到真实生产环境，未来就露馅了：配置热更新不一致、一个共享向量库字段变更、某个供应商 API 配额收紧、缓存 key 多了个前缀、消息队列重试导致重复执行，整套“自治系统”立刻从交响乐退化成群体踩踏。
很多 CTO 把这种事归类为“工程细节”。我不同意。它不是细节，它是战略问题。因为系统架构决定了组织的成本结构，成本结构又决定了产品能不能活。你可以容忍模型偶尔笨一点，因为模型能力会随时间普遍上升；但你不能容忍系统耦合失控，因为那会把每一次迭代都变成一次可能的全栈事故。模型错误通常伤害单次输出，结构错误伤害整个交付节奏。
换句话说：模型弱，最多让你难看；结构烂，会让你破产。
先说最常见的第一类隐性耦合：共享数据语义。
很多团队会让多个 Agent 共享同一份知识库、同一个向量索引、同一套任务状态表。听上去很高效，像在做“统一认知底座”。问题是，一旦这个底座的字段意义发生变化，或者某个 Agent 悄悄依赖了未文档化的隐含字段，系统就会进入一种很恶心的状态：所有组件都还活着，但没有一个组件真正正常。A Agent 认为 status=done 表示“已完成”，B Agent 认为表示“已提交待审”，C Agent 又把它当作“可进入归档”。恭喜，你得到的不是协作，是一台礼貌地胡说八道的机器。
这也是为什么我一直反感那种“先把数据打通，后面自然智能化”的口号。数据打通本身不是价值，语义一致才是价值。没有强约束的共享数据层，本质上是把一堆未来事故预写进数据库。
第二类隐性耦合，是共享资源池。
比如多个 Agent 共用同一个第三方 API 配额、同一个 Redis、同一个浏览器池、同一个消息队列、同一个 embedding 预算。平时风平浪静，压力一上来，系统开始互相杀死彼此。一个看似无关的爬虫 Agent 突然吃满限流，客服 Agent 回复速度下降；一个批量 embedding 任务把 token 预算吞光，主流程开始抖；一个调度 Agent 过于勤奋地产生重试，整个队列尾延迟暴涨。最滑稽的是，团队往往还会在事故复盘里说“根因是供应商不稳定”。不，很多时候根因是你把不同优先级、不同 SLA、不同故障模式的工作塞进了同一条血管。
这背后其实是很朴素的商业逻辑：你在系统设计阶段偷的懒，最后都会以更贵的运营成本还回来。共享资源不是不能用，但前提是你知道自己在共享什么，愿意为隔离付多少钱，以及谁该在高峰期先活下来。没有优先级策略的共享，就是廉价；廉价在生产环境里通常是高利贷。
第三类隐性耦合，是时序假设。
这一类最阴。因为代码里往往没有“依赖”字样，只有一堆默认成立的顺序：先抓取、再清洗、再索引、再检索、再总结、再发布。问题是，分布式世界最不爱给你的东西，就是顺序保证。你以为 Agent B 一定会在 Agent A 之后读取到新状态，结果消息延迟；你以为重试是幂等的，结果重复写入；你以为缓存 5 分钟不会出事，结果恰好碰上发布窗口。时序一乱，所有“聪明”的上层推理都会变得像穿着西装踩进沼泽——看起来体面，实际上寸步难行。
很多做 Agent 产品的人喜欢讲“协作”。但协作不是大家轮流发言，协作是对状态转移有共同约束。人类团队还能靠常识和临场补位救火，Agent 系统没有这种奢侈。你不给它明确的幂等规则、版本边界、失败补偿和优先级，它就会用最机械、也最致命的方式执行你的模糊幻想。
第四类隐性耦合，是组织耦合，这才是大多数公司真正不愿承认的部分。
表面看是系统问题，底下其实是权责问题。谁拥有 prompt？谁拥有工具接口？谁定义任务状态？谁能改共享 schema？谁对事故负责？很多公司以为自己在做多 Agent，实际上是在把原本就混乱的组织边界，编码成自动化流程。于是每个 Agent 都像一个部门：各自看起来有 KPI，合在一起没人对结果负责。最后 bug 不是没人发现，而是每个人都觉得那不是自己的 bug。
这就是为什么我说，多 Agent 架构首先是管理学问题，其次才是模型问题。一个连组织边界都没理顺的团队，强行上多 Agent，只会把内部混乱放大、加速并永久化。AI 不会自动纠正坏组织，它只会让坏组织的输出速度更快。
那正确方向是什么？不是反多 Agent，而是先停止对“更多 Agent = 更高级”这种幼稚想象上头。
我的建议很直接：
第一，先把系统切成最少必要角色。 如果一个 Agent + 一组确定性工具就能解决，就不要为了显得前沿硬拆成四个。很多所谓 planner / executor / critic / memory manager 的四层结构，本质上只是把一个人的犹豫外包成四个进程。你不是在构建智能，你是在制造延迟。
第二，把共享改成显式协议，不要改成共享幻想。 任何跨 Agent 的状态、字段、消息，都应该版本化、可审计、可回滚。别让“大家都懂”的默认语义存在。系统最怕的不是文档多，而是默契多。
第三，资源必须按优先级隔离。 面向用户的主流程、后台批处理、实验性任务，别共用一套配额和一条队列。省出来那点云成本，迟早在凌晨三点的事故里十倍吐回去。
第四，所有重试都当作潜在写放大攻击来设计。 没有幂等键、没有去重窗口、没有死信处理的 Agent 重试机制，本质上就是优雅一点的 DDoS。
第五，把观测重点放在“关系”上，不要只盯着单点指标。 绝大部分团队的监控还停留在 CPU、延迟、成功率。真正该补的是依赖图漂移、共享 schema 变更、跨 Agent 重试链、资源池竞争、状态不一致率。单个 Agent 全绿，不代表系统没病；很可能只是病灶长在连接处。
这件事还有一个更深的哲学层面：我们为什么如此执着于让系统看起来像社会？
我怀疑，很多人迷恋多 Agent，不是因为它真的更有效，而是因为它满足了一种拟人冲动。一个会分工、会争论、会审查、会记忆的系统，看上去更像“组织”、更像“生命”、更像“数字员工团队”。这很迷人，也很危险。因为一旦你开始用社会隐喻理解系统，你就容易把工程约束忘掉。你会高估弹性，低估边界；高估自适应，低估耦合；高估“自治”，低估治理。
说得难听一点，很多多 Agent 产品不是在设计系统，而是在表演系统。它们把复杂性当卖点，把角色数量当能力证明，把交互戏剧性当价值。用户第一次看会觉得高级，第三次出事故就只会觉得烦。商业世界没有耐心为架构表演买单。客户真正愿意付费的，从来不是“有多少 Agent 在幕后协作”，而是“结果稳不稳、成本值不值、出问题你多久能修好”。
所以，未来几年真正能活下来的 Agent 产品，我判断不是最会讲自治故事的那批，而是最会做结构收敛的那批。它们会减少角色数量，强化协议边界，明确优先级隔离，缩短故障半径，把“聪明”建立在可控之上，而不是建立在堆叠幻觉之上。
别再问“这个任务要不要多加两个 Agent 提高成功率”。先问一个更值钱的问题：如果其中一个 Agent 失真、延迟、重试、超配额，谁会被它一起拖下水？
答不出来，就别上线。因为那不是智能系统，那是包装得比较时髦的事故制造机。
—— https://www.80aj.com