本文回答
- 什么情况下无需采用多 Agent 协同？
- 编排 Agent 应怎样描述子任务边界？
- Agent 交接时应传递哪些上下文？
本文面向企业AI项目负责人、业务架构师与技术研发主管，聚焦多Agent系统职责划分模糊、任务交接上下文缺失的常见落地问题，提供适用边界判断、子任务定义与交接规范三类可操作参考。
下文引用的公开资料仅代表对应机构的现有做法，其余内容为通用实施建议，具体执行范围需由项目参与方共同约定。
多Agent协同的适用边界判断
判断工作由项目架构师联合业务负责人共同完成，输入为待落地的任务全流程拆解清单、任务环节间的依赖关系说明、各环节所需的信息与工具列表。形成的可检查结果为多Agent适用性判定表，覆盖任务复杂度、依赖程度、预期收益、协调成本估算四类评估维度。判定存在分歧时，先搭建单Agent原型完成核心任务验证，再对比多Agent方案的收益与成本，验证结果作为最终判定的核心依据。
无需采用多Agent协同的情形主要包括三类。
- 任务链路单一且无明确分工需求时，无需采用多Agent。Microsoft Learn 建议采用能够可靠满足需求的最低复杂度，避免不必要的协调开销、延迟和成本31。Anthropic 的 Agent 构建研究也建议优先寻找最简单的可用方案，仅在确有需要时增加系统复杂度32。如果单Agent搭配工具调用即可覆盖全部任务，多Agent的协调成本反而会拉低整体效率。
- 任务各环节依赖密集且需要持续共享完整上下文时，无需采用多Agent。Anthropic 指出，需要共享相同上下文或 Agent 间依赖密集的领域，目前不适合采用多 Agent 系统33。比如需要连续推理的深度分析任务，拆分给多个Agent反而会因上下文传递损耗增加出错概率。
- 任务没有明确的专长领域区分时，无需采用多Agent。如果各环节所需的能力、工具、知识范围完全重合，多Agent的分工价值无法体现，反而会增加系统维护难度。
编排Agent的子任务边界定义方法
子任务边界定义工作由AI系统架构师负责，输入为总任务的业务目标、各专门Agent的能力说明书、可用工具与数据源清单。形成的可检查结果为结构化的子任务描述模板，每个子任务的边界描述都可被独立验证是否符合要求。子任务边界出现重叠或空白时，调整任务拆分维度，或临时增设协调节点处理交叉部分。
Anthropic 将路由描述为对输入分类并分配给专门后续任务的工作流，编排器工作流由中心模型动态拆解任务，委派工作模型并汇总结果32。Microsoft Learn 的 AI Agent 编排模式资料提到，顺序编排按预定义线性顺序连接 Agent，各阶段处理前序输出，并发编排让不同 Agent 同时处理相同任务，从各自专长提供独立分析，交接编排允许专门 Agent 根据上下文和需求判断直接处理还是转交任务31。
编排Agent描述子任务边界时，需要覆盖四类核心信息，每类信息都要使用明确无歧义的表述，避免模糊性描述带来的理解偏差。
- 明确任务目标与完成标准。用业务语言描述子任务需要达成的结果，以及判断完成的可验证条件，避免模糊表述导致Agent越权或失职。
- 明确输出格式与交付要求。规定子任务输出的结构、字段、呈现形式，方便编排Agent直接汇总不同子任务的结果，无需额外二次处理。
- 明确可用工具与数据范围。列出子Agent可以调用的工具、可以访问的知识库范围，禁止超出授权的操作，从边界上限制Agent的行动空间。
- 明确不可触碰的任务范围。清晰标注子任务不需要处理的内容、需要转交给其他Agent的情形，避免不同Agent处理同一问题产生冲突。
Anthropic 的多 Agent 研究系统实践也验证了这一点，其子 Agent 需要明确目标、输出格式、工具与来源指引及任务边界33。
Agent交接的上下文传递规范
上下文传递规则由AI系统架构师联合安全负责人共同制定，输入为Agent的职责边界说明、业务数据的敏感分级标准、任务交接的场景清单。形成的可检查结果为上下文传递配置规则，每个交接场景的传递内容、过滤规则都可被审计。交接后接收Agent出现理解偏差或操作越权时，暂停对应交接链路，回溯上下文配置并补充缺失的约束信息。
OpenAI Agents SDK 文档说明，交接后接收 Agent 默认能够看到此前完整对话历史34。但在实际企业场景中，需要根据职责边界对传递的上下文进行筛选，内容过多反而会干扰Agent判断。通常需要传递的内容包括四类，传递时可将核心信息提炼为结构化摘要放在上下文最前端，减少接收Agent处理长文本的成本。
- 任务原始需求与已完成进展。包括用户提出的原始请求、总任务的目标、此前已经完成的步骤与对应结果，避免接收Agent重复执行已完成的工作。
- 已调用的工具与返回结果。包括此前已经调用过的工具、传入的参数、获得的返回内容，帮助接收Agent快速掌握已有的信息基础，减少重复调用工具的成本。
- 已确认的约束与权限信息。包括用户的身份权限范围、业务规则中的硬性约束、此前已经确认过的特殊要求，让接收Agent的操作符合合规要求。
- 待解决的核心问题与注意事项。包括此前处理中遇到的异常、未解决的疑问、需要后续环节重点关注的内容，帮助接收Agent快速切入核心问题。
OpenAI Agents SDK 文档说明，可以通过输入过滤器改变接收 Agent 所见的历史34。对于与接收Agent职责无关的敏感信息，要通过过滤器进行屏蔽，避免无关信息干扰Agent判断，也降低数据泄露风险。嵌套交接历史只改变记录呈现方式，不会清除敏感数据，相关内容已在OpenAI Agents SDK文档中明确说明34。
落地实施的核对项与下一步动作
企业推进多Agent项目前，可对照以下核对项逐步推进。
- 完成适用性判定。梳理当前待落地的AI任务流程，对照适用边界判断是否需要采用多Agent方案，形成书面判定记录，避免盲目追求技术复杂度。
- 定义子任务边界。确认采用多Agent方案后，先梳理各专门Agent的能力范围，制定统一的子任务描述模板，完成所有子任务边界的定义并交叉验证无重叠无空白。
- 制定上下文传递规则。梳理所有可能的交接场景，明确每个场景需要传递的上下文内容与过滤规则，完成敏感数据处理规则的配置并做安全测试。
- 开展小范围验证。选取典型任务场景做多Agent协同测试，验证职责划分是否清晰、上下文传递是否完整、整体效率是否符合预期，根据测试结果调整配置。
