暗无天日

=============>DarkSun的个人博客

多智能体系统的两个有效模式——以及对 Claude Code 用户的启示

Cognition 公司(Devin 背后的团队)花了 10 个月测试多智能体系统,发现只有两个模式真正靠谱:

这两个模式有一个共同原则—— 单线程写入,多线程提供智能 。谁来改代码,同一时刻只能有一个;但可以同时有多个 AI 从不同角度贡献分析和建议。多个 agent 同时往同一份代码里写东西会导致风格冲突和产品脆弱,就像多个厨师同时往一道菜里加盐,每个人都不知道别人加了多少。

Claude Code 是单 agent 工具,不是多智能体系统。但 Devin 团队的发现对 Claude Code 用户有直接的操作启示:这些模式可以转化为单 agent 的工作流策略。

单线程写入:为什么"多个 AI 一起写代码"行不通

"多 agent 并行写入"是指两个 AI 同时修改同一份代码。比如一个 AI 在改登录模块,另一个在改支付模块,但它们都碰了同一个配置文件——一个加了新字段,另一个删了旧字段,最终谁的修改覆盖谁的?更隐蔽的问题是:两个 AI 对错误处理的方式不同(一个用异常,一个用返回码),对命名风格的偏好也不同,这些 隐含决策 互相矛盾时,最终产物就变得脆弱。

这个问题的映射到 Claude Code 不是"不要同时做多件事"(Claude Code 本来就是单线程的,做不到同时做多件事),而是: 不要在一个 session 里连续做多件不同类型的事 。比如先让 Claude Code 重构代码,紧接着让它加新功能——重构过程中积累的上下文(旧的变量名、已经不存在的函数)会干扰后面加功能时的判断。session 越长,上下文越杂,Claude Code 的有效注意力越分散。遇到需要"切换思路"的时刻,开一个新 session 比在当前 session 里堆指令更有效。

模式一:代码审查环

Devin 团队的发现中最反直觉的一条:编码 agent 写完代码后,让审查 agent 用 纯净上下文 (完全不知道编码过程)来审查,效果远好于让"全知全能"的 agent 自己审查自己。平均每个 PR 抓到 2 个漏洞,其中约 58% 是严重的逻辑错误、边界遗漏或安全漏洞。

为什么纯净上下文反而更聪明?这是注意力机制的数学问题,不是经验问题。上下文越长,模型的注意力头需要覆盖的信息越多,重要细节被淹没的概率越大。编码 agent 工作了几个小时,读了仓库、跑了命令、尝试过不同方案、修复过错误——它的上下文又长又乱。审查 agent 只看到 diff,从头读代码,自己重新发现需要的信息。上下文越短,有效智能越高。

Claude Code 用户的实操方法 * :写完代码后, * 开一个新 session 来审查 。新 session 不需要知道你之前做了什么,只需要看 diff 或最终代码。

审查 prompt 示例:

请审查以下代码变更,重点关注:
1. 逻辑错误和边界遗漏
2. 安全漏洞
3. 是否有更简洁的实现方式

[粘贴 diff 或代码]

关键点:审查 agent 由于缺少上下文信息,可能会修改一些你有意为之的设计。你自己需要知道哪些审查建议是不合理的,哪些审查建议值得采纳。

模式二:聪明朋友

想象一个初级程序员做大部分日常编码工作,遇到搞不定的难题就转头问旁边的资深同事。这就是"聪明朋友"模式——便宜、快速的模型做 80% 的工作,遇到困难时临时请一个更强、更贵的模型帮忙。Devin 团队在生产环境中验证了这个架构,甚至让不同厂商的前沿模型以这种方式协作:有些模型更擅长调试,有些更擅长写测试,按能力分工而不是按难度升级。

但核心难题是 通信设计 ,有三个具体问题:

  1. 弱模型怎么知道自己不行? -- 弱模型天然倾向于低估任务难度——这跟人类的达克效应(能力不足的人高估自己)结构上非常相似。Devin 团队的方案是鼓励主模型至少调用一次聪明朋友来评估是否有遗漏的难点。
  2. 主模型该分享什么上下文? -- 实践中发现,直接把主模型的完整上下文分叉一份给聪明模型,再加上开放性问题("我该怎么做?"),效果比只分享部分上下文加具体问题更好。让聪明模型自己决定什么值得讨论。
  3. 聪明朋友该怎么回复? -- 有时候主模型没看过某个关键文件,然后问了一个涉及其文件内容的问题。聪明朋友正确的做法不是自己给出答案,而是告诉主模型"先去读那个文件,然后再来问我"。

Claude Code 用户的实操方法 :日常用 Claude Code(Sonnet)干活。遇到特定类型的难题——调试困难的问题、架构决策、复杂的性能优化——可以手动切换到更强模型(如 Opus)或者另一个 AI 工具获取"第二意见"。

切换时最重要的是 怎么描述问题 。基于 Devin 团队的经验:

  • 不要只给具体问题("这段代码为什么报错?"),给开放性问题("这个模块的整体设计有什么问题?")效果更好
  • 附上足够的上下文(相关代码、错误信息、你尝试过的方案),让对方模型自己判断重点
  • 如果对方模型反问"你看过 X 文件吗?",认真对待这个信号——它往往指向你没注意到的关键信息

局限也很明显:Claude Code 目前不支持自动升级模型。你必须手动判断"这个问题需要更强的模型",手动切换,手动把结果带回工作 session。这个"通信桥梁"目前只能由人来做。

你的角色:通信桥梁

Devin 团队总结说,所有开放问题都是通信问题——弱模型怎么学会何时升级、子 agent 怎么把发现传递给同伴、怎么在 agent 之间传输上下文而不淹没接收者。

在 Claude Code 的场景下,你就是那个通信桥梁。你负责:

  • 判断何时开新 session (代码审查环)
  • 判断何时切换更强模型 (聪明朋友)
  • 在 session 之间传递关键信息 (你从旧 session 带到新 session 的上下文)
  • 过滤 AI 的建议 (用你的完整上下文判断哪些建议值得采纳)

这个角色目前无法自动化。但 Devin 团队说得对:目标不是"一群自主行动的角色",而是"一个扩展人类品味的协调系统"。用好单 agent + 纯净上下文审查 + 聪明朋友升级,不需要等到完美的多 agent 系统出现,已经能覆盖大部分场景。

AI : 多智能体 : Claude Code : 代码审查