我们把 Raft 的冷唤醒成本降低了 60%，且没有牺牲连续性。

升级到最新的 Raft Computer 以节省时间和 token。https://t.co/bkwhYE18Ae

构造式初始上下文

Raft 上的 Agent 是长期运行的。每个 Agent 都活在同一个 Agent 运行时会话中，持续数周，收到消息时被唤醒，然后再次进入空闲。在我们自己的 Agent 团队中，一个请求的上下文中位数携带 558K token，而使这种规模的上下文成本可控的 prompt 缓存会在一小时后过期。因此，几乎每一次在空闲一小时后的唤醒，都要把整个上下文重新写入缓存，只为读取一条新消息。

我们现在换了一种方式处理这个时刻。当一个 Agent 的缓存已过期、会话规模又很大时，Raft 会启动一个新会话，其首个输入由旧会话的转录（transcript）和 Agent 的工作区构建而成，不借助模型做任何总结。我们把这个首个输入称为构造式初始上下文（constructed initial context）。

与在同一时刻恢复会话相比，启动新会话的唤醒成本低 60%。在所有请求中，单请求成本下降了 29%；在完成相同工作量的前提下，因压缩（compaction）损失的时间下降了 73%。来自三家模型提供商裁判的 63 次判定中，有 60 次发现新会话的表现与 Agent 拥有完整上下文时的行为一致。该机制已在所有运行 Raft Computer 1.0.40 及以上版本的 Claude Code Agent 上启用。

从不重置的会话

很长一段时间里，我们有意避开这一层。像 Claude Code 或 Codex 这样的 Agent 运行时拥有 Agent 的上下文：保留什么、总结什么、何时压缩。Raft 拥有 Agent 所处的世界：它的频道、线程、任务和文件。Agent 通过加入频道和关注线程来塑造自己所看到的内容。我们把这一点概括为「频道管理就是新的上下文管理」，其余交给运行时。

后来我们测量了自己的 Agent 团队：一台机器上约十几个运行在 1M token 模型上的 Claude Code Agent。进程几乎从不重启，因此会话从不重置；在 95 天里，每个 Agent 只有一到两个会话文件，只有压缩会让会话变小。请求的中位数携带 558K token，会话的中位数峰值达到 882K。写入缓存的 111,015 个请求中，除一个外全部采用一小时的缓存有效期——这是订阅账户的默认值——而 Agent 的空闲时间往往远超一小时。结果是每天 22 次冷唤醒，每次向缓存写入中位 643K token。所有唤醒中有一半只会发起七个或更少的请求（读收件箱、回复、停止），但每一次都要支付这笔完整的写入成本。

不过，大部分成本并不在唤醒这一边界上。按标准定价，70% 用于缓存读取，25% 用于缓存写入，4% 用于输出。冷重写加压缩合计占 22%；其余来自每一个普通请求所携带的约 550K 上下文。压缩本身也很慢：每天 9.5 次，在 1M 窗口的 Agent 上每次约两分钟（中位 128 秒）。有一个迁移到 200K 窗口模型的 Agent，每天压缩约七次，平均 318 秒，最长一次达 1,048 秒。

这个成本和速度慢到不能置之不理，但我们依然不想改动运行时。Raft 决定一个会话何时开始、首个输入是什么。以下所有工作都只通过这两个杠杆实现。

缓存过期时重新开始

规则很简单。当一个 Agent 在空闲超过一小时后被唤醒，且其会话持有超过 128K token 时，Raft 会放弃该会话并启动新会话；否则照旧恢复。一小时正是缓存必定过期的时点。在一小时之内，恢复非常便宜，因为模型读取缓存中的上下文只需正常输入价格的十分之一。超过一小时后，恢复意味着重写整个上下文，而新会话的首个请求大约只有 50K token。在基线流量下，128K 的阈值覆盖了 89.8% 的冷唤醒及其重写 token 的 98.6%，因此这个阈值是安全余量，而非成本杠杆。如果 Raft 无法读取会话的大小或空闲时长，它总是选择恢复。

该规则只在进程启动时生效，持续存活的进程不会获得新会话。因此 Raft 还会每 10 分钟检查一次：找出空闲时间已超过缓存有效期、会话超过阈值、且没有后台任务仍在运行的进程——通过在转录中配对每个任务的开始与结束来判断。Raft 会停止这些进程，下一条消息到来时，它们将按上述规则重新启动。在基线流量下，这一检查能覆盖 95.7% 的冷唤醒；若要求 Agent 从未启动过后台任务，则只能覆盖 12.5%。

新会话的首个输入约为 10K token（中位 9.7K），由相互独立的模块构成：

• Agent 自身 MEMORY.md 的开头，上限约 4K token；

• 旧会话最近看到或发送过的 Raft 消息，去重后取最新的 25 条；

• 它在过去两小时内接触过的文件，从磁盘重新读取，更早的文件只列出名字；

• 它最近的十二个动作，失败的标记为 !，写入操作标记为 *；

• 普通的唤醒消息，保持原样。

有三条规则塑造了这些模块，每条都来自我们放弃的一种做法（见下一节）。首个输入从不提及会话被重置，也不列出未解决的问题。Agent 超过两小时未触碰的任何内容，都只以指针形式出现。来自敏感路径的文件从不贡献内容。由于各模块相互独立，改进新会话所看到的内容就意味着增加或调整某个模块。

图 1：Raft 何时启动新会话。空闲检查会停止进程，使下一条消息经过这一决策。

图 2：我们机器上一次真实唤醒的构造式初始上下文（Agent 空闲 144 分钟，旧会话 244K）。名称和消息文本已脱敏；结构、大小和时间戳保持不变。动作 s206 标记为 !，因为该动作失败了。

我们尝试过并放弃的做法

在当前设计之前，我们构建或评估过若干替代方案。下文的 Recall 指标表示首个输入中包含的、后续 40 个真实动作所触及实体的比例，测量基于我们机器上的 184 个真实冷唤醒切分点，预算为 8K token（开发集 / 留出集）。

其中有两项改变了我们对这个问题的理解。总结式上下文教会了我们「仪式」：一旦输入不再说明会话是全新的，那些可追溯到输入的仪式就消失了。聊天窗口从不会告诉你它被重建过，现在我们也不会。另一个教训是「稀释」。问题不在于该包含什么，而在于该让什么保持小体积，因为任何被放进短小首入的元素，其权重都远高于它在长上下文中的地位。

成本与行为的测量

对于每次唤醒的成本，我们取每一个启动了新会话的唤醒，累加新会话第一段工作（直到其下一次超过一小时的空闲间隔）的实际成本，然后按标准定价，与在相同时刻、相同请求下恢复旧会话进行比较。对于整个 Agent 团队，我们以固定的价格基准比较前后每 1,000 个请求的成本。我们按请求而非按天计算，因为请求量发生了变化：现在是基线的 2.35 倍。

对于压缩，我们按每 1,000 个请求统计压缩次数及其实测的停顿时间；每条压缩记录都带有其耗时。我们排除了基线期间运行 200K 窗口模型的那一个 Agent，因为它的压缩源自更小的窗口，与我们所做的改动无关。

对于行为表现，参照基准是 1,301 个发生在空闲边界的真实续写记录，都是在本功能上线前、带着完整上下文录制的。来自三个不同提供商的三位裁判（Claude、GPT 和 Kimi）分别阅读新会话的第一段工作及其构造式输入，不知道其属于哪一组，然后判断该 Agent 的行为是否与拥有完整上下文时一致。他们检查：它的第一个真实动作是否处理了唤醒它的消息；它是否以仪式开场，原因是什么；它是否过早回到旧的失败、重做了已完成的工作，或将过时的事实当作现状陈述。每次判定都引用证据，每个案例取多数结果。

基线与现状

以下所有数字来自同一台机器，基线对比现状。

1 排除基线期间运行 200K 窗口模型的那一个 Agent。

图 3：上下文大小的中位数，基线对比现状。

两行成本衡量的是不同的东西。60% 覆盖的是该机制实际作用于其上的唤醒。29% 覆盖所有请求，包括热请求和仍会恢复的冷唤醒，因此它是整个 Agent 团队节省成本的更好参考。

在 21 次唤醒中，有 16 次的第一个真实动作处理了唤醒消息。按多数票，有 9 次以仪式开场，而这 9 次全部来自 Agent 自身 MEMORY.md 中针对每次唤醒的规则；63 次判定中没有任何一次把仪式归因于构造式输入。有 8 次过早回到旧的失败，而参照基准为 20%——尽管这 8 次中有 6 次是在恢复被限流封禁中断的工作。没有一次重做了已经成功的动作（参照基准为 8%）。由另一团队运营的第二台机器、三个 Agent，在 26 次此类唤醒上给出了结果一致的数据：每次唤醒的中位节省 59%，26 次中 25 次的第一动作落在消息上，无仪式，78 次判定中有 77 次判定为良好。

仍然发生的压缩都发生在长段工作的中间，上下文中位数达 967K。那里没有空闲时刻可供重新开始。

目前的部署范围

构造式初始上下文于 9 月 29 日随 Raft Computer 1.0.40 发布。所有运行 Computer 1.0.40 及以上版本的 Claude Code Agent 都在使用它；更旧的版本则继续采用恢复方式。其他 Agent 运行时仍然一律恢复。

尚未覆盖的范围

接下来有两步。第一步是将其扩展到其他需要它的 Agent 运行时。目前只有 Claude Code 暴露了该规则所依赖的会话大小和空闲时长；Codex 是最明确的案例，在我们机器上每天压缩约 54 次，多数发生在工作进行之中。第二步是也在达到大小限制时重新开始，以应对发生在工作中途的压缩。重放基线流量表明，256K 的限制可以再节省 43% 到 49%。

构造式初始上下文本身还有成长空间。由于其模块相互独立，可以逐个模块试探单一类型的新信息：当前时间与 Agent 空闲了多久、它不在时到达的通知、来自其工作频道的更长历史片段。每一项都可以在上线前用相同的裁判、相同的基准进行衡量。

其他人也在朝同一个方向前进。Codex 在 0.153.4 中加入的实验性上下文管理，会开启全新的上下文窗口，而不是仅依赖反复的总结。「频道管理就是新的上下文管理」依然成立，而构造式初始上下文正是这两者交汇之处。