市面上叫得上名字的 AI 编程工具，这两年我基本都折腾过一轮。从最早拿 Claude Code 当高级补全用，到后来把 Codex CLI 接进终端工作流，再到最近把 OpenClaw 和 Hermes Agent 分别部署到本地和局域网里跑，踩的坑足够写一本小册子。这篇不打算做那种"十大 AI 编程工具排行榜"式的罗列，而是想把这四个东西——OpenClaw、Hermes Agent、Claude Code、Codex CLI——放在同一张桌子上，从它们各自解决什么问题、适合什么场景、部署时哪些环节最容易翻车这几个角度，掰开揉碎讲清楚。如果你正在纠结"我到底该用哪个"，或者已经在某个工具上卡在安装环节出不来，这篇应该能帮你省下几个晚上的时间。
1. 先把四个工具的定位摆正，别拿锤子找螺丝
很多人一上来就问"哪个最好用"，这个问题本身就问错了。这四个工具虽然都挂着"AI 编程"的标签，但它们的设计出发点完全不同，混着比只会越比越乱。我习惯先把它们分成两类：终端里的编程助手和可自托管的 Agent 平台。
1.1 Claude Code 和 Codex CLI：终端原生的编程搭子
Claude Code 和 Codex CLI 属于同一类——它们是跑在你终端里的命令行工具，核心能力是理解你的代码库、执行文件操作、跑命令、改代码。区别在于背后的模型和交互风格。
Claude Code 是 Anthropic 出的，走的是"深度理解代码上下文"的路线。它的强项在于对大型代码库的把握，你让它改一个函数，它会先去看这个函数被谁调用、依赖哪些模块，改完之后还会顺手检查有没有破坏别的地方。我拿它重构过一个两千多行的老项目，它自己梳理出了模块间的依赖关系，这点确实省心。
Codex CLI 则是 OpenAI 阵营的终端工具，风格更偏向"快速执行"。它的命令补全和脚本生成很利索，适合那种"我知道要干什么，你帮我快速写出来"的场景。不过它的环境依赖问题比较烦人，后面会专门讲那个经典的报错。
这两个工具的共同点是：它们不提供独立的图形界面，你得习惯在终端里跟它们对话。对常年泡在命令行里的人来说这是优点，对习惯 IDE 的人可能需要适应。
1.2 OpenClaw 和 Hermes Agent：能自己搭起来的 Agent 平台
OpenClaw 和 Hermes Agent 是另一条路线。它们不是单纯的编程助手，而是可部署、可对接、可扩展的 Agent 框架。你可以把它们理解成一个"AI 助手的底座"，装好之后可以对接不同的模型、接入不同的聊天平台（比如飞书）、配置不同的技能。
OpenClaw 的特点是部署方式灵活，支持本地一键部署，也能在安卓的 Termux 里原生跑起来，甚至有人在麒麟 V10 这种国产系统上部署局域网版本。它的卖点在于"把 AI 助手变成你自己的服务"，而不是租用别人的。
Hermes Agent 走的是类似的路子，有桌面版，也支持 Windows 本地安装和 Docker 部署。它的中文资料相对多一些，官网和中文官网都能找到，对国内用户友好一点。
这两个工具的核心价值不在于"帮你写代码有多强"，而在于你能完全掌控这个 Agent 的运行环境、数据流向和对接方式。对于有数据合规要求、或者想把 AI 助手深度嵌进自己工作流的团队，这类自托管方案才是正解。
1.3 一张表看清四者的差异
| 维度 | Claude Code | Codex CLI | OpenClaw | Hermes Agent |
|---|---|---|---|---|
| 形态 | 终端命令行工具 | 终端命令行工具 | 可自托管 Agent 平台 | 可自托管 Agent 平台 |
| 核心场景 | 大型代码库理解与重构 | 快速脚本生成与命令执行 | 私有化 AI 助手服务 | 私有化 AI 助手服务 |
| 部署难度 | 低（装完即用） | 中（环境依赖易出问题） | 中高（需配置运行环境） | 中高（需配置运行环境） |
| 数据可控性 | 依赖官方服务 | 依赖官方服务 | 完全自控 | 完全自控 |
| 适合人群 | 终端重度用户、重构需求多 | 脚本党、快速原型 | 有私有化需求的团队 | 有私有化需求的团队 |
把这张表看明白，你基本就不会再问"哪个最好"了。正确的问法是："我现在这个场景，该用哪一类？"
2. 部署环节才是真正的分水岭，装不上一切白搭
工具选型只是第一步，真正让人抓狂的是部署。我见过太多人兴致勃勃地选了个工具，结果卡在安装环节三天没进展，最后放弃。这一章把四个工具部署时最容易出问题的地方挨个说清楚。
2.1 Codex CLI 那个经典的 "unable to locate the codex cli binary"
这个报错我至少遇到过五次，每次都是不同的人来问。完整报错是chatgpt failed to start. unable to locate the codex cli binary or required runtime components，或者unable to locate the codex cli binary or required runtime components. check。
最迷惑的地方在于：你在命令行里敲codex --version明明能看到版本号，说明二进制是装上了，但一用 Windows Terminal 或者某个集成环境就报找不到。这个问题的根因是环境变量 PATH 的作用域不一致。
具体来说，你在 CMD 或 PowerShell 里装 Codex CLI 时，安装程序把路径写进了当前用户的环境变量。但 Windows Terminal 或者某些 IDE 启动时继承的是另一套环境变量快照，尤其是你装完之后没有重启终端，它读的还是旧的环境变量。解决办法很直接：
- 确认二进制实际位置，通常在
%USERPROFILE%\.codex\bin或 npm 全局目录下 - 把这个目录手动加进系统级 PATH，而不是用户级
- 完全关闭所有终端窗口再重新打开，不是新开标签页，是彻底退出进程
- 如果还不行，在报错的那个终端里直接
echo $env:PATH看看路径到底有没有
提示：Windows 上环境变量分"用户变量"和"系统变量"，很多安装程序只写用户变量，而某些启动方式读的是系统变量。两边都加上最保险。
还有一个隐蔽的坑：如果你同时装了多个版本的 Codex CLI（比如 npm 装了一个、独立安装包装了一个），PATH 里靠前的那个可能是坏的。用where codex命令列出所有匹配项，把多余的清掉。
2.2 OpenClaw 的 WSL2 环境校验失败
OpenClaw 在 Windows 上部署时，有个高频报错是openclaw could not safely verify the wsl2 environment。这个报错的意思是 OpenClaw 想确认你的 WSL2 环境是干净可用的，但校验没通过。
WSL2 校验失败通常有三个原因：一是 WSL2 根本没装或者装的是 WSL1；二是 WSL2 装了但默认发行版没设置；三是 WSL2 里的某些组件版本太旧。
排查顺序建议这样走：
- 先在 PowerShell 里跑
wsl --list --verbose，看 VERSION 那一列是不是 2。如果是 1，用wsl --set-version <发行版名> 2升级 - 确认默认发行版：
wsl --set-default <发行版名> - 进 WSL2 里更新组件：
sudo apt update && sudo apt upgrade - 如果 OpenClaw 还是报校验失败，检查一下 WSL2 的 systemd 是否启用，有些版本需要手动在
/etc/wsl.conf里加[boot] systemd=true
Mac 下安装 OpenClaw 相对省心，基本是下载安装包、拖进应用目录、首次运行授权这几步。但要注意 Mac 的 Gatekeeper 可能会拦截未签名的应用，需要在"系统设置-隐私与安全性"里手动放行。
2.3 在安卓 Termux 里原生部署 OpenClaw
这个玩法比较硬核，但确实有人这么干——不借助 proot，直接在 Termux 原生环境里跑 OpenClaw。好处是性能损耗小，坏处是依赖得自己一个个装。
核心步骤是：先pkg update && pkg upgrade，然后装 Node.js 环境（pkg install nodejs），再装 OpenClaw 的依赖。这里最容易卡住的是某些 npm 包需要编译原生模块，而 Termux 默认没有完整的编译工具链。解决办法是提前装好pkg install build-essential python，让编译能跑通。
另一个坑是 Termux 的存储权限。OpenClaw 要读写文件，你得先跑termux-setup-storage授权，否则会一直报权限错误。这个命令会弹系统授权框，同意之后 Termux 才能访问共享存储。
2.4 Hermes Agent 在麒麟 V10 上的局域网部署
国产系统上部署 Hermes Agent 是个真实需求，我帮人弄过一次麒麟 V10 的局域网版本。整体思路是 Docker 部署，但麒麟 V10 的 Docker 源速度感人，得先配加速。
流程大致是：装 Docker 和 Docker Compose，配置镜像加速地址，拉取 Hermes Agent 镜像，写 docker-compose.yml 定义服务，然后docker compose up -d启动。局域网访问的话，注意防火墙要放行对应端口，麒麟 V10 默认的防火墙策略比较严。
Hermes Agent 的 Windows 本地安装和桌面版安装相对简单，官网有安装包，双击走流程就行。但要注意安装路径别带中文和空格，这类工具对路径里的特殊字符处理普遍不好。
3. 真正用起来之后，这些细节决定体验上限
装好了只是开始，用起来之后你会发现一堆文档里不会写的东西。这一章讲的是实战中积累的经验，都是踩过坑才明白的。
3.1 Claude Code 的上下文管理是门手艺
Claude Code 强在理解代码库，但这个"理解"是有代价的——它会读取大量文件来建立上下文。如果你在一个巨型项目里直接开问，它可能会读进去几百个文件，响应变慢不说，还容易抓不住重点。
我的做法是先给它划定范围。比如你要改用户模块，就先告诉它"只看 src/user 目录下的文件"，或者用它的文件引用语法精确指定。这样既快又准。
另一个技巧是善用 git worktree。Claude Code 配合 git worktree 用起来很舒服——你可以在一个独立的工作树里让它随便改，改坏了直接删掉工作树，主分支不受影响。这个组合我强烈推荐给所有用 Claude Code 做重构的人。
Claude Code 的 Skills 机制也值得研究。你可以把常用的操作封装成 Skill，比如"按项目规范生成 commit message"、"自动补全单元测试"，装好之后一句话就能调用。Skills 的安装一般是从社区仓库拉取，注意看清楚它要什么权限。
3.2 Codex CLI 接入飞书的那些坑
有人想把 Codex CLI 接进飞书当机器人用，这个思路可行但坑不少。最典型的问题是输出被截断——飞书的消息长度有限制，Codex CLI 生成的代码或者长回复经常超限，直接被砍掉后半截。
解决办法是在中间加一层处理：把 Codex CLI 的输出先落到文件或者数据库，然后分段推送到飞书，或者只推送摘要加一个查看完整内容的链接。别指望直接把长输出塞进飞书消息里。
另外 Codex CLI 接入飞书需要处理鉴权和事件订阅，这部分和普通的飞书机器人开发没区别，但要注意 Codex CLI 的执行是异步的，得设计好回调机制，不然用户发了指令半天没反应。
3.3 OpenClaw 对接魔塔与输出截断问题
OpenClaw 可以对接魔塔（ModelScope）上的模型，这对想用国产模型的用户很友好。对接方式一般是在配置里填 API 地址和密钥，然后指定模型名称。要注意的是不同模型的接口格式可能有差异，OpenClaw 的适配层不一定全覆盖，遇到不兼容的得自己写适配。
OpenClaw 在飞书输出容易被截断这个问题和 Codex CLI 类似，根因都是消息长度限制。OpenClaw 的配置里通常有分片发送的选项，打开它，或者调整单条消息的最大长度。如果它没有内置分片，就得在对接层自己处理。
3.4 Hermes Agent 安装时的"请求的名称有效"报错
Hermes Agent 安装过程中有个报错叫"请求的名称有效，但未找到该主机数据"，这本质是 DNS 解析问题。通常是安装脚本要访问某个域名拉取资源，但你的网络环境解析不了。
排查思路：先ping一下脚本里涉及的域名，看能不能通；不通的话检查 DNS 设置，换成公共 DNS 试试；如果是公司内网，可能有代理或者防火墙拦截，得找网管放行。这个报错和工具本身没关系，纯粹是网络环境问题。
4. 按场景选工具，而不是按名气选
聊完部署和使用细节，回到最开始的问题：到底怎么选。我给几个典型场景的推荐，你对号入座。
4.1 场景一：个人开发者，主要写业务代码
如果你是一个人写项目，日常就是改改业务逻辑、写写接口、调调 bug，Claude Code 是首选。它对代码库的理解能力能帮你省下大量"这个函数在哪被调用"的排查时间。配合 git worktree 用，重构起来毫无心理负担。
Codex CLI 可以作为补充，尤其是你需要快速生成一些脚本、处理一些命令行任务的时候，它更利索。
4.2 场景二：团队有私有化需求
如果你们团队对数据流向有要求，不能把代码发给第三方服务，那OpenClaw 或 Hermes Agent 是唯一选择。这两个都能自托管，模型可以接本地的或者国产的，数据不出内网。
选哪个看你的技术栈：OpenClaw 的部署方式更灵活，Termux、Mac、Windows、国产系统都有案例；Hermes Agent 的中文资料更全，桌面版对新手友好。团队里有运维的话，两个都能搞定；没有运维的话，Hermes Agent 的桌面版可能更省心。
4.3 场景三：想学 AI 编程，不知道从哪入手
如果你是想入门 AI 编程，我的建议是先从 Claude Code 或 Codex CLI 用起，因为它们装完就能用，反馈快，能让你快速建立"和 AI 协作写代码"的感觉。等你摸清了 AI 编程的脾气，再考虑要不要上自托管的 Agent 平台。
网上那些"AI 编程培训应该包括哪些知识"的课程，核心其实就三块：怎么描述需求（提示词）、怎么验证 AI 的输出、怎么把 AI 嵌进现有工作流。工具只是载体，这三样才是真本事。
4.4 场景四：想在移动端或特殊环境用
想在安卓手机上用 AI 编程助手，Termux 里原生部署 OpenClaw 是可行方案，但体验肯定不如桌面。适合应急或者折腾着玩。真要在移动端干活，还是建议远程连回自己的开发机。
5. 那些没人告诉你但很重要的经验
最后这部分是我个人踩坑攒下来的零碎经验，不成体系但都实用。
关于卸载：OpenClaw 卸载不干净会残留配置和缓存，下次重装可能出怪问题。卸载前先找到它的配置目录（通常在用户主目录下的隐藏文件夹），手动删干净。Windows 上还要检查环境变量里有没有残留的路径。
关于版本：这类工具迭代快，版本之间行为差异可能很大。遇到诡异问题先确认版本，然后去翻对应版本的更新日志，很多"bug"其实是行为变更。
关于提示词：AI 编程提示词的核心不是写得花哨，而是把约束条件说清楚。告诉它用什么语言、什么框架、什么代码风格、不要动哪些文件，比写一堆"你是一个资深工程师"之类的角色设定有用得多。
关于验证：永远不要直接信任 AI 生成的代码，尤其是涉及数据库操作、权限校验、金额计算的部分。让它写完，你自己过一遍，跑一遍测试。AI 编程提效的前提是你有能力判断它写得对不对。
关于网络：自托管 Agent 对接外部模型时，网络稳定性直接影响体验。局域网部署的话，把模型服务放在同一网段，延迟能低不少。
关于备份：在让 AI 大改代码之前，先 commit 或者打个 tag。这个习惯能救你无数次。git worktree 之所以好用，就是因为它天然隔离，改坏了不影响主分支。
折腾这四个工具的过程，本质上是在回答一个问题：你希望 AI 在你的开发工作流里扮演什么角色。是随叫随到的补全工具，还是能独立干活的 Agent，还是完全受你控制的私有服务。想清楚这个，工具选择就是水到渠成的事。我现在的配置是 Claude Code 主力写代码，Codex CLI 处理脚本杂活，OpenClaw 挂在局域网里当团队的私有助手，各司其职，谁也不耽误谁。
