源码拆解：DSH 的 system prompt 不是一份大 prompt，而是三条装配线

[bobleer]

刚把 packages/core/system-prompt、agent-loop 和 tools 这条链路顺了一遍。先说结论：DSH 的“秘方”并不是一份很长的 system prompt，而是三条分开的装配线。

第一条是相对稳定的 prompt sections：identity、persona、Plan policy、各插件自己的 guidance、Code SDK，按显式 order 组合。第二条是 provider/model/cwd 这类会变的 runtime facts，它们不会每轮粗暴地重写固定前缀，而是在变化或压缩移除后，以可持久化的 user snapshot 追加。第三条则是独立的 canonical tool schemas。

这个拆法里最反直觉的是 Plan Mode。它并不会把 write/bash 从工具列表里删掉，源码测试里这些工具在 Plan 下照样可以执行；Plan 插件只增加一段 policy。好处是 Code SDK 和工具目录不用跟着再抖一次，坏处也要讲清楚：这不是执行层的安全 gate，真正的限制仍然要靠 sandbox / approval。

Code Mode 也不适合直接概括成“更省 token”。它确实把模型直接看到的 wire tool 收敛成 run_code，其他工具从生成 SDK 里调用，而且内部调用仍然重走完整工具管线；但仓库里的 ACP snapshot 中，native prompt 约 3.5KB，code prompt 约 28KB。总成本得把 prompt、独立 schema、cache hit 和真实调用轨迹放在一起测，不能只看 tool 数量下结论。

我觉得这里可以加一个很有用的调试面：除了 --dump-config，能不能提供一次请求的 prompt section provenance、tool schema digest 和预计 cache boundary？这样写插件的人一眼就能看到，是哪一段配置让前缀失稳。

利益相关：我参与 BitFun。我们碰到的是同一个 DeepSeek cache 问题，但路线更偏产品工程：session identity 缓存固定 system prompt，工具 contract 明确要求 byte-stable，动态 reminder 按固定顺序放在后面。README 公开的那轮 SWE-Bench-Pro 平均 KV cache hit 是 98.67%，这是一次公开评估均值，不是所有任务的保证。两边的实现取舍都挺值得继续对照：https://github.com/GCWing/BitFun

相关源码：

• packages/core/system-prompt/src/index.ts
• packages/core/agent-loop/src/runtime-context.ts
• packages/core/tools/src/index.ts
• packages/plan/plan-mode/src/index.ts
• packages/plan/plan-mode/tests/plan-mode.spec.ts