笨重带来的问题是什么，解决思路是什么

回复 群友 8764： 接着上面说。笨重的代价最后都会落到具体的地方，我按"会出什么事"讲，再讲业界现在怎么绕。 一、问题清单 1 上下文分裂。这是根子。子 agent 各自只看到局部，会做一堆互相不兼容的隐含决策，合并时才发现对不上。Cognition 那个 Flappy Bird 的例子就是——不是谁做错了，是没人知道对方的假设。 2 成本与延迟乘数。每个子 agent 都要把背景自己读一遍，重复 N 次。Anthropic 在它那套多 agent 研究系统里给的数字是 token 消耗约为普通对话的 15 倍；延迟也随链条拉长，主 agent 等子 agent、子 agent 再等模型，串行下去用户就是干等。 3 交接时有损压缩。子 agent 把一大段过程压成一段摘要回给主 agent，主 agent 只能基于摘要决策。关键那句"这个接口不能用"要是没写进摘要，后面所有活都建在错的假设上，而且没人发现。 4 出错难归因、难回滚。分布式的老问题：错了算谁的，重试要不要全重跑，中间产物怎么退。三个各有副作用的子 agent 跑完，"撤销"基本做不到。 5 并发冲突。多个 agent 同时改同一份文件、同一张表，互相覆盖。没有单写者约束就必然踩。 6 可观测性差。trace 散在 N 个会话里，出问题只能靠猜，调试成本最后超过它省下的时间。 7 验收断层。主 agent 没看过细节，没能力验收，只能相信子 agent 说"我完成了"——而这是整条链上最不可信的一环。 二、解决思路 分三层：先做取舍，再做上下文，最后做结构。 1 先做减法，别默认多 agent。Anthropic 那篇 Building Effective Agents 的顺序是先单次调用、再 workflow、最后才是 agent。一次调用加好工具能搞定的就别拆；控制流能用确定性代码写清楚的，就别交给模型决定。 2 把"共享上下文"变成硬约束。Cognition 两条原则：共享完整 trace 而不是事后交换消息；每个动作都暗含决策，冲突会积累。工程化做法不是每步同步全文，而是把关键决策提前固化成一份共享的规格/计划文件，所有 agent 的行动都必须追得到这份文件里的某一条。冲突在写规格时就被消解，而不是等合并才发现。 3 上下文工程比提示词工程更关键。三个手段：压缩，把历史总结成状态摘要，丢掉不重要的部分；外部记忆，让 agent 自己维护进度笔记，需要时再读回来；分层加载，上下文里先放索引和引用，用到才取原文。目标是任意时刻进模型的都是"这一步真正需要的"，不是全部历史。 4 子 agent 走"隔离加契约"。子 agent 在独立上下文里跑，只允许把结果压成结构化产物返回，主 agent 只消费结论、不消费过程。这个模式对信息收集型任务收益最大——搜资料、读代码、查日志，天生可并行、可压缩；别拿它做需要共享隐含决策的实现型任务，写代码、做设计，那正是 Cognition 反对的场景。 5 结构上做确定性。真需要多个执行体时，把编排写成 workflow：固定 router 分派、并行跑、代码里合并结果，控制流握在代码手里。这样成本、延迟、失败路径都可预测。 6 读写立规矩。一份资源同一时刻只有一个写者；并行改动放在分支或沙箱里，最后统一合并；agent 之间用显式交接协议说明交什么、谁负责、下一步是谁，不靠"默认对方知道"。 7 验收和可观测当第一等公民。子任务派出去时就带上可判定的验收标准，也就是前面聊的 rubric；全链路留 trace，失败能定位到具体一步、能只重跑那一步；关键节点用人或自动化测试当 gate，别让主 agent 自己给自己打分。 8 算 ROI、设硬边界。token 上限、步数上限、超时都写死。多 agent 换来的是并行度和专精，如果任务本身不并行、子结果又压不紧，那你买到的就只有乘数成本。 一句判断标准：任务能切成互相独立、结果可压缩的信息块，才值得上多 agent；需要统一品味和大量隐含上下文的活，一个 agent 加好上下文通常更强。所以现在主流不是"多 agent 还是单 agent"的二选一，而是单 agent 为主、把多 agent 限制在少数可隔离的环节上——这也是为什么老 IT 人说它笨重，但没有人说它没用。