博客

当"Kimi K3"出现在我的搜索建议栏时，我做了任何开发者都会做的事——打开 Hugging Face 页面，看了一眼文件列表。

96 个分片。

我数了两遍。不是 9 个，不是 16 个。96 个主要权重分片，文件元数据合计约 1.56 TB。

这个数字没有让我感到失望，它让我感到清醒。

看到 4/17 的那一刻，我的第一反应和大多数人一样：又一个模型跑分。

HumanLayer 选了三道题，共 17 个 checkpoint，拿 Opus 5 去跑，严格通过 4 个。这个数字很容易被放进"模型评测"的心理框架里，然后滑过去，像一条新闻标题。我也几乎这样做了。

后来我打开了 SlopCodeBench 的论文。

用 Coding Agent 久了，我越来越不信单纯的模型排名。

不是说排名没有用，而是它能告诉我的事情有限。我同时跑 Claude Code 和 Codex 做真实项目，时间长了有个明显感受：同一个模型，在不同 Harness 下交出来的结果差距很大。上下文怎么进、工具开了哪些、验证跑在哪一层——这些东西会直接改变最终输出的质量，跟模型本身一样重要，有时候比模型本身更重要。

所以每次新模型发布，我第一反应不是刷榜单，而是想搞清楚：这个新数字，是在什么 Agent、什么 Harness、什么 effort 下测出来的？

Opus 5 发布在七月二十四日。这一次，公开材料提供的信息足够多，刚好可以把这个问题问得更清楚。

刚刚我用 Codex CLI 做了一次只读诊断，最终状态显示 completed，答案正确，Agent 给出了我期望中的最小修复判断。如果这是我唯一看到的东西，我会满意地关掉终端，认为一切如预期运行。

但事件流里还有另一层故事。

上一篇 Observability 教程里保存了一次真实的 Codex CLI 0.145.0 运行。最终判断是正确的，turn 状态是 completed，5 次工具调用里有 2 次失败——Agent 自己绕过去了，结果还是对的。保存的事件流记录了这条路径里可见的工具调用、失败结果和恢复过程。

但它回答不了一个更重要的问题：明天我换了 Agent 版本、换了模型、调整了 Prompt、改了 Skill loadout，甚至只是升级了 Harness——新行为究竟是更好、更差，还是只是不一样？

一次成功运行不是回归测试。

7 月 23 日的热榜有点意思。

7 月 23 日的一次 NewsNow／掘金热榜抓取里，同时出现了三种内容：怎么挑选值得装的 Skills、怎么写出好的 Skill、以及"为什么装得越多，Agent 越笨"。同一时间窗口，Hacker News 上也出现了检查 Skills 负载、用使用证据治理 Skill 修改、统计哪些能力长期没有触发过的项目。

这个并列本身就说明了问题正在发生变化。

大家的提问，已经从"还能装什么"，悄悄转向了"哪些真的会触发、哪些会误触、哪些互相抢任务、哪些只是在占上下文"。这是一个方向性的转变，值得认真想一想。

在我开始关注“Loop Engineering”和“Graph Engineering”这两个词之前，工作中已经出现了让我不舒服的信号：一个被拆分成多个子任务的总体目标，在运行一段时间后开始出现奇怪的漂移。不同的工作单元各自在收敛，但它们收敛的方向并不一致；某个单元完成了局部目标，却悄悄改变了另一个单元赖以决策的前提。我知道问题出在哪里，但当时没有好的词来说它。

后来在 X 和一些开发者文章里看到这两个词被拿来对比，感觉很像是找到了语言。不是术语帮我想清楚了，而是语言把已经想清楚的东西给了一个锚点。

很多人看到 Cursor、Claude Code、Codex CLI 三个工具，第一反应是：到底该选哪个？

但更常见的实际问题是：我已经在用 Cursor 了，Claude Code 或 Codex CLI 还有必要加吗？

结论先说：三个工具分工不同，可以搭配，但不代表你一定要全买。关键是搞清楚各自的主场，按实际需求组合。

结论先说：两个工具都是终端 Agent，都能读写文件、执行命令、多步骤自动完成任务。但一个根植 Anthropic / Claude 生态，一个是 OpenAI Codex 产品线的本地入口。选哪个，更多是在选生态，不是在选功能。

OpenAI 推出了 Codex CLI。

如果你听说过它但还不确定它是什么——这篇讲清楚。