别再手写规则修Agent了：OpenAI用Codex把税务Agent变成自改进系统

摘要

很多团队做 Agent，真正卡住的不是第一版能不能跑起来，而是后面怎么持续变好。线上用户问出边界问题，Agent 答错一次，研发就补一个规则、改一段 prompt、加一个 if else。短期看能止血，长期看系统会越来越难维护。

OpenAI 官方工程博客《Building self-improving tax agents with Codex》提供了一个更工程化的方向：把 Agent 的失败样例、专家纠正、代码修改和评测回归串成闭环。它不是让模型“自动乱改自己”，而是让 Codex 在受控任务范围内修改 agent 逻辑与 eval，再由评测和人工审查把关。

背景：税务Agent为什么适合做样板

税务场景有几个典型特点：规则复杂、边界多、错误成本高，而且专家知识很重要。这类场景很适合暴露 Agent 研发中的通用问题：

• 模型回答错了，到底是知识缺失、工具选择错，还是流程判断错；
• 专家发现问题后，如何把纠正转成可复用系统能力；
• 修复一次问题后，如何确认没有破坏其他任务；
• 评测样例如何从真实生产错误中持续积累。

OpenAI 这篇文章把流程拆成三步：一是从生产 traces 中定位 failure mode；二是由税务专家给出正确处理方式；三是让 Codex 生成 scoped task，改代码、补 eval，并通过测试验证。

技术要点一：失败样例要来自真实trace，而不是拍脑袋

很多 Agent 团队的评测集来自研发自己编的样例。这样能覆盖基础路径，但很难覆盖真实用户的复杂输入。

OpenAI 的流程强调从 production traces 中发现 Agent 失败模式。这个细节很关键。真实 trace 通常包含完整上下文：用户问题、Agent 中间步骤、工具调用、检索内容、最终回答和错误位置。相比只看最终答案，trace 能帮助研发判断问题发生在哪个环节。

对工程团队来说，第一件事不是立刻让 Agent 自我改进，而是先把 trace 记录完整。没有 trace，就没有可定位的 failure mode；没有 failure mode，后续修复就只能靠猜。

技术要点二：专家纠正不是一句反馈，而是可执行规格

税务专家在流程中的价值，不只是说“这个答案不对”。真正有用的是把错误改成可执行的修复目标：什么时候应该走某个判断，哪些条件必须检查，哪些来源不能忽略，输出应该满足什么约束。

这对应到软件工程里，就是把专家反馈转成规格。Codex 能处理代码任务，但前提是任务边界清楚。OpenAI 文章中提到的 scoped task 很重要：让 Codex 在明确范围内修改 agent 逻辑和 eval，而不是开放式地重写系统。

这对研发团队是一个提醒：不要把“专家审核”停留在批注层。专家纠正应该沉淀成测试、规则、工具约束、prompt 约束或数据样例，否则下一次同类问题仍然会重复出现。

技术要点三：改Agent逻辑必须同步补Eval

这篇文章最值得借鉴的地方，是 Codex 不只是改 agent，还会补 eval。很多项目只做前半段：修 prompt、调工具、改流程。问题是修完之后没有回归测试，后续任何优化都可能把旧问题带回来。

更合理的做法是，每个真实失败都应该尽量转成一个回归样例。修复代码时同时补 eval，才能形成“失败一次，系统记住一次”的效果。

这也是 self-improving 的工程含义：不是模型凭空变聪明，而是系统把生产错误转化为可运行的测试和可审查的改动。只要这个闭环持续运行，Agent 的边界覆盖就会越来越完整。

技术要点四：Codex适合做受控改动，不适合无边界自治

这里需要避免一个误解：self-improving agent 不等于让 Agent 在生产环境里自由改代码。

OpenAI 的做法更接近工程协作：Codex 接收 scoped task，在代码库里实现修复、补充 eval，然后通过测试和人工流程进入系统。它仍然需要边界、审查和验证。

这比“全自动自治”更现实。尤其在税务这类高风险领域，任何自动修复都必须可追踪：改了哪段逻辑、为什么改、对应哪个失败 trace、通过了哪些 eval、是否需要专家复核。

研发视角：Agent平台应该内置改进闭环

如果把这篇文章抽象成通用架构，一个成熟 Agent 平台至少需要五个模块：

1. Trace 采集：记录用户输入、工具调用、中间状态和最终输出。
2. Failure triage：把失败归因到知识、流程、工具、上下文或输出格式。
3. Expert correction：把专家反馈转成可执行规格。
4. Code/eval change：用 Codex 或研发改 agent 逻辑，同时补充评测。
5. Regression gate：合入前必须跑评测，合入后继续监控线上效果。

没有这个闭环，Agent 项目通常会停在 demo 阶段。因为每次上线后的真实错误都只变成一次临时修补，而不是系统能力的增长。

实践建议：给现有Agent加一条自改进流水线

如果你在维护企业内部 Agent，可以先从低风险版本做起：

• 先记录完整 trace，不要只保存用户问题和最终答案；
• 每周挑选高频失败样例，归类成 failure mode；
• 让领域专家给出结构化纠正，而不是自由文本建议；
• 每个修复都必须附带至少一个 eval；
• Codex 生成的改动进入普通代码评审流程；
• 对高风险工具调用设置人工确认和权限边界；
• 用 baseline 观察修复前后通过率、成本和延迟变化。

这套流程不一定一开始全自动。先把人工修复流程标准化，再逐步引入 Codex 协助生成 patch 和 eval，会比直接追求自治更稳。

风险与限制

税务 Agent 属于专业领域，文章中的方法不能直接等同于通用问答或娱乐类 Agent。高风险场景必须保留专家审核、审计记录和合规边界。

另外，生产 trace 可能包含敏感信息。研发团队在构建类似闭环时，需要先处理数据脱敏、权限控制和日志保留策略。否则，Agent 改进系统本身也会变成新的安全风险。

结语

真正有价值的 Agent，不是第一次回答得像人，而是每次失败后都能被系统性修复。OpenAI 这篇工程文章给出的启发很直接：别再只靠手写规则和改 prompt 续命，要把 trace、专家纠正、Codex patch、eval 回归连成闭环。

你们现在的 Agent 失败样例，是进入评测集，还是只停留在群聊复盘里？如果还没有 trace-to-eval 流程，建议先从最常见的 20 个失败样例开始。

参考来源

• OpenAI Engineering: Building self-improving tax agents with Codex
  https://openai.com/news/engineering/