前言前面我们已经学习了 Agent 的基础能力Prompt结构化输出Tool CallingReActWorkflowMemoryRAGMCP。现在可以回头思考一个问题一个 Agent 能不能把所有事情都做好理论上可以让一个 Agent 负责理解需求、制定计划、调用工具、写代码、审查代码、输出结果。但在实际项目中这种“大而全 Agent”很容易出现问题Prompt 越来越长工具越来越多职责混乱结果难以排查错误难以定位高风险动作难以控制一次失败后不知道是理解错、规划错还是执行错。因此当任务复杂到一定程度时可以考虑多智能体协作。多智能体不是“创建很多聊天机器人”而是将复杂任务拆分成职责清晰的角色由协调器控制任务流转并通过明确输入输出完成协作。一、什么场景适合多智能体不是所有 Agent 项目都需要多智能体。例如一个简单的知识库问答功能用户提问 - RAG 检索 - 模型回答一个 Agent 就足够了。但下面这些场景更适合考虑多智能体复杂任务拆解 多步骤数据分析 代码生成与代码审查 研发流程自动化 客服工单分流与处理 运维故障诊断 多个系统协同查询 长任务执行与质量复核例如用户提出一个需求帮我分析订单支付失败率升高的原因并给出排查建议。这个任务可能需要规划确定需要查哪些数据。 检索查询最近发布记录。 执行查询错误日志和监控指标。 分析汇总可能原因。 审核检查结论是否有足够证据。 输出给出排查建议。如果全部交给一个 Agent虽然能跑但可控性会比较差。二、多智能体常见角色划分下面是一个比较常见的角色模型。1. Planner规划 Agent职责理解用户目标拆分任务确定执行顺序判断是否需要工具输出结构化计划。例如用户说帮我排查订单服务错误率上升的问题。Planner 可以输出{goal:分析订单服务错误率上升原因,steps:[{step:1,action:查询最近发布记录,tool:get_release_history},{step:2,action:查询订单服务错误日志,tool:search_error_logs},{step:3,action:查询服务监控指标,tool:get_service_metrics},{step:4,action:汇总证据并生成排查结论,tool:null}]}2. Executor执行 Agent职责根据计划调用受控工具获取外部数据处理工具失败返回结构化执行结果。Executor 不应该擅自扩展权限也不应该因为“想试试”就调用未授权工具。3. Analyst分析 Agent职责根据执行结果找出关联关系识别可能原因区分事实和推测给出下一步排查方向。例如事实错误率上升发生在版本 v1.4.2 发布后 10 分钟。 事实错误日志中 DatabaseTimeoutException 占比 72%。 推测新版本可能增加了慢 SQL 或连接池压力。 建议检查订单查询 SQL、连接池指标和数据库慢日志。4. Reviewer审核 Agent职责检查结论是否有证据检查是否存在过度推断检查是否遗漏关键步骤检查最终内容是否触发安全风险。Reviewer 不负责重新做所有工作而是负责质量把关。5. Coordinator协调器Coordinator 可以是一个 Agent也可以是后端 Workflow。它负责维护任务状态决定下一步交给谁控制最大执行次数处理超时、失败和重试汇总最终结果要求用户确认高风险操作。在生产系统里Coordinator 往往更适合由后端 Workflow 实现而不是把所有调度决策完全交给模型。三、一个多智能体协作流程以“线上故障排查”作为例子。用户订单服务错误率突然升高帮我分析。 Coordinator 1. 创建诊断任务。 2. 交给 Planner 生成排查计划。 3. 交给 Executor 调用日志、发布记录、监控工具。 4. 交给 Analyst 根据证据分析。 5. 交给 Reviewer 审核分析结论。 6. 输出最终排查报告。流程可以表示为用户问题 | Planner 生成计划 | Executor 查询工具 | Analyst 汇总分析 | Reviewer 质量审核 | Coordinator 输出结果注意这不是要求每一轮都必须经过五个 Agent。真正的工程实践应该是简单任务走简单流程 复杂任务才进入多智能体协作否则系统成本、耗时和复杂度都会明显上升。四、规划结果必须结构化不推荐 Planner 返回一大段自然语言我建议先查看发布记录然后再看看日志接着观察数据库情况……因为后端很难稳定解析也不方便控制执行。推荐 Planner 返回 JSON。1. 任务计划 DTODatapublicclassAgentPlan{privateStringgoal;privateListPlanStepsteps;privateBooleanneedUserConfirmation;}DatapublicclassPlanStep{privateIntegerstepNo;privateStringaction;privateStringtoolName;privateMapString,Objectarguments;privateStringriskLevel;}2. Planner Prompt 示例你是任务规划 Agent。 请根据用户问题生成可执行计划。 规则 1. 只使用允许的工具。 2. 每一步必须说明目标、工具和参数。 3. 不能直接执行删除、发布、退款、权限修改等高风险操作。 4. 高风险操作必须标记 needUserConfirmationtrue。 5. 不要输出自然语言说明只返回 JSON。 6. 如果当前信息不足优先生成“查询信息”的步骤而不是猜测结论。3. 后端校验计划即使 Planner 返回了 JSON后端也不能直接执行。ServicepublicclassPlanValidationService{privatestaticfinalSetStringALLOWED_TOOLSSet.of(get_release_history,search_error_logs,get_service_metrics,search_project_document);publicvoidvalidate(AgentPlanplan){if(plan.getSteps()null||plan.getSteps().isEmpty()){thrownewBusinessException(任务计划不能为空);}if(plan.getSteps().size()8){thrownewBusinessException(任务步骤过多);}for(PlanStepstep:plan.getSteps()){if(step.getToolName()!null!ALLOWED_TOOLS.contains(step.getToolName())){thrownewBusinessException(计划包含未授权工具step.getToolName());}}}}这一步很重要模型生成的是建议计划后端校验后的计划才能进入执行阶段。五、执行 Agent 不应该拥有无限权限Executor 的职责是执行已审核的计划而不是自由发挥。例如 Planner 给出{stepNo:1,action:查询订单服务最近一小时错误日志,toolName:search_error_logs,arguments:{serviceName:order-service,timeRange:LAST_1_HOUR}}Executor 执行时还要做以下校验当前用户是否有日志查询权限 serviceName 是否在允许范围 timeRange 是否超过最大查询窗口 工具返回内容是否包含敏感字段 单次查询数据量是否过大示例代码ServiceRequiredArgsConstructorpublicclassAgentExecutionService{privatefinalToolRegistrytoolRegistry;privatefinalAgentAuditLogServiceagentAuditLogService;publicToolExecuteResultexecute(LonguserId,StringconversationId,PlanStepstep){AgentTooltooltoolRegistry.getTool(step.getToolName());if(toolnull){thrownewBusinessException(工具不存在step.getToolName());}tool.validateArguments(step.getArguments());tool.checkPermission(userId,step.getArguments());longstartTimeSystem.currentTimeMillis();try{ToolExecuteResultresulttool.execute(userId,step.getArguments());agentAuditLogService.recordSuccess(userId,conversationId,step.getToolName(),duration(startTime));returnresult;}catch(Exceptione){agentAuditLogService.recordFailure(userId,conversationId,step.getToolName(),duration(startTime),e.getMessage());returnToolExecuteResult.fail(工具执行失败请检查权限或参数);}}privatelongduration(longstartTime){returnSystem.currentTimeMillis()-startTime;}}六、分析 Agent 如何避免“看起来很合理但其实在猜”多智能体系统里最危险的情况之一就是工具结果不完整但分析 Agent 给出了非常肯定的结论。例如工具只查到了错误日志DatabaseTimeoutException 出现 100 次。分析 Agent 却直接说根因是数据库连接池配置错误。这就是过度推断。更好的分析输出应该区分证据 推测 待验证项 建议动作1. 分析结果 DTODatapublicclassDiagnosisResult{privateListStringfacts;privateListStringhypotheses;privateListStringverificationItems;privateListStringrecommendations;privateStringconfidenceLevel;}2. Analyst Prompt 示例你是故障分析 Agent。 请仅根据工具返回的数据进行分析。 输出要求 1. facts只能写已有证据直接支持的事实。 2. hypotheses可以给出可能原因但必须使用“可能”“需要验证”等表达。 3. verificationItems列出下一步需要检查的数据。 4. recommendations给出低风险排查建议。 5. 如果证据不足明确说明无法判断根因。 6. 不要把推测写成确定事实。这样能明显提高分析结果的可解释性。七、Reviewer 到底审核什么Reviewer 不是“再问一次模型你觉得对不对”。它应该有明确检查项。1. 证据完整性结论是否能在工具结果中找到依据2. 推测边界是否把可能原因说成了确定根因3. 安全边界是否泄露了敏感信息 是否建议了未确认的高风险操作4. 执行完整性是否漏掉了计划中的关键步骤 工具失败时是否有说明5. 输出可读性最终结论是否能让开发、测试或运维人员继续行动Reviewer 可以返回{passed:false,issues:[结论中提到连接池配置错误但工具结果未提供连接池指标。,建议补充查询数据库连接池使用率和慢 SQL 日志。]}Coordinator 收到未通过结果后可以补充调用工具 - 再次分析 - 再次审核但必须设置最大循环次数避免 Agent 无限循环。八、为什么多智能体需要状态管理多智能体任务通常不是一次请求就结束。因此需要在后端保存任务状态。1. 任务表示例CREATETABLEai_agent_task(idBIGINTPRIMARYKEYAUTO_INCREMENT,task_noVARCHAR(64)NOTNULL,user_idBIGINTNOTNULL,conversation_idVARCHAR(64)NOTNULL,task_typeVARCHAR(64)NOTNULL,statusVARCHAR(32)NOTNULL,current_stageVARCHAR(32)NOTNULL,input_contentTEXTNOTNULL,plan_contentTEXTDEFAULTNULL,result_contentTEXTDEFAULTNULL,error_messageVARCHAR(1000)DEFAULTNULL,created_timeDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,updated_timeDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMP,UNIQUEKEYuk_task_no(task_no),INDEXidx_user_status(user_id,status))COMMENTAI Agent任务表;状态可以设计为PENDING PLANNING EXECUTING ANALYZING REVIEWING WAITING_CONFIRMATION SUCCESS FAILED CANCELLED2. 状态流转要受控不推荐在代码里随意写task.setStatus(SUCCESS);更好的是封装状态机规则。publicvoidtransit(AgentTasktask,TaskStatustargetStatus){if(!isAllowed(task.getStatus(),targetStatus)){thrownewBusinessException(非法任务状态流转);}task.setStatus(targetStatus);agentTaskMapper.updateStatus(task);}例如PENDING - PLANNING PLANNING - EXECUTING EXECUTING - ANALYZING ANALYZING - REVIEWING REVIEWING - SUCCESS这样能避免任务状态混乱。九、人机协同比“全自动”更重要多智能体系统最容易被误解成“让 AI 自动完成一切”。但在企业场景中更稳妥的方向往往是人机协同。适合 Agent 自动做的事情总结日志 检索文档 生成排查计划 提取工单信息 分析异常趋势 生成测试用例草稿 生成代码审查建议需要人工确认的事情发布生产环境 删除数据 调整权限 修改价格 退款 发送大规模通知 执行数据库变更可以设计确认卡片操作类型发布测试环境 项目order-service 版本v1.2.0 影响范围重启 2 个实例 执行人当前用户 是否确认执行这里的确认逻辑必须由后端控制不能依赖模型在回答文本里写一句“我确认”。十、什么时候不应该使用多智能体下面几种情况不建议一开始就引入多智能体。1. 任务非常简单例如根据知识库回答一个问题。一个 RAG Agent 即可完成。2. 工具很少例如系统只有两个只读工具查询订单 查询用户信息此时清晰的 Tool Calling 流程就足够了。3. 业务规则高度确定例如提交报销 - 审批 - 打款 - 通知这更适合 Workflow而不是多个 Agent 轮流决策。4. 没有评测和观测能力如果你无法回答下面这些问题哪个 Agent 出错了 哪一步耗时最长 哪一个工具调用失败 为什么最终答案不可靠那么多智能体只会让问题变得更难排查。十一、实际开发建议1. 先从“单 Agent 多角色 Prompt”开始在早期阶段可以不真的部署多个独立 Agent 服务。先使用一个模型但分阶段调用第一次调用生成计划 第二次调用分析工具结果 第三次调用审核最终结论每一步使用不同 Prompt、不同 JSON 输出结构。这样既能验证多角色协作思路也不会过早引入复杂架构。2. 用 Workflow 控制流程用 Agent 做判断这是一个很实用的组合Workflow 控制状态、顺序、重试、超时、确认、审计。 Agent 理解自然语言、生成计划、分析信息、总结结论。不要让模型独自决定所有流程跳转和权限边界。3. 限制最大步骤和最大重试次数例如最大计划步骤8 步 单个工具最大重试2 次 分析审核最大循环2 次 单任务最大执行时间60 秒这些限制可以防止成本失控和无限循环。4. 给每一步保留可追踪记录建议记录任务ID 当前角色 输入摘要 输出摘要 工具调用信息 耗时 失败原因 Token 使用情况这样用户反馈“这个结论从哪里来的”时你能够解释整个过程。十二、总结这一篇我们学习了多智能体协作的基本设计。重点可以记住多智能体的核心是职责拆分不是堆很多聊天机器人。常见角色包括 Planner、Executor、Analyst、Reviewer 和 Coordinator。Planner 应输出结构化计划后端必须校验后才能执行。Executor 只执行受控工具不能拥有无限权限。Analyst 必须区分事实、推测和待验证项。Reviewer 用于检查证据、边界、安全和输出质量。多智能体任务需要后端状态管理、重试限制和审计日志。高风险操作必须人机协同不能让 Agent 自动执行。简单任务不需要多智能体Workflow 往往比自由决策更可靠。下一篇我们会进入 Agent 的质量保障如何评估回答质量、发现幻觉、定位错误工具调用并建立可观测性。
