跳到主要内容

第 2.9.1 节：先判断什么时候真的需要多智能体协作

进入实现之前，先围绕“先判断什么时候真的需要多智能体协作”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出什么时候真的需要多智能体协作的适用场景、不适用场景、前置条件和进入工程实现的判断标准。

本章要解决什么问题​

第 1.6 章讲了 Tool Calling（工具调用），让 Agent（智能体）可以在受控边界内查订单、查政策和创建工单。第 1.7 章讲了状态、记忆与会话，让系统知道当前任务走到哪里、缺什么字段、什么时候停止。第 2.8 章讲了 LangGraph（智能体状态图框架），把多步骤客服流程编排成可暂停、可恢复、可观测的状态图。

到这一章，读者会遇到新的工程断层：一个 Agent 越来越像“万能客服”，但真实客服系统里的职责并不应该全塞给一个模型角色。

在企业客服知识库与工单 Agent 工作台里，同一段对话可能同时涉及：

  • 接待用户，理解问题和情绪。
  • 检索售后政策、商品说明和客服话术。
  • 查询订单、物流、支付和历史工单。
  • 创建或更新工单。
  • 判断是否涉及投诉、退款、补偿和敏感风险。
  • 检查回答是否准确、是否过度承诺、是否该升级人工。

如果全部交给一个 Agent，Prompt（提示词）会越来越长，工具权限会越来越宽，状态字段会越来越混乱，出错后也很难知道到底是哪一步误判了。新手常见做法是“多叫几个模型”，比如一个模型查资料、一个模型写回复、一个模型检查结果。这个做法看起来像多智能体，实际只是多次调用模型。真正的 Multi-agent（多智能体） 系统要解决的是：把任务按角色、状态、交接和监督拆开，让每个 Agent 只在自己的职责和权限内工作。

本章通过角色、状态、交接与监督的工程设计，讲清：

  • 什么时候需要多智能体，什么时候一个工作流就够了。
  • 客服场景中接待 Agent、知识库 Agent、订单 Agent、工单 Agent、质检 Agent 和 Supervisor（监督者）分别负责什么。
  • Handoff（任务转交） 必须带哪些字段，不能只写“转给另一个 Agent”。
  • Supervisor（监督者） 如何路由、仲裁、停止、返工和升级人工。
  • 如何避免循环、互相推责、权限扩大和日志混乱。
  • 面试时如何把多智能体讲成工程协作能力，而不是“我用了很多 Agent”。

学习目标​

学完本章后，读者应该能做到：

  • 用人话解释多智能体不是多次模型调用，而是角色、状态、交接和监督的工程设计。
  • 判断客服工作台中哪些问题适合单 Agent 工作流，哪些问题值得拆成多智能体协作。
  • 为接待、知识库、订单、工单、质检和 Supervisor（监督者）设计清晰职责边界。
  • 设计 Handoff（任务转交）字段契约，至少覆盖 task_id（任务编号）、session_id（会话编号）、current_agent（当前智能体）、target_agent（目标智能体）、handoff_reason（交接原因）、handoff_payload（交接载荷）、supervisor_decision（监督者决策）、state（状态）、confidence（置信度）、risk_level（风险等级）、permissions（权限范围）、stop_reason（停止原因）、escalation_required（是否升级人工）和 trace_id（追踪编号）。
  • 说明 Supervisor（监督者）如何做路由、仲裁、停止、返工和人工升级。
  • 设计多智能体系统的权限、状态、日志、循环上限和失败兜底。
  • 识别多智能体项目中常见的循环、推责、越权、成本和延迟风险。
  • 把本章内容连接到 LangGraph（智能体状态图框架）、RAG（检索增强生成）、MCP（模型上下文协议）、安全权限和可观测性章节。
  • 准备一套能放进作品集和面试表达的多智能体设计材料。

贯穿业务场景​

继续使用本书的贯穿项目：企业客服知识库与工单 Agent 工作台。

这一章聚焦一个典型复杂问题：

用户说：“我这个订单一直没发货，客服也没人回复。我想退款，如果你们处理不了我就投诉。”

这个问题不是普通问答。它至少包含 5 类任务：

任务需要的能力适合的角色
理解用户意图和情绪判断是催发货、退款、投诉还是复合诉求接待 Agent
查询售后和发货政策从企业知识库检索可引用依据知识库 Agent
查询订单状态检查支付、库存、发货、物流和售后状态订单 Agent
创建或更新工单汇总诉求、关联订单、进入客服处理流程工单 Agent
检查答复和风险判断是否过度承诺、是否需要人工介入质检 Agent
路由和停止决定下一步交给谁、是否结束、是否升级人工Supervisor（监督者）

如果用一个 Agent 做，流程可能是：识别问题、查政策、查订单、生成工单草稿、检查风险、最终回答。这不是不可以，第 2.8 章的状态图就能处理很多这类流程。

但当系统开始出现以下情况时，多智能体就有价值：

  • 不同能力需要不同工具权限。比如订单 Agent 能查订单，但知识库 Agent 不能访问用户私有订单。
  • 不同角色的判断标准不同。接待 Agent 关注用户体验，质检 Agent 关注准确性和合规。
  • 任务结果需要复核。比如退款、投诉、补偿类回复，需要质检 Agent 检查后再发出。
  • 工单处理和知识库问答需要并行准备，但最终必须由 Supervisor（监督者）统一决策。
  • 团队希望把角色能力单独测试、单独优化、单独限权。

本章的核心不是让系统更热闹，而是让复杂客服任务更可控。

新手为什么会卡住​

新手做多智能体项目时，最常见的问题不是“不会创建多个 Agent”，而是“多个 Agent 没有工程边界”。

误解项目后果正确理解
多智能体就是多叫几个模型成本上升，但流程仍然不可控多智能体要有角色职责、状态契约、交接条件和监督规则。
每个 Agent 都能调用所有工具权限扩大，任何角色都可能误查订单或误建工单每个 Agent 只能使用自己职责内的工具和数据。
Handoff（任务转交）就是把聊天记录转过去目标 Agent 不知道任务边界、风险和下一步交接必须带结构化字段和上下文摘要。
Supervisor（监督者）越聪明越好Supervisor（监督者）变成另一个万能 AgentSupervisor（监督者）主要负责路由、仲裁、停止和升级，不包办所有业务动作。
Agent 之间可以互相商量到满意为止可能无限循环、互相推责、延迟和成本失控必须有最大轮数、停止原因和人工升级路径。
质检 Agent 只是最后润色风险检查流于形式质检要检查事实依据、权限边界、承诺风险和是否需要人工。
只要最终回答对就行出错时无法追踪是谁判断、谁转交、谁调用工具每次交接、决策和工具调用都要有 trace_id（追踪编号）和日志。

本章会把这些误区拆开。读者要先记住一句话：多智能体的难点不是“多”，而是“协作契约”。

继续学习​