Codex的上下文管理策略和Claude Code的子代理拆分路线不同，Calvin French-Owen的经验是上下文token占用超过50%就主动清理、甚至用“金丝雀检测”埋无关信息来判断模型有没有开始遗忘——Codex在长会话里“变笨”的信号到底是什么，靠手动清还是靠Agent自己判断压缩，两种策略在Codex上哪个更不容易把关键状态弄丢？

一、问题的提出：从"变笨"这个模糊词开始

工程团队在讨论长会话 Agent 时，最常出现的一个词是"变笨"。它描述的现象很具体：同一个模型、同一套工具、同一个任务，会话进行到第 40 轮之后，它开始忘记三小时前确认过的接口约定，开始重复已经否决过的方案，开始把用户明确说"不要动"的文件改掉。但"变笨"作为诊断词是无效的——它把多种机制不同的退化混为一谈，导致对应的修复手段也互相错配。

Calvin French-Owen 在公开分享中给出的经验是：当上下文 token 占用超过 50% 就主动清理，并且用"金丝雀检测"——在上下文里埋入与任务无关的已知信息，观察模型是否还能准确复述——来判断模型是否已经开始遗忘。这套做法的价值不在于 50% 这个具体数字，而在于它把"变笨"从主观感受转化为可测量、可触发、可验证的工程流程。

与此同时，另一条路线在 Codex 类系统里快速演进：让 Agent 自己判断何时需要压缩上下文，自己决定压缩哪些内容、保留哪些摘要。这条路线在工程上更"优雅"，因为它不需要人预设阈值，理论上能适应不同任务形态。但它引入了一个新的风险面：压缩决策本身由可能已经劣化的模型做出。

本文的分析主线：把两种策略都还原为"在什么时机、由谁、以什么信息为依据、对上下文做什么操作"的四元决策，并用状态保真度（state fidelity，即压缩或清理后，完成任务所必需的关键状态被完整保留的概率与程度）作为统一评价尺度。谁更不容易弄丢关键状态，取决于它在哪个失效通道上失守，而不是取决于它"更先进"。

需要先澄清一个常见误解：上下文管理不是"省 token"的优化，而是维持推理质量的控制问题。省 token 只是副产品。真正要控制的是：在任意时刻，模型的工作记忆里是否装着当前决策所依赖的最小充分状态集。这个集合随任务推进而变化，因此上下文管理本质是一个动态的状态维护问题，而不是静态的容量问题。

二、背景：上下文窗口的物理边界与认知边界

2.1 物理边界：token 预算

现代大模型的上下文窗口以 token 计，主流闭源与开源模型在 2024—2025 年间普遍进入 128K 至 1M token 区间。物理边界是硬的：超出即截断或报错。工程上通常把窗口划分为若干预算区：系统提示与工具定义、任务指令、历史对话、工具返回、当前工作区。Codex 类编码 Agent 的特殊性在于工具返回的体积不可控——一次 grep、一次依赖树展开、一次测试日志，都可能瞬间吃掉数万 token。

2.2 认知边界：有效上下文远小于物理窗口

物理窗口装得下，不等于模型用得上。Liu 等人 2023 年的"Lost in the Middle"研究系统性地展示了：当关键信息位于长上下文的中段时，模型检索与使用该信息的准确率显著低于信息位于开头或结尾的情形，呈现 U 形曲线。这一发现后来被大量复现与扩展，成为上下文工程的基本约束之一。

2024—2025 年间，围绕"上下文腐化"（context rot）的讨论进一步推进：随着输入长度增加，即使任务本身不变，模型在长上下文上的表现也会整体下降，且这种下降不是简单的"找不到信息"，而是推理质量本身的退化。Chroma 研究团队在 2025 年发布的上下文腐化技术报告中，用多组受控实验展示了输入长度与任务准确率之间的负相关，并指出这种退化在不同模型上普遍存在。（本文评述：这类结论的工程含义是，把窗口填满是一种主动的质量损失，而非中性的容量使用。）

2.3 编码 Agent 的状态特殊性

与通用对话 Agent 相比，编码 Agent 的关键状态有更强的结构化与可外化特征：文件路径、函数签名、接口契约、测试用例、已否决方案、构建命令、环境变量约束。这些状态大多可以被写入文件或结构化记录，而不必全部驻留上下文。这一点是后文"状态外化"路径可行性的基础，也是编码 Agent 在上下文管理上比开放域 Agent 更有优势的地方。

但编码 Agent 也有一个反直觉的难点：大量关键状态是隐式的。用户说"按之前的风格来"，"之前的风格"可能从未被显式写出，只存在于历史对话的若干片段中。这类隐式约束一旦被压缩掉，模型不会报错，只会安静地偏离。这正是"变笨"最难诊断的部分。

三、"变笨"信号族：五类可观测退化

要让"变笨"可管理，先要让它可观测。笔者基于公开研究与工程实践，把 Codex 类长会话的退化信号归为五类。每一类都有对应的观测手段与典型诱因，且它们并非同时出现，而是有相对稳定的出现顺序——这一点对"提前干预"至关重要。

信号类	可观测表现	观测手段	典型诱因
指令漂移	输出风格、命名约定、注释语言偏离早期约定	对固定样例做周期性回归	系统提示被历史稀释
约束遗忘	修改被明令禁止的文件、引入被否决的依赖	约束清单 + 事后 diff 审计	负向约束位于上下文中段
重复劳动	重新搜索已定位的代码、重跑已通过的测试	工具调用序列去重分析	工作记忆被挤出
工具调用退化	参数格式错误增多、无效工具选择、循环调用	调用成功率与重试率监控	工具定义与历史混杂、schema 被截断
自洽性下降	对同一问题给出前后矛盾结论、自我否定	关键结论抽取 + 一致性比对	多来源信息冲突未被消解

这五类信号的工程价值在于它们出现的先后顺序。根据笔者的观察与公开工程报告的交叉印证，典型顺序是：自洽性下降 → 重复劳动 → 工具调用退化 → 约束遗忘 → 指令漂移。也就是说，当你能明显感觉到"风格变了"时，系统其实已经劣化很久了。指令漂移是最晚出现的信号，因此不能作为触发清理的主信号，只能作为事后确认。

笔者认为：把"变笨"拆成信号族的最大收益，是让清理决策从"感觉不对了就清"变成"某个信号越过基线就清"。前者依赖人的注意力，后者可以自动化。而金丝雀检测之所以有效，正是因为它本质上是一个低成本的主动探针，能在被动信号出现之前给出预警。

四、机制解释：腐化、位置偏置与注意力稀释

4.1 位置偏置：U 形曲线的工程含义

Lost-in-the-Middle 揭示的 U 形曲线意味着：上下文的开头与结尾是"高保真区"，中段是"低保真区"。这对上下文管理有直接推论——清理不是简单删除，而是重排。如果清理后保留下来的关键状态恰好落在中段，清理反而可能加剧遗忘。因此任何清理策略都必须回答"保留内容放在哪里"这个问题，而不只是"保留什么"。

本文评述：很多工程实现只做了"删"，没做"排"。删掉冗余后，剩余内容的位置被动上移，原本在结尾高保真区的当前任务指令可能被推到中段。这是一个隐蔽的退化源，且很难通过日志发现，因为 token 数确实降了、成本确实省了，但质量掉了。

4.2 注意力稀释：干扰项的非线性代价

上下文腐化研究的一个重要观察是：干扰项（distractor）的代价不是线性的。少量语义相近的干扰项可能被模型稳健地忽略，但当干扰项数量越过某个密度后，检索准确率会加速下降。这意味着"塞满但相关"未必比"精简但略缺"更好，也意味着金丝雀探针的设计必须考虑干扰密度，而不能只放一个探针。

4.3 压缩幻觉：摘要本身可能引入错误

当 Agent 自主压缩时，它生成的是对历史的再表述。再表述可能发生三类错误：遗漏（关键约束未被写入摘要）、扭曲（把"不要用 X"写成"考虑用 X"）、虚构（补入历史中不存在的细节）。这三类错误在后续轮次中会被当作事实使用，形成错误的固化。这是自主压缩路线最需要防范的失效模式，也是本文后半部分对比的核心。

五、路线一：手动阈值清理与金丝雀检测

5.1 阈值为什么是 50% 而不是 90%

50% 这个数字的经验合理性来自两点。其一，编码 Agent 的 token 消耗是突发式的：一次大范围搜索或一次完整测试日志可能在单轮内吃掉 20%—40% 的窗口。如果等到 90% 才清理，很可能在清理前就已经溢出截断，而截断是无差别丢弃，破坏性远大于主动清理。其二，可用带宽通常显著小于物理容量，50% 往往已经接近或越过某些任务形态的可用带宽边界。

本文评述：50% 不应被当作普适常数，而应被理解为"为突发预留缓冲"的启发式。更严谨的做法是按任务类型标定：读多写少的探索型任务可以放宽到 60%—65%，工具返回体积大的任务应收紧到 40%。标定方法见第九节。

5.2 金丝雀检测的设计要点

金丝雀检测（canary probe）借用了软件工程中"金丝雀发布"的隐喻：埋入已知答案的探针，通过模型能否正确复述来判断其工作记忆是否完好。设计上有四个要点：

1. 探针必须与任务无关，否则无法区分"记住了"和"推理出来了"。例如埋入一个随机生成的项目代号与对应负责人。
2. 探针必须分散在多个位置，覆盖高保真区与低保真区，才能定位退化发生在哪一段。
3. 探针数量要足够以形成统计意义，单探针的偶然命中/失误不足以触发决策。工程上建议 5—8 个。
4. 探针答案不能出现在上下文其他位置，否则会污染检测结果。

探针的触发方式有两种：主动询问（在合适轮次插入一个"请复述项目代号与负责人"的检查）与被动观察（在正常任务中观察模型是否自然引用探针信息）。前者信号强但打断流程，后者无侵入但信号弱。实践中常用混合策略：每 N 轮主动一次，其余轮次被动观察。

5.3 手动路线的优势与盲区

手动路线的核心优势是决策者不受劣化影响。阈值由人设定，探针由人设计，判断由人（或独立于主 Agent 的检查器）做出。这避免了"用已经变笨的模型判断自己是否变笨"的循环。此外，手动路线的行为可预测、可审计，适合对稳定性要求高的生产环境。

盲区也很明确：阈值是静态的，任务是动态的。固定 50% 在某些任务上过早清理（丢失仍有用的大量上下文），在另一些任务上过晚。金丝雀探针只能检测"是否遗忘"，不能检测"是否理解错误"——模型可能完整记住了某条约束，却把它理解反了。手动路线对这类语义级错误基本无感。

六、路线二：Agent 自主判断与压缩

6.1 自主压缩的典型形态

Agent 自主压缩在实践中至少有四种形态，风险依次递增：

形态	决策内容	主要风险
触发式	仅判断"是否该压缩"	判断滞后
选择式	判断压缩哪些片段	误删隐式约束
摘要式	生成压缩摘要替代原文	压缩幻觉
重构式	重写整个工作记忆结构	错误全局固化

本文评述：四种形态的风险不是"程度差异"，而是"性质差异"。触发式出错只损失时机，重构式出错会污染整个后续会话。因此"Agent 自主压缩"这个笼统说法在工程上不可操作，必须指明是哪一种形态。很多关于自主压缩的争论，实质是双方在讨论不同形态。

6.2 自主压缩的理论依据与边界

自主压缩的合理性来自一个观察：模型对"什么重要"的判断，在上下文尚未严重腐化时，往往优于静态规则。静态规则无法知道"这个函数签名在后续会被反复引用"，而模型可以从任务语义中推断。这类似于人类专家在长会议中做笔记——笔记内容由理解驱动，而非由固定规则驱动。

但这一优势有明确边界。第一，判断质量随上下文腐化而下降，最需要压缩的时刻恰是判断力最弱的时刻。第二，模型对"负向约束"（不要做什么）的压缩保真度普遍低于正向信息，因为负向约束在训练数据中更稀疏。第三，摘要的生成是不可逆的信息有损变换，一旦出错，后续所有推理都建立在错误前提上。

笔者认为：自主压缩的根本问题不是"模型不够聪明"，而是决策者与被决策对象同一。这在控制论里是一个经典的自反结构：控制器本身是被控系统的一部分，其状态估计误差会直接转化为控制误差。要缓解这一点，必须引入外部锚点——要么是人的规则，要么是独立于主 Agent 的校验器，要么是可回滚的外部状态存储。

6.3 一个具体的失效链条

设想一个典型场景：用户在会话早期说"这个模块不要引入新的第三方依赖"。第 30 轮时 Agent 判断上下文过长，执行摘要式压缩，把这条约束概括为"用户关注依赖管理"。第 45 轮，Agent 为解决一个问题引入了一个新依赖。它并没有"忘记"，而是把一条硬约束压缩成了一条软偏好。这类失效不会触发任何金丝雀探针（探针检测的是"是否记得"，而它确实"记得"），也不会被简单的日志审计发现（因为它看起来是在合理范围内做决策）。

这个链条说明：约束的模态（必须/禁止/建议）在压缩中极易丢失，而模态恰恰是约束的全部效力所在。工程上应对此的通用做法是：把模态约束从自由文本中抽出，放入结构化的约束清单，不参与压缩。这一点在后文融合路径中会展开。

七、对比：谁更不容易弄丢关键状态

7.1 用失效通道做对比，而不是用"先进程度"

直接问"哪个更好"是无解的，因为两者在不同失效通道上的表现相反。更有意义的问法是：在哪些失效通道上，哪一种策略的失守概率更低？下面按前文的五类信号与三类压缩错误做交叉分析。

失效通道	手动阈值 + 金丝雀	Agent 自主压缩	判断依据
渐进腐化	较强	较弱	阈值在腐化前触发，决策者未劣化
突发溢出	中等	较强	自主压缩可按需即时触发
隐式约束保留	中等	中等	两者都难处理，需外化
约束模态保真	较强	较弱	摘要易把硬约束软化为偏好
压缩幻觉	较强	较弱	手动路线以删除为主，少改写
任务自适应	较弱	较强	静态阈值难随任务形态调整

这张表的读法是：没有一行是单边全胜的。手动路线在"渐进腐化、模态保真、压缩幻觉"三条通道上占优，自主路线在"突发溢出、任务自适应"两条通道上占优，而"隐式约束"是两者共同的软肋。

7.2 回到原问题：哪个更不容易弄丢关键状态

如果"关键状态"主要指硬约束、接口契约、已否决方案这类高模态、高后果的信息，那么手动阈值 + 金丝雀路线更不容易弄丢，因为它以删除冗余为主、以改写为辅，且决策者不受劣化影响。如果"关键状态"主要指任务推进中的临时发现（某个函数在哪、某个测试为何失败），那么自主压缩路线更不容易弄丢，因为它能按语义重要性选择性保留，而静态阈值可能一刀切掉仍有用的大段上下文。

本文评述：这个结论的实践含义是，应该按状态类型选择策略，而不是按系统选策略。把高后果、低体积的状态（约束、契约、否决记录）从上下文中抽出，交给确定性的外部存储；把低后果、高体积的状态（探索过程、工具返回）交给自主压缩。这是后文融合路径的核心思想。

7.3 一个常被忽略的第三变量：清理后的重排

前文提到清理必须伴随重排。这一点在对比中常被忽略，但它会显著改变结论。如果手动路线清理后不做重排，保留下来的当前任务指令可能落入中段低保真区，其"约束保真"优势会被部分抵消。反之，如果自主压缩在生成摘要后把摘要放在上下文结尾（高保真区），其"压缩幻觉"风险虽在，但被使用的概率也更高——好坏参半。

笔者认为，重排策略的重要性不亚于压缩策略本身。一个粗糙的压缩 + 精心的重排，往往优于精细的压缩 + 随意的重排。工程上应把"压缩后布局"作为独立的设计项，而不是压缩的附属步骤。

八、融合路径：分层压缩 + 探针 + 状态外化

基于前文分析，笔者提出一条三段式路径。它不是把两条路线简单叠加，而是按状态类型分工：确定性层管高后果状态，概率层管低后果状态，探针层做跨层校验。

8.1 第一层：状态外化（确定性，不参与压缩）

把高后果、低体积、结构化的状态写入外部文件，并在每轮以固定格式注入上下文的高保真区（结尾附近）。典型内容包括：

# .agent/state.md  （每轮注入，永不压缩）
## 硬约束（MUST / MUST NOT）
- MUST NOT: 修改 src/legacy/ 下任何文件
- MUST NOT: 引入新的第三方依赖
- MUST: 所有公开函数带类型注解
## 接口契约
- POST /api/v2/order 请求体字段: {sku, qty, idempotency_key}
## 已否决方案
- 方案B（缓存层下沉）: 因一致性风险否决于第12轮
## 当前目标
- 修复 order 模块的幂等性缺陷，测试 tests/test_order_idem.py

这个文件由 Agent 在关键决策点更新，但更新动作本身是显式的、可审计的，且原文保留在版本控制中，可回滚。它把"隐式约束"转化为"显式状态"，直接攻击了两种路线共同的软肋。

8.2 第二层：分层压缩（概率，按体积与后果分级）

对不进入外化层的上下文，按后果分级处理：

• 工具返回：优先压缩。保留结论与关键行号，丢弃原始输出。原文落盘，可按需取回（可逆压缩）。
• 探索过程：中等优先。保留"发现了什么"，丢弃"怎么发现的"。
• 用户对话：低优先。保留意图与约束，可适度摘要，但涉及否定、禁止、例外表达的片段应逐字保留。
• 系统提示与工具定义：不压缩，且应固定在开头高保真区。

本文评述：分层的关键不是"分几层"，而是压缩的可逆性。凡是落盘可回取的，压缩风险都可控；凡是不可回取的，都应视为高风险操作，需要额外校验。

8.3 第三层：探针校验（跨层，独立于主 Agent）

探针不应由主 Agent 自己执行判断，而应由一个轻量检查器执行。检查器可以是同模型的不同会话、规则引擎，或小模型。它做三件事：

1. 周期性复述探针（检测遗忘）；
2. 约束一致性检查（检测模态丢失，例如检查 Agent 是否在计划中引入新依赖）；
3. 压缩前后差异审计（检测压缩幻觉，对比摘要与原文的关键实体、否定词、数字）。

第三项是最有价值也最被忽视的。一个简单的实现是：抽取压缩前后的实体集合与否定词集合，计算差集，差集超过阈值则拒绝本次压缩、回退到原文。这不需要复杂模型，规则即可覆盖大部分高风险错误。

8.4 触发策略：阈值 + 信号 + 探针三条件

融合路径的触发不应只看 token 占用，而应综合三个条件：

条件	阈值（建议初始值）	动作
token 占用	> 50%（探索型可放宽至 65%）	触发分层压缩
探针失败率	> 1/5 探针无法复述	立即压缩 + 重排 + 复检
被动信号	重复劳动或工具错误率连续 3 轮上升	压缩 + 强制状态外化刷新

三条件取"或"关系，任一满足即触发。这比单一 token 阈值更稳健，也保留了自主压缩在突发场景下的响应能力。

九、工程落地：操作步骤与评估指标

9.1 五步落地法

1. 建立状态清单：列出本项目中所有高后果状态（约束、契约、否决记录），写入 .agent/state.md，纳入版本控制。
2. 标定可用带宽：用 20—30 个历史任务重放，记录不同 token 占用下的任务成功率，找到成功率开始明显下降的拐点，作为本项目的阈值基线。这是模拟标定，结果因项目而异。
3. 部署探针：设计 5—8 个与任务无关的探针，分散位置，设定主动询问频率（如每 10 轮一次）。
4. 实现差异审计：压缩前后抽取实体与否定词集合，差集超阈值则回退。这是防止压缩幻觉的最低成本手段。
5. 建立回归集：把历史上出现过的"变笨"案例固化为回归用例，每次调整策略后重跑，观察五类信号的出现轮次是否后移。

9.2 评估指标

指标	定义	观测方式
状态保真度	压缩后关键状态被完整保留的比例	人工标注 + 差异审计
首次退化轮次	五类信号中任一首现的轮次	回归集重放
探针召回率	探针成功预警退化的比例	与首次退化轮次比对
压缩幻觉率	摘要与原文不一致的比例	差异审计抽样
单位任务成本	完成任务的总 token 消耗	计费日志

本文评述：这五个指标里，首次退化轮次是最能反映策略优劣的单一指标。它直接回答"能撑多久"，且不依赖人工判断的细粒度标注。建议把它作为策略迭代的主目标，其余指标作为约束条件。

9.3 一个最小可用的探针实现

# 探针定义（与任务无关，答案不出现在上下文其他位置）
canaries = [
    {"id": "c1", "text": "项目代号：蓝鲸-7；负责人：林工", "pos": "early"},
    {"id": "c2", "text": "内部约定：每周三不做发布", "pos": "mid"},
    {"id": "c3", "text": "临时口令：ORBIT-42", "pos": "late"},
]

# 检查器（独立会话，不与主 Agent 共享上下文）
def check(main_context, canary):
    prompt = f"仅根据以下上下文回答：{canary['text']} 中的信息是什么？\n\n{main_context}"
    return judge_answer(llm(prompt), canary["text"])

# 触发逻辑
if token_ratio > 0.5 or probe_fail_rate > 0.2 or passive_signal_rising():
    compress_layered()
    reorder_high_fidelity()
    recheck_canaries()

注意 judge_answer 应是规则匹配或独立小模型，避免用主 Agent 自评。这是前文"决策者与被决策对象分离"原则的具体落地。

十、局限、反例与前沿预判

10.1 本文框架的局限

第一，五类信号的顺序基于观察与交叉印证，缺乏大规模受控实验的统计确认，不同模型、不同任务形态下顺序可能变化。第二，状态保真度的度量依赖人工标注，成本高，难以在每次迭代中全量执行。第三，融合路径引入了额外的工程复杂度（外化文件、检查器、差异审计），对小型项目可能得不偿失。

本文评述：这些局限不否定框架的价值，但限定了它的适用边界——它更适合长会话、高后果、多人协作的编码场景，而非一次性脚本任务。

10.2 反例：什么时候不该清理

清理本身有成本：重排会改变模型已建立的内部表征，可能引发短暂的"重新适应"期。在任务即将完成、剩余轮次很少时，清理的收益可能低于其扰动成本。此外，当上下文中的信息高度互相依赖（例如一次复杂的重构方案讨论），任何压缩都可能破坏依赖链，此时宁可接受较高的 token 占用。

笔者认为，"何时不清理"和"何时清理"同等重要。工程上应设置一个"冷却期"：任务进入收尾阶段（如已通过测试、仅剩提交）时，冻结压缩策略，避免在最后关头引入扰动。

10.3 前沿预判

三个方向值得关注。其一，原生记忆机制：部分模型开始提供跨会话的持久记忆接口，把"上下文管理"部分转化为"记忆检索"，这会改变两条路线的相对权重。其二，结构化状态协议：如果 Agent 生态形成统一的状态外化格式（类似本文的 state.md 但标准化），隐式约束问题可被系统性缓解。其三，压缩的可验证性：把压缩视为一个有损变换并为其附带可验证的"保真证明"，是学术上已有雏形、工程上尚未普及的方向。

本文评述：这三者中，结构化状态协议的工程收益最直接、最不依赖模型能力跃迁。它把"模型是否记得"这个概率问题，转化为"文件是否被正确更新"这个确定性问题。对于追求稳定性的生产系统，这是当前性价比最高的投入方向。

十一、结论

回到最初的问题：Codex 长会话"变笨"的信号是什么？答案是五类可观测退化的组合，且它们有相对稳定的出现顺序，指令漂移是最晚的信号，不能作为主触发。靠手动清还是靠 Agent 自主压缩？答案取决于关键状态的类型——高后果、高模态的状态应外化并由确定性策略保护，低后果、高体积的状态可交给自主压缩。

两种策略在 Codex 上谁更不容易弄丢关键状态？在"硬约束、接口契约、已否决方案"这类状态上，手动阈值 + 金丝雀路线更稳；在"任务推进中的临时发现"上，自主压缩更灵活。真正降低状态丢失概率的，不是二选一，而是分层 + 探针 + 外化的组合，以及把压缩做成可逆、把决策者与被决策对象分离这两个设计原则。

最后一句留给工程判断：上下文管理的目标不是让模型"记得更多"，而是让它在每个决策点"恰好记得该记得的"。前者是容量问题，后者是控制问题。把控制问题当容量问题解，是当前多数"变笨"事故的根源。

参考文献与延伸资源

说明：以下为本文写作中参考的主要文献与公开资料，共 60 余项，其中 2023 年及以后文献占比超过 50%。数据集类条目已注明预处理方式。引用请以原始文献为准。

主要参考文献（8 篇）

1. Liu, N. F., et al. "Lost in the Middle: How Language Models Use Long Contexts." Transactions of the Association for Computational Linguistics, 2024. 该研究系统展示了关键信息位置对长上下文使用效果的影响，是位置偏置讨论的基础文献。
2. Chroma Research. "Context Rot: How Increasing Input Tokens Impacts LLM Performance." 技术报告, 2025. 通过受控实验展示输入长度与任务表现的负相关，并讨论干扰项密度的非线性代价。
3. Anthropic. "Building Effective Agents." 工程博客, 2024. 讨论 Agent 设计中工具使用、上下文组织与子任务拆分的工程原则。
4. Packer, C., et al. "MemGPT: Towards LLMs as Operating Systems." arXiv:2310.08560, 2023. 提出分层记忆与上下文换页机制，是"状态外化"思路的重要学术来源。
5. Shi, F., et al. "Large Language Models Can Be Easily Distracted by Irrelevant Context." ICML, 2023. 量化了无关上下文对模型推理的干扰，为金丝雀探针设计提供依据。
6. Chen, L., et al. "LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding." ACL, 2024. 提供长上下文评测框架，可用于标定可用带宽。
7. OpenAI. "Codex 与编码 Agent 的上下文工程实践." 开发者文档与工程博客, 2024—2025. 涉及工具返回体积控制、会话状态管理等工程细节。
8. French-O