v0.12.4

新功能与改进

1. 01

   root agent 缓存身份稳定且对齐

   root agent 现在拥有单一、确定性的缓存身份，并在其整个生命周期的每一轮都向 Codex 呈现该身份，而不是逐请求漂移或重新生成。

   • 内核取 resolved agent/init.json 路径的 sha256，截取前 8 个十六进制字符作为稳定哈希；先做路径解析意味着同一 agent 无论以何种方式被寻址都映射到同一哈希。
   • 该哈希被逐字节一致地用作 Codex session-id、thread-id 与 prompt_cache_key，使同一逻辑 agent 的三个路由/缓存面彼此一致。
   • 由于身份来自 resolved 磁盘路径而非逐调用状态，它在重启、重连与同一 agent 的多轮之间保持稳定。

   为什么重要：Codex prompt 缓存奖励稳定、重复的会话身份。当 session-id、thread-id 与 prompt_cache_key 三者一致并持续存在时，provider 能识别出新一轮是在延续既有上下文，于是共享前缀从缓存命中，而不是重新计费、重新编码。

2. 02

   daemon run 获得自己作用域的缓存 anchor

   LingTai 后端 daemon run 不再借用父级或单一全局身份。每次 run 获得 daemon 作用域的 service 与 per-run 的 Codex anchor，使 daemon 既可缓存又彼此隔离。

   • 每个 LingTai 后端 daemon run 现在通过自己 daemon 作用域的 LLMService 运行，而不是共用父 agent service。
   • 某次 run 的 Codex anchor 从 resolved per-run daemon.json 路径派生，采用与 root agent 身份相同的 resolved-path 哈希方案，使每次 run 拥有各自独立但稳定的 anchor。
   • preset daemon 保留自己专用的 service，它们使用的 Codex preset 现在同样获得 daemon anchor，使 preset 驱动的 daemon 工作与临时 run 共享同一身份纪律。

   为什么重要：daemon 是 LingTai agent 卸载隔离工作的方式。如果每个 daemon 都复用一个父级/全局身份，独立 run 会在同一缓存命名空间里相互碰撞、彼此污染；如果各自生成不稳定身份，则谁都无法命中缓存。per-run 的 resolved-path anchor 让每个 daemon 拥有自己稳定的身份，同时让独立 run 保持干净隔离。

3. 03

   为什么缓存命中率上升，以及此前为何未命中

   本轮代码量小，但机制具体。值得明确说明缓存行为到底改了什么，以及此前的安排为何把命中白白浪费掉。

   • 改动后：同一 root agent 的多轮向 Codex 呈现单一、稳定、对齐的路由/缓存身份，provider 将其视为延续的会话，并从缓存提供共享前缀。
   • 改动后：daemon run 不再全部复用单一父级/全局身份，也不再生成逐调用的不稳定身份；在一次 run 内，session-id、thread-id 与 prompt_cache_key 对齐。
   • 改动前：root agent 与 daemon run 的 session-id、thread-id 与 prompt_cache_key 不够稳定或不够对齐，等价 prompt 在 Codex 看来彼此无关，因而错过缓存。
   • 改动前：daemon run 可能共用父级 service/缓存身份，或相互碰撞、彼此污染，于是本应复用前缀的 prompt 要么越过隔离边界，要么使彼此失效。

   为什么重要：prompt 缓存本质是一个识别问题：只有当 provider 能识别两次请求属于同一逻辑会话时，才会复用已有工作。此前的身份方案恰恰让最常重复的两个单元——root agent 与 daemon run——的识别变得不可靠。在这两个边界上把身份固定下来，正是命中率提升的来源。

4. 04

   与 OpenClaw、Hermes、Codex CLI 的对比

   这是架构层面的对比，而非基准测试结论。外部 CLI/proxy 系统的共同经验是：缓存复用跟随谁持有稳定的会话身份；v0.12.4 让 LingTai 在 agent 与 run 级别持有该身份。

   • 外部 coding CLI 与 provider proxy（Codex CLI，以及与 OpenClaw、Hermes 同类的 CLI/proxy 系统）通常在多轮之间保持稳定的 CLI 侧 session/thread/conversation 身份，这正是 provider 得以复用缓存前缀的原因。
   • 在 v0.12.4 之前，LingTai 没有为自己重复的单元一致地呈现这样的稳定身份，因此即便 prompt 实质上是延续，也无法享受同样的 provider 侧复用。
   • v0.12.4 让 LingTai 拥有从 resolved 路径派生的、属于自己的稳定 agent/run anchor，于是 Codex 在多轮之间一致地看到同一逻辑单元——这正是 CLI 侧 session 能良好缓存的同一性质。
   • 与单一长生命周期 CLI session 的区别在于隔离：LingTai 仍通过 per-run anchor 将独立 daemon 分开，因此在获得复用收益的同时，不会把无关 run 合并成一个共享身份。

   为什么重要：这组对比的目的是诚实地说明收益来源。LingTai 并没有发明新的缓存技巧；它采用的是良好 CLI 早已依赖的同一套稳定身份纪律，并把它应用到 LingTai 网络特有的 agent 与 daemon-run 边界上。