多智能体系统：读取可以并行，写入只留一条线程

2025 年 6 月 12 日，Cognition 的 Walden Yan 发表了一篇标题直白的文章：“Don’t Build Multi-Agents”（别构建多智能体）。第二天，Anthropic 发布了 Research 系统：由运行 Claude Opus 4 的主智能体编排多个 Sonnet 4 子智能体。在 Anthropic 自己的内部研究评测中，这套系统比单智能体 Opus 4 的表现高出 90.2%。

两家做智能体的公司，相隔 24 小时，给出两个相反的结论。如果你是前线部署工程师（FDE），客户迟早会问你：“我们该不该用多智能体？”

无论往哪个方向判断失误，代价都不小。问题确实需要时你说不用，客户就错失了明显的质量提升；不需要时你说要用，留下的就是一套成本高出数倍、故障难以预测的系统，凌晨 2 点被叫起来调试的很可能就是你。

两个阵营其实没在争论

仔细读就会发现，Anthropic 从未说多智能体适合所有场景。它的文章写道，这种架构最擅长的是需要大量并行的高价值任务。同一篇文章也承认，大多数编码任务中真正可以并行的部分比研究任务少。

Cognition 做的是编码智能体，看问题的角度正好相反。Walden Yan 的观点是：多个智能体协作时，上下文和决策会分散，结果就是一个脆弱的系统。

他的第二条原则解释了原因：每个动作都带有隐性决策，而相互冲突的隐性决策会导致糟糕的结果。

Anthropic 发文三天后，LangChain 的一篇文章调和了这两种观点。它的观察是：读取天然比写入更容易并行。从这个角度看，前两篇文章就都说得通了：研究是读取，写代码是写入。

举个例子。一个子智能体读供应商 A 的文档，另一个读供应商 B 的。两项工作互不干扰，因为读取不会改变外部世界。

但如果第一个子智能体用 UTC 写了一个日期处理函数，第二个写的界面代码却默认使用本地时间，两段代码单独看都“正确”，合在一起就错了。这正是 Cognition 所说的隐性决策。

成本不只是账单

Anthropic 公布的数字是 token 用量约为聊天的 15 倍。用一个假设的例子更直观：一次消耗 10,000 token 的交互会变成约 150,000 token。对一份需要分析师花一整天完成的市场分析报告来说，这很便宜；对一个回答休假政策问题的聊天机器人来说，就很荒唐。

token 账单只是看得见的部分。从 2024 年底起，Anthropic 就提醒，智能体的自主性会带来更高的成本和错误累积的风险。再举一个假设的例子：如果智能体每一步的正确率是 95%，那么 10 个相互依赖的步骤串起来，整体正确率只有约 60%（0.95 的 10 次方）。

智能体越多，步骤越多，交接越多，错误放大的环节也越多。

为什么调试难得多

普通软件用同样的输入重跑一遍，就能看到同样的 bug。智能体不是这样。Anthropic 写道，智能体会动态做决策，即使提示词完全相同，每次运行的结果也不确定。

把这一点乘以多个相互对话的智能体，你得到的系统里，昨天的故障今天未必能复现。Anthropic 还承认，LLM 智能体目前还不擅长实时协调、向其他智能体分派任务。换句话说，这种架构里最难的部分，恰恰是模型最弱的部分。

Cognition 也谈到追踪（trace），但角度不同。它的第一条原则是共享上下文：把完整的智能体追踪传给其他智能体，而不只是零散的消息。对 Anthropic 来说，追踪是工程师找 bug 的工具；对 Cognition 来说，追踪是智能体避免在信息缺失时做决策的必需品。

目的不同，指向却相同：需要保留的是完整的步骤链，而不只是最终答案。

可行的模式：多双眼睛读，一只手写

2026 年 4 月，Cognition 再次谈到这个话题，这次的更新比前一年的标题温和。它的结论是：目前多智能体在写入保持单线程时效果最好。这与 LangChain 的读写划分一致。

那篇文章里最实用的具体模式是上下文干净的审查者。据 Cognition 介绍，这种审查者能发现编码智能体自己看不到的 bug。原因很简单：写代码的智能体带着自己的全部假设，而审查者只读结果，不受先前思路的牵引，而且关键在于，它什么都不写。

把这些来源放在一起，可以得到一张任何一篇都没有完整列出的决策表：

客户场景	读还是写	合理的架构	原因
综合多个独立来源的信息	以读为主	主智能体 + 并行子智能体	可拆分，价值足以覆盖 token 成本
跨多个文件修改代码	写	一个线性智能体	多个智能体的隐性决策会冲突
检查智能体刚写好的代码	读	增加上下文干净的审查者	能发现写入智能体漏掉的 bug，且不碰写入路径
简单问答或查询	轻量读取	一次模型调用或一个智能体	最简单的方案就够，成本不划算

很多项目就栽在最后一行。Anthropic 在《Building effective agents》中的建议依然适用：先找尽可能简单的方案，只在确实需要时才增加复杂度。

到了客户现场，从哪里入手？

假设一家保险公司想要一个智能体：读取理赔材料，对照保单条款核查，再在核心系统中更新理赔状态。第一步不是画一张五个智能体的架构图，而是列出每个动作并打上标签：读理赔材料、读保单条款、查询客户历史属于读取；更新状态属于写入。

到这一步，架构几乎自然浮现。相互独立的读取步骤，如果量足够大，可以交给并行运行的子智能体。对核心系统的写入只由一个智能体完成，且它掌握完整上下文。如果出错代价高，就在写入前加一个只读审查者做检查。

还有，在写第一行智能体代码之前，先把追踪搭好。客户打电话说“昨天它批了一笔不该批的理赔”时，你需要的是那一次运行的完整追踪，而不是一句“我们试着复现一下”。

谈决策，不谈智能体数量

如果在岗位描述里看到“多智能体经验”，别理解成要你搭一个智能体越多越好的系统。懂行的面试官很可能反过来问你：为什么不用单个智能体？

所以写简历或介绍项目时，要讲决策，而不是智能体的数量。比如“把文档查询拆给并行子智能体，数据更新保留在单个智能体中，并增加了审查者和追踪”，这样一句话就能说明你既懂收益，也懂成本。

如果你曾把一个多智能体系统收拢回单个智能体，并且系统因此更稳定，那在面试里是个更好的故事。

与此配套、值得练习的技能是读追踪。如果你顺着一串工具调用，定位到两个隐性决策冲突的位置，这就是可以带进面试的具体例子，比罗列一堆编排框架有说服力得多。

距离 2025 年 6 月那两个针锋相对的标题已过去一年多，答案不在任何一方。它在于一个简单的分类，你在第一次需求调研时就能做：这项工作是读，还是写？