在多智能体协作系统中，Coordinator 是离用户最近、却最容易被低估的角色。它不执行任何具体任务，但整个系统的用户体验上限，取决于它。
一、你需要一个 Coordinator
当你的 AI 系统从”一个模型打天下”演进到 Multi-Agent 架构时，一个新角色自然浮现——Coordinator。
想象一个大型医院的导诊台。患者走进来说”我头疼”，导诊护士不会自己做诊断，她的工作是：理解患者的诉求，判断应该挂哪个科室，然后把患者引导过去。如果她判断错了——把偏头痛送去了骨科——患者的就医体验直接崩盘，哪怕骨科的医生再厉害也没用。
Coordinator 就是 Multi-Agent 系统里的那个导诊台。
它的职责很简单：理解用户在说什么，找到最合适的 Agent 去处理。它不写文章、不分析数据、不生成报告。但如果它理解错了、派发错了，整个系统的能力就等于零。
这引出了 Coordinator 设计中最核心的一条原则：
路由准确率，是 Coordinator 唯一的 KPI。
二、我们的 Coordinator 架构
在我们的实践中，Coordinator 与各个专业 Agent 之间通过 A2A（Agent-to-Agent）协议进行通信，以 Team 的形式组织协作。每个专业 Agent 独立部署、独立演进，可能由不同的团队甚至不同的组织开发。Coordinator 通过标准化的能力描述（Agent Card）来认识它们，通过统一的通信协议来调用它们。
这意味着 Coordinator 面对的是一个开放、异构、不完全可控的 Agent 生态。这是它与传统的”函数调用路由”最本质的区别。
为了在这样的生态中做出准确的路由决策，Coordinator 需要依赖的远不只是对当前这句话的理解。它需要感知用户所处的工作场景——用户是在热点工作台上，还是在内容分析页面？它需要追踪对话状态——上一轮任务派发给了哪个 Agent、那个 Agent 的回答中是否包含了对用户的追问？它需要记录路由历史——同一个话题是否已经连续两次被用户否定、已经尝试过哪些 Agent？
这些场景感知能力、状态追踪机制和路由记忆，共同构成了 Coordinator 的决策基础：
1 | ┌─────────────────────────────────────────────────┐ |
每一层都在为路由准确率服务。缺少任何一层，Coordinator 的决策质量都会显著下降。
三、第一道难关：对话不只有一轮
如果每次对话都是独立的一句话，Coordinator 的工作就很简单——分析意图、匹配 Agent、派发任务。但现实中，用户的对话是连续的、有上下文的，充满了指代、省略和隐含信息。
3.1 多轮对话中的身份危机
用户说了一个字——“是”。
这个”是”可能是：
- 对上一轮 Agent 提问”是否需要详细分析？”的确认
- 对某个选项列表的选择
- 一个莫名其妙的首条消息
Coordinator 必须在瞬间判断：这句话是给谁的？是延续上一轮对话，还是开启新话题？
在单 Agent 系统中这不是问题——所有消息都给同一个 Agent 处理。但在 Multi-Agent 架构中，每一轮对话都是一次路由决策。判断错了，用户的确认被送给了一个完全不相关的 Agent，体验直接崩坏。
3.2 我们的解法：输入分类优先级树
经过大量真实对话的分析，我们设计了一个分层的输入分类框架。用户的每一次输入，Coordinator 会按优先级从高到低依次判断：
第一优先级：纠错信号检测
用户是否在表达”上一轮回答不对”？这个判断的优先级最高——因为它直接影响后续是”继续交给同一个 Agent”还是”需要换人”。一旦检测到纠错意图，必须立即进入纠错流程，而不是简单地延续上一轮对话。
第二优先级：简短回复识别
用户输入是否是一个简短的确认、否定或选择（”好的”、”1和3”、”取消”）？这类输入几乎必然是对上一轮对话的回应，Coordinator 应该保持对话的连贯性。
第三优先级：延续与新话题判断
当以上两层都未命中时，再通过话题关联性、指代信号、动作延续性等维度来判断是延续还是新话题。
为什么要分层？因为模糊情况下的默认行为不同。简短回复的默认行为是”继续给上一个 Agent”，而纠错信号的默认行为恰恰相反——“不要继续给上一个 Agent”。如果不分层，这两种相反的策略会在边界 case 中打架。
3.3 指代消解：Coordinator 该做到哪一步
用户说”帮我看看它的评论情况”——“它”是什么？只有 Coordinator 知道，因为只有它持有完整的对话历史。
但问题是，如果 Coordinator 做了太多的理解和改写工作，它就不再”薄”了。它可能改错、改多、改变了用户的原始意图。
我们的原则是：Coordinator 只做常识性的补全，领域判断留给专业 Agent。
具体来说，Coordinator 负责：
- 把代词替换成实体——“它”→”《春节运营复盘》”
- 补全省略的主语——“再分析一下”→”再分析一下昨天的爆款数据”
- 继承显式约束——上文确定的时间范围、筛选条件
Coordinator 不负责：
- 判断用户说的”效果不好”具体指哪个指标
- 推断用户想要什么粒度的分析
这条线划得很清楚：人人都能做的常识性补全 → Coordinator；需要领域知识的解读 → 专业 Agent。
以上这些，都建立在一个前提上：Coordinator 知道该把任务给谁。如果系统里只有寥寥几个 Agent、各司其职、边界清晰，路由决策并不难。但当 Agent 生态逐渐丰富，能力开始出现重叠，Coordinator 会遭遇第二道难关。
四、第二道难关：相似的 Agent，不同的场景
当你的 Agent 生态足够丰富时，一定会遇到这个问题：两个 Agent 看起来能做同一件事，但适用场景不同。
4.1 真实案例
在我们的系统中，有两个 Agent 都能对热点事件进行”拆解”：
- Agent A：对指定热点事件做深度角度拆解，产出多个写作切入点
- Agent B：对热点事件做潜力评估，分析事件热度趋势和跟进价值
用户说”帮我拆解一下这个热点”，该给谁？
4.2 错误做法：硬编码默认值
最容易想到的方案：
1 | if 确定在场景 X: |
这个方案的问题在于：“没有明确在场景 X”不等于”用户想要 Agent B 的服务”。默认值是对用户意图的粗暴假设。
4.3 我们的做法：多层消歧 + 场景感知
我们的 Agent 系统具备用户场景感知能力——在用户发起请求时，系统会感知用户当前所处的工作场景（例如在哪个工作台、浏览什么页面），并将这个场景信息作为上下文提供给 Coordinator。
有了场景感知后，消歧规则变成了一个多层判断：
第一层：确定性信号。 场景感知提供了明确的环境标识——用户就在某个特定工作台上，这是最强的路由信号，可以直接决策。
第二层：表述特征。 当没有环境信号时，从用户的表述中提取意图特征。比如”有什么值得跟的热点”是探索性表述，倾向于潜力评估；”帮我把这个事件拆出几个写作角度”是明确的角度拆解需求。
第三层：承认不知道。 当前两层都无法给出确定性判断时，Coordinator 不应该猜测——而是向用户追问。
这个设计背后有一个重要的认知：场景感知不是一个”可选的优化”，而是 Multi-Agent 路由系统的核心基础设施。当你的 Agent 生态越丰富，能力重叠越多，纯靠 NLU（自然语言理解）做路由的天花板就越低。场景信号是另一个维度的信息，它和语言理解互补，共同提升路由准确率。
4.4 通用的消歧设计模式
从这个案例中我们抽象出了一个通用的消歧处理模式：
- 识别冲突组：哪些 Agent 的能力存在重叠？
- 定义区分特征：这些 Agent 在什么维度上不同？（场景、用户表述、操作对象……）
- 建立有序规则：按信号强度从高到低排列判断条件
- 设定兜底行为：所有规则都无法命中时，追问而非猜测
每一对可能混淆的 Agent 都应该有自己的消歧规则。这些规则不应该散落在 Coordinator 的各处，而应该作为结构化的路由配置来维护——当 Agent 增减时，只需要更新配置，不需要重写 Coordinator 的核心逻辑。
五、第三道难关：派错了怎么办
在理想世界里，Coordinator 每次都能把任务派给对的 Agent，Agent 每次都能给出正确的回答。但现实是，错误不可避免。
更棘手的是，在我们的架构中，Coordinator 在 Agent 返回结果后没有”审阅”的机会。
5.1 为什么选择”透传”
我们的系统选择了将专业 Agent 的输出直接呈现给用户，而不是经过 Coordinator 的二次加工。这个决策基于两个考量：
保真度。 专业 Agent 精心组织的回答——表格、数据、格式化建议——如果经过 Coordinator 的”总结”和”转述”，信息必然会丢失或变形。Coordinator 的语言能力不一定比专业 Agent 强，但它”翻译”一遍一定会引入噪声。
响应速度。 每多一次 LLM 推理就意味着额外的延迟和成本。在用户体感上，等待时间从 3 秒变成 6 秒，满意度会显著下降。
但透传的代价是：Coordinator 失去了”兜底”的机会。Agent 答错了、答偏了、甚至说了”我处理不了”——这些内容会原封不动地到达用户面前。
5.2 如果不透传：Coordinator 后处理模式
另一种架构选择是让 Coordinator 在 Agent 返回后保留一次”审阅”的机会。在这种模式下，Agent 的输出先回到 Coordinator，Coordinator 可以：
- 结果审阅：快速判断 Agent 的回答是否与用户问题对得上——是不是答非所问、是否包含明显的拒绝或错误信号
- 失败拦截：如果发现 Agent 返回了”抱歉我无法处理”或者回答明显偏离用户需求，Coordinator 可以拦截这个结果，悄悄重新路由到另一个 Agent，用户感知上只是”等了久一点”而不是”被告知处理不了”
- 补充引导：在 Agent 回答的末尾追加一些引导语，帮助用户进行后续探索
这种模式的纠错能力显著更强——Coordinator 可以在用户无感知的情况下完成一次自动重试。但它的代价也很明确：每次都多一轮 LLM 推理，增加延迟和成本；Coordinator 的”总结”可能扭曲 Agent 的原始输出；而且审阅本身也可能误判——把正确的回答当成了错误的。
两种模式没有绝对的优劣，取决于你的系统更在意什么。 如果 Agent 的输出质量已经比较稳定、路由准确率较高，透传模式的高效和保真优势更大；如果 Agent 生态还在早期、质量参差不齐，后处理模式的纠错能力可能更重要。也可以折中——对高置信度路由走透传，对低置信度路由保留后处理。
我们选择了透传，因此需要在其他环节补上失去的纠错能力。
5.3 透传模式下的失败检测：用户的下一句话
既然 Coordinator 无法在 Agent 返回后审阅，那么失败检测只能发生在用户的下一轮输入。
这要求 Coordinator 对用户的”纠错信号”高度敏感。我们把纠错信号分为三类：
- 显式否定：”不对”、”错了”、”不是我想要的”——用户直接告诉你上一轮有问题
- 隐式纠正：”我的意思是…”、”不是 XX，是 YY”——用户通过重新描述来纠正方向
- 情绪反馈：”这不靠谱”、”没用”——用户对质量表达不满
检测到纠错信号后，Coordinator 需要进一步判断：是”派错了人”，还是”找对了人但理解偏了”？
这两种失败的补救策略完全不同：
- 派错了人 → 重新路由到正确的 Agent，并在任务信息中附加纠错上下文
- 理解偏了 → 仍然交给同一个 Agent，但用纠正后的需求描述替换原始 query
5.4 防死循环机制
纠错重试必须有边界。如果同一个话题连续两轮被用户否定，Coordinator 不应该继续自动路由——这时候大概率是 Coordinator 对用户意图的理解存在根本性偏差。正确的做法是停下来，明确追问用户想要什么，给出具体的选项供选择。
同时，Coordinator 需要记录已经尝试过的 Agent，避免在同一个话题中反复派给同一个失败的 Agent——这是死循环的常见来源。
5.5 更根本的解法：减少出错
事后纠错终归是代价高昂的——它需要用户多说一轮话，需要 Coordinator 重新推理，需要另一个 Agent 重新处理。
与其把精力放在”错了怎么补”，不如把更多精力放在”怎么不出错”：
- 提高首次路由准确率：每一对容易混淆的 Agent 都建立消歧规则
- 前置信息完整性检查：在派发之前确认信息是否充分，不够就先问
- 保证 Query 质量：传递给 Agent 的请求要完整、无歧义、自洽
- 宁可多问一句，不要派错一次
六、Coordinator 的设计原则
基于以上实践，我们沉淀了几条 Coordinator 的设计原则：
原则一：Coordinator 要足够”薄”
Coordinator 只做两件事——理解和路由。所有超出这两件事的工作，都应该下放给专业 Agent。
一个常见的陷阱是往 Coordinator 里堆越来越多的逻辑：实体抽取、信息补全、格式化输出、质量校验……每加一项能力，Coordinator 的复杂度就上升一个台阶，它在每一项上的表现就被稀释一分。
专注产生准确，臃肿制造混乱。 还记得 Coordinator 唯一的 KPI 吗？路由准确率。一个臃肿的 Coordinator，能力越多，路由越不准——这不是悖论，这是分心的必然代价。
原则二：质量把控前置
如果你的架构允许 Coordinator 在 Agent 返回后做审阅和补救，那是最好的。但如果像我们一样选择了透传模式，那么所有的质量把控都必须在派发之前完成。
这意味着：
- 信息够不够？不够就追问，不要让 Agent 去猜
- Query 清不清楚？有歧义就改写，不要把模糊的需求扔给 Agent
- 路由有没有把握？没把握就确认，不要赌
一次高质量的派发，胜过三次补救。
原则三：为失败设计
不要问”怎么保证不出错”——这在 LLM 系统中是不可能的。要问”出错后怎么最快恢复”。
这要求 Coordinator 在每一轮对话中都保持一种”可能上一轮是错的”的警觉。纠错信号的优先级要高于延续对话的判断——因为如果用户在说”不对”，而你还在继续往下走，那就是错上加错。
原则四：Agent 的能力描述决定路由的上限
Coordinator 做路由决策时，依赖的核心信息是每个 Agent 的能力描述。如果能力描述写得模糊、有重叠、边界不清，再聪明的 Coordinator 也做不出正确判断。
好的 Agent 能力描述应该包含：
- 能做什么：核心能力和擅长场景
- 不能做什么：明确的边界和限制
- 容易混淆的场景：与其他 Agent 的能力重叠区域和区分方法
投入在 Agent 能力描述上的精力，回报率远高于调优 Coordinator 的 Prompt。
原则五：决策逻辑与 Agent 知识分离
Coordinator 的核心 Prompt 应该定义”如何做决策”——输入分类框架、路由优先级、纠错流程——这些是稳定的方法论，不随 Agent 的增减而变化。
而”认识哪些 Agent”、”它们的能力是什么”、”谁和谁容易混淆”——这些是动态的数据，应该随 Agent 列表一起注入上下文，而不是硬编码在 Prompt 中。
这种分离确保了：加入新 Agent 时，只需要补充能力描述和消歧规则，而不需要重写 Coordinator 的决策逻辑。
七、几点反思
做了这么久 Coordinator，有几个认知值得分享：
第一，Coordinator 是整个 Multi-Agent 系统中最需要”产品思维”的组件。
它不是一个纯技术问题。理解用户在说什么、判断用户想要什么、决定在什么时候追问而不是猜测——这些本质上是产品设计决策。好的 Coordinator 设计者，需要同时具备 NLP 的技术功底和产品经理的用户同理心。
第二，完美的路由不存在，但 80 分的路由加上好的纠错机制可以接近 95 分的体验。
不要追求一次做对。要追求的是：做对的时候足够快，做错的时候用户能用最少的成本纠正你。
第三，Coordinator 的 Prompt 不是越详细越好。
我们经历过从 200 行到 500 行再精简回 250 行的过程。更长的 Prompt 不会带来更好的决策——反而会稀释 LLM 的注意力，让它在边界 case 上表现更差。每一条规则只应该出现一次，用引用而非重述。
第四，Multi-Agent 系统的用户体验瓶颈，几乎总是在 Coordinator。
用户不会说”这个 Agent 不行”——他们会说”这个 AI 助手不行”。因为在用户眼里，他们只和一个角色对话。Coordinator 的任何失误——理解错了、派发错了、没有追问该追问的问题——都会直接伤害用户对整个系统的信任。
善待你的 Coordinator。它是用户和你精心构建的 Agent 生态之间，唯一的桥梁。
回到最初那句话：路由准确率，是 Coordinator 唯一的 KPI。 所有的架构设计、所有的原则取舍，最终都在回答同一个问题——用户的这句话，有没有送到对的地方。
