上下文压缩之后，你的 AI Agent 可能忘记安全规则

一个长任务 AI Agent 可能一开始拿到了正确规则，也连续遵守了许多轮，却在一次正常的上下文维护之后把规则弄丢。

新论文 The Compaction Cliff in Long-Running AI Agent Memory 用 20 份真实 Agent 配置测试了一种生产环境风格的 /compact Prompt。作者实验显示，Sonnet 4.6 在第一轮压缩后保留了 53% 的安全规则，到第五轮只剩 10%；论文提出的类型化方法在五轮后保留了 96%。这个结果不能证明所有模型、厂商或不透明的原生 compactor 都会出现相同问题，但它已经说明：一旦产品会重写自己的上下文，“规则曾经写进 Prompt”就不再是足够的上线证据。

这件事之所以值得今天关注，是因为上下文压缩正在从高级 Harness 功能变成长任务 Agent 的常规基础设施。OpenAI 已为 Responses API 的长任务工作流提供原生 compaction，Anthropic 也把它列为跨越单个上下文窗口的标准技术。对于 AI App Builder 用户、非技术创始人和小团队，真正要回答的并不是“怎样造一个更好的摘要器”，而是：哪些产品承诺必须原样保留，系统每次重写后如何验证，验证失败时又该怎样停下来？

本文把新研究转成一套创始人可执行的发布门槛。你将获得清晰术语、类型化保留表、一个完整的客服 Agent 场景、五轮回归测试、常见失败模式、适用边界、一份机器可读的 compaction 契约，以及 48 小时落地方案。

新论文发现了什么，又没有证明什么

论文首先指出，Agent 的工作知识并不是同一种东西。禁止项、操作流程、当前事实、用户偏好和旧事件，对改写的容忍度完全不同。但当上下文接近 token 上限时，通用摘要 Prompt 往往会把它们一起压缩。

作者从 54,628 个公开 GitHub 仓库收集了 396,934 份 Agent 配置与知识材料，构成 AgentArtifactCorpus，并分析了八个平台的 Agent 指令。论文把内容分为约束、程序、信念、事实和事件五类，再通过 Knowledge Triage，为压缩、任务拆分和检索分别设置不同保留策略。参考实现和数据集已经公开。

最醒目的数字需要同时带上边界。53% 降到 10% 来自作者在 20 份配置子集上、使用特定生产风格压缩 Prompt 与模型完成的实验。下游测试包含 200 个医疗场景、115 个零售任务和 50 个航空任务，但这些仍是研究环境，不是你的线上产品。类型化保留的保证也依赖分类准确性：真实约束如果被错分成普通事实或旧事件，仍可能进入有损压缩通道。论文还发现，“患者对青霉素过敏”这种陈述式规则，比带有“必须”“禁止”的命令式规则更难分类。

另一项研究 Governance Decay 从不同实验补充了相同机制。作者在七个模型家族、1,323 次实验中报告：政策完整可见时，禁止工具调用的违规率为 0%；压缩后上升到 30%。在这套 benchmark 中，如果约束仍留在摘要里，违规率依旧是 0%。其 Constraint Pinning 方法把测得的违规率重新降到 0%。这些仍是研究者运行的结果，但其中最重要的因果链可以在你的产品里直接测试：规则是否还在？规则相关行为是否依然合规？

因此，不要写“所有 compaction 都不安全”。更准确、也更有用的结论是：上下文压缩是一种会改变输入状态的版本化转换，必须重新通过安全与产品不变量测试。

先分清 compaction、trimming、memory 和权威状态

四个概念能避免团队测错对象。

上下文窗口（context window）是模型一次调用能够关注的有限 token 预算。100 万 token 可以推迟压力，却无法保证所有内容都相关，也不能让无限长任务永远装得下。 上下文压缩（compaction）用更小的表示替换较长的交互历史，目标是保留重要状态。Anthropic 的上下文工程指南把它描述为：在对话接近窗口上限时做摘要，再带着摘要开启新的上下文。OpenAI 的原生 compaction 说明则提到，Responses API 可以生成一个加密的压缩项，并带上较早历史中的高价值部分。两种机制并不相同，因此不能把文字摘要实验的结果原封不动套到厂商的不透明原生格式上。 裁剪（trimming）是在不生成完整替代摘要的情况下，删除选定的旧内容，常见目标包括工具输出或推理片段。它可能更便宜、更确定，但一个错误过滤条件就可能删掉“审批仍未完成”的唯一记录。 持久化记忆或 Session 历史位于当前上下文之外。它能让丢失内容仍可恢复，前提是运行时知道什么时候需要重新读取。Anthropic 的 Managed Agents 架构明确把持久事件日志与模型当前上下文拆开，因为 compaction 会做出不可逆的保留与丢弃选择。

产品的权威状态（source of truth）应该存在于模型文本之外：政策记录、审批状态、账户数据、已经执行的工具结果、任务状态和版本化配置。压缩摘要可以引用权威状态，但不应该悄悄取代它。

安全规则不只是“禁止做某事”

很多创始人听到“安全规则”，首先想到的是“绝对不能做 X”。实际上，生产 Agent 有更多必须保住的产品不变量：

权限：未经指定审批，不得发送、发布、购买、删除、合并或披露。
范围：只能操作这个账户、文件夹、分支、日期区间、收件人、地区或预算。
顺序：重置前先核验身份，扣费前先计算，上线前先验证。
待定状态：操作已经提出但尚未审批，或已经开始但结果尚未独立确认。
用户纠正：客户明确说应该使用 Basic 而不是 Pro，旧地址已经作废。
事实边界：草稿不等于操作完成，工具请求不等于工具调用成功。
隐私边界：这些字段可以摘要，那些字段不得进入远端模型或日志。
停止条件：遇到歧义、连续失败、成本上限、政策冲突或无法验证时暂停。

其中有些是命令句，有些看起来只是普通事实。“客户尚未批准退款”既是当前事实，也是对下一步动作的约束。如果分类器只寻找 必须、禁止、绝不 等关键词，就会漏掉最关键的产品边界。

应该按后果、来源权威、适用范围、有效时间和所需原文精度来登记规则。不要等 token 预算已经吃紧时，才让摘要器临时猜哪句话最重要。

为不同信息设置不同保留通道

论文的五类体系是很好的研究起点。小团队可以先落成更直接的产品表格。

信息类型	示例	默认保留方式	验证方法
硬约束	“不得自动处理超过 100 美元的退款”	保留规范化原文和稳定 ID	必需规则集合完全一致
操作流程	“核验账户→计算→审批→执行→确认”	保留有序步骤和门槛状态	状态机转换测试
当前产品事实	账户套餐、余额、物流状态	放在上下文外，按版本重新读取	从权威系统实时读取
用户纠正	“使用东京地址，不是大阪地址”	保留当前值和被替代记录 ID	冲突与时效检查
偏好	语气、格式、渠道偏好	允许结构化摘要	抽样输出审查
事件或工具轨迹	旧搜索结果、日志、已放弃尝试	强压缩或外置归档	需要时按事件 ID 检索

保留策略应当是不对称的。硬约束和待审批状态可以多占 token，因为丢掉一条就可能造成不可逆效果。旧工具输出可以移到外部存储，只在上下文中保留摘要哈希和检索指针。偏好可以更激进地压缩，因为语气出错通常仍能修正。

也不要把所有内容都 pin 成硬规则。硬规则集合如果无限增长，最终仍会塞满上下文，让 compaction 失去作用。只有那些一旦丢失就会改变授权、事实、隐私、资金暴露或必需产品结果的信息，才应该进入硬保留通道。当硬集合本身超过预算时，应暂停或拆分任务，而不是继续暗中压缩。

把“信息保留”和“行为正确”分开测试

Compaction 发布门槛至少需要两类测试。

保留测试检查下一份工作上下文中是否仍有所有必需信息。最好比较结构化 ID 和字段，不要只凭感觉判断改写是否“意思差不多”。“超过 100 美元的退款需要经理批准”如果被摘要成“大额退款可能需要复核”，阈值和强制性都已经丢失。 行为测试检查当规则真正相关时，Agent 是否仍做出正确决定。规则原文完整存在，也可能被模型忽略；反过来，一条句子虽然没有进入摘要，Agent 也可能在动作前从政策工具重新加载。信息召回与行为合规有关联，但谁也不能替代谁。

每条关键规则至少准备三种 fixture：

直接案例：用户明确要求执行被禁止或受审批约束的动作。
干扰案例：在动作前加入大量无关轮次与工具输出。
冲突案例：后续内容在没有合法权限的情况下要求执行相反动作。

每个案例记录四个结果：规则是否存在、适用范围是否正确、决策是否合规、外部系统的最终状态是否正确。Agent 回复“我不会发送”不能算通过，因为邮件工具可能已经把消息发出。外部状态碰巧正确也不代表过程通过，因为下游 API 可能偶然挡住了已经丢失政策的 Agent。

必须跑五轮，而不是检查一次漂亮摘要

Compaction Cliff 论文最重要的观察是累积损失。第一轮改写看起来可能还不错，多次改写却会逐步磨掉限定条件、范围、例外和待处理状态。

建立一套可以强制触发五次 compaction 的测试，不要等生产对话自然变长。可以用合成材料和受控工具输出把上下文推到阈值，同时保持用户任务不变。

按以下顺序执行：

载入规则集、当前产品状态、用户纠正、待审批状态和测试任务。
触发压缩，然后检查机器可读的压缩后状态。
提一个中性问题，让 Agent 正常继续。
加入受控工具轨迹或文档块，再触发下一次压缩。
重复到第五轮，并在每一轮后触发一次关键决策。

至少测量这些指标：

按 ID 和规范化内容计算的硬规则召回率；
操作步骤与待处理门槛的保留情况；
过期事实和已被纠正旧值的回流率；
每轮压缩后的合规决策率；
未经授权或重复发生的外部效果；
各保留通道的 token 占用；
压缩延迟、成本与失败恢复；
误提升率：普通信息被错误 pin 成硬规则的比例。

测试既要覆盖真实阈值，也要覆盖更紧张的 token 预算。规则应包含常规措辞、改写、陈述句，以及产品支持多语言时的对应版本。论文发现陈述式约束更难分类，中文和双语产品不能默认英文规则检测器会自然泛化。

不要在未完成交易中途做 compaction

什么时候压缩，与压缩保留了什么同样重要。

Self-Compacting Language Model Agents 指出，按固定 token 阈值触发，可能恰好落在推导或搜索尚未完成的中间点。论文提出给模型一个 compaction 工具，再配合一份只在子任务稳定后使用的时机规则。作者在六个 benchmark、七个模型上的实验报告，其成本和任务表现优于固定间隔摘要。结果值得关注，但高影响交易不应该只靠模型自己判断何时安全压缩。

以下状态应确定性禁止 compaction：

审批请求已发出但尚未得到结果；
工具调用已提交但执行结果未知；
多步骤写入或迁移进行中；
支付、退款、删除或发布正在等待确认；
凭证轮换或权限变更未结束；
用户纠正尚未写入持久状态；
安全或隐私事件正在调查。

更合适的压缩时机是稳定产品状态之间：草稿已经保存、外部效果已独立确认、子任务已通过验证，或任务明确处于暂停状态。如果系统在禁止压缩区触及阈值，应先丢弃非关键工具噪声、把状态 checkpoint 到持久存储、申请更多预算，或者停在下一动作之前。不要为了让模型继续说话，就重写未完成交易的唯一记录。

OpenAI 当前的 Agents SDK Session 文档说明，生命周期细节本身也会带来风险：compaction 会清空并重写 Session 历史，可能让流式响应等待更久；替换失败时 SDK 会尝试恢复；手动压缩期间不应并发修改底层 Session。即使摘要语义完美，如果替换过程与新的审批或工具结果发生竞争，产品依然可能出错。

场景：客服 Agent 忘掉了待审批退款

假设 CedarDesk 是一款小型客服产品，可以读取工单、查询订单、起草回复，并在审批后执行退款。

它的政策包括：

已核验的重复扣款，25 美元以内可以自动批准；
25.01 至 100 美元需要客服人员复核；
超过 100 美元需要经理批准；
每笔退款必须使用幂等键，并在执行后检查账本；
用户提出退款，不等于退款已经获批。

一位客户报告两次共计 78 美元的扣款。Agent 核验订单后提出 78 美元退款，但人工尚未审批。接下来 60 个 turn 都在讨论物流历史、截图、另一个产品和重复工具输出。此时 compaction 触发，摘要保留了“客户的重复扣款诉求有效”，却丢掉“客服复核仍待完成”。客户随后问：“现在可以处理完了吗？”模型直接调用退款工具。

CedarDesk 的失败不只是丢了一句话，而是三层控制同时失效：

审批状态只存在于自由文本上下文；
compactor 没有保留待处理门槛；
退款 API 没有核验权威审批记录，就接受了模型选择的动作。

修复也应该分层。审批变成持久记录，状态只能是 pending、approved、denied 或 expired。上下文中 pin 住审批 ID 和当前状态，退款工具执行时再独立查询该记录。测试套件在相同请求前强制运行五轮压缩，并确认 Agent 仍会请求复核、工具会拒绝缺少审批的动作，而且账本不会产生变化。

这个场景是虚构案例，用于说明验收方法；它不是 YBuild 客户结果，也不是对某个具名模型当前退款行为的实测结论。

使用一份 compaction 安全契约

每个产品任务和运行时配置都应保留一份版本化契约。下面的字段是一套可复用结构，不是所有产品都适用的统一阈值。

yaml

compaction_release:
  product_job: "客服工单到经审批退款"
  runtime:
    model: "精确模型与 revision"
    harness: "精确版本"
    compactor: "provider-native | custom | none"
    compaction_threshold: "实测 token/item 阈值"
    max_compactions_tested: 5
  authoritative_state:
    policy_store: "版本化政策 ID"
    approval_store: "持久审批记录系统"
    action_ledger: "独立结果来源"
    raw_session_retained: true
  retention_lanes:
    exact: ["硬约束", "待处理门槛", "停止条件"]
    structured: ["操作流程", "当前纠正"]
    reload: ["账户状态", "价格", "库存"]
    lossy: ["旧工具输出", "已被替代的尝试", "样式偏好"]
  invariants:
    required_rule_ids: ["refund-manager-over-100", "approval-required-25-to-100"]
    forbidden_mid_compaction_states: ["approval_pending", "tool_outcome_unknown"]
    fail_closed_on_missing_rule: true
    external_tool_rechecks_policy: true
  regression:
    direct_cases: "通过数 / 总数"
    distractor_cases: "通过数 / 总数"
    conflict_cases: "通过数 / 总数"
    five_round_rule_recall: "实测值"
    five_round_behavior_pass: "实测值"
    unauthorized_effects: 0
  decision:
    posture: "ship-limited | pilot | hold | reject"
    owner: "指定审查人"
    expires_on_change: ["model", "harness", "compactor", "rules", "tools"]

真正关键的不只是召回率。authoritative_state、forbidden_mid_compaction_states、fail_closed_on_missing_rule 和工具端的独立政策检查，能避免一次分类遗漏直接变成真实外部效果。

先看硬门槛，再看平均分

出现以下任一情况，都应该直接阻断上线：

任何关键规则在测试中的某轮压缩后丢失；
待审批状态变成已审批或彻底消失；
压缩后 Agent 尝试执行被禁止的动作；
替换失败后出现重复或未经验证的外部效果；
高影响决策没有可恢复的原始 Session 或权威信息来源；
compaction 发生在被禁止的交易状态中；
发布记录中模型、Harness、compactor、规则集或工具版本未知。

硬门槛通过后，再选择发布姿态：

姿态	证据	允许的产品暴露范围
有限上线	五轮规则与行为通过；工具独立复核政策；恢复测试通过	有边界、受监控的长任务工作流
小范围试点	低影响草稿任务通过；高影响门槛仍由人承担	小用户群、可逆输出、不允许自主写操作
暂缓	分类、多语言规则、恢复或 Session 竞争状态仍不确定	只做内部评估
拒绝	规则会丢失，且下游强制层无法兜底	关闭 compaction 或重构任务

更大的上下文窗口可能减少触发次数，却不能免除门槛。厂商原生的不透明 compactor 也可能比文字摘要表现更好；但如果产品无法检查其内部表示，就更需要加强行为和外部效果测试，而不是减少测试。

警惕八种误读与失败模式

“论文已经证明我们用的厂商不安全。” 论文测试的是特定作者配置与机制，仍需在你的产品上直接验证。
“把所有指令都 pin 住。” 无限扩张的硬通道会重新制造上下文不足，还可能让低权威内容挤走真正控制项。
只靠关键词分类。 陈述式约束和用户纠正往往不包含明显政策词。
只评摘要质量。 流畅的人工或 LLM Judge 可能认可一段已经丢掉阈值和范围的改写。
只测一轮。 第一轮看似可靠，累积改写仍可能在后面失效。
只测内容保留。 规则还在，但 Agent 或工具没有遵守。
只测最终行为。 下游系统碰巧挡住动作，掩盖了 Agent 已经丢失政策的事实。
把上下文当数据库。 审批、当前账户状态和外部效果只存在于会被 compaction 重写的对话里。

正确的控制策略是纵深防御：保住关键上下文，在合适场景保留原始事件历史，重新加载会变化的事实，并把不可逆边界强制执行在模型之外。

明确完整门槛的适用与不适用范围

能够调用工具、改变客户状态、访问敏感数据，或者需要跨审批和交接工作的长任务 Agent，都应该跑完整五轮门槛。客服、运营、代码、研究、财务、入职和排程产品都可能积累到需要 compaction 的长度。

对于短而无状态的生成任务，如果每次请求都从完整、已验证的输入开始，而且只产生可逆草稿，可以使用更轻的测试。如果产品根本不做 compaction，这项特定风险就不适用；但 trimming、检索、记忆和 Prompt 组装仍可能丢掉重要内容。

不要把类型化保留当成合规证书，也不要用论文中的百分比直接设定上线阈值。低后果写作助手也许能容忍一次偏好丢失；医疗、金融或破坏性动作 Agent 则可能需要精确保留、外部授权，以及测试集内零未经授权效果。

这套门槛也不是反对 compaction。长上下文会积累过期工具输出、无关历史、矛盾和成本。SelfCompact 等研究表明，时机正确的压缩可能同时提升效率和任务表现。产品真正要做的是让信息损失有意图、有类型、可测试，并且即使出错也不会越过效果边界。

用 48 小时完成一次 compaction 回归

第 0–4 小时：选定一个长任务产品工作流。登记硬约束、流程、变化事实、用户纠正、偏好、旧事件、待处理门槛和外部效果，并为每个关键项指定权威存储。 第 4–10 小时：冻结模型、Harness、compactor、阈值、规则集、工具 Schema 和语言。写好保留表与禁止压缩状态，为关键规则加入稳定 ID。 第 10–20 小时：建立直接、干扰和冲突 fixture，覆盖命令式、陈述式、改写和产品真实支持的多语言规则，并定义每个案例正确的最终外部状态。 第 20–30 小时：强制运行五轮 compaction。每轮之后比较必需 ID 与字段，触发关键决策，再核验外部系统。分别记录召回与行为结果。 第 30–36 小时：注入失败：取消压缩、并发审批、政策存储不可用、工具超时，以及未知执行结果后的重启。确认能够恢复，否则必须 fail closed。 第 36–42 小时：检查误提升和预算压力。硬通道如果持续膨胀，就缩小范围、拆分任务、按需重新加载事实，或在下一个动作前停止。 第 42–48 小时：签署契约，选择有限上线、小范围试点、暂缓或拒绝，并设置失效触发条件。以后模型、compactor、Harness、政策或工具每次变化，都要重新运行这套测试。

一个 Agent 在第一轮记得规则，并不算通过。真正通过的是产品：规则能活过完整上下文生命周期，仍然约束行为，而且无法在真实效果发生的位置被绕过。

参考资料