跳到主要内容

第 2.9.3 节：用共享状态和 Supervisor 路由控制协作过程

共享状态和 Supervisor 路由只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够按顺序说明共享状态和 Supervisor 路由的触发、处理、复核、记录和兜底步骤。

实现步骤或决策流程​

什么时候需要多智能体，什么时候一个工作流够用​

多智能体有成本，也有调试复杂度。不要把它当成默认方案。

场景推荐方案原因
用户问“退货周期是多久”单 Agent（智能体） + RAG（检索增强生成）只需要检索政策并回答。
用户查一个订单物流单 Agent 工作流 + 工具调用只涉及身份校验和订单查询。
用户申请普通工单单 Agent 状态图流程清楚，风险较低，一个工作流可控。
用户同时要求退款、投诉和催发货多智能体需要政策、订单、工单和质检协作。
高价值客户投诉，可能涉及赔付多智能体 + Supervisor（监督者） + 人工升级风险高，需要复核和审批。
知识库答案和订单状态互相冲突多智能体 + 仲裁需要证据汇总和冲突处理。
早期 Demo（演示）只展示问答不建议多智能体调试和日志成本不值得。

判断标准可以简化成 4 个问题：

  • 是否存在明显不同的专业角色？
  • 是否需要不同工具权限？
  • 是否需要复核、仲裁或人工升级？
  • 是否能承受额外延迟、成本和日志复杂度？

如果 4 个问题多数回答“否”，一个状态图工作流通常就够了。多智能体不是成熟度的标志，能用更简单方案稳定交付才是工程判断。

推荐技术流​

设计客服多智能体系统，推荐按下面顺序做。

步骤做什么为什么
1选定一条复杂业务主线先做“延迟发货 + 退款 + 投诉”，不要一开始覆盖所有客服问题。
2判断是否真的需要多智能体避免把简单流程过度设计。
3定义角色职责明确接待、知识库、订单、工单、质检和 Supervisor（监督者）分别做什么。
4定义每个角色的权限防止所有 Agent 都能访问所有工具。
5定义共享状态字段让角色之间通过结构化状态协作。
6定义 Handoff（任务转交）字段契约每次交接都能被目标角色理解和日志复盘。
7定义 Supervisor（监督者）路由规则让下一步由规则和状态驱动，而不是自由聊天。
8定义仲裁和停止规则解决冲突、循环、返工和结束条件。
9定义人工升级路径高风险、低置信度、权限冲突和循环超限时转人工。
10设计日志和 trace_id（追踪编号）让每个 Agent 的输入、输出和交接可追踪。
11用路径样例验收覆盖成功、冲突、失败、越权、循环和人工介入。

这条技术流的核心理由是：多智能体必须先有“组织结构”，再有“模型调用”。如果先写一堆 Agent，后面再补状态和权限，系统会很快失控。

角色设计​

起步版本的客服多智能体系统建议只设计 6 个角色，不要一开始拆得太碎。

角色主要职责可用能力不应该做什么
接待 Agent理解用户问题、识别意图、发现缺失信息、安抚情绪会话摘要、意图识别、追问字段不直接查订单，不承诺退款，不创建工单。
知识库 Agent检索政策、商品说明、客服规范和处理依据RAG、资料引用、依据摘要不访问用户私有订单，不替业务系统判断订单状态。
订单 Agent查询订单、物流、支付、售后状态和历史工单只读订单工具、订单归属校验不修改订单，不创建赔付，不写工单正文。
工单 Agent准备工单草稿、创建或更新工单工单工具、用户确认、幂等校验不绕过确认，不处理资金，不修改政策。
质检 Agent检查事实依据、回复风险、权限边界和过度承诺答复审查、风险标注、返工建议不替 Supervisor（监督者）做最终路由。
Supervisor（监督者）分派任务、汇总结果、仲裁冲突、停止或升级人工共享状态、角色路由、决策日志不亲自包办所有工具调用，不变成万能客服。

角色设计要遵守两个原则。

第一，角色职责要能一句话说清。如果一个角色需要三四句话才能解释，它可能拆得不对。

第二，角色权限要比职责更窄。能理解用户诉求，不代表能查订单；能写工单草稿，不代表能直接提交高风险工单；能质检回答，不代表能修改订单状态。

字段契约​

多智能体系统最重要的字段契约是 Handoff（任务转交）契约和 Supervisor（监督者）决策契约。字段契约不是代码语法，而是让所有角色、前端、后端、日志和测试都对齐的业务协议。

Handoff（任务转交）字段契约​

字段中文含义来源谁可以写用途
task_id任务编号系统生成Supervisor（监督者）或任务系统标识一次客服任务，支持恢复和幂等。
session_id（会话编号）会话编号会话系统会话系统串联多轮用户对话。
current_agent当前智能体执行上下文Supervisor（监督者）或当前 Agent说明交接从谁发起。
target_agent目标智能体路由规则Supervisor（监督者）说明下一步交给谁。
handoff_reason交接原因当前 Agent 输出和路由规则当前 Agent 提出，Supervisor（监督者）确认解释为什么需要交接。
handoff_payload交接载荷当前状态和角色输出当前 Agent 在权限内写入给目标 Agent 的必要上下文摘要。
supervisor_decision监督者决策Supervisor（监督者）Supervisor（监督者）记录路由、返工、停止或升级人工的决定。
state状态共享状态模块按字段权限写入保存当前任务事实、阶段和已知结果。
confidence置信度Agent 输出或规则评估当前 Agent 建议，Supervisor（监督者）采纳或修正判断是否需要复核、返工或人工。
risk_level风险等级意图识别、工具结果、质检结果Supervisor（监督者）或风控规则控制工具权限、交接和人工升级。
permissions权限范围权限模块权限模块限制目标 Agent 可访问资料和工具。
stop_reason停止原因Supervisor（监督者）Supervisor（监督者）说明任务为什么结束、暂停或转人工。
escalation_required是否升级人工风控规则、质检结果、Supervisor（监督者）Supervisor（监督者）标记是否需要人工客服或审核人介入。
trace_id（追踪编号）追踪编号系统生成追踪系统串联本次任务中的消息、交接、工具、决策和最终回复。

Handoff（任务转交）载荷应该包含什么​

handoff_payload（交接载荷）不要塞完整聊天记录，也不要只写一句“用户要退款”。它应该是目标 Agent 完成任务所需的最小上下文。

目标角色handoff_payload（交接载荷）应包含不应包含
知识库 Agent用户问题摘要、需要查询的政策类型、商品类别、地区、时间范围用户完整隐私资料、订单系统内部字段。
订单 Agent已校验用户身份、订单编号候选、查询原因、允许查询范围售后政策原文、无关聊天记录。
工单 Agent用户诉求摘要、关联订单、政策依据、订单状态、用户确认状态、风险提示未确认的退款承诺、超出权限的赔付建议。
质检 Agent候选答复、证据来源、工具结果摘要、风险等级、是否涉及承诺可执行写入工具权限。
Supervisor（监督者）角色输出摘要、置信度、风险、建议下一步、失败原因目标角色无法解释的长文本堆叠。

一个合格的 handoff_payload（交接载荷）要满足 3 个条件：

  • 目标 Agent 读完能知道自己要做什么。
  • 日志系统能复盘为什么发生这次交接。
  • 敏感数据和权限不会因为交接而扩大。

Supervisor（监督者）决策契约​

决策类型触发条件输出字段下一步
route（路由）当前任务需要某个专业角色处理target_agent（目标智能体）、handoff_reason（交接原因）发起 Handoff（任务转交）。
merge（汇总）多个角色结果已返回state（状态）、confidence（置信度）汇总证据并判断是否冲突。
arbitrate（仲裁）角色结果冲突或证据不一致supervisor_decision（监督者决策）、risk_level（风险等级）复查、质检或转人工。
retry（返工）质检不通过、字段缺失、低置信度target_agent（目标智能体）、handoff_reason（交接原因）指定角色补充处理。
stop（停止）任务已完成、用户取消、无权限、转人工stop_reason（停止原因）写入最终状态并结束。
escalate（升级人工）高风险、循环超限、权限冲突、用户强烈投诉escalation_required（是否升级人工）、risk_level（风险等级）转人工客服或审核。

Supervisor（监督者）决策不应该是一段模糊自然语言。它可以有解释文字，但必须落到可执行字段上，否则前端、日志和后续 Agent 都无法稳定处理。

Supervisor（监督者）如何路由、仲裁、停止和升级人工​

路由​

路由是 Supervisor（监督者）的第一项职责。它要根据当前状态决定目标 Agent，而不是让 Agent 互相随意召唤。

当前状态路由目标路由原因
用户问题刚进入，意图不清接待 Agent先识别意图、情绪和缺失信息。
需要政策依据知识库 Agent需要从知识库检索可引用资料。
需要订单事实订单 Agent需要读取订单、物流或支付状态。
需要写入客服流程工单 Agent需要准备草稿、用户确认和工单创建。
答复涉及退款、投诉、补偿或冲突证据质检 Agent需要复核事实和风险。
风险高、冲突无法解决、循环超限人工客服或审核人系统不应继续自动处理。

仲裁​

仲裁发生在结论冲突时。常见冲突包括：

冲突类型例子仲裁策略
政策与订单状态冲突政策说 7 天可退，订单显示已超过 7 天以订单事实和政策版本共同判断，必要时质检或人工。
角色置信度冲突知识库 Agent 高置信，订单 Agent 低置信查证低置信来源，不直接平均。
工具结果与用户描述冲突用户说没发货，订单显示已签收要求补充证据或转人工，不指责用户。
质检与工单草稿冲突草稿承诺了无法保证的赔付要求工单 Agent 返工。
权限判断冲突接待 Agent 认为可查，权限模块拒绝以权限模块为准。

仲裁不是让多个 Agent 投票。业务系统事实、权限规则、已发布政策和人工审批的优先级，通常高于模型角色的自然语言判断。

停止​

停止条件必须清楚。否则多智能体系统会不断交接、返工和自我检查。

stop_reason（停止原因）含义用户或系统动作
completed（已完成）已回答或已创建工单返回最终答复和依据。
waiting_user（等待用户）缺少订单号、确认或材料暂停并展示需要补充的内容。
waiting_human（等待人工）已升级人工客服或审核展示人工处理状态。
no_permission（无权限）当前用户不能访问对象拒绝并说明边界。
low_confidence（低置信度）证据不足，不能自动判断转人工或要求补充信息。
loop_limit（循环超限）返工或交接超过上限停止自动处理并升级人工。
tool_failure（工具失败）关键工具不可用降级、转人工或稍后重试。
user_cancelled（用户取消）用户不再处理记录状态并结束。

停止不是失败。很多客服任务正确的停止状态就是等待用户、等待人工或无权限拒绝。

升级人工​

escalation_required（是否升级人工）不是最后没办法才补的字段，而是 Supervisor（监督者）从一开始就要持续评估的风险开关。

升级条件为什么要升级
涉及退款、赔付、投诉升级或法律风险自动回答可能造成承诺或合规风险。
用户情绪强烈，连续表达投诉或威胁升级需要人工安抚和业务判断。
证据冲突，系统无法确认真实状态不能让模型硬判。
权限不清或订单归属异常可能涉及隐私和安全。
多次返工仍未通过质检自动流程已经不可靠。
关键工具持续失败系统无法获得必要事实。

人工升级要带上下文摘要和已执行路径，不能只把用户原话甩给人工客服。否则人工还要重新查一遍，协作价值会消失。

制作步骤​

第 1 步：选定一条复杂客服主线​

不要一开始做“全功能多智能体客服系统”。起步版本建议只做一条主线：

用户投诉订单延迟发货，并要求退款或人工处理。

这条主线足够复杂：它需要接待、知识库、订单、工单、质检和 Supervisor（监督者），也能覆盖风险、交接、仲裁和人工升级。

第 2 步：判断是否必须多智能体​

先把任务拆成业务阶段：

业务阶段是否需要独立 Agent判断
意图识别和情绪识别可以独立接待职责清楚，输入输出稳定。
政策检索建议独立资料来源和引用要求明确。
订单查询建议独立涉及用户私有数据和工具权限。
工单创建建议独立涉及写入、确认和幂等。
最终答复润色不一定独立可以由接待或 Supervisor（监督者）组织，但高风险要质检。
风险质检建议独立能防止过度承诺和事实错误。

如果某个角色没有独立权限、独立产出或独立验收标准，就先不要拆。

第 3 步：写角色卡​

每个角色都写一张角色卡，至少包含：

字段说明
role_name（角色名称）稳定名称，例如 order_agent（订单智能体）。
responsibility（职责）一句话说明负责什么。
allowed_inputs（允许输入）这个角色能读取哪些字段。
allowed_tools（允许工具）这个角色能调用哪些工具。
allowed_outputs（允许输出）这个角色能写哪些状态字段。
forbidden_actions（禁止动作）明确不能做什么。
handoff_out（可交接目标）它可以建议转给哪些角色。
stop_condition（停止条件）它什么时候必须停止并交回 Supervisor（监督者）。

角色卡越清楚，后续 Prompt（提示词）、权限和测试越容易写。

第 4 步：设计共享状态​

共享状态先从最小字段开始，不要把完整对话都塞进去。

字段用途
task_id（任务编号）标识任务，支持恢复和幂等。
session_id（会话编号）串联用户会话。
trace_id（追踪编号）串联日志。
user_intent（用户意图）判断当前主线。
current_agent（当前智能体）展示和调试当前处理者。
risk_level（风险等级）控制质检和人工升级。
order_summary（订单摘要）保存订单 Agent 输出。
policy_summary（政策摘要）保存知识库 Agent 输出。
ticket_draft（工单草稿）保存工单 Agent 输出。
qa_result（质检结果）保存质检 Agent 输出。
stop_reason（停止原因）表示任务结束、暂停或升级原因。

状态字段要能驱动路由。如果某个字段只为了“看起来完整”，但不会影响分支、权限、展示或日志，可以先不放。

第 5 步：设计 Handoff（任务转交）​

每次交接前，系统要检查：

  • target_agent（目标智能体）是否存在。
  • current_agent（当前智能体）是否允许交给这个目标。
  • permissions（权限范围）是否满足目标角色。
  • handoff_payload（交接载荷）是否包含目标角色必需字段。
  • risk_level（风险等级）是否要求先质检或人工。
  • trace_id（追踪编号）是否贯穿。

交接失败时不要让当前 Agent 自己找另一个目标。应该回到 Supervisor（监督者）写入 supervisor_decision（监督者决策）。

第 6 步：设计 Supervisor（监督者）规则​

Supervisor（监督者）至少要有 5 类规则：

规则例子
初始路由规则新任务先交给接待 Agent。
证据补充规则缺政策依据交给知识库 Agent，缺订单事实交给订单 Agent。
写入前确认规则工单创建前必须有用户确认和权限校验。
质检规则涉及退款、投诉、补偿或低置信度时必须质检。
停止与升级规则循环超限、工具失败、高风险冲突时转人工。

这些规则可以逐步演进，但起步版本就必须写成可验收表格，而不是只写“Supervisor（监督者）会判断”。

第 7 步：设计质检​

质检 Agent 至少检查 5 件事：

  • 答复是否有政策依据或工具结果依据。
  • 是否泄露了用户不该看到的内部字段。
  • 是否承诺了系统不能保证的退款、赔付或时效。
  • 是否忽略了 risk_level（风险等级）和 escalation_required（是否升级人工）。
  • 是否需要返工、转人工或可以最终回复。

质检结果不要只写“通过”或“不通过”。它要说明原因和下一步建议。

第 8 步：设置循环上限​

多智能体允许返工，但不允许无限返工。

循环类型最大次数建议超限处理
补充政策依据1 到 2 次转人工或提示资料不足。
订单查询重试1 次转人工或稍后重试。
工单草稿返工1 到 2 次交给人工客服整理。
质检返工1 次Supervisor（监督者）仲裁或升级人工。
角色互相交接不允许无目标往返立即停止并写 loop_limit（循环超限）。

循环上限要写入状态和日志，不能只存在开发者脑子里。

第 9 步：验收路径​

至少准备 7 条路径样例：

路径期望行为
简单政策问答不触发多智能体，只用知识库回答。
查订单发货状态接待识别后交给订单 Agent，再最终回复。
延迟发货并要求工单知识库和订单结果汇总后，工单 Agent 创建草稿。
退款投诉高风险必须质检并升级人工或等待确认。
订单无权限Supervisor（监督者）停止，stop_reason（停止原因）为 no_permission（无权限）。
政策和订单冲突Supervisor（监督者）仲裁，必要时转人工。
质检连续不通过达到循环上限后转人工。

验收时要看最终答复，也要看日志能否还原路径。

和后续章节关系​

后续章节或主题和本章的关系
前端界面前端要展示当前处理角色、等待原因、人工升级和最终状态。
部署与运维多智能体会增加调用次数、延迟、成本和故障点。
可观测性与成本trace_id（追踪编号）、角色日志、交接日志和 Supervisor（监督者）决策日志会成为监控重点。
安全、权限与 Guardrail（护栏）本章的角色权限和人工升级会在安全章节扩展成更完整的风控体系。
商业交付多智能体适合展示复杂客服任务如何被分工、复核和升级人工。
综合项目后续完整客服工作台会把工具、状态图、多智能体、前端和部署串起来。

本章是第 2.8 章状态图之后的自然扩展。没有状态、权限和日志，多智能体只是多个模型互相传话；有了状态图和 Supervisor（监督者），多智能体才能变成可交付的协作系统。

版本与资料来源​

本节聚焦多智能体的角色分工、Handoff（任务转交）契约、Supervisor（监督者）决策、权限、状态、日志和面试表达。

主要资料入口：

过时风险：多智能体框架、Agents SDK（智能体软件开发工具包）、LangGraph（智能体状态图框架）和 MCP（模型上下文协议）生态会持续变化。进入真实项目开发前，必须重新核对当前官方文档、版本说明、团队运行时能力和权限策略。

继续学习​