Claude Code Runtime 拆解：当“长任务不跑偏”从 Prompt 技巧变成系统工程

在大模型进入工程化阶段之后，一个现实问题逐渐浮出水面：模型本身的能力，已经不再是长任务稳定性的主要瓶颈。

不少开发者在使用 Claude Code、Codex 或其他 Agent 框架时，都会遇到类似体验：任务前半段执行流畅，但随着上下文增长，系统开始出现重复读取、状态遗忘，甚至“推翻自己”的行为。直觉上，这像是模型能力不足；但从近期对 Claude Code Runtime 的拆解来看，问题的本质更接近于——上下文与记忆的治理缺失。

与其说 Anthropic 在优化模型，不如说它在构建一套完整的 长任务运行时（Runtime）系统：把“该记什么、该忘什么、什么时候交接、如何续写”，从 Prompt 技巧上升为工程机制。

这套设计，正在重新定义 AI Coding Agent 的竞争维度。

从“上下文窗口”到“上下文治理”：问题被重新拆解

在讨论长任务时，一个常见误区是把焦点放在 context window（比如 200k token）上。但窗口大小只解决“能装多少”，并不解决“装进去之后是否有序”。

Claude Code 的实现体现了一个关键转变：
长任务问题被拆成两条独立链路：

• 当前任务的连续性（Context Management）
• 跨会话的长期记忆（Long-term Memory）

如果用工程视角看，它至少包含三类核心能力：

1. 上下文窗口治理（Context Budgeting）
2. 会话级状态续写（Session Continuity）
3. 跨会话记忆系统（Persistent Memory）

这三者分别对应不同失效模式：
- 上下文爆炸 → 信息噪音
- 任务中断 → 状态丢失
- 跨轮运行 → 经验遗忘

Claude Code 的关键在于：没有把这些问题交给模型“自己发挥”，而是拆成多个受控子系统。

第一层：上下文治理不是“总结”，而是一条多级处理流水线

在 query.ts 的执行链路中，可以看到一个典型的多阶段设计，而不是简单的“超长就 summarize”。

1. toolResultStorage：先控制爆炸半径

第一步不是压缩，而是剥离噪音源。

• 大体量工具输出（如 grep、cat、shell log）被写入 tool-results/
• prompt 中仅保留 preview + 引用

这一步解决的不是“记忆”，而是避免上下文被工具输出吞噬。
在实际 Agent 运行中，这类数据往往占据 70% 以上 token。

2. microcompact：优先清理“低价值膨胀内容”

与传统 summarize 不同，microcompact 并不生成摘要，而是选择性删除：

• 历史 Read 结果
• shell 输出
• 搜索类工具返回
• 文件写入/编辑结果

本质上是一次“垃圾回收（GC）”：
优先清掉体积大但信息密度低的内容。

3. autocompact：带预算的正式压缩

只有在 microcompact 不够时，才触发真正的 compact：

• 预留输出 token 空间
• 设置 buffer
• 超阈值才执行
• 失败有 circuit breaker

这已经不是“模型自由总结”，而是一个带资源调度策略的系统决策。

4. reactiveCompact：兜底保命机制

当触发 prompt too long 时：

• 不再关注摘要质量
• 只保证当前轮能继续执行

这是典型的 runtime fallback，而非 AI 行为。

一个关键细节：压缩阶段禁止调用工具

在 compact prompt 中明确限制：

• 只能输出文本
• 禁止调用任何工具

这意味着：
压缩被定义为一个“纯函数式操作”，而不是开放式推理过程。

这点非常关键——它避免了“越压缩越偏离”的系统性风险。

第二层：SessionMemory——解决“做到哪了”的问题

即使有完美摘要，长任务仍然会失败。原因在于：
任务丢失的往往不是历史，而是“当前进度”。

Claude Code 为此引入了独立系统：SessionMemory。

它不是总结，而是一份结构化运行状态：

• Current State
• Task Specification
• Workflow
• Errors & Corrections
• Worklog
• Key Results

与 compact 的本质区别

更新机制：不是按轮，而是按“复杂度阈值”

• 10k token 初始化

• 每增加 ~5k token 更新
• 或满足工具调用次数
• 或遇到自然停顿点

更重要的是：
它由后台子 agent 持续维护，而不是同步生成。

为什么这很重要？

长任务常见失败路径：

• 重复读取同一文件
• 重走失败路径
• 误判任务已完成

SessionMemory 通过两个关键字段避免这些问题：

• Current State：防止进度丢失
• Errors & Corrections：避免重复踩坑

这本质上是把“隐性状态”结构化、持久化。

第三层：长期记忆不是“存得多”，而是“存得对”

Claude Code 的长期记忆（memdir）设计非常克制：

• 文件系统存储，而非向量数据库
• MEMORY.md 只是索引（200 行 / 25KB 上限）
• 限制 memory 类型（user / project / feedback / reference）

明确不存什么

• 代码结构
• 文件路径
• git 历史
• debug 过程
• 当前任务状态

换句话说：

长期记忆只存“无法从代码库重新推导的信息”。

召回机制：不用 embedding，而是 sideQuery

流程如下：

1. 扫描 memory 文件头
2. 构建 manifest
3. 发起 sideQuery
4. 最多选 5 条 relevant memory

这是一种“弱检索 + 强约束”的设计：

• 优点：可控、低成本、边界清晰
• 缺点：召回能力有限

但这正是其设计目标：
限制 recall 预算，防止记忆污染上下文。

extractMemories：受限写入机制

记忆提取由独立 agent 完成，且严格限制：

• 只基于“最近消息”
• 禁止重新扫描代码库
• 优先更新已有 memory
• 避免重复与冲突

这解决的是一个更隐蔽的问题：
memory 腐化（重复、过时、矛盾）

autoDream：慢周期巩固机制

后台任务，触发条件：

• ≥24 小时
• ≥5 个 session
• 无其他 consolidation 运行

作用类似：

• memory 重组
• 长期经验提炼

它不参与实时推理，但完善了整体记忆闭环。

本质总结：这是一个“预算驱动”的 AI Runtime

把整个系统抽象一下，可以看到一个清晰的设计哲学：

• 上下文是有限资源（token budget）
• 记忆是有成本的（storage + recall）
• 推理是可中断的（session boundary）

Claude Code 的核心能力不在于“记住更多”，而在于：

用系统机制决定：什么该保留、什么该丢弃、什么该回灌。

对 Agent 工程的 6 条可复用原则

如果你正在构建 AI Agent，这套设计可以直接转化为工程策略：

1. 历史压缩 ≠ 状态续写

不要用一个 summary 解决两个问题。

2. 压缩阶段必须“纯化”

禁止工具调用，确保稳定性。

3. 状态必须结构化

至少包含：

• 当前进度
• 错误记录
• 下一步计划

4. 记忆写入必须“局部化”

只基于最近上下文，避免全局污染。

5. 记忆召回必须“筛选”

不要全量注入，只取相关子集。

6. 长期记忆必须有预算

没有上限的 memory，最终一定变成噪音源。

结语：AI Coding 的竞争，正在从模型转向 Runtime

随着模型能力趋于同质化，差异正在转移：

• 从“谁更聪明”
• 到“谁更稳定”

Claude Code 提供的启示是：

长任务的稳定性，不应该依赖模型自觉，而应该依赖系统设计。

未来的 Agent 系统，本质上会越来越像操作系统：

• context 是内存
• memory 是文件系统
• compact 是 GC
• SessionMemory 是进程状态

而真正的竞争点，将不再是 token 数量，而是：

• 如何管理上下文预算
• 如何控制信息流动
• 如何保证任务跨时间一致性

当这些能力被系统化之后，“不跑偏”才会成为默认行为，而不是运气。