1. 从单轮到多 Agent：为什么架构必须演进
1.1 单轮调用的本质与天花板
很多人第一次接触 Agent，都是从“给大模型一个工具，让它自己决定调不调”开始的。这其实就是最原始的单轮调用形态：用户输入一句话，模型判断是否需要调用某个函数，拿到结果后直接生成最终回复。整个过程只有一次“思考—行动—回答”的闭环，干净利落，调试也简单。
我早期做客服意图识别的时候，就是这种模式。用户问“我的订单到哪了”，模型识别出query_order这个工具，传入订单号，拿到物流信息，拼成一句话返回。链路短、延迟低、可控性强，上线第一个月准确率能到 92% 左右。但很快问题就来了：用户接着问“那帮我改一下收货地址”，模型不知道上一轮查的是哪个订单，因为它没有“记住”上下文里的工具调用结果。你只能把历史记录一股脑塞进 prompt，token 消耗飙升，而且模型经常把不同订单的字段搞混。
单轮调用的天花板非常明显：它只能处理“一步就能解决”的任务。一旦任务需要多步推理、跨工具协作、或者依赖中间结果做二次判断，单轮调用就会力不从心。更麻烦的是，你没法在中间插入人工审核、数据校验或者异常回滚。它就像一个只会做单选题的学生，你让他写一篇议论文，他直接交白卷。
1.2 多 Agent 协作到底解决了什么问题
多 Agent 协作的核心思路，是把一个复杂任务拆成多个子任务，每个子任务交给一个专门的 Agent 去处理，Agent 之间通过消息传递、共享内存或者编排层来协调。听起来像是“把一个人的活分给一个团队”，但实际落地时，它解决的是三个单轮调用根本搞不定的问题。
第一是上下文隔离。写代码的 Agent 不需要知道客服对话的历史，查数据库的 Agent 不需要理解自然语言里的情绪。每个 Agent 只关心自己那一亩三分地，prompt 可以做得非常精简，推理准确率反而更高。我实测过一个场景：让一个 Agent 同时做“查订单+改地址+发通知”，准确率只有 67%；拆成三个 Agent 串行执行，每个环节准确率都在 90% 以上，整体成功率反而升到 85%。
第二是工具权限分离。单轮调用时，模型手里攥着所有工具的调用权限，一旦被诱导，可能直接调用删除接口。多 Agent 架构下，查数据的 Agent 只有只读权限，改数据的 Agent 需要经过审批 Agent 的二次确认。这种“最小权限原则”在安全敏感场景里几乎是刚需。
第三是可观测与可干预。每个 Agent 的输入输出都是独立的，你可以单独给某个 Agent 加日志、加断点、加人工审核。单轮调用是一团黑盒，出了问题只能看最终输出，排查成本极高。
1.3 什么场景该上多 Agent，什么场景别硬上
不是所有任务都值得拆成多 Agent。我见过不少团队，明明就是一个“查天气+发邮件”的简单流程，非要搞三个 Agent 互相发消息，结果延迟从 1.2 秒涨到 4.5 秒，故障点还多了两倍。判断标准其实很简单：如果任务可以在一轮工具调用内完成，或者只需要线性串行两步，单轮调用加一个简单的状态机就够了。
真正需要多 Agent 的场景，通常具备以下特征：任务步骤超过三步且存在分支判断；不同步骤需要不同的工具权限或数据隔离；需要多个“专家角色”从不同角度分析同一份输入（比如一个 Agent 写代码，一个 Agent 做代码审查）；或者任务执行时间很长，需要异步并行处理。我个人的经验是，当单轮调用的 prompt 超过 2000 token 且还在膨胀时，就是时候考虑拆 Agent 了。
2. 多 Agent 协作的四种主流实现方式
2.1 串行流水线：最稳但最慢
串行流水线是最容易理解的多 Agent 形态。Agent A 处理完，把结果传给 Agent B，B 处理完传给 C，像工厂流水线一样。它的优势是逻辑清晰、调试简单、每个环节可独立替换。我做过一个合同审核的流程：提取 Agent 负责从 PDF 里抽关键条款，比对 Agent 负责和标准模板做差异分析，风控 Agent 负责判断是否存在高风险条款。三个 Agent 串行，每个环节的输出都是下一个环节的输入，出了问题直接看中间结果就能定位。
但串行的缺点也很致命：总延迟等于所有 Agent 延迟之和。如果每个 Agent 平均耗时 1.5 秒，五个 Agent 就是 7.5 秒，用户早就关页面了。所以串行流水线适合对延迟不敏感的后台任务，比如批量数据处理、夜间报表生成。如果非要用于实时场景，必须做流式输出，让用户先看到部分结果。
2.2 并行扇出：用并发换时间
并行扇出的思路是，把同一个输入同时发给多个 Agent，每个 Agent 独立处理，最后由一个聚合 Agent 汇总结果。典型场景是“多角度分析”：一份用户反馈，情感分析 Agent 判断情绪，分类 Agent 打标签，实体抽取 Agent 提取产品名，三个 Agent 同时跑，最后合并成结构化数据。
这种模式的关键在于聚合策略。如果三个 Agent 的结果有冲突怎么办？我的做法是给每个 Agent 设一个置信度权重，聚合时加权投票。比如情感分析 Agent 置信度 0.9，分类 Agent 置信度 0.7，冲突时以高置信度为准。另外，并行扇出对基础设施有要求：你得能同时发起多个模型调用，并且处理好超时和部分失败。我一般会给每个 Agent 设 3 秒超时，超时的 Agent 直接返回空结果，不阻塞整体流程。
2.3 层级编排：主管 Agent 与工人 Agent
层级编排是我目前最常用的架构。一个“主管 Agent”负责理解用户意图、拆解任务、分配给“工人 Agent”，工人 Agent 执行完把结果交回主管，主管决定下一步。这就像项目经理带团队，项目经理不写代码，但他知道谁该写什么。
主管 Agent 的 prompt 里通常包含一份“工人名册”，描述每个工人的能力边界和输入输出格式。工人 Agent 的 prompt 则非常聚焦，只做一件事。我做过一个数据分析场景：主管 Agent 收到“帮我分析上个月销售下滑原因”，它会拆成“查销售数据”“查流量数据”“查竞品动态”三个子任务，分别派给三个工人 Agent，最后汇总成一份报告。实测下来，主管 Agent 的拆解准确率在 88% 左右，主要错误是拆得太细或太粗，需要反复调 prompt。
层级编排的坑在于主管 Agent 容易成为瓶颈。如果工人 Agent 返回的结果格式不对，主管可能反复重试，陷入死循环。我的做法是给主管设一个最大重试次数（通常 3 次），超过就降级返回“部分结果+人工介入提示”。
2.4 黑板模式：共享内存驱动的协作
黑板模式源自经典 AI 架构，多个 Agent 共享一块“黑板”（通常是 Redis 或内存数据库），每个 Agent 都可以读写黑板上的内容，通过轮询或事件触发来决定自己何时行动。这种模式适合没有明确先后顺序、需要多 Agent 协同编辑同一份数据的场景。
比如一个代码生成任务：架构 Agent 先在黑板上写下模块划分，编码 Agent 读取后生成代码片段写回黑板，测试 Agent 读取代码生成测试用例，审查 Agent 检查代码规范。每个 Agent 不需要知道其他 Agent 的存在，只关心黑板上的状态变化。这种松耦合的好处是扩展性强，加一个新 Agent 只需要让它订阅黑板事件即可。
但黑板模式的调试难度最高。因为 Agent 之间的触发关系是隐式的，出了问题很难追踪是哪个 Agent 在什么时候改了哪块数据。我一般会在黑板上加版本号和操作日志，每次读写都记录 Agent ID 和时间戳，方便回放。
3. 核心组件拆解：一个多 Agent 系统到底由什么构成
3.1 编排层：谁来决定下一步谁干活
编排层是多 Agent 系统的大脑。它可以是代码里的一个状态机，也可以是一个专门的编排 Agent。状态机的好处是确定性高，每个状态转移都是硬编码的，不会出现“模型突然决定不按流程走”的情况。我早期做审批流的时候就用状态机：提交→初审→复审→通过/驳回，每个节点触发对应的 Agent，简单可靠。
但状态机的问题是灵活性差。如果任务分支特别多，状态机会膨胀成一张巨大的图，维护成本很高。这时候就需要编排 Agent 出场。编排 Agent 本质上是一个被赋予了“调度权”的模型，它根据当前上下文决定下一个该调用哪个 Agent。它的 prompt 里通常包含所有 Agent 的描述和当前任务状态，输出是下一个 Agent 的名字和输入参数。
我的经验是：流程固定的用状态机，流程动态的用编排 Agent，混合使用最稳。比如主流程用状态机保证不跑偏，每个状态内部的子任务分配用编排 Agent 灵活处理。
3.2 记忆系统：Agent 怎么记住上下文
多 Agent 系统里的记忆分三层。第一层是短期记忆，就是当前对话的上下文窗口，通常只保留最近几轮的消息。第二层是工作记忆，存储当前任务执行过程中的中间结果，比如某个 Agent 查到的数据、生成的草稿。第三层是长期记忆，跨会话持久化的知识，比如用户偏好、历史工单记录。
工作记忆的存储选型很关键。我试过三种方案：直接放在 prompt 里（简单但 token 消耗大）、放在 Redis 里（快但需要序列化）、放在向量数据库里（适合语义检索但延迟高）。实测下来，工作记忆用 Redis 存结构化 JSON，需要时按 key 取出来拼进 prompt，是性价比最高的方案。长期记忆才用向量数据库，因为需要语义相似度检索。
这里有个坑：多 Agent 共享记忆时，容易出现“写冲突”。Agent A 和 Agent B 同时读到一个值，各自修改后写回，后写的覆盖先写的。我的做法是给工作记忆加乐观锁，每次写入前检查版本号，冲突时让 Agent 重新读取最新值再操作。
3.3 工具层：Agent 的手和脚
工具层就是 Agent 能调用的外部能力，包括 API、数据库查询、文件操作、代码执行等。多 Agent 架构下，工具层需要做权限隔离：每个 Agent 只能看到自己被授权的工具列表。这不仅仅是安全考虑，也能减少模型的选择困难。我做过对比实验：给一个 Agent 20 个工具，它选错工具的概率是 18%；只给它 5 个相关工具，选错概率降到 4%。
工具描述的质量直接影响调用准确率。我的经验是，工具描述里必须包含：功能一句话说明、输入参数的类型和示例、输出格式、以及什么情况下不该用这个工具。最后一条最容易被忽略，但效果显著。比如“查订单”工具的描述里加上“如果用户没有提供订单号，不要调用此工具，先询问订单号”，能减少大量无效调用。
3.4 通信机制：Agent 之间怎么说话
Agent 之间的通信有两种主流方式：消息传递和共享状态。消息传递是 Agent A 直接给 Agent B 发一条结构化消息，B 收到后处理并回复。这种方式适合串行和层级编排，通信路径清晰。共享状态就是前面说的黑板模式，Agent 通过读写共享存储来间接通信。
消息格式我强烈建议用 JSON Schema 严格约束。早期我用自然语言让 Agent 之间传话，结果 A 说“订单号是 12345”，B 理解成“订单号可能是 12345”，C 直接当成“订单号不是 12345”。后来改成{"order_id": "12345", "confidence": 0.95}，问题立刻消失。Agent 之间的通信必须是机器可解析的，自然语言只用于最终面向用户的输出。
4. 实操：从零搭一个多 Agent 协作原型
4.1 环境准备与框架选型
如果你只是想快速验证想法，我建议从轻量级框架入手。LangChain 的 Agent 模块适合快速原型，但它的抽象层比较厚，调试时容易迷失。AutoGen 在多 Agent 对话方面做得不错，但学习曲线陡峭。我目前用得最多的是自己写编排层+直接调模型 API，因为可控性最强，出了问题能精确到每一行代码。
环境上，Python 3.10+ 是底线，依赖主要是openai或anthropic的 SDK、redis做工作记忆、pydantic做数据校验。如果你要用本地模型，ollama或者vllm都可以，但多 Agent 场景下本地模型的并发能力往往不够，建议至少用 API 版本做原型验证。
# 最小依赖安装 pip install openai redis pydantic httpx4.2 定义 Agent 的输入输出契约
在写任何逻辑之前，先把每个 Agent 的输入输出用 Pydantic 模型定死。这是整个项目里最重要的一步，没有之一。我见过太多项目因为 Agent 之间传参格式不统一，导致调试时间比开发时间还长。
from pydantic import BaseModel, Field from typing import Literal class TaskInput(BaseModel): task_id: str user_query: str context: dict = Field(default_factory=dict) class AgentResult(BaseModel): agent_name: str status: Literal["success", "failed", "need_human"] output: dict confidence: float = Field(ge=0, le=1) error_message: str | None = None每个 Agent 的函数签名都遵循TaskInput -> AgentResult，这样编排层可以用统一的方式调用任何 Agent，不用关心内部实现。confidence字段是必须的，后面做聚合和降级判断全靠它。
4.3 实现一个主管 Agent 的调度逻辑
主管 Agent 的核心是一个循环：读取当前任务状态，决定下一个 Agent，调用它，更新状态，直到任务完成或达到最大步数。下面是我常用的简化版调度器：
import json from openai import OpenAI client = OpenAI() AGENT_REGISTRY = { "data_fetcher": "负责从数据库查询销售数据，输入：时间范围", "trend_analyzer": "负责分析数据趋势，输入：销售数据JSON", "report_writer": "负责生成分析报告，输入：趋势分析结果", } def supervisor_agent(task_input: TaskInput, max_steps: int = 5) -> AgentResult: state = {"task": task_input.user_query, "history": [], "step": 0} while state["step"] < max_steps: prompt = f""" 当前任务：{state['task']} 已执行步骤：{json.dumps(state['history'], ensure_ascii=False)} 可用Agent：{json.dumps(AGENT_REGISTRY, ensure_ascii=False)} 请决定下一步调用哪个Agent，输出JSON格式： {{"next_agent": "agent_name", "input": {{...}}, "reason": "..."}} 如果任务已完成，next_agent 填 "FINISH"。 """ response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], response_format={"type": "json_object"} ) decision = json.loads(response.choices[0].message.content) if decision["next_agent"] == "FINISH": return AgentResult( agent_name="supervisor", status="success", output={"final": state["history"][-1]}, confidence=0.9 ) # 调用对应 Agent（这里省略具体实现） result = call_agent(decision["next_agent"], decision["input"]) state["history"].append({ "agent": decision["next_agent"], "input": decision["input"], "output": result.output, "status": result.status }) state["step"] += 1 return AgentResult( agent_name="supervisor", status="need_human", output={"partial": state["history"]}, confidence=0.5, error_message="达到最大步数限制" )这段代码的关键点在于：主管 Agent 只输出 JSON，不输出自然语言。response_format={"type": "json_object"}强制模型返回结构化数据，避免解析失败。另外，max_steps是必须的，防止模型陷入无限循环。
4.4 工作记忆的读写与版本控制
工作记忆我用 Redis Hash 来存，每个任务一个 key，field 是变量名，value 是 JSON 字符串。版本控制用一个单独的version字段，每次写入前用 WATCH/MULTI 做乐观锁。
import redis import json r = redis.Redis(host='localhost', port=6379, decode_responses=True) def read_memory(task_id: str) -> dict: data = r.hgetall(f"task:{task_id}") return {k: json.loads(v) for k, v in data.items() if k != "version"} def write_memory(task_id: str, updates: dict, expected_version: int) -> bool: key = f"task:{task_id}" with r.pipeline() as pipe: try: pipe.watch(key) current_version = int(pipe.hget(key, "version") or 0) if current_version != expected_version: pipe.unwatch() return False pipe.multi() for k, v in updates.items(): pipe.hset(key, k, json.dumps(v, ensure_ascii=False)) pipe.hset(key, "version", current_version + 1) pipe.execute() return True except redis.WatchError: return False实测下来，这套乐观锁在并发量不高（每秒几十次写入）的场景下完全够用。如果并发更高，建议换成 Redis 的 Lua 脚本或者直接用数据库的行锁。
4.5 超时、重试与降级策略
多 Agent 系统里，任何一个 Agent 失败都不应该拖垮整个流程。我的策略是分级降级：单个 Agent 超时（默认 5 秒），重试一次；重试仍失败，返回status="failed"并附带错误信息；主管 Agent 收到 failed 后，判断是否可以跳过该步骤继续，或者降级返回部分结果。
import asyncio from tenacity import retry, stop_after_attempt, wait_fixed @retry(stop=stop_after_attempt(2), wait=wait_fixed(1)) async def call_agent_with_retry(agent_name: str, input_data: dict) -> AgentResult: try: result = await asyncio.wait_for( call_agent_async(agent_name, input_data), timeout=5.0 ) return result except asyncio.TimeoutError: return AgentResult( agent_name=agent_name, status="failed", output={}, confidence=0.0, error_message="timeout" )这里有个细节：重试时不要原样重发，最好在 input 里加一个retry_count字段，让 Agent 知道这是重试，可以调整策略。比如第一次用精确匹配查数据库没查到，重试时改用模糊匹配。
5. 常见问题与排查技巧实录
5.1 Agent 之间互相等待导致死锁
这是层级编排里最常见的问题。主管 Agent 派任务给工人 A，工人 A 的输出需要工人 B 的输入，但主管忘了先调 B，导致 A 一直等。更隐蔽的是，A 和 B 互相等对方的输出，形成循环依赖。
排查方法：在编排层加一个依赖图检查，每次派任务前检查是否存在循环依赖。我的做法是维护一个pending_tasks集合，如果某个 Agent 的输入依赖的变量还没被写入工作记忆，就把它标记为blocked，先执行其他可执行的 Agent。如果所有 Agent 都 blocked，直接报错并输出依赖图。
注意：不要依赖模型自己发现死锁，模型没有全局状态视图，它只会按照 prompt 里的信息做局部决策。死锁检测必须放在编排层的代码里。
5.2 工具调用参数格式错误
模型生成的工具调用参数经常出现类型错误，比如该传整数的地方传了字符串，该传数组的地方传了单个对象。这类错误在单 Agent 场景下可能被模型自己纠正，但在多 Agent 场景下，错误会沿着调用链传播，最终导致整个任务失败。
我的解决方案是在工具层加一层参数校验和自动修复。用 Pydantic 定义每个工具的参数模型，调用前先校验，校验失败时尝试自动转换（比如"123"转123），转换失败则返回明确的错误信息给 Agent，让它重新生成。
from pydantic import BaseModel, ValidationError class QueryOrderInput(BaseModel): order_id: int fields: list[str] = ["status", "logistics"] def safe_tool_call(tool_name: str, raw_params: dict): try: params = QueryOrderInput(**raw_params) except ValidationError as e: # 尝试自动修复常见错误 if "order_id" in raw_params and isinstance(raw_params["order_id"], str): raw_params["order_id"] = int(raw_params["order_id"]) try: params = QueryOrderInput(**raw_params) except ValidationError: return {"error": f"参数格式错误：{e.errors()}"} return execute_tool(tool_name, params.dict())5.3 上下文膨胀导致推理变慢
多 Agent 系统跑久了，工作记忆里的数据越积越多，每次拼进 prompt 的上下文越来越长，推理延迟从 1 秒涨到 5 秒。我遇到过最夸张的情况，一个任务跑了 20 步，prompt 里塞了 15000 token 的历史记录，模型直接超时。
解决办法是定期压缩工作记忆。每完成一个阶段，就把该阶段的详细记录压缩成一段摘要，只保留关键结论。比如“查数据”阶段的 10 条中间记录，压缩成“已获取 2024 年 1-6 月销售数据，总额 1200 万，环比下降 15%”。压缩用一个小模型（比如 gpt-4o-mini）来做，成本低速度快。
另一个技巧是按需加载。工作记忆里存全量数据，但拼 prompt 时只取当前 Agent 需要的字段。比如报告生成 Agent 只需要趋势分析结果，不需要原始销售数据，那就只把趋势结果拼进去。
5.4 模型选择与成本控制
多 Agent 系统里，不是所有 Agent 都需要用最贵的模型。我的分配策略是：主管 Agent 和需要复杂推理的 Agent 用强模型（如 GPT-4o），执行固定格式转换或简单判断的 Agent 用轻量模型（如 GPT-4o-mini）。实测下来，一个五 Agent 的系统，如果三个用轻量模型，整体成本能降 60%，而任务成功率只下降 3 个百分点。
还有一个省钱技巧：缓存重复的工具调用结果。同一个订单号在同一个任务里被查了三次，后两次直接读缓存。用 Redis 做工具结果缓存，TTL 设 5 分钟，能省下不少 token。
| 问题类型 | 典型表现 | 排查方向 | 解决手段 |
|---|---|---|---|
| 死锁 | 任务卡住不推进 | 检查依赖图 | 编排层加循环检测 |
| 参数错误 | 工具调用失败 | 查看原始参数 | Pydantic 校验+自动修复 |
| 上下文膨胀 | 推理延迟飙升 | 统计 prompt token 数 | 定期压缩+按需加载 |
| 成本过高 | 账单超预期 | 按 Agent 统计 token | 分级用模型+结果缓存 |
| 结果冲突 | 多 Agent 输出矛盾 | 检查置信度权重 | 加权投票+人工兜底 |
5.5 安全边界：别让 Agent 拿到不该拿的权限
多 Agent 架构下，权限隔离是安全底线。我的原则是：每个 Agent 的工具列表在代码里硬编码，不通过 prompt 动态分配。模型可以决定“调不调”，但不能决定“能不能调”。比如删除数据的工具，只有经过审批 Agent 确认后，才由编排层动态注入到执行 Agent 的工具列表里，执行完立刻移除。
另外，所有 Agent 的输出在传给下一个 Agent 之前，都要经过一次敏感信息过滤。我见过一个案例：查数据库的 Agent 把用户手机号完整地传给了报告生成 Agent，报告里直接打印了手机号。后来在通信层加了一个正则过滤器，自动脱敏手机号、身份证号、邮箱等字段。
提示：不要信任任何 Agent 的输出。即使是最简单的格式转换 Agent，也可能因为 prompt 注入而输出意外内容。每个 Agent 的输出都应该被视为“不可信输入”，经过校验后再使用。
6. 多 Agent 协作的进阶方向
6.1 动态 Agent 生成：按需创建专家
固定 Agent 列表的局限性在于，你没法预判所有可能的任务类型。动态 Agent 生成的思路是：主管 Agent 发现现有 Agent 都不适合当前子任务时，自动生成一个新的 Agent 描述（包括角色、工具、输出格式），然后由编排层实例化并调用。这听起来很科幻，但实际落地时，我建议只生成 prompt 和工具列表，代码逻辑复用同一个执行器。
我试过一个简化版：主管 Agent 输出一个 JSON，包含role_description、allowed_tools、output_schema，编排层用这个 JSON 动态构造一个 Agent 实例。实测下来，在数据分析场景里，动态生成的 Agent 有 70% 的概率比固定 Agent 表现更好，因为它的 prompt 更贴合具体任务。但另外 30% 的情况会生成过于宽泛或自相矛盾的角色描述，需要加一个校验层。
6.2 Agent 评测：怎么知道系统好不好
多 Agent 系统的评测比单 Agent 复杂得多，因为失败可能发生在任何一个环节。我的评测框架分三层：端到端成功率（最终输出是否正确）、单 Agent 准确率（每个 Agent 的输出是否符合预期）、编排效率（步数、延迟、token 消耗）。端到端成功率是最终指标，但单 Agent 准确率能帮你定位瓶颈。
评测数据集我一般构造 50-100 个典型任务，每个任务标注期望的最终输出和关键中间结果。跑评测时，记录每个 Agent 的输入输出，人工抽查失败案例。我踩过的坑是：只测成功路径，不测异常路径。后来强制要求评测集里至少 30% 是异常场景（工具超时、参数错误、结果冲突），才发现降级逻辑里有一堆 bug。
6.3 从原型到生产：还需要补什么
原型跑通只是第一步，上生产还需要补三样东西。第一是可观测性：每个 Agent 的调用链路、耗时、token 消耗、输入输出都要打日志，最好接入分布式追踪（比如 OpenTelemetry）。第二是灰度发布：新版本的 Agent prompt 先跑 10% 流量，对比成功率和延迟，没问题再全量。第三是人工兜底：当系统返回need_human时，要有界面让运营人员看到完整上下文并手动处理，处理结果反哺到评测集里。
我个人的体会是，多 Agent 系统的复杂度不是线性增长的，而是指数级的。每加一个 Agent，通信路径就多一倍，故障模式也多一倍。所以我的建议是：从两个 Agent 开始，跑稳了再加第三个，永远不要一次性设计一个十 Agent 的系统。先把串行流水线跑通，再尝试并行扇出，最后才上层级编排。每一步都做好评测和监控，比追求架构先进重要得多。
最后分享一个小技巧：在主管 Agent 的 prompt 里加一句“如果你不确定下一步该调用哪个 Agent，输出need_human而不是猜测”。这句话能挡掉大量因为模型“硬猜”导致的错误传播。我实测下来，加上这句话后，需要人工介入的比例从 5% 升到 12%，但端到端成功率从 78% 升到 91%。多出来的 7% 人工成本，换来 13 个百分点的准确率提升，这笔账怎么算都划算。
