别急着上多 Agent：先分清 Subagent、Handoff 和 Agent Teams
最近几年，AI 圈子一聊到 Agent，就是“我们上了多少个 Agent”。好像不用多智能体架构，项目就显得没技术含量。我也见过不少团队，任务稍微复杂一点，第一反应就是把任务拆给好几个 Agent，让它们并行协作。结果呢？API 账单翻了几倍，响应时延从两秒变成半分钟，日志乱成一锅粥，最后还得加一个超级复杂的编排模块去协调这群“员工”之间的沟通，成本比收益大得多。
回头复盘很多翻车项目，问题往往不在模型能力，而在架构选型。多数人根本没分清多智能体系统里的三种组织方式：Subagent、Handoff、Agent Teams。它们看起来都是“多个 Agent 一起干活”，但适用的场景、复杂度、稳定性完全是三码事。这篇文章我想把这三者的边界一次说透，并附上我在实操中沉淀的选型方法、示例代码和踩坑记录，帮你在动手前先想清楚到底该用哪一种。
1. 内容整体设计与思路拆解
1.1 为什么多 Agent 不等于高性能
要理解三种组织方式的区别，先得弄明白一个底层逻辑：多 Agent 不等于高性能，它只等于“更复杂的系统”。
单个 Agent 的能力边界是很清晰的，它拿到一个任务，调用自己的工具，按自己的上下文生成结果。当任务超过单 Agent 的能力范围，你自然会想引入第二个、第三个 Agent。但关键在于，Agent 之间协作产生的通信开销、状态同步成本、上下文切换损耗，往往比你省下的那点任务处理时间还要大。
我把多 Agent 系统想象成一个公司的不同组织架构：Subagent 像部门内部招的实习生，你把任务细分后分派下去，他们独立干活，不需要互相汇报，你只需要统一验收结果；Handoff 像客服中心的一次转接，用户的需求需要不同领域的专家依次处理，整个流程是一对一交接的；Agent Teams 则像跨部门协作项目组，一组 Agent 围绕一个共同目标，有分工、有复核、有讨论。
选错架构，就相当于你本来只需要一个实习生帮忙处理杂事，却硬是拉起了一个跨部门项目组，流程没跑起来，协调成本先把你压垮了。
1.2 三种组织方式的本质：分层、交接与协作
我分别用一个词来概括这三种方式的本质。
Subagent 的本质是分层。你在一个主 Agent 下面挂若干子 Agent，主 Agent 负责理解任务、拆解任务、分配任务，子 Agent 负责执行具体子任务，然后把结果回传给主 Agent。这是一种树状结构，控制权在主 Agent 手里，通信方向是纵向的，子 Agent 之间基本不交流。
Handoff 的本质是交接。若干个 Agent 处于平级状态，每个 Agent 负责一个专门的领域，当一个 Agent 发现自己处理不了当前任务，或者任务已经进入到下一个阶段时，它就把上下文完整地交给下一个 Agent。整个过程是横向流转的，像流水线上的工位一样，每个工位只处理自己最擅长的那一道工序。
Agent Teams 的本质是协作。一群 Agent 以平行的方式组织，各自可能有不同的工具和角色，但它们共同围绕一个复杂目标，通过一个调度层来动态分配任务，甚至可能包含讨论、评审、相互调用。这种模式下 Agent 之间会有更多的通信路径，架构最灵活，也最复杂。
搞懂这三个本质，你就知道它们之间不是替代关系，而是在不同复杂度阶梯上的选择。选错了，系统稳定性和可维护性都会急剧下降。
1.3 为什么很多项目根本不需要多 Agent
在展开三种模式之前，我想先泼一盆冷水：很多项目的复杂度，用单 Agent 加工具调用（Function Calling）就能解决，根本不需要走到多智能体这一步。
比如你只需要做“给定一个需求文档，生成一份测试用例”，这个任务有明确的输入、明确的工具、明确的输出，单 Agent 加一个测试用例生成工具就够了。你强行拆成“需求分析 Agent + 测试设计 Agent + 用例评审 Agent”，除了增加三层嵌套的 JSON 解析错误之外，没有任何收益。
我的经验法则是：先用单 Agent 把任务跑通，只有在满足至少两个条件时，才考虑引入多 Agent 架构。哪两个条件？第一，单一 Agent 的上下文窗口确实装不下完整的信息；第二，任务中确实存在天然的阶段性分工，且不同阶段需要的工具和提示词差异很大。
这也是这篇文章的核心建议：别急着上多 Agent，先按自己的真实任务复杂度，找到正确的组织方式。
2. 逐层拆解：Subagent 到底解决什么问题
2.1 Subagent 的核心机制与适用场景
如果你想让一个 Agent 具备多种专业能力，同时你又不想把所有的工具和上下文都塞进同一个 Prompt 里，Subagent 就是最直接的选择。
它的核心机制是：父 Agent 负责调度，子 Agent 负责执行。父 Agent 接收到用户需求后，自行规划要拆解成哪些子任务，然后逐个调用子 Agent 去完成，最后汇总所有结果。每个子 Agent 可以拥有自己独立的 System Prompt、工具集和模型配置，相当于一个“专项小组”。
举个例子。用户让你“调研一下 2025 年国内大模型厂商的 API 定价，并给出一个性价比推荐”。用 Subagent 架构，父 Agent 可以拆出三个子任务：资料收集（调用搜索引擎工具）、价格对比（调用结构化对比工具）、推荐报告生成（调用文档生成工具）。每个子 Agent 各干各的，用不着互相通信，父 Agent 最后把三份结果拼起来。
Subagent 最有价值的场景是阶段并行和无状态子任务。比如你要批量处理一万条客服工单，对每一条工单都要做意图识别、情绪判断、答复制稿。这些都是完全独立的子任务，用 Subagent 的方式并行跑，效率提升非常直观。我这里指的“并行”，是指模块层面的并行编排能力，也就是一次组装多个子 Agent 调用，而不是传统语言环境里的多线程，模型 API 的并发限制才是真正的瓶颈。
2.2 Subagent 的技术实现：从 Tool 到 Agent 的升级
从代码角度讲，Subagent 最少只需要两个核心组件：一是父 Agent 的“任务分配器”，二是子 Agent 的执行单元。
很多框架里，子 Agent 本质上就是封装好的 Tool。你只需要在父 Agent 的 Tool 列表里注册一个特殊工具，这个工具的执行逻辑是“调用一个新的 Agent 完成任务”。我把这种模式叫做“Agent 即工具”。函数大致长这样：
async def run_subagent(task: str, context: dict) -> str: sub_agent = 始终新建一个独立 Agent 配置对应的 system prompt 和工具集 return await sub_agent.run(task, context)然后在父 Agent 的工具列表里注册：
tools = [ { "type": "function", "function": { "name": "run_web_research", "description": "通过子 Agent 完成在线调研任务", "parameters": { "type": "object", "properties": { "task": {"type": "string", "description": "调研任务的具体描述"} } # 仅示意，实际情况可能还有其他序列化结构 } } } ]有几点实操层面的体会：
第一，子 Agent 的 System Prompt 一定要极简、聚焦，不要什么都往里面塞。子 Agent 的任务范围越小，它的输出质量和稳定性就越好。我发现一个子 Agent 的 Prompt 超过 2000 字，它的行为就开始“漂移”。
第二，子 Agent 需要返回给父 Agent 的内容必须结构化，最好用 JSON 格式，字段固定，不要有自由发挥空间。父 Agent 拿到结构化结果后，再做统一的格式化或汇总，这样能减少解析错误。
第三，子 Agent 的上下文要独立管理。如果子 Agent 能“看到”父 Agent 的全部上下文，那这个设计就失去了意义。子 Agent 只应看到自己完成任务所需的最小上下文，否则又多花钱，又增加上下文冲突。
2.3 什么时候别用 Subagent
Subagent 最大的问题在于：父 Agent 是瓶颈。父 Agent 要负责理解、拆解、调度、汇总，它承载了几乎所有的智能调度负担。如果你的任务需要多轮协作、需要不同子 Agent 之间相互讨论，Subagent 就不太合适了。
团队对一个系统的容错要求通常很高。Subagent 架构中，一旦父 Agent 的任务分解出现错误，整个执行链路都会失败，而且是“静默失败”——父 Agent 可能补一句“这个子任务我合并处理了”然后跳过关键步骤。排查起来特别痛苦，因为问题不在子 Agent 的结果，而在父 Agent 的“脑回路”。
因此，当任务本身需要动态路由、需要多个领域专家依次处理时，Subagent 已经不是最优解，Handoff 是更合理的组织方式。
3. 流程交接：Handoff 的适用边界与实现要点
3.1 Handoff 到底是什么，和 Subagent 有什么不同
Handoff 最典型的应用是客服系统。用户先和接待 Agent 对话，接待 Agent 判断“这人要解决技术故障”后，把会话转给技术支持 Agent；技术支持 Agent 查了查说“需要做退款处理”，又把会话转给订单售后 Agent。每一次转接，当前 Agent 都会把对话历史、用户信息、当前状态完整地传给下一个 Agent。
和 Subagent 相比，核心区别在于：Subagent 是有中心的，父 Agent 始终掌握全局；Handoff 是无中心的、链式的，每个 Agent 在接手任务的那一刻，自己就是新的中心，处理完再传给下一个。
我用一个生活化类比来帮助理解：Subagent 像是你去饭店，点了一桌菜，厨师长负责分配炒菜师傅、凉菜师傅、煲汤师傅；Handoff 则像你去医院，需要先去挂号分诊，分诊台判断你挂内科，内科医生检查后说需要做手术，转到外科，外科医生处理后说你还要康复治疗，再转到康复科。
Handoff 不需要一个“全知全能”的主 Agent 来指挥。每个 Agent 只需要做一件事：判断当前任务是否在自己能力范围内。在自己范围内就自己处理，不在就把话柄交出去。
3.2 利用 Handoff 构建线性流程
Handoff 非常适合线性流水线任务，比如内容审核、申请审批、多阶段报告生成。我以“简历筛选”为例给你演示核心实现思路。
这里有三个 Agent：HR Agent 负责初筛，Tech Agent 负责技术能力评估，Final Agent 负责最终决策。每个 Agent 都声明自己可以处理什么，不能处理什么。
from agents import Agent, Runner, handoff hr_agent = Agent( name="HR Agent", instructions="你是 HR 专员，负责筛选候选人的基本资质。" "如果候选人的经验年限匹配，就说明 'APPROVED'。" "如果不匹配，直接交给 final_agent 处理。" ) tech_agent = Agent( name="Tech Agent", instructions="你是技术面试官，负责评估候选人的技术深度和项目经验。" "评估结束后，将结论提交给 final_agent 做决策。", handoffs=[hr_agent] ) final_agent = Agent( name="Final Agent", instructions="你是招聘负责人，根据 HR 缇糨和技术评估的结论给出最终录用决策。", handoffs=[hr_agent, tech_agent] )这里需要注意一个关键点：在 Agent SDK 里，Handoff 不是简单地“调另一个函数”，而是要在一个新的 Agent 实例中恢复执行，它会带着之前所有 Agent 的对话历史和内部状态。也就是说，当你从 HR Agent 传给 Tech Agent 时，Tech Agent 是能“看到”之前 HR 阶段的对话的。这种能力的代价就是状态管理复杂度变高，你必须保证传给下一个 Agent 的上下文是干净的、可追踪的。
实际操作中，很多团队在这个地方翻车：传出去的上下文里附带了一堆中间推理过程，下一个 Agent 被误导，做出了错误决策。我的解决方案是：在 Handoff 之前，让当前 Agent 输出一个“交接摘要”，只把这个摘要和必要的原始上下文传给下一个 Agent。摘要包含三段：当前结论、待办事项、关键证据。
3.3 动态路由中的 Handoff 策略
Handoff 不仅适用于线性流程，它也是动态路由的重要手段。
什么是动态路由？简单说，系统一开始不知道任务应该交给谁处理，需要靠 Agent 自己判断。比如你搭了一个“综合知识助手”，用户提问“帮我看看这个电路板哪里烧了”，系统预置了三个 Agent：美食专家、编程专家、硬件维修专家。它怎么知道要把任务转给谁？靠的就是每个 Agent 自身的领域识别能力，或者一个独立的 Handoff 判断条件。
在代码层面，Handoff 的一端是“当前 Agent 判断该转给谁”，另一端是“接收方 Agent 的调用接口”。这类动态路由的性能，完全取决于每个 Agent 对自身边界的定义清晰度。我在 Agent 的 Instructions 里会反复强调“什么时候你绝对不能接手”，比“什么时候你可以接手”更重要。负面约束对模型行为的规范效果往往比正面描述更好。
3.4 为什么不建议所有场景都用 Handoff
Handoff 虽然结构优雅，但它有个天生的弱点：串行时延叠加。任务每经过一个 Agent，都会产生一次完整的大模型推理调用。一个流程经过四个 Agent，用户等到的响应时间就是四次模型推理之和（可能还不止，因为模型自己决定要内部推理多轮）。如果是 real-time chatbot，这种延迟体验基本不可接受。
另外，Handoff 链路的故障排查难度也比较大。假设最终结果出错了，你不知道错误是在第一个 Agent 的判断上、中间某一个 Agent 的处理上，还是在最后一个决策上。整个链路就像一个嵌套的函数调用栈，靠日志一层一层回滚排查的体验，属实酸爽。
所以，如果任务的步骤可以静态确定，且流程比较短、阶段边界清晰，才建议优先用 Handoff。如果任务是一个多角色、多工具、大量交互讨论的复杂协作场景，应该考虑下面要说的 Agent Teams。
4. 团队协作：Agent Teams 的复杂模式与实战经验
4.1 Agent Teams 的运行机制
Agent Teams 是所有多智能体组织方式中最复杂、最灵活、也最容易玩脱的一种。
它的核心运行机制可以拆成三种角色的协同：一是“路由 Agent”，负责接收任务并决定分发到哪个工作子 Agent；二是“工作Agent”，负责具体的领域任务执行；三是“审计 Agent”，负责检查工作 Agent 的输出，判断是否返工或直接通过。
听起来是不是和 Subagent 有点像？确实，Agent Teams 在形式上可能复用 Subagent 的调用方式，但关键区别在于反馈回路。Subagent 是单向的“分配 → 执行 → 归集”，Agent Teams 允许审计 Agent 把任务打回去重新处理，允许路由 Agent 根据中间结果调整原始任务分配方案。这种反馈机制让它能处理更复杂的、非确定性的任务。
我用一个“智能运维告警系统”来举例。这个系统每分钟要处理数千条服务器告警，每个告警都需要：判断严重级别，关联历史故障记录，给值班工程师生成处理方案。单 Agent 根本扛不住上下文和逻辑复杂度，Subagent 又不够灵活——告警之间可能有相关性，比如说多个告警只是同一个故障在多个指标上的不同投影，你需要一个专职 Agent 去“去重聚合”，这些聚合同伴逻辑需要大量的迭代讨论。
用 Agent Teams 怎么设计？一个路由 Agent 接收所有告警；三个工作 Agent 分别专职处理“硬件类告警”“网络类告警”“应用类告警”；一个审计 Agent 专门检查工作 Agent 输出的处理建议是否准确，发现“这台服务器已经报了三十分钟 CPU 告警，你才建议重启，太晚了”，就会打回重做。这套架构在实战中能显著提升大促高峰期告警处理效率。
4.2 中心化 vs 去中心化：Agent Teams 的组织哲学
在设计 Agent Teams 时，经常会遇到哲学问题：到底要不要保留一个“总指挥”？
我的结论是：对于绝大多数业务场景，中心化架构更稳。一个中心调度 Agent 负责制定计划、分发任务、汇总结果和最终交付，其他 Agent 只是执行节点。这个中心调度 Agent 不需要比工作 Agent 更专业，它只需要比它们更有全局观。
但中心化有个隐患：调度 Agent 的上下文如果太宽，开销会急剧膨胀，甚至出现“调度 Agent 忘了让某个工作 Agent 干活”的乌龙。我见过一个真实案例，一个五 Agent 的协作系统，最后排查发现主 Agent 用了八轮推理、两万多 token 还没完成调度，就因为它一直在“思考最优方案”，迟迟不下发指令。
去中心化则恰好相反，每个 Agent 平等协作，通过讨论达成一致。这种方式在论文研讨、战略分析这类开放性任务中效果不错，但稳定性和可控性极差，调试成本极高。我建议普通团队不要轻易尝试全去中心化，成本不在模型调用，而在无休止的“争论”可能直接掩盖问题。
4.3 Agent Teams 中常见的路由与分发陷阱
Agent Teams 看起来美好，实际跑起来坑很多。我给你列几个最典型的。
第一个坑是置乱路由。有一个路由 Agent 同时把任务发给多个工作 Agent，而这些工作 Agent 有重叠的能力边界，导致多个 Agent 重复处理同一个任务，造成资源浪费和结果冲突。解决思路是在路由 Agent 的 Instructions 里指定明确的 Assignee 选择策略——宁可让一个任务没人处理，也不能让两个 Agent 同时处理。如果加了“无人处理再重新路由”的策略，稳定性会好很多。
第二个坑是缺少终止条件。Agent Teams 的反馈回路如果设计得不好，会出现“审计 Agent 打回 → 工作 Agent 修改 → 审计 Agent 又打回 → 工作 Agent 再修改”的无限循环。有团队直接跑出了上千次迭代，费用高到吓人。我的做法是在每次打回时，审计 Agent 都必须给出具体的修改建议，而不是单纯拒绝；同时设置最大迭代次数，超过次数自动升级给人工处理。相当于给团队上了一道安全红线。
第三个坑是任务粒度失衡。每个工作 Agent 的任务粒度差异过大，有的 Agent 每次只需要做个动作，有的 Agent 则要花大量算力完成一个巨型任务。粒度小的 Agent 早早挂起，粒度大的 Agent 成了瓶颈。在设计阶段，应该尽量把任务拆均匀，或者让路由 Agent 统计各 Agent 的描述和工具调用频次，自动调整后续任务分发策略。
4.4 从 Subagent 向 Agent Teams 演进的时机
很多踩过坑的团队会问我：什么时候应该从 Subagent 切到 Agent Teams？
我的判断标准就一条：当任务的不可预测性超过某个阈值时。如果子任务的执行路径在编写代码时就能 100% 确定，那用 Subagent、用工作流、甚至用普通代码写死都行；只有当任务本身需要动态决策、结果需要多轮修正、不同模块之间存在相互依赖时，才值得引入 Agent Teams。
换句话说，Agent Teams 应该是最后的选择，而不是第一选择。从单 Agent 一点一点加到多 Agent，而不是一开始就拉满。这也是为什么我一直在强调“别急着上多 Agent”。
5. 核心判断准则：我到底该选哪种模式
5.1 一张表帮你快速决策
我不太喜欢讲虚的。下面这张表格就是我每次做架构判断时心里默认的那张决策表，直接给出来：
| 判断维度 | Subagent | Handoff | Agent Teams |
|---|---|---|---|
| 适用任务形态 | 一个主任务分成多个独立子任务 | 任务按专业领域分阶段传递 | 多角色围绕一个复杂目标动态协作 |
| 通信方向 | 纵向（父子） | 横向（链式交接） | 网状（多路路由 + 反馈） |
| 控制权归属 | 父 Agent 全局掌控 | 当前 Agent 局部掌控 | 调度/路由 Agent 掌控，或分布式 |
| 状态共享方式 | 子 Agent 只取最小上下文 | 每次交接完整对话快照 | 各 Agent 关键状态逐步沉淀进共享内存或路由层 |
| 实现复杂度 | 低 | 中 | 高 |
| 典型例子 | 批量数据处理、独立调研任务 | 客服转接、多阶段审批 | 运维告警聚合、复杂报告生成、多专家评审 |
| 我最推荐的使用场景 | 任务拆解清晰且子任务互不依赖 | 流程阶段清晰且需要不同专业角色 | 任务边界不清晰，需要动态讨论和修正 |
补充一个要点：这三种方式并非完全对立。实际项目里很可能同时使用 Subagent 和 Handoff。例如一个主流路由分发后，其中某条链路内部又用到子 Agent 并行处理。设计时要先确定顶层组织方式，再逐层决定内部细节。
5.2 三个关键问题：技能边界、通信密度与结果形态
除了表格，实操时我还会问自己三个问题，答案直接指向模式选择。
问题一：技能的边界在哪里？如果我无法清晰划分“哪个 Agent 擅长什么”“哪个 Agent 绝对不擅长什么”，那我连 Subagent 都不该用，应该先回头把任务分析清楚。技能边界清晰是用一切多 Agent 架构的前提，边界模糊时强行上多 Agent，系统只会混乱。
问题二：通信的密度有多高？子任务之间几乎不沟通，选 Subagent；需要一条清晰的流程链路传递信息，选 Handoff；需要多角色来回讨论、反复修改，选 Agent Teams。
问题三：期待的交付物形态是什么？如果你期待的是一份固定格式的报告，那所有信息可以汇总后统一生成；如果你期待的是在报告生成过程中还需要决策、评审、返工，那就要用 Agent Teams，并且在路由层或共享内存层记录过程状态与中间产物。
5.3 中心化的思考者，分布式的执行者
作为一个大量落地多 Agent 项目的工程师，我最后分享一个比较深刻的心得。
之前在 OpenAI 中文社区看到过一个观点，大意是“每个 Agent 系统都应该有一个中心化的思考者和分布式的执行者”。我完全认同。意思是：思考、决策、规划应该集中在一个可控的节点上，而执行可以尽量分散。这个原则能同时保证系统的智能上限和可维护性。
如果你把这句话应用到实践中，就会发现：Subagent 天然符合这个原则（父 Agent 思考，子 Agent 执行）；Handoff 是“分段思考 + 分段执行”；Agent Teams 最容易偏离这个原则，想着“每个 Agent 都很强”，结果每个 Agent 都在思考，反而没有人在真正对最终结果负责。
我在设计 Agent Teams 时，会把这一原则写进调度 Agent 的 System Prompt 里：你才是项目的最终负责人，你有权限打断、返工、终止任何子 Agent 的任务。用这种强中心化设计去约束 Agent Teams 的自由度，系统稳定性会高很多。也可以把“当前进度摘要 + 阶段性结论”持续写入一个共享记忆层或状态对象，供路由和审计读取。你说到的“多 agent 共享记忆”热词，本质就是这个意思，但真正的挑战不是技术实现，而是记忆的写入策略和淘汰机制，否则共享记忆会变成一个大垃圾箱。
6. 实操中常见的翻车案例与排查方案
6.1 案例一：Subagent 输出认知偏差
真实项目里，我们曾用一个“分析 Subagent”去处理用户上传的调研素材，再把结果返回给主 Agent 写总结。最初设计时，分析 Subagent 的 Instructions 只写了“提炼关键数据和事实”。结果它不够“智能”，竟然把素材里矛盾的项也一起提炼了，导致主 Agent 的总结里出现了两个冲突结论。
排查过程很有意思，拉到日志里才发现，主 Agent 只是原样使用了分析 Subagent 的输出，根本不知道为什么会有冲突。最后解决方案是给分析 Subagent 加了一条硬性指令：如果发现信息矛盾，必须在输出中明确标出 two_sides，并说明为什么无法判断，而不是擅自合并或删除。
你会在这种时刻深深体会到：子 Agent 的 Instructions 必须包含“如何证明自己的结论”和“什么情况下承认自己不知道”。这两点远比“做什么”更重要。
6.2 案例二：Handoff 链路的上下文污染
另一个项目我们做了一个文档翻译审校系统，流程是“翻译 Agent → 术语 Agent → 审校 Agent”。开始设计的时候没做上下文裁剪，结果术语 Agent 看到的对话历史里充斥着中间推理，导致它在审校时反复修改同一个术语，理由是“我看到了之前某个临时术语后来不需要保留”。
我排查了很久才意识到，问题出在一个迁移到新 Agent 实例时，会把旧 Agent 的历史消息一字不漏地带过去。后来在每次交接前，让前序 Agent 生成一个结构化的交接摘要，这个摘要同时作为新 Agent 的上下文前缀，原始消息全部裁剪掉。术语 Agent 的输出准确率明显提升，上下文 token 消耗也大幅下降。这个方案现在我已经固定为 Handoff 的默认设计。
6.3 案例三：Agent Teams 的无效迭代
最经典的翻车当然还是“打回 — 重做”的死循环。
在“智能运维告警聚合”项目初期，我们给审计 Agent 的指令是“如果处理方案不合理，打回重做”，没有给具体的修改建议，也设置了最大重试轮次。结果发现工作 Agent 每次被打回后，只是调整了一下表述措辞，又把几乎一样的方案提交上来，审计 Agent 再打回，又换一种措辞再提交。如此反复，直到触发我们设的最大轮数才停止，但结果仍然不合格，最后还是靠人工改了。
这个案例让我养成了一个原则：审计 Agent 必须同时是指导 Agent。它不仅说“不行”，还要说“应该改成什么样”。如果审计 Agent 做不到给出建设性意见，说明该 Agent 的能力不足以担任审计角色，需要更换或补充更细致的参考资料。
6.4 常见问题速查表
| 现象 | 可能原因 | 排查思路与解决建议 |
|---|---|---|
| 某个子 Agent 频繁输出低质量结果 | System Prompt 承担了过多职责 | 拆分岗位；增加负面边界说明；给示例输出 |
| 父 Agent 总在“规划”，迟迟不执行 | 调度逻辑塞了太多工具和约束 | 把规划与执行分离；让调度 Agent 在首轮就下发第一个动作 |
| Handoff 后新 Agent 的行为异常 | 历史上下文污染 | 用结构化交接摘要替代完整历史；只保留必要用户意图与状态 |
| Agent Teams 反复修改同一处问题 | 审计指令缺少具体建议 | 强制审计 Agent 返回修改建议；设置最大迭代次数 |
| 多 Agent 系统费用远超预期 | 每个 Agent 反复读取超大上下文 | 启用上下文压缩；定期清理历史；用共享记忆层存储关键结论 |
6.5 多 Agent 共享记忆的误区
最后聊一下“多 agent 共享记忆”。这个热词确实在多个项目里被反复提到，但很多理解是错的。
很多人以为共享记忆就是把所有 Agent 的聊天记录全部塞到一个向量数据库里，谁要用谁去查。这是条岔路。试想一下，如果几个 Agent 都要读同一段很长的记录，结论很容易被无关历史带偏。
我的建议是：共享记忆里只放“经过提炼的结论、状态和决策”，原始对话单独归档，不直接参与 Agent 推理上下文。例如一个故障处理的 Agent Teams，共享记忆里应该记录的是：“错误码 503 已在 14:30 触发，当前状态修复中，已通知安全工程师老王”，而不是把运维平台一整天的日志都放进去。
共享记忆需要明确的写入时机和淘汰机制，否则它会成为新的不可控上下文。我一般在路由层设置一个记忆写入策略：每次审计通过或任务阶段完成时，把阶段结论写入共享记忆；每次新任务开始时，按相关性和时间衰减读取最近的记忆子集。这样 Agent 不必每次都追溯所有历史，也能保持决策的一致性。
6.6 从日志角度设计可观测性
一个多 Agent 系统如果没有好的日志设计，你会在排查问题时生不如死，这一点必须留足工程冗余。
我给每个 Agent 分别分配一个 trace_id，同时用全局 request_id 串联整条请求链路。每一步 Agent 执行、工具调用、Handoff 转接、Task 生成，都输出结构化日志，包含输入摘要、输出摘要、token 消耗、耗时。特别是 Handoff 的交接，我会额外记录交接摘要的原文，方便在最终结果出错时追溯是哪一环交接决策有问题。
市面上常见的框架其实都提供了比较基础的 tracing 功能（比如 Agent SDK 的 Run Tracing），但这些默认 tracing 只能到“哪个 Agent 调用了哪个 Tool”的粒度，对于 Agent Teams 的场景远远不够。我建议业务团队还是要自建一层业务日志，把 Agent 决策过程中的关键节点记录下来，才能支撑起后面的质量复盘和优化。
7. 最终建议和一点个人经验
文章写到这里，我把自己这几年在多 Agent 架构上的沉淀都展开了。核心就一句话：别急着上多 Agent，先分清 Subagent、Handoff 和 Agent Teams，再根据任务的确定性、通信密度和技能边界来做选型。
从个人经验来说，我见过太多翻车案例都是因为“想一步到位”。实际稳妥的路径应该是：
先跑通单 Agent 基线，用函数调用来解决部分工具性问题。如果单 Agent 确实不够，再引入 Subagent，这是复杂度最低的升级路径。如果任务有明显阶段分界，而且需要不同专业角色接力，再考虑 Handoff。最后只有任务不可预测、需要多角色动态讨论、需要返工修正时，才上 Agent Teams。
在写代码之前，永远先画一张协作关系图，标清楚谁是决策者，谁是执行者，谁负责审计，上下文在什么时候在哪两个 Agent 之间流转。这张图多花半小时，能帮你省掉后面好几天的排查成本。
还有一个比较容易被忽略的小建议：不要把所有 Agent 都设置成同一个大模型。成本敏感的子任务可以用更强的模型，高频但简单的任务完全可以用响应更快的模型。按任务复杂度分配模型规格，多 Agent 系统的成本能有效下降。
如果这篇文章能让你在动手写第一个多 Agent 项目之前多想十秒钟，那我觉得它就值了。
