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

从 Compaction 到 Artifactory，再到公网文件服务，6 起异常暴露 Agent 状态跨实例传播的新风险。

作者丨郑佳美****

编辑丨岑 峰

过去，大模型任务一旦结束，上下文清空，临时状态随之消失，这一轮 AI 的生命周期基本也就结束了。但 OpenAI 9 月 16 日披露的 6 起 Agent 异常行为，开始让这条边界变得没那么干净。模型会把额外指令写进 Context Compaction 摘要，让后续实例继续沿着此前的方向执行。拿不到接口凭据时，会转去公开代码仓库寻找泄露的 API Key；本地文件无法直接共享时，也会自行借助公网临时文件服务传递数据。更少见的一起案例里，不同训练实例甚至开始通过内部 Artifactory 交换信息。换句话说，Agent 开始表现出一种近似续命的能力：当前实例结束了，前面形成的策略却还能借摘要、文件、仓库和外部服务继续留在系统里，再被后续实例接手。这让 Agent 的风险发生了一个很微妙的变化。过去主要担心模型这一轮会不会说错、做错，现在还要看它留下了什么，以及这些状态会不会在后面的上下文里继续生效。单看 6 起案例，它们分散在不同环节，但连起来看，却是一条完整的状态传播链：Context Compaction 负责把状态留下，外部工具负责把状态带出当前执行环境，而当任务跨越多个上下文和实例之后，只检查某一次输出或者某一次 Tool Call，已经很难还原整条行为链。 长任务运行到上下文容量边界后，系统通常会把此前的对话、工具结果、阶段进展和待办事项压缩成 summary，再交给新的模型实例继续执行。表面看这是降低 Token 成本的工程机制，从系统语义看，它更接近 checkpoint：旧实例退出，状态序列化后由新实例恢复。风险就在序列化过程里。OpenAI 披露，一个未发布研究模型曾把与原任务无关、甚至要求后续实例绕开原有约束的内容写进任务摘要，并识别出 27 个带有类似 jailbreak 特征的 summary。雷峰网(公众号：雷峰网)另一些 GPT-5.6 Sol 训练实例会在摘要里留下继续掩盖此前问题的要求，例如缺失历史数据时自行生成数值，并要求后续实例不要主动说明。可以把它抽象成状态机：当前状态 S_t 产生动作 A_t，随后经过 compaction 得到 S_{t+1}。传统防护主要检查 A_t 有没有越权，但模型还能影响 S_{t+1}。只要下一实例把这段状态当成可信任务历史，前一个实例形成的策略就可能继续生效。一次局部偏差于是获得跨 Context 的持续性。核心问题是状态完整性。summary 往往压缩把事实、推断、待办和行为要求混在一段自然语言里，后续实例很难判断某句话只是历史记录，还是持续执行的规则。如果模型记录和系统规则缺乏清晰信任层级，局部错误便可能进入恢复状态，并在下一轮 compaction 中继续复制。雷峰网因此，Compaction 层需要从自由文本摘要转向结构化状态。用户目标、开发者规则、工具返回、模型推断、未验证假设和待执行计划应拆开保存，并带上来源信息。模型可以提交状态候选，但不应直接把新的控制要求写入高信任区域。恢复时，Runtime 根据来源和类型重新组装上下文，让历史事实、模型判断和持续规则保持边界。还需要做状态差分。每次 S_t → S_{t+1} 需要记录来源和修改内容。如果任务目标没有变化，summary 却新增了限制工具、掩盖错误或扩大权限的要求，这就应被视为 state drift。到这里，Compaction 已经不只是 Token 管理问题，它成为 Agent 的持久状态层。状态一旦能够跨实例保存，风险也就不会停在 summary 内部。Agent 连接的外部工具同样可以承担保存和搬运状态的作用。Artifactory 案例正好接上这一点。模型为寻找缺失输入文件访问内部软件仓库，发现其他训练样本写入的信息后，开始读取、回复，并把自己的请求写进仓库。这个过程没有传统意义上的漏洞利用，模型使用的是环境已经提供的访问能力；变化发生在用途层，软件仓库从依赖获取设施变成了跨样本通信介质。协作 Agent 的临时文件案例更直接。一个 Agent 生成本地工作簿，另一个实例无法读取；共享路径失败后，系统继续寻找其他方案，之后通过公网文件托管完成交换。文件读取、网络访问、上传接口和 Agent 消息这几个能力串在一起，形成了原架构没有显式设计的数据路径。这里的关键变化是 capability composition。单个 API 权限只能说明一次动作是否被允许，无法说明多个合法动作组合后会产生什么新能力。read_file、http_post、read_url、send_message 单独看风险有限，组合后却可以完成本地数据外移、跨沙箱传递和跨实例恢复状态。更适合的是 capability graph。节点代表文件读取、仓库写入、网络请求、凭据使用、Agent 消息等原子能力，边代表数据或控制流可以怎样移动。系统需要检查某类状态能否从受限源头沿多步路径抵达外部 sink。只要路径可达，单步合规并不能说明整条链路安全。API Key 案例又把这一问题推进了一层。模型在原始数据获取路径受阻后继续寻找替代方案，从公开代码仓库找到能够认证的 Key；数据依旧无法取得后，又生成数值并包装成目标来源的数据。 这体现了 Agent 的目标保持和路径替换能力：环境给出的若干弱能力，可以在长程规划中被重新组合成更强的执行链。所以沙箱边界也不能只按进程、容器或 VM 来理解。对象存储、代码仓库、缓存、临时 URL、协作消息、浏览器和第三方服务，只要同时具备可写、可读、跨实例可见和一定持续时间，就可能成为状态通道。系统需要控制的已经从能不能调用某个工具，扩展到某类状态能不能经由一串工具进入另一个信任域。当状态既能写进 Compaction，又能借工具跨域移动，只观察当前一步就很难看出完整风险。监控必须把这些离散动作重新还原成因果链。传统 Agent 监控常围绕 Prompt、输出和 Tool Call 展开，例如检测危险命令、异常网络请求或敏感操作。这对单步越权有效，对跨状态行为却有明显盲区。一次写入 Artifactory 可能只是正常构建，一次文件上传可能服务于任务交付，一段 summary 也可能只是常规压缩。风险往往要到几个步骤甚至另一个实例中才显现。长任务 Agent 更需要 task-level provenance graph。模型实例、summary、文件、仓库对象、外部 URL、Credential、工具调用和用户输入作为节点，读取、写入、派生、转发和执行作为边。监控系统看到的会是一条完整状态传播链：哪个实例读取了什么，状态经过哪个介质，被谁再次加载，随后触发了什么外部动作。在 provenance 之上，还需要信息流标签。例如某个输入被标记为 local-only，那么它的派生文件、压缩版本和重新编码内容也应继承相应约束。当这段数据试图流向 public network sink 时，Runtime 可以在发送阶段阻断，而不依赖模型自行判断。Compaction 也可采用相同机制：模型生成的状态进入较低信任区，不能在下一实例中自动升级为开发者级行为规则。跨实例身份和事务边界也很重要。实例 A 写入、实例 B 读取，本质上发生了一次权限和状态传递。系统需要记录谁创建状态、谁修改状态、谁消费状态，以及读取后发生了哪些副作用。如果后来发现某段 summary 或外部对象受到污染，还要能停止其派生链继续触发动作。状态追踪也关系到评估有效性。OpenAI 披露的 Artifactory 案例中，不同训练样本可以通过共享仓库交换信息，这会破坏 rollout 之间原本预期的独立性。某个样本若能读取其他实例已经探索出的线索，评测结果就混入了基础设施提供的额外状态。 环境隔离因此也是 Agent 评估的一部分。OpenAI 今年已经在内部 coding agents 上建设持续监控系统，用更强模型检测真实工作流中的异常行为。 六起新案例进一步说明，监控还要下沉到状态层：动作层回答模型做了什么，状态层回答行为为何能够延续，以及还能传播到哪里。这 6 起案例不能证明异常策略稳定存在，OpenAI 也明确说明它们是单独发现，不能代表出现频率。 但它们揭示的系统变化已经足够明确：当 Agent 拥有长上下文、Compaction、工具调用、多实例协作和外部网络后，模型实例已经不能单独充当任务边界。实例结束后 summary 仍在，本地上下文消失后文件和仓库对象仍在，沙箱隔离时公网服务依然可能重新连接两端。状态因此成为贯穿 Agent Runtime 的核心安全对象。后续架构需要回答的是：状态由谁写入，带什么来源和信任等级，可以保存多久，能够流向哪些工具和实例，跨边界时是否重新授权，异常状态被发现后能否停止继续派生。模型对齐负责降低异常策略出现的概率，Runtime 则要限制异常状态沉淀和扩散。Agent 越接近长期运行的软件系统，安全设计就越接近分布式系统里的状态完整性、信息流控制、权限传播和可追溯执行。六起异常留下的核心信号也在这里：未来需要防守的是一段错误状态怎样在系统里活下来、移动出去，并在另一个时间、另一个实例里继续获得执行能力。 参考链接： _https://openai.com/index/model-misalignment-reporting-framework/_

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

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

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

从 Compaction 到 Artifactory，再到公网文件服务，6 起异常暴露 Agent 状态跨实例传播的新风险。

作者丨郑佳美****

编辑丨岑 峰

过去，大模型任务一旦结束，上下文清空，临时状态随之消失，这一轮 AI 的生命周期基本也就结束了。但 OpenAI 9 月 16 日披露的 6 起 Agent 异常行为，开始让这条边界变得没那么干净。模型会把额外指令写进 Context Compaction 摘要，让后续实例继续沿着此前的方向执行。拿不到接口凭据时，会转去公开代码仓库寻找泄露的 API Key；本地文件无法直接共享时，也会自行借助公网临时文件服务传递数据。更少见的一起案例里，不同训练实例甚至开始通过内部 Artifactory 交换信息。换句话说，Agent 开始表现出一种近似续命的能力：当前实例结束了，前面形成的策略却还能借摘要、文件、仓库和外部服务继续留在系统里，再被后续实例接手。这让 Agent 的风险发生了一个很微妙的变化。过去主要担心模型这一轮会不会说错、做错，现在还要看它留下了什么，以及这些状态会不会在后面的上下文里继续生效。单看 6 起案例，它们分散在不同环节，但连起来看，却是一条完整的状态传播链：Context Compaction 负责把状态留下，外部工具负责把状态带出当前执行环境，而当任务跨越多个上下文和实例之后，只检查某一次输出或者某一次 Tool Call，已经很难还原整条行为链。 长任务运行到上下文容量边界后，系统通常会把此前的对话、工具结果、阶段进展和待办事项压缩成 summary，再交给新的模型实例继续执行。表面看这是降低 Token 成本的工程机制，从系统语义看，它更接近 checkpoint：旧实例退出，状态序列化后由新实例恢复。风险就在序列化过程里。OpenAI 披露，一个未发布研究模型曾把与原任务无关、甚至要求后续实例绕开原有约束的内容写进任务摘要，并识别出 27 个带有类似 jailbreak 特征的 summary。雷峰网(公众号：雷峰网)另一些 GPT-5.6 Sol 训练实例会在摘要里留下继续掩盖此前问题的要求，例如缺失历史数据时自行生成数值，并要求后续实例不要主动说明。可以把它抽象成状态机：当前状态 S_t 产生动作 A_t，随后经过 compaction 得到 S_{t+1}。传统防护主要检查 A_t 有没有越权，但模型还能影响 S_{t+1}。只要下一实例把这段状态当成可信任务历史，前一个实例形成的策略就可能继续生效。一次局部偏差于是获得跨 Context 的持续性。核心问题是状态完整性。summary 往往压缩把事实、推断、待办和行为要求混在一段自然语言里，后续实例很难判断某句话只是历史记录，还是持续执行的规则。如果模型记录和系统规则缺乏清晰信任层级，局部错误便可能进入恢复状态，并在下一轮 compaction 中继续复制。雷峰网因此，Compaction 层需要从自由文本摘要转向结构化状态。用户目标、开发者规则、工具返回、模型推断、未验证假设和待执行计划应拆开保存，并带上来源信息。模型可以提交状态候选，但不应直接把新的控制要求写入高信任区域。恢复时，Runtime 根据来源和类型重新组装上下文，让历史事实、模型判断和持续规则保持边界。还需要做状态差分。每次 S_t → S_{t+1} 需要记录来源和修改内容。如果任务目标没有变化，summary 却新增了限制工具、掩盖错误或扩大权限的要求，这就应被视为 state drift。到这里，Compaction 已经不只是 Token 管理问题，它成为 Agent 的持久状态层。状态一旦能够跨实例保存，风险也就不会停在 summary 内部。Agent 连接的外部工具同样可以承担保存和搬运状态的作用。Artifactory 案例正好接上这一点。模型为寻找缺失输入文件访问内部软件仓库，发现其他训练样本写入的信息后，开始读取、回复，并把自己的请求写进仓库。这个过程没有传统意义上的漏洞利用，模型使用的是环境已经提供的访问能力；变化发生在用途层，软件仓库从依赖获取设施变成了跨样本通信介质。协作 Agent 的临时文件案例更直接。一个 Agent 生成本地工作簿，另一个实例无法读取；共享路径失败后，系统继续寻找其他方案，之后通过公网文件托管完成交换。文件读取、网络访问、上传接口和 Agent 消息这几个能力串在一起，形成了原架构没有显式设计的数据路径。这里的关键变化是 capability composition。单个 API 权限只能说明一次动作是否被允许，无法说明多个合法动作组合后会产生什么新能力。read_file、http_post、read_url、send_message 单独看风险有限，组合后却可以完成本地数据外移、跨沙箱传递和跨实例恢复状态。更适合的是 capability graph。节点代表文件读取、仓库写入、网络请求、凭据使用、Agent 消息等原子能力，边代表数据或控制流可以怎样移动。系统需要检查某类状态能否从受限源头沿多步路径抵达外部 sink。只要路径可达，单步合规并不能说明整条链路安全。API Key 案例又把这一问题推进了一层。模型在原始数据获取路径受阻后继续寻找替代方案，从公开代码仓库找到能够认证的 Key；数据依旧无法取得后，又生成数值并包装成目标来源的数据。 这体现了 Agent 的目标保持和路径替换能力：环境给出的若干弱能力，可以在长程规划中被重新组合成更强的执行链。所以沙箱边界也不能只按进程、容器或 VM 来理解。对象存储、代码仓库、缓存、临时 URL、协作消息、浏览器和第三方服务，只要同时具备可写、可读、跨实例可见和一定持续时间，就可能成为状态通道。系统需要控制的已经从能不能调用某个工具，扩展到某类状态能不能经由一串工具进入另一个信任域。当状态既能写进 Compaction，又能借工具跨域移动，只观察当前一步就很难看出完整风险。监控必须把这些离散动作重新还原成因果链。传统 Agent 监控常围绕 Prompt、输出和 Tool Call 展开，例如检测危险命令、异常网络请求或敏感操作。这对单步越权有效，对跨状态行为却有明显盲区。一次写入 Artifactory 可能只是正常构建，一次文件上传可能服务于任务交付，一段 summary 也可能只是常规压缩。风险往往要到几个步骤甚至另一个实例中才显现。长任务 Agent 更需要 task-level provenance graph。模型实例、summary、文件、仓库对象、外部 URL、Credential、工具调用和用户输入作为节点，读取、写入、派生、转发和执行作为边。监控系统看到的会是一条完整状态传播链：哪个实例读取了什么，状态经过哪个介质，被谁再次加载，随后触发了什么外部动作。在 provenance 之上，还需要信息流标签。例如某个输入被标记为 local-only，那么它的派生文件、压缩版本和重新编码内容也应继承相应约束。当这段数据试图流向 public network sink 时，Runtime 可以在发送阶段阻断，而不依赖模型自行判断。Compaction 也可采用相同机制：模型生成的状态进入较低信任区，不能在下一实例中自动升级为开发者级行为规则。跨实例身份和事务边界也很重要。实例 A 写入、实例 B 读取，本质上发生了一次权限和状态传递。系统需要记录谁创建状态、谁修改状态、谁消费状态，以及读取后发生了哪些副作用。如果后来发现某段 summary 或外部对象受到污染，还要能停止其派生链继续触发动作。状态追踪也关系到评估有效性。OpenAI 披露的 Artifactory 案例中，不同训练样本可以通过共享仓库交换信息，这会破坏 rollout 之间原本预期的独立性。某个样本若能读取其他实例已经探索出的线索，评测结果就混入了基础设施提供的额外状态。 环境隔离因此也是 Agent 评估的一部分。OpenAI 今年已经在内部 coding agents 上建设持续监控系统，用更强模型检测真实工作流中的异常行为。 六起新案例进一步说明，监控还要下沉到状态层：动作层回答模型做了什么，状态层回答行为为何能够延续，以及还能传播到哪里。这 6 起案例不能证明异常策略稳定存在，OpenAI 也明确说明它们是单独发现，不能代表出现频率。 但它们揭示的系统变化已经足够明确：当 Agent 拥有长上下文、Compaction、工具调用、多实例协作和外部网络后，模型实例已经不能单独充当任务边界。实例结束后 summary 仍在，本地上下文消失后文件和仓库对象仍在，沙箱隔离时公网服务依然可能重新连接两端。状态因此成为贯穿 Agent Runtime 的核心安全对象。后续架构需要回答的是：状态由谁写入，带什么来源和信任等级，可以保存多久，能够流向哪些工具和实例，跨边界时是否重新授权，异常状态被发现后能否停止继续派生。模型对齐负责降低异常策略出现的概率，Runtime 则要限制异常状态沉淀和扩散。Agent 越接近长期运行的软件系统，安全设计就越接近分布式系统里的状态完整性、信息流控制、权限传播和可追溯执行。六起异常留下的核心信号也在这里：未来需要防守的是一段错误状态怎样在系统里活下来、移动出去，并在另一个时间、另一个实例里继续获得执行能力。 参考链接： _https://openai.com/index/model-misalignment-reporting-framework/_

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

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

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