Reasonix：一个基于DeepSeek、具有Claude Code风格的编程助手

如果你喜欢 Claude Code 的工作方式——即那种运行在终端中、能读取文件、执行命令并自行修正错误的编程助手——但又不想支付每月订阅费，只愿按任务数量付费的话，这里有个解决方案：Reasonix，一个仿照 Claude Code 风格的命令行工具，它连接的是 DeepSeek 的 API。

更新于 2026-09-16：我已于 2026-09-09 在自己的环境中停用 Reasonix，如今它在我的聊天应用中也不再作为终端机器人出现。本文仅作为记录其运作方式的参考；若想寻找当前仍在维护且功能类似的方案，可参阅 DeepSeek Harness (dsh)。

最终能得到什么

首先是截至 2026-07-11 的版本信息：

$ reasonix --version
1.18.0

接下来是工作流程：你进入某个项目的目录并打开终端，输入 reasonix，随后描述需求即可：“给这个脚本添加 --dry-run 参数并更新 README。”该代理会读取相关文件、执行编辑操作，运行脚本以验证结果后再反馈给你——整个过程与 Claude Code 的使用体验如出一辙。区别仅在于底层实现机制：

• 核心计算能力由 DeepSeek 提供，费用按 token 计费。目前有两个服务等级可满足各类需求：flash 模型适用于日常编辑及简单任务；pro 推理模型则更适合复杂的代码重构与调试工作。2026年6月，我持续运行的代理程序正是基于这两个等级提供服务，最终 DeepSeek 的计费总额仅为 24.08 美元。
• 使用时间完全由你掌控。由于无需购买用户许可，你可以让代理持续处理大量耗时工作——比如批量代码重构、测试用例编写或文档更新——而无需时刻留意使用量统计。
• 状态信息存储于本地目录中。Reasonix 会在 ~/.reasonix/ 目录下创建配置文件，并保存各项目的会话历史与记忆内容；如此一来，每次运行时它都能记住对应代码库的相关上下文信息。

步骤一：安装

这是一个全局性的 npm 包：

npm install -g reasonix
reasonix --version

安装过程即此而已。若你将 Node.js 安装在非标准路径下，请记下 npm 的完整路径——后续在设置自动更新功能时还需用到它。

步骤二：指定 DeepSeek 作为后端

首先登录 DeepSeek 平台生成 API 密钥（按使用量付费；我整个代理系统7月前11天的开销仅为2.23美元）。随后在 ~/.reasonix/config.toml 中配置相关参数：

# ~/.reasonix/config.toml — the shape, not a paste of mine
default_model = "deepseek-flash"

[[providers]]
name        = "deepseek"
base_url    = "https://api.deepseek.com"
models      = ["deepseek-v4-flash", "deepseek-v4-pro"]
api_key_env = "DEEPSEEK_API_KEY"    # NAME of the variable, not the key itself

各类代理工具的配置项名称虽略有差异，但本质上均围绕三个核心要素：基础 URL、认证凭证以及模型编号。无论使用何种工具，都必须遵守两条基本规范：

• chmod 600 设置密钥文件权限；切记切勿在命令行中直接输入密钥——否则它会出现在 shell 历史记录及 ps 输出结果中。设置 api_key_env 的目的正是将敏感信息与配置内容分离：配置文件便于你向他人求助时粘贴分享，而 .env 文件则绝对保密。
• 务必同时指定两个服务等级。默认使用 flash 模型、复杂任务才启用 pro 模型——这样既能大幅降低日常开销，又能在模型难以胜任时快速升级配置。

步骤三：子代理与技能设置

所谓“子代理”，即主代理所调用的独立工作单元——比如“在代码库中搜索所有调用该函数的位置”；由于按 token 计费，它们也是控制成本的关键手段：主代理使用 pro 模型统筹全局时，各子代理仍可运行于资源消耗更低的 flash 等级。而“技能”则指代理按需加载的指令集；这样一来，诸如部署流程或测试编写规范等内容只需记录一次即可反复调用。

当前版本允许你明确指定任务分配规则而非依赖默认设置，下面这段代码尤为关键——它直接决定了费用支出：

[agent]
# planner_model  = "deepseek-pro"    # two-model collaboration: pro plans, flash executes
# subagent_model = "deepseek-pro"    # default tier for spawned workers
# subagent_models = { review = "deepseek-pro", security_review = "deepseek-pro" }
# recovery_model = "deepseek-pro"    # steps in when a turn fails

其中第三行的按技能划分模型映射最为实用。大多数常规操作——搜索代码、重命名文件或编写测试——均适合由 flash 模型完成；而代码审查或安全检测则不然：此类任务若交由廉价模型处理，极易产生看似合理实则错误的结论。因此只需为少数关键任务指定高级模型即可实现精准成本控制，这比对所有子代理统一配置一个等级更为高效。

步骤四：设置定期自动更新

这类命令行工具迭代速度极快，版本滞后可能导致功能缺失。所幸目前已有内置更新机制可供使用：

reasonix upgrade

只需在配置文件中选定对应版本轨道即可：

[cli]
update_channel = "stable"   # stable | preview

若希望完全自动化操作，也可自行编写定时任务。我本人便从未手动干预过相关流程；直至 2026年9月停用前，我的系统始终运行着 v1.18.0 版本的 Reasonix。下面这段脚本直接调用 npm 指令——即便你选择使用内置更新功能，该脚本仍值得参考：因为若单纯定时执行 npm update -g，极易出现两类潜在故障：

#!/usr/bin/env bash
set -euo pipefail
LOG="$HOME/logs/update-reasonix.log"
NPM="$(command -v npm)"

# 1. Lock guard — two overlapping npm runs corrupt the install
exec 9>"${LOG%.log}.lock"
flock -n 9 || { echo "update already running"; exit 0; }

# 2. Log rotation — cron logs grow forever unless you trim them
[ -f "$LOG" ] && tail -n 5000 "$LOG" > "$LOG.tmp" && mv "$LOG.tmp" "$LOG"

echo "before: $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"
"$NPM" update -g reasonix >> "$LOG" 2>&1
echo "after:  $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"

你可以将该脚本绑定至 cron 或 systemd 定时任务中——两种方式均可生效。记录更新前后的版本信息至关重要：若某天代理行为突然改变，通过日志即可迅速判断是否为版本更新所致。

在实际项目中应用

前文所述均为全局配置内容；真正决定工具实用性的则是项目级设置。Reasonix 的配置读取遵循特定优先级顺序：

flag  >  ./reasonix.toml  >  ~/.reasonix/config.toml  >  built-in defaults

如此一来，提交至代码库根目录的 reasonix.toml 便成为该项目的专属操作指南，全局配置文件则负责保存认证信息与个人偏好。部分设置项被刻意限定为全局配置——比如更新渠道与 CLI 行为偏好——以确保他人共享的代码库无法擅自更改你的系统更新机制。这种设计十分合理：它使得他人提供的项目配置文件具备安全性，可放心采用。

各项目的会话状态与记忆内容亦按项目分类存储于 ~/.reasonix/projects/<project>/sessions/ 目录下。从项目目录启动工具可获得跨会话的上下文延续性——它能记住上次处理该代码库时学到的信息而非每次从头开始；从 $HOME 目录启动亦可运行，但此时所有项目的上下文信息将混杂在一起，若需同时操作多个代码库则应避免此种做法。

我认为项目配置文件至少应包含以下几类内容——按性价比排序：

• 构建与测试指令。这是最具价值的配置项。知晓如何验证自身输出的代理便不再盲目猜测。
• 任务分配规则——即前文提到的 subagent_models 配置块，需针对具体项目作出调整。涉及安全层面的项目与静态站点所需配置自然截然不同。
• 绝对禁止的操作。比如部署限制、不可修改的文件类型或“严禁对生产环境执行此操作”等约束条件——此类规则只需书写一次即可永久生效。
• 各类流程化操作的技能描述——诸如部署手册或发布检查清单等，将其写入配置文件即可使相关流程完全依附于代码库存在而非仅留存于记忆中。

若想了解该工具如何应用于实际场景，可参阅 自托管聊天应用、备份工具图形界面以及 WordPress 静态化重构项目——它们均具备共同特征：结构清晰的代码库、可验证操作结果的测试指令以及发布前的多重校验机制。

附加功能：集成至聊天应用

此类终端代理未必局限于命令行界面。由于 Reasonix 本质上只是基于伪终端运行的 CLI 程序，你便可借助 xterm.js 技术将其输出内容实时传输至网页端，从而在任何联网设备上调用该工具。直至 2026年9月，我自制的聊天应用便采用了此种方案：Reasonix 以“终端机器人”身份与普通聊天代理并列呈现，并配有启动/重启/停止控制功能。整个集成过程已详细记载于 DisPatch：自托管 AI 聊天系统一文中。

注意事项

• 推理型模型在回复前看似“停滞”了。 Pro 版本会在生成回复前先输出其思考过程；但如果围绕该代理的封装层或网关设置了较短的空闲超时时间，那些需要长时间思考的请求就会被中途中断。此时应适当延长超时时间，而非责怪模型本身。
• 切勿将密钥放入命令行参数中。 密钥只能保存在配置文件（权限设为 chmod 600）或环境变量文件中。通过命令行传递的密钥很容易泄露在历史记录或进程列表中。
• 在更新脚本中显式指定 npm 路径。 Cron 任务运行时所使用的 PATH 环境变量极为精简；因此交互式 Shell 与 Cron 环境中对 npm 的解析结果可能不同。务必在脚本中硬编码或显式指定其路径。
• 为更新任务加锁。 若未使用 flock 进行加锁，当 npm 注册表响应缓慢且更新任务调度频繁时，便可能同时出现两次全局安装操作，最终导致 CLI 工具无法正常使用。
• 留意费用累积情况。 只有将“按令牌计费”设为默认模式时，相关费用才会维持在较低水平。若出于“以防万一”的考虑而让所有任务都使用 Pro 版本，则费用便会大幅上升——建议在最初一周内密切监控实际支出情况。
• 会话文件夹会不断增大。 按项目保存对话历史固然不错，但若是频繁交互的代理，数月下来相关数据量也会激增；因此需定期清理该文件夹中的旧会话数据。
• 配置结构可能发生变化。 本工具之所以设有 config_version 标记，正是因为不同版本间的配置结构会有所调整——比如某些凭证原本位于 config.toml 中，后来则被移至 api_key_env 处。倘若更新后代理突然无法完成身份验证，请先对照最新文档检查配置结构，再重新生成所需密钥。
• 恢复旧会话并非零成本。 若提供商的提示缓存窗口已过期才重新开启对话，那么整个上下文内容又需重新发送，费用也相应产生。脚本中设有在冷启动时清理过时工具输出的选项，建议保持启用状态。通常情况下，新建一个会话比恢复旧会话更经济实惠。

相关参考：更全面的 DeepSeek 集成指南介绍了如何将 Claude Code CLI 指向 DeepSeek 提供的兼容 Anthropic 协议的端点——原理与前述内容类似。另可参阅 DeepSeek Harness (dsh)、如何配置 LLM 助手以及 DisPatch：自托管式 AI 聊天工具。