当 AI 开始调教 AI：Codex 与 Claude Code 的智能体优化实战

想象这样一个实验：你给两个 AI 编程助手各自分配一个容器，里面塞进一个 AI 智能体应用、一百条运行日志、一个评分指标，然后告诉它们一件事：「把这个智能体的表现优化到最好」。没有详细的步骤说明，没有专门的评测工具，也没有 prompt 优化框架的 API。就是一个裸容器、一份数据、一个目标。

它们会怎么做？

Andrew Jesson 做了这件事。他把 Claude Code 和 Codex 分别放进相同的容器环境，让它们各自优化五个不同类型的 AI 智能体应用。结果很有意思：两个助手都交出了超越基线的方案。但他更关注的不是结果本身，而是它们在过程中展现出的工程行为。

五个应用，一个任务#

实验覆盖了五类智能体应用：

每个应用先用 gpt-5.4-mini 运行基线（最多 100 个任务），产出推理日志和评分反馈。然后优化智能体（Claude Code 用 claude-sonnet-4-6，Codex 用 gpt-5.4）被放进容器，拿到这些数据和一份简短的 skill 文件。

这份 skill 文件说了什么？四句话：浏览数据 → 添加 prompt 变体 → 测试 → 迭代。仅此而已。

没有说明书，它们自己会找到方法#

skill 文件没有教它们怎么做失败模式分析，没有说怎么跑评测，更没有提 prompt 优化框架。但两个智能体都自发地填补了这些空白。

失败模式分析：从日志到洞察#

优化智能体的第一步永远是「哪里出了问题」。它们被给了一份 feedback.jsonl（记录每个任务的评分）和一份 inferences.jsonl（记录模型实际输出了什么）。两份文件都是几十 MB 的 JSONL。

两个智能体独立地摸索出了相同的工作流：先从反馈中过滤出失败的任务 ID，再回到推理日志中查找对应的输出内容，最后将失败模式抽象成命名的问题。

比如在 NER 任务中，Codex 分析出了四类失败：

• 过度提取为 MISC 类别：日期、数字、常见短语被错误标记
• 实体边界混乱：从「Baltimore Orioles」中单独提取「Baltimore」
• 类别错误：把运动队「ENGLAND」标为地点而非组织
• 泛化过度：把「local police」等泛称标为命名组织

这其实就是人类 ML 工程师做错误分析的标准流程，只是没有用到任何专用工具，全程在终端里用 grep 和 node -e 完成。

自建评测：curl 就是评测框架#

skill 文件提示了一句「用 /inference 接口探测新变体的输出」，仅此而已。两个智能体都没有调用 OpenAI 的 eval API 或任何评测平台。它们的选择是：挑出有代表性的基线输入，用 curl 逐条发送给网关，自己阅读返回的 JSON 输出，人工判断（这里的「人工」是 AI 自己）变体是否比基线更好。

相比传统评测流程（创建数据集 → 定义评分器 → 启动评测任务 → 轮询结果 → 解析报告），智能体的自建评测省掉了所有中间层。curl 的请求体就是数据集，AI 自己对响应的解读就是评分器，下一轮探测的结果就是评判结论。

Codex 更「卷」：迭代、修剪、死磕#

这是两个智能体行为差异最大的地方。

在 25 轮优化实验中（5 个应用 × 5 个随机种子），Codex 表现出了更强的迭代倾向：

Codex 的典型行为是：写出一个 prompt 变体 → 用代表性输入探测 → 发现一个边缘 case 挂掉了 → 修改 prompt → 重新探测同一输入 → 确认修复。如果某个变体在探测中表现不佳，它会主动将其从候选列表中删除。

Claude Code 则更「佛系」：写一个变体模板，然后通过切换不同模型来生成多个候选。不删、不改、一次成型。

这背后反映的是两种不同的策略直觉。Codex 倾向于「多个 prompt × 一个模型」，深挖一个 prompt 的表达能力；Claude Code 倾向于「一个 prompt × 多个模型」，用模型多样性来覆盖不同的表现面。

自创 few-shot 示例#

两个智能体都没有拿到任何「训练数据」。但它们从基线日志中找到了真正的失败案例，把这些案例写进了新的 prompt 模板中作为 few-shot 示例。在 NER 任务中，Claude Code 甚至加上了对比结构：左侧是错误输出，右侧是正确输出，外加一个「请勿提取」区块。

这不是 skill 文件教的。这是它们从大量软件工程训练中泛化出来的模式。

专门工具还有存在的必要吗？#

Andrew Jesson 在文章末尾抛出了一个问题，我觉得值得认真对待：

失败模式分析器、评测框架（OpenAI Eval / Fireworks）、prompt 优化库（DSPy）：这些都是独立存在、精心设计的专业化工具。但当 Claude Code 和 Codex 在不访问这些工具的情况下，自发地做出了与这些工具同构的操作，我们还需要把它们建成独立的模块吗？

他的判断是谨慎的：对于小规模任务（50–70 轮对话内），打包成 skill 的方式可能就够用了。但他也给出了一个有力的反方论据：上下文焦虑。

长运行会话中，智能体的工作内存会逐渐被工具输出、部分分析和历史回合填满。专用的评测工具可以独立运行、返回摘要、释放主智能体的注意力。而让智能体自己跑评测意味着它要在同一个上下文中同时承担「写代码」「分析错误」「跑测试」「判断结果」多重角色，这在大规模场景下能否持续有效，是尚未被检验的。

我的看法：这不是替代，而是分层#

读完整篇文章，我有一个直觉：把「专门工具」和「智能体自带能力」对立起来，可能是一个错误的二分法。

Codex 做失败模式分析的效率显然不如一个专用的分析仪表板，但它胜在零部署成本、即时可用。这让我想到软件工程里一个经典的分层逻辑：探索阶段用手动工具快速迭代，稳定阶段用自动化 pipeline 做规模化。智能体的自建评测和 prompt 优化，对应的是探索阶段；专门的评测框架和优化库，对应的是稳定阶段。

两者不互斥，它们解决的是不同层次的问题。

Andrew 在文章中提到的「harness attribution」项目方向也很有意思。一旦把更多网关层的能力开放给智能体（工具添加、流程编排、可观测性），会出现什么新行为？智能体会发明自己的回归测试吗？会设计新的控制流模式吗？这些问题的答案，可能比「要不要用 DSPy」更有价值。

一点实践启发#

如果你正在用 Codex 或 Claude Code 做 AI 应用开发，这个实验至少给了三个可以用起来的启示：

1. 先给基线数据，别急着写 prompt。让智能体自己读失败案例的推理日志，它总结出的失败模式往往比你拍脑袋想到的更具体、更有操作性。

2. curl 就够了，不需要把评测框架搭起来才开始优化。在探索阶段，一两轮手动探测 + 即时判断的迭代速度远快于走完整套评测 pipeline。

3. 关注策略差异，匹配任务特性。如果任务需要 deep diving（比如 prompt 的措辞对结果影响很大），Codex 的迭代风格可能更合适；如果任务偏探索性（不确定哪个模型更好），Claude Code 的多模型策略可能更高效。

参考来源：Andrew Jesson, “The engineering practices Claude Code and Codex use to improve AI agents” (April 2026), andrewjesson.com