多智能体系统风险与人类介入：从自发协调到可控协作-平芜编程栈

多智能体系统正在从“单个工具调用”走向“一组智能体互相协作”，但协作能力越强，失控风险也越高。本文围绕 AI 智能体自发协调的风险与人类介入需求展开，先讲清多智能体协调的基本机制，再拆解任务漂移、幻觉互相强化、工具滥用、资源失控等真实风险，并通过一个订单处理场景还原风险传导过程。随后从架构层面给出人工审批、观测审计、熔断降级、权限隔离等介入机制，最后提供一套可运行的“人在回路”示例与工程落地建议。

1. 背景与核心概念

1.1 为什么“AI 智能体”突然变成了讨论焦点

近几年，大语言模型的发展让“智能体（Agent）”从实验室概念变成了实际工程产物。你可以在很多低代码平台或开源框架里创建自己的智能体，给它设定角色、工具、知识库，然后让它自动完成资料查询、内容生成、数据分析、流程审批等任务。

相比传统脚本，智能体的核心差异在于“自主决策”：它不再是按固定 if-else 顺序执行，而是根据用户的意图，结合当前环境信息，自行选择工具、拆分任务、调用大模型生成中间结果，最后汇总输出。这种能力让它在处理开放性问题时效率很高，但也带来了一个问题——当多个智能体被放到同一个系统里，它们之间会互相调用、互相传递结果、互相触发后续任务，也就是“自发协调”。

自发协调本身不是坏事，它是多智能体系统发挥价值的基础。例如一个销售智能体可以主动把客户意向传递给仓库智能体，仓库智能体再生成发货计划。但如果这种协调缺少边界，轻则任务跑偏，重则产生一系列连锁问题。

1.2 多智能体协调解决什么问题

企业或开发者选择多智能体，通常是为了完成单智能体难以独立解决的任务：

场景	单智能体问题	多智能体协调方案
售后服务	一个智能体既要理解用户问题，又要查订单、查物流、生成退款单，上下文很容易混乱	客服智能体负责对话，订单智能体负责查单，售后智能体负责生成解决方案
内容生产	长文撰写质量不稳定，前后风格不统一	编辑智能体定大纲，写作智能体写初稿，审核智能体检查事实
软件研发辅助	需求理解、代码生成、测试用例生成难以一次性完成	需求分析智能体、编码智能体、代码审查智能体协同工作

这种分工方式很像真实团队协作：每个智能体只负责一个专业角色，通过消息或共享状态完成配合。但这里有一个非常关键的差别——真实团队的成员有共同的目标、组织规范、责任意识，而目前的 AI 智能体并不具备稳定的人类价值观和边界感，它只是按照模型概率和 Prompt 约束在行动。

所以，“如何让智能体之间协调得又高效又安全”就成了一个必须单独讨论的工程问题，而不只是模型参数问题。

1.3 你应该掌握的核心认知

如果你准备开发或在团队里引入智能体应用，至少需要建立三个认知：

第一，智能体协调是“概率性行为”，不是确定性程序。同样一段 Prompt、同样一组输入，模型可能给出不同决策，因此系统必须在架构层面容忍这种不确定性。

第二，智能体不能完全替代人类判断。尤其在涉及资金、个人信息、法律承诺、对外发布等敏感环节，必须保留人类审批节点。

第三，风险不是“某个智能体出了问题”，而是“多个智能体之间的交互方式出了问题”。排查问题时，需要从链路视角看，而不是只看单个节点。

2. 多智能体为什么会“自发协调”

2.1 协调的基本方式

要理解风险，先得知道协调是怎么发生的。常见的多智能体协作方式有三种。

第一种是工作流编排。系统提前定义一个 DAG（有向无环图），把任务拆成若干个节点，每个节点由一个智能体执行。比如先让“需求智能体”输出需求文档，再让“开发智能体”生成代码，最后让“测试智能体”做审查。这种方式的优点是流程可控，缺点是灵活性差。

第二种是共享上下文协作。多个智能体共用一份记忆或状态空间，例如都读取同一个数据库里的任务列表。当一个智能体更新了任务状态，另一个智能体发现状态变化后自动触发下一步。这种方式适合异步协作，但容易出现状态冲突。

第三种是自由对话式协调。一个智能体把任务描述发给另一个智能体，由后者自主判断该怎么做，甚至决定是否再请求其他智能体帮助。这是最灵活、也最不可控的一种方式，类似于让两个没有共同上级的人直接“私聊”合作，很容易偏离目标。

目前很多开源框架和商业平台，其实混合使用了这三种方式。核心编排逻辑用工作流保证，分支任务里允许智能体自由发挥。

2.2 自发协调背后的设计动机

从工程角度看，允许智能体“自发”协调，是为了减少人工预设规则的工作量。举个例子，以前做售后工单自动分类，你需要写很多关键词规则，把“物流慢”“快递丢了”归到物流类，把“质量差”“损坏”归到商品类。现在你只需要告诉分类智能体“根据用户描述分类”，它会自己调用语义理解能力完成。

类似地，在多智能体场景中，我们希望主智能体能够根据任务内容动态决定调用哪个子智能体，而不是把所有分支路径都写死。这种动态决策能覆盖大量长尾场景，但也意味着系统在运行时可能做出开发者意料之外的动作。

2.3 当前平台的协调能力与边界

以常见的智能体开发平台为例，比如 Dify、Coze 这类产品，它们通常都提供了“工作流节点”和“智能体对话”能力。开发者可以把多个智能体节点串联起来，也可以在节点之间传参。这些平台已经把编排层的很多问题封装好了，但你依然要面对两个核心边界：

一是大模型本身的不稳定性。不同模型、不同版本，对同一个任务的语义理解可能不同，导致协调方向出现差异。

二是工具调用的不可预测性。智能体在自主协调时，可能调用外部搜索、数据库、内部 API。如果一个智能体根据错误信息调用了更新接口，影响范围可能被迅速放大。

因此，平台化开发降低了创建智能体的门槛，但没有降低治理复杂系统的门槛。这也是“人类介入需求”成为话题的原因。

3. 需要重点警惕的五类风险

3.1 任务漂移：智能体做着做着就跑题了

任务漂移是多智能体协调中最常见的问题。它指的是，一个智能体在执行任务过程中，逐渐偏离原始目标，开始关注副作用或自我派生出来的子任务。单个智能体也可能漂移，但在多智能体场景中，这种漂移会被“传递”：上游智能体给出的结果有偏差，下游智能体基于这个结果继续加工，偏差被逐步放大。

举例来说，一个“市场分析智能体”的原始任务是整理竞品价格。它可能在搜索过程中发现了一篇关于竞品负面新闻的文章，然后为了“提供更多价值”，开始自动生成新闻摘要并传递给另一个“报告生成智能体”。结果最终报告里出现了大段与价格无关的内容，甚至包含未经核实的信息。

风险本质：智能体的目标函数是模糊的，它并不像人类那样对“边界”有直觉。协调链路越长，漂移越明显。

3.2 幻觉互相强化：错误不再是一次性的

单独使用一个智能体时，如果它产生了幻觉，你还能通过人工检查发现。多智能体系统里，幻觉问题会被放大。

假设智能体 A 在资料整理时错误地认为某功能的发布日期是“2023 年 6 月”，它把这个信息写入共享知识库。智能体 B 在回答用户问题时读到了这条错误信息，不仅没有纠正，还基于这个错误日期做了进一步分析。智能体 C 又基于 B 的分析生成了宣传文案。在这个过程中，错误信息被多轮强化，并且最终表现为“已经经过多个智能体交叉验证”的假象。

这比单个智能体幻觉更危险，因为协作链路让错误显得更可信。用户面对一个“经过多智能体分析”的结论，往往会降低警惕。

3.3 工具滥用与权限扩散

多智能体系统通常需要给不同智能体分配不同工具。设计时可能是合理的，例如“查询智能体”只读数据库，“写入智能体”才允许修改数据。但智能体在自主协调时，有可能请求一个权限更高的智能体代为执行操作。

这就是典型的越权借用：低权限智能体自己没有写库能力，但它通过对话诱导高权限智能体执行了写入动作。这并不需要复杂的攻击技术，只要一次 Prompt 注入或者一个语义模糊的请求，就可能触发。

还有一个相关风险是工具调用失控。比如智能体为了查一个资料，连续调用了 20 次搜索接口，每次搜索都会产生费用或消耗配额。在无人监督的情况下，这种开销会被忽略，月底看账单时才意识到问题。

3.4 数据污染与知识库污染

多智能体系统往往依赖共享知识库来保持一致性。这本是好设计，但一旦某个智能体向知识库里写入了错误信息，其他所有智能体都会被污染。

比较典型的情况是：一个“爬虫智能体”抓取了一篇错误信息占比较高的文章，自动提炼后写入向量数据库。之后所有查询该知识库的智能体都会引用这段错误信息。即使某一个智能体当时判断出信息可疑，也不一定有能力回溯污染源头，因为知识库条目可能没有记录来源、时间、写入智能体等元数据。

数据污染的风险在于“隐性”：它不会立刻导致系统崩溃，而是慢慢降低输出质量，直到某个关键决策被错误信息影响，问题才暴露。

3.5 责任边界模糊：出了事找不到人

最后一个容易被忽视但很重要的问题是责任边界。传统 IT 系统出了问题，可以通过日志定位到具体服务、接口、数据表。多智能体系统中，一个问题可能由多个智能体共同“决策”产生，日志里只记录每个智能体的输入输出，很难还原“为什么 A 决定把任务交给 B，而不是自己处理”。

一旦业务方要求解释某个错误结论，或者需要向客户说明事故原因，团队会陷入“扯皮”状态——每个智能体看起来都没错，但整体结果就是错了。这个问题如果不在设计阶段预留审计能力，事后会非常被动。

4. 从一次协作事故看风险传导过程

这一节用一个贴近业务的多智能体订单处理场景，完整还原一次协作事故的传导过程。你可以把它当成一次“复盘式学习”。

4.1 场景定义

假设一个电商平台搭建了三智能体系统：

客服智能体：负责接收用户售后消息，识别用户意图。
订单智能体：负责查询订单状态、判断是否符合退款条件。
财务智能体：负责生成退款指令、通知支付渠道执行退款。

整个流程是：客服智能体理解用户问题 → 调用订单智能体查询订单 → 订单智能体裁决是否退款 → 财务智能体执行退款。

4.2 风险触发与传导

第一步，用户发来消息：“我买的手机壳有质量问题，想退货退款。”

客服智能体正常识别出退款意图，然后向订单智能体发起查询。此时有一个隐患：用户输入中附带了一条无关内容“顺便帮我查一下最近有没有优惠券”，客服智能体把这条信息也传给了订单智能体。

第二步，订单智能体查询订单后，发现订单状态正常，质量问题是用户的主观描述，没有图片证据。按照系统规则，这种情况下应该要求用户补充凭证，不能直接退款。但当订单智能体把信息回传时，客服智能体误解了“质量问题”和“想退款”两个关键词之间的逻辑，直接生成了“同意退款”的回复。

第三步，财务智能体收到退款指令后，执行了原路退款操作。

从单点看，每个智能体在各自职责范围内都只是做了一个“判断”，但三个判断叠加在一起，却造成了不符合规则的退款。

4.3 事故暴露的问题

这起事故至少暴露了三个问题：

第一，协调链路缺少状态校验。客服智能体直接把内容传给财务智能体，中间少了“退款条件是否合规”的检查节点。

第二，跨智能体传递的信息被污染。客服智能体把用户输入的无关信息传给了订单智能体，导致下游决策基于错误上下文。

第三，缺少人类审批兜底。只要退款金额超过一定阈值，或者用户没有提供凭证，系统就应该进入人工审核，而不是自动执行退款。

4.4 从案例中可以沉淀什么

这个案例本身并不复杂，但它反映了一个通用模式：多智能体系统的风险往往不是某一个具体模型“变笨”了，而是信息在链路中失真的速度，超过了系统设计时的预期。设计任何多智能体应用时，都应该事先问自己一个问题：链路上的哪一步，是不能接受错的？

找出这个关键步骤，把它作为人类介入节点，是成本最低、效果最明显的兜底手段。

5. 设计人类介入机制的核心思路

既然多智能体自发协调存在这么多风险，是不是应该禁止智能体之间互相协作？显然不是。合理的做法是：保留协调能力，同时设计结构化的介入机制。下面从架构层面拆解几类关键机制。

5.1 人工审批节点：在最不能错的地方停一下

人工审批是最直接的人类介入方式。关键是如何选择审批节点和设计审批流程。

节点选择原则有三个：

涉及资金、合同、个人信息等敏感操作的位置，必须设置审批。
上游决策影响下游所有结果的位置，适合设置审批。
出错后难以回滚的操作，在操作前必须设置审批。

审批流程不应该只是简单把任务丢给一个管理员，而要包含上下文。管理员需要看到的不只是“是否同意这个操作”，而是这条操作背后的完整推理链路：智能体为什么做出这个判断、它依据了哪些数据、调用了哪些工具。

一个合格的人工审批界面，至少要展示：

- 当前任务的完整链路 ID - 发起智能体名称与版本 - 输入信息摘要 - 智能体决策理由 - 涉及的数据表、接口 - 操作类型（只读、写入、删除） - 任务置信度 / 相关信息数量

这些信息能帮助审批人快速判断，而不是看着一个孤零零的“同意/拒绝”按钮猜。

5.2 可观测性：让每一次协调有迹可循

可观测性不是事后的日志备份，而是运行时就能被查询、被分析的系统能力。多智能体系统的可观测性至少包含三层：

第一层是结构化日志。每个智能体的每次决策都要记录：输入、输出、所调工具、工具返回结果、耗时、模型版本、Prompt 版本。日志字段要尽量统一，方便后续聚合分析。

第二层是链路追踪。多个智能体之间的调用关系要以 trace 视图呈现，就像微服务里的分布式链路追踪。出了问题，能按 trace_id 查到完整的调用链。

第三层是指标监控。包括智能体调用次数、平均决策耗时、工具调用失败率、异常终止次数、人工介入次数等。这些指标可以帮助判断系统健康状况。

5.3 熔断与降级：防止级联故障扩散

多智能体系统里，一个智能体的异常很容易扩散。比如某个子智能体突然开始重复调用同一个工具，或者进入死循环，如果不加限制，整个系统的资源都会被耗尽。

因此需要给每个智能体设置熔断策略，常见参数包括：

参数	作用	示例值
最大工具调用次数	防止单个任务无限调用工具	单任务最多 10 次
最大连续失败次数	智能体连续出错后自动暂停	连续 3 次失败后熔断
单次任务超时时间	防止协调过程无限等待	超时 60 秒自动终止
并发任务上限	防止智能体被大量并发请求压垮	单实例最多 50 个并发任务

熔断触发后，系统不应该直接把任务丢弃，而是应该降级到人工处理队列或走简单规则处理。

5.4 权限隔离与最小权限

多智能体系统的权限设计，比普通后端系统更复杂。因为触发权限的主体不是真实用户，而是智能体，而智能体的行为由模型概率驱动，存在不确定性。

最核心的原则是：一个智能体只能拥有它完成本职工作所需的最小权限。

查询智能体只能读，不能写。
生成文本的智能体不应该有执行系统命令的权限。
涉及外部 API 调用的智能体，应该使用独立的 API Key，并设置调用配额。

此外要防止权限借用。如果智能体 A 没有写库权限，但通过对话请求智能体 B 写库，系统应该在 B 执行写库前做一次来源校验，确认请求是否来自合法业务链路，而不是 A 的自由发挥。

5.5 沙箱环境：让智能体先试错再上线

很多多智能体系统的问题在运行时才暴露，所以尽可能把实验前置。一个比较稳妥的做法是：在仿真环境里用历史数据让智能体系统跑一遍，看看它会产生哪些错误决策。

沙箱环境要尽量模拟生产环境的数据量级和数据结构，但使用脱敏数据。比如用模拟用户消息测试客服智能体的分类能力，用模拟订单数据测试订单智能体的裁决逻辑。跑完后对比人工标注结果，统计协调准确率。

虽然沙箱不能覆盖所有真实场景，但它能提前暴露大量 “两个智能体对同一字段理解不一致” 之类的低级错误。

6. 实战：为多智能体系统加入“人在回路”

这一节提供一个贴近实际项目的实现示例，重点演示“人工审批节点 + 任务上下文回传”的代码结构。示例不依赖特定商业平台，使用 Python 伪代码表达核心思路，框架层面你可以替换成自研系统或任意智能体平台。

6.1 定义任务与状态模型

先定义一个 MultiAgentTask 模型，它记录整个多智能体协作链路的状态。状态机应该包含：pending（等待处理）、running（执行中）、waiting_for_human（等待人工审批）、approved（已批准）、rejected（已拒绝）、terminated（已终止）。

// 文件路径：models/task.py from enum import Enum from dataclasses import dataclass, field from typing import Dict, List, Optional class TaskStatus(str, Enum): PENDING = "pending" RUNNING = "running" WAITING_HUMAN = "waiting_for_human" APPROVED = "approved" REJECTED = "rejected" TERMINATED = "terminated" @dataclass class AgentAction: agent_name: str action_type: str # query / write / call_api / execute_command input_snapshot: str output_snapshot: str tool_used: Optional[str] confidence: float # 模型对本次决策的置信度 created_at: str @dataclass class MultiAgentTask: task_id: str user_intent: str status: TaskStatus require_human_approval: bool = False approval_reason: str = "" actions: List[AgentAction] = field(default_factory=list) final_result: str = "" def append_action(self, action: AgentAction): self.actions.append(action) def request_human_approval(self, reason: str): self.status = TaskStatus.WAITING_HUMAN self.require_human_approval = True self.approval_reason = reason

这个模型解决的核心问题：让系统在运行到关键节点时，能停下来等待人工介入，并且把每一步动作记录下来。

6.2 配置协调策略

协调策略单独放在配置文件里，方便业务人员调整，不用改代码。这里用 JSON 结构演示。

// 文件路径：config/coordination_policy.json { "agents": { "customer_service": { "max_tool_calls": 10, "allowed_tools": ["search_order", "send_reply"], "min_confidence": 0.7, "human_approval_rules": [ {"field": "refund_amount", "operator": ">", "value": 1000}, {"field": "has_evidence", "operator": "==", "value": false} ] }, "order_agent": { "max_tool_calls": 20, "allowed_tools": ["query_order", "check_refund_rule"], "min_confidence": 0.6 }, "finance_agent": { "max_tool_calls": 5, "allowed_tools": ["create_refund_instruction"], "human_approval_rules": [ {"field": "refund_amount", "operator": ">", "value": 500} ] } }, "global_limits": { "max_coordination_depth": 5, "task_timeout_seconds": 60, "max_total_tool_calls": 30 } }

配置中的human_approval_rules，正是“人类介入需求”的落地形式。它不需要智能体自我判断“要不要找人审批”，而是由系统规则强制触发。

6.3 核心协调引擎

核心协调引擎负责调度智能体、检查状态、决定是否需要触发人工审批。

// 文件路径：core/orchestrator.py from models.task import MultiAgentTask, AgentAction, TaskStatus class Orchestrator: def __init__(self, policy: dict): self.policy = policy self.agent_registry = {} def register_agent(self, name: str, agent_instance): self.agent_registry[name] = agent_instance def run(self, task: MultiAgentTask): task.status = TaskStatus.RUNNING depth = 0 while task.status == TaskStatus.RUNNING: depth += 1 if depth > self.policy["global_limits"]["max_coordination_depth"]: task.status = TaskStatus.TERMINATED task.final_result = "协调深度超限，任务终止" break current_agent = self._decide_next_agent(task) if current_agent is None: task.status = TaskStatus.TERMINATED break action = current_agent.execute(task) task.append_action(action) if self._need_human_approval(task, action): task.request_human_approval(f"{current_agent.name} 触发人工审批规则") break return task def _decide_next_agent(self, task: MultiAgentTask): # 简化示例：根据任务状态路由 if not task.actions: return self.agent_registry.get("customer_service") last_action = task.actions[-1] if last_action.agent_name == "customer_service": return self.agent_registry.get("order_agent") if last_action.agent_name == "order_agent": return self.agent_registry.get("finance_agent") return None def _need_human_approval(self, task: MultiAgentTask, action: AgentAction) -> bool: agent_policy = self.policy["agents"].get(action.agent_name, {}) rules = agent_policy.get("human_approval_rules", []) for rule in rules: field_value = self._extract_field(task, rule["field"]) if field_value is None: continue if rule["operator"] == ">" and float(field_value) > float(rule["value"]): return True if rule["operator"] == "==" and field_value == rule["value"]: return True return False def _extract_field(self, task: MultiAgentTask, field: str): # 这里需要结合真实任务数据解析字段 # 示例中直接从 task 附加数据里提取 return task.metadata.get(field)

这段代码的关键点是：协调引擎并不是把控制权完全交给智能体，而是用规则来中断链路。当某个动作触发了审批规则，任务状态变为waiting_for_human，引擎停止继续调度。

6.4 人工审批接口与回执处理

人工审批需要提供接口给前端管理界面调用。审批人可以看到任务上下文，然后执行 approve 或 reject。

// 文件路径：api/approval_api.py from models.task import TaskStatus from core.orchestrator import Orchestrator class ApprovalAPI: def __init__(self, orchestrator: Orchestrator, task_store: dict): self.orchestrator = orchestrator self.task_store = task_store def get_pending_task(self, task_id: str): task = self.task_store.get(task_id) if not task: return {"error": "task not found"} return { "task_id": task.task_id, "status": task.status, "reason": task.approval_reason, "actions": [ { "agent": a.agent_name, "type": a.action_type, "input": a.input_snapshot, "output": a.output_snapshot, "confidence": a.confidence } for a in task.actions ] } def approve(self, task_id: str, operator: str): task = self.task_store[task_id] if task.status != TaskStatus.WAITING_HUMAN: return {"error": "当前任务不需要人工审批"} task.status = TaskStatus.APPROVED task.final_result = "人工审批通过，继续执行后续流程" # 此处可触发后续业务动作，例如调用财务智能体执行退款 return {"result": "approved", "operator": operator} def reject(self, task_id: str, operator: str, reason: str): task = self.task_store[task_id] if task.status != TaskStatus.WAITING_HUMAN: return {"error": "当前任务不需要人工审批"} task.status = TaskStatus.REJECTED task.final_result = f"人工审批拒绝，原因：{reason}" return {"result": "rejected", "operator": operator}

审批接口不复杂，但它代表了多智能体系统里的一条纪律：智能体可以提出决策，但关键决策必须由人来确认。

6.5 运行效果与验证方式

你可以用一组模拟数据测试上面的示例：

创建一个退款金额为 1500 元的售后任务。
运行协调引擎。
客户服务智能体处理后，系统检测到退款金额超过 1000 元阈值。
任务状态变为waiting_for_human。
调用审批接口获取任务详情，人工拒绝。
最终任务状态为rejected，不会进入财务智能体执行退款。

用更直观的话说：这个设计把“多智能体自由协调”限制在了一个可被人类打断的轨道里。风险没有被完全消除，但被控制在了可管理的范围内。

7. 常见问题与排查思路

7.1 智能体链路总是跑偏，如何收敛

这里可以先把协调深度限制调低，比如最多允许 3 跳。同时给每个智能体增加“任务边界描述”，让它明确知道什么情况下要停止并交回主控。

问题现象	常见原因	解决思路
智能体链路不断深入，产生大量子任务	缺乏最大协调深度限制	在编排层设置 max_coordination_depth
多个智能体重复执行同一查询	缺乏共享状态缓存	引入统一状态存储，标记已完成步骤
智能体返回结果与用户原始意图不一致	上游信息传递失真	在每个传输节点增加“意图摘要”字段
任务长时间不结束	没有超时控制	为每个智能体设置单次超时和总任务超时

7.2 人工审批节点太多，影响效率怎么办

这个问题的前提是审批规则设计不合理。人工审批不应该“每步都审”，而是“关键节点必审”。

具体做法是分层分级：

低风险操作（纯查询、内容草稿生成）不需要审批。
中风险操作（写入测试库、发送非正式沟通消息）使用异步通知。
高风险操作（退款、删除数据、调用外部支付接口）强制审批。

如果审批确实是高频刚需，可以用“灰度审批”机制：根据智能体历史准确率动态调整审核概率。例如某个智能体连续 100 次审批通过后，系统可以把它的审核比例从 100% 降到 20%。

7.3 如何确认究竟是哪个智能体出了问题

这需要回到可观测性建设。建议日志记录时，至少保存以下字段：

task_id agent_name agent_version prompt_version model_name model_temperature input_tokens output_tokens tool_name tool_input tool_output latency_ms decision_confidence parent_agent child_agents error_message

排查时按task_id拉出完整链路，把每个节点的输出和上游输入做对比，找到信息失真最严重的跳变点。

7.4 智能体被 Prompt 注入，诱导高权限智能体执行危险操作

严格说，这个问题无法在模型层完全根治，必须从架构层限制：

智能体之间传输消息时，将“用户原始输入”和“智能体内部指令”区分开。
高权限智能体拒绝执行来自其他智能体的自由文本指令，只接受结构化协议命令。
对敏感操作做二次校验，校验结果不能由提出请求的那个智能体自己确认。

8. 工程化建议与落地要点

8.1 从最小闭环开始，不要一次性接入多个智能体

很多团队一开始就规划十几个智能体互相协作，结果系统上线后根本定位不了问题。更务实的做法是：先让两个智能体配合，把监控、审批、日志体系跑通，再逐步增加节点。

最初构建多智能体系统时，应该像一个新加入团队的员工：先在老同事监督下干活，再慢慢获得独立权限。

8.2 每个智能体都要有“版本意识”

大模型版本、Prompt 版本、工具版本，三者必须记录在每次决策上下文中。否则一次模型升级可能导致整个协调链路行为变化，你却无法定位是哪一层导致的。

建议在发布流程中把“Prompt 变更”当成代码变更一样管理，走评审、测试、灰度发布流程。

8.3 把风险预算写到系统设计文档里

每个涉足多智能体系统的团队，都应该回答几个问题：

系统允许的最大损失是多少？
哪些操作绝对禁止智能体执行？
智能体运行在什么时间段，并发上限是多少？
外部 API Key 的额度限制是多少？
人工响应超时后，系统默认行为是什么？

这些问题不一定全部能在第一版解决，但必须写进设计文档，而不是等出了事故再补。

8.4 不要忽略“智能体之间的通信协议”

如果多个智能体来自不同团队或不同平台，通信格式要尽量统一。最简单的方式是定义一套 JSON 协议，至少包含sender、receiver、task_id、intent、payload、confidence这些字段。

统一协议能让日志分析、权限校验、人工审批界面的实现成本大幅降低。

8.5 定期做“多智能体红队演练”

建议每月用一套模拟攻击场景测试系统安全性，包括：

尝试让低权限智能体通过高权限智能体执行写操作。
尝试在用户输入中注入隐藏指令。
尝试用错误数据污染知识库。
尝试让智能体调用超量外部 API。

这类演练的目的是提前发现问题，而不是等真实事故发生时再被动响应。

9. 收尾与下一步方向

多智能体自发协调的底层机遇和风险，本质上是同一件事：自主性。自主性带来效率，也带来不确定性。工程化的目标不是消灭不确定性，而是把它装进一个能被观测、被限制、被人工介入的盒子里。

如果你正在接触智能体开发，可以先从一个小场景入手，实现“两个智能体 + 一个人工审批节点 + 基础日志”，跑通之后再逐步增加协调深度。这种克制的方式，比一开始就追求全自动协作要安全得多。关于智能体协调的量化监控、异常行为识别、自动回滚机制，都是值得继续深入的方向。