你可能遇到过这样的情况。

一开始，你明确告诉 Agent：“不要改原有格式”“不要编造数据”“总预算不能超过 8000 元”。前几轮它都记得，也一次次确认。

可任务越跑越久，token 一路烧，时间也一点点耗掉。你看着它查资料、调用工具、反复修改，以为终于要拿到结果，交付物却和预期大相径庭：原有格式被改了，缺失数据被补得煞有介事，或者最关键的预算限制被直接忽略。前面的成本已经付出，结果却不能用，你只能气得在聊天框里疯狂输出：“我不是一开始就说过吗？”

最让人恼火的是，它并没有完全忘记任务。它还知道要写什么、改什么、去哪里，甚至能复述大部分背景。它只是丢掉了一个决定结果能不能使用的条件。

看到这种结果，人们很容易把问题归结为“模型不够聪明”。但这个判断并不准确。模型能力当然会影响表现，这里暴露的却是另一类问题：模型理解过一条要求，不等于这条要求会在后续每次行动中持续生效。即使模型足够强，长任务仍然需要明确维护当前有效的要求、后续修订和完成证据。

类似的吐槽并不少见：有开发者抱怨 Claude Code 明明读过项目规则，下一轮仍照样越界；Cursor 用户也报告过，上下文压缩后，规则虽然还在，Agent 却更难持续遵守。用户感受到的是 Agent“越来越不听话”。这些现象未必来自同一个原因，却会造成同一种结果：一条始终存在、甚至仍能被准确复述的要求，最终没有可靠地约束 Agent 的行动和交付结果。

这类问题很容易被概括成“上下文不够长”。现在，部分模型的上下文窗口已经进入百万 token 级别。以 GPT-5.6 Sol 为例，OpenAI 标注的上下文窗口是 1,050,000 tokens。窗口变大当然有用：Agent 可以在压缩旧内容前保留更多代码、工具输出和对话历史。但容量变大，并不等于关键要求从此不会丢失。

问题不只在于 Agent 能“看见多少”，还在于它能否持续判断：哪些要求仍然有效，哪条新要求替代了旧要求，以及它凭什么宣称任务已经完成。

1. 1M 上下文解决了什么，又没有解决什么？

1.1 窗口是容量上限，不是一张优先级清单

上下文窗口回答的是“一次推理最多能放进多少内容”。它不会给每句话附上永久优先级，也不会自动把一句“绝对不要修改附录”变成贯穿后续几十轮操作的硬约束。

长任务里通常同时存在原始需求、补充说明、失败日志、网页正文、工具输出和多个中间版本。即使它们都还在窗口内，模型仍要在每次行动前重新判断什么最重要。《Lost in the Middle》在多文档问答和键值检索实验中发现：相关信息放在输入开头或结尾时表现通常最好，移到中间时准确率会明显下降，而且这种现象在显式支持长上下文的模型中仍然存在。窗口能容纳信息，只说明信息还在，不说明模型会在需要时稳定地使用它。

上下文越长，这个区别越重要。1M tokens 并不是一份被整理过的需求文档，而更像一个很大的工作台：东西都可以放上去，但关键约束可能被大量过程材料包围。把更多内容塞进窗口，不能代替对重要状态的筛选和维护。

1.2 遵守要求，比找到一句话更难

很多长上下文测试考察的是单点检索：在大量文本里埋入一条信息，再问模型能否找出来。但真实要求很少是一根孤立的“针”。它们经常分散在不同轮次，而且带有条件、否定和依赖关系：

• “不要改表格格式”，但允许更新其中三列；
• “预算不超过 8000 元”，同时还要包括市内交通；
• “周三下午不能安排景点”，而不是简单记住“周三见朋友”；
• “只有官方来源确认后，才能写成已预约”。

Agent 要找到这些句子，把它们组合起来，映射到当前正在执行的动作，并在输出前检查是否全部满足。这已经从检索变成了多步推理和约束执行。

一项针对五个百万上下文模型的近期研究给出了更直观的对比：最强模型在 1M tokens 的单点检索中仍能达到 100%，但任务改为串联三处信息后，所有模型都出现了不同程度的下降。有些模型到 512K 仍保持 80% 以上、到 1M 后小幅下降，有些则在 512K 到 1M 之间明显崩落。研究使用的是古典中文语料，不是在测试 Agent 是否会忘记命令；但它说明了一个与这里直接相关的事实：标称窗口长度不能代表模型可以同样可靠地组合窗口里的全部信息。

1.3 完整历史，不等于当前任务状态

真实任务还会不断变化。用户可能先说“控制在 1 万元以内”，后来改成“最多 8000 元”；可能补充“周三下午已经有安排”，也可能明确撤销一项原要求。

如果只是保留完整对话，新旧版本会同时存在。Agent 仍然需要回答：哪条正在生效，哪条已经被替代，哪条只适用于某个文件，哪处冲突还需要确认。聊天记录按时间保存“说过什么”，任务状态则要表达“现在应该做什么”。二者不是同一种数据结构。

因此，更多历史有时只是更完整地保存了冲突。没有显式的修订关系，Agent 可能继续执行旧要求，也可能把一句补充说明误认为对全部任务的替换。

1.4 记得要求，不等于已经满足要求

即使 Agent 正确找回了要求，任务也还没有结束。它可能记得“必须查官方来源”，也成功打开了一个网页，但这不证明页面是官方的、信息是最新的，更不证明预订已经完成。它也可能交付了七天行程和预算汇总，却在周三下午排入了另一个景点。

这说明长任务至少包含三类状态：当前有效的要求、已经完成的工作，以及能够证明要求被满足的证据。对话历史主要记录前两者发生过什么，却不会自动建立“要求—证据”的对应关系。没有这种对应，Agent 很容易把“做过一次搜索”“运行过一个命令”或“产出了一份文件”当成整个要求已经通过。

1.5 压缩不是根因，但会放大问题

百万上下文仍然是有限的。任务继续增长后，Agent 可能压缩较早内容，或在恢复任务时依赖一份摘要。摘要是一种有损压缩：它往往保留任务主线，却更容易省略否定约束、验收条件、尚未解决的冲突和刚刚发生的修订。于是，“去北京做七日行程”留了下来，“母亲不能走太多”和“未核实不能写成已预订”却可能消失。

Codex 的公开 issue 中已经出现了两种具体表现。Issue #19910 报告称，中途压缩后，Agent 没有继续携带活动目标中的完成审计要求，因而把局部验证当成了整个目标已经完成；Issue #35226 中，Agent 仍记得项目方向，却忘了执行进度，反复读取相同文件和重做分析。这是两个公开案例，不足以说明问题出现得有多频繁，但它们共同指向一个区别：主目标被保留下来，不等于任务状态被保留下来。

更大的窗口确实能推迟压缩，并让 Agent 直接访问更多原始材料。不过“全部放进去”也有现实成本。按 GPT-5.6 Sol 当前的 API 计价，输入超过 272K tokens 后，不只是超出的部分，而是整次请求都按输入 2 倍、输出 1.5 倍计费。长上下文因此更适合被看作一种资源，而不是越接近上限越好的默认目标。

所以，1M 上下文缓解了容量问题，却没有自动解决优先级、修订、进度和验收问题。真正需要稳定保存的，通常不是全部聊天记录，而是少量仍然有效的要求、它们的修订关系，以及完成这些要求所需的证据。Context Guard 就是沿着这个思路设计的。

2. Context Guard 具体解决什么问题？

Context Guard 是我为 Codex 开源的本地正确性保护层。它不保存整段对话，也不试图替代模型的记忆，而是用生命周期 hooks维护一份私有、可验证的要求与证据账本。

用一个更生活化的例子说明。假设你先告诉 Agent：

下周从武汉去北京玩七天，帮我做一份行程。

Agent 开始查高铁、酒店和景点后，你又陆续补充：和母亲同行；母亲膝盖不好，每天不能走太多；往返都坐高铁，不坐飞机；两人总预算不超过 8000 元；周三 15:00—19:00 要去海淀见朋友；想去故宫；凡是依赖预约的项目，都必须以当前官方信息核实，没核实就不能写成“已订好”。

随着 Agent 比较车次、酒店、预约规则和每日路线，对话越来越长。发生上下文压缩后，摘要也许仍记得“武汉到北京七日游”，却漏掉母亲的步行限制，或把景点排进周三下午；它也可能引用一篇过期攻略，把尚未核实的开放时间和余票写成已经确认。

这时，Context Guard 保护的不是全部聊天记录，而是随任务逐步形成的契约：

[ ] 下周武汉到北京，七天往返
[ ] 两人出行：用户和母亲；总预算不超过 8000 元
[ ] 往返均乘高铁，不坐飞机
[ ] 母亲膝盖不适：控制步行量，避免连续安排高强度行程
[ ] 周三 15:00—19:00 在海淀见朋友，该时段不可占用
[ ] 安排故宫
[ ] 预约、开放时间、价格和交通信息需用当前官方来源核实
[ ] 未核实或未预订的项目必须标为“待确认”

搜索、比较、排行程、算预算和调用其他 Agent，仍然由 Codex 完成。Context Guard 只记录与正确性直接相关的状态：用户要求、后续新增或修订、工具返回的可用证据，以及尚未完成的工作。

在 /compact 或任务恢复后，这份清单会重新进入上下文。如果还没有检查周三时段是否空出，或“用官方来源核实故宫预约”没有对应的成功证据，Context Guard 会将相关要求保留为未完成，而不会仅因为行程已经生成就接受“行程已经完整规划”的结论。至于行程内容是否真正满足步行量和时段要求，仍需由 Codex、检查工具或用户判断。

它不是让摘要变得更长，而是避免任务契约在摘要里被悄悄改写。

3. 它如何工作？

Context Guard 不替代 Codex 原生的 Plan、Goal、上下文压缩或子 Agent。它只维护一份较小的正确性状态：当前有哪些有效要求、要求如何被修订、哪些证据已经成功、还有什么没有完成。

它主要做四件事：

• 保留有效要求。 压缩或恢复后，重新注入的不是整段聊天，而是仍然生效的任务契约。
• 记录修订关系。 新要求可以补充或替代旧要求；遇到含糊冲突时，先保留原要求，而不是猜测用户已经撤销。
• 用证据限制完成声明。 成功打开网页或运行命令，只能证明这个动作执行过。证据还需要对应正确的要求、对象和范围；含糊结果不能直接关闭任务。
• 区分局部结果与根任务。 子 Agent 可以完成受委派的工作，但无权修改用户给根任务的要求，局部完成也不会自动升级为整体完成。

此外，Context Guard 也可以记录一份执行契约。显式采用后，它按角色分开记录任务中的来源：

来源	决定什么	边界
用户要求	任务目标与写入授权	不能被其他来源扩大
AGENTS.md 与已选 Skill	工作流程与安全约束	冲突时以用户要求为准
Codex Plan	可调整的执行步骤	可修改，但完成门不依赖它
工具、文件、图片和公开读回	哪些事实已经成立	可纠正事实假设，但不能扩大授权

一切都发生在 Codex 的权限、沙箱与 Hook 信任边界之内。

这份执行契约默认处于休眠状态：只有发起根任务的用户可以显式采用（context-guard adopt <project-relative-json>），采用后它会记录、恢复并在完成时核对这份契约。被采用的 Skill 或 Codex Plan 一旦变化，旧绑定会标记为需要重新确认，而不是继续按旧内容执行。Context Guard 不会改写 Codex Plan、拦截工具调用、自动发布，也不会授予新的权限。

为了避免保护层本身误判，Context Guard 会判断 Agent 输出的一句话是在讨论“完成”，还是在正式宣布整个任务已经完成。比如，Agent 说“任务完成了吗？”是在提问，说“任务还没有完成”是在否定，说“‘任务已完成’这种说法并不准确”是在讨论措辞；这些都不是 Agent 对任务状态作出的完成声明。相反，如果 Agent 直接说“任务已完成”——哪怕只是把这句话单独放在引号里——或者明确说“我已经完成了所有要求”，仍然必须通过完成门的证据检查。

如果下一步需要用户确认、等待外部系统，或已明确延期，Context Guard 会保留未完成项，而不是把“当前可以停下”误写成“整个任务已经完成”。按项目的隐私与保留设计，运行时账本默认保存在本地，不进入项目 Git，也不复制完整对话。

4. 安装与适用范围

按当前公开的环境要求，项目需要 Python 3.10 或更高版本，已验证的 Codex CLI 最低基线为 0.146.0。安装命令如下。

macOS 和 Linux：

git clone https://github.com/GreenLv/codex-context-guard.git
cd codex-context-guard
python3 scripts/manage_plugin.py --apply

Windows：

py -3.10 scripts\manage_plugin.py --apply

安装完成后，可以在 Codex 对话中使用以下控制命令来启用 Context Guard、查看状态或进行诊断：

$context-guard
context-guard status
context-guard diagnose

Context Guard 适合持续时间较长、要求会继续变化，并且需要工具结果证明完成的任务，例如：

• 规划复杂旅行，同时追加预算、同行人、固定时段或交通方式等约束；
• 撰写或修改文档，同时保护模板、术语、数字和不可改范围；
• 重构代码，同时保持接口、数据格式或兼容行为；
• 批量运行实验或处理文件，避免把局部成功说成全部完成；
• 协调多个子 Agent，同时区分根任务授权与有限委派。

一次对话内即可完成的小改动，通常没有必要启用完整流程。项目公开的五个匿名、工具调用较多的桌面任务样本中，Context Guard 0.6.1 的直接 Hook 与恢复上下文约占总 token 的 1.4%，计入插件触发的检查后约为 1.5%，可把 1%—2% 视为相近长任务的量级估计。这是小样本观察，不是对所有任务的保证。

项目已经完成 macOS 和 Windows 的有限范围原生验收；Linux 目前只声明源码 CI。它也不是语义正确性证明器、安全沙箱、云同步或完整对话备份。完整安装、验证范围和使用边界见中文 README、Compatibility 和 Local release acceptance。

5. 总结

Context Guard 的核心思路很简单：

不要从一份压缩后的摘要里猜测任务契约。把仍然有效的要求和完成证据保存在本地、可验证的账本中；压缩后恢复它们，再判断任务是否真的完成。

1M 上下文让 Agent 能携带更多材料，但“能携带”与“不会丢掉关键要求”仍是两件事。对长任务而言，真正需要稳定保存的往往不是全部聊天记录，而是少量决定结果能不能交付的约束，以及证明这些约束已经满足的证据。

如果你用 Codex 处理长任务，也遇到过压缩后要求漂移、只完成局部就停止，或多 Agent 协作中授权边界不清的问题，可以试试：

GitHub：GreenLv/codex-context-guard

最新版本：GitHub Releases

如果它对你有用，欢迎 Star、提交 issue，或分享一个可以复现的长任务上下文问题。

参考资料

• GPT-5.6 Sol model page
• Lost in the Middle: How Language Models Use Long Contexts
• Codex issue #19910: active goal and audit requirements can be lost after compaction
• Codex issue #35226: auto-compaction can lose progress and repeat file reads
• Retrieval and Multi-Hop Reasoning in 1M-Token Context Windows
• Claude Code issue #32659: context amnesia in long sessions — constraints silently dropped as context grows
• Cursor forum: “Rules” do not survive context compression events
• 36氪：Anthropic 的 Harness 工程白做了？Claude Code 被曝不遵守 CLAUDE.md，开发者烧光 credits 怒喊退钱