用 Codex 构建自我改进的税务 Agent

Tax AI 通过从业者修正、production traces 和 Codex 驱动的迭代循环实现自我改进。

OpenAI 与 Thrive Holdings 如何携手为 Crete 会计师打造 Tax AI：融合从业者专业知识与 Codex 驱动的迭代循环

现实世界的系统在 production 环境中的表现往往与实验室中截然不同，会以部署前难以预料的方式出问题。团队通常在上线后才发现这些 failure，然后花费数周时间检查 edge cases、调整 prompts，并将 production 反馈转化为持久的产品改进。这种 feedback loop 是手动且缓慢的，只有工程师推动它时才会前进。但如今，凭借精心设计的 eval 基础设施、直接触达从业者和真实环境的渠道，以及 Codex 的前沿 agent 能力，你可以构建能够自我改进的 agents。

在本文中，我们将拆解如何使用 Codex 构建这类 agent。在过去六个月里，OpenAI 派驻了工程师和研究员，与 Thrive Holdings 的工程师合作，为 Crete 旗下 30 多家会计师事务所的网络共同打造了 Tax AI，帮助处理日益复杂的税务申报。Tax AI 不再依赖工程师逐一发现和修复每个 failure，而是用 Codex 将 production 使用转化为结构化 signals，驱动自主改进。

Crete 的从业者每个报税季要处理数万份税务申报，需要查阅数百万份底层文档。对于中等至高复杂度的申报，仅数据录入就可能每份耗时八小时，往往涉及杂乱的数据源、往年文档以及手动提取和计算。他们指出，税务申报是报税季最繁忙时段的重大瓶颈。

为解决这个问题，Tax AI 在本报税季处理了 Crete 参与试点的会计师事务所共 7,000 份税务申报。该系统自动化了处理 1040 和 1041 税务申报中大量耗时的流程，但比效率提升更引人注目的是，系统本身相比三个月前首次部署的版本有了可衡量的显著改进。

可衡量的自我改进

在 Tax AI 中，从业者上传源文件以及任何客户特定的备注。Tax AI 随后创建 tax engine 提交，供审核使用。它为从业者节省了约三分之一的税务申报时间，以高达 97% 的准确率起草申报表，并将吞吐量提高约 50%，让他们有更多时间与客户沟通。

我们可以通过了解 Tax AI 完成申报的准确程度来量化这种改进，即无需后续修正就能正确完成的申报比例。我们通过检查有多少申报达到 75%、90% 或 100% 的字段正确完成率来衡量准确性。上线时，只有四分之一的申报达到 75% 的字段正确完成率，但六周内，86% 的申报达到了这一标准。系统在 90% 和 100% 字段正确完成率级别上显示出更快的增长。这些阈值让我们实际了解不同申报仍需从业者多少后续跟进。

初期，Tax AI 处理较简单的工作，如 W-2 和 1099 表格。随着报税季推进，它开始处理更复杂的申报，包括 K-1、附表中以及更难的 edge cases。每一项新能力都比前一项每份申报节省更多时间，因为它承担的任务更难、手动处理更耗时。我们至今仍持续看到进展。

接下来，我们将详细介绍我们的团队如何依靠三大核心支柱共同设计 Tax AI 使其能够自我改进：1) 专业从业者的 feedback，2) production traces（从 inputs 到最终 output 的结构化历史记录），3) 基于定制化 evals 的 Codex 驱动 iteration loop，以实现持续、更快的产品开发。我们希望我们的经验对其他在从业者专业知识对塑造整体系统和数据质量至关重要的领域进行构建的人有所帮助。

随着 Tax AI 扩展到更复杂的申报领域，达到 75%、90% 和完全完成率的申报比例在整个报税季持续上升。

问题所在

当我们深入税务申报中更困难的部分（K-1、房地产租赁附表，以及需要在多个源文件之间协调数值的税务表格）时，显而易见，真正的挑战在于产品是否能让复杂的 production failures 变得可见、可理解且可操作。

在产品早期，大多数修正都是手动的。从业者可以修正系统错误，但产品没有捕获完整的上下文：申报前更改的数值可能反映了真正的 extraction miss、mapping 问题、产品支持缺失，或是预期的 workflow noise。理清这些情况仍需要工程团队跟进。工程师可以使用 coding agents，但系统尚未设计成在 improvement loop 中有意义地使用 AI。我们没有 signal 来确定应该攻克哪个难点。

我们的方法：三部分 loop

这促使我们围绕三大支柱设计系统：

1. 贴近从业者： 从事实际工作的人需要引导产品的学习方向。他们的直觉和理解揭示了哪些错误至关重要，并帮助确定 workflow 中哪些部分值得接下来重点关注。
2. 构建能让 production 产生 evidence 的产品： 产品不能只捕获 inputs 和 outputs；它需要捕获从源材料到 extracted fields 和 provenance，再到 downstream submission 和 expert correction 的完整路径。
3. 创建 Codex 驱动的改进 loop： 一旦 production issues 变得可见且结构化，它们就可以成为 findings、定制化 evals 和范围明确的 engineering tasks。Codex 随后可以帮助调查、提出变更、针对 targeted 和 regression evals 进行验证，并推动产品前进，速度远快于纯手动的 iteration cycle。

下面的房地产租赁示例展示了这个 loop 在实际中如何运作，带你了解从业者 correction 如何变成 structured finding，然后成为 eval target，最后成为 Codex 范围的 engineering task。

房地产租赁示例

房地产租赁收入在个人税务申报的 Schedule E 中申报。从工程角度来看，提取这项收入的任务描述起来简单，但要做好却很难。系统必须阅读杂乱的源材料（手写笔记、电子邮件、电子表格和其他客户文件），提取系统可以有信心 mapping 到 tax engine 的租赁物业字段，并保留足够的 evidence，让从业者可以批准或修正结果。下面的简化示例展示了这些源文件和提取的 output 可能是什么样子。

房地产租赁源包被标准化为带引用的 fields，然后 mapping 到下游 tax engine concepts。

1. 从业者 correction 揭示 failure

agent 预测值与已申报税务回报的实际值之间的差异可能反映了真正的 extraction miss，但也可能是从业者偏好、从 tax engine 中往年申报结转的值，或在 filing workflow 其他地方引入或更改的值。从业者帮助我们区分这些情况，以便我们识别哪些操作需要从业者 correction 或阻止提交。

由于我们能够详细看到这些 corrections，我们将 review 流程从事后的 terminal 步骤转变为持续的学习 cycle。我们设计 workflow 将专家 actions 捕获为结构化 data。现在，每次 intervention 都通过准确记录 Tax AI 提议的内容、从业者修改的内容以及最终进入已申报回报的内容，为产品的 improvement loop 提供养分。

2. Product traces 将 corrections 转化为 evals

对于像房地产租赁这样的复杂 workflow，系统必须保留源文件和已申报回报之间发生的一切。在这条路径上，文档被组织、拆分和分类；租赁物业字段被提取并附带指向源材料的引用；这些值被 mapping 到 tax engine 中；从业者仍可能在申报前修正它们。这些 product-level traces 使得调查 failure 发生在哪里成为可能。要将从业者 corrections 转化为有用的 evaluation targets，系统分三步处理它们：

• 捕获差异： 将 Tax AI 的 output 与已申报回报进行比较，生成 field-level review rows，捕获预期值、预测值以及差异是否看似可操作。
• 分组相关 failures： 将相似的 review rows 分组，以区分重复出现的产品 failures 和预期的 workflow noise。例如，重复的从业者 corrections 可能表明 Tax AI 经常遗漏 fair-rental-day 字段、错误处理"other expenses"，或混淆同一源包中的多个租赁物业。
• 将重复模式转化为 eval targets： 一旦经过 review 和测量，重复的 findings 就成为 Codex 改进的清晰 eval targets。

房地产租赁 review rows 区分了重复出现的产品 failures 和预期的 noise，然后将可操作的案例转化为 evaluation targets，为 Codex 提供攻克的难点。

3. Finding 成为 Codex 攻克的难点

第三支柱是创建能够针对这些新 evals 采取行动的 engineering loop。这正是 Codex 发挥核心作用的地方。

假设我们的 eval pipeline 标记出 Tax AI 持续遗漏"fair rental days"字段，而从业者却能可靠地填写它。由于这个 finding 已经被打包成一个 targeted eval set，包含代表性的源包和预期的 outputs，Codex 可以直接在产品 scaffold 内调查根本原因。

Codex 不仅仅处理低于标准的最终 output。它同时检查 trace、eval、repo 和 skills：

• 调查 pipeline： 检查源包、extraction schemas、mapper 行为和 code paths，以确定问题是 unsupported field、missed extraction pattern、source-selection 问题、mapper gap 还是 grader issue。
• 实施针对性修复： 扩展 extraction schema、改进租赁物业文档的 source selection、更新 tax-engine mapper，或者如果预期的 workflow noise 被计为 failure 则优化 grader。
• 验证并提出： 重新运行 targeted eval，运行更广泛的 regression suites，并提出 candidate pull request 供工程 review。
• 关闭 loop： 将重复出现的从业者 correction 转化为可衡量的 engineering task。如果 evidence 模糊或无法安全自动化，案例将返回产品团队，而不是被迫通过 loop。

端到端的 self-improvement loop：production traces 暴露重复的 field-level corrections，这些成为 failure signals，Codex 可以连同 trace、evals、repo 和 skills 一起检查。可操作的模式成为有边界的 evals 和 candidate product changes；模糊的案例返回工程师进行 review。每一次 shipped improvement 都会为下一个 cycle 创造新的 production evidence。

如何使用 Codex 构建这个 loop

房地产租赁示例是一个更广泛可复用模式的象征：利用 production artifacts 和 traces 来提高 agent 的能力。给定来自 production data 的 reviewed findings、source traces、预期的 tax-engine output、相关 code examples 和 eval commands 作为一组 inputs，Codex 可以在数周和数月内显著提高性能和准确性。这建立在我们关于 harness engineering 和 Symphony 工作中描述的原则之上，这些工作介绍了如何让 tasks 对 Codex 可读、提供有边界的 context 和 tools，并将 validation 和 human review 保留在环境中。

这些 evidence 不会自动成为 Codex task。从业者 correction 可能反映 extraction miss、mapping issue、不支持的产品行为、税务判断或预期的 workflow noise。只有在重复的差异经过 review 并分组为可操作的 finding 后，系统才会将它们转化为具有清晰成功条件的有边界 task。

我们将这种自动化应用于产品的有边界层。该层执行 extraction 并将源文档 mapping 到税务 workflows。工程师仍负责 architecture、产品决策和 shipping。从业者通过他们已经在做的工作来引导 improvement loop：修正 extracted values、review 申报和批准最终 filings。

对于 Codex，结果不是模糊的 alert，而是具有 evidence、可编辑产品表面和明确 validation gates 的范围明确的 engineering task。代表性租赁物业任务的 context 可以概括如下：

有边界的 Codex task 环境将可写入的 worktree 与只读的 production context 分离。worktree 包含 Codex 可以检查或修改的范围明确的产品表面、定义成功的 targeted 和 regression evals，以及编码如何运行任务和尊重先前决策的可复用 skills/docs。只读 context 提供 production trace、源文档、Tax AI 预测、最终确定的回报和 tax-engine 字段文档，因此 Codex 可以在不改变底层 evidence 的情况下调查 failure。

扩展到新领域

同样的 loop 适用于房地产租赁之外的领域。房地产租赁花费了大约六周时间和大量的工程监督才达到 90% 的 precision 和 recall，但这项工作产生了可复用的 abstractions、review artifacts、eval conventions 和 implementation patterns，使得支持同样复杂的 Schedule C 和 Schedule A 等附表变得更加容易。

Tax AI 证明了构建 self-improving agents 的一条路径。从业者通过提供服务生成高价值的 feedback signals。产品 workflows 将这些 signals 保存为结构化 evidence。Eval 支持的 engineering systems 在改进到达 production 之前验证它们，而 agent 驱动的 loop 使系统保持持续的 self-improving 流程。

Thrive Holdings 的结构使我们能够在特定行业中复制这种环境。Holdings 既是所有者又是运营者，因此我们的联合工程团队能够直接与从业者合作，并使用来自 Crete 等企业内部的 production data，不是作为供应商，而是作为合作伙伴。这意味着技术、产品和服务都在一个屋檐下，帮助我们更快地行动并构建卓越的产品。

一位高级会计师去年在税务准备上花费了 180 小时，而今年只花了 15 小时。她将部分时间用于给每位客户打电话，向他们详细解释申报表，这种高水平的贴心服务在一年前是不可能的。剩余的时间她用来承接新客户并扩展新的服务项目。

我们的团队现在正将 Tax AI 的三部分设计作为蓝图，用于在 Thrive Holdings 跨其他领域构建 workflows；会计 workflows 如簿记和审计，以及运营 workflows 如 IT 服务台自动化。跨领域和行业，self-improving agents 的更广泛承诺依然成立。最好的 agents 由人类引导，学习变得更有能力、更受信任、更有价值。

要了解更多关于参与此项目的 OpenAI 团队信息，请联系。