📌 项目地址Gitlawb/openclaude | ⭐ 28,022 颗星 | 🔧 TypeScript | 📜 NOASSERTION

不是又一个 ChatGPT 壳子

你打开 README 第一行:”OpenClaude is an open-source coding-agent CLI for cloud and local model providers”。它没说自己要做 AI 的瑞士军刀,也没说“一站式解决方案”。它只是个 CLI,专为写代码的人设计,把多个 AI 后端接到同一个终端里。

28022 个 star,被 GitLawb、Atomic Chat、小米 MiMo 等团队赞助。数字不算小,但真正值得问的问题是:它到底解决了什么,解决得怎么样?

拼合后端的成本

我试过同时用 GPT-4o、本地 Qwen2.5 和 Gemini。换一个模型就得换一个终端、换一套启动参数,有时候还得换工具。OpenClaude 的做法是把这些后端抽象成一个接口,用 openclaude 启动,用 /provider 命令切换。

安装:

npm install -g @gitlawb/openclaude@latest

Arch Linux 用户可以用 AUR:

paru -S openclaude

启动前如果 ripgrep not found,先装 ripgrep,确认 rg --version 能跑。

最快配 OpenAI:

export CLAUDE_CODE_USE_OPENAI=1
export OPENAI_API_KEY=sk-your-key-here
export OPENAI_MODEL=gpt-4o
openclaude

Windows PowerShell 用 $env: 代替 export

最快配本地 Ollama:

export CLAUDE_CODE_USE_OPENAI=1
export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_MODEL=qwen2.5-coder:7b
openclaude

关键变量是 CLAUDE_CODE_USE_OPENAI=1。它告诉 OpenClaude 走 OpenAI 兼容接口,剩下的 OPENAI_BASE_URLOPENAI_MODEL 指向具体后端。也就是说,只要后端提供 OpenAI 兼容 API,就能接入。Gemini、GitHub Models、Codex(含 OAuth)、Ollama、Atomic Chat 都适用。

工作流长的样子

进入终端后,所有交互在同一个对话里完成。斜杠命令驱动:

  • /provider:引导创建和保存多个配置档案。我配了三个,gpt-4o 日常用,qwen2.5-coder:7b 离线跑,gemini-1.5-pro 处理长上下文。切模型只用打一条命令。
  • /onboard-github:简化 GitHub Models 的认证,不用手动处理 OAuth 流程。

内置的能力包括:bash 执行、文件读写、grep 搜索、glob 匹配、子代理(agent)、任务串行(tasks)、MCP 协议、web 工具。这些都在同一个会话里,不用另开窗口跑命令。

我写代码时常用 grep 搜项目里的 TODO,再让模型解释上下文,然后让它改。整个过程不离开终端。流式输出也不卡,体验像在本地跑模型。

藏在细节里的东西

项目结构和 README 透露出一些有意思的信息。

一是 生态拼图。赞助商包括 GitLawb(代码托管)、Bankr.bot(金融机器人)、Atomic Chat(去中心化聊天)、小米 MiMo(IoT 平台)、Atlas Cloud(云服务)。每个赞助都对应一个特定的使用场景。这说明 OpenClaude 不是个人玩具,是真的有人在用它在不同场景里接模型。

二是 VS Code 扩展。README 提到扩展支持启动集成和主题,但没有详细展开。扩展的目的是把 CLI 嵌入编辑器,省去切终端这一步。我试了下,功能基本就是“在 VS Code 里开一个 OpenClaude 终端”,外加主题适配。不算惊艳,但够用。

三是 镜像到 GitLawb。GitLab 到 GitHub 的镜像常见,反过来不常见。GitLawb 是一个基于 IPFS 的去中心化代码托管平台。这个镜像意味着 OpenClaude 本身也有“抗审查”的打算——即使 GitHub 方面出问题,代码和社区还能在 GitLawb 上继续。

几个值得注意的风险

CLI 的定位。OpenClaude 是 coding-agent,不是通用聊天客户端。如果你只是想问几个问题,它不如直接开个 chat.openai.com。它假定你正在写代码,需要把 AI 嵌进 bash、文件操作和代码搜索里。这个前提成立,体验就好用。不成立,第一反应可能是“怎么连个聊天界面都没有”。

生态稳定性。28022 个 star 很多,但 star 不等于社区贡献。OpenClaude 的讨论区和 PR 检查都在 GitHub 上,目前看起来维护者活跃。但一旦核心维护者精力不足,这种高度集成多个后端的项目会变得难以维护——每个后端接口变动,都要跟。如果你重度依赖它,建议关注一下仓库的提交频率和 issue 响应速度。

环境变量的混乱风险。如果你同时接多个模型,环境变量会堆叠。我试过 CLAUDE_CODE_USE_OPENAIOPENAI_BASE_URLOPENAI_MODELOPENAI_API_KEY 同时存在,忘了哪个是哪个。最好用 /provider 保存配置,然后只在有需要时手动设置。依赖环境变量做全局配置,自己容易搞混。

客观评价

OpenClaude 是当前 star 最多的多后端编码 CLI 之一。它的核心价值不是模型本身,而是拼合成本——把多个后端接到同一个工作流里,省去切换工具的时间。是否值得用,取决于你平时要维护多少种 AI 后端。如果你只用一家,比如只开 ChatGPT 会员,那它没有意义。如果你手上同时有个 gpt-4o 在云端跑、一个 qwen2.5 在本地跑、一个 gemini 做长文档分析,那它确实能减少摩擦。

它的局限也很明确:不是聊天工具、不是代码补全、不是 IDE 插件。它是一个终端命令,完成的是“从代码到模型再到代码”的闭环。这个闭环对写代码的人有用,对不写代码的人没用。

最后一句实话:如果你想试试,用环境变量配一个最快的 OpenAI 后端,几十秒就能跑起来。觉得值得,再用 /provider 保存配置,接其他模型。

这篇文章对你有帮助吗?

发表回复