当我写第一部分时Coding Harness 架构对比：Eager Hydration vs. Just-in-Time Search，我以为整个问题的关键就是第一轮的一个决策：eager 还是 JIT，两个阵营，选一边。
我继续构建。继续测量、记录日志、time to first byte、time to first turn、cache reads，目标是把其他一切都压到零。而我越往兔子洞深处走，两个阵营就越不像两个阵营。它们是从相反两端下注、却朝着同一个目的地前进的同一场赌注。它们的_行为_仍然不同，而本文剩余部分讨论的就是这些差异如何体现：不同的断点、不同的生命周期、不同的可共享性上限。但在它们底层，有一条我无法绕开的单一规则。
一个写得好的 harness 内部的一切，都是围绕一条定律的实现细节。
Cache Economics 定律。“永远不要让 cache 失效。”
听起来很简单。但在我测量过的每个 harness 中，这都是被违反得最多的一条规则，包括那些由撰写 caching 文档的实验室构建的 harness。
Tokens 从来不是重点，cache 才是，并且永远都是。而 harness 真正产生分歧的地方，主要在于其平台 API允许做什么。后文会展开。
注意：下文若干 harness 细节仍在快速变化。据称 Claude Code 的 system prompt 被削减了约 80%（Boris，YC，2026 年 7 月 28 日），MCP V2 spec（2026–07–28）改变了 tool-caching 与 inheritance，而 Gemini CLI 已经退役，由 Antigravity 取代。请将与具体 harness 相关的事实视为一个快照；其底层定律才是稳定的。
什么是 Harness Engineering？
OpenAI 将这种实践命名为 harness engineering，这个比喻非常贴切。
model 就像一匹马。它拥有巨大的力量、速度和潜力，但没有方向；如果没有外部边界，它可能会狂奔失控。缰绳用来控制方向，眼罩用来保持专注，马鞍让它能够承载重量；在被 harnessed 之前，这种原始力量几乎没有用处。Harness 是围绕 model 的基础设施，可以理解为 native tool definitions、context docs、policies、safety rules（sandboxes）、eval beds、feedback loops，以及那些引导 model 如何执行工作的东西。rider 是工程师或 agent，他们通过 intent、prompt 来设定目的地和边界，而不是手动完成所有事情。这就是 Harness Engineering。
本文中的每个决策，都是关于 harness 如何保护 prefix，并进一步保护 cache 的决策。这里列出的每个优秀 harness 都做出了一百多个小决策，而这些决策都朝着同一个方向倾斜：保持 prefix 稳定，把易变内容放到后面，永远不要重写本可以读取的东西。
真正的成本是回滚
关于 eager 与 JIT 的大多数争论，都使用了错误的计量单位。Eager 前期支付更多，JIT 消耗更少 tokens 但可能漏掉某些东西。这种记账方式漏掉了真正伤人的成本：一次_回滚_。
Model 生成代码，然后后续某一轮暴露出一个约束，导致它已经写下的一部分内容失效。表面价格是一次纠正轮次。真正的价格是一个 blast radius：从错误假设到被发现的那一刻之间触及的一切，现在都变得可疑，都需要重新验证，不管它实际上是否错误。你是否见过一个 agent 基于不完整信息工作，验证一个它自己并不信任的结论？这种检查通常是成本中最大的一项，也是最容易被忽视的一项。Turns-to-discovery 比错误本身的大小更重要。第二轮发现，便宜。第十五轮发现，前面十四轮依赖性工作都必须被拆解。
这重新定义了权衡。Eager hydration 是一笔保险费，无论回滚是否真的会发生，都要预先支付。JIT search 是一次理赔，如果早早发现就很便宜；如果很晚才浮现，且 blast radius 很大，就会非常惨烈。
明确一点，cache 并不拥有这一切。信息缺失可能因为与 caching 无关的原因而造成毁灭性后果，比如错误的架构决策、糟糕的安全假设；它也可能在_完全没有 eviction_ 的情况下很容易修复。Cache 保护的是拆解依赖性工作所需的 token 成本，这是真实的，但不是回滚成本的全部。即便如此，账本仍然偏向 eager。JIT 的滴灌式发现会提高 turns-to-discovery，因此 JIT 的论点依赖于让回滚变得罕见且尽早被捕获，并以更干净、更可共享的 prefix 作为交换。
成本曲线。 未缓存路径会随着你不断重新发送的 context 大致呈二次增长。缓存路径则近乎平坦，因为 prefix 以十分之一价格读取。OpenAI 已经专门写博客讨论过这一点。
下一个读取这个 cache 的是谁？
Eager 为单个 session 预热 cache。JIT 则让 prefix 足够干净，使它能为之后的所有人预热，从 subagent，到团队，再到整个组织。这是对同一个问题的两种不同答案，而答案完全取决于各自的构建方式。
干净的 prefix 就是可缓存的 prefix。
Anthropic 的 cache 是严格基于 prefix 且 byte-exact 的。它按顺序 hash tools、system、messages，直到标记了 cache_control 的 block。这个标记之前只要有一个 token 改变，之后的一切都会 miss，并按全价重写。
Eager hydration 离这面墙更近。它把越多 workspace state 提交到 context 前部，比如实时文件列表、打开的编辑器标签、wall-clock stamp，prefix 中易腐坏的部分就越多。如果这些状态保留在 tail，它们在单个 session 内仍然可以很好地缓存，Cline 和 Roo Code 证明了这一点。
上限在于共享。一个充满 session-specific state 的 prefix 无法跨 session、用户或团队共享，因为它们之间不同的部分，恰恰就是被前置加载的部分。后文会继续讨论。
JIT 有意让 context 前部保持简单。Tools 和稳定的 system prompt 位于顶部，易变的 per-turn input 位于底部，而那些本来会被 eager hydration 的 search results，则作为 tool calls 晚些出现在 message array 中它们应该出现的位置。Prefix 在请求之间、session 之间，以及关键地，在用户之间保持一致。
那么 breakpoints 应该放在哪里？
Anthropic 每个 request 最多暴露四个 cache breakpoints，有趣之处在于决定每一个要保护什么。标准形态是两个：一个 breakpoint 放在稳定层末尾（tool definitions 加 system prompt，即 session 生命周期内不会变化的部分），第二个放在 tail，用来随着 conversation 增长锚定最近的 tool calls。
这里有两个细节会咬人。第一，最小可缓存 prefix 因 model 而异。Anthropic 的基线曾是 1,024 tokens，但某些 models 上有更高的最小值，并且较新的 model families 也有进一步变化，所以你需要按 model 单独处理。无论你如何标记，太小的 prompts 可能根本不会缓存。第二，automatic lookback 只能向后回看大约 ~20 个 content blocks，因此一个发出超过这个数量 block 的长 agent turn，可能会把较早的一次 write 推出范围，并悄悄开始 miss。长 turn 需要每十几个 block 放一个 intermediate breakpoint 才能保持覆盖。
这就是 JIT 需要额外机制的地方。Eager 写一次，在第一轮开始处写入少量 blocks，很少触及二十个 block 的上限，因为通常没有那么多量。JIT 会写很多次：每次 grep、每次 file read、每个 tool result 都是自己的 block，一个接一个追加；单个调查性 turn 就可能消耗十几个。把这累积到一个长 session 中，tail 就会有几十个 blocks，lookback 便够不到最后一个真正的 breakpoint。不是因为 JIT 粗心，而是因为 discovery 是滴灌式的，eager 不是。Eager 为稳定性预先一次性付费。JIT 则逐轮挣得稳定性，因此它需要 intermediate breakpoints、deferred tool loading、严格的 append-only ordering。这种复杂性不是设计缺陷，而是选择检索而非前置加载的代价。
要点： 跨 sessions 和 models 监控 cache responses，最小值和 lookback behavior 正是那种会在你脚下漂移的东西。
这种双 breakpoint 形态是地板，不是天花板。另外两个 breakpoint 才能让长 session 接近百分之百：将它们作为 rolling anchors，随着 conversation 增长重新定位，每隔一段时间就把最近几轮提升为一个新的 breakpoint，而不是让它们在有机会缓存之前就老化到 lookback window 之外。两个 breakpoints 保护开头和即时 tail。四个则不断重新锚定中间部分，使它们在 session 仍在运行时不会从范围中掉出去。
Live tail 左侧的一切都以 0.1x 从 cache 读取。这就是在完全相同 workload 上 96%+ hit rate 与 60% hit rate 之间的差别。（请阅读 Anthropic 关于这点的文档，我贴在底部。）
造成这个差距的唯一杠杆，是易变内容的位置。把 timestamps、open tabs 和 todo lists 推到前面、放在 breakpoints 之前，命中率会断崖式下跌；把它们留在 tail，或者干脆省略，命中率就会上升。
两个 Breakpoints，两种生命周期：TTL Tiering
不同的 breakpoints，不同的生命周期——tiering 用来处理这个差距。Anthropic 提供两种 TTL：默认五分钟和可选一小时。两者都会在每次 read 时刷新，因此一个活跃 session 只要持续使用，就能让 cache 无限期 保持 warm。
稳定层（tools 和 system prompt）天然适合 one-hour TTL——它对每个 session 和每个队友都是相同 bytes，因此应该能挺过 calls 之间的安静间隔。易变 tail（recent tool calls）适合 five-minute TTL，因为它快速 churn，支付成本长期保留它没有意义。
只有当 prefix 的真实生命周期超过五分钟 cache 本来能存活的时间时，一小时 tier 才划算。这里还有一条严格的 ordering rule。One-hour entries 必须出现在 prefix 中 five-minute entries 之前。这自然来自分层：长生命周期在顶部，短生命周期在底部，正是你本来也会采用的构建顺序。
偶尔 cache miss 是可以接受的，这是系统正常工作的证据：文件被编辑了，新 tool 确实被拉进来了。失败状态不是偶发 miss。Eager hydration 在一个 session 内部 命中表现很好，百分之九十，和最佳水平一样，但前提是它像 Cline 和 Roo Code 那样严格约束自己前置加载的_内容_。如果改为把易变 workspace state 提交到 context 前部，同一条路径就会滑向百分之六十的地板。它的_结构性_ miss 则不同且不可避免：prefix 从第一个 byte 开始就是个人化的，因此永远无法跨第二个 session、队友或 fleet 共享。
顺序式答案：Cline 和 Roo Code
我想公平对待那些证明 eager hydration 有效的 harness，首先是 Cline，以及并行提到的 Roo Code。它们的基础 cache hit rate 很高，而且这不是运气。Roo Code 的默认形态无需辩论就展示了整个原则。
开箱即带五种 modes。Orchestrator、Architect、Code、Debug、Ask。Orchestrator 的工作是推理，并向适合该任务的 mode 写出清晰的 handoffs。该 mode 运行、返回 summary，然后把控制权交回。每一步都是顺序执行，一个 agent 切换帽子，一条 timeline，没有任何并行运行。每个构建 harness 的团队都应该复制这一点：orchestrator 的工作是推理，并向下面每个 subagent 写出干净的 handoffs。简单。
这正是 cache 行为如此好的原因。观察一个 live session 的 token accounting，你会看到 cache、cache、cache。我查看过一段十到十五轮的区间，其中 cache writes 为零，这一度让我惊讶，直到我想通了。在单个 repo 上，一次只由一个 mode 处理，下游 mode 需要的东西几乎总是在几轮之前已经被上游 mode 拉进来了。Five-minute TTL 每次 read 都会刷新，而顺序 handoffs 移动得足够快，以至于 cache 在它们之间从不会冷却。
这是通过拒绝并行化免费获得的 coherence。没有两个 agents 争抢同一批文件，没有 model boundary 切分 cache，没有 concurrent write 与 read 竞态。顺序性是一种由架构自动强制执行的 cache-coherence 策略。而这个保证，正是并行设计放弃的东西。
并行式答案：Subagents 与 Recursive Admission Control
谨慎花费这种 coherence，因为并行性正是它不再免费的地方。Sub-agents 是必须手工重建保证的地方，也是如果没人盯对层级就会悄悄崩塌的地方。一个 sub-agent 通常会从其 parent 继承，MCP servers 是最明显的例子。生成一个 sub-agent，它就会带着 parent 的整个 tool 和 MCP surface 启动，无论它的 scoped task 是否触及其中任何部分。这种 inheritance 是 eager hydration，发生在 context window 之下一级，dashboard 上的 token counters 看不到它。[这一层会发生很多变化，归因于 MCP V2 2026–07–28 spec。]
修复方式是 recursive admission control。在我早前的第一部分文章中，我主张在顶层使用它：任务不需要的东西绝不进入 window。扩展含义是，同一个 gate 必须在每一层 delegation 都触发，否则 sub-agent 就会成为泄漏点。
那么多个 agents 如何触碰一个共享 repo 而不碎片化 cache？
Cline/Roo Code 和 Claude Code 给出了两种不同答案，但都朝着同一个目的地前进。Cline/Roo Code 的答案是：不要有多个 agents，保持顺序，一个 warm cache 由结构自然生成，coherence 问题根本没有机会出现。
Claude Code 的答案是允许多个 agents，并且它实际上给你两种模式。标准 subagent 在自己的隔离 context 中运行。它不继承 parent 的 system prompt 或 history，而是从零开始，加载共享 project config 和 tool pool，并构建自己的干净 prefix。它从不触碰 parent 的 cache，因此无法使其失效。Fork 则相反，它 byte-for-byte 继承 parent 的 prefix、model 和完整 history，并读取 parent 已经付费得到的 cache，而不是组装自己的 cache。而 parent 本身也可以是 subagent，因此这可以嵌套，depth-first，一路向下。两条路径都遵守定律。Fork 复用 warm cache；标准 subagent 从不触碰它。两者都不会使任何东西失效，这就是重点。
Model Binding 是 Cache-Coherence 要求
Model 选择是另一半，而且这不是风格偏好，而是 cache-coherence 要求。一个 cached prefix 绑定到特定 model，因此同一个 repo 上的两个 sub-agents 一旦运行在不同 models 上，它们就完全停止共享 cache，各自支付自己的 write premium，而不是由一个 fleet 只支付一次。Session 中途切换 models 也会在小范围内造成同样损害。有些 harness 会阻止这种情况，有些不会。
扩展 Prefix：从 Subagents 到整个组织
你的 prefix 首先应该是_为_你的 subagents 准备的。把这一点做好，你就能把它向上渗透到团队、组织，甚至更远。这就是第一部分暗示过的 team-level cache。
一个稳定、model-consistent、admission-controlled 的 prefix，是整个 agent 团队都能读取的 prefix——这是 eager hydration 达不到的回报，因为它的 prefix 从第一个 byte 开始就是易腐的。但必须精确理解实践中 shared 的含义：在 Claude Code 中，共享只在 system-prompt 和 tool-schema 层是结构性的，并且通过 byte-for-byte 继承 parent prefix 的 forks 实现。标准 subagents 按设计从零开始，永不触碰 parent cache，因此顶层以下的 team-level reuse 是你有意架构出来的东西，而不是默认继承来的东西。API 允许 org-wide warm prefix，但 harness 只有构建正确才配得上它。
因为 system prompt 和 tool schemas 对所有人都是相同的，这一层就是整个公司都能读取的一个 warm prefix，下面的树则根据工作共享的范围进行分支。持续使用它，你就能在组织范围内无限期保持 warm cache——只要所有人使用同一个 model。把 fleet 拆到多个 models 上，也就同时把 cache 拆开了。
三个实验室，三种 API
一个 harness 的样子，大多是对其 provider 允许什么的回应。按 cache discipline（1 到 5）和 retrieval posture（eager 到 JIT）给每个 harness 打分，就会呈现出一种形状。纪律严明且偏 JIT 的角落很拥挤，而 eager 但纪律严明、以及纯 JIT 但 cache-blind 的角落各有一个孤例，证明这两个轴是可分离的。Aider 纪律严明但 eager；Terminus 2 是纯 JIT 但 cache-blind。
Anthropic - explicit。 前文详述过的 breakpoints 和 tiered TTLs。每个 request 四个 cache_control markers，由 harness 自行放置。这是唯一一个直接把杠杆交给你的 API，而不是让 harness 自己挣得或放弃折扣——这也是如此多 harness 首先运行在 Claude 上的大部分原因。
OpenAI - automatic。 没有 breakpoints 可放置，没有 lifetime 可选择。平台匹配至少 1,024 tokens 的 exact prefix，并对 read 打折，仅此而已。较新的 models 正开始加入 explicit breakpoints，但对于今天大多数运行中的东西，全部纪律都落在 harness 行为上，也就是 API 周围的架构上。Codex CLI 诚实地做到了这一点：agent loop 有意追加新 messages，而不是编辑早先的 messages，因此旧 prompt 始终是新 prompt 的 exact prefix。OpenAI 已经明确表示，另一种方式——让 transcript 按 naive loop 的方式增长——会让 agent loop 在每轮发送的 JSON 上呈二次增长。Codex 通过永远不给平台 miss 的理由来赢得自己的 hit rate。
Google - in between。 默认 implicit caching，同时提供 explicit CachedContent 选项；如果 harness 选择管理它，在当前一代 Gemini models 上大约能省 90%。Gemini CLI 从未这样做：system prompt 和完整 GEMINI.md hierarchy 每次 call 都被重新组装并重新发送，一个关于两条简单数学查询的 tracked issue 测得大约 13,000 input tokens 被白白烧掉。
来自每个方向的同一场转变
那种形态的 Gemini CLI 已不复存在。Google 于 2026 年 6 月 18 日 对多数用户退役了它，并用 Antigravity CLI 取而代之，后者明确围绕 orchestrated、multi-agent workflows 构建，而不是一个线性 session。
一篇来自某位大规模运行 Antigravity 的开发者的生产实践文章提到，他们曾将 timestamps 直接嵌入 system prompt，这正是本文反复围绕的错误；修复方式是 stable content first、volatile content last，结果 cache hit rate 从 38% 提升到 78%。一个明确围绕 multi-agent orchestration 构建的 harness，也带着此前所有系统同样的新手 bug 发布，而同样的修复带来了同样形态的收益。
三个实验室，交给 harness 的控制权数量不同，但底层定律相同：Anthropic 直接把杠杆交给你；OpenAI 要求你通过纪律赢得它；Google 则把它放在桌上，直到某个 harness 决定拿起来。
一切都追溯到第一层
每个决策都追溯到一个数字。根据我自己的估算，而非经审计基准，这些 harness 的 cold-start prefix size 相差 约四十倍：从不到一千 tokens 到三万三千 tokens，在任何一轮真实工作发生之前。
这个范围不是排行榜。小 prefix 和大 prefix 都可以很有纪律；它们只是对 layer one 应该承载什么作出的不同赌注。真正重要的数字不是第一轮有多小，而是被提交到那里的一切，究竟会以 90% off 被读取一百次，还是因为没人保护它而从头重写。
一个被持续读取的大 prefix，永远胜过一个持续失效的小 prefix。句号。
胜负就在这里决定。每个决策——干净的 prefix、breakpoint placement、tiered TTLs、recursive admission control、整个 fleet 使用单一 model——其实都是在同一个地方做出的同一个决策：layer one，也就是 context 在任何下游看到它之前被组装的地方。Cache 不是在 miss 发生后通过打补丁来管理的。它是在根部一次性正确组装 prefix 来管理的，然后让所有下游以两种方式之一遵守定律：fork 继承该 prefix 且不重写任何东西；fresh subagent 不读取它，但基于所有人共享的同一稳定层构建。无论哪种方式，warm prefix 都存活下来，没有人让自己没碰过的东西失效。
接下来往哪里走？
先把各个实验室放到一边。Gemini CLI 死去，又以 Antigravity 的形式回来，按设计就是 multi-agent。它带着同样的新手 bug 发布，采用同样的修复，获得同样的收益。放大视角，这就不再是三个产品，而是一种形态。Orchestrator dispatching to a fleet 现在已经成为默认形态，而 harness 是它的 control plane。无论是本地、sandboxed，还是作为 SDK 运行，底层都是同一件事：一个 agent 生成 subagents。是的，成本最终以 tokens 计价。因此，当团队和公司开始运行 autonomous agents fleets 时，问题就变成了到底从哪里开始优化。在一组 agent 反复处理同一个 repo 的 fleet 中，共享 prefix 是杠杆最高的优化。一个 warm prefix 被多人读取，而不是每个 agent 都支付自己的 write premium。
这引出了我一直反复思考的两个问题。
第一个是这些 subagents 住在哪里。Fleet 必须运行在某个地方，而环境不是你设置一次就忘掉的 plumbing。Spawning 到多深、每一层继承什么、runs 之间保留什么和拆掉什么，这一切要么保护 prefix，要么悄悄撕碎它。如果构建得粗心，你赢得的每个保证都会在 dashboard 下方一层泄漏出去，而那里没人看着。对深度要有意设计。对允许它们保留什么也要有意设计。
第二个是 memory。简单的 prefix 解决了一个 session 内的 coherence，也解决了该 session 内 fleet 之间的 coherence。它无法解决跨 sessions 的问题，当工作跨越多天，而必须保持 coherent 的东西根本不是 prefix，而是关于“什么改变了以及为什么改变”的持久记录。这不是 context-loading 问题，而是 memory 问题。
我要说的是：Memory 是为了那些必须存活下来的东西，穿过一次 repave，持久化以阻止 incidents 和 recurring patterns 反复发生，并最终在新东西取代它时被遗忘。它不是便利层。当你的 harness 能把 memory 读回来，让没人需要重新解释十五个 sessions 之前发生了什么，或者重新发明某位队友已经在同一个 issue 上搞明白的东西时，再去使用 memory。
Harness 中的一切都回到第一轮。之后的一切都是同一种立场的延伸、实现细节：保持 prefix 稳定，把易变内容放到后面，永远不要重写本可以读取的东西。
永远不要让 cache 失效。
阅读清单
1.Anthropic - Prompt caching
2.Anthropic - How Claude Code uses prompt caching
3.Anthropic - Lessons from building Claude Code: Prompt caching is everything
4.OpenAI - Unrolling the Codex agent loop
5.OpenAI - Prompt caching guide
6.Google - Gemini CLI memory & context management
Claude Code - Resume/continue cache invalidation, #43657
Claude Code - Session resume invalidates prompt cache, #42338
Aider - Unstable repomap breaks caching, #1874
Gemini CLI / Antigravity - massive token overhead discussion, #27307
OpenCode - Gemini caching missing on OpenRouter, #36069
Codex CLI - stable prompt-cache key needed, #21796
Franklin - cache_control breakpoint budget bug, #73
CLIProxyAPI - round-robin breaks Gemini/Antigravity caching, #307
OnlyTerp/prompt-cache-skills - the Cline→Roo→Continue breakpoint bug
Aider - Prompt caching docs
Cline - Context window explained
Hermes Agent - Prompt assembly architecture
pi - Prompt caching in agents (earendil.com)
Terminus 2 - Harbor framework docs
Google Developers Blog - official transition announcement
Antigravity Lab - production cache strategy, the 38%→78% report
The Register - Bye-bye Gemini CLI coverage
Claude Code Camp - how prompt caching actually works
Codex Knowledge Base - prompt caching in Codex CLI