Claude Code 和 Codex 用于改进 AI 代理的工程实践

标题：Claude Code 和 Codex 用于改进 AI 代理的工程实践

作者：Andrew Jesson | 2026年4月24日

编码代理在被要求改进 AI 代理时，会执行常见的工程实践。它们是否会取代用于故障模式分析、评估和提示优化的专用工具？

给一个编码代理一个模拟的代理应用、一百条基线轨迹和一个要优化的指标，它就会交付改进。Claude Code 和 Codex 都能做到这一点。我感兴趣的是观察它们在这个过程中具体做了什么。

实验设置：我提示 Claude Code 和 Codex 优化了五个模拟的代理应用，仅在容器中更换了代理 CLI。对于每个应用，我使用初始提示和模型（gpt-5.4-mini）在多达100个不同任务上运行基线代理。生成的轨迹通过应用特定的反馈进行评分。优化任务是通过修改基线代理提示和/或选择不同但价格相近的模型来提出改进。优化器代理（Claude Code 或 Codex）被放入一个容器中，可以访问这些轨迹、反馈、基线配置副本和一个描述任务的技能文件。它分析轨迹和反馈，写入一个或多个新的模型-提示变体到代理配置中，然后退出。验证表明，两个编码代理都在每个应用上交付了匹配或超越基线的新变体。

它们使用了哪些工程实践？两个编码代理使用相同的技能文件，只包含应用名称、指标、可用模型、数据布局和一些效率方法，以及一个四要点方法论：调查→添加变体→测试→迭代。技能文件对如何抽象故障模式或如何验证改进保持沉默。两个代理填补了这一空白。它们读取基线轨迹和反馈，从原始行中抽象出一些故障模式，编写两到四个提示变体，运行一些推理，分析新输出，然后退出。

故障模式分析：从推理和反馈数据集出发，识别出“模型过度抽取杂项，因为它将其视为一个综合类”这样的模式。技能文件将这两个先决条件留给代理：从 JSONL 中投影失败行，然后将它们抽象为命名模式。两个代理都采用了相同的配方：从反馈中 grep 出失败的 target_id，然后将每个 ID 对应到推理行并取最后一行。在获得失败行后，两个代理都可以跨多个轨迹进行抽象。例如，在命名实体识别任务中，代理识别出过度抽取、实体边界混淆、错误分类等故障模式。

此外，编码代理还会发现错误——不仅是“模型在这一类上出错”，而是“模拟器在测试时行为异常”等深层问题。

这些观察让我重新考虑专用工具在代理优化日益自动化背景下的作用和形态。这也是我启动一个名为“harness attribution”的项目的原因；本文是其首次探索。