第 2.9.2 节：把角色职责和 Handoff 载荷设计清楚
本节围绕“把角色职责和 Handoff 载荷设计清楚”展开，先建立直观判断，再进入工程细节。完成本节后，你应该能够说清角色设计与 Handoff 载荷的处理顺序、关键检查点和失败处理。
核心概念四层解释法
Multi-agent（多智能体）
| 层级 | 解释 |
|---|---|
| 人话解释 | 多智能体是让多个有明确职责的 Agent（智能体）协作完成任务，而不是让一个 Agent 什么都做。 |
| 项目位置 | 在客服工作台里，接待 Agent 负责理解用户，知识库 Agent 负责找依据，订单 Agent 负责查业务状态，工单 Agent 负责写入工单，质检 Agent 负责复核，Supervisor（监督者）负责调度。 |
| 工程动作 | 你要定义角色、权限、可用工具、输入输出、交接字段、共享状态、循环上限、日志和验收样例。 |
| 面试说法 | 多智能体不是为了增加模型数量，而是把复杂任务拆成可限权、可测试、可复核、可追踪的角色协作。 |
Agent（智能体） role（智能体角色）
| 层级 | 解释 |
|---|---|
| 人话解释 | Agent role（智能体角色）是一个 Agent 在系统里的职责边界，说明它能做什么、不能做什么、能用哪些资料和工具。 |
| 项目位置 | 订单 Agent 能读取订单状态，但不能改售后政策；知识库 Agent 能检索资料，但不能创建工单；工单 Agent 能创建工单，但必须依赖用户确认和权限校验。 |
| 工程动作 | 为每个角色写清任务范围、输入字段、输出字段、工具权限、风险等级和停止条件。 |
| 面试说法 | 我不会让每个 Agent 都拿全量上下文和全量工具，而是按角色最小权限设计。 |
Handoff（任务转交）
| 层级 | 解释 |
|---|---|
| 人话解释 | Handoff（任务转交）是当前 Agent 把任务转给另一个 Agent 处理，并交代清楚为什么转、转什么、已经做过什么、接下来应该注意什么。 |
| 项目位置 | 接待 Agent 识别到用户需要查询订单后，把任务交给订单 Agent；订单 Agent 查到订单异常后，把结果交回 Supervisor（监督者），再由 Supervisor（监督者）决定是否交给工单 Agent。 |
| 工程动作 | 交接要有 task_id（任务编号）、session_id（会话编号）、current_agent（当前智能体）、target_agent（目标智能体）、handoff_reason（交接原因）、handoff_payload（交接载荷）、state（状态）、confidence（置信度）、risk_level（风险等级）、permissions（权限范围）和 trace_id（追踪编号）。 |
| 面试说法 | Handoff（任务转交）不是把聊天记录转发，而是一次可审计的任务边界切换。 |
Supervisor（监督者）
| 层级 | 解释 |
|---|---|
| 人话解释 | Supervisor（监督者）像客服主管，不一定亲自查订单或写工单，但负责决定任务应该交给谁、结果是否合格、是否要返工、什么时候停止、什么时候升级人工。 |
| 项目位置 | 在客服工作台里，Supervisor（监督者）接收每个 Agent 的结果，维护共享状态，决定下一步路由：继续查资料、查订单、创建工单、质检、最终回复或转人工。 |
| 工程动作 | 你要设计路由规则、仲裁规则、停止条件、最大轮数、人工升级条件、日志字段和异常处理。 |
| 面试说法 | Supervisor（监督者）的价值是把多个 Agent 的协作收束到可控流程，而不是让多个模型自由聊天。 |
Shared state（共享状态）
| 层级 | 解释 |
|---|---|
| 人话解释 | Shared state（共享状态）是多智能体共同读取和更新的任务事实，不是随意拼接的聊天记录。 |
| 项目位置 | 客服任务的共享状态包含用户意图、订单状态、政策依据、工单草稿、风险等级、当前处理角色、交接历史、停止原因和是否需要人工。 |
| 工程动作 | 共享状态要区分可写字段和只读字段。不是每个 Agent 都能改 risk_level（风险等级）、permissions（权限范围）或 stop_reason（停止原因）。 |
| 面试说法 | 多智能体协作要靠结构化状态对齐，不应该让每个 Agent 各自维护一份事实。 |
仲裁
| 层级 | 解释 |
|---|---|
| 人话解释 | 仲裁是多个 Agent 的结论冲突时，由 Supervisor（监督者）按规则决定采信谁、是否复查、是否转人工。 |
| 项目位置 | 知识库 Agent 认为政策允许退款，但订单 Agent 发现商品已过售后期。Supervisor（监督者）不能随便选一个答案，而要按订单状态、政策版本和风险等级决定是否让质检 Agent 复核或升级人工。 |
| 工程动作 | 你要定义冲突类型、证据优先级、复查路径、人工升级条件和最终 stop_reason（停止原因）。 |
| 面试说法 | 多智能体不是投票游戏。涉及业务状态和高风险动作时，仲裁要依赖规则、证据和权限。 |
本章在客服 Agent（智能体）工作台中的位置
客服工作台可以分成 9 层。本章负责多智能体协作层和监督层。
| 层级 | 作用 | 本章关注点 |
|---|---|---|
| 用户入口 | 接收用户消息、登录状态、订单选择和确认动作 | 提供 session_id（会话编号）和用户身份。 |
| 接待层 | 识别用户意图、情绪、缺失信息和初始风险 | 接待 Agent 的职责边界。 |
| 知识库层 | 检索售后政策、商品说明和客服规范 | 知识库 Agent 与 RAG（检索增强生成） 的关系。 |
| 业务工具层 | 查订单、查历史工单、创建工单 | 订单 Agent 和工单 Agent 的权限边界。 |
| 状态与工作流层 | 保存任务状态、节点状态和恢复点 | 承接第 1.7 章和第 2.8 章。 |
| 多智能体协作层 | 角色分工、交接、结果汇总和返工 | 本章核心。 |
| Supervisor（监督者）层 | 路由、仲裁、停止、升级人工 | 本章核心。 |
| 日志审计层 | 记录交接、工具、状态、决策和最终输出 | 防止日志混乱。 |
| 展示与运营层 | 展示当前由谁处理、为什么转人工、工单状态 | 让用户和客服人员可理解。 |
一个重要边界是：多智能体协作不替代状态图。第 2.8 章的状态图仍然负责流程阶段和恢复，本章是在状态图上增加角色分工和监督规则。简单说，状态图回答“流程到哪一步”，多智能体回答“这一步由哪个角色负责”，Supervisor（监督者）回答“下一步该交给谁，是否结束”。
系统流程图
下面是一条“延迟发货、退款和投诉”客服任务的多智能体协作流程。
读图重点：先读上组：接待后由 Supervisor 分派知识库和订单角色，证据冲突时进入质检与仲裁；再读下组：工单写入先确认，最终质检可放行、定向返工或升级人工，所有结果写入停止原因。
这张图有 6 个重点：
- 接待 Agent 不直接查订单或创建工单，它先识别意图和风险。
- 知识库 Agent 和订单 Agent 可以并行准备证据，但都要回到 Supervisor（监督者）。
- Supervisor（监督者）不是普通聊天角色，它维护共享状态并决定路由。
- 质检 Agent 不是润色工具，而是检查事实、风险、权限和是否过度承诺。
- 工单 Agent 只负责工单相关动作，写入前要确认和校验。
- 所有分支最终都要写入 stop_reason（停止原因），不能让任务悬空。
模块拆分
客服工作台里的多智能体能力，可以拆成 10 个模块。
| 模块 | 作用 | 关键产出 |
|---|---|---|
| 角色注册模块 | 定义系统有哪些 Agent 角色 | 角色清单、职责边界、可用工具。 |
| 权限模块 | 控制每个角色能读写什么 | permissions（权限范围）、工具白名单、数据范围。 |
| 共享状态模块 | 保存任务事实和协作结果 | task_id（任务编号）、state（状态）、risk_level（风险等级）。 |
| 交接模块 | 记录和执行 Handoff（任务转交） | 交接契约、交接历史、目标角色校验。 |
| Supervisor（监督者）模块 | 路由、仲裁、停止和升级人工 | supervisor_decision（监督者决策）、stop_reason（停止原因）。 |
| Agent 执行模块 | 让具体角色处理自己的任务 | 输入摘要、输出摘要、confidence（置信度）。 |
| 工具治理模块 | 管控订单、知识库和工单工具 | 工具权限、幂等、错误和审计。 |
| 质检模块 | 复核事实、风险和合规 | 质检结果、返工建议、人工升级建议。 |
| 日志追踪模块 | 串联一次任务的所有事件 | trace_id（追踪编号）、交接日志、决策日志。 |
| 展示模块 | 给用户和客服人员展示当前状态 | 当前处理角色、等待原因、下一步动作。 |
模块拆分的重点不是增加目录，而是让职责可独立验收。比如角色注册模块要能回答“订单 Agent 到底能不能创建工单”，日志追踪模块要能回答“为什么这次任务从知识库 Agent 转给了质检 Agent”。