最近被问爆的一个问题就是手上同时冒出OpenClaw、Hermes Agent、Claude Code、Codex CLI这四个名字的时候到底该怎么选。说实话我第一次把四个放在一起看也愣了半天——它们虽然都挂着 Agent 的名头但本质上是完全不同的物种。OpenClaw 更像一个生活自动化管家Hermes Agent 主打多功能本地助理Claude Code 和 Codex CLI 则是正儿八经的终端编程 Agent。这篇文章我不打算给你念说明书而是从定位、部署、实操踩坑到最终选型把四款工具一次讲透帮你少走弯路。1. 四个选手分别是什么来头1.1 OpenClaw捧着一大堆渠道接口的“生活管家”OpenClaw 是目前社区里热度很高的一款开源个人助手 Agent。它的招牌能力是“把模型能力和外部世界接起来”而且接得非常彻底飞书、钉钉、Telegram 这类 IM 渠道它能接浏览器操作它能做电脑上的文件它能读写甚至有人把它接到了智能家居和手机上。换句话说它的定位不是“帮你写代码的编程工具”而是“帮你在生活和工作里自动跑腿的管家”。为什么那么多人愿意折腾 OpenClaw我实测下来的感受是两个点最吸引人。第一开源可控数据可以完全掌握在自己手里不依赖某个厂商的封闭生态第二渠道丰富你可以在飞书里直接和一个 Agent 对话让它去执行任务这个体验比守着网页聊天窗口舒服太多了。不过它也有明显短板配置项多、文档分散不同版本的配置兼容性经常让人头疼。同样一份部署教程有人一键成功有人折腾一晚上差异往往就出在环境细节上后文我会把高频问题集中列出来。1.2 Hermes Agent把模型和工具揉在一起的“万能助理”Hermes Agent 是另一条技术路线的开源 Agent 框架。它更强调“多模型接入 多工具组装 知识库问答”这三件事的整合部署形态也更多样既有桌面客户端也能通过 Docker 跑在局域网服务器上让团队或者家庭成员一起用。我试用下来的感觉是Hermes Agent 的入门门槛比 OpenClaw 要低。它的安装包相对完整自带管理界面不用像 OpenClaw 那样手动接一堆渠道。你只要把模型 API 配好就能得到一个能聊天、能查知识库、能调用工具的统一入口。它很适合小团队或者家庭自托管一台小主机一份 Docker Compose 配置局域网里的人就能共享一个 AI 助理。当然它的能力上限也受限于你接的模型——模型不行框架再花哨也白搭。1.3 Claude Code只做编程的“终端副驾”Claude Code 是 Anthropic 推出的终端 AI 编码 Agent。和前面两个“大而全”的家伙不同Claude Code 非常克制它只关心一件事怎么把代码写好。它能在你的项目目录里读文件、改代码、跑命令、查 Git 状态甚至帮你整理提交信息。你可以在终端里直接和它对话也可以配合 VSCode 的客户端使用。在长上下文理解和复杂工程修改上Claude Code 的表现很突出。你扔给它一个几万行的仓库它能比较准确地定位问题文件并提出修改方案这种“深度工程理解”能力是通用助手 Agent 很难做到的。但要注意它不是免费玩具后端的模型能力需要你通过 Claude 的订阅或者 API 来付费成本控制是使用前必须想清楚的事。它和 OpenClaw、Hermes Agent 不是替代关系更像是不同工种。1.4 Codex CLIOpenAI 官方下场做的“编程 Agent”Codex CLI 是 OpenAI 官方开源的终端 Agent也是 ChatGPT 桌面端里那套 Agent 能力的命令行呈现。它的目标用户和 Claude Code 高度重合开发者。它由 Codex 系列模型驱动能在一个终端会话里完成看代码、改文件、跑测试、解释报错这一类任务。Codex CLI 的特殊之处在于它不仅是一个能对话的终端工具还可以作为后台能力被集成到其他应用里。社区里已经有不少人做了“Codex CLI 接入飞书机器人”的案例让 Agent 在飞书里接收任务、执行命令、回传结果。所以它的定位其实是双重的对普通开发者来说是好用的编程 Agent对喜欢折腾的人来说它是一个可以被二次开发、嵌入到产品里的自动化执行引擎。2. 核心差异拆解定位、部署、交互2.1 一句话定位和典型场景对比在动手安装之前先把四个工具的本质差异理顺。我给它们各打了一个标签放在一起看会更清楚工具一句话定位适合谁典型交互方式OpenClaw生活与工作自动化管家喜欢折腾的人、想把 AI 接进飞书/智能家居的人IM 对话、语音、定时任务Hermes Agent多功能本地助理家庭或小团队自托管用户网页 UI、桌面客户端Claude Code终端编程 Agent日常写代码的工程师命令行对话、VSCode 集成Codex CLI终端编程 AgentOpenAI 生态开发者、AI 产品集成者命令行调用、接口集成这里最容易被忽视的一点是前两者是“空间型”工具它们负责把你的工作流铺开到不同渠道、不同设备后两者是“深度型”工具它们负责在某个具体领域里把任务做到极致。拿编程场景举例你让 Claude Code 帮你查代码问题很顺手但让它去给你发一条飞书消息就很别扭反过来你让 OpenClaw 帮你管消息通知很顺手让它去理解一个大型代码仓库就力不从心了。2.2 部署方式和平台支持差在哪部署上的差异会直接影响你的第一体验这里单独拉出来说。OpenClaw 的部署方式最花样Windows、macOS、Linux 都有对应方案Docker 也能跑甚至有玩家用安卓 Termux 原生部署不装 proot 也能跑起来。但我建议新手优先选择官方提供的一键安装脚本或者 Docker 方案别一上来就挑战源码编译否则很容易被环境依赖劝退。Hermes Agent 的部署相对统一Windows 本地安装、macOS 安装、Linux 下用 Docker Compose 跑都比较成熟。因为它的设计是“一个服务多人使用”所以局域网部署是它最常见的形态。只要一台机器上把服务跑起来同网段的人就能通过浏览器访问。Claude Code 和 Codex CLI 的部署是最像的都依赖 Node.js 环境通过 npm 全局安装命令然后在项目目录里启动对话。Claude Code 现在也有桌面版/客户端形态Codex CLI 还能和 ChatGPT 桌面端联动。Windows 用户需要额外注意 Shell 兼容性和 PATH 路径问题后文踩坑部分我会给到具体排查方法。2.3 模型接入和权限控制的取舍模型接入策略是四款工具最大的路线分歧。OpenClaw 和 Hermes Agent 走的是“接入层”路线——它们本身不捆绑模型可以接 OpenAI 系、Anthropic 系、通义千问、本地开源模型等。自由度很大但模型质量直接决定了整体体验。你给 OpenClaw 换一个弱模型它执行任务的准确性会肉眼可见地下降给 Hermes Agent 换一个强模型它回答质量立刻上一档。所以用这两款工具本质上是在做“模型路由”的活模型选型比工具本身更影响最终效果。Claude Code 和 Codex CLI 则相反它们和自家模型深度绑定。Claude Code 只能用 Claude 模型Codex CLI 只能用 Codex/GPT 系列模型。好处是开箱即用、效果稳定坏处是你没得选。权限控制也是一个大问题。编程 Agent 需要读写文件、执行命令本质上是把一台电脑的控制权交出去。Claude Code 和 Codex CLI 都提供权限确认机制但使用时要克制我见过不少人图省事直接关掉所有确认结果 Agent 误操作把项目目录改了最后欲哭无泪。个人建议是在测试环境里可以放开权限生产环境和真实项目里务必保留确认步骤。3. 四个工具的实操记录与踩坑速查3.1 OpenClaw 实操一键部署、飞书截断、安卓原生部署先聊部署。OpenClaw 如果走官方脚本正常环境下几分钟就能起一个实例。真正让人头疼的是 Windows 用户经常遇到的报错OpenClaw could not safely verify the WSL2 environment。这个报错的意思是安装脚本检测到 WSL2 环境但无法安全确认它可用。我排查下来的主要原因一般是两个一是 Windows 版本太低WSL2 支持不完整二是 WSL 内核版本过旧。解决方法很简单在管理员 PowerShell 里执行wsl --update更新 WSL 内核然后关闭旧版 WSL 功能重新运行安装脚本基本就能过。再看飞书输出截断。很多人把 OpenClaw 接到飞书后发现 Agent 说话稍微长一点就被截断消息发不完整。原因是飞书自定义应用的消息接口对单条消息长度有限制Agent 一次性返回太长的内容就会失败。解决思路是在 OpenClaw 的渠道配置里打开输出分片或者调低单次输出上限。我实测下来把单条消息控制在 800 到 1500 个字符比较稳超过这个区间就切割成多条发送。如果你回复的内容经常超过几千字建议改成文件消息类型让 Agent 把长结果生成文件发出来体验会好很多。最后是安卓手机原生部署。在 Termux 里不装 proot直接跑 OpenClaw 确实是可行的关键点是依赖安装顺序。先执行pkg install git python nodejs ffmpeg把这几个基础依赖装上再克隆项目仓库进行构建。注意 Termux 里没有 systemd官方脚本里的服务管理命令大多不可用需要手动用前台命令启动或者配合termux-wake-lock防止手机息屏后进程被杀。在电量和后台策略上还要把 Termux 的“忽略电池优化”打开否则跑一段时间就被系统回收了。至于为什么用原生方式而不是 proot我用过之后觉得proot 的 IO 性能损耗太明显跑 Agent 这种需要频繁读写的任务很不划算。3.2 Hermes Agent 实操Windows 安装报错与局域网 Docker 部署Hermes Agent 的 Windows 本地安装我遇到最多的报错是“请求的名称有效但是找不到请求的类型数据”。第一次碰到这个我还以为是软件问题后来排查发现这是网络层面的老问题安装脚本尝试在线下载依赖包但网络环境不稳定或者 DNS 解析异常连接直接被拒了。解决思路不是反复重跑脚本而是先确认网络可以让脚本访问到下载源如果实在不行就手动下载安装包再离线安装。另外Windows 下安装前还要检查 PowerShell 执行策略如果被限制脚本会直接罢工。执行Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser就可以放开。Linux 下部署 Hermes Agent 我推荐直接用 Docker Compose比手动装依赖省太多事了。不少人在麒麟 V10 这类国产系统上部署时卡在镜像拉取慢的问题上。这种情况不用死等给 Docker 配置好镜像加速地址再docker compose up -d启动速度差别非常明显。启动后通过局域网 IP 访问管理界面但要注意系统防火墙默认可能不放行对应端口。我踩过这个坑服务明明起来了局域网其他机器就是访问不了最后发现是 firewalld 拦住了端口用firewall-cmd --add-port端口/tcp放行就解决了。还有一个小建议Docker Compose 里记得给容器加上restart: unless-stopped否则服务器一重启你的 Agent 服务也跟着没了还得手动去拉起来不值当。3.3 Claude Code 实操VSCode 配置、Skills 安装、权限管理Claude Code 的安装非常标准先确保机器上有 Node.js再执行npm install -g anthropic-ai/claude-code装好后在项目目录里运行claude就能进入交互界面。第一次启动会让你登录或者配置 API Key按提示操作就行。VSCode 集成是我很喜欢的一个点。你可以在编辑器里直接打开 Claude Code 的侧边栏选中一段代码让它解释逻辑或者报告 Bug它会把文件上下文带进来回答比纯聊天窗口准确很多。这个配置过程也不复杂装好官方扩展后默认就能识别项目里的对话会话很多新手第一次用会感叹“原来代码还能这么查”。Skills 是 Claude Code 的扩展机制相当于给 Agent 装额外的“能力包”。每个 Skill 放在指定目录下通过一个SKILL.md文件描述它怎么被调用。我自己写过一个“提交信息规范”的 Skill让 Claude Code 在每次提交前自动按团队的提交规范生成 Commit 消息。装上之后它就能在对话里通过/skill名称被直接触发非常实用。新手不用把这个想得太复杂本质上就是把一些重复性的要求沉淀成一个可复用的指令文件。权限管理一定要单独说。Claude Code 提供了一个--dangerously-skip-permissions参数加上之后所有操作都不再询问执行效率极高。但我强烈建议只在隔离环境或者临时测试容器里用它。在真实项目里你至少要知道它要改哪些文件、跑哪些命令否则 Agent 一旦理解错你的意图就可能干出超出预期的事。3.4 Codex CLI 实操找不到二进制的经典报错与飞书接入Codex CLI 安装同样是 npm 路线npm install -g openai/codex。但有一个高频问题几乎每天都有新人问ChatGPT 桌面端启动时报错“ChatGPT failed to start. unable to locate the codex cli binary or required runtime components. Check...”。这个报错翻译过来就是ChatGPT 桌面端要调用 Codex CLI但找不到它的二进制文件。排查顺序其实很固定。先确认 Codex CLI 装没装npm install -g openai/codex再跑一遍然后确认命令可用codex --version接着确认路径Windows 下用where codexLinux/macOS 下用which codex确保 npm 全局目录在 PATH 里。还有一个很隐蔽的情况终端里明明能看到codex --version的输出版本但 ChatGPT 桌面端还是报错这通常是 PATH 缓存没刷新重启终端或者重新登录 Windows 就能解决。不要一上来就重装系统先按这个顺序排查八成能救回来。Codex CLI 接入飞书这事社区里已经玩出花了。本质思路不算复杂飞书应用收到消息后调用一个脚本脚本里通过命令行把任务喂给 Codex CLI等它执行完再拿输出回传飞书。实现的时候要注意两点第一Agent 跑任务非常慢给回调接口设超时时间时要留足余量第二把工作目录限制在安全范围别让飞书上的任意消息都能触发 Codex 在服务器上乱跑。顺带解释一个很多人搜过的问题harness 和 agent 的区别。harness 更像 Agent 外面的“运行骨架”负责上下文管理、工具调用、错误恢复Agent 本身是思考和决策的大脑。Codex CLI 这类产品把两者打包在一起所以你使用时只感知到一个完整工具。4. 从选型到落地我的一些建议4.1 按使用场景选型速查很多人在四款工具之间反复横跳就是因为没先定义自己的场景。我先给一个速查表你对着自己的核心需求找答案就可以使用场景首选方案备选方案理由在飞书/钉钉里和一个 AI 聊天并让它自动执行任务OpenClawHermes Agent渠道接入生态最成熟小团队/家庭知识库问答、统一 AI 入口Hermes AgentOpenClaw自带管理界面部署简单日常写代码、做跨文件项目修改Claude CodeCodex CLI代码理解深度领先深度绑定 OpenAI 生态、需要二次集成Codex CLIClaude Code官方支持接口友好想在安卓手机上随身跑一个 AgentOpenClaw无Termux 原生方案成熟这里我想特别点一下选型不是看谁的发布会漂亮而是看准自己的高频场景。如果你是程序员Claude Code 和 Codex CLI 应该作为日常主力OpenClaw 可以当作辅助自动化工具如果你不是程序员只是想让 AI 帮你管消息、查资料、自动跑一些流程那 OpenClaw 和 Hermes Agent 的优先级要远高于两个编程 Agent。4.2 我自己的组合方案与优先级我目前自己用的组合是主力编程用 Claude Code自动化任务用 OpenClawHermes Agent 按需部署Codex CLI 留着做 OpenAI 生态的兼容性备份。这个组合不是说四款都要装而是“只让每个工具干它最擅长的事”。比如我用 Claude Code 改项目代码因为它对工程上下文的理解确实好改完代码后如果用 OpenClaw 接的飞书机器人给团队发一条更新通知就不用自己手动切窗口了。Codex CLI 偶尔用来跑一些需要 OpenAI 模型背书的实验性任务尤其是想横向对比 Claude 和 Codex 模型输出差异的时候。Hermes Agent 我在家里那台小服务器上部署了一份主要给家里人用一个浏览器入口就能用 AI 对话和知识库比教他们装各种客户端省心太多。如果你不想维护这么多工具我的建议是优先只选一个跑通一条链路别一上来就全家桶。每多一个 Agent你就多一份模型费用、多一个配置要维护、多一个半夜报错的风险。把一条链路跑稳定比装三个吃灰的工具强得多。4.3 几个容易忽略的坑最后再集中写几个我实际踩过、而且不太容易被搜到的坑。长文本输出被截断这个问题不止飞书有。钉钉、Telegram 这类 IM 渠道都有单条消息长度限制建议在 Agent 端统一配置输出分片而不是在某个渠道单独调整。另一个容易忽略的是模型的 token 消耗。Agent 跑一个稍复杂的任务消耗的 token 数量往往是聊天问答的几十倍生产环境一定要配好限额否则账单会让你怀疑人生。权限和隔离也值得反复强调。不管用哪个 Agent尽量先给它一个临时目录或者测试环境不要一上来就让它直接操作生产环境。我见过有人让 Codex CLI 在服务器上跑自动化脚本结果它把旧的配置文件覆盖了恢复花了一下午。Agent 再聪明也只是执行者最终的监督责任在你自己身上。另外很多人搜 Agent 相关话题时会看到 agent evals、pi agent、openclaw 一键部署这类词。我的看法是评测基准看看就好它只能说明模型在标准题集上的能力不代表它在你的真实环境里就好用新项目层出不穷不用焦虑工具没有最好的只有最适合当前场景的。最后说点实在的。我自己也曾经陷入“工具收集癖”把这几款装了个遍结果真正每天在用的还是那么一两个。Agent 选型的本质是先想清楚“我要它替我干什么事”再决定模型、渠道和权限怎么配。OpenClaw 适合做生活自动化Hermes Agent 适合做组织内的知识助理Claude Code 和 Codex CLI 更像是两个强大互补的编程搭子。先挑一个跑通一条链路再加装下一个体验会舒服很多。