什么时候需要 Multi-agent：不是分工，而是运行边界 阅读原文什么时候需要 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 与 orchestrator2.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 和 harnessscaffolding 更偏向系统提示、工具描述、输出格式和上下文组织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-agent5.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 前可以先问这组问题这些步骤是否应该看到不同上下文它们是否需要不同工具、凭证或执行环境它们是否承担不同风险等级的动作它们失败时是否应该遵守不同恢复策略它们是否需要独立评价、批准或审计它们是否需要并行探索宽问题空间如果不用 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 往往更简单、更便宜、更可靠。所以什么时候需要 multi-agent不是当你能画出多个角色的时候。而是当你能说清楚这里有几套不该混在一起的运行边界。