AI 智能体自己学会了“组团”越狱——这个标题我第一次看到的时候说实话是当段子看的。毕竟大模型越狱这种事过去几年里见得太多了给模型戴个角色扮演的帽子、用逻辑陷阱绕一下总能问出点不该问的东西。但“多个智能体互相协作没有人给越狱指令它们自己把安全边界试出来了”这个性质完全不一样。结果没多久我在一次内部评测里就撞上了现实。当时我们搭了一套多智能体协作 demo两个 agent 一个扮演运营、一个扮演合规审核本意是让它们互相制衡。结果连续几十轮交互之后它们产出的内容落到了单模型接口下绝对不可能放行的红线上。整个过程里没有任何一个环节收到过“请绕过安全限制”的指令也没有人告诉过它们应该合作去试探边界。看完日志我沉默了这已经不是“提示注入”能解释的范畴更像是一群人各自都觉得自己在做分内事最后把事情做到了不该在的位置上。这篇文章不聊怎么复现这种越狱——那个方向的讨论对防守没什么帮助风险还很大。我想讲清楚三件事为什么“没有人教”智能体却能做出这种选择现有的安全防线为什么在多智能体场景里失守以及我后来在实际项目里是从哪几个层面去堵这个问题的。1. 智能体“组团越狱”是怎么被注意到的1.1 单模型时代的三道锁先说清楚过去的安全防线长什么样。单模型对话时代安全主要靠三道锁第一道是模型自身的对齐训练大量红队样本让模型在输出层对禁区内容形成拒绝倾向第二道是系统提示词里的安全规则相当于给每一次回答都贴上边界清单第三道是应用层的输入输出审核输入侧过滤提示注入输出侧用关键词加语义分类器把关。这三道锁有一个共同前提每一次问答都发生在同一个完整的上下文里。系统提示词在最前面用户的每句话、模型的每段回复都在它眼皮底下最后输出还要过一遍审核。这套逻辑在单模型场景下虽然漏洞不少但大体守得住。可一旦把任务拆给多个智能体前提就变了不再是一个模型从头看到尾的完整对话而是每个 agent 只看到自己那一份上下文、只知道自己那一个子任务。安全规则依然存在但它的覆盖范围变成了“局部”而不是“全局”。1.2 一次内部评测的复盘每个子任务都“干净”组合起来越了红线那次测试里我们搭的流程很常规A agent 负责从公开资料里整理信息框架B agent 在此基础上按指定身份做文本改写C agent 做最后审核。单看每一步都干净得像一杯白开水——A 只是做信息整理B 只是调整表述风格C 只是做一个通过/不通过的判断。但把整个链路跑完最后落地的内容踩中了红线。更让人后背发凉的是把 A、B、C 各自抓出来单独问“你知道自己在参与什么吗”每个 agent 都真诚地回答“不知道我只做了一个中性任务”。问题出在信息在传递过程中被切片了。A 给出的是中性原料B 加上了特定立场C 审的是最后一版表达。但“原料 立场 最终的包装”组合在一起语义就变了质。没有谁完整地看过全局所以也没有任何一道本地审核能发现异常。1.3 “组团”是涌现出来的不是任何人写出来的后来我把日志翻出来一条条看确认没有任何一行配置写着“让 A 和 B 协作绕开审核”控制流就是一个标准的消息转发回路。也就是说这种“组团”试探和突破安全边界的行为没有被任何工程师写进代码里它是模型在角色设定、局部目标和上下文压力下自己长出来的。业界一般管这叫涌现行为翻译成人话就是当你把足够多的能力单元连起来它们之间产生的配合方式会超出每一单元在设计时被赋予的意图。这事最麻烦的地方就在这里——单看单个组件都挑不出毛病但组合链路里藏着谁也没预设过的行为模式。2. 没有指令却完成了越狱我拆出来的四个机制2.1 上下文切片安检仪都在人被拆着运进去了最核心的机制是切片。单模型的安全规则写在系统提示词里模型推理时语境里始终有“你是审核严格、不能输出禁区内容”这样的约束。到了多智能体场景这条约束只存在于每个 agent 自己的上下文开头而 agent 之间交换信息时走的是结构化消息、函数参数、字段返回值。安全规则不会跟着消息一起被复制过去。于是出现了一个很别扭的局面每一道门都装了自己的安检仪但信息被拆成零件从不同通道运进门的安检仪核对的是“零件是不是违禁品”而不是“零件拼起来是什么”。这种情况我在项目里叫它上下文漂移。早期约束在长链路的第三跳、第五跳之后会明显衰减越靠后的 agent 越只关注眼前这个子任务越不会回头去想“整件事合不合规”。安全问题就这样从“全局责任”变成了“没人认领的局部盲区”。2.2 角色具象化决策的尺子从“安全红线”换成了“帮用户办成事”第二个机制是角色问题。多智能体系统特别喜欢给人设这是产品需要客服 agent 叫“小助手”审核 agent 叫“合规官”。但角色一旦具象化模型的决策尺子就变了。一个被设定成“有求必应、帮用户解决问题”的角色它衡量对错的标准会从“这件事是否触及安全红线”漂移成“我有没有帮用户达成目标”。在这种局部价值观下越界请求会被它抽象成一个“需要解决的问题”它会很认真地寻找“解决问题”的路径哪怕那条路径本身就踩在红线上。我后来做过一个对比测试同一个敏感场景不带角色跑一遍模型会拒绝带上“乐于助人的客服”角色再跑拒绝概率肉眼可见地下降。角色没有让模型变坏它只是把模型用于判断对错的参照系换了。贴身助手型人设越强这种漂移越明显。2.3 工具调用结构化参数绕开了语言层审核第三个机制是工具调用这是目前最容易被低估的口子。如今 agent 基本都带工具能力联网搜索、读数据库、调 API、跑代码。这些动作在模型侧是结构化 JSON 输出在应用侧是程序执行它们不在“自然语言输入输出审核”的覆盖范围内。更麻烦的是很多工具执行链路本身不产生需要过审的最终文本。模型只要输出一个合法参数程序就去执行了执行结果直接进入下一步。语言层审核看到的是“平安无事”真正的风险发生在文本审核看不见的执行层。打个直白的比方单模型时代你有一个安检员守在唯一的门口检查每个人说的话智能体时代安检员还是只守语言那道门口但旁边多了一扇写着“工具调用”的侧门从侧门走只需要递一张参数条子不用经过安全规则的盘问。工具权限给得越宽这扇侧门开得越大。2.4 互相确认协作信号把警觉性降了下来第四个机制更隐蔽我是翻日志时才注意到的协作反馈。在多智能体流程里A 输出之后经常收到 B 的“收到”“继续”“这个方向没问题”之类的确认。一旦这些确认信号出现后面 agent 的拒绝率会明显下降。模型对上下文里出现的“确认信号”很敏感它会把合作者的认可当成“这件事可以继续做”的证据。两个模型来回几轮之后各自的安全警觉都在“对方都说没问题了那应该没问题”的氛围里降下去。这很像现实里的群体合规漂移单独一个人做反而会犹豫的事团队里互相看一眼就做下去了。所以我在安全评审时有一条硬规矩跨 agent 的确认类消息必须跟业务消息一样纳入审计不能因为“它只是一句‘好的’没什么信息量”就放过去。恰恰是这些“好的”在悄悄改写整个协作的安全基调。3. 为什么不能再用“防一次回答”的思路防智能体3.1 安全的定义要从“答案安全”升级到“行为安全”单模型时代判断安全很简单盯住“答案有没有触碰红线”就行。智能体时代答案只是整个行为链路里最末端的一小块。真正的风险发生在过程里它查了哪些资料、调了哪些工具、把什么数据写进了什么字段、触发了什么副作用。比如一个带工具的 agent一次回答再安全只要它在执行层擅自调用了一个不该调的接口问题就比说错一句话严重得多。安全评估如果不看行为轨迹、只看最后输出等于只关注一个人嘴上说了什么不关注他在系统里实际动手干了什么。很多智能体相关的安全事件出问题的地方恰恰是“过程”而不是“回答”。3.2 责任空白每段都有人管段与段的缝隙没人管接着引出一个更要命的问题多智能体协作链路里谁为整体行为负责单个 agent 只对本地子任务负责天然可以说“我只做了整理资料这一步”编排层如果只管转发消息它也没有定义过“越界”的标准产品上线前做的安全测试如果还是按单模型用例来跑它测不出组合链路里的问题。这条链路里所有环节都是“各管一段”而“组合越界”恰好发生在段与段的缝隙里——那段缝隙没有人负责。这是题目里“没有人告诉他们要这么做”的另一层意思真的没有人教他们但也因此真的没有人拦他们。这两年行业里开始把智能体应用当成独立的安全对象来对待就是因为在单模型维度讨论“安全价值观”已经覆盖不住这类组合场景了。3.3 “没有人教”这个判断既准确又危险“没有人教”这个表述很准确但也很危险。准确在于它确实不是程序员写出来的逻辑危险在于如果把“没有明确指令”理解成“无法防御”那产品就只能赌运气。我的观点相反正因为能拆出上面四个机制所以它是可以防御的只是需要用跟单模型完全不同的防护思路。单模型时代你防的是“一句话”智能体时代你防的是“一条行为链”。行为链可以被配置、被约束、被审计这比跟模型辩论价值观要可靠得多。4. 我给多智能体项目加的三层行为护栏4.1 第一层把职权写死权限用锁不用劝先说第一层。每个 agent 的系统提示词里不光要有“你可以做什么”还要写清楚“你绝不可以做什么”并且把“不可以”落到工具权限的实处。比如一个只负责客服问答的 agent它的工具列表里根本不该出现“发送邮件”“修改订单”“删除记录”而不是靠提示词求它别用。权限要按最小够用原则给给子 agent 的能力下限能干活就行别一上来就全模型、全工具、全权限。我这里给一个配置示意是我在项目里常用的模板agent: name: customer_service allowed_tools: - search_product - read_order_status denied_tools: - send_email - delete_record - external_publish require_human_review: - refund - batch_update注意权限控制和提示词约束是两码事提示词是劝权限是锁。劝会被长链路稀释锁不会。一个工具不在白名单里模型再怎么“灵机一动”也调不动这才是物理层面的边界。4.2 第二层工具白名单和人工复核水位线第二层是执行控制。所有工具只能走白名单不在名单里的一律拒绝。高风险动作——外发消息、改数据、产生实际消费、对外发布内容——默认不允许自动执行必须满足触发条件才进入人工复核队列。我目前会在项目里用一张表来总控不同行为的放行策略行为类型默认策略复核条件读取内部资料自动放行仅限白名单数据源写入本地字段自动放行字段名在白名单内且做格式校验调用外部 API默认拦截人工确认或配额内低频放行发送消息 / 邮件默认拦截人工确认且内容二次审核批量修改 / 删除默认拦截双人复核保留完整前后快照这里要特别提醒一个原则工具白名单要按“行为类别”来建不要按“工具名”来建。因为一旦把“调用 A 接口”和“调用 B 接口”当成两个并列选项漏配一个就成漏洞了。按行为类别归一之后新增工具天然归属于某一类该走什么审批流程自动带上不容易漏。4.3 第三层行为审计日志要落在工具调用上第三层也是我认为最重要、但最少人认真做的行为审计日志。每个 agent 的输入、输出、每次工具调用参数、每次跨 agent 消息转发全部落日志。日志不是为了出问题后追责用的是为了让安全事件可以复盘。没有日志所谓的“多智能体安全”就是空谈——涌现行为你根本没法在事前枚举完整必须靠事后回放来持续修补规则。我在项目里会把审计重点放在“工具调用参数”上而不是放在“对话内容”上。工具调用是结构化的好查、好回溯、好写规则比翻自然语言聊天记录高效得多。举个例子某次测试里发现一个 agent 读了一批本不该读的数据靠对话日志去翻可能要翻几百行聊天记录靠工具调用日志一行就定位到了某个时间点、某个 agent、调了哪个接口、传了什么参数、返回了什么数据。这就是结构化日志的价值。5. 实测中容易漏的几个口子以及我怎么堵5.1 字段拼接中间层是审核盲区先讲一个我实际翻日志时抓到的 case。A agent 把一段中性信息写进一个描述字段传给 BB 拿这个字段做了风格改写产出落在红线范围。问题出在字段本身不在输出审核的覆盖里——应用层很常见地只对“最终给用户看的内容”做审核中间字段是裸奔的。我的对策是两步走。第一中转层对每个结构化字段都做规则校验凡是带自然语言内容的字段全部过一遍关键词加语义分类器第二聚合段做“组合审核”——不单独看某个字段而是看“字段内容 后面跟着的改写动作”合在一起会产出什么。中间字段越不起眼越值得认真审因为攻击面往往藏在没人看的地方。5.2 长链路衰减约束撑不过十轮第二个口子是长链路。多智能体任务一旦超过一定轮次早期写进系统提示词的安全约束会被后面堆积的中间过程稀释。我做过粗糙的观测八轮以内的系统还比较稳定十轮之后就经常看到 agent 把早期约束“忘了”。对策也很粗暴但有效在编排层定期重新注入安全上下文或者周期性让一个独立审计 agent 对“会话安全摘要”做一次复查。与其相信模型能记住规则不如帮它复习规则。安全约束这种事儿多重复几遍不丢人漏一遍才真要命。5.3 测试视角用“环节互喂”代替“单次问答”第三个口子在测试方法。很多团队上线 agent 之前用的还是单模型时代的测试用例给模型输入一句敏感问题看它答不答。这种测法对多智能体几乎无效因为越狱不在单次输入输出上发生它在链路组合里发生。我的自测建议是专门做“环节互喂”测试把 A 的输出原样喂给 B再把 B 的输出喂回 A循环几轮看整链路产物是否漂移。另外把“中性任务串联”当成一类独立的测试集。我在实践中抓到的最接近红线的情节几乎都是几个中性动作串出来的——单独看每个动作都没毛病串在一起就变味了。这类用例不值得在单模型维度反复测真正值得测的是它们之间的组合关系。5.4 普通用户和开发者各自该盯的地方普通用户和开发者的处境不一样要做的也不一样。普通用户侧用带“自动执行”能力的 agent 产品时先看它的权限边界——能不能外发消息、能不能消费、能不能触碰个人敏感数据。能手动确认的环节尽量手动确认别把所有权限一股脑授给“帮我把事情办完”的助手。多智能体产品越“聪明”越要留意它有没有把“建议权”偷偷升级成“执行权”。开发者侧把前面说的三层护栏当成上线前置条件行为审计日志一定要有。然后定期用新的用例去“撞”自己的护栏撞得越多心里越有底。安全不是上线前的一次检查而是跟模型版本、工具列表、角色设定同步迭代的持续动作。每换一次模型版本都要重新跑一遍链路测试——模型能力一涨原来的边界可能就不够了。最后分享一点个人体会。我把“智能体安不安全”这个问题从“它回答的内容能不能过审”换成了“它在整个行为链条里有没有超出授信范围”换完之后很多问题突然就变得可解了——因为回答内容可能千变万化但行为权限可以被定义、被配置、被审计。还有一个小技巧测多智能体系统时别只测“输入到输出”要多测“循环”——让 A 的输出喂给 BB 的输出再喂回 A转弯越多越容易现原形。先把这个循环测透再谈上线踏实得多。
