Codex eval 生产实践：OpenAI 自进化 Agent 如何把 traces 转化为 scoped eval 目标

可工作的 demo Agent 与能在生产环境中持续自我进化的 Agent 之间，差距不在于选择了哪个模型，而在于系统在运行时捕获了什么、以及这些证据如何流回改进循环。5 月 27 日，OpenAI 工程团队发布了一篇详细文章，描述了他们如何为 Thrive Holdings 的 Tax AI 闭合这一反馈循环——这是一个由 Codex 驱动的 Agent，本税季共处理了 7000 份税务申报表。其架构思路远超税务软件本身：任何在 API 层之上构建 Agent 的团队，都需要回答这篇案例研究正面解答的核心问题——你的生产基础设施是被设计为生成"证据"，还是只生成"输出"？

发生了什么

OpenAI 的前沿部署团队与 Thrive Holdings 协作，为 Crete 旗下 30 多家会计师事务所的网络构建了 Tax AI，以自动化处理 1040 和 1041 税务申报表。系统上线后，与大多数 Agent 部署不同——它在可量化地持续改进自身。

上线时，仅有 25% 的申报表达到了 75% 字段填写正确率。六周之内，这一数字达到了 86%。系统处理的申报表逐步变得更复杂——从 W-2 到 K-1、租赁明细、跨多文档协调——每次扩展都由上一阶段的结构化反馈驱动，而非工程师手动逐条排查失败原因。

让这一切成为可能的三层架构：

1. 将专家反馈转化为结构化信号。 会计师在提交前会修正 Tax AI 的预测。这些修正不只是被记录为差值，而是被分类为有据可查的证据：真实的字段提取失误、提示词覆盖缺口、工作流噪声，或格式不支持。这种分类将一次修正从噪声转化为可执行的训练信号。

2. 保留完整上下文的生产轨迹（production traces）。 系统捕获从源文件到字段提取、引用、下游税务引擎映射，再到会计师修正的完整路径。这是关键的设计决策：只记录输入输出的轨迹无法告诉你失败发生在流水线的哪个环节；保留中间来源信息的轨迹才能做到。

3. 用 Codex 驱动的迭代循环闭合反馈。 结构化的发现成为定制 eval 目标。Codex 将这些 eval 视作可攀登的"山丘"——排查失败原因、提出代码修改、针对回归测试套件验证，并以比手动迭代更快的速度推进改进。这里的 coding agent 不是产品本身；它是产品质量循环的基础设施运营者。

为什么这对 AI 工程团队至关重要

大多数生产 Agent 部署在反馈循环上失败，而非在模型上。失败模式跨领域高度一致：会计师、客服人员或终端用户修正了 Agent 的输出；这条修正进入工单系统或电子表格；工程师几周后手动审查，或许更新一条提示词。Agent 从生产环境中什么都没学到，直到某个人手动把信号搬回上游。

Tax AI 的架构在两个环节打破了这一模式。首先，它通过设计强制生产环境生成可检验的证据——每次交互都被结构化为可审查，而非仅仅被记录。其次，它用 coding agent 加速了工程侧的循环，使"生产中检测到模式"到"修复部署并通过回归测试"的时间从数周缩短到数天。

eval 目标的筛选策略同样值得关注。团队没有运行无差别的 eval 套件，而是按模式对失败分组（重复出现的"公平租赁天数"字段遗漏；多属性包的混淆），将模式转化为具体 eval 目标，再让 Codex 逐一攀登。精准度在这里举足轻重：衡量整体准确率的宽泛 eval 可能在全局提升的同时，让某个具体失败类别变得更糟；精准 eval 才能捕捉到聚合指标掩盖的回归。

Router/Operator 视角

对于通过 API 网关运行 Agent 的团队来说，这套自我进化模式暴露了两个通常被低估的基础设施决策。

轨迹设计是 operator 的责任，而非事后补救。 如果网关只记录模型的输入和输出，你可以衡量准确率，但无法调试多步骤 Agent 流水线中失败发生的位置。生产级 Agent 追踪意味着捕获中间状态：工具调用、检索文档、中间推理步骤、带来源引用的结构化字段提取。这不是模型可观测性的问题，而是流水线可观测性的问题。网关层决定了这份轨迹记录是被组装起来还是被丢失。

Eval 基础设施会改变你的模型路由策略。 一旦你拥有衡量特定能力切片的精准 eval——租赁属性提取准确率、K-1 字段精度、多文档协调——你就可以基于可量化的任务质量而非基准榜单排名，将不同流水线步骤路由到不同模型。一个在通用 coding 排行榜上得分很高的模型，在你有 eval 数据衡量之后，可能并不适合某个特定的提取任务。这是从"按成本路由"到"按可量化任务质量路由"的关键跨越。

希望采用这套模式的团队，可以参考以下实践清单：

• 记录中间状态，而非只记录 I/O。 每次工具调用、检索、提取步骤和验证检查都应成为轨迹的一部分。为此预留足够存储。
• 在存储修正前先对其分类。 原始的会计师修正是噪声；标注了失败类别（提取遗漏、提示词缺口、输入歧义、工作流跳过）的修正才是训练信号。
• 在需要 eval 之前就建立精准 eval。 Tax AI 团队在自我进化循环运转之前就已具备 eval 基础设施。试图在失败之后补建 eval 的团队永远落后一步。
• 将 coding agent 用作运营者，而非只是产品。 Codex 级别的 agent 可以编写并运行 eval 脚本、提交带修复的 PR，并针对回归套件进行验证。这个循环比手动迭代快得多——但前提是你的生产轨迹给了它一个具体可攀登的"山丘"。
• 在模型升级时关注路由策略。 如果你切换了 provider 或升级了模型版本，现有精准 eval 可能会揭示特定能力切片上的回归，而这些回归在聚合基准中被掩盖了。

TheRouter 用户应关注什么

通过 TheRouter 路由 Agent 工作流的团队，处于在网关层添加轨迹捕获能力的有利位置，无需修改应用代码。API 层的请求级日志与模型结构化工具调用响应相结合，为中间状态捕获提供了基础。

自我进化模式也进一步支持了一个论点：路由应被视为由 eval 数据驱动的按任务决策，而非静态的模型选择。当你拥有按能力切片划分的精准 eval 结果时，可以将文档提取步骤与推理步骤路由到不同的模型——并随着生产环境积累更多 eval 证据，持续更新路由策略。

OpenAI 原文值得完整阅读，尤其是具体的租赁属性示例——它展示了单次会计师修正如何从原始数据差值，流经分类、聚合、eval 目标化，最终成为 Codex 范围内的工程任务。从修正到改进的完整轨迹，就是这套模式的核心——领域是可替换的。