不知道你们发现没有，最近身边聊 AI Agent 的人突然变多了。尤其是在 AI 编程这个方向上，从 OpenClaw、Hermes Agent 这种偏“个人助手”的框架，到 Claude Code、Codex CLI 这种直接扎进终端的编程 Agent，几乎每周都有新版本、新玩法冒出来。但这四个名字放在一起，很多人容易搞混：到底谁是用来写代码的，谁是用来跑任务的？哪个更适合部署在飞书上，哪个更适合在 VSCode 里当副驾？
这篇对比指南就是来解决这个问题的。我会从定位、部署方式、典型使用场景、踩坑记录这几个维度，把这四个工具挨个拆开聊清楚。无论你是刚入门的 AI 编程新手，还是已经在折腾 Termux 部署、局域网 Agent 的老玩家，这篇文章都能帮你少走不少弯路。
1. 四个工具的本质区别：先搞清楚谁在哪个赛道
1.1 OpenClaw：全能型个人助理 Agent
OpenClaw 在热搜词里频繁和“飞书”“Termux”“WSL2”“魔塔”这些词绑定出现，其实已经说明了它的定位：它不是一个单纯的编程工具，而是一个能连接 IM 平台、能在各种环境下跑任务的多智能体框架。你在飞书里给它发一条消息，它能用内置的 Skill 或子 Agent 帮你查资料、写文档、调接口，甚至把你每天早上的日报流程自动化跑完。
我在实际部署中最大的体会是，OpenClaw 的亮点不是单点能力，而是“连接能力”。它把很多原本需要人肉串联的环节做成了可配置的任务流。比如我曾在飞书群里搭过一个简单的舆情监控 bot：OpenClaw 定时抓取几个指定源的更新，做摘要后推送到群聊。整个过程不需要自己写复杂的状态机，只需要把抓取、摘要、推送三个步骤配置好就行。
但它的缺点也同样明显：多平台部署意味着每个平台都有自己的环境问题。热搜里那句“openclaw could not safely verify the wsl2 environment”不是段子，是真实会遇到的报错。WSL2 下安装时如果 Docker 的 Windows 集成没开，或者/etc/wsl.conf里的 systemd 设置不对，OpenClaw 的安全校验大概率会失败。后文我会单独讲这个坑。
1.2 Hermes Agent：偏桌面与局域网部署的 Agent 框架
Hermes Agent 和 OpenClaw 有点像是“同一个物种下的不同亚种”。从合集里“Hermes Agent 桌面版”“Hermes Agent Windows 本地安装”“麒麟 V10 部署局域网 Hermes Agent”这些词条来看，它更偏向于“单机或局域网内的可靠部署”。
我自己对 Hermes Agent 的理解是，它更像一个可以被你“安装在桌面上的助手”。配置好之后，它可以通过桌面端或网页端交互，适合个人知识库整理、日程管理、本地文档处理这类偏私域的任务。它的核心价值在于：数据不出局域网，运行环境相对可控，适合对数据敏感或者网络环境不稳定的场景。
不过“局域网部署”这四个字背后往往隐藏着一堆问题。尤其在国内的信创环境里，很多人用的是麒麟 V10，想在上面跑 Hermes Agent，第一道坎就是 Docker 加速器配置。默认源拉镜像慢到怀疑人生，后来我换成可用的加速镜像之后，整个部署时间从原本可能一小时以上缩短到十几分钟。这部分我会在第 2 章详细展开。
1.3 Claude Code：Anthropic 的终端编程主力
Claude Code 是 Anthropic 官方出品的编程 Agent，它的定位非常清晰：就是在终端里帮你写代码、改代码、跑测试、提交 PR。它和前面两个工具不一样，OpenClaw 和 Hermes Agent 更像是“家庭总管”，而 Claude Code 是“专职程序员”。
它的用法也很直接：在项目目录下运行claude，它会读取你的项目结构、Git 历史、代码规范，然后你只需要用自然语言描述需求，它会自己读文件、改文件、执行命令。我比较常用的一个场景是接手一个没文档的老项目，让 Claude Code 先帮我梳理代码结构和核心逻辑，再让它定位某个 bug 的大致位置，效率比人肉翻代码高非常多。
热词里提到“Claude Code Skills 安装”，这个是它的一个扩展机制。你可以在项目里配置.claude/skills，把团队内部的一些规范、脚本模板、常用命令封装成 Skills，这样每次对话时它都能按你的约定工作。这点对于团队协作来说很实用，等于把团队的最佳实践固化到了 Agent 的工作流里。
另外，“VSCode 配置 Claude Code”也是很多人关心的问题。虽然 Claude Code 本身是终端工具，但你在 VSCode 的集成终端里跑它，再配合 Cline 之类的插件做可视化 diff，体验会顺滑很多。我建议不要把 Claude Code 当成一个孤立工具，而是嵌进你已有的 IDE 工作流里。
1.4 Codex CLI：OpenAI 的本地编程 Agent
Codex CLI 是 OpenAI 在 Claude Code 之后推出的对标产品，同样是命令行工具，同样主打“AI 能直接在本地代码仓库里干活”。它的特点是背后模型默认基于 GPT 系列，和 OpenAI 生态的 API 衔接比较顺。
热词里有一条很有意思——“codex cli接入飞书”。很多人会觉得奇怪，一个编程 CLI 怎么跟飞书扯上关系？实际上，当 Codex CLI 跑在服务器或长期在线的终端里时，完全可以把它封装成一个飞书机器人：在飞书里发一条消息，后台调用 Codex CLI 执行，再把结果回传。这个玩法在中小团队里其实挺常见，等于给飞书群里塞了一个“能改代码的机器人”。
但我必须提醒，Codex CLI 在 Windows 上的体验并不算好。热词里那句“在 windows 命令行安装了 codex cli codex --version也能查看版本，但是用 window termi...”是很多人真实遇到过的：在 PowerShell 里安装没问题，一换到 Windows Terminal 或 Git Bash 就找不到 codex 命令。这通常是环境变量 PATH 没有刷新，或者安装器只写入了当前 shell 的 profile。解决办法我后面会讲。
2. 部署踩坑实录：那些搜索量飙升的问题都是真的
2.1 WSL2 环境校验失败与 Terminal 找不到命令
“openclaw could not safely verify the wsl2 environment”这条热搜背后，反映的是 WSL2 部署 Agent 时最典型的信任链问题。OpenClaw 在安装阶段会检查 WSL2 环境是否满足安全要求，比如内核版本、systemd 是否启用、/etc/resolv.conf是否正常。如果你用的是从 Microsoft Store 装的旧版 WSL，或者手动编译过内核，校验很容易挂。
我当时排查的步骤是这样的：
- 先跑
wsl --version确认 WSL 版本，低于 1.0 建议直接升级。 - 检查
/etc/wsl.conf里有没有[boot] systemd=true，没有就加上，然后wsl --shutdown重启。 - 看内核版本，如果太低就
sudo apt update && sudo apt upgrade。 - 最后检查 Docker Desktop 是否打开了 WSL2 集成。
常见的一键安装命令如下（适用于 Docker 版 OpenClaw）：
# 在 WSL2 内执行 sudo apt update && sudo apt upgrade -y wget -O install.sh https://raw.githubusercontent.com/openclaw/install/main/install.sh chmod +x install.sh sudo bash install.sh另外一条高频问题“windows 命令行安装了 codex cli codex --version也能查看版本，但是用 window termi...”的根源通常只有一个：安装器写入了当前用户的 PATH，但 Windows Terminal 打开时缓存了旧的 PATH。解决办法是安装完成后，彻底重启 Windows Terminal，或者在系统环境变量里手动追加%USERPROFILE%\.codex\bin。如果还不行，直接重启电脑最省事。
2.2 在安卓 Termux 原生部署 OpenClaw：无 proot 也能跑
“在安卓 termux 原生部署openclaw:无proot轻”这个词条，我觉得是懂行的人才会搜的。Termux 上跑 Agent 的常规方案是装 proot，隔离出一个 Linux 环境，但性能损耗大、目录结构别扭。而 OpenClaw 的设计让它比较适合在 Termux 里原生跑，少一层虚拟化，资源占用低很多。
无 proot 部署的核心是两点：一是确认 Termux 的 sysroot 与 OpenClaw 的二进制兼容；二是依赖克隆。因为 Termux 的包管理器和标准 Linux 发行版不太一样，很多 Agent 依赖的build-essential、python-dev之类的东西在 Termux 里要换名字装。
实操上我建议这样：
pkg update && pkg upgrade -y pkg install python python-pip nodejs git clang make libffi -y # 拉取 OpenClaw 源码 git clone https://github.com/openclaw/openclaw.git cd openclaw pip install -r requirements.txt跑起来之后，手机就变成了一个随身携带的个人 Agent 节点。我在一台备用 Android 机上跑过一周，主要用于在飞书上接收消息并执行轻量任务，发热和耗电都能接受。但要注意 Termux 在后台容易被系统杀掉，需要在电池优化里把 Termux 设为白名单，否则 Agent 会莫名其妙失联。
2.3 麒麟 V10 上部署 Hermes Agent：Docker 加速是关键
如果你在信创环境里，那“麒麟 V10 部署局域网 Hermes Agent:docker加速+完整运行实操”这条热词应该会救你一命。麒麟 V10 默认的 Docker 源在国内拉取镜像时非常不稳定，而 Hermes Agent 的镜像体积又比较大。不配加速，经常拉到一半断掉，然后就得从头再来。
我的建议是，装好 Docker 之后立刻配置加速器。修改/etc/docker/daemon.json加上国内可用的镜像加速地址，然后重启 Docker：
sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://docker.1ms.run"] } EOF sudo systemctl daemon-reload sudo systemctl restart docker配置完加速之后，再拉 Hermes Agent 镜像，速度会稳定很多。但这里要特别注意：加速器只是加速镜像拉取，不会加速 Agent 本身的输出性能。局域网部署时要关注服务器的 CPU 内存占用，我有一次在 2 核 4G 的 ARM 机器上跑 Hermes Agent，开几个对话后内存直接占满，不得不给 Node 进程做内存限制。之后我还把数据库切到了 SQLite 而不是默认的 PostgreSQL，才勉强稳住。如果条件允许，建议至少 4 核 8G。
2.4 飞书输出截断：不是玄学，是消息长度和类型问题
“openclaw在飞书输出容易被截断”这个问题，凡是拿 Agent 跑飞书机器人的应该都撞过。飞书自建应用的“机器人发送消息”接口，对文本消息长度有限制，普通文本超过一定字符数会被直接截断，而且不会报错。你往往看到的是 Agent 正常跑完了，但在飞书里只收到前半段内容，后半段凭空消失，也不知道去哪了。
解决思路通常是这几种：
- 分片发送：把长文本按段落或指定长度切分，循环多次调接口发送。
- 改用卡片消息：如果 Agent 输出的是格式化内容，用飞书的交互式卡片接口，容量比纯文本大得多。
- 上传为文件：超过限制的内容，先写入本地临时文件，再调用飞书上传文件接口发给用户。
从工程上说，最稳的是第三种：Agent 生成完内容后，自动生成一个 Markdown 或 TXT 文件，通过 webhook 发出去。这样即便内容很长也能完整保留，用户体验反而更好。飞书截断问题并不是故意恶心人，而是平台为了保证 IM 消息的可读性设定的限制。理解了这一点，你会愿意在 Agent 配置层多做一层“输出适配”，而不是把这个锅甩给 Agent 框架。
3. 使用姿势对比：同一个 Agent，不同玩法
3.1 Claude Code：当编程 Agent 用，关键在 Skills 和上下文
Claude Code 最值得研究的是它的 Skills 机制。很多新手只把它当一个“高级聊天框”用，让它写代码，然后手动复制粘贴回文件。这其实完全理解偏了。Claude Code 厉害之处在于它默认就有读文件、改文件、执行命令的权限，你完全可以直接说“帮我把src/utils.ts里那个formatDate函数重构一下，然后跑一遍相关测试”，它会自己完成修改和验证。
而 Skills 等于给 Claude Code 装上了“领域工作流模板”。比如在我自己维护的项目里，我会写一个code-reviewSkill，让它每次改完代码后自动检查类型定义、Lint 规则、边界条件；再写一个commitSkill，让它根据 Git diff 生成符合团队规范的提交信息。配置路径很简单：
.claude/skills/code-review/SKILL.md文件内容就是 Markdown 格式的指令模板。Claude Code 在启动时会自动扫描这些文件，并把对应的指令注入到上下文中。
用 Claude Code 配合 VSCode，我推荐把终端面板打开到侧边，和代码编辑器并排。这样你既能通过图形界面看文件改动，又能在终端里和 Agent 交互。如果你用的是 Cline 或者 Continue 这类插件，也建议把 Claude Code 作为底层执行器接入，享受插件 UI 和 Claude Code 的执行能力。
3.2 Codex CLI：当云端任务执行器，接飞书最“香”
Codex CLI 和 Claude Code 的功能高度重叠，但它在国内被玩得比较野。因为 OpenAI 的 Codex 本身是一个云端 Agent 平台，而 Codex CLI 相当于本地终端和云的桥梁，所以很多人用它来跑定时任务，甚至当“无人编程工人”用。
接入飞书的思路其实很直接：写一个简单的 Node.js 服务，接收飞书 webhook 推送的消息，解析出用户指令，然后调用codex exec执行，执行完把 stdout 回传到飞书。这样你在手机上发一句“帮我看看测试服接口为什么抖”，飞书机器人收到后触发 Codex CLI 去查日志、分析代码，再把结论发回来。
需要注意的一点是，Codex CLI 在 Windows 上虽然能装，但如果你让它跑一些涉及 Docker 或 shell 脚本的任务，建议还是部署在 WSL2 或者 Linux 服务器上。Windows 的原生 shell 环境和一些命令工具不兼容，会导致 Agent 干活的时候莫名其妙失败。
3.3 OpenClaw：当个人助理用，飞书、魔塔、移动端都能折腾
OpenClaw 的使用场景真不是“编程”两个字能框住的。它在飞书生态里能做的事情非常多：可以把它接进群聊做智能问答，也可以给它配置定时任务做自动化巡检，还可以通过多轮对话让子 Agent 协作完成复杂报告。我还见过有人把它和魔塔社区（一个 AI 应用平台）对接，在魔塔上跑模型推理，然后把结果送回飞书，等于给飞书加了一层更复杂的 AI 能力。
如果你在安卓 Termux 上部署了 OpenClaw，它的灵活度还会再上一个台阶。手机端的优势在于“时刻在线”，只要不断电不断网，它就是一个随身携带的任务节点。我个人的做法是：在手机上用 OpenClaw 监听一个飞书群，群里发“提醒我两小时后喝水”，它会定时发消息提醒我。看起来简单，但这是个人 Agent 最实用的场景之一。
3.4 Hermes Agent：当私域知识管家，桌面端和局域网部署更合适
Hermes Agent 的核心价值在于“私域部署”。如果你不想让代码、文档、聊天记录经过第三方云端，或者你在内网环境工作，Hermes Agent 桌面版往往是更安全、更可控的选择。它可以把本地文件作为知识库，做一些基于向量检索的问答；也可以把局域网内的设备接入进来，控制它执行简单操作。
热词里“Hermes Agent Windows 本地安装”说明它确实能被普通 Windows 用户直接安装。安装过程一般就是下载对应平台的安装包，按引导完成。但要注意它依赖一个本地服务引擎，安装完之后需要确认后台服务已经启动，否则桌面端会一直卡在“正在连接服务”的界面。
4. 选型建议：别被“全能”带偏，按场景下菜碟
4.1 我最终是怎么选的：四个场景四选一
我见过很多朋友钻研一个 Agent 框架恨不得用出花来，结果发现 80% 的需求用另一个工具 20% 的功能就能满足。选型千万别跟风，而是先想清楚你的主场景。
如果核心需求是“我需要一个能写代码、改代码、跑测试的终端 AI 助手”，那首选是 Claude Code。它在代码理解和上下文能力上的表现比较稳定，VSCode 集成也成熟。Codex CLI 可以作为备选，尤其是当你的代码库和 OpenAI 生态绑定得比较深时，Codex 的 CI/CD 集成会更顺。
如果核心需求是“我想在飞书或微信里有一个随时可以调用的 AI 助理”，那 OpenClaw 的社区生态和 IM 接入方案是最丰富的。你几乎不需要从零开发，大部分功能通过配置就能实现。
如果核心需求是“数据和隐私不出内网，资料只在局域网内用”，那 Hermes Agent 更适合。它本来就为本地部署和桌面端使用做了优化，不依赖公网 API，离线能力也更强。
如果核心需求是“我想做一个能自动执行任务的机器人，并且想跑在云端/服务器上”，那 Codex CLI 反而可能是第一选择。因为它就是为“命令行任务自动化”而生的，和飞书、钉钉等 IM 工具的配合完全可以靠脚本搞定。
4.2 一个被低估的考量点：Agent Evals
热搜词里有一项“agent evals”很多人没在意，但我觉得这是这四个工具不断迭代过程中最值得关注的指标之一。简单说，Evals 就是一套评估 Agent 能力的标准化测试集——你给它一个任务，看它能不能完成，完成得有多好。
我在实践中养成了一个习惯：每引入一个 Agent 新版本之前，先在我的测试集上跑一遍“回归测试”。测试集里包含十几个典型任务，比如“改一个文件里所有日期格式”“在项目里新增一个 API 路由”“飞书群里发一条日报”。跑完之后看哪些用例挂了，再决定要不要升级。实测下来，这比看官方文档和 changelog 更能反映真实水平。
市面上的 Agent 发布会宣传都很猛，但版本升级导致原有功能回退的情况也不少见。如果你正在做一个依赖 Agent 的自动化流程，建议固定一个“已验证可用的版本”，不要盲目跟随升级，否则线上任务随时可能翻车。
4.3 我的几点实操体会
踩过几次坑之后，我个人对这几个工具的使用建议可以浓缩成三句话：
- 能用托管服务解决的，不要自己折腾本地部署；
- 能在容器里跑的，不要直接在宿主机跑；
- 能在消息里简短回应的，不要让它输出长文，否则接接口截断又得加班。
现在已经有很多人把 Agent 当成“新同事”看待，我建议你也试着把它们当成团队里的“辅助角色”来管理：先写清楚岗位职责（场景边界），再定好工作流程（Skills/Agent 配置），最后做好绩效考核（Evals）。这套思路放在 OpenClaw、Hermes Agent、Claude Code、Codex CLI 里都通用。
最后再分享一个小技巧：如果你还在犹豫该用哪个，先拿同一个任务分别在 Claude Code 和 Codex CLI 里各跑一遍，对比一下输出质量和执行速度；再拿同一个“飞书日报生成”任务分别在 OpenClaw 和 Hermes Agent 里试一次。四十行代码的任务和定时日报的任务，跑完基本你心里就有答案了。工具没有绝对的高下，只有合不合适。
