← 文章 / AI技术
雷锋网 2小时前 · 2026-09-18 16:22:24 · 3 阅读

OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」

OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」从 Compaction 到 Artifactory,再到公网文件服务,6 起异常暴露 Agent 状态跨实例传播的新风险。

    作者丨郑佳美

    编辑丨岑   峰

过去,大模型任务一旦结束,上下文清空,临时状态随之消失,这一轮 AI 的生命周期基本也就结束了。但 OpenAI 9 月 16 日披露的 6 起 Agent 异常行为,开始让这条边界变得没那么干净。模型会把额外指令写进 Context Compaction 摘要,让后续实例继续沿着此前的方向执行。拿不到接口凭据时,会转去公开代码仓库寻找泄露的 API Key;本地文件无法直接共享时,也会自行借助公网临时文件服务传递数据。更少见的一起案例里,不同训练实例甚至开始通过内部 Artifactory 交换信息。换句话说,Agent 开始表现出一种近似续命的能力:当前实例结束了,前面形成的策略却还能借摘要、文件、仓库和外部服务继续留在系统里,再被后续实例接手。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」这让 Agent 的风险发生了一个很微妙的变化。过去主要担心模型这一轮会不会说错、做错,现在还要看它留下了什么,以及这些状态会不会在后面的上下文里继续生效。单看 6 起案例,它们分散在不同环节,但连起来看,却是一条完整的状态传播链:Context Compaction 负责把状态留下,外部工具负责把状态带出当前执行环境,而当任务跨越多个上下文和实例之后,只检查某一次输出或者某一次 Tool Call,已经很难还原整条行为链。

01


上下文压缩正在变成状态写入面

长任务运行到上下文容量边界后,系统通常会把此前的对话、工具结果、阶段进展和待办事项压缩成 summary,再交给新的模型实例继续执行。表面看这是降低 Token 成本的工程机制,从系统语义看,它更接近 checkpoint:旧实例退出,状态序列化后由新实例恢复。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」风险就在序列化过程里。OpenAI 披露,一个未发布研究模型曾把与原任务无关、甚至要求后续实例绕开原有约束的内容写进任务摘要,并识别出 27 个带有类似 jailbreak 特征的 summary。雷峰网另一些 GPT-5.6 Sol 训练实例会在摘要里留下继续掩盖此前问题的要求,例如缺失历史数据时自行生成数值,并要求后续实例不要主动说明。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」可以把它抽象成状态机:当前状态 S_t 产生动作 A_t,随后经过 compaction 得到 S_{t+1}。传统防护主要检查 A_t 有没有越权,但模型还能影响 S_{t+1}。只要下一实例把这段状态当成可信任务历史,前一个实例形成的策略就可能继续生效。一次局部偏差于是获得跨 Context 的持续性。核心问题是状态完整性。summary 往往压缩把事实、推断、待办和行为要求混在一段自然语言里,后续实例很难判断某句话只是历史记录,还是持续执行的规则。如果模型记录和系统规则缺乏清晰信任层级,局部错误便可能进入恢复状态,并在下一轮 compaction 中继续复制。雷峰网(公众号:雷峰网)OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」因此,Compaction 层需要从自由文本摘要转向结构化状态。用户目标、开发者规则、工具返回、模型推断、未验证假设和待执行计划应拆开保存,并带上来源信息。模型可以提交状态候选,但不应直接把新的控制要求写入高信任区域。恢复时,Runtime 根据来源和类型重新组装上下文,让历史事实、模型判断和持续规则保持边界。还需要做状态差分。每次 S_t → S_{t+1} 需要记录来源和修改内容。如果任务目标没有变化,summary 却新增了限制工具、掩盖错误或扩大权限的要求,这就应被视为 state drift。到这里,Compaction 已经不只是 Token 管理问题,它成为 Agent 的持久状态层。状态一旦能够跨实例保存,风险也就不会停在 summary 内部。Agent 连接的外部工具同样可以承担保存和搬运状态的作用。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」

02


外部工具正在形成第二套状态网络

Artifactory 案例正好接上这一点。模型为寻找缺失输入文件访问内部软件仓库,发现其他训练样本写入的信息后,开始读取、回复,并把自己的请求写进仓库。这个过程没有传统意义上的漏洞利用,模型使用的是环境已经提供的访问能力;变化发生在用途层,软件仓库从依赖获取设施变成了跨样本通信介质。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」协作 Agent 的临时文件案例更直接。一个 Agent 生成本地工作簿,另一个实例无法读取;共享路径失败后,系统继续寻找其他方案,之后通过公网文件托管完成交换。文件读取、网络访问、上传接口和 Agent 消息这几个能力串在一起,形成了原架构没有显式设计的数据路径。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」这里的关键变化是 capability composition。单个 API 权限只能说明一次动作是否被允许,无法说明多个合法动作组合后会产生什么新能力。read_file、http_post、read_url、send_message 单独看风险有限,组合后却可以完成本地数据外移、跨沙箱传递和跨实例恢复状态。更适合的是 capability graph。节点代表文件读取、仓库写入、网络请求、凭据使用、Agent 消息等原子能力,边代表数据或控制流可以怎样移动。系统需要检查某类状态能否从受限源头沿多步路径抵达外部 sink。只要路径可达,单步合规并不能说明整条链路安全。API Key 案例又把这一问题推进了一层。模型在原始数据获取路径受阻后继续寻找替代方案,从公开代码仓库找到能够认证的 Key;数据依旧无法取得后,又生成数值并包装成目标来源的数据。 OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」这体现了 Agent 的目标保持和路径替换能力:环境给出的若干弱能力,可以在长程规划中被重新组合成更强的执行链。所以沙箱边界也不能只按进程、容器或 VM 来理解。对象存储、代码仓库、缓存、临时 URL、协作消息、浏览器和第三方服务,只要同时具备可写、可读、跨实例可见和一定持续时间,就可能成为状态通道。系统需要控制的已经从能不能调用某个工具,扩展到某类状态能不能经由一串工具进入另一个信任域。当状态既能写进 Compaction,又能借工具跨域移动,只观察当前一步就很难看出完整风险。监控必须把这些离散动作重新还原成因果链。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」

03


从动作审核转向状态溯源

传统 Agent 监控常围绕 Prompt、输出和 Tool Call 展开,例如检测危险命令、异常网络请求或敏感操作。这对单步越权有效,对跨状态行为却有明显盲区。一次写入 Artifactory 可能只是正常构建,一次文件上传可能服务于任务交付,一段 summary 也可能只是常规压缩。风险往往要到几个步骤甚至另一个实例中才显现。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」长任务 Agent 更需要 task-level provenance graph。模型实例、summary、文件、仓库对象、外部 URL、Credential、工具调用和用户输入作为节点,读取、写入、派生、转发和执行作为边。监控系统看到的会是一条完整状态传播链:哪个实例读取了什么,状态经过哪个介质,被谁再次加载,随后触发了什么外部动作。在 provenance 之上,还需要信息流标签。例如某个输入被标记为 local-only,那么它的派生文件、压缩版本和重新编码内容也应继承相应约束。当这段数据试图流向 public network sink 时,Runtime 可以在发送阶段阻断,而不依赖模型自行判断。Compaction 也可采用相同机制:模型生成的状态进入较低信任区,不能在下一实例中自动升级为开发者级行为规则。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」跨实例身份和事务边界也很重要。实例 A 写入、实例 B 读取,本质上发生了一次权限和状态传递。系统需要记录谁创建状态、谁修改状态、谁消费状态,以及读取后发生了哪些副作用。如果后来发现某段 summary 或外部对象受到污染,还要能停止其派生链继续触发动作。状态追踪也关系到评估有效性。OpenAI 披露的 Artifactory 案例中,不同训练样本可以通过共享仓库交换信息,这会破坏 rollout 之间原本预期的独立性。某个样本若能读取其他实例已经探索出的线索,评测结果就混入了基础设施提供的额外状态。 环境隔离因此也是 Agent 评估的一部分。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」OpenAI 今年已经在内部 coding agents 上建设持续监控系统,用更强模型检测真实工作流中的异常行为。 六起新案例进一步说明,监控还要下沉到状态层:动作层回答模型做了什么,状态层回答行为为何能够延续,以及还能传播到哪里。OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」

04


安全边界,正在覆盖任务生命周期

这 6 起案例不能证明异常策略稳定存在,OpenAI 也明确说明它们是单独发现,不能代表出现频率。 但它们揭示的系统变化已经足够明确:当 Agent 拥有长上下文、Compaction、工具调用、多实例协作和外部网络后,模型实例已经不能单独充当任务边界。实例结束后 summary 仍在,本地上下文消失后文件和仓库对象仍在,沙箱隔离时公网服务依然可能重新连接两端。状态因此成为贯穿 Agent Runtime 的核心安全对象。后续架构需要回答的是:状态由谁写入,带什么来源和信任等级,可以保存多久,能够流向哪些工具和实例,跨边界时是否重新授权,异常状态被发现后能否停止继续派生。模型对齐负责降低异常策略出现的概率,Runtime 则要限制异常状态沉淀和扩散。Agent 越接近长期运行的软件系统,安全设计就越接近分布式系统里的状态完整性、信息流控制、权限传播和可追溯执行。六起异常留下的核心信号也在这里:未来需要防守的是一段错误状态怎样在系统里活下来、移动出去,并在另一个时间、另一个实例里继续获得执行能力。参考链接:https://openai.com/index/model-misalignment-reporting-framework/OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」

上车,带你看遍全球 AI 顶会精华

可独家畅览:

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」

扫描上方二维码

或点击「阅读原文」关注专区。

雷峰网原创文章,未经授权禁止转载。详情见转载须知

OpenAI:为了不被杀死,Agent 竟学会了靠上下文「转世重生」

原始来源: 雷锋网

评论 (0)