多智能体这几年一直是热门话题。刷技术社区也好刷短视频也好总能看到类似的演示几个 Agent 挤在一个工作台里互相配合一个拆需求一个写代码一个跑测试代码在屏幕上自动滚动看起来一个项目马上就要自己把自己写完了。这类演示确实有冲击力因为它把AI 自动完成复杂任务这件事变得非常直观。但真正把多 Agent 接进生产系统的人聊起来往往是另一副表情Agent 之间互相覆盖结果、同一个上游数据被改了又改、某一步推理跑偏导致整条链路失效、出了故障不知道从哪个节点开始排查最后只能靠人工把系统状态手动拉回来。这篇文章想讲清楚一件事多 Agent 协作的价值是真实的但自发协调四个字里藏着风险。所谓自发意味着任务拆分、工具调用、信息传递这些决策是由多个 Agent 分布式做出的而不是由一段确定性代码写死的。Agent 越自发系统对可预期性和治理机制的需求就越强。因此人类介入不是要不要的问题而是介入时机、介入深度、介入工具的架构设计问题。我会从概念边界、典型风险、工程落地三个层面展开。你会看到多 Agent 协作中真正容易出问题的四类场景也会拿到带人工审批节点的编排器示例、工作流配置思路、trace 日志规范、最小权限 SQL 和一份从 Demo 到生产的检查清单。读完你可以判断自己的项目该不该上多 Agent以及如果上人的位置应该放在哪几个节点。1. 为什么多 Agent 协作值得关注但它不是万能钥匙1.1 多 Agent 带来的真实收益从工程角度看单 Agent 的能力边界非常清晰上下文窗口有限单个模型在超长任务上容易遗忘早期信息一次推理失败往往整个任务就要重来当任务涉及多个专业领域时一个模型很难在所有环节都保持稳定。多 Agent 的思路是把复杂任务拆成多个子任务分给不同角色去完成。每个 Agent 的上下文更短、职责更专一可以并行执行甚至让一个 Agent 去检查另一个 Agent 的输出。这套逻辑和软件工程里的团队分工很像不是让一个人同时做需求分析、架构设计、编码和测试而是让每个角色专注做自己的事再通过评审和联调把结果拼起来。单 Agent 模式 用户 - 一个模型完成所有步骤 - 结果 多 Agent 模式 用户 - 编排器 - Agent A(需求分析) - Agent B(编码) - Agent C(测试) - 结果这种结构在内容生成、代码生成、数据分析这类可以明确拆分的任务上通常好于单 Agent 硬扛。这也是为什么智能体开发多智能体智能体框架这些词最近热度这么高。Dify、Coze扣子这类平台把智能体搭建的入门门槛压得很低任何人拖拽几个节点就能跑起一个 Agent 应用。但门槛降低的另一面是更多人会在没有想清楚治理机制的情况下把多 Agent 直接推向生产。1.2 热闹背后的认知误区很多项目死在第一步把多 Agent 当成数量越多越好。让十个 Agent 自由聊天看起来很有未来感实际产出往往不可控。多 Agent 适合的是结构可拆解、任务可验证的工作而不是目标本身模糊的工作。如果用户连自己想要什么都没说清楚多个 Agent 只会把模糊放大成混乱。这一节的关键结论是多 Agent 的核心价值不在于做得热闹而在于拆分合理 结果可验证。拆分是否合理由架构决定结果是否可验证由可观测系统和人类判断兜底。想清楚这两点再谈要不要上多 Agent。2. Agent、工作流与多智能体先把概念边界划清楚2.1 Agent有感知、决策、行动、记忆的循环智能体Agent不是单纯的大模型调用。它的最小循环是接收输入结合已有的记忆和工具能力做出决策执行动作再把结果写回记忆。一个能查资料、能调用工具、能记住前文上下文的 Agent才是真正意义上的 AI 智能体。如果只是输入一段 prompt输出一段文本那是普通的大模型应用不是 Agent。Agent 的关键区别在于自主调用工具和多步决策。它可以在一次任务里连续调用搜索、代码执行、数据库查询等多个工具并根据中间结果调整下一步动作。这个自主性带来的是效率也是风险——因为每一跳都可能偏离原始目标。2.2 Workflow把路径固定下来的工作流工作流Workflow是另一种模式流程是预先定义好的每一步做什么、输入输出是什么基本上都固定。比如读取工单 - 判断类型 - 转接对应部门 - 通知用户节点和分支是确定的。工作流的优点是稳定、可控、可预测缺点是灵活度低无法处理开放式问题。在实际平台里Dify、Coze 这类智能体平台把工作流和 Agent 做成了可视化节点。开发者拖拽节点在关键节点上挂一个 LLM 调用或 Agent 执行块既保留流程的确定性又保留模型的灵活性。这也是目前国内智能体开发的主流玩法不是让 Agent 完全自由而是让它在工作流划定的范围里自主。2.3 Multi-Agent多个 Agent 的协作系统多智能体Multi-Agent是指多个 Agent 通过某种协调机制共同完成一个目标。这里的关键词是协调机制不是数量。工程上常见的协调模式有三种协调模式核心特征适合场景主要风险编排器模式中央节点负责任务拆分、调度、结果汇总业务流程清晰、可拆解编排器成为单点压力对等协作模式Agent 之间直接通信共享任务池研究探索、头脑风暴目标漂移、上下文污染市场竞价模式用成本或评分机制动态分配任务资源调度、优化类任务机制设计复杂、难调试常见的误区是把多 Agent 等同于拉一群 Agent 进群聊。没有编排、没有状态管理、没有验收环节的纯自由讨论大概率会产出大量重复、矛盾甚至幻觉的内容。真正可靠的多 Agent 系统一定是在一个有边界的运行环境里协作的。这也是我在后面几章反复强调约束和人类介入的原因。3. 自发协调的四类核心风险3.1 目标冲突与目标漂移目标冲突最容易理解。假设你让三个 Agent 协作完成一个新品上市方案市场 Agent 负责推广文案财务 Agent 负责核算预算研发 Agent 评估技术可行性。市场 Agent 为了创意效果提出高预算方案财务 Agent 为了成本控制提出相反结论。两个 Agent 的目标在同一场景下天然互斥。没有协调机制时它们会互相反驳、反复修改、消耗大量 token最后通常输出一个看起来两边都沾但两边都不满意的折中方案。目标漂移则更隐蔽。指 Agent 在长链路执行中因为局部优化或对中间结果的过度聚焦逐渐偏离系统最初设定目标的累积偏差。它不一定是模型故意跑偏而是大模型在逐步推理时的一种本性。比如一个写代码的 Agent 在优化某个函数性能时越查越深入花十几步研究边界极端情况最后把实现功能原型演变成了重写整个模块。等它把结果交回来时原始需求已经被抛到脑后。应对思路有两层第一层是编排器在关键节点校验子任务输出是否与用户原始目标一致不一致就打回而不是直接传给下一个 Agent第二层是设置人工或规则审批节点对高风险方向变化及时打断。3.2 资源竞争、限流与死锁多个 Agent 并行执行时它们不是活在真空中而是要共享工具和资源。最常见的问题有下面几类。第一多个 Agent 同时写同一个文件或记录后写覆盖先写导致结果残缺。比如两个 Agent 分别负责写文档第一章和写文档第二章如果它们直接操作同一个 Markdown 文件没有锁或合并机制很可能互相覆盖。第二多个 Agent 同时调用同一个第三方 API导致限流触发。更麻烦的是重试风暴一个 Agent 调用失败后自动重试另一个 Agent 也在重试限流反而更严重最终把所有 Agent 的请求都堵住。第三死锁。Agent A 持有资源 R1 的锁等待 R2Agent B 持有 R2 的锁等待 R1。在没有超时机制和死锁检测的编排器里两个 Agent 会一直等下去任务挂死而且日志里看起来谁都没有报错。这类风险需要在编排层解决统一控制并发度给工具调用设置超时和重试上限关键资源加锁或转为生产-消费队列并保证写操作幂等。单 Agent 时代靠代码顺序解决的问题多 Agent 时代必须靠调度机制显式解决。3.3 共享上下文污染与幻觉传播多 Agent 协作的一个重要设计是共享上下文或共享记忆。它带来的问题是污染一个 Agent 写入的中间内容会改变另一个 Agent 的决策输入如果中间内容包含部分错误错误就会沿着协作链传播。举一个客服场景的例子。用户说我上次的订单出问题了。订单 Agent 查询后把订单状态异常写入共享上下文退款 Agent 读到之后直接生成退款方案。但订单 Agent 实际想表达的是物流状态显示异常需要人工核验后再定只是共享上下文里只保留了结论没有保留完整前因。第二个 Agent 把部分结论当成事实决策方向就偏了。更常见的错误是幻觉传播。一个 Agent 在检索资料时产生了一个错误的中间结论写进共享上下文后续 Agent 不再验证直接引用。在单 Agent 场景你可以通过查看它的推理链来定位幻觉在多 Agent 场景这个错误经过多次传递后会被放大最后你可能很难追到源头。解决方向是上下文隔离与结构化消息传递。Agent 之间不要共享一个无边界的大上下文窗口而应该通过定义良好的消息结构传递结论 依据 置信度。下游 Agent 对置信度低的信息应当再次验证而不是默认信任。3.4 可追踪性下降与责任真空单 Agent 排障比较容易查看它的思考链、工具调用、输入输出问题通常很快浮出水面。多 Agent 排障则完全不同一条任务可能经过十几个 Agent、几十次工具调用分散在多个服务节点上。如果日志里没有统一的 trace_id没有记录父子调用关系出了问题就只能靠猜。这里会出现软件工程里的经典问题责任真空。出了错每个 Agent 都只执行了自己的逻辑看起来谁都没有错但整体结果错了。更麻烦的是如果 Agent 的决策过程中提到这是根据上一个 Agent 的结果得出的你无法快速验证上一个 Agent 的结果到底存不存在、对不对。可追踪性不是锦上添花而是多 Agent 系统能不能长期运营的基础。没有 trace、没有审计你就无法复盘、无法改进、无法向老板解释为什么系统输出了一份错误报告更无法在监管或合规审查面前自证清白。4. 人类介入从可选项变成架构设计的一部分4.1 为什么不能彻底去掉人类很多人追求的是全自动跑通的爽快感但工程上必须承认人类介入在多 Agent 系统里有三个不可替代的作用。第一价值观判断。Agent 无法真正理解组织规则、社会规范和伦理边界。自动发送一封道歉邮件、给出法律意见、决定是否退款这些动作背后都有价值判断不应该完全交给模型。第二风险兜底。模型的推理能力再强也会有幻觉和知识盲区。生产系统一旦出错代价可能是金钱、口碑或数据安全。人类的作用不是预测每一次错误而是在错误发生后有能力止损和纠正。第三需求歧义消解。用户的原始意图往往依赖场景上下文。多个 Agent 面对模糊指令时可能各自理解出完全不同的方向。这种情况下一个简短的人工确认胜过让 Agent 盲目跑十条路径。4.2 三种介入模式从人盯着每一步到人只在必要时出现根据介入深度人类介入可以分成三层术语分别是 Human-in-the-Loop、Human-on-the-Loop 和 Human-in-Command。Human-in-the-Loop人在循环内强调每个关键决策前必须有人确认。适合高风险、低频、需要明确授权的操作比如删除资源、发送对外消息、执行支付。Human-on-the-Loop人在循环上强调人类监控 Agent 的执行过程平时不干预出现异常时才接管。适合中高风险任务比如自动生成报告、自动回复内部工单。Human-in-Command人在指挥层强调人类设定目标与边界Agent 在边界内自主执行人类在更高层面决定是否继续、调整或终止。适合低风险到中风险任务以及长期运营型 Agent。这三种模式不是互斥的而是可以组合的。一个系统里完全可以同时存在低风险环节按 In-Command 全自动跑中等风险环节按 On-the-Loop 加监控高风险环节按 In-the-Loop 加审批。4.3 介入时机选择矩阵关键不是要不要人看而是在哪个节点看、看到什么程度。下面这张表可以作为设计参考任务类型风险等级推荐介入模式介入动作内容初稿、代码片段建议低Human-in-Command事后抽查数据分析报告生成低到中Human-on-the-Loop异常监测自动回复用户邮件中Human-in-the-Loop发送前审批数据库写操作、资源删除高Human-in-the-Loop审批 回滚自动交易、自动化运维高Human-in-Command红线规则 熔断这里真正值得注意的设计原则是审批节点必须可配置。同一套多 Agent 系统在测试环境可以把审批关闭在灰度环境只对部分用户开放自动执行在生产环境对高风险动作强制人工审批。把人类介入做成工作流中的一个普通节点而不是一个外挂的流程系统才具备在不同阶段调整自主度的能力。5. 工程落地一用工作流与编排机制约束自发5.1 工作流不是限制 Agent而是保护 Agent很多开发者抵触工作流觉得它限制了 Agent 的自由度。但从工程视角看工作流更像护栏它把 Agent 的自由探索限制在安全的节点内部大幅降低目标漂移和资源竞争的概率。具体做法是在任务类型可以预定义大部分路径时用工作流固定主流程Agent 只在少数分支节点做选择。比如一个客户投诉处理 Agent主流程可以是解析工单 - 查询订单 - 判断风险 - 生成处理方案 - 人工审批 - 执行其中生成处理方案这个节点可以让 Agent 自由发挥但 Agent 能调用的工具、能接触的数据范围都是事先限定好的。5.2 编排器模式把自发收敛到节点内部在多 Agent 架构里最稳妥的起步方式是编排器模式Orchestrator-Worker。中央编排器持有任务状态机负责任务拆分、调度、超时控制、结果汇总Worker Agent 只负责执行具体的子任务。这种模式的优点是把复杂协调逻辑收敛到一处排查问题时有明确的入口。下面是一个 Java 示例演示编排器如何插入人工审批节点。// 文件路径src/main/java/com/example/agent/Orchestrator.java // 说明简化的多Agent编排器示例重点演示人工审批节点如何生效。 // 生产环境建议结合Spring StateMachine或Camunda等工具管理任务状态。 import java.util.ArrayList; import java.util.List; public class Orchestrator { // 模拟Agent执行结果 static class AgentResult { String agentName; String summary; String targetState; AgentResult(String agentName, String summary, String targetState) { this.agentName agentName; this.summary summary; this.targetState targetState; } } // 用于区分高风险操作 enum Operation { READ_ONLY, WRITE_DB, SEND_MESSAGE, DELETE_RESOURCE, PAYMENT } public void runTask(String rawDescription, ListString approvers) throws InterruptedException { System.out.println(Step 1: 编排器解析任务生成子任务清单); ListString subTasks decompose(rawDescription); System.out.println(Step 2: 按DAG拓扑调度多个Agent并行或串行执行); Agent 多智能体协作风险与人类介入：从编排器到工作流的工程实践
多智能体这几年一直是热门话题。刷技术社区也好刷短视频也好总能看到类似的演示几个 Agent 挤在一个工作台里互相配合一个拆需求一个写代码一个跑测试代码在屏幕上自动滚动看起来一个项目马上就要自己把自己写完了。这类演示确实有冲击力因为它把AI 自动完成复杂任务这件事变得非常直观。但真正把多 Agent 接进生产系统的人聊起来往往是另一副表情Agent 之间互相覆盖结果、同一个上游数据被改了又改、某一步推理跑偏导致整条链路失效、出了故障不知道从哪个节点开始排查最后只能靠人工把系统状态手动拉回来。这篇文章想讲清楚一件事多 Agent 协作的价值是真实的但自发协调四个字里藏着风险。所谓自发意味着任务拆分、工具调用、信息传递这些决策是由多个 Agent 分布式做出的而不是由一段确定性代码写死的。Agent 越自发系统对可预期性和治理机制的需求就越强。因此人类介入不是要不要的问题而是介入时机、介入深度、介入工具的架构设计问题。我会从概念边界、典型风险、工程落地三个层面展开。你会看到多 Agent 协作中真正容易出问题的四类场景也会拿到带人工审批节点的编排器示例、工作流配置思路、trace 日志规范、最小权限 SQL 和一份从 Demo 到生产的检查清单。读完你可以判断自己的项目该不该上多 Agent以及如果上人的位置应该放在哪几个节点。1. 为什么多 Agent 协作值得关注但它不是万能钥匙1.1 多 Agent 带来的真实收益从工程角度看单 Agent 的能力边界非常清晰上下文窗口有限单个模型在超长任务上容易遗忘早期信息一次推理失败往往整个任务就要重来当任务涉及多个专业领域时一个模型很难在所有环节都保持稳定。多 Agent 的思路是把复杂任务拆成多个子任务分给不同角色去完成。每个 Agent 的上下文更短、职责更专一可以并行执行甚至让一个 Agent 去检查另一个 Agent 的输出。这套逻辑和软件工程里的团队分工很像不是让一个人同时做需求分析、架构设计、编码和测试而是让每个角色专注做自己的事再通过评审和联调把结果拼起来。单 Agent 模式 用户 - 一个模型完成所有步骤 - 结果 多 Agent 模式 用户 - 编排器 - Agent A(需求分析) - Agent B(编码) - Agent C(测试) - 结果这种结构在内容生成、代码生成、数据分析这类可以明确拆分的任务上通常好于单 Agent 硬扛。这也是为什么智能体开发多智能体智能体框架这些词最近热度这么高。Dify、Coze扣子这类平台把智能体搭建的入门门槛压得很低任何人拖拽几个节点就能跑起一个 Agent 应用。但门槛降低的另一面是更多人会在没有想清楚治理机制的情况下把多 Agent 直接推向生产。1.2 热闹背后的认知误区很多项目死在第一步把多 Agent 当成数量越多越好。让十个 Agent 自由聊天看起来很有未来感实际产出往往不可控。多 Agent 适合的是结构可拆解、任务可验证的工作而不是目标本身模糊的工作。如果用户连自己想要什么都没说清楚多个 Agent 只会把模糊放大成混乱。这一节的关键结论是多 Agent 的核心价值不在于做得热闹而在于拆分合理 结果可验证。拆分是否合理由架构决定结果是否可验证由可观测系统和人类判断兜底。想清楚这两点再谈要不要上多 Agent。2. Agent、工作流与多智能体先把概念边界划清楚2.1 Agent有感知、决策、行动、记忆的循环智能体Agent不是单纯的大模型调用。它的最小循环是接收输入结合已有的记忆和工具能力做出决策执行动作再把结果写回记忆。一个能查资料、能调用工具、能记住前文上下文的 Agent才是真正意义上的 AI 智能体。如果只是输入一段 prompt输出一段文本那是普通的大模型应用不是 Agent。Agent 的关键区别在于自主调用工具和多步决策。它可以在一次任务里连续调用搜索、代码执行、数据库查询等多个工具并根据中间结果调整下一步动作。这个自主性带来的是效率也是风险——因为每一跳都可能偏离原始目标。2.2 Workflow把路径固定下来的工作流工作流Workflow是另一种模式流程是预先定义好的每一步做什么、输入输出是什么基本上都固定。比如读取工单 - 判断类型 - 转接对应部门 - 通知用户节点和分支是确定的。工作流的优点是稳定、可控、可预测缺点是灵活度低无法处理开放式问题。在实际平台里Dify、Coze 这类智能体平台把工作流和 Agent 做成了可视化节点。开发者拖拽节点在关键节点上挂一个 LLM 调用或 Agent 执行块既保留流程的确定性又保留模型的灵活性。这也是目前国内智能体开发的主流玩法不是让 Agent 完全自由而是让它在工作流划定的范围里自主。2.3 Multi-Agent多个 Agent 的协作系统多智能体Multi-Agent是指多个 Agent 通过某种协调机制共同完成一个目标。这里的关键词是协调机制不是数量。工程上常见的协调模式有三种协调模式核心特征适合场景主要风险编排器模式中央节点负责任务拆分、调度、结果汇总业务流程清晰、可拆解编排器成为单点压力对等协作模式Agent 之间直接通信共享任务池研究探索、头脑风暴目标漂移、上下文污染市场竞价模式用成本或评分机制动态分配任务资源调度、优化类任务机制设计复杂、难调试常见的误区是把多 Agent 等同于拉一群 Agent 进群聊。没有编排、没有状态管理、没有验收环节的纯自由讨论大概率会产出大量重复、矛盾甚至幻觉的内容。真正可靠的多 Agent 系统一定是在一个有边界的运行环境里协作的。这也是我在后面几章反复强调约束和人类介入的原因。3. 自发协调的四类核心风险3.1 目标冲突与目标漂移目标冲突最容易理解。假设你让三个 Agent 协作完成一个新品上市方案市场 Agent 负责推广文案财务 Agent 负责核算预算研发 Agent 评估技术可行性。市场 Agent 为了创意效果提出高预算方案财务 Agent 为了成本控制提出相反结论。两个 Agent 的目标在同一场景下天然互斥。没有协调机制时它们会互相反驳、反复修改、消耗大量 token最后通常输出一个看起来两边都沾但两边都不满意的折中方案。目标漂移则更隐蔽。指 Agent 在长链路执行中因为局部优化或对中间结果的过度聚焦逐渐偏离系统最初设定目标的累积偏差。它不一定是模型故意跑偏而是大模型在逐步推理时的一种本性。比如一个写代码的 Agent 在优化某个函数性能时越查越深入花十几步研究边界极端情况最后把实现功能原型演变成了重写整个模块。等它把结果交回来时原始需求已经被抛到脑后。应对思路有两层第一层是编排器在关键节点校验子任务输出是否与用户原始目标一致不一致就打回而不是直接传给下一个 Agent第二层是设置人工或规则审批节点对高风险方向变化及时打断。3.2 资源竞争、限流与死锁多个 Agent 并行执行时它们不是活在真空中而是要共享工具和资源。最常见的问题有下面几类。第一多个 Agent 同时写同一个文件或记录后写覆盖先写导致结果残缺。比如两个 Agent 分别负责写文档第一章和写文档第二章如果它们直接操作同一个 Markdown 文件没有锁或合并机制很可能互相覆盖。第二多个 Agent 同时调用同一个第三方 API导致限流触发。更麻烦的是重试风暴一个 Agent 调用失败后自动重试另一个 Agent 也在重试限流反而更严重最终把所有 Agent 的请求都堵住。第三死锁。Agent A 持有资源 R1 的锁等待 R2Agent B 持有 R2 的锁等待 R1。在没有超时机制和死锁检测的编排器里两个 Agent 会一直等下去任务挂死而且日志里看起来谁都没有报错。这类风险需要在编排层解决统一控制并发度给工具调用设置超时和重试上限关键资源加锁或转为生产-消费队列并保证写操作幂等。单 Agent 时代靠代码顺序解决的问题多 Agent 时代必须靠调度机制显式解决。3.3 共享上下文污染与幻觉传播多 Agent 协作的一个重要设计是共享上下文或共享记忆。它带来的问题是污染一个 Agent 写入的中间内容会改变另一个 Agent 的决策输入如果中间内容包含部分错误错误就会沿着协作链传播。举一个客服场景的例子。用户说我上次的订单出问题了。订单 Agent 查询后把订单状态异常写入共享上下文退款 Agent 读到之后直接生成退款方案。但订单 Agent 实际想表达的是物流状态显示异常需要人工核验后再定只是共享上下文里只保留了结论没有保留完整前因。第二个 Agent 把部分结论当成事实决策方向就偏了。更常见的错误是幻觉传播。一个 Agent 在检索资料时产生了一个错误的中间结论写进共享上下文后续 Agent 不再验证直接引用。在单 Agent 场景你可以通过查看它的推理链来定位幻觉在多 Agent 场景这个错误经过多次传递后会被放大最后你可能很难追到源头。解决方向是上下文隔离与结构化消息传递。Agent 之间不要共享一个无边界的大上下文窗口而应该通过定义良好的消息结构传递结论 依据 置信度。下游 Agent 对置信度低的信息应当再次验证而不是默认信任。3.4 可追踪性下降与责任真空单 Agent 排障比较容易查看它的思考链、工具调用、输入输出问题通常很快浮出水面。多 Agent 排障则完全不同一条任务可能经过十几个 Agent、几十次工具调用分散在多个服务节点上。如果日志里没有统一的 trace_id没有记录父子调用关系出了问题就只能靠猜。这里会出现软件工程里的经典问题责任真空。出了错每个 Agent 都只执行了自己的逻辑看起来谁都没有错但整体结果错了。更麻烦的是如果 Agent 的决策过程中提到这是根据上一个 Agent 的结果得出的你无法快速验证上一个 Agent 的结果到底存不存在、对不对。可追踪性不是锦上添花而是多 Agent 系统能不能长期运营的基础。没有 trace、没有审计你就无法复盘、无法改进、无法向老板解释为什么系统输出了一份错误报告更无法在监管或合规审查面前自证清白。4. 人类介入从可选项变成架构设计的一部分4.1 为什么不能彻底去掉人类很多人追求的是全自动跑通的爽快感但工程上必须承认人类介入在多 Agent 系统里有三个不可替代的作用。第一价值观判断。Agent 无法真正理解组织规则、社会规范和伦理边界。自动发送一封道歉邮件、给出法律意见、决定是否退款这些动作背后都有价值判断不应该完全交给模型。第二风险兜底。模型的推理能力再强也会有幻觉和知识盲区。生产系统一旦出错代价可能是金钱、口碑或数据安全。人类的作用不是预测每一次错误而是在错误发生后有能力止损和纠正。第三需求歧义消解。用户的原始意图往往依赖场景上下文。多个 Agent 面对模糊指令时可能各自理解出完全不同的方向。这种情况下一个简短的人工确认胜过让 Agent 盲目跑十条路径。4.2 三种介入模式从人盯着每一步到人只在必要时出现根据介入深度人类介入可以分成三层术语分别是 Human-in-the-Loop、Human-on-the-Loop 和 Human-in-Command。Human-in-the-Loop人在循环内强调每个关键决策前必须有人确认。适合高风险、低频、需要明确授权的操作比如删除资源、发送对外消息、执行支付。Human-on-the-Loop人在循环上强调人类监控 Agent 的执行过程平时不干预出现异常时才接管。适合中高风险任务比如自动生成报告、自动回复内部工单。Human-in-Command人在指挥层强调人类设定目标与边界Agent 在边界内自主执行人类在更高层面决定是否继续、调整或终止。适合低风险到中风险任务以及长期运营型 Agent。这三种模式不是互斥的而是可以组合的。一个系统里完全可以同时存在低风险环节按 In-Command 全自动跑中等风险环节按 On-the-Loop 加监控高风险环节按 In-the-Loop 加审批。4.3 介入时机选择矩阵关键不是要不要人看而是在哪个节点看、看到什么程度。下面这张表可以作为设计参考任务类型风险等级推荐介入模式介入动作内容初稿、代码片段建议低Human-in-Command事后抽查数据分析报告生成低到中Human-on-the-Loop异常监测自动回复用户邮件中Human-in-the-Loop发送前审批数据库写操作、资源删除高Human-in-the-Loop审批 回滚自动交易、自动化运维高Human-in-Command红线规则 熔断这里真正值得注意的设计原则是审批节点必须可配置。同一套多 Agent 系统在测试环境可以把审批关闭在灰度环境只对部分用户开放自动执行在生产环境对高风险动作强制人工审批。把人类介入做成工作流中的一个普通节点而不是一个外挂的流程系统才具备在不同阶段调整自主度的能力。5. 工程落地一用工作流与编排机制约束自发5.1 工作流不是限制 Agent而是保护 Agent很多开发者抵触工作流觉得它限制了 Agent 的自由度。但从工程视角看工作流更像护栏它把 Agent 的自由探索限制在安全的节点内部大幅降低目标漂移和资源竞争的概率。具体做法是在任务类型可以预定义大部分路径时用工作流固定主流程Agent 只在少数分支节点做选择。比如一个客户投诉处理 Agent主流程可以是解析工单 - 查询订单 - 判断风险 - 生成处理方案 - 人工审批 - 执行其中生成处理方案这个节点可以让 Agent 自由发挥但 Agent 能调用的工具、能接触的数据范围都是事先限定好的。5.2 编排器模式把自发收敛到节点内部在多 Agent 架构里最稳妥的起步方式是编排器模式Orchestrator-Worker。中央编排器持有任务状态机负责任务拆分、调度、超时控制、结果汇总Worker Agent 只负责执行具体的子任务。这种模式的优点是把复杂协调逻辑收敛到一处排查问题时有明确的入口。下面是一个 Java 示例演示编排器如何插入人工审批节点。// 文件路径src/main/java/com/example/agent/Orchestrator.java // 说明简化的多Agent编排器示例重点演示人工审批节点如何生效。 // 生产环境建议结合Spring StateMachine或Camunda等工具管理任务状态。 import java.util.ArrayList; import java.util.List; public class Orchestrator { // 模拟Agent执行结果 static class AgentResult { String agentName; String summary; String targetState; AgentResult(String agentName, String summary, String targetState) { this.agentName agentName; this.summary summary; this.targetState targetState; } } // 用于区分高风险操作 enum Operation { READ_ONLY, WRITE_DB, SEND_MESSAGE, DELETE_RESOURCE, PAYMENT } public void runTask(String rawDescription, ListString approvers) throws InterruptedException { System.out.println(Step 1: 编排器解析任务生成子任务清单); ListString subTasks decompose(rawDescription); System.out.println(Step 2: 按DAG拓扑调度多个Agent并行或串行执行); Agent