DeepSeek 出了个终端编程 Agent，刚开源 就8.1k Star了，我把代码读完后发现，它真正的壁垒不是 AI，是会计

来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 网络安全, 编程, 芯片, 大模型
原文链接： https://mp.weixin.qq.com/s/DVTs_pkZgo0IqyMsjvHO2g

摘要

你可能会问，市面上的 AI 编程工具已经多到产生选择焦虑了——Cursor、Claude Code、Aider、Copilot——为什么还需要一个新的？ 启动图标 再说一个你可能没意识到的事实。 你用 Claude Code 写一天代码，API 账单大概在 $15-30。这不是因为 Anthropic 贵，是因为每次请求，你的 system prompt、工具定义、对话历史都要原封不动重新传一遍。 模型每次都从零开始"读"你的上下文，而你为这些重复传输的字节付了全价。 DeepSeek 有个机制叫前缀缓存（Prefix Cache）：如果两次请求的前缀字节完全一致，缓存部分...

核心内容

你可能会问，市面上的 AI 编程工具已经多到产生选择焦虑了——Cursor、Claude Code、Aider、Copilot——为什么还需要一个新的？
启动图标
再说一个你可能没意识到的事实。

你用 Claude Code 写一天代码，API 账单大概在 $15-30。这不是因为 Anthropic 贵，是因为每次请求，你的 system prompt、工具定义、对话历史都要原封不动重新传一遍。 模型每次都从零开始"读"你的上下文，而你为这些重复传输的字节付了全价。

DeepSeek 有个机制叫前缀缓存（Prefix Cache）：如果两次请求的前缀字节完全一致，缓存部分只收 ~10% 的费用。这个机制在 API 文档里只有一行，大多数 agent 框架根本没当回事。

Reasonix 把它当成了架构的第一性原理。
TUI 界面，感觉很好看，我是做不出来他奶奶的，还出了 webui 界面，也是很美观
读完它的源码和架构文档后，我的判断是：这不是又一个"套壳" agent，这是一个把 DeepSeek 的成本优势压榨到极限的工程艺术品。

先说一个反直觉的事实，最好的编程 agent 不是"最聪明的"，我认为是是"最省钱的"那种

先看一组真实数据（来自 Reasonix README 的 case study）：

真实用户，单日（2026-05-01）：4.35 亿 input tokens，99.82% 缓存命中，实际花费 ~$12。 同样的 workload 如果没有缓存命中，需要 ~$61。

4 亿 token 花 12 美元。你感受一下。

这背后是一个简单的算术题：DeepSeek V4-Flash 的缓存命中价是 $0.014/百万 token，缓存未命中价是 $0.14/百万 token。10 倍的差价。

Claude Code 没有这个机制——不是因为 Claude 做不到，是因为 Anthropic 的定价模型没有为缓存做如此激进的设计。Cursor 也没有——因为它的后端是多模型的，无法为单一 provider 做深度优化。

这就是 Reasonix 最核心的取舍：故意只支持 DeepSeek。 不是做不到多 provider，是不做。绑死一个后端，把它的缓存机制吃干榨净——这不是技术限制，是产品策略。

三根支柱：读完架构文档我服了

Reasonix 的整个循环围绕着三根支柱构建。我逐一拆解。

Pillar 1：缓存优先循环——"上下文分区"这个想法简单得像天才

问题的本质是：LLM API 的前缀缓存要求两次请求的前缀字节完全一致。大多数 agent 框架每轮都重写 system prompt、重排工具定义、插入时间戳——缓存命中率实际不到 20%。

Reasonix 的解法是把上下文切成三块：

┌─────────────────────────────────────────┐
│ IMMUTABLE PREFIX │ ← 整个 session 不变 │ 缓存命中候选
│ system + tool_specs │ │
├─────────────────────────────────────────┤
│ APPEND-ONLY LOG │ ← 单调增长 │ 保留前面轮次的缓存
│ [assistant₁][tool₁]... │ │
├─────────────────────────────────────────┤
│ VOLATILE SCRATCH │ ← 每轮重置 │ 从不发送给 API
│ R1 思考 / 临时计划 │ │
└─────────────────────────────────────────┘
关键不变量：

• • Prefix 在整个 session 里只算一次，哈希后钉住，永不变。
• • Log 只能追加，不能改写。 这就是为什么 Reasonix 不支持"编辑历史消息"——那不是 UI 限制，是缓存不变量。
• • Scratch 是模型内部的思考草稿，在发送下一轮请求前被蒸馏提炼，提炼后的信息才进 Log。
  这解释了 README 里那句看似凡尔赛的话："缓存稳定不是开关，而是循环要围绕设计的不变量。"

你再想想——为什么 Claude Code 不支持"一直开着"？因为它的对话历史每轮都在变，缓存根本用不上，开着就是烧钱。Reasonix 的设计让挂着不关在经济上是可行的。

还有一个细节：并行工具派发。read_file、search_content、web_search 这类只读工具声明了 parallelSafe: true，循环会把连续的并行安全调用打包成一个 chunk，Promise.allSettled 并发执行。互斥工具（写文件）充当串行屏障——读写顺序不被破坏。这个优化在 4.35 亿 token 的 workload 里省了多少轮次，自己去品。

Pillar 2：工具调用修复——四个 pass，专治 DeepSeek 的"小毛病"

如果你用过 DeepSeek API，你可能遇到过这些情况：

• • 模型把 tool call JSON 塞进了 reasoning_content（ 标签里），忘了在正式的 tool_calls 字段里暴露
• • 参数多了就漏字段
• • 同一个工具用同样的参数反复调用（call-storm）
• • JSON 被 max_tokens 截断，半截丢给 parser
  Reasonix 在收到模型响应后跑四个修复 pass：
  Pass干什么为什么 DeepSeek 需要flatten参数 >10 个或嵌套 >2 层的 schema，自动扁平化为点号表示发给模型DeepSeek 对深层嵌套 JSON 的生成稳定性不如扁平结构scavenge用正则 + JSON parser 从 reasoning_content 里捞出模型"想调用但忘了输出"的 tool callDeepSeek 的 reasoning 有时在 think 里把 tool call 想好了，但正式输出里丢了truncation检测不完整的 JSON，通过补括号或请求 continuation 修复max_tokens 截断在参数中间也是常事storm检测滑动窗口内完全相同的 (tool, args) 元组，抑制调用并注入反思轮模型偶尔会陷入"调用→失败→重试→相同调用"的死循环
  这四个 pass 是纯工程——没有 AI 魔法，就是正则、状态机、去重哈希。但合在一起，它们让 DeepSeek V4-Flash 在工具调用场景下的可靠性和

...(内容截断，完整内容请查看原文)

本页由自动化脚本生成，待人工审核补充