最近看了一圈 Codex、Claude Code、Kimi Code、OpenCode、Hermes，我发现它们已经不太像同一类工具了。
有的偏写代码，有的偏跑流程，有的偏长任务，有的偏团队交付，还有的干脆想做一个 Agent Hub。
所以这篇不聊谁跑分高，也不聊谁的 benchmark 更吓人。对程序员来说，真正重要的是：
它能不能接手一段真实工作流？
也就是这条链路能不能跑顺：
理解任务 → 执行工具 → 处理权限 → 交付结果 → 复用流程
如果只看模型能力，很容易看花眼。现在这些工具已经开始分岔了。
1. AI 编程工具，已经不只是“帮我写代码”
以前我们说 Coding Agent，基本就是：
- 帮我写代码
- 帮我改 bug
- 帮我补测试
- 帮我解释报错
现在不一样了。
最近这些工具都在往更完整的工作流走：
- Codex 开始支持 Record & Replay，把重复流程录成 Skill
- Claude Code 上了 Artifacts，把终端工作变成可分享的页面
- Kimi Code 强化了 Goal、AgentSwarm、后台问题、Sub-Skill
- OpenCode 强化 LSP、AST、MCP、插件生态
- Hermes 做后台 subagent、多平台渠道、Dashboard、Profile Builder
这说明一件事：
AI 编程工具正在从“终端里的助手”，变成“能接手一段工作流的 Agent”。
这也是我觉得横评不能只问“谁代码能力强”的原因。
写代码只是第一步。真正麻烦的是后面的事：
- 谁来跑测试？
- 谁来处理审批？
- 谁把结果整理给团队？
- 谁能把流程沉淀下来？
- 谁能后台跑长任务？
- 谁能接入本地文件、MCP、LSP、浏览器、消息渠道？
这些才是现在工具链开始卷的地方。
2. Codex：把重复流程录成 Skill
Codex 最近比较有代表性的更新，是 Record & Replay。
翻译成人话就是：
你不用写一长串 prompt，只要示范一次流程，Codex 把它整理成可复用的 Skill。
这个方向很有意思。
它不是单纯写代码，而是在把 GUI 操作、浏览器操作、插件调用，变成可复用的自动化流程。
适合场景大概是这些：
- 填写报销单
- 提交 issue
- 发布内容
- 下载报表
- 填写表单
- 定期整理数据
- 把某个网页流程重复跑一遍
这类任务有个共同点：流程明确，但操作繁琐。
以前你可能要写一堆 prompt：
先打开这个页面，然后点这里，再输入这个字段，再下载这个报表，最后把结果整理成表格。
现在 Codex 的思路是：
你先演示一次，我记录，然后下次你来告诉我新的输入。
这其实更接近 RPA，但它又比普通 RPA 多了一层理解能力。
不过 Codex 这条路也不是万能的。
它更适合：
- 流程固定的重复任务
- 有明确输入输出的流程
- 需要浏览器 / GUI / 插件配合的任务
- 办公自动化、运营流程、轻量业务操作
不太适合：
- 开放式研发任务
- 架构设计
- 复杂代码迁移
- 需要大量上下文判断的工程问题
所以我对 Codex 的判断是：
它不是最强的 Coding Agent，但它正在把“重复工作流自动化”这个坑填上。
3. Claude Code：终端 Coding + Artifacts 交付
Claude Code 最近的亮点是 Artifacts。
它不是简单把代码输出到终端，而是可以把 Claude Code 的工作成果发布成一个可分享的私有页面。
这个功能很实用。
比如你可以让它：
- 把 PR 改动整理成一个带标注的 review 页面
- 把一次排查过程做成时间线
- 把部署失败数据做成 dashboard
- 把几个方案并排展示
- 把迁移计划做成 checklist
- 生成一个团队能直接打开看的 HTML 页面
这解决了一个很真实的痛点：
终端输出适合人看，但不一定适合团队同步。
以前 Claude Code 跑完一堆东西，你可能要把结果复制到 Slack、飞书、Notion 里。
现在可以直接给一个 artifact 链接。
这对团队协作很友好。
尤其是这些场景：
- PR review
- 技术方案对比
- 故障复盘
- 数据看板
- 迁移计划
- 给产品 / 测试 / 非技术同事看的交付物
但 Artifacts 也不是完整应用。
官方文档里也讲得很清楚，它更像：
一个自包含的单页交付物。
它不适合：
- 多页面应用
- 需要后端的应用
- 需要实时 API 调用的页面
- 复杂业务系统
所以我对 Claude Code 的判断是：
它很适合“编码 + 交付物”。尤其适合需要把终端工作变成团队可理解内容的场景。
简单说：
Claude Code 不只是把代码写出来，它还在帮你把结果讲清楚。
4. Kimi Code / Kimi Work：国产 Agent 的长任务打法
Kimi 这边要分两块看：Kimi Code 和 Kimi Work。
它们相关，但定位不一样。
先说清楚一个前提：Kimi Work 目前还偏 internal testing / Beta 状态，公开可用性、稳定性、插件覆盖范围，都不一定像官方介绍得那么成熟。把它写进横评，更适合当成“方向观察”，不要当成已经完全稳定可用的生产工具。
Kimi Code：更像开发者的长任务 Agent
Kimi Code 最近的更新很密。
几个值得关注的点：
- Kimi K2.7 Code 发布
- Goal 模式
- 后台结构化提问
- Sub-Skill
- AgentSwarm
- /goal next 任务队列
- 从 Claude Code / Codex 导入指令、Skills、MCP 设置
- ACP 接入 IDE
- Web 模式
- 会话可视化 kimi vis
这里最值得关注的是 Goal 模式 和 AgentSwarm。
Goal 模式的思路是：
你给一个目标，它跨多个轮次持续推进，直到完成，或者遇到需要你决策的阻塞。
这对程序员很实用。
比如你给它一个任务：
把这个项目的配置整理一下，补 README，生成部署脚本，跑一遍测试，最后给我迁移清单。
这种任务不是一句 prompt 能说完的。
它中间可能需要：
- 读代码
- 改配置
- 跑命令
- 遇到测试失败再修
- 问你几个选择
- 最后整理结果
Kimi Code 现在明显在补这类能力。
还有 后台结构化提问 也挺关键。
以前 Agent 遇到一个问题卡住，整个流程就停了。
现在它可以把需要人确认的问题挂到后台，然后继续处理其他步骤。
这对长任务很重要。
长任务最怕的不是慢，而是动不动就停下来等你。
另外，Kimi Code 支持从 Claude Code 和 Codex 导入部分指令、Skills、MCP 设置，这个对迁移用户挺友好。
不用一上来全部重配。
Kimi Work：更像桌面级数字员工，但要等成熟度
Kimi Work 更偏知识工作者，不只是程序员。
它主打的是：
- 本地文件
- 浏览器自动化 WebBridge
- 定时任务
- Agent Swarm
- 生成 PPT / Excel
- 金融数据源
- 目标模式
- 插件中心
如果说 Kimi Code 更像“开发终端里的 Agent”，那 Kimi Work 更像：
一个坐在你电脑上的数字员工。
它适合：
- 自动抓网页数据
- 整理行业资料
- 生成 PPT
- 做 Excel
- 跑定时任务
- 处理本地文件
- 跨网页执行多步骤任务
但这里要特别保守一点。
Kimi Work 目前不要当成熟生产工具写。
至少到 2026 年 6 月，它更像是 internal testing / Beta 方向，公开可用性、权限边界、插件稳定性、长任务可靠性，都需要再观察。
所以我对 Kimi Work 的判断是：
方向很诱人，但现阶段更适合试用和观察，不适合直接写进公司生产流程。
如果说 Kimi Code 是“国产长任务 Agent”的实打实入口，Kimi Work 更像是月之暗面在桌面级 Agent 上的一次提前占位。
5. OpenCode：本地可控的 Agent Runtime
OpenCode 的定位不太一样。
它不像 Claude Code 那样主打终端体验和团队交付，也不像 Kimi Work 那样偏桌面数字员工。
OpenCode 更像：
一个可以本地配置、组合 LSP / AST / MCP / 插件的 Agent Runtime。
这点很重要。
它适合喜欢自己搭工作流的人。
比如：
- 自己配置 LSP
- 自己接 MCP
- 自己选模型
- 自己写 instruction
- 自己控制 Agent 行为
- 自己决定哪些工具能跑
OpenCode 最近比较值得写的是 LSP Servers。
它支持很多语言服务器，比如：
- Go：gopls
- Java：jdtls
- C#：csharp / razor
- TypeScript：typescript
- Python：pyright
- Rust：rust-analyzer
- Kotlin：kotlin-ls
- PHP：php intelephense
- Vue / Svelte / Astro 等前端项目也有对应支持
LSP 的作用是把语言服务器 diagnostics 反馈给 Agent。
也就是说，Agent 不只是靠聊天上下文理解代码，还能拿到：
- 语法错误
- 类型错误
- lint 问题
- 项目诊断信息
这对写代码有帮助。
但这里要泼一盆冷水：
LSP 不是越强越好。
OpenCode 文档里也说得很实在。
LSP 可能：
- 占内存
- 和工程状态不同步
- 拖慢 Agent workflow
- 不同项目体验差异很大
- 有些项目不如直接跑 lint / typecheck
所以我的建议是：
不要无脑开 LSP。
更稳的做法是：
- 小项目可以先开
- 大型项目谨慎开
- Java / C# / Go 这类强类型项目可以试
- 前端项目可以先用 eslint / typecheck
- 如果 LSP 拖慢明显，关掉，让 Agent 直接跑 CLI 诊断
我对 OpenCode 的判断是：
它适合本地可控的工作流，不适合只想开箱即用的人。
如果你喜欢自己调配置、接工具、控制边界，OpenCode 很有意思。
如果你只想打开就用，Claude Code / Kimi Code 可能更省心。
6. Hermes：从 Agent 客户端，变成 Agent Hub
Hermes 最近的版本，已经不是单纯一个 Agent 客户端了。
它更像是在做：
Agent Hub。
这版 Hermes 有几个变化值得注意：
- 后台 subagent
- Desktop App 大幅增强
- Dashboard Profile Builder
- Skills Hub 重做
- Memory atomic batch
- Telegram rich messages
- iMessage / Raft / WhatsApp 新渠道
- image edit
- Grok Composer 模型接入
- Curator 默认省成本
这里面最值得程序员关注的是 后台 subagent。
以前你让 Agent 跑一个长任务，很多时候只能等着。
现在 Hermes 的后台 subagent 可以：
- 立即返回 handle
- 后台继续跑
- 跑完再把结果送回对话
这对多任务场景很实用。
比如你可以让它后台做：
- 长调研
- 多步骤 build
- 文档整理
- 日志分析
- 代码迁移检查
然后你自己继续干别的。
另外，Hermes 的 Dashboard Profile Builder 也很关键。
它让你可以在浏览器里配置：
- model
- skills
- MCP servers
- profile
- session
- tool backend
这对团队管理 Agent 很有用。
因为 Agent 一旦变成日常工具，问题就不只是“怎么问 prompt”了。
你还要管：
- 谁用什么模型
- 哪些 profile 给谁用
- 哪些 skills 可以装
- 哪些 MCP 能连
- 哪些渠道能发消息
- 哪些任务可以后台跑
所以我对 Hermes 的判断是：
它适合做 Agent Hub，不适合只拿它当一个代码补全工具。
7. 这几个工具，到底怎么选？
我不建议按“谁最强”选。
这个选法太虚。
更实际的选法是按任务选。
如果你想改代码
优先看：
- Claude Code
- Kimi Code
- OpenCode
如果你想要省心和交付物，Claude Code 更顺。
如果你想要国产长任务，Kimi Code 值得试。
如果你想要本地可控，OpenCode 更适合。
如果你想做团队交付
优先看：
- Claude Code Artifacts
- Kimi Work，前提是你能拿到测试资格，并且接受 Beta 状态
- Hermes Desktop
尤其是 Claude Code Artifacts，很适合把 PR review、排查过程、方案对比做成页面。
这点比单纯终端输出更接近团队协作。
如果你想跑长任务
优先看：
- Kimi Code Goal
- Hermes background subagent
- OpenCode background agents
长任务的核心不是“会不会写代码”，而是：
- 能不能持续推进
- 能不能后台跑
- 遇到阻塞怎么办
- 能不能接下一个目标
- 能不能恢复上下文
Kimi Code 的 Goal / AgentSwarm 是这条路线。
Hermes 的后台 subagent 也是这条路线。
如果你想自动化重复流程
优先看：
- Codex Record & Replay
- Kimi Work WebBridge，但现阶段更偏 Beta 试用
- Hermes Automation Blueprints
这类任务的关键不是模型多聪明，而是：
- 能不能记录流程
- 能不能复用
- 能不能处理变量输入
- 能不能分享
- 能不能稳定重跑
Codex Record & Replay 的思路很直接：
示范一次，变成 Skill，下次复用。
这对重复办公流程很有吸引力。
如果你想搭本地 Agent 工作流
优先看：
- OpenCode
- Hermes
OpenCode 更偏本地 runtime。
Hermes 更偏 hub 和管理面。
如果你想自己控制模型、工具、MCP、LSP、权限边界，这两个都值得看。
8. 一张表看定位
| 工具 | 更适合做什么 | 不太适合什么 | 一句话判断 |
|---|---|---|---|
| Codex | 重复流程自动化、GUI / 浏览器操作、Skill 复用 | 开放式研发、复杂架构任务 | 把流程录下来，下次接着跑 |
| Claude Code | 编码、PR review、团队交付物、Artifacts | 多平台消息接入、本地 Agent Hub | 写代码，也负责把结果讲清楚 |
| Kimi Code | 国产长任务、多 Agent 并行、开发者工作流 | 团队级 Agent 管理面 | 给一个目标，让它持续推进 |
| Kimi Work | 知识工作、浏览器自动化、PPT / Excel、定时任务 | 成熟生产工具 | 方向诱人，但目前更适合试用观察 |
| OpenCode | 本地可控 Agent Runtime、LSP / MCP / 插件组合 | 开箱即用、非技术用户 | 喜欢自己搭工作流的人会更喜欢 |
| Hermes | 多平台渠道、后台 subagent、Agent Hub、Profile 管理 | 单一编码场景 | 更像 Agent 中枢，不像单个工具 |
这张表别当排行榜看。
它更像是选型图。
9. 我的真实建议
如果我是个人开发者，我不会一上来就追最贵的旗舰。
我会先按自己的真实工作流选。
经常写代码、改 bug、跑测试
先用 Claude Code / Kimi Code / OpenCode 试。
- 想要交付物：Claude Code
- 想要国产长任务：Kimi Code
- 想要本地可控：OpenCode
经常做团队同步
重点看 Claude Code Artifacts。
它解决的不是代码问题，而是协作问题。
很多技术工作最后不是死在“不会写”，而是死在“写完了没人看得懂”。
经常有重复流程
重点看 Codex Record & Replay。
如果你经常做“打开网页、下载报表、填表、通知别人”这种事，录一次流程比写 20 行 prompt 靠谱。
经常跑长任务
重点看 Kimi Code Goal 和 Hermes background subagent。
长任务最重要的不是快，而是稳。
能后台跑、能恢复、能排队、能处理阻塞，比单次回答漂亮更重要。
想把 Agent 当系统级工具用
重点看 Hermes。
它更像 Agent Hub，不只是 coding 工具。
多 profile、多平台、多渠道、后台任务、Dashboard 管理，这些才是 hub 的价值。
10. 最后说说我的用法
现在这批 AI Agent 工具，已经不是“谁替代谁”的关系了。
更像是一套组合：
- OpenCode：本地工作流，自己可控
- Kimi Code：国产长任务，持续推进
- Claude Code：编码和团队交付
- Codex：重复流程自动化
- Kimi Work：知识工作和浏览器自动化，但当前更适合试用观察
- Hermes：Agent Hub 和多平台调度
真正好用的方式，不是只装一个。
而是把你的工作拆开：
- 写代码，用什么
- 跑长任务，用什么
- 做交付物，用什么
- 自动化重复流程，用什么
- 管理多个 Agent，用什么
这才是现在 AI Agent 工具链横评最有用的地方。
别再只问“哪个模型强”。
先问你的工作流卡在哪。
卡点不同，答案完全不同。
评论区