子 Agent 还是多 Agent？按控制权和共享状态选择协作拓扑

“子 Agent 还是多 Agent”并非严格的二选一：子 Agent 本身就是多 Agent 系统中的受委派角色。真正需要选的是谁拆任务、谁决定下一步、谁向用户交付最终结果，以及多个执行者如何交换状态。一组专家可以由父 Agent 当作工具调用，也可以在分流后接管对话；独立任务还可以并行执行。这些选择是控制权和执行方式的组合，不是框架名称的比赛。

先确认这项工作确实需要模型根据观察选择后续动作。固定工作流还是 Agent处理这个前提。本页从已经决定使用 Agent 的那段工作出发，判断是否值得增加第二个 Agent，以及增加后怎样让责任清楚。动作权限由权限阶梯单独决定，委派不会自动扩大任何人的授权。

先按结果所有者选择控制方式

拿一项真实任务，标出用户最终要收到什么、哪些中间结果能独立验收，以及任务走偏时谁有权改变计划。再比较四个起点：

方案	谁保留下一步与最终答复	适用证据	需要额外处理
单 Agent 加工具	同一个 Agent	各步骤依赖同一份不断变化的上下文，拆分后只会重复解释	限定工具与循环预算
父 Agent 调用专家	父 Agent 拆任务、验收并汇总	专家可在清楚范围内产出一份中间结果，用户只需一个最终负责人	子任务输入、输出契约与汇总时的冲突处理
分流后交接	专家接管当前对话或阶段	专家需要继续向用户提问，父 Agent 无须再转述每一句	对话历史过滤、交接状态和用户可见的负责人
代码分发并汇合	程序决定执行顺序与汇合点；可调用多个 Agent	子任务预先可列出，结果互不依赖，速度值得并发成本	并发上限、超时、部分完成与确定性的汇合规则

OpenAI Agents SDK 把“专家作为工具”和“handoff”列为两种核心编排：前者保留父 Agent 的会话控制，后者将本轮的活动 Agent 改为专家。Anthropic 则把预设的并行分工与动态拆任务的 orchestrator-workers 分开；Microsoft 还列出顺序、并发、交接和共享对话等模式。框架可以组合这些方式，但不能替你定义业务里的结果所有者。

用任务依赖和共享状态决定是否并行

把任务画成几行：每行写输入、产物、验证方法、是否必须等上一行完成。两个专家各自读取不同资料并返回可核验摘要，可以共用一份版本固定的任务简报后并行工作。若第二位必须等第一位给出候选对象，先做前者；“有两个角色”并不意味着同时运行。

共享状态要注明权威来源和版本。只读快照容易分发；共享且会变化的库存、订单或文件，不能让两个 Agent 各拿旧副本同时写。需要写入时，先由程序串行化，或让目标系统以版本检查、事务与幂等规则拒绝冲突。提示词里的“请协作”不具有加锁能力。并行读取也要核对资料权限，不能因为某个专家需要一个字段，就把全部历史发给每个专家。

还要问“独立”的含义：子任务能否分别验收？一位专家失败后，其他结果能否作为部分交付？如果答案都是不能，额外的 Agent 可能只是在同一条依赖链上增加交接点。先用一个 Agent 加明确工具跑基线，再证明拆分能改善合格率或时间。

交接时只传下一位完成任务所需的状态

为每次委派保存一份小交接包：任务目标与截止时间、允许读取的对象、资料快照及版本、期望输出格式、证据指针、已完成与尚未确认的步骤、禁止动作、返回给谁，以及超时后由谁接手。专家不能把“我猜已经完成”当作已确认状态；父 Agent 汇总时也要保留原始证据和冲突，不应把不同结论悄悄平均。

具体框架的默认状态行为不能靠名字猜。OpenAI 的 Agent.as_tool() 会启动嵌套运行，父运行的会话状态不会自动继承；应用必须显式构造所需输入。其 handoff 默认会让接手专家看到之前的对话历史，应用若只允许传部分内容，需要配置输入过滤。无论哪种方式，身份、数据访问和写入批准仍应在执行端检查；工具调用契约可用于每个实际动作。

把总费用和故障归属写进拓扑

比较同一批任务的每项合格结果，而非只看一次模型调用价格。记录父 Agent 的规划与汇总、每位专家重复接收的上下文、工具费用、失败重跑、人工复核。并行可能缩短墙钟时间，却通常不会抹掉各路模型用量；同步等待最慢的一路也可能抵消收益。为候选拓扑写出可接受的费用和时延上限，再同单 Agent 基线比较。

每个执行者都要有任务编号、输入版本、完成状态和负责人。专家超时，父 Agent 应报告哪部分没有完成，决定按原输入安全重试、跳过该部分，还是交人处理。专家结果相互冲突时，最终负责人应查原证据；不能以“多数专家同意”替代核验。涉及外部副作用时，先查目标系统的真实状态，再决定是否重试。运行护栏负责单次运行里的继续与停止，本页负责跨 Agent 的责任链。

案例一：办公楼节能评审适合父 Agent 委派

物业团队要为三栋办公楼形成一份节能改造建议。电力分析员读取分时电表与合同费率，暖通分析员检查设备运行和维护记录，财务分析员核对预算、回收期假设和租约限制。三份资料可以按同一日期做只读快照，各专家分别返回主张、计算依据、来源位置和未解决问题。父 Agent 保留总任务、审查是否引用了同一栋楼与同一期数据，并写出一份面向项目负责人的建议。

团队可先用单 Agent 和三位专家方案处理同样的历史项目。验收不是“观点更多”，而是每项节能估计能追溯到正确数据、互相矛盾的假设被标出、总费用和交付时间在限额内。如果暖通资料缺失，父 Agent 标明暖通部分待补，不拿电力结果冒充完整方案。项目负责人仍批准任何真实采购或设备调整；多 Agent 拓扑只负责分析。

案例二：图书馆借阅异常需要清楚的对话交接

一位读者说已归还图书，账户却仍显示逾期。入口 Agent 可判断这不是一般馆藏查询，并把问题交给账户核对专家。后者需要继续向读者询问归还地点、日期和凭条信息，因而接管当前对话比让入口 Agent 反复转述更直接。交接包只包含此借阅记录的授权标识、已确认事实、尚需核对的问题和可见的会话摘要，不转发读者无关的历史咨询。

账户专家可以读取归还扫描和异常工单，并说明下一步；它不能仅因接管对话就免除身份校验或直接撤销费用。测试用例应覆盖正确归还、归还记录未同步、读者给出的编号不属于其账户，以及交接后缺少关键日期。复核者要能指出：谁正在答复读者、哪个系统记录最权威、信息不足时会回到哪支人工队列。

反例：共享库存的写入不能靠多 Agent 同时处理

门店只剩最后一件可售的替换零件。两个销售 Agent 各自读取到“库存 1”，分别为不同顾客创建预留。即使两位专家的提示词都写着“先检查库存”，它们的检查也可能在同一旧状态上通过。这里需要目标库存系统在写入时落实原子预留、版本检查或串行队列。Agent 可以准备建议，负责写入的程序或服务必须裁决冲突；新增第三个 Agent 无法解决竞争条件。

这个反例也说明，故障归属要在架构图上写成具体名称。若一次预留请求超时，负责调用的一方保存操作标识并查询真实状态；其他 Agent 不得把未知结果当作“没有预留”再试。用户体验可以是一条清楚的等待和人工接手路径，而不是让多个 Agent 继续争抢同一记录。

用同一批案例验证拆分是否值得

至少准备独立可并行、前后依赖、交接缺少上下文、两位专家证据冲突、一位专家超时、共享记录写入冲突六种案例。对单 Agent 基线和目标拓扑记录合格率、严重错误、模型与工具总费用、墙钟时间、人工复核量及部分失败可追溯性。特别核对交接后的专家是否只看到应看的内容，以及父 Agent 能否如实说明缺失部分。

如果拆分只增加费用与等待，却没有改善可验收结果，就保留单 Agent 或明确的固定步骤。若专家输出确实独立、父 Agent 能把来源与冲突合并，且费用和失败处理都过关，再增加并发。选择可以按任务段落不同：一个系统既可在资料调查时并行，也可在用户沟通时交接，在写入时用确定性程序串行。

常见问题

子 Agent 一定要并行运行吗？

不一定。子 Agent 描述的是委派关系；可以串行，也可以并行。只有输入与外部效果互不依赖时，才考虑同时执行。

多个 Agent 给出相同结论，就能直接发布吗？

不能。它们可能读了同一份错误资料，或共享了错误假设。最终负责人仍要检查证据来源、版本、冲突及发布权限。

不适用边界

这张拓扑表不能证明某项任务需要 Agent，也不授权跨系统访问或外部写入。若任务结果不可验收、状态来源不清或没有最终负责人，应先处理任务定义和系统控制。涉及付款、生产修改、个人资料及受监管判断时，交接设计之外仍需相应审批、访问控制和事故处理机制。