--- title: "多 Agent 不是虚拟公司：从 Anthropic 五种模式看信息流怎么设计" source: wechat url: https://mp.weixin.qq.com/s/fMPSK00Lxb0uv90sun_BYQ ingest_date: 2026-07-04 vxc: 64 stars: 4 sha256: eae957ad8b3bcb2842da22a24b161c392d15590578f7466c3ca671fd94367ee5 --- # 多 Agent 不是虚拟公司：从 Anthropic 五种模式看信息流怎么设计 **来源**: 架构师 **发布日期**: 2026-04-18 **原文链接**: https://mp.weixin.qq.com/s/fMPSK00Lxb0uv90sun_BYQ --- # 架构师（JiaGouX） 我们都是架构师！ 架构未来，你来不来？ 这几天 Anthropic 发了一篇文章，专门讲多 Agent 协调模式。 标题看起来很朴素：《Multi-agent coordination patterns: Five approaches and when to use them》。五种模式、适用场景、什么时候该从一种演进到另一种。 如果只把它当成一篇“多 Agent 五种架构总结”，其实有点可惜。 我读完更强烈的感觉是：Anthropic 真正想提醒的，是另一件更工程化的事： 多 Agent 的难点不在于给模型分配几个角色，而在于把任务拆到合适的上下文边界里，再让信息流、验证和停止机制能稳稳接住。 这和最近社区里很流行的一类说法正好相反。 很多多 Agent 教程喜欢把系统画成一个 虚拟公司 ：一个 Agent 当产品经理，一个当架构师，一个当开发，一个当测试。图很好看，故事也很好懂。CrewAI、MetaGPT 这类框架之所以积累了大量用户，很大程度上就是因为这个直觉太好解释了。 但有意思的是，Anthropic、OpenAI、Google 三家在构建自己的生产级 Agent 系统时，没有一家采用“虚拟公司”模式。 Anthropic 用的是 orchestrator-worker 并行探索，OpenAI Codex 靠的是 spec 文件 + skills + compaction，Google Gemini CLI 走的是 Conductor 扩展 + 持久化 Markdown 文件。 三家的做法虽然不一样，但都没有出现“PM Agent 交给 Dev Agent 再交给 QA Agent”这种流水线。 这或许不是巧合。 LLM 系统真正卡住的地方，往往不是“岗位不够齐”，而是上下文丢失、信息传递失真、验证标准模糊、循环不收敛。 所以今天不打算把 Anthropic 的文章只是翻译一下。我更想借它来理清一个思路： 多 Agent 架构不是组织架构，首先是信息架构。 ## 太长不看版 - • Anthropic 总结了五种多 Agent 协调模式：生成-验证、编排-子 Agent、Agent 团队、消息总线、共享状态。 - • 这五种模式表面是在讲“Agent 怎么协作”，底层其实是在回答三个问题：上下文边界怎么切，信息怎么流，系统什么时候停。 - • 大多数团队未必需要一上来做复杂的“虚拟公司式 Agent 团队”。从单 Agent 或编排-子 Agent 开始，通常更稳。 - • Generator-Verifier 的关键不是“两个 Agent”，而是可检查的验收标准。没有标准，验证 Agent 只是一个更贵的橡皮图章。 - • Orchestrator-Subagent 适合短任务、独立探索和清晰边界。Claude Code 的 subagent 就是典型例子。但它会遇到信息瓶颈。 - • Agent Teams 适合长期、独立、可分区的任务，比如大代码库迁移。前提是任务边界足够硬，否则多个 worker 会互相打架。 - • Message Bus 适合事件驱动流水线。它让系统更可扩展，也让追踪和调试更难。 - • Shared State 适合协作研究和动态知识积累。它消除了部分中心瓶颈，但需要认真设计终止条件。 - • 更关键的选型问题不是“我要几个 Agent”，而是“这个任务的信息依赖结构是什么”。 - • Anthropic、OpenAI、Google 三家构建生产级 Agent 系统时，没有一家采用"虚拟公司"模式。多 Agent 的性能提升主要来自更大的搜索覆盖，而不是分工更合理。 - • 角色词不是完全没用，它可以约束语气和关注点。但如果目标是稳定交付，主线更应该是能力节点、协调模式和运行时约束，而不是人格设定。 ## 多 Agent 最容易被讲成“虚拟公司” 先说一个很常见的直觉。 既然人类公司里有产品、设计、开发、测试，那多 Agent 系统是不是也可以这么搭？ PM Agent 写需求，架构师 Agent 设计方案，开发 Agent 写代码，QA Agent 测试，最后再交给发布 Agent。看起来很顺。画成流程图，也很像一个成熟团队。 这个直觉之所以流行，是因为它非常好解释。 跟一个非技术背景的人说“这个 Agent 是产品经理，那个 Agent 是测试工程师”，对方马上能听懂。它也满足了我们对“AI 团队”的想象：既然一个 AI 像一个人，那多个 AI 放在一起，是不是就像一家公司？ 但放到工程里，这个类比很容易误导。 人类需要按岗位分工，主要是因为人有很多限制： - • 一个人的注意力有限，不能长期同时处理所有信息。 - • 人有专业边界，学习和切换成本很高。 - • 人与人之间需要接口、文档、会议和组织机制来协作。 LLM 的限制不完全是这套。 同一个模型可以写 PRD，也可以写代码，还可以读日志、跑测试、解释架构。它真正怕的，往往不是“职业边界不清”，而是另一组问题： - • 关键上下文没有带进来。 - • 中间推理被压缩成结论后失真。 - • 任务目标在多轮传递里漂移。 - • 验证标准太抽象，系统只是在假装质检。 - • 多个 Agent 互相响应，持续烧 token 但不收敛。 这里有个词需要顺手解释一下： persona 。 它其实就是我们平时说的“角色提示”或“身份设定”。 比如“你是一名资深架构师”“你是一名严格的代码审查员”“你是一名产品经理”。这类提示不是没用。让模型带一点角色感，有时确实能让表达更贴近场景，语气更稳，输出姿态更像某类读者期待的形式。 比如写给管理者、写给工程师、写给客服团队，语气和重点本来就不一样。 坦率说，我自己以前也很喜欢这么写 prompt。 有一阵子，我会在开头堆一串很豪华的身份： “你是乔布斯 + 马斯克 + 顶级架构师 + 编程大神”。 现在回头看，多少有点尴尬，但这个习惯很典型。我们会本能地以为，把身份设得越强，模型就会想得越深。 后来用得多了，体感会变得更克制。 角色提示确实可能让模型更有“那个味儿”：更像某类人说话，更愿意站在某个角度组织答案。可一旦任务从“生成一段内容”切到“核对事实是否准确、代码是否安全、方案是否成立”，这类身份设定就不一定是增益了。 说白了： 角色提示的收益和代价经常绑在一起。 它可能帮对齐型、生成型任务找到语气和立场，但在判别型任务、事实准确率、知识检索和严肃审查上，过强的身份设定反而可能把模型带进某种表演状态。它更像是在调音色，不是在增加底层推理深度。 所以我会把 persona 放在比较靠上的层：它管的是语气和立场，不是系统的控制面。 尤其在事实核查、代码审查、问题分诊、架构取舍这类任务里，真正能托住结果的，还是更底层的几件事：能力节点、协调模式、运行时状态、验证标准和停止条件。 图 1：别把角色设定放进控制面 别把角色设定放进控制面 所以，把 Agent 叫成“产品经理”或者“测试工程师”，不一定会让它更专业。很多时候，反而会制造一个假的职责边界。 最有价值的推理，常常发生在边界上。而且“虚拟公司”模式传递的是结论，不是推理过程。Agent A 产出一个文档，传给 Agent B。B 拿到文档，重新理解，重新建立上下文。原始意图在衰减，隐含假设在丢失，每次传递都在累积误差。工作流越长，最终输出越“局部正确但整体漂移”。 比如写代码时发现需求本身有问题，做测试时发现架构抽象不稳，排查日志时反过来改写验收标准。人类组织里这些跨边界发现靠经验、会议和非正式沟通补回来。Agent 之间如果只是按角色接力，很容易把这些发现压掉。 这也是我读 Anthropic 这篇文章时最在意的地方。 它没有把多 Agent 讲成一个“AI 公司怎么分工”的故事，而是把五种模式放回了更朴素的问题里： 谁需要什么上下文，信息要经过谁，什么时候该停下来。 图 2：选多 Agent 之前，先看任务的信息结构 选多 Agent 之前，先看任务的信息结构 这张图也是后面所有模式的底层框架。 先别急着问“我要几个 Agent”，更值得先看这三个问题。 ## 把岗位拆回能力节点 这里可以再往前走一步。 很多“角色型 Agent”之所以让人感觉自然，是因为它把复杂工作重新包装成了我们熟悉的岗位语言。产品经理、架构师、开发、测试、运维，一听就知道在说什么。 但如果真的要落到系统里，我会更愿意把这些岗位拆回一组更细的能力节点。 比如“测试工程师 Agent”这个说法听起来很完整，但它里面其实包含很多动作： - • 找到项目的测试入口。 - • 区分失败是环境问题、数据问题，还是代码回归。 - • 缩小最小复现范围。 - • 决定哪些测试要重跑。 - • 把失败映射回变更文件。 - • 给出下一步修复建议。 这些动作串在一起，才是一个能反复跑的 test-triage 工作流。它不用先“扮演测试工程师”，它需要的是稳定执行一条检查链路。之前拆 Hermes Agent 的三层学习机制时也聊过类似的事：Hermes 沉淀下来的不是“角色记忆”，而是 skill——“这类任务以后怎么做”的操作规程。 代码审查也是一样。 与其说“请一个 Reviewer Agent”，不如拆成更具体的节点： - • 读取变更范围。 - • 对照 Issue 验收标准。 - • 跑静态检查和测试。 - • 检查权限、数据迁移、兼容性。 - • 把风险按严重级别输出。 这些节点可以串起来，也可以并行跑。需要的时候，它们由一个 Agent 执行；更复杂的时候，它们可以分给多个 Agent。但系统真正复用的，不是“Reviewer 这个人格”，而是这条审查 pipeline。 这也是为什么我越来越觉得，“多 Agent 是信息架构”比“多 Agent 是组织架构”更靠谱。 角色可以作为提示词的一部分，帮助模型调整语气、关注点和输出格式。但它很难单独承担系统治理。 真正能沉淀下来的，通常是这些东西： - • 某类问题需要哪些上下文。 - • 哪些步骤需要固定。 - • 哪些边界不能越。 - • 哪些输出需要结构化。 - • 哪些检查需要通过。 - • 失败之后怎么回滚或升级。 如果把这些东西写清楚，它们就会自然长成 workflow、skill、pipeline，或者某种更工程化的运行规程。 前两天翻 Codex App 本机的插件缓存目录时，我也看到了类似的信号。Codex 官方挑选的那批 skills，名字不是“架构师”“测试负责人”，而是 test-triage 、 render-debug 、 packaging-notarization 、 evaluate-skill 这些。它们指向的不是“一个人”，而是“一类可以反复处理的问题”。 图 3：从岗位名拆回 skills pipeline 从岗位名拆回 skills pipeline 名字不重要。 重要的是，它们比“当前扮演什么角色”更稳定，也更容易被复用、评估和改进。 这也能解释为什么 Anthropic 的五种模式里，真正关键的不是角色配置，而是信息流配置。 ## 模式一：生成-验证，关键不是双 Agent，而是验收标准 Anthropic 讲的第一个模式叫 Generator-Verifier 。 一个 Agent 生成结果，另一个 Agent 负责检查。检查通过就结束，不通过就把反馈打回去，让生成方重做。直到通过，或者达到最大迭代次数。 这个模式很简单，也很常见。 代码场景里，一个 Agent 写代码，另一个写测试、跑测试、查回归。客服场景里，一个 Agent 生成邮件回复，另一个核对产品文档、品牌语气和用户问题是否都被覆盖。合规、事实核查、评分表批改，也都能放进这类模式。 但这里最容易被误解。 很多人看到“生成-验证”，以为关键是多加一个验证 Agent。 其实不是。 这个模式真正值钱的是验证标准，不是验证角色。 如果只是告诉 verifier：“帮我看看这个结果好不好。”它很可能会点头放行。原因不在模型懒，而在“好不好”这个标准本身不可执行。 更工程化的写法应该是： - • 代码是否通过指定测试集？ - • 是否修改了任务范围外的文件？ - • 是否覆盖了 Issue 里的每条验收标准？ - • 是否引用了知识库里不存在的功能？ - • 是否包含高风险操作？ - • 是否给出了失败时的兜底路径？ 验证 Agent 更像一个会执行 rubric 的检查器，而不是一个“资深同事帮忙看一眼”。 这里和最近一直在聊的 Harness 思路是接上的。前阵子拆 Managed Agents 的时候就说过，质量不能靠一句“认真检查”托住，得落到测试、日志、权限、规则、失败处理和可追踪的验收条件里。 Generator-Verifier 还有一个边界：生成和验证需要能拆开。 如果你要验证的是代码能不能跑、事实是否准确、格式是否符合规范，这很好拆。但如果你要验证一个创意方案是否“惊艳”，或者一个技术取舍是否“足够深”，验证本身可能和生成一样难。这个时候，第二个 Agent 未必比第一个更可靠。 还有一个更实际的问题：循环会卡死。 生成方始终解决不了 verifier 提的问题，两个 Agent 来回踢皮球。系统表面上还在工作，实际上只是持续消耗 token。 所以这个模式至少需要两个保险： - • 最大迭代次数。 - • 兜底策略，比如升级给人、返回当前最好版本并标注未解决问题。 Generator-Verifier 最适合放在“有明确验收标准，错一次的代价比多跑一轮高得多”的地方。 它的价值不在于让系统看起来更聪明，而在于把质量关口前置。 ## 模式二：编排-子 Agent，大多数团队可以从这里开始 第二种是 Orchestrator-Subagent 。 一个主 Agent 负责理解目标、规划任务、拆分子问题、汇总结果。子 Agent 处理具体、边界清晰的子任务，完成后把结论返回给主 Agent。 Claude Code 的 subagent 就是很典型的例子。 主 Agent 自己写代码、改文件、跑命令。当它需要搜索大型代码库、调查一个独立问题、查一组不影响主线的资料时，就派 subagent 去做。subagent 在自己的上下文窗口里工作，最后把压缩过的结果带回来。 这个模式为什么常用？ 因为它保留了一个很关键的东西： 主 Agent 对整体目标的连续掌控。 子任务可以并行探索，但最终还是回到一个主线里综合。任务目标、约束条件和最终取舍，不会被拆成一条长长的接力赛。 它适合这样的任务： - • 子问题边界清楚。 - • 子问题之间依赖少。 - • 每个子问题有明确输出。 - • 最后需要一个统一结论。 比如自动代码审查。 安全检查、测试覆盖、代码风格、架构一致性，这几个方向可以分别查。它们需要的上下文不同，输出也比较清楚。主 Agent 汇总成一份 review，就很自然。 但编排模式也有一个明显瓶颈：信息要经过主 Agent。 如果安全子 Agent 发现了一个认证问题，这个发现会影响架构子 Agent 的分析。它通常要先回到主 Agent，再由主 Agent 识别依赖关系，转发给另一个子 Agent。传几轮之后，关键细节很容易被摘要掉。 我自己用 Claude Code 的体感也类似。subagent 做简单查询很舒服，因为主线不会被文件搜索和长日志污染。但如果子 Agent 之间需要频繁共享中间发现，编排模式就开始吃力。 这里有个小经验： 如果子 Agent 只需要把最终结论交回来，编排模式很稳；如果子 Agent 需要边做边互相影响，系统已经在接近下一种复杂度了。 大多数刚上手多 Agent 的团队，我都建议先从这个模式跑起来。 协调成本低，出了问题也比较容易看出来。 ## 模式三：Agent 团队，只有任务边界足够硬才值得上 第三种叫 Agent Teams 。 它和编排-子 Agent 看起来很像，都是有一个协调者分派工作。但区别很关键： 子 Agent 是一次性的，worker 是持久的。 编排模式里，subagent 接一个小任务，做完就退出。Agent Teams 里，worker 会持续存在，跨多轮任务积累自己负责领域的上下文。 这适合什么？ 典型场景是大代码库迁移。 比如一个公司要把多个服务从旧框架迁到新框架。每个 worker 负责一个服务，连续处理它的依赖、配置、测试、部署脚本。第一次弄明白这个服务的脾气之后，后续就能复用这些上下文。 一次性 subagent 每次都要重新读，持久 worker 则能逐步积累。 这个模式听起来很诱人，但前提非常硬： 任务最好能稳定分区。 如果 worker A 改的东西会影响 worker B，而两边都不知道，结果很容易冲突。多个 Agent 同时操作同一个代码库、数据库或文件系统，最常见的问题就是抢同一块资源。 所以 Agent Teams 不是“多叫几个 Agent 一起上”。 更稳的做法通常要配这些机制： - • 文件级或模块级任务分区。 - • 独立分支、worktree 或 sandbox。 - • 清晰的 ownership。 - • 合并前冲突检测。 - • 集成测试和回滚策略。 - • 协调者能处理部分完成和超时。 如果这些都没有，Agent Teams 只是把一个不确定任务分给多个不确定执行者，最后再得到一组不确定结果。 我会把它看成一个更偏执行层的扩展模式：当任务能切成互不干扰的块，而且每块都能从持续上下文中受益，它才值得上。 ## 模式四：消息总线，当编排器里的 if-else 开始膨胀 第四种是 Message Bus 。 到了这一步，系统已经不再是一个主 Agent 显式指挥所有事情，而是引入一个共享通信层。Agent 通过发布和订阅事件来协作。 这对做过微服务、事件驱动架构的人很熟。 Agent 订阅自己关心的 topic。新事件进来，路由器把消息投递给合适的 Agent。以后有新 Agent 加入，也不需要重连一堆调用关系，只要订阅对应 topic。 Anthropic 举的例子是安全运营自动化。 告警从多个来源进来。分诊 Agent 识别严重级别和类型，把网络类告警交给网络调查 Agent，把凭证类告警交给身份分析 Agent。调查过程中可能发布更多情报请求，最终结果流向响应协调 Agent。 这个模式适合事件驱动场景： - • 事件来源多。 - • 工作流不完全固定。 - • 新类型不断出现。 - • Agent 生态会持续扩展。 一个很实用的升级信号是： 当 orchestrator 里的条件分支越来越多，系统开始为了各种特殊情况堆 if-else，消息总线就值得考虑了。 但消息总线的代价也很明显。 调试会变难。 编排模式下，至少还有一条比较明确的顺序决策链。消息总线里，一个告警可能触发五六个 Agent 的事件级联。中间哪个事件被错分、哪个消息丢了、哪个 Agent 没响应，都需要日志和 trace 才能看清。 更麻烦的是静默失败。 路由器把事件分错了，系统可能不崩溃，也不报错，只是什么都没处理。 所以 Message Bus 不是“更高级的编排器”。它是在用可扩展性换可追踪性。没有好的日志、关联 ID、重试、死信队列和审计，很容易把问题藏起来。 ## 模式五：共享状态，吞吐量换来收敛难题 第五种是 Shared State 。 前面几种模式，不管是 orchestrator、coordinator 还是 router，都有某种中心角色在管理信息流。共享状态则把这个中间人拿掉。 多个 Agent 共同读写一个持久化存储，比如数据库、文件系统、文档、知识库。 任务一般从往共享存储里写入一个问题或数据集开始。各个 Agent 自主读取信息、调查、写回发现。其他 Agent 再基于这些发现继续深入。 它最适合协作研究。 比如研究一个复杂问题，一个 Agent 查论文，一个看行业报告，一个翻专利，一个监控新闻。查论文的 Agent 发现了某个关键研究者，这条信息马上写入共享状态。看行业的 Agent 不需要等协调者转发，就能看到并继续查这个研究者背后的公司。 这个模式的优点很明显： - • 发现能实时流通。 - • 没有单一 orchestrator 瓶颈。 - • 某个 Agent 停了，其他 Agent 还能继续。 - • 共享存储本身会变成动态知识库。 但它的风险也更像分布式系统。 没有强协调者，就会有重复工作、方向冲突、并发写入、版本覆盖。 工程上，锁、版本控制、分区、幂等写入都能处理一部分问题。 真正麻烦的是行为层面的循环。 Agent A 写了一个发现，Agent B 看到后补充，Agent A 又看到 B 的补充再回应。两个 Agent 都觉得自己在推进，系统却没有收敛。 这不是加锁能解决的问题。 它需要一开始就设计终止条件： - • 时间预算。 - • token 预算。 - • 连续 N 轮没有新增发现就停止。 - • 指定一个 judge Agent 评估共享状态是否已经足够。 - • 对每个 Agent 限定可响应的事件类型和最大响应深度。 共享状态很强，但它不是免费的去中心化。 更贴近工程的说法是：它用中心瓶颈换来了收敛难题。 ## 五种模式，其实是在回答同一个选型问题 把五种模式放在一起看，会发现它们不是并列的“架构清单”，更像一条复杂度演进路径。 图 4：五种模式不是等级表，而是按瓶颈演进 五种模式不是等级表，而是按瓶颈演进 这个图里有个重点：复杂模式不是奖励。 越往右不代表越高级，团队更成熟也不代表一定要上共享状态。 更靠谱的做法是：先用最简单能跑通的模式，看它在哪里撑不住，再按瓶颈往上走。 这里可以压成一张更实用的表： 观察到的信号 更适合的模式 先检查什么 输出错一次代价很高，且标准能写清 生成-验证 rubric、测试、最大迭代次数 子任务短、边界清楚、最终要统一综合 编排-子 Agent 子任务定义、并行能力、摘要损耗 子任务长期独立运行，需要积累领域上下文 Agent 团队 任务分区、资源冲突、集成验证 工作流由事件触发，类型会不断增加 消息总线 路由准确性、trace、死信和重试 Agent 需要实时共享中间发现 共享状态 版本控制、终止条件、响应深度 实际生产系统往往会混用多种模式。Anthropic 上周推出的 Managed Agents，底层就是把这些模式做成了可托管的运行底座，帮团队省掉沙箱、权限、状态管理这些基建活。常见的组合是外层用编排-子 Agent 管整体工作流，内层某个协作密集的子任务用共享状态。或者外层用消息总线做事件路由，每种事件类型由一个 Agent 团队来处理。这五种模式是积木，不是互斥的选项。 如果只保留一句话，我会这么说： 多 Agent 的演进，不是从“一个人”升级到“一家公司”，更像是从“单一上下文”逐步拆出更多边界和通信机制。 边界越多，系统吞吐量可能越高。 但调试、验证和收敛成本也会一起上来。 Anthropic 在自己的 Research 系统里也验证了一个有意思的结论： 多 Agent 带来的性能提升，80% 可以用 token 消耗量来解释。 也就是说，多 Agent 的价值主要不是“分工更合理”，而是“用更多 token 覆盖了更大的搜索空间”。 这和“虚拟公司”的直觉也许是正好相反的： 多 Agent 更适合广度优先的并行探索，而不是模拟人类组织里的职能接力。 ## 回到 Claude Code：为什么编排模式这么常见 Anthropic 在原文里提到 Claude Code 用的是编排-子 Agent 模式，这一点很有意思。 因为 Claude Code 本身已经很强，为什么还需要 subagent？ 不是因为主 Agent“能力不够”。更关键的是，它的上下文得保持干净。 写代码时，主线任务通常需要连续推理：现在改哪个文件，为什么这么改，测试失败说明了什么，用户最初的约束是什么。 但代码库搜索、日志扫描、独立问题调查，这些支线工作会产生大量中间噪音。 如果全部塞进主上下文，主 Agent 会越来越重。读过的文件、失败的尝试、无关路径，都会留下痕迹。 subagent 的价值就在这里： 它把支线探索隔离出去。 主 Agent 不需要背下整个搜索过程，只需要拿到一个压缩后的结论，比如“认证中间件在这里，相关测试在这里，风险点是这个”。 这其实和之前聊 1M context 时的观察是一致的。 前两天我们写过， 1M 上下文不是终点 ，Anthropic 正在把 Claude Code 变成一个“上下文操作系统”。窗口变大，不代表什么都适合塞进去。上下文管理的重点，不只在“能不能装下”，还包括“哪些东西不该污染主线”。Anthropic 自己也发现，Sonnet 4.5 有“context anxiety”——快到窗口边界时会提前收尾。harness 加了 context reset 来应对，但 Opus 4.5 里这个行为消失了，reset 变成了死重量。这说明 harness 需要随模型迭代而演化，“永久解法”只是当前阶段的工程妥协。 所以 Claude Code 的 subagent，不是一个“虚拟同事”，更像一个受控的上下文隔离工具。 这个视角很关键。 一旦把 subagent 看成“角色”，很自然就会想给它起各种岗位名。一旦把它看成“上下文隔离”，问题就变了：这段支线信息该不该进主线程？ 这两个问题导向的架构完全不同。 ## 多 Agent 设计前，先搞清楚这 7 个问题 如果有人跟我说准备搞多 Agent 系统，我不会先问“打算用几个 Agent”。 我会先搞清楚这些： - - 这个任务是否真的超过了单 Agent 的上下文或搜索能力？ - - 子任务之间是独立的，还是强依赖的？ - - 每个 Agent 需要看到的上下文边界是什么？ - - 中间发现是只回到主 Agent，还是要实时共享？ - - 什么算完成，能不能写成可检查标准？ - - 如果 Agent 之间产生循环，系统怎么停？ - - 失败时是回滚、重试、降级，还是交给人？ 这 7 个问题如果还没想清楚，直接堆 Agent 数量，大概率只是把复杂度提前引入系统。 反过来，如果这 7 个问题回答得清楚，很多时候会发现：一个单 Agent 加好的状态文件、测试、权限、日志和任务边界，就已经能解决大部分问题。 三家厂商的做法也验证了这一点。Anthropic 的 claude-progress.txt 是跨 session 的工作日志，每次结束时更新，下次开始时读取。OpenAI 的 runbook 文件同时充当共享记忆和审计日志，GPT-5.3-Codex 靠它跑了约 25 小时不间断、完成了一个完整设计工具。Google 的 Conductor 把项目意图从聊天窗口里移出来，放进代码库里的持久化 Markdown。三家的形式不一样，但原则一样：推理链的关键节点必须外化到持久存储里，而不是依赖模型在 context window 里“记住”。 这不是保守。这是对复杂度的基本尊重。 多 Agent 有价值的地方，更多在于扩展搜索空间、隔离上下文、提升并行吞吐、增加验证视角，而不是模拟人类公司里那些本来就很重的组织结构。 这也能解释为什么我们之前对比 OpenClaw 和 Hermes 时，真正拉开差距的不是“谁的角色设定更丰富”，而是谁的 skill 沉淀、session 检索和过程记忆做得更扎实。 Agent 框架之间的竞争，最后也会落到这些更底层的工程能力上。 ## 写在最后 Anthropic 这篇文章最值得参考的，应该不仅仅只是“五种模式”这个分类本身。 分类会变。框架会变。模型能力也会变。 真正稳定一点的，是它背后那个很朴素的做事方式：先用最简单能跑的模式，看它在哪里卡住，再按具体问题往上走。 这句话听起来朴素，但在多 Agent 这件事上尤其重要。 因为多 Agent 太容易被讲得很热闹。 角色很多，流程很多，图很好看。每个 Agent 都像在工作，每个节点都有输出。但一旦任务复杂度上来，系统可能会出现一种很难诊断的退化：局部都合理，整体却漂移。 这比直接失败更麻烦。 所以我现在更愿意把多 Agent 看成一种信息架构设计，而不是组织架构设计。 它更关心的不是“让 AI 像公司一样工作”，而是： - • 哪些上下文适合隔离？ - • 哪些发现适合共享？ - • 哪些质量标准需要显式化？ - • 哪些循环需要能停下来？ - • 哪些失败需要被看见？ 真正好的多 Agent 系统，可能并不像一家公司。 它更像一个有外部状态、有检查点、有分支探索、有回滚机制的思考系统。 不同 Agent 不是在扮演职位，而是在不同上下文边界里展开工作。最后由清晰的信息流和验证机制，把这些工作收束成一个连贯结果。 这也是我觉得 Anthropic 这篇文章值得认真读的原因。 它表面是在讲五种协作模式。 底层讲的，其实还是我们最近一直在追的那条线： 模型会越来越强，但真正能沉淀下来的，仍然是模型外面的工程系统。 从聊 AI-First 的真正门槛是软件工程 ，到说 模型不是公司资产 、能沉淀的是模型外面那层接口，到今天拆多 Agent 的信息流设计，这几天聊的其实是同一件事： 不管模型怎么迭代，能力节点、工作流、验证标准、状态文件、停止条件——这些东西不会因为模型换了就作废。它们才是系统真正的结构资产。 ## 参考资料 - • Anthropic: Multi-agent coordination patterns: Five approaches and when to use them https://claude.com/blog/multi-agent-coordination-patterns - • Anthropic: Building multi-agent systems: When and how to use them https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them - • Anthropic: Building effective agents https://www.anthropic.com/engineering/building-effective-agents - • Anthropic: Harness design for long-running apps https://www.anthropic.com/engineering/harness-design-long-running-apps - • Anthropic: Managed Agents https://www.anthropic.com/engineering/managed-agents - • Anthropic: Harnessing Claude's intelligence https://claude.com/blog/harnessing-claudes-intelligence 如喜欢本文，请点击右上角，把文章分享到朋友圈 如有想了解学习的技术点，请留言给若飞安排分享 因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享 ·END· ```python 相关阅读： - 刚刚，Claude Code“代码泄露”背后：如何重新看 Agent Harness - 大家都在讲 Harness，但它到底该怎么理解 - 模型越来越强，为什么大家却开始重写 Harness - 如何让单个 Agent 做长任务不失真：Anthropic 给出了一套更工程化的答案 - Claude Code高手的 8 个 Claude Code 实战习惯 - 别从 README 开始：一个架构师会怎样翻 Codex 仓库 - Spec 不是代码的替代品，它是 AI Coding 的上下文管理层 - 如何让 Agents 自己设计、升级 Agents - OpenAI怎么把开源项目维护做成工作流：Skills、AGENTS.md 和 CI 的一套组合拳 - Claude Skills 入门：把“会用 AI”变成“可复制的工程能力” - 一套可复制的 Claude Code 配置方案：CLAUDE.md、Rules、Commands、Hooks - Claude Code 最佳实践：把上下文变成生产力（团队可落地版） - 把 AI 当成新同事：Agent Coding 的上下文与验证体系 - 一周写百万行的背后：Cursor长时间运行 Agent 的工程方法论 - 2026年生活重启指南 - 我真不敢相信，AI 先加速的是工程师。 - 扒一扒 Claude Cowork 系统提示词：Anthropic 如何打造数字同事 - Cowork 安全架构深度解析：从 Claude Code 到 Cowork，Anthropic 如何把“可控”做成产品 - Anthropic官方万字长文：AI Agent评估的系统化方法论 - 银弹还是枷锁？Claude Agent SDK 的架构真相 - Claude Code创始人亲授13条使用技巧 - Claude Code 内部工具开源 code-simplifier：终结 AI 屎山代码的终极方案 ``` 版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢! 架构师 我们都是架构师！