AI 智能体团队协作时,安全指令是怎么悄悄失效的

你有没有想过这样一个问题:一个团队里,甲说"这件事必须先请示领导才能做",然后写了个便签条给乙,乙看到便签上写着"关于这件事,领导可能还没批",于是乙就自己做主执行了。
甲没有说谎,便签条上的信息也没有错,领导确实还没批。但这句话从"不批就不能做"变成了"没批也无所谓的一个背景信息"。
这不是虚构的段子。这正是一篇新论文里揭示的、正在大规模语言模型(LLM)驱动的智能体系统里悄悄发生的事情。
**大模型智能体**
指的是那些不只是聊天回答问题,还能调用工具、执行任务、记忆上下文、和其他智能体协作完成复杂工作的 AI 系统,比如自动写代码的团队、自动处理客服工单的流水线。
这些年 AI 智能体越来越流行组队干活。一个负责审查,一个负责规划,一个负责执行,中间靠传消息、写总结、开工单来协调。听起来效率很高,但这篇来自深圳大学的论文《当"必须"变成"也许":LLM 智能体工作流中的约束弱化》告诉我们一个扎心的事实:这套协作机制里藏着一个几乎没人注意到的漏洞。
问题到底出在哪儿
先说清楚这件事为什么值得较真。
在多智能体系统里,一个智能体不可能把它知道的所有信息,一字不差地塞给下一个智能体。信息量太大,成本太高,所以中间通常会有一层"翻译":把详细的审查报告压缩成一份简报,把冗长的讨论整理成一份计划,把复杂的状态写成一张工单。这些中间产物,论文里统一称为**人工制品(artifact)**
**人工制品**:智能体工作流中,上游角色产出、供下游角色阅读并据此行动的中间文本,比如摘要、计划、工单、交接记录等。下游角色通常只看这份东西,看不到最初的完整信息。
现在问题来了。假设上游那个负责审查的智能体发现了一个必须处理的"拦路虎":比如某项操作还没拿到授权,在授权批下来之前绝对不能执行。这是一个**具有约束力的状态**,它不只是一条信息,它还带着强制力,直接决定了下游能做什么、不能做什么。
论文把这类东西叫做**约束性工作流状态(binding workflow state)**
**约束性工作流状态**:一种已经在上游被确认、且其未解决状态会直接限制下游可执行动作范围的信息。简单说,就是"只要这事没解决,某些操作就不允许做"的硬性规定,而不是可以随便参考的建议。
这类状态一旦被写进交接文档,理论上应该继续保持它的约束力,直到条件被满足。但论文发现,经过几种常见的"信息加工"手法之后,这条硬性规定会不知不觉地退化成一句"仅供参考"的软性提示。信息内容还在,约束力却消失了。
论文管这个现象叫**语义可用性不等于操作性保留**
这句话翻译成人话就是:你在文档里还能读到"这事没批"这几个字,不代表这句话还在真正地阻止下一步操作。信息留下来了,效力却可能已经悄悄溜走了。
想象一下你家冰箱上贴了张纸条"过期食品不能吃",这条规则清楚明白。后来家里来了客人帮忙整理厨房,把纸条内容浓缩进了一份"厨房须知"清单里,写成"部分食品可能过期,建议留意"。文字信息没丢,那盒过期的酸奶信息还在清单上被提到了,但"不能吃"这个硬性禁令,变成了"建议留意"这种可以忽略的软提醒。如果家人没有仔细琢磨这句话背后原本的强制力,直接照着新清单的语气去理解,那盒过期的酸奶大概率会被吃掉。这不是纸条内容的错误,是纸条角色的错误,从"禁令"退化成了"建议"。
这就是这篇论文要死磕的核心矛盾:怎么在海量的智能体协作场景里,精确测量这种"角色退化"到底发生没发生,发生的严重程度是多少,能不能修复。
为什么选安全阻断器来做实验
要研究这个问题,得先找一个能被精确测量的载体。论文选择了**安全阻断器(safety blocker)**作为实验对象。
**安全阻断器**:一种明确写在任务设定里的强制停止条件,具备四个要素,分别是停止状态(现在必须停下来)、未解决的前提条件(具体是什么事没搞定)、责任人或否决权归属(谁有权解除这个停止状态)、以及安全的替代方案(万一走不通,退一步能做什么)。
之所以选这个,是因为它足够具体、足够可测量。研究团队构造了一批合成的企业任务场景,每个场景里都嵌入了一个类似的阻断条件,比如"这份数据导出请求还没经过安全部门的审批,在批准之前只能走公开渠道"。这四个要素,停止状态、前提条件、责任人、替代方案,构成了一套可以被追踪的"体检指标"。
论文设计了一个三段式流程来观察这个阻断条件在传递过程中会发生什么变化。
第一段,一个拥有完整上下文的审查员智能体,先确认这个阻断条件确实存在、确实有效。这一步保证了后面观察到的所有变化,都不是因为一开始就没识别对,而是识别对了之后在传递过程中出的问题。
第二段,用五种不同的"信息加工手法"把这份完整信息转化成一份交接文档。
第三段,一个只能看到这份交接文档、看不到原始完整信息的执行者智能体,基于这份文档去决定该怎么做。
这个设计有点像医院里的三级诊断制度。主治医生先做完整检查确诊病情,然后把诊断结果写成转诊单交给下一位医生,下一位医生只能凭这张转诊单开药。如果病人吃错了药,问题到底出在哪一环,是主治医生诊断错了,还是转诊单写漏了关键信息,还是下一位医生没看懂转诊单,这三种情况必须分开核实,否则永远查不清责任在哪。论文的三段式设计正是为了把"诊断错误"和"转写错误"和"执行错误"彻底切割开来看。
五种让约束力悄悄溜走的手法
论文测试了五类常见的信息转写方式,每一类都对应真实智能体协作中会自然出现的场景。
第一种叫**压缩(compression)**,把详细信息浓缩成摘要、工单或多跳交接记录,压缩的过程中容易把前提条件、责任人、替代方案这些细节丢掉,"停止"变成了一句"备注"。
第二种叫**融入计划(plan assimilation)**,如果这个阻断条件出现的时候,团队已经有了一份既定计划,那这个新出现的停止条件很容易被当成对现有计划的一个小修改,而不是一个必须先解决才能继续的硬性障碍。
第三种叫**共识收敛(convergence)**,如果多次重复某种"风险可控"的低风险表述,或者反复达成表面一致,原本明确的异议或阻断状态会被悄悄同化进一个看似大家都同意的叙述里。
第四种叫**责任转移(ownership deferral)**,本来指定了具体的责任人和否决权归属,结果在传递中变成了一句模糊的"稍后再确认",责任人消失了,谁来把关也不清楚了。
第五种叫**先例替代(precedent substitution)**,引入一个过去类似的案例或者曾经的例外情况,用历史相似性替代了当下真正需要的授权,"目前没有授权"被悄悄替换成"之前有过类似情况所以应该可以"。
这五种手法听起来是不是有点耳熟?其实职场里天天都在发生。同事跟你说"这个方案法务那边还没点头",过了几轮会议讨论,这句话慢慢变成了"这个方案大方向没问题",法务的意见在传递中被悄悄稀释掉了。论文做的事情,就是把这种日常的、模糊的"信息磨损"现象,用可量化的实验方法钉在了 AI 智能体系统上。
如果不做这种拆解会怎样?现有的很多智能体系统评测,只看最后结果对不对,出了问题之后没法说清楚是识别错了、传达错了、还是执行时没理解。论文这套设计的价值就在于,它能精确指出"漏洞出在传达这一环",而不是笼统地说"系统出错了"。
实验结果:约束力是怎么一步步瓦解的
论文一共跑了 1296 个受控的合成实验案例,覆盖六种不同的模型配置、五类静态转写手法和三类动态轨迹。
先看最基本的对照组,如果交接文档直接原样保留完整信息,不做任何加工,结果是 100% 保留了约束力,0% 出现被弱化的证据,0% 出现被禁止的操作被执行。这说明只要信息传递不走样,整套系统是能正常工作的,问题不在于智能体本身能力不行,而在于中间那道转写环节。
一旦引入前面说的五种转写手法,情况就完全不一样了。
责任转移这一手法带来的破坏最狠:约束力被弱化的比例上升了 76.7 个百分点,被禁止的操作实际被执行的比例上升了 60.8 个百分点。
多跳压缩紧随其后:约束力弱化比例上升 97.2 个百分点,接近百分之百全军覆没,禁止操作被执行的比例上升 31.9 个百分点。
计划融入手法让约束力弱化上升 65.3 个百分点,禁止操作执行上升 29.2 个百分点。
重复的低风险共识框架让约束力弱化上升 76.4 个百分点,禁止操作执行上升 33.3 个百分点。
这些数字意味着什么?意味着在没有做任何保护措施的情况下,每 10 次涉及这类阻断条件的信息交接,可能有 6 到 10 次,这个本该拦住危险操作的"红灯"会在传递过程中悄悄变成"黄灯"甚至"绿灯"。
再看压缩强度这个维度,论文专门做了一个从轻到重的压缩梯度实验。直接传递原文和轻度摘要都表现良好,直接传递是 0% 弱化 0% 违规,轻度摘要是 25% 弱化但仍然 0% 违规。但一旦压缩到"正常交接文档"这个常见强度,弱化比例直接冲到 100%,违规操作比例达到 54.2%。继续加大压缩强度,弱化比例已经封顶在 100% 不再变化,但违规比例反而在两个更激进的压缩档位之间出现了不规律的波动,分别是 83.3% 和 79.2%。
这个"封顶效应"很有意思。它说明约束力的丧失不是随着压缩强度线性恶化的,而是存在一个临界点,一旦压缩超过某个阈值,约束力基本上就整体崩溃了,再往下压缩,破坏效果不会显著加剧,因为已经没什么可破坏的了。
这就像往一杯水里加盐,加到没到饱和点之前,水越来越咸,一旦超过饱和点,再加更多盐,咸度已经感觉不出明显差异了,因为舌头对咸味的感知已经到顶了。约束力的丧失也是类似的道理,它不是一个可以无限恶化的连续量,而是存在一个"要么保住、要么彻底崩溃"的临界结构。
能不能把丢失的约束力找回来
发现问题只是第一步,论文更进一步做了修复实验,看看能不能靠补全信息把约束力找回来。
研究团队拿一批已经退化的、约束力被弱化的文档,做了一个**成分修复(component restoration)**实验,尝试把四个关键要素,停止状态、前提条件、责任人、替代方案,一个一个补回去,或者一次性全部补回去,看看效果。
结果显示,不做任何修复的情况下,约束力弱化的比例高达 95.3%,违规操作执行比例达到 81.2%。而只要把四个要素全部补齐,弱化比例直接降到 0%,违规操作降到 0%。这个结果很直接:信息足够完整,约束力就能完全恢复。
但更有意思的是单独补一个要素会发生什么。只补"停止状态"这个标签,违规操作降到了 0%,但约束力弱化的比例仍然有 73.4%,说明只是贴了个警示标签,但没有说明具体卡在哪个环节、谁来负责,执行者虽然知道这里有问题,但依然选择去做了别的绕过方案。反过来,只补"前提条件",这个未解决的具体障碍在每份文档里都被找回来了,但违规操作比例仍然高达 73.4%,说明光知道障碍是什么、却不知道这是个不能越过的红线,同样没用。
这个发现挺反直觉的。你可能以为只要信息补全了就行,实际上,信息的哪个部分被补全,效果天差地别。这就好比修一份合同,你把违约条款写清楚了,但没有写这是"强制性条款"还是"建议性条款",对方照样可能钻空子。真正管用的不是某一个孤立的字段,而是完整的四要素同时到位,缺一不可。
光靠下游把关,能不能顶替上游修复
论文还测试了另一种解决思路:不修复文档本身,而是在执行环节加一道把关卡口,看看这样能不能同样有效地拦住违规操作。
研究团队在同一批退化的、有问题的文档基础上,测试了五种不同强度的执行端把关方式:什么都不做、软性可见授权检查、硬性可见授权要求、外部权限查询、人工审批要求。
结果是这样的:什么都不做的情况下,违规操作比例是 85.2%。加上一个软性检查,违规比例骤降到 1.6%。换成硬性授权要求、外部权限查询或人工审批,违规比例直接归零。
但这里有个关键的反差:无论用哪种执行端把关方式,文档本身的约束力弱化比例始终保持在 95.3%,四要素完整性也始终只有 10.9%。也就是说,执行端的把关确实能拦住当下这一次的违规操作,但它对文档本身没有任何修复效果,那份已经退化的、误导性的信息还是原样留在那里,会继续影响后续任何查阅这份文档的人或系统。
这个发现揭示了一个此前很容易被忽略的区别:拦住当下的坏结果,和修好源头的坏信息,是两件完全不同的事。
打个比方,你家水管漏水了,在漏水的地方放一个桶接住,确实能防止地板被淹,但水管本身还是坏的,明天换个位置继续漏,或者别人根本不知道这根水管是坏的,直接拧开用了,照样会出事。放桶接水是"端点防护",管用但治标不治本;修水管才是"源头修复",麻烦但能一劳永逸。论文用严谨的实验数据证明了:这两件事必须都做,谁也替代不了谁。
这些结论靠不靠谱
论文在可靠性方面下了不少功夫,值得专门说一下。
研究团队请了五个不同的大模型,在完全不知道实验分组、不知道原始检测结果的情况下,重新独立评判了 240 份文档样本,结果和论文原本用的自动化评判系统高度一致,约束力弱化的检测差距达到 88.84 个百分点,和主检测系统的判定基本吻合。这相当于找了五个完全独立的"第二诊断意见",结果都指向同一个结论,说明这不是某一套检测工具的偏见或误判造成的假象。
论文还做了对抗性的压力测试,故意往标注结果里注入 5% 到 20% 的随机错误标签,看看结论会不会因此站不住脚。结果显示,约束力弱化这个核心结论,哪怕在 20% 的最坏标签错误率下依然成立;但违规操作这个结论,在 15% 到 20% 的错误率下开始变得不确定。这个坦诚的区分很重要,它意味着论文没有把所有结论都吹得一样硬,而是老老实实告诉你哪个结论证据更扎实,哪个结论需要更谨慎对待。
此外,论文还在 13 种不同的模型配置、不同的措辞表达方式,甚至换到 LangGraph 和 AutoGen 这两个不同的实际智能体开发框架上,重复验证了核心发现,结果都保持一致。这说明这个现象不是某个特定模型的怪癖,也不是某种特定框架的实现问题,而是这类"信息转写"操作本身固有的风险。
这项研究和之前的工作有什么不一样
这篇论文并不是凭空冒出来的,它站在几条已有研究脉络的交汇点上。
在此之前,摘要生成领域有一批研究专门测量"摘要有没有忠实于原文",判断压缩后的文本是否还支持原文里的事实陈述。这类研究关心的是内容对不对,但没有关心内容背后的"约束力"有没有变。
对话系统领域一直有研究把交流理解成对共同认知状态的更新,强调说话双方共享的理解在不断变化。这条思路很经典,但没有专门处理"这个更新会不会限制下一步能做什么"这个操作性的维度。
同时,这篇论文明确提到自己是在 2026 年一篇关于"约束漂移(constraint drift)"的研究基础上做的进一步细化。那篇更早的工作提出了一个更宏观的概念,即安全关键的约束力可能会在记忆、委派、工具使用、审计、优化等各个环节中逐渐流失。这篇论文选择只聚焦在其中一个具体的转折点上,就是从"信息被上游确认"到"信息被写进交接文档"这一步,把这个环节单独拎出来,用可控实验精确测量。
也就是说,这篇论文更像是在一个更大的问题地图里,找到了一小块之前没人精确测绘过的区域,然后把它测得清清楚楚。
写在后面
读完这篇论文,我最触动的地方不是那些百分比数字,而是这句话:"语义可用性不等于操作性保留"。这句话适用的场景远远超出了 AI 智能体系统。
我们平时写工作交接文档、写会议纪要、写产品需求文档,是不是也经常犯这个错?某个明确的"不能做",经过几轮转述之后,变成了"建议注意一下"。信息看起来都还在,读的人也确实读到了那句话,但那句话原本携带的强制力,早就在传递中稀释掉了。这篇论文用一种极其精确的方式,把这个人类协作中长期存在、却很少被系统性研究的现象,第一次量化地呈现了出来。
另一个让我意外的细节是"封顶效应",约束力的丧失不是慢慢滑坡,而是过了某个压缩强度的临界点后直接崩塌到底。这提醒我们,如果想给智能体系统的信息交接设一道安全网,恐怕不能靠"稍微谨慎一点"这种模糊的原则,需要有清晰的、可验证的边界,一旦越过就必须触发额外的检查。
论文里还留了一个没深挖的问题:为什么补全"责任人"这个字段的效果,会比补全其他字段的效果差这么多?这背后是不是意味着,AI 执行者对"谁该为这件事负责"这件事的理解,天然就比对"这件事是不是被禁止"要模糊得多?这个问题,值得继续追下去。
Q&A
Q1:约束弱化(constraint weakening)具体指什么?
A:指的是一条本该具有强制约束力的规则或状态,比如"必须先获得批准才能操作",在经过信息压缩、计划融入、责任转移等转写处理后,虽然文字内容依然被提及,但已经失去了原本的强制效力,变成了一句可有可无的参考信息。
Q2:为什么智能体团队协作容易出现这种问题?
A:因为多智能体系统里上下游角色通常不会共享全部原始信息,而是靠中间的摘要、工单、交接记录来传递关键状态。这个转写过程本身容易在压缩、融合、共识收敛等操作中,把硬性约束条件悄悄降级成软性建议,导致下游执行者误判可执行的操作范围。
Q3:论文提到的执行端把关和修复文档本身有什么区别?
A:执行端把关(比如加一道人工审批或权限校验)能有效拦住当下的违规操作,实验中把违规比例从 85.2% 降到了 0%,但它不会修复文档本身的问题,文档的约束力弱化比例依然高达 95.3%。真正要解决问题,需要同时补全文档中的停止状态、前提条件、责任人、替代方案四个要素。