什么时候需要 multi-agent？

一个常见回答是：当任务能拆成多个角色时。比如一个 agent 负责规划，一个 agent 负责搜索，一个 agent 负责写代码，一个 agent 负责审查，一个 agent 负责发布。这个回答听起来很自然，因为它借用了人类组织里的分工语言，也很容易画成一张漂亮的流程图。

但它不是一个足够好的工程判断标准。

真正的问题不是“我能不能给任务起出几个角色名”，而是“这里是否存在多套不该混在一起的运行边界”。如果两个步骤应该看到不同上下文、拥有不同工具、使用不同权限、追求不同目标、遵守不同失败约束，或者由不同主体承担批准责任，那么 multi-agent 才开始成为一个有意义的架构选项。

换句话说，multi-agent 的核心不是分工，而是边界。

一、问题不在“几个角色”，而在“几套边界”

1.1 角色语言很方便，但容易误导

“规划者”“执行者”“审查者”“发布者”这些词很有用。它们能帮助我们描述工作流，也能帮助 prompt 更清楚地表达某一步要做什么。但它们有一个危险之处：它们让人误以为，只要工作流里出现多个职责，就应该把它们做成多个 agent。

这通常会过早复杂化系统。

一个 agent 完全可以在不同阶段采用不同提示、不同输出格式、不同工具选择策略。一个普通 workflow 也可以在步骤之间插入测试、静态扫描、权限检查和人工审批。很多系统需要的是更好的上下文管理、更清楚的工具描述、更可靠的验证，而不是更多“人格化”的 agent。

如果只是让同一个模型换一个口吻，从“产品经理视角”切到“工程师视角”，这不叫充分的 multi-agent 理由。这更像是 prompt 里的模式切换。

1.2 架构问题从边界开始

multi-agent 值得考虑的时刻，通常不是“角色变多”的时刻，而是下面这些问题开始出现的时刻：

  • 这个步骤是否不该看到前一步的全部推理和偏见？
  • 这个步骤是否只应该拥有一小组工具，而不是全量工具？
  • 这个步骤是否需要不同的系统提示、策略约束或合规规则？
  • 这个步骤是否需要独立判断，而不是继承生成者的目标函数？
  • 这个步骤失败时，是否应该停止并升级，而不是继续重试？
  • 这个步骤是否拥有批准、部署、付款、删除、外发等高影响权限？

如果答案是肯定的，那么你面对的就不是简单的“分工问题”，而是运行边界问题。

这也是为什么软件开发是一个典型案例。需求澄清、测试设计、代码实现、代码审查、上线发布看起来是一条连续链路，但它们不应该天然共用同一套可放行的 harness。否则系统很容易变成：自己理解需求，自己制定标准，自己写实现，自己判断通过，最后自己给自己放行。

这不是单纯的“自证”问题。更准确地说，是上下文、权限、目标函数和风险边界全混在了一起。

二、先把词说清楚：model、agent、harness 与 orchestrator

2.1 model 不是 agent

在这个问题上，先把词说清楚很重要。

model 是语言模型本身。它接收输入，生成输出。它可以在输出里表达“我想调用某个工具”的意图，但模型自己不会真的打开文件、执行命令、访问数据库、记住长期状态或决定何时停止循环。

OpenAI Agents SDK 把 agent 描述为带有 instructions、tools、handoffs、guardrails、structured outputs 等运行配置的 LLM。这个定义虽然是某个 SDK 的表达，但它抓住了关键点：agent 不是裸模型，而是模型加上一组让它能行动的运行配置和运行机制。

所以，当我们讨论 multi-agent 时，讨论的不是“多调用几次模型”，而是“多套能独立行动、受不同规则约束的运行实体”。

2.2 Agent = Model + Harness

一个更有用的等式是：Agent = Model + Harness。model 提供语言理解、推理和生成能力；harness 则是模型之外的系统层，负责把这种能力变成可以行动、观察、记忆、调用工具、处理错误并持续推进目标的 agent。

LangChain 的 agent harness 文章 直接使用了这个等式：如果不是模型，就是 harness。文章把 harness 定义为模型之外的代码、配置和执行逻辑，包括状态、工具执行、反馈循环和可执行约束。Martin Fowler 网站上的 harness engineering 文章 也采用了类似定义：harness 是 AI agent 中除 model 外的一切。

更细一点看，Hugging Face 的 agent 术语表 区分了 scaffolding 和 harness：scaffolding 更偏向系统提示、工具描述、输出格式和上下文组织；harness 更偏向执行层，负责调用模型、处理工具调用、决定何时停止。但它也承认，在 Claude Code、Codex 这类产品语境里，harness 常被宽泛地用来指模型之外的整个 agentic 层。Databricks 对 AI agent harness 的解释 也很接近这个工程直觉：harness 把模型连接到工具、记忆、执行环境和安全控制，让模型不只是回答问题，而是能完成任务。

这也解释了“运行边界”在 agent 架构里的位置。边界不是 harness 的同义词，而是 harness 的设计结果：一个 agent 能看见什么、能调用什么、能在哪里执行、失败后能不能重试、是否需要审批，都是 harness 层面的设计决定。

同一个模型，如果被放进不同 harness，可能就是两个完全不同的 agent：一个只能读文档并生成建议，另一个能改代码、运行测试、打开浏览器、提交 PR。它们的差异不是人格差异，而是 model 之外那一整套 harness 的差异。

2.3 orchestrator 管的是 agent，不是模型的一次输出

orchestrator 是更高一层的控制者。它不只是把 prompt 丢给模型，而是管理多个 agent 之间的调用、路由、交接、状态同步和结果合并。

这里有两种常见形态。

一种是 agents-as-tools：主 agent 保持最终控制权，把 specialist agent 当作受限能力调用。OpenAI 的 orchestration 指南 将这种模式描述为 manager-style workflow：主 agent 负责最终回答，专家 agent 作为 bounded capability 被调用。

另一种是 handoff：控制权转移给另一个 specialist agent，让它接管下一段对话或工作分支。这适合真正需要不同策略、不同工具或不同上下文所有权的场景。

这两种模式都不是“多几个角色名”。它们本质上是在回答：谁拥有下一步控制权？谁拥有上下文？谁负责最终输出？谁承担策略边界？

三、multi-agent 的核心：拆运行边界

3.1 上下文边界：不是所有信息都应该被同一个模型看见

LangChain 的 multi-agent 文档 说，多 agent 设计的中心是 context engineering：决定每个 agent 看到什么信息。这个说法非常关键。

上下文不是越多越好。对生成者有帮助的信息，可能会污染审查者；对调试者必要的日志，可能不该暴露给负责对外回复的 agent；对客服 agent 可见的用户隐私，未必应该进入营销分析 agent 的上下文。

软件开发里也一样。实现 agent 需要知道需求、代码结构、测试反馈和局部设计取舍。但审查 agent 不一定应该继承实现 agent 的全部推理过程。它更应该看到需求、diff、测试结果、风险清单和审查标准。否则它很容易被实现者的叙事带偏，沿着同一条错误路径继续自洽。

所以，上下文边界不是节省 token 的小技巧，而是认知隔离机制。

3.2 工具与权限边界：不是所有能力都应该同时开放

如果一个 agent 同时能读需求、改代码、改 CI、管理 secrets、合并 PR、部署生产，那么它当然“很能干”。但这也意味着一个错误推理、一次提示注入、一个被污染的工具结果，都可能沿着权限链条一路放大。

工具越多，选择错误工具的概率越高；权限越大，错误动作的后果越重。multi-agent 在这里的价值不是让系统显得更“智能”，而是把能力拆成更小的授权面。

例如，实现 agent 可以拥有写工作区和运行测试的权限，但不应默认拥有合并主分支和部署生产的权限。发布 agent 可以读取构建产物和部署状态，但不应随意改业务代码。安全审查 agent 可以读 diff 和安全扫描结果，但不一定需要写权限。

这类拆分也不总是要靠另一个 LLM agent 完成。有时最好的边界是操作系统权限、CI required checks、branch protection、policy engine 或人工审批。

3.3 目标函数边界：生成者和验收者不该追求同一个局部最优

实现者天然倾向于让方案成立。它会解释自己的取舍，会优先证明当前路径能走通，会把测试通过视为强证据。审查者的目标应该不同：寻找遗漏、反例、风险、边界条件和不可接受的副作用。

如果同一个 harness 同时负责生成和验收，而上下文又保留了完整的自我解释，那么验收过程就很容易变成“沿着原来的理由再检查一遍”。这不是因为模型“坏”，而是因为目标函数没有被拆开。

LLM-as-judge 研究里也有类似警示。Self-Preference Bias in LLM-as-a-Judge 讨论了模型评估中对自身或熟悉风格输出的偏好风险。这个研究不意味着“只要换一个 agent 就绝对客观”，但它提醒我们：独立评价不能只靠一句“请客观审查”，还需要不同上下文、不同标准、不同证据来源，必要时还要有人类或确定性 gate 参与。

3.4 失败约束边界：失败时谁能重试、谁必须停止

很多 agent 系统的问题不是第一次失败，而是失败后的行为没有边界。

实现 agent 测试失败时，可以读取错误、修改代码、再次运行测试。研究 agent 搜索不到资料时，可以换关键词、扩大范围、再查一次。可是发布 agent 遇到权限异常、部署异常、生产验证异常时，通常不应该无限重试，更不应该自行绕过审批。

失败约束本身就是 harness 的一部分。一个 agent 是否允许重试、重试几次、是否能降级、何时必须上报、是否允许调用更高权限工具，这些规则决定了它在异常状态下的风险。

当两个步骤的失败语义不同，它们就不应该被塞进同一个无差别循环里。

四、软件开发为什么是一个典型案例

4.1 需求、测试、实现、审查和发布不是同一种权力

软件开发链路特别适合说明 multi-agent 的边界问题，因为它表面上是一条连续流程，实质上包含多种权力：

  • 需求澄清决定“要解决什么问题”。
  • 测试设计决定“什么证据算完成”。
  • 代码实现决定“用什么方式达成”。
  • 代码审查决定“这个实现是否可接受”。
  • 上线发布决定“是否允许影响真实用户或生产系统”。

这些步骤当然可以被一个 agent 串起来辅助完成，尤其是在低风险个人项目里。但在更严肃的工程环境中，它们不应共享同一套可最终放行的 harness。

原因很简单：制定标准、生成实现、判断通过、发布生产，是不同类型的权力。把它们都交给同一个 agent，不是“自动化程度高”，而是控制面过于集中。

4.2 自证问题背后是混合边界问题

“自己写代码、自己审查代码”听起来像是主要问题。但更深层的问题是：

  • 它共享了同一份需求理解。
  • 它共享了同一套实现假设。
  • 它共享了同一段上下文和推理路径。
  • 它共享了同一个“任务完成”的局部目标。
  • 如果还有提交、合并、部署权限，它也共享了同一条放行路径。

这会让错误不只是发生一次，而是在后续步骤里被继承和加固。

一个更好的设计，不一定是“多开五个 agent”。更准确的设计是：把生成和验收之间的证据链拆开。测试应尽量可验证，审查应读取 diff 和标准而不是实现者的自我辩护，发布应依赖独立的 CI、审批和审计记录。

在 GitHub 这样的开发平台上，branch protection 和 required review 就是这种思想的传统工程实现：不是所有写入者都能直接合并，合并前需要检查、审批和规则满足。

4.3 AI 代码也需要职责分离

AI 生成代码并没有取消软件工程里的职责分离，反而让它更重要。

OWASP AISVS Appendix C 对 AI-assisted secure coding 的控制要求里明确提到，AI 生成代码需要经过合格人类工程师审查，审查者不应是最初请求 AI 生成代码的同一身份，AI agent 自身也不算人类 reviewer。它还特别列出了“autonomous agents approving their own work”这类威胁场景。

这个要求背后的思想不是反对自动化，而是反对把生成、验证和批准都压到同一个不受约束的主体上。

在实践里，可以有很多组合：

  • agent 写代码，人类审查。
  • agent 写代码，另一个只读 agent 做初步审查，人类最终批准。
  • agent 写代码，CI 运行测试和扫描，protected branch 阻止未通过变更合并。
  • agent 生成发布说明，但发布动作需要人工确认或 policy engine 放行。

关键不在于“几个 agent”，而在于每个环节的权限和责任是否清楚。

五、什么时候不要 multi-agent

5.1 只是口吻不同，不必拆 agent

如果所谓 multi-agent 只是让同一个模型依次扮演“产品经理”“架构师”“程序员”“测试员”，但它们共享同一份完整上下文、同一套工具、同一组权限、同一个停止条件，那它很可能只是角色扮演，不是架构隔离。

这种设计可能有提示层面的价值，但不要高估它的治理价值。它不能天然带来独立审查，也不能天然带来权限隔离。

很多情况下，一个 agent 加上清楚的阶段提示、结构化输出、工具 gating、测试命令和人工确认，就足够了。

5.2 问题窄、风险低、路径稳定时，workflow 更合适

Microsoft 关于 single-agent 与 multi-agent 的决策建议 有一个很务实的提醒：不要假设角色分离必然需要 multi-agent。许多场景应该先用 single-agent prototype 验证，只有当单 agent 在上下文、性能、权限或规模上出现无法通过优化解决的限制时，再切到 multi-agent。

如果任务范围窄、输入输出稳定、风险低、工具集小，一个单 agent 反而更可控。它更容易调试，状态更集中，成本更低，延迟更短。

比如从一组公开文档里抽取摘要，或者按固定格式生成一封内部邮件，通常不需要多 agent。把它拆成“阅读 agent”“摘要 agent”“审查 agent”，可能只会增加日志、prompt、错误面和 token 成本。

5.3 能用确定性 gate 解决的，不要交给另一个 agent 表演

有些边界不是认知边界，而是确定性验证边界。

代码是否格式化，可以用 formatter。依赖是否有已知漏洞，可以用 SCA。测试是否通过，可以用 CI。分支是否允许合并，可以用 branch protection。部署是否需要审批，可以用环境保护规则或发布系统。

这些问题不应该优先交给另一个 agent “判断”。agent 可以解释失败原因，可以建议修复方式，但 gate 本身最好是确定性的、可审计的、可重复的。

好的 multi-agent 设计，不是把所有控制都 LLM 化，而是把 LLM 放在适合它的边界内。

六、什么时候确实该拆

6.1 需要不同上下文

当两个步骤不应该共享同一份上下文时，拆 agent 开始有意义。

典型例子是生成与审查。实现 agent 可以保留大量探索记录，但审查 agent 更应该从需求、diff、测试、风险规则出发。另一个例子是用户隐私处理：一个 agent 可能需要读取敏感原文，另一个 agent 只应该看到脱敏摘要。

上下文隔离不仅是效率问题，也是安全和认知独立问题。

6.2 需要不同工具、凭证或执行环境

如果两个步骤需要完全不同的工具集合，也应该考虑拆分。

例如，一个 agent 需要访问浏览器和本地工作区，另一个 agent 只需要读 PR diff；一个 agent 可以运行测试，另一个 agent 只能读取测试结果；一个 agent 可以访问 staging，另一个 agent 绝不能触碰生产凭证。

这类拆分的价值很直接：降低工具误用和权限扩散的风险。

6.3 需要独立评价、批准或审计

当一个步骤承担评价、批准或审计职责时，它通常需要独立边界。

这里的“独立”不只是换一个 prompt，而是至少包括不同输入、不同标准、不同权限和可追踪记录。审查者应该知道自己审查的是什么、依据是什么、能做什么、不能做什么，以及审查结果如何被记录。

在高风险系统里，最终批准往往不应该由 LLM agent 单独完成。agent 可以提供分析，但批准路径应由人类、策略系统或组织授权机制承担。

6.4 需要并行探索宽问题空间

multi-agent 还有一个非常实际的价值：并行探索。

Anthropic 关于 multi-agent research system 的工程复盘 提到，复杂研究任务天然需要探索许多来源，并行子 agent 能显著提升覆盖面和速度。但同一篇文章也强调，多 agent 会带来快速增长的协调复杂度和 token 成本。

所以，并行是充分理由之一，但不是免费的理由。它适合宽问题空间，例如开放式调研、复杂故障排查、多来源证据收集、跨模块代码审查。它不适合被用来装饰一个本来很窄的问题。

七、拆分之后的新问题

7.1 协调复杂度会增长

multi-agent 不是把复杂度消灭，而是把复杂度从单个 agent 内部转移到 agent 之间。

你需要决定谁分配任务，谁合并结果，谁处理冲突，谁判断某个子任务已经足够，谁防止重复工作，谁在子 agent 失败时恢复。Anthropic 的实践里，早期 agent 甚至会为简单查询生成过多 subagent、反复搜索不存在的来源，或者互相干扰。

如果没有清楚的任务边界、输出格式和停止规则，multi-agent 会让系统更难调试。

7.2 成本、延迟和状态同步会变差

多个 agent 意味着更多 prompt、更多上下文复制、更多工具调用、更多中间结果。Microsoft 的决策框架也提醒，多 agent 会增加协议设计、错误处理、状态同步、监控和调试成本。

这不是理论问题。每个 handoff 都可能增加延迟，每个子 agent 都可能重复读取背景信息，每个结果合并点都可能丢失细节或引入矛盾。

因此，multi-agent 应该服务于明确收益：更好的隔离、更强的并行、更清楚的审计、更安全的权限，而不是“看起来更像团队”。

7.3 安全面会扩大

agent 越多，数据流越多。数据从一个 agent 传给另一个 agent 时，可能带着未清洗的网页内容、PR 评论、issue 文本、工具输出、日志片段或第三方文档。所有这些都可能成为提示注入载体。

OWASP AI Agent Security Cheat Sheet 明确提醒：不要给 agent 无限制工具权限，不要让 agent 在没有人工监督时做高影响决策，不要在 multi-agent 系统中传递未清洗数据。

这意味着 multi-agent 不只是“多几个智能体协作”，也是多几个身份、多几条通信通道、多几处授权点、多几份日志和多几个攻击面。

八、一张工程判断清单

8.1 先问边界，再问 agent 数量

在决定是否使用 multi-agent 前，可以先问这组问题：

  1. 这些步骤是否应该看到不同上下文？
  2. 它们是否需要不同工具、凭证或执行环境？
  3. 它们是否承担不同风险等级的动作？
  4. 它们失败时是否应该遵守不同恢复策略？
  5. 它们是否需要独立评价、批准或审计？
  6. 它们是否需要并行探索宽问题空间？
  7. 如果不用 multi-agent，能否用 workflow、CI、policy gate 或人工审批更简单地实现边界？

这些问题比“能不能拆出几个角色”更接近架构本质。

8.2 选择合适的边界实现

可以把选择简化成几种情况：

  • 使用 single agent：任务有一份连贯上下文、一套权限、低风险输出，且没有强独立审查需求。
  • 使用 workflow 或 CI gate：边界是确定性、可验证、可重复的，比如测试、扫描、格式化、审批规则。
  • 使用 agents-as-tools：主 agent 应该保留最终输出所有权，但需要调用受限专家能力。
  • 使用 handoff：某个 specialist 应该接管下一段对话、策略或工具环境。
  • 使用完整 multi-agent orchestration：多个独立边界的 agent 需要并行工作、互相交接、汇总证据，且这些边界具有真实治理意义。

这张清单的目的不是让 multi-agent 显得更难，而是让它更诚实。该拆的时候要拆，不该拆的时候也要有克制。

结语

multi-agent 最容易被讲成一个组织隐喻：像一个团队，有人规划，有人执行，有人审查，有人发布。但真正有用的工程问题不是“这个团队有几个人”，而是“哪些权力不该放在同一个人手里，哪些信息不该被同一个主体看见，哪些动作不该由同一个 harness 放行”。

当上下文、工具、权限、目标函数、失败约束和批准责任需要隔离时，multi-agent 是一种强有力的架构手段。当问题只是口吻不同、步骤不同或流程稍长时，single agent 加 workflow 往往更简单、更便宜、更可靠。

本文参考了 OpenAI 关于 Agents 与 orchestration 的文档、LangChain 的 multi-agent 设计说明与 agent harness 定义、Martin Fowler 网站上的 harness engineering 文章、Microsoft 的 single-agent 与 multi-agent 决策指南、Anthropic 的 multi-agent research system 复盘、Databricks 对 AI agent harness 的解释、Hugging Face 的 agent 术语表、OWASP 的 AI Agent Security Cheat Sheet 与 AISVS Appendix C，以及关于 LLM-as-a-Judge self-preference bias 的研究。

所以，什么时候需要 multi-agent？

不是当你能画出多个角色的时候。

而是当你能说清楚：这里有几套不该混在一起的运行边界。