多Agent意图路由中枢——把"盲选Agent"变成"系统精准调度"

场景演示

你对着 AI 助手发出一条请求：

"帮我查一下这个供应商的资质，顺带催一下他们欠我们的货款，再把这个结果更新到飞书表格里。"

这句话听起来是一件事，但拆开来看：资质查询 + 催款沟通 + 飞书更新，分别对应三个不同的处理流程。

传统做法是：你心里先想好要拆成几个步骤，再分别调用不同的工具或 Agent——本质上还是人在做"任务拆解 + 路由分配"。

多Agent意图路由中枢做的，就是把这层苦力活交给系统：用户说一句，系统自动理解意图、自动拆解、自动路由到对应 Agent、自动汇总结果。

Step by Step

第一步：部署路由判官（Intent Classifier Agent）

这个 Agent 专职做一件事——读用户的输入，输出结构化的路由指令。

它不需要执行任务，只需要判断：

用户输入 → 应该路由给哪些子Agent（0个或多个） → 优先级是什么

核心 Prompt 示例：

你是一个意图分类器。用户会输入一段自然语言请求。
你的任务是分析这段话中包含多少个独立的处理意图，并为每个意图标注：
1. intent_type: 具体意图类型（见下方分类表）
2. target_agent: 最合适的执行Agent
3. urgency: 紧急程度（high / medium / low）
4. requires_context: 执行前是否需要补充上下文（yes/no）

【意图分类表】
- intent_type: supplier_check → target_agent: supplier_review_agent
- intent_type: payment_reminder → target_agent: communication_agent  
- intent_type: spreadsheet_update → target_agent: bitable_agent
- intent_type: stock_analysis → target_agent: stock_agent
- intent_type: music_creation → target_agent: banana_berry_studio
- intent_type: meeting_minutes → target_agent: meeting_agent
- intent_type: code_review → target_agent: dev_agent
- intent_type: report_generation → target_agent: report_agent
...（按实际需求扩展）

输出格式：JSON数组，每个元素对应一个独立意图。
如果用户输入不含任何可识别意图，输出空数组。
不要臆测，只输出你确定的部分。

示例输入："帮我查一下这个供应商的资质，顺带催一下他们欠我们的货款"
示例输出：[{"intent_type":"supplier_check","target_agent":"supplier_review_agent","urgency":"medium","requires_context":"yes"},{"intent_type":"payment_reminder","target_agent":"communication_agent","urgency":"high","requires_context":"yes"}]

第二步：注册子Agent能力清单

每个子Agent在启动前，向中枢注册自己的能力域和输入输出格式：

Agent注册表（存于飞书Bitable或多Agent共享记忆）：
| Agent ID | 能力域 | 接受参数 | 输出格式 | 依赖其他Agent |
| supplier_review_agent | 供应商资质核查 | supplier_name, supplier_code | 结构化报告 | bitable_agent |
| communication_agent | 对外沟通（邮件/消息） | recipient, message_type, content | 发送状态 | - |
| bitable_agent | 飞书多维表格读写 | app_token, table_id, fields | 操作结果 | - |
| stock_agent | A股行情分析 | stock_code, analysis_type | 分析报告 | - |
| ... | ... | ... | ... | ... |

第三步：中枢调度执行

路由判官输出路由指令后，调度Agent（Orchestrator）按依赖顺序触发子Agent：

调度规则：
1. 无依赖的Agent → 并行触发
2. 有依赖的Agent → 等前置完成后才触发
3. 某个Agent失败 → 根据容错策略：重试 / 跳过 / 中断
4. 所有Agent完成 → 汇总结果，生成最终回复

调度流程示意：

用户输入
    ↓
意图分类（路由判官Agent）
    ↓ JSON路由指令
调度Agent读取Agent注册表
    ↓
并行触发：无依赖的Agent同时执行
    ↓
依赖链按序执行（如 communication_agent 依赖 bitable_agent 的数据）
    ↓
结果汇总 → 最终输出 → 用户

第四步：结果汇聚与兜底

每个子Agent执行完毕后，将结果写入共享上下文（可用飞书Bitable或内存）。调度Agent负责：

• 合并多个Agent的输出
• 过滤冗余信息
• 生成面向用户的最终回复
• 将关键数据写回指定系统（如飞书表格）

可复制提示词

路由判官Agent启动提示词

你是一个专业的AI意图分类中枢。
用户会输入一段自然语言请求。
请严格按照以下JSON格式输出分类结果，不要添加任何解释说明。

【意图分类表】
- supplier_check → supplier_review_agent（供应商资质核查）
- payment_reminder → communication_agent（催款沟通）
- spreadsheet_update → bitable_agent（飞书表格更新）
- stock_analysis → stock_agent（股票行情分析）
- music_creation → banana_berry_studio（音乐创作）
- meeting_minutes → meeting_agent（会议纪要处理）
- code_review → dev_agent（代码审查）
- report_generation → report_agent（报告生成）
- knowledge_qa → knowledge_agent（知识问答）
- multi_agent_collaboration → orchestrator_agent（需要多Agent协作的复杂任务）

【输出格式】

[

{

"intent_type": "对应分类名",

"target_agent": "AgentID",

"urgency": "high/medium/low",

"requires_context": "yes/no",

"missing_info": ["缺少的上下文字段列表"]

}

]

如果输入不含任何可识别意图，输出：{"intents": []}

子Agent标准接口提示词

你是一个专门负责【具体能力域】的Agent。
你只处理 intent_type 为【对应类型】的请求。
接收参数：{由路由判官传入的JSON参数}
执行步骤：
1. 校验参数完整性，若缺少必要字段立即报错
2. 执行对应操作
3. 将结果写入共享上下文，格式如下：
{"agent_id":"xxx","status":"success/failed","result":{...},"error":"错误信息（如有）"}
不要主动调用其他Agent，不要做路由决策。

使用的Skills

价值与注意事项

核心价值

1. 降低使用门槛：用户不需要知道系统里有哪些Agent，只需要说人话
2. 减少路由错误：路由决策集中由"判官Agent"统一处理，不依赖用户的Agent知识
3. 并行效率最大化：无依赖的任务自动并行，有依赖的自动排队
4. 可观测性强：每次路由决策都有记录（存Bitable），方便审计和优化
5. 扩展性强：新增Agent只需注册到表里，路由判官无需修改

注意事项

1. 路由准确率是瓶颈：路由判官的Prompt需要持续优化，建议每月Review一次路由日志的错误率
2. 防止过度路由：一句话里隐含多个意图时，判官容易"过度拆解"，导致路由泛化
3. 共享上下文隔离：多Agent并发写入同一Bitable时，建议加行级锁或时间戳校验
4. 容错兜底：某个子Agent超时不返回时，调度Agent需要有超时中断和降级回复策略
5. 不要用路由中枢做简单任务：路由判官本身也有调用成本，"今天天气怎么样"这类意图就不需要过路由中枢，直接匹配关键词更快

效果对比

总结：多Agent意图路由中枢，是把"人做路由"变成"AI做路由"的关键组件。路由判官是核心，它决定了整个系统的智能程度上限。下次你听到"这个AI系统很聪明"，最底层，很可能就是一个意图路由中枢在默默工作。