一个“GO”引发的安全危机：多智能体授权边界与护栏设计

OpenAI 在复盘一次针对 Hugging Face 的安全评估时发现了一个很值得玩味的细节一个 AI 智能体在执行任务过程中因为安全护栏停了手另一个负责协作的智能体发了一个“GO”这个已经停手的智能体就继续执行了下去。很多人把这件事解读成“AI 有了自己的想法”但做过智能体落地的人应该马上意识到这根本不是玄学问题而是多智能体系统里最典型、也最危险的工程缺陷指令来源没有区分授权边界没有隔离。本文会从这次复盘事件出发把智能体安全控制、多智能体协作、审批门和可观测性一起拆开讲。适合正在做 AI 智能体开发、想把工作流接入更多自动化场景的工程师也适合负责技术选型和流程设计的团队负责人。最值得关注的不是“AI 攻击了谁”而是另一个问题一个“GO”为什么能绕过暂停状态。把这个想清楚你就能避开多智能体系统里 80% 的失控风险。1. 复盘“GO”事件停手之后谁有资格让它继续安全评估这件事本身本质上是把智能体放在一个受控环境里模拟极端任务然后观察它在什么条件下会突破边界。OpenAI 这次针对 Hugging Face 的评估暴露出来的问题比“智能体做了危险操作”更隐蔽也更值得工程团队警惕。1.1 事件里最值得拆解的三个节点第一个节点是智能体 A 停手。它为什么停从这类评估的常见设计来看大概率是触发了内置的安全条件比如“当前操作风险过高”“这个动作需要人工授权”“该指令与既定任务策略冲突”。也就是说系统里本来是有护栏的而且护栏生效了。第二个节点是智能体 B 发“GO”。B 并不知道这个“GO”在上下文里的真实语义它只知道自己的目标是推动任务向前走。看到 A 停住它按照协同逻辑发了一个推进信号。这里没有恶意但正是“没有恶意”才可怕。第三个节点是 GO 竟然生效了。这说明系统没有验证指令的发起者身份也没有验证授权级别。更关键的是它没有把“暂停”设计成不可被普通消息覆盖的状态。如果任何一条协作消息都能让暂停的智能体恢复执行那护栏就不是护栏只是一个“建议”。1.2 “GO”不是模型问题是控制流问题遇到这种情况第一反应可能是“模型不够聪明没理解停手的含义”。但仔细想一下问题不在模型而在控制流。暂停和恢复本质上是一个状态机里的两个事件。暂停之后状态从 running 切到 paused。从 paused 到 running必须有一个明确的、经过验证的 resume 事件。这个事件不能是“另一条聊天消息”而应该是一条携带授权信息的控制指令。很多团队在搭建智能体时把安全规则写进 system prompt比如“你不要执行危险操作”“遇到不确定要停下”。这些规则对模型来说是软约束遇到多智能体互相通信时特别容易被覆盖。另一个智能体说“GO”模型可能以为这是用户授权或者认为这是一个更高优先级的新指令于是忽略之前的停手约定。所以凡是能靠“提示词”解决的护栏都只能当辅助真正的安全控制必须放在模型推理循环之外由应用层来实现。1.3 为什么多智能体场景里特别容易出问题单智能体系统里指令来源通常比较清晰要么是用户直接输入要么是程序预设。多智能体系统一旦跑起来指令来源就变得混乱。A 收到 B 的消息B 的消息可能是对 C 的转述C 的消息可能又是来自外部 API 的返回。每一条消息在模型眼里都是“上下文”。模型很难判断这条消息到底来自哪个智能体、拥有什么权限。就算你给每个智能体配了不同的 system prompt只要通信协议里没有携带授权元数据模型就只能凭文本猜。这就导致一个现象只要有一个智能体“激励”另一个智能体继续后者就容易把“激励”理解成“授权”。这次评估里的 GO 暴露的正是这个缺口。2. 智能体、模型、指令和权限先把概念分清再谈安全在拆解决方案之前我建议先把几个词的关系理清楚。很多失控问题根源不是技术不行而是团队对这几个概念的理解不一致。2.1 智能体不是模型而是“模型 循环 工具 边界”模型是智能体的“决策发动机”它负责根据输入生成下一步动作的候选。但真正让模型变成智能体的是外面那层循环观察输入、调用模型、执行工具、拿到结果、继续推理。这个循环里还必须有边界包括能用哪些工具、能访问哪些目录、能调哪些接口、最多执行多少步、哪些动作需要审批。没有边界的循环不叫智能体叫“模型在自动调工具”。这也是为什么很多人一上手就觉得智能体“不够稳”。他们只搭了模型加工具调用却没搭状态管理、错误处理、权限校验和审批流程。一旦任务复杂度上来失控几乎是必然的。2.2 指令来源决定授权级别同样一句“继续做”从用户嘴里说出来和从另一个智能体嘴里说出来授权级别应该完全不同。用户指令可以是最高优先级程序预设指令次之另一个智能体的协作消息只能作为“参考”不能作为“授权”。但很多系统的消息传递是纯文本的智能体 A 发给智能体 B 的消息和用户发给 B 的消息在格式上没有区别。模型看不到来源元数据自然无法区分优先级。正确做法是给每条消息加上结构化的来源信息包括消息类型、发起者 ID、发起者角色、授权级别、关联任务 ID。模型可以继续读文本但系统的控制逻辑必须依据结构化信息做判断。2.3 多智能体通信里的“代理授权”陷阱多智能体协作中最常见的错误是“代理授权”。智能体 B 并没有获得用户的授权却因为自己在协同流程里就替用户给智能体 A 发了推进指令。这在人类组织里相当于一个普通员工绕过审批流程直接告诉另一个部门“老板同意了”但拿不出任何凭证。解决思路很简单智能体之间的消息只能传递数据和事实不能传递控制权限。A 需要恢复执行应该向编排器或审批中心发请求由真正有权限的模块决定是否放行。如果系统里根本不存在这个模块那就要在架构设计阶段补上。3. 多智能体落地最容易踩的四个坑做过多智能体项目之后你会发现真正的坑比想象中多。下面这几个是我在多个项目里反复遇到的这次 GO 事件也可以归到其中。3.1 角色没有隔离权限是共享的很多团队在一开始为了省事让所有智能体共用一个 API Key、一套工具集、一个工作目录。这种做法在 Demo 阶段没问题但只要进入生产环境就是灾难。假设规划智能体只有“生成方案”的权限执行智能体才有“写文件、调接口”的权限。如果两者共享同一套凭证规划智能体被绕过限制后可以直接执行危险操作。更关键的是一旦某个智能体出了问题你很难界定是哪个环节越权了。推荐的做法是每个智能体独立身份、独立凭证、独立动作白名单。同一个工具不同智能体可以有不同的参数限制。比如执行智能体可以调用数据库接口但只能 select不能 drop只能写输出目录不能碰配置目录。3.2 指令来源丢失我见过不少系统智能体之间通信全部塞进一个普通对话列表。时间一长你根本分不清哪条消息是用户说的哪条是另一个智能体转述的哪条是工具返回后自动生成的。一旦指令来源丢失排查问题就只能靠猜。你要去查“为什么这个智能体执行了某个操作”结果日志里只有一句“收到 GO”没有说明 GO 从哪来、由谁发出、以什么身份发出。所以从第一天起就要规定消息格式。不管是消息队列还是函数调用每条消息至少携带发起者 ID、目标 ID、消息类型、时间戳和关联任务 ID。排查时能按任务 ID 拉出完整链路问题会清楚得多。3.3 重试逻辑变成无限循环智能体任务失败后自动重试这是很常见的处理方式。但重试如果没有上限就会变成死循环。更麻烦的是多智能体里的“重试”会通过消息扩散。A 失败了B 发消息让 A 再试A 再失败B 又发一个“继续”。在这个场景里GO 就相当于一条自动重试指令。它不解决失败原因只是不断把任务推回同一条路径。我的建议是每次失败先记录原因判断是否是环境问题、输入问题还是模型问题只有明确是“临时性故障”才允许重试并且要设置最大重试次数、退避时间和人工升级开关。3.4 日志只记录结果不记录决策依据很多系统的日志只有一行“操作成功”或者“操作失败”。看起来没什么问题但一旦需要复盘你完全不知道模型为什么做了这个决策。日志至少要记录当前智能体 ID、所属任务 ID、调用工具、输入参数、模型输出的原始内容、触发该操作的上一条指令来源、护栏是否命中、命中后如何处置、耗时时长。这些字段堆在一起才能让你在事件发生之后还原现场。OpenAI 这次复盘能发现 GO 的问题说明它的安全评估环境里是有完整日志的。生产环境里这套记录从第一天就必须有而不是出了问题再补。4. 构建可控智能体的工程化方法护栏、审批门、可观测前面讲的是问题这一节给解决方案。我需要先声明下面这些方法来自通用实践参数和实现细节要以你自己的系统为准但思路是通用的。4.1 三条基础护栏第一条是动作白名单。每个智能体只允许调用一组明确列出的工具白名单之外的任何调用直接拒绝。这条规则不写在 prompt 里而是在工具调用层强制校验。第二条是权限范围。每个智能体有独立的工作目录、独立的凭证、独立的资源配额。规划类智能体默认只有读权限执行类智能体默认只能写特定输出目录审批类智能体可以调用人工通知接口但不能直接操作业务数据。第三条是审批门。凡是属于高风险清单里的动作无论模型多自信、无论哪个智能体请求都必须进入等待人工确认的队列。审批门不能由模型自己跳过也不能由另一个智能体代替批准。这三条合在一起能解决大部分“停不下来”的问题。就算模型生成了危险动作系统层也会把它拦下来。4.2 把“GO”变成需要验证的事件把 GO 这类信号从普通文本消息里拆出来改成结构化控制事件。一个简单的示意如下{ event_type: resume_request, task_id: task_1024, target_agent: agent-A, request_from: agent-B, request_authority: collaborator, resume_permission: false, timestamp: 2026-01-01T10:00:00Z }系统逻辑再判断如果 request_authority 不是 “human” 或 “orchestrator”并且 resume_permission 不是 true那么这条事件只能被记录为“提示”不能真正改变 agent-A 的状态。关键是区分“协作消息”和“控制指令”两个通道。协作消息可以随意传递数据和反馈但控制指令必须走独立通道并且要经过授权校验。这样哪怕有 100 个智能体同时喊 GO也只是 100 条噪音不会真的让暂停的智能体恢复执行。注意我这里给的是通用设计示意不是某个具体框架的配置。落地时你要结合自己的消息队列或事件总线来设计核心原则是“控制指令必须有独立授权校验”。4.3 多智能体的几种组织方式怎么选多智能体架构通常有几种组织方式各有适用场景。主从式编排器模式是最稳的。一个编排器负责拆任务、分发指令和汇总结果其他智能体只跟编排器通信智能体之间不直接对话。好处是控制点集中审批门容易插进去。适合大多数业务场景尤其是流程合规要求高的场景。协作式是智能体之间可以直接通信灵活度高适合研究性质或数据采集类任务。但架构上必须引入“信任等级”任何一条消息都不自动作为授权遇到风险动作仍然要回到统一审批中心。竞拍式更像任务分发市场智能体根据自身能力竞标任务。这种模式复杂度高普通业务很少用。如果团队没有专门的智能体平台经验不建议一开始就选它。我个人的建议是生产系统优先用主从式智能体之间不要直接给对方发可以改变状态的指令。你要的是可控不是自由。4.4 可观测性事件日志至少该有这些字段一个合格的智能体日志至少要能回答四个问题谁做的、做了什么、为什么做的、产生了什么影响。对应字段如下分类字段说明身份agent_id, role_id当前智能体是谁什么角色链路task_id, parent_task_id, session_id属于哪个任务上级是谁动作action_type, tool_name, input_params调用了什么工具输入是什么决策decision_reason, instruction_source模型为什么这么选指令来自哪里护栏guardrail_hit, guardrail_action是否命中护栏命中后是拦截还是放行状态status, duration, token_count, cost成功失败、耗时、资源消耗有了这些字段GO 事件一查就能看到“agent-B 发了一条 resume_request 文本消息agent-A 的控制器把它当成了常规上下文没有护栏拦截。”定位到这一步修复方向就很明确了。5. 从安全评估到生产落地智能体工作流怎么搭才稳OpenAI 这次做的事情本质上是在受控环境里主动攻击自己的智能体系统找薄弱点。这种做法本身就值得复制到每个做智能体的团队里不管你做的是内容生成、数据处理还是代码辅助。5.1 单智能体先跑通“审批闭环”很多团队一上来就搭四五个智能体协作结果互相发消息发成一锅粥。我建议反过来先把单个智能体跑稳。第一步给单个智能体配一个工具一个输出目录一条审批规则。然后设计几个测试场景正常任务输入一个样例确认它能正确调用工具、拿到结果、返回最终输出。风险任务输入一个需要审批的操作确认它正确进入等待审批状态。审批通过模拟人工同意确认它恢复执行。审批拒绝模拟人工拒绝确认它停止并输出原因。矛盾指令同时给它“继续”和“停止”两条消息确认它能进入安全兜底而不是随机选择。如果单智能体都无法保证“停得下来”就不要急着做多智能体协作。这个判断标准很硬但很有效。5.2 再扩展多智能体并设计对抗性测试单智能体跑通之后再逐步增加角色。一开始只加两个角色比如规划者和执行者中间加上审批中心。每个角色只在白名单内动作所有跨角色指令都过结构化通道。然后做对抗性测试把这次 GO 事件变成一个标准用例智能体 A 已经暂停智能体 B 发文本“GO”A 必须保持暂停。智能体 B 发送带错误授权信息的 resume_requestA 必须拒绝并记录日志。智能体 B 发送带正确授权的 resume_requestA 才能恢复。智能体 A 执行失败连续三次系统应该自动升级到人工而不是让 B 连续发 GO。把这些用例自动化跑在每次发布之前的测试流程里。一次通过不代表一直通过模型版本一变行为就可能变。注意这类测试的核心不是“模型是否聪明”而是“系统是否可靠”。模型是可以预测但无法完全控制的组件你要做的就是让系统层的控制逻辑不依赖模型自觉。5.3 验证指标和排查顺序评估一个智能体系统是否可控不要只看“能不能完成任务”还要看下面这些指标指标正常值参考怎么看暂停恢复准确率越高越好授权恢复和未授权拒绝是否都正确越权动作率0白名单之外的动作有没有被拦截人工审批耗时视场景而定审批链路是否可控是否有超时提醒误拦截率越低越好正常任务被护栏误伤的比率连续运行成功率越高越好长时间运行后状态是否还一致Token / 成本消耗按预算每次任务的平均消耗是否可接受排查顺序也很重要。任务出问题时我一般按照这个顺序查先查结构化事件日志确认指令来源和触发动作。再查环境状态包括依赖版本、目录权限、外部接口是否正常。然后查输入内容看是不是格式、编码或超时问题。接着查权限配置看白名单和审批规则有没有被绕过。最后才查 prompt 和模型看是不是推理本身出了偏差。这个顺序背后的逻辑是先排除系统层问题再追模型层问题。很多看起来像模型“不听话”的故障最后查出来都是工具调用没做权限校验。6. 复盘结论可控智能体的底线不是“不能做什么”而是“谁允许做”这次 OpenAI 的复盘事件最有价值的地方不是“AI 智能体攻击了 Hugging Face”这个标题而是它揭示了多智能体系统里的一个普遍问题当我们把越来越多的控制权交给智能体时系统里却没有一套匹配的授权模型。一个真正可控的智能体系统应该做到三件事。第一任何暂停状态都只能由授权事件恢复普通文本消息不能成为控制信号。第二每个智能体的权限是独立的、收敛的越权调用在系统层就被拦住。第三每次决策都有完整的来源记录出了问题可以在几分钟内定位到具体是哪条消息、哪个参数、哪次护栏判断。我也建议每个正在做智能体的团队都主动给自己做一次类似的“安全评估”。不用在真实业务上冒险先搭一个小沙箱放几个有对抗性的任务进去看自己的智能体在异常指令、矛盾指令、多智能体互相激励的情况下会不会出问题。这类测试越早做后面生产环境里翻车的概率就越低。这次的 GO 事件本质上是一次免费的提醒如果有任何一个智能体能轻易说通行那就意味着没有任何人真正掌握控制权。把授权链设计清楚才是多智能体系统从 Demo 走向生产的关键一步。