DeepSeek 的 prefix cache 定价策略让长会话 coding agent 的成本两极分化：缓存命中时输入只要 0.02 元/百万 token，缓存未命中则要 1 元，差了 50 倍。同样一段长上下文编程任务，会话管理得好和管得不好，成本可能差一个数量级。
但主流终端 coding agent（Claude Code、Codex 等）并不针对 DeepSeek 的缓存机制做优化。它们按通用模型设计，system prompt、工具列表、上下文窗口的维护方式没有围绕 prefix cache 稳定性来调。结果就是你用 DeepSeek 的 API，却付着缓存未命中价。
Reasonix 就是冲着这个缺口来的--一个社区构建的 DeepSeek 原生终端 coding agent（非 DeepSeek 官方产品，仓库 esengine/DeepSeek-Reasonix），围绕 DeepSeek prefix cache 调优，让长会话的 token 成本保持低位。这篇 SOP 走一遍从安装到缓存调优到双模型配置的完整流程。所有命令均来自 README，配置示意已标注以官方文档为准。
一、场景痛点：长会话成本为何失控
先看 DeepSeek 的定价模型（来自 DeepSeek 官方文档）：
| 项目 | 价格（元/百万 token） |
|---|---|
| 缓存命中输入 | 0.02 |
| 缓存未命中输入 | 1.0 |
| 输出 | 2.0 |
缓存命中和未命中差 50 倍。一次长会话编程任务，system prompt + 工具定义 + 历史对话动辄上万 token。如果每轮对话都触发缓存未命中（prefix 变了），成本直接乘 50。
什么时候缓存会失效？当请求的 prefix（从开头到某个位置的前缀）发生变化时。常见原因：
- system prompt 被频繁修改
- 工具列表顺序变动或增删
- 上下文压缩时丢失了原始前缀结构
- 多轮对话中插入新内容导致前缀偏移
Claude Code 和 Codex 是通用 coding agent，不专门对齐 DeepSeek 的 prefix cache 规则。Reasonix 的 cache-aware 机制就是来补这个缺口的。
二、准备：安装 reasonix 与 DeepSeek API Key
Reasonix 是 Go 写的单二进制工具（CGO_ENABLED=0，唯一依赖 TOML 解析器），交叉编译支持 6 个目标（darwin / linux / windows × amd64 / arm64）。安装方式按你的平台选。
Path A：npm 全局安装（任意 OS，最简单）
npm i -g reasonixPath A 备选：macOS Homebrew
brew install esengine/reasonix/reasonixPath D：源码编译（需要 Go 环境）
git clone https://github.com/esengine/DeepSeek-Reasonix.git
cd DeepSeek-Reasonix
make build # 产出 bin/reasonix
make cross # 交叉编译 6 目标，产出 dist/安装完验证：
reasonix --help如果你还想要桌面 app（Path B）或 VS Code 扩展（Path C），需要先完成 Path A。VS Code 扩展 ID 是 SivanLiu.reasonix-agent，启动后会拉起本地 reasonix acp 后端。
接下来准备 DeepSeek API Key。在 DeepSeek 开放平台获取后，按环境变量设置（请替换为你的真实 key）：
export DEEPSEEK_API_KEY=你的key具体环境变量名以 reasonix setup 交互引导提示为准。
三、配置：reasonix setup 与 reasonix.toml
装好后第一步是初始化配置：
reasonix setupreasonix setup 会引导你配置一个 provider 和 model。DeepSeek 是预设 provider，选它再填入 API Key 即可。配置完成后启动交互式 TUI：
reasonixReasonix 的核心理念是 config-driven--一切配置在 reasonix.toml 文件里声明，没有硬编码的模型。README 明确提到 reasonix.toml 管理以下概念区域：
- providers：API 端点配置。DeepSeek 是预设；任何 OpenAI 兼容端点写一条配置即可接入。
- agent：agent 行为配置。
- enabled tools / plugins：启用的内置工具和外部插件列表。
README 未完整展示 reasonix.toml 的字段定义。以下是基于 README 提到的概念区域写的示意结构，具体字段名和默认值以官方 GUIDE / SPEC 文档为准：
# reasonix.toml 示意结构
# 基于 README 提到的概念区域，非完整字段定义
# 具体字段以官方 GUIDE / SPEC 文档为准
# [providers] 区域
# DeepSeek 为预设 provider
# 任何 OpenAI 兼容端点写一条配置即可接入
# [agent] 区域
# agent 行为配置
# enabled tools / plugins
# 启用的内置工具（编译期自注册）和外部插件（MCP 兼容）完整命令列表可通过 reasonix --help 查看。
四、缓存调优实战：让 prefix cache 命中率拉满
这是 Reasonix 区别于通用 coding agent 的核心价值。DeepSeek 的 prefix cache 要求请求的前缀保持稳定，命中才能走 0.02 元的价。Reasonix 的 cache-aware 机制从三个层面帮你维持前缀稳定：
1. 启动注入稳定环境摘要
Reasonix 在启动时注入一段稳定的环境摘要（environment summary），这段内容在整个会话中保持不变，构成 prefix cache 的稳定基底。只要这段前缀不动，后续请求的前缀就能命中缓存。
2. 陈旧工具输出剪枝
当会话变长需要压缩 summary 时，Reasonix 会在压缩前剪枝掉陈旧的工具输出，而不是粗暴截断历史。这样保留了前缀结构的完整性，避免因压缩导致 prefix 偏移而缓存失效。
3. 工具 schema 契约
内置工具在编译期自注册，schema 契约有文档供回归审查。这意味着工具定义是稳定的、可预期的，不会在会话中途变动导致前缀变化。
实操建议对照表：
| 实践 | 效果 | 对应价格 |
|---|---|---|
| 保持 system prompt 不变 | 前缀稳定 | 命中 0.02 元 |
| 不中途增删工具 | 工具列表不变 | 前缀稳定 |
| 长会话用 summary 压缩 | 剪枝而非截断 | 前缀结构保持 |
| 频繁改 system prompt | 前缀变化 | 未命中 1 元 |
核心公式：缓存命中 0.02 元 vs 未命中 1 元，差 50 倍。Reasonix 的 cache-aware 机制就是帮你守住命中这一侧。
五、进阶：双模型 executor + planner
Reasonix 支持可选的双模型同跑模式：executor 和 planner 分别跑在两个独立、缓存稳定的 session 里。
为什么分两个 session？不同任务对上下文的需求不同：
- planner：负责规划，需要全局视野，上下文较大
- executor：负责执行具体编码任务，上下文更聚焦
塞在同一个 session 里，planner 的规划上下文会和 executor 的执行上下文互相干扰，导致 prefix 频繁变化，缓存失效。分两个独立 session 后，各自的 prefix 保持稳定，命中率更高。
在 reasonix.toml 中配置双模型的示意（具体字段以官方文档为准）：
# 示意：双模型 executor + planner 分 session
# 两者各自独立、缓存稳定
# DeepSeek 是预设模型，也可配不同的 OpenAI 兼容端点
# 具体配置字段以官方 GUIDE / SPEC 文档为准双模型不是必须的，单模型（DeepSeek 预设）已能满足大多数场景。当你发现单 session 里规划和执行互相干扰、缓存命中率下降时，再开双模型。
六、MCP 插件：接外部工具
Reasonix 的插件机制是 MCP 兼容的：外部工具以子进程 + stdio JSON-RPC 运行。内置工具在编译期自注册，外部工具通过插件机制接入。
这意味着你可以把现有的 MCP server（文件系统、数据库、搜索等）接入 Reasonix，扩展 agent 的能力边界。插件在 reasonix.toml 的 enabled tools / plugins 区域声明。
具体插件配置字段以官方文档为准，可通过 reasonix --help 查看完整命令列表。
七、完整工作流
把以上步骤串起来，一个典型的 Reasonix coding 工作流：
1. npm i -g reasonix # 安装
2. export DEEPSEEK_API_KEY=你的key # 设置 API Key
3. reasonix setup # 配置 provider + model
4. reasonix # 启动 TUI 交互
5. 在 TUI 中描述任务 # agent 开始规划
6. agent 执行编码任务 # cache-aware 保持 prefix 稳定
7. 审查 agent 输出 # 人工确认进阶流程（双模型）：
1. 完成 Path A 安装 + reasonix setup
2. 在 reasonix.toml 配置 executor + planner 双模型（示意，字段以官方文档为准）
3. reasonix 启动后，planner 规划 + executor 执行分 session 运行
4. 各 session prefix 独立稳定，缓存命中率最大化八、踩坑记录
坑一：Reasonix 非官方产品，无 SLA。 Reasonix 是社区构建的工具（仓库 esengine/DeepSeek-Reasonix），不是 DeepSeek 官方产品。没有官方 SLA 保障，生产环境使用需自担风险，建议关注仓库 issue 跟踪稳定性。
坑二：频繁改 system prompt 会击穿缓存。 prefix cache 的前提是前缀稳定。如果你在会话中途修改 system prompt、增删工具，前缀就变了，缓存直接失效，从 0.02 元跳到 1 元。Reasonix 的 cache-aware 机制能帮你维持稳定，但你自己频繁改还是会失效。
坑三：需自带 DeepSeek API Key。 Reasonix 是客户端工具，不自带模型访问权限。你必须自己去 DeepSeek 开放平台申请 API Key 并按环境变量配置。
坑四：桌面 app / VS Code 扩展依赖 Path A。 Path B（桌面 app）和 Path C（VS Code 扩展）不能独立使用，必须先完成 Path A（CLI / TUI 安装）。VS Code 扩展启动后会拉起本地 reasonix acp 后端。
坑五：配置字段别照抄示意结构。 本文的 reasonix.toml 示意只反映了 README 提到的概念区域（providers / agent / enabled tools / plugins），不是完整字段定义。实际使用前务必查阅官方 GUIDE / SPEC 文档确认字段名和默认值，别照着示意结构写配置然后报错。
九、常见问题 FAQ
Q1：Reasonix 和 Claude Code 怎么选？ Claude Code 是 Anthropic 官方终端 agent，针对 Claude 模型优化；Reasonix 是社区构建的 DeepSeek 原生终端 agent，针对 DeepSeek prefix cache 调优。如果你主力用 DeepSeek 且在意长会话成本，Reasonix 的 cache-aware 机制能帮你守住 0.02 元命中价。如果你用 Claude 模型，Claude Code 是原生选择。两者不互斥，可以按模型分别使用。
Q2：缓存命中怎么算的？ DeepSeek 的 prefix cache 机制：当请求的前缀（从开头到某位置的连续 token）与之前某次请求一致时，这部分走缓存命中价（0.02 元/百万 token）；不一致的部分走未命中价（1 元）。Reasonix 通过注入稳定环境摘要、剪枝陈旧工具输出、固定工具 schema 来维持前缀稳定，提高命中率。
Q3：能接 MCP 吗？
能。Reasonix 的插件机制是 MCP 兼容的，外部工具以子进程 + stdio JSON-RPC 运行。内置工具编译期自注册，外部 MCP server 在 reasonix.toml 的 enabled tools / plugins 区域声明。具体配置字段以官方文档为准。
Q4：Windows 能用吗？
能。npm i -g reasonix 支持 Windows；源码编译 make cross 产出含 windows amd64 / arm64 目标。Reasonix 是 CGO_ENABLED=0 单二进制，无 CGO 依赖，Windows 上可直接运行。
Q5：双模型 executor + planner 怎么配？
双模型是可选模式：executor 和 planner 分两个独立 session 运行，各自 prefix 独立稳定。配置在 reasonix.toml 中声明（具体字段以官方 GUIDE / SPEC 文档为准）。DeepSeek 是预设模型，也可配不同的 OpenAI 兼容端点。单模型已能满足大多数场景，当规划和执行互相干扰、缓存命中率下降时再开双模型。
参考来源
- esengine/DeepSeek-Reasonix GitHub 仓库
- DeepSeek 官方定价文档
- Reasonix 官方 GUIDE / SPEC 文档（以仓库 README 内链接为准）