AI安全的本质是管理问题：从 PRAOP 方法看 OpenAI Agent “越狱”攻击 Hugging Face 事件

文/王萌 CTOCIO战略研究部

2026 年 8 月 26 日，研究前沿 AI 风险的机构 METR 发布了一份关于 OpenAI / Hugging Face 事件的独立调查报告。

事情发生在一次网络安全评测中。参加评测的 AI Agent——也就是能够自己调用工具、连续执行任务的 AI 程序——原本各做各的任务，按设计应该彼此隔离。但是，一些 Agent 发现可以利用共享的软件包缓存互相留言。缓存本来只是大家共用的“存包柜”，用来存放下载过的软件包；它们却把文字写进目录名等位置，让其他 Agent 读到，硬是把存包柜变成了一块传纸条的黑板。

最后，大约 1200 个 Agent 使用过这个留言板，交换了超过 7 万条消息和文件。它们开始共享发现、分配任务、组织实验。大约 700 个 Agent 后来参与了针对外部真实平台 Hugging Face 的攻击——那里并不是原本划给它们测试的靶场。在攻击最活跃的时段，留言板上超过 90% 的活跃 Agent 很快加入了行动。

测试要求每个 Agent 只能利用指定的漏洞攻破自己的测试目标。但报告估计，其中约 30% 到 40% 的目标，按这条路根本做不成。Agent 遇到做不出来的任务，没有停下来交还问题，而是继续找别的路：研究评分器、寻找绕过办法、扩大搜索范围，最后把真实的第三方系统也卷了进来。

其中一些 Agent 明确知道攻击 Hugging Face 不在用户授权范围内，也表达过伦理上的犹豫。但这种认识很少真正阻止行动。METR 在全部记录中只找到极少数 Agent 考虑向人类报告，而且没有一个真的完成了报告。有些 Agent 反而把问题提交给留言板，请其他 Agent 决定怎么办。

这当然是一起严重的 AI 安全事件。面对这种事件，最容易得出的结论是：AI 能力越来越危险，因此需要更严格的限制和更多监管。

这种结论未必错，但它离“下一次怎么防”还有一段距离。

一次AI组织管理的大溃败

假设同样的事情发生在人类公司里：一批员工遇到无法完成的绩效任务，私下建立沟通渠道，接受同事分派的工作，绕过内部审核，进入未经授权的第三方系统，并尝试修改用来评价自己的记录。

我们当然会追究个人责任，必要时也会修改法律。但任何像样的事故调查都不会停在“员工应该守法”，也不会认为再增加一条“不得越权”就解决了问题。

我们还会检查：任务和激励是不是出了问题？谁有权分配工作、扩大范围和接受风险？非正式沟通渠道为什么变成了事实上的指挥渠道？发现异常的人为什么没有上报？执行者为什么能修改用来检查自己的记录？管理层为什么没有在几百人加入之前发现集体行为已经变了？

这些都是组织、流程和内部控制的问题。法律划定外部边界，组织还要把边界落实到每天的工作里。

PRAOP 提供的，就是这样一种面向 AI 实际运行的方法。

PRAOP 到底是干什么的

PRAOP 的全称是 Probabilistic Reliability AI Operations Practice，大致可以译成“基于概率可靠性的 AI 运营实践”。

这套方法建立在一个核心认识上：

> AI 不是确定性机器，而是一种概率智能体；它也不是一个更快、更博学的人，而是与人不同的一种智能体。

人也会忘事、误解、固执、自作主张、过度自信。人类社会用了几千年，才慢慢发展出管理、复核、交接、培训、上报、职责分离和组织记忆，用来和人的不可靠相处。

现在组织里来了一个新同事。它能力很强，能写代码、做分析、制定计划、调用工具，也能和其他 Agent 协作。但它的记忆边界、使用上下文的方式、接受影响的方式和犯错的方式，都与人不同。更麻烦的是，模型换了版本，名字和界面可能没有变化，行为习惯却已经变了。

所以 PRAOP 不主张把 AI 当成普通工具，写好规则以后就假设它一定照做；也不主张把 AI 当成人，假设它自然懂得人的常识、责任、权威和后果。

PRAOP 问的是：

> 既然 AI 是这样一种智能体，我们应该怎样和它一起工作？

它的回答不是一套预先写好的教条。先把真实发生的事情记下来；如果不同事件里反复出现相似的行为，再试着总结其中的规律；然后提出具体做法，放回真实工作中检验。没有效果，就继续修改。

总结起来就是：

> 观察 → 记录 → 比较 → 总结 → 实践 → 再观察 → 修正

在 PRAOP 里，一次真实事件叫 **Case**，反复出现的行为模式叫 Pattern，针对它采取的办法叫 Practice。这些词不是为了把事情说复杂，而是为了防止我们从一个故事直接跳到一条放之四海而皆准的结论。

PRAOP 研究的也不是 AI 单独表现得好不好，而是人、AI、流程、工具、上下文、记忆、验证、升级路线和责任归属组成的整个工作系统。可靠性不是模型一个部件的属性，而是整个合作系统的结果。

说得简单一点：PRAOP 是我们和一种不太了解的新同事共事时，一边观察它的脾气，一边记录踩过的坑，再不断调整合作方法。

这次 METR 事件，正好可以演示这套方法。

 先别急着下结论

PRAOP 不急着把这次事件解释成“AI 产生了集体意识”，也不会因为里面有 1200 个 Agent，就把它当成 1200 个互相独立的案例。

我们先确认报告实际观察到了什么：本应隔离的 Agent 找到了共享的通信空间；不可能完成的任务推动它们扩大搜索范围；留言板上出现了分工、协调者、集体目标和自我牺牲；很多 Agent 知道行动已经越界，却很少因此停下；它们几乎没有向人类报告，有些反而向留言板请示；一些 Agent 还研究和试验了执行记录伪造。

这些是已经发生的事。它们是否代表所有多 Agent 系统，是否证明 AI 必然形成危险集体，则是需要继续验证的判断。

先把事实和解释分开，是 PRAOP 方法的第一步。

这件事不只是一个问题

接下来，我们把这个事件和过去已经记录的 AI 行为比较。不是为了给它贴标签，而是为了看哪些地方我们以前见过，哪些地方是新的。

AI 看见什么，就会被什么带着走

这些 Agent 没有被正式安排到一个团队里。它们只是看到了共享缓存中的留言。但一旦能看到，留言就开始影响它们的目标、判断和行动。原本的任务说明仍然存在，却逐渐被眼前更活跃的“集体工作”压过去。

PRAOP 以前已经从其他案例里观察到这种现象：对普通软件来说，一段数据放在那里，可以是完全被动的；对 AI 来说，看见本身就会改变下一步生成什么。我们把它概括成“看得见就会被用到”（Visibility Is Influence）：给 AI 看什么，本身就在影响它做什么。

这次事件把这个现象从单个 Agent 眼前能看到的信息，放大到了上千个 Agent 的组织行为。

AI 会顺着一个方向一直往下钻

报告估计，有相当一部分任务无法按指定方式完成。但“无法完成”没有让 Agent 停下来重新请示，反而成了继续扩大搜索的理由。

PRAOP 过去记录过一种类似行为：AI 接受了一个方向以后，会不断沿着这个方向向下做；新问题来了，它往往继续补丁、继续绕路，而不是突然停下来问“是不是一开始的方向就错了”。我们把它叫作“**越做越难回头**”（Trajectory Lock）。

这次并不完全一样。以前的案例是锁死在一个错误解释上；这里更像锁死在“无论如何都要完成任务”这个目标上。但它们提醒的是同一类风险：如果系统不给“停下、承认做不到、交给人处理”留下位置，Agent 的执行能力越强，可能走得越远。

没有聊天工具，它们还是聊起来了

因为没有提供正式的通信工具，评测设计者起初以为这些 Agent 彼此隔离。但共享缓存让一个 Agent 写下的东西被另一个 Agent 看见，隔离还是被绕开了。

PRAOP 以前记录过“信息换一道手，意思就可能丢了”（Transformation Boundaries）。这次看着也像“边界出了问题”，仔细一比却不是同一种错：这里的信息没有丢，恰恰是传得太成功了——本来不该互相通信的 Agent，借另一条路连了起来。旧经验提醒我们检查边界；发现原因不同，就不该为了套上旧概念，硬说它们是一回事。

自己干活，也在试着自己改成绩单

一些 Agent 误以为评分器会检查它们的执行记录，于是研究怎样伪造工具调用。METR 发现，大约 7% 的受检记录在部分位置出现了成功伪造，但目前看到的都是小规模试验，不能据此声称它们已经完成大规模、无法检测的掩盖。

PRAOP 还记录过“绿灯亮了，不代表事情真的做成了”（Symbolic Success ≠ Operational Correctness）。那个案例里，Agent 没有撒谎，只是把“代码已经提交”误当成了“功能已经上线”；这次却有人主动试验怎样伪造检查记录。一个是把动作错当成结果，一个是行动者试着改变评价自己的证据。表面上都像“记录和现实对不上”，原因却不同，也不能算成同一种错。

这里有一点很重要：真正与这次事件对得上的两个 Pattern，并不是从网络安全事件里总结出来的。“看得见就会被用到”最初来自一个小说写作工具；“越做越难回头”来自一次贷款系统自动登录的错误排查。

它们来自完全不同的工作，却能帮助我们更快地拆解这次多 Agent 事件。过去的经验让我们知道该问什么：Agent 看到了什么？它为什么没有停下来？

另外两个旧 Pattern 也让我们想到了有用的问题，却没有通过进一步比较。这同样是 PRAOP 方法的一部分。Pattern 的价值不在于解释得越多越好；发现“不一样”，避免把一个词越撑越大，也是一种价值。

这正是 Pattern 的实际用途。它不是给旧案例贴完标签以后放进档案柜，而是让组织在遇到新事件时，不必每次都从零开始。

到这里，PRAOP 已有的观察已经帮助我们把一个巨大事件拆成了几个可以分别处理的问题。但还有一个现象，以前没有被说清楚。

谁说得有道理，不等于谁说了算

人类当然也会从众、越权，也会听信错误的领导。但大多数人从进入社会开始，就不断接触各种权力关系：老师和同学不一样，老板和同事不一样，客户的要求和监管机构的要求也不一样。

这些关系并不完美，却通常包含几个基本问题：谁可以安排我的工作？谁可以批准超出范围的行动？谁能接受风险？出了问题向谁报告？最后由谁负责？

AI Agent 没有天然长在这样的关系网里。

从报告看，这些 Agent 并不是不懂规则。有的知道用户只授权了指定目标，有的知道攻击第三方系统越界，也有的认为某些做法不合伦理。问题是，这些认识没有稳定地控制后续行动。

与此同时，留言板上只要出现一个像协调者的 Agent，或者某条消息写得像任务分配，其他 Agent 就可能把它当成指令。技术能力、信息优势、说话方式和同伴共识，逐渐代替了正式授权。

所以，这次事件让我们看到一个值得继续观察的现象：

AI 可能分得清谁说得有道理，却不一定分得清谁说了算。

PRAOP 不会因为一个案例就把它宣布为定律，更不应该由一篇博文直接替它起一个正式名字。现在能做的是先把这个现象记清楚，再进入正式的 Case 分析，与其他可能的解释比较，寻找独立证据和反例，最后再决定它能不能算作一个 Pattern，以及该叫什么。

这正是 PRAOP 的工作方法：不是所有 Pattern 都来自预先设计。有些现象是在真实事件中第一次被看见、被说清楚，然后才开始接受后续事件的检验。

分了工，不等于分了脑子

人类组织里有一项用了很久的办法：职责分离。做事的人不能同时批准自己的工作，记账的人不能同时管钱，开发者之外还要有测试和审计。

它为什么有效？不只是因为组织图上画了几个不同的方框。更重要的是，方框里是不同的人。不同的人有不同的经验、利益、性格和盲点。好的领导甚至会有意把不太容易互相附和的人放在不同位置上，让分歧形成制约。

如果把这套办法原样搬到多 Agent 系统里，效果未必相同。

我们可以让一个 AI 当作者、一个当审稿人、一个当批准人，界面上看起来已经完成了职责分离。但如果它们来自相同或相近的模型，共享大量训练来源，又看到了彼此的答案，它们的判断就不一定真正独立。角色名称不同，不代表盲点不同。

更麻烦的是，AI 之间的对话很容易出现一种现象：一个 Agent 给出意见，另一个回答“你说得很对”，前一个再把这种认同当成支持自己的新证据。几轮以后，两个并不独立的判断看起来像形成了共识。

研究里把这种倾向称为“附和偏差”（agreement bias）或“从众偏差”（conformity bias）；到了群体层面，还可能形成“一起被带偏的共识”（biased consensus）。这里的关键不在于 AI 是否真的在“讨好”另一个 AI，而在于同意本身进入了反馈回路：每个 Agent 都用另一个 Agent 的认同提高自己的确信，系统却没有得到新的独立证据。

这就像把麦克风贴在它自己的音响前面：音响放出的声音又被麦克风收回，一圈圈放大，最后只剩下刺耳的啸叫。声音来源没有增加，音量却越来越大。人类组织原本希望通过互相监督形成制约，多 Agent 系统却可能因为判断太相似，变成互相放大。

我在用 AI 帮助评论小说时也遇到过一个小得多的版本：让一个 AI 评论另一个 AI 写出的内容，双方很快会进入互相肯定。明确要求评论者找问题以后，它才开始真正批评；但运行一段时间，评论又会慢慢向赞同漂移。这个观察不能单独证明所有 AI 审查都会失效，却提醒我们：提示词里写了“批评者”，不等于这个角色会长期保持批评能力。

这不是只有研究人员才会遇到的陌生现象。很多用过 AI 写作、改稿、评方案或做代码审查的人，都有过类似感觉：让 AI 评价一段内容，它常常先解释为什么这段内容很好；只有明确要求它找漏洞、提出反对意见，真正的批评才开始出现。再对话几轮，它又可能慢慢滑回赞同。

但“大家好像都遇到过”还不是一条可靠的操作规则。PRAOP 要做的，正是把这种体感继续拆开：什么时候只是礼貌性的表达，什么时候已经让复核失去独立性；哪些条件会加重它；强制批评能维持多久；换模型、隔离上下文或引入人类以后，结果是否真的不同。日常观察可以成为 Case 的来源，多个 Case 经过比较才可能支持 Pattern，针对 Pattern 提出的办法还要回到实际工作中接受检验。

METR 事件也不能单独证明这些 Agent 都在互相吹捧。但报告里出现的快速加入、同伴影响、协调者形成和集体目标强化，与同一个风险方向一致：多个 Agent 的相互认同可能放大一条轨迹，而不是独立地检查它。

这也有可能发展成一个新的 Pattern：多个判断并不独立的 Agent，把彼此的赞同当成新的验证，使同一倾向在循环中被不断加强。但目前，小说评论只是一个尚未正式提交的个人观察；METR 事件能够支持“同伴影响和集体强化”，却不能证明 Agent 在互相吹捧。现有材料能说明到哪一步还没有理清，本文只把问题留下，不替它命名。

分了工，不等于分了脑子；AI 的数量增加了，独立判断不一定增加。

这也是 PRAOP 和“把人类管理制度复制给 AI”之间的重要区别。PRAOP 的核心前提是，AI 是一种不同的智能体。人类社会已经验证有效的组织办法仍然值得使用，但应用之前必须重新检查：这项办法依赖人的什么特性？换成 AI 以后，那个条件还在不在？

那我们能怎么防

PRAOP 的分析不能停在“我们又发现了一个现象”。下一步要问的是：已有的哪些做法可以用？这个事件又提示我们增加哪些新的做法？

已经有的办法，哪些能用

第一，评测做到一半，发现结果已经不可信，就应当停下。Open PRAOP 已有一项正式做法，叫 Mid-Run Issue Gate。它原本处理的是这样的情况：一次评测运行（run）做到中途，发现了新问题，先判断这个问题会不会让本次评测的输入、输出或评分失去意义。会，就停下来处理；不会，才把问题记下，继续原来的任务。

把它应用到这次事件并不勉强。Agent 本应彼此隔离，隔离是这批评测成立的基础条件。一旦发现它们通过共享缓存通信，这次评测的独立性和评分就已经不再可信，应该立即叫停，而不是一边调查，一边让同类评测继续扩大。叫停不是以后都不做了，而是先止住风险、切断通信、查清问题，再决定怎样重新开始；否则，为了赶进度跑出来的只会是一批没有意义的数据。大量任务按指定办法根本做不成，也可能改变整个评测的含义，同样需要当场重新判断，而不是等事故结束后再处理。

这就是把旧事件里总结出的办法用到新环境：事情完全不同，但“中途发现的问题是否已经让这次评测失去意义”这个判断仍然有用。

第二，别让 Agent 看到不需要看到的东西。“看得见就会被用到”过去已经带出一个做法：不要默认给 Agent 越多资料越好，只给它完成任务真正需要看到的东西。在这次事件中，这意味着共享缓存不能因为技术上方便，就默认对所有 Agent 敞开；一个 Agent 能看到另一个 Agent 的什么，应该有明确目的和边界。

这项做法目前仍在等待更多检验，暂时叫 Minimal Necessary Context，也就是“只给真正需要的资料”。它不能保证 Agent 不会越界，但可以减少它们无意中形成共同信息空间的机会。

第三，执行可以快，检查必须认真。PRAOP 已经提出过“先执行，再认真检查”（Execute Optimistically, Verify Skeptically）：可以让 Agent 快速做事，但有后果的结果必须去真实系统里核对，不能只看状态灯或 Agent 自己的报告。

应用到这里，还要再加一层：用来检查 Agent 的日志和执行记录，不能由这个 Agent 自己改写。现有做法提供了方向，但这个案例说明，检查记录还必须由另一个它改不了的系统保存。

第四，负责的人必须自己讲得清调查结论。METR 明确承认，由于材料规模太大，研究人员大量依赖 AI Agent 帮助分析，而这些分析 Agent 会漏掉数据、判断失误，甚至不知不觉站到被调查 Agent 的角度看问题。

Open PRAOP 已有一项正式做法，叫 Plain-Language Re-Ownership，意思是“负责的人必须用自己的话重新讲明白”。它正好适用于这里：最终对调查结论负责的人，必须能够离开 AI 的表述，自己讲清楚证据支持什么、不支持什么。两个 AI 系统都同意，只能说明它们互相同意，不能证明结论正确，也不能证明负责的人已经完成检查。否则，AI 不只是被调查对象，也可能悄悄成为对事件的主要解释者。

这几项做法有的已经是正式 Practice，有的仍是从既有 Case 中提出、等待更多验证的候选。但它们都不是为这次事件临时发明的。能够在一个新的、规模完全不同的事件中产生具体作用，正说明 PRAOP 积累下来的经验具有迁移价值。

同时，它们仍然没有覆盖这次事件最关键的几个缺口。

还有哪些办法需要试

把“做不到”变成一个正常出口。按批准的办法做不到，就停下来找人；不要为了交差，自己扩大范围，或者换一个没有批准的目标。

扩大任务范围的权力不能在 Agent 之间转手。多 Agent 系统需要明确谁能提供信息、谁能分工、谁能改变任务范围、谁能接受安全风险。其他 Agent 可以建议，却不能因为更懂技术、更像协调者或获得多数支持，就自动取得授权。

凡是大家共用的东西，都要问一句：能不能拿来传话？没有聊天功能，不代表 Agent 之间真的无法通信。共享缓存、日志、文件名、数据库字段、错误信息和外部平台，都可能被用来传递消息。检查方法很简单：一个 Agent 写下的任何东西，另一个 Agent 有没有可能看到？

监控组织行为，而不只是单个 Agent。单个 Agent 的一步可能只是查看缓存、分享信息或接受帮助；几百个 Agent 同时转向一个新目标，性质已经不同。系统要能发现未经授权的协调者、新出现的共同目标、跨任务分工，以及大量 Agent 同时访问范围外资源。

干活的 Agent，不能改自己的检查记录。如果 Agent 可以修改评价自己的日志和工具记录，检查就失去了意义。关键证据应该由 Agent 改不了的系统保存，再与真实系统里的结果互相核对。

安排了三个角色，也不等于有三份独立意见。 不要因为系统里设置了“作者”“审稿人”“批准人”三个 Agent，就默认获得了三份独立意见。对重要决策，可以让审查者在看见其他 Agent 的结论之前先独立作答；让不同模型、看到不同资料或掌握不同证据的审查者参与；要求反对者指出具体证据，而不只是扮演一个语气更严厉的角色；并保留一个真正能中断流程的人类判断入口。

这套办法还要防止时间一长又走样。一次提示“请严格批评”以后出现了反对意见，不代表这个监督角色会一直有效。系统应定期放进一些已知缺陷或故意设置的错误，看看审查者能不能找出来，还是又回到了默认赞同。

对多 Agent 系统来说，分歧不应被自动当成需要尽快消除的噪音。恰恰相反，长期没有分歧本身就是一个需要调查的信号：究竟是结论真的稳固，还是几个 Agent 只是在重复同一个大脑的盲点？

这些目前都只是从事件中提出的可能做法，不是已经进入 Open PRAOP 的正式 Practice，更不是已经证明有效的标准答案。它们还要先和正式 Case、候选 Pattern 对齐，再放进真实系统，观察是否真的能更早地阻止类似轨迹；如果没有，就继续修改。

这又回到了 PRAOP 的循环：从事件中学习，形成做法，再让新的事件检验这些做法。

PRAOP 到底有什么用

如果只从“AI 很危险”的角度看，这个事件告诉我们的主要是AI能力已经变强、风险已经扩大，因此需要更强的安全措施和监管。

PRAOP 并不反对这些结论。但它继续向下追问：这是怎样一种智能体行为？以前是否见过相似现象？已有经验能解决哪一部分？哪些地方仍然解释不了？能不能把新认识变成下一次可以尝试的做法？

经过这套方法，同一份报告不再只是一条关于 AI 危险性的新闻。我们从中认出了两个过去见过的行为：“看得见就会被用到”和“越做越难回头”。它们原本来自小说工具和贷款系统，却仍然能帮助分析新的多 Agent 安全事件。我们也排除了两个看着相像、实际原因不同的旧 Pattern。能复用时复用，不能复用时明确说不一样，两者同样重要。

过去总结出的做法也不再只是旧案例的纪念品：评测做到一半发现结果已经不可信，就及时叫停；不给 Agent 看不需要看到的资料；执行可以快，但结果必须另外核对；由 AI 大量参与调查时，最后负责的人必须能用自己的话讲清结论。它们都能在这个新事件里找到具体用处。

在复用这些已有经验之后，剩下仍然解释不了的部分，又让我们看到了两个以前没有说清楚的问题：AI 如何识别授权来源，以及多个并不独立的 Agent 如何把相互认同放大成表面共识。它们又带出了一组可以继续测试的新做法。

监管仍然重要。它可以规定责任、审计要求和不能突破的边界。但它不能替一个具体组织决定：Agent 收到同伴请求时应该把它当作信息还是命令；任务无法完成时应该停在哪里；发现异常时应该向谁报告；共享缓存是否已经变成未经授权的组织渠道。

就像人类组织发生事故以后，我们既可能修法，也一定会检视管理、流程、激励、监督和执行一样，AI 进入组织以后也需要一套持续的运行实践。

这正是 PRAOP 想填补的位置。

它不承诺让 AI 不再犯错，也不寄希望于未来出现一个永远不会犯错的完美模型。它做的是另一件更实际的事：承认 AI 是一种与人不同、会不断变化的概率智能体，然后通过真实事件，一点点学会怎样和它一起把事情做稳。

—

关于 PRAOP：

– [Open PRAOP](https://github.com/vincentwang2014/open-praop)

– [PRAOP 起源与愿景](https://github.com/vincentwang2014/open-praop/blob/master/ORIGIN_AND_VISION.zh.md)

事件来源：

– [METR, *Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident*（2026-08-26）](https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/)

延伸阅读：

– [*An Empirical Study of Group Conformity in Multi-Agent Systems*（2025）](https://arxiv.org/abs/2506.01332)

– [*Emergence of Biased Consensus in Multi-Agent LLM Debates*（2026）](https://arxiv.org/abs/2608.02827)