为什么我又做了一个 AI Coding CLI：Darwin Code 的取舍

项目地址：https://github.com/huizhike/darwin-code

现在 AI Coding CLI 已经不少了。继续做 Darwin Code，并不是因为世界上缺一个“聊天框”，而是因为我在长期使用开发机、远程服务器和自动化开发环境时，越来越在意几个很朴素的问题：

• 它能不能长时间跑着，而不是越跑越重？
• 模型、endpoint、key 是不是我自己明确配置的？
• 它是不是一个本地执行引擎，而不是被账号体系和平台逻辑包住？
• 当我想接 DeepSeek、Qwen、内部网关或其他 OpenAI-compatible 服务时，是不是足够直接？

Darwin Code 的答案很简单：做一个 performance-focused、BYOK-only、适合长时间开发工作流的 AI Coding CLI。

不是平台，而是执行引擎

很多 AI Coding 工具的产品重心是平台：账号、云端工作区、订阅、登录态、模型分发、遥测和插件市场。这些能力不一定错，但对于一套长期运行的开发环境来说，它们会让本地工具链变得不够透明。

Darwin Code 的定位更窄：它首先是一个本地执行引擎。外层是 Node launcher，核心在 Rust 运行时里，入口包括 TUI、非交互 exec、app-server 和 MCP server；每一轮对话会进入 core runtime，再走 provider、tool boundary、sandbox policy 和本地状态持久化。

这意味着它的核心问题不是“再做一个平台”，而是：

如何让 AI coding agent 在自己的机器上，以可控、轻量、可持续的方式运行？

这也是它和很多平台型工具的差异。Darwin Code 不试图替你决定模型供应商，也不把登录态、工作区账号和模型调用揉成一个黑盒。它更像一把可以放进自己工具箱里的执行刀具：边界清楚，能力集中，必要时可以替换 provider、切换模型、调整 endpoint。

这种设计会牺牲一部分“开箱即用的云端体验”，但换来的是工程可解释性。对于喜欢自己管理开发环境的人来说，这个取舍很重要：出了问题，至少知道配置在哪、请求往哪走、状态落在哪里。

BYOK：把模型选择权还给用户

Darwin Code 默认走 BYOK（Bring Your Own Key）。你需要显式配置 provider、model、base_url 和自己的 api_key。模型也挂在 provider 下面，而不是散落在多个隐式列表里。

一个简化后的配置长这样：

model_provider = "qwen"
model = "qwen3.6-plus"

[openai_compatible.qwen]
name = "Qwen"
base_url = "https://provider.example/v1"
wire_api = "chat-completions"
api_key = "YOUR_PROVIDER_API_KEY"

[openai_compatible.qwen.models."qwen3.6-plus"]
display_name = "Qwen 3.6 Plus"
context_window = 128000
max_output_tokens = 8192
thinking = true
multimodal = true

这里的关键不是 TOML，而是边界：provider 负责自己的 endpoint、key 和模型表；运行时只根据当前选择好的 provider + model 发起请求。这样 /model 切换模型时，背后的供应商也应该一起切换，不需要在调用链里到处猜。

目前最实用的路径是 OpenAI-compatible：DeepSeek、Qwen、企业内部网关、本地代理，只要兼容 Chat Completions 或 Responses 风格，就可以比较直接地接进来。OpenAI、Gemini、Claude 也在 provider 配置目标里，但我不想把未完成的部分包装成“全都好了”：原生 Gemini / Claude 流式适配仍需要继续补齐；在那之前，通过 OpenAI-compatible gateway 接入会更稳。

为什么强调长时间工作流？

因为很多真实开发不是在一个短会话里完成的。你可能在远程机器上跑重构，在本地开发环境里处理一个大仓库，或者让 agent 持续执行测试、修复、再验证。

长期运行和单次 demo 的要求不一样。单次 demo 更在意“能不能马上看到效果”；长期运行更在意进程是否稳定、配置是否可复现、状态是否能追踪、失败后是否容易定位。Darwin Code 的设计优先级也更偏向后者。换句话说，它更像工程工具，而不是一次性的演示玩具。

这种场景下，我更看重三件事：

1. 源码优先：需要最新能力时，直接从 GitHub 代码运行，而不是等包发布。
2. 低资源取向：减少不必要的平台逻辑，让运行时围绕核心执行路径收敛。
3. 显式配置：key、本地状态、provider 都是用户可见、可审计、可替换的。

源码运行方式也很直白：

cd /your/own/path/darwin-code
cp config-example.toml config.toml
$EDITOR config.toml
cd darwin-rs
cargo clean
cargo run -p darwin-code-cli --bin darwin-code

npm 也会提供更方便的安装方式：

npm install -g @darwin-code/darwin-code

但如果你想跟进最新代码，源码方式仍然是首选；npm 包可能会滞后。

当前边界

Darwin Code 不是一个“所有 provider 原生能力都已经完美实现”的项目。当前我更愿意把边界讲清楚：OpenAI-compatible 是主路径；本地 config.toml 是敏感文件，不应该提交；性能和低资源占用是设计方向，也需要后续用 benchmark 继续验证。

如果你想要的是一个账号体系完整、云端能力丰富的平台，Darwin Code 可能不是最合适的选择。

但如果你更在意的是：自己的 key、自己的 endpoint、自己的开发环境，以及一个可以长期运行的 AI coding 执行引擎，那它值得试一下。

GitHub：https://github.com/huizhike/darwin-code

欢迎 star、提 issue，尤其欢迎关于长时间运行、OpenAI-compatible provider、私有网关接入和资源占用的真实反馈。