OpenAI · 官方博客

用 Codex 构建自我改进的税务代理

Building self-improving tax agents with Codex

二〇二六年五月二十七日 · 英文原文

Thrive Holdings 与 OpenAI 合作,为 Crete 旗下 30 多家会计师事务所开发了 Tax AI,该系统基于 Codex 驱动循环实现自我改进。Tax AI 在本报税季处理了 7,000 份纳税申报,自动化了 1040 和 1041 申报的耗时流程,为从业者节省约三分之一准备时间,准确率达 97%,吞吐量提高约 50%。系统通过三个支柱实现改进:专家从业者反馈、生产轨迹捕获、Codex 驱动的 eval 迭代循环。上线六周内,86% 的申报达到 75% 正确字段完成率,较初期的 25% 显著提升。

Thrive Holdings 与 OpenAI 如何通过融合从业者专业知识与 Codex 驱动的循环,为 Crete 的会计师共同开发 Tax AI

真实系统在生产环境中的表现与实验室不同,其故障方式在部署前难以预料。团队通常在上线后才发现这些故障,然后花费数周检查边缘案例、调整 prompt,并将生产反馈转化为持久的产品改进。这个反馈循环是手动且缓慢的,只有工程师推动时才能改进。但如今,借助精心设计的 eval 基础设施、直接接触从业者和真实环境的能力,以及 Codex 的前沿 agent 能力,你可以构建能够自我改进的 agent。

在这篇文章中,我们将解析如何使用 Codex 构建这类 agent。过去六个月里,OpenAI 的前沿部署工程师和研究人员与 Thrive Holdings 的工程师合作,为 Crete⁠(opens in a new window) 旗下 30 多家会计师事务所共同构建了 Tax AI,以帮助处理日益复杂的纳税申报。Tax AI 不依赖工程师来发现和修复每个故障,而是利用 Codex 将生产使用转化为结构化信号,从而驱动自主改进。

Crete 的从业者每个季度要准备数万份纳税申报,这需要处理数百万份底层文档。对于中高复杂度的申报,仅数据录入每份就需要八小时,通常涉及杂乱的数据源、往年文档以及手动提取和计算。他们指出,在报税季最繁忙的时期,税务准备是一个重大瓶颈。

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

可衡量的自我改进

在 Tax AI 中,从业者上传源文件以及任何客户特定的备注。然后 Tax AI 创建一份可供审核的税务引擎提交。它能为从业者节省约三分之一的税务准备时间,以高达 97% 的准确率起草申报,并将吞吐量提高约 50%,从而为他们创造更多与客户相处的时间。

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

早期,Tax AI 处理较简单的工作,如 W-2 和 1099。随着报税季推进,它转向更复杂的申报,涉及 K-1、附表以及更难的边缘案例。每项新能力比前一项节省更多时间,因为它承担的任务更难、手动操作更耗时。我们今天仍能看到持续的进展。

接下来,我们将介绍我们的团队如何通过三个关键支柱共同设计 Tax AI 以实现自我改进:1) 专家从业者反馈,2) 生产轨迹(从输入到最终输出的结构化历史),以及 3) 基于定制 eval 的 Codex 驱动迭代循环,以实现持续、更快的产品开发。我们希望我们的经验能对其他领域的构建者有所帮助,在这些领域中,从业者专业知识对于塑造整体系统及其运行数据的质量至关重要。

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

问题

当我们推进到税务准备中更困难的部分(K-1、租赁房地产附表,以及需要在多个源文件之间对账的税表)时,很明显真正的挑战在于产品能否让复杂的生产故障变得可见、可理解且可操作。

在产品早期,大部分修正都是手动的。从业者可以纠正系统错误,但产品并未捕获完整的上下文:申报前更改的值可能反映真正的提取遗漏、映射问题、产品支持缺失或预期的工作流噪声。区分这些情况仍需工程团队跟进。工程师可以使用编码 agent,但系统尚未设计为在改进循环中有意义地使用 AI。我们没有信号来确定正确的改进方向。

我们的方法:三部分循环

这促使我们围绕三个支柱设计系统:

  1. 贴近从业者: 实际工作的人需要引导产品学习的内容。他们的直觉和理解揭示了哪些错误重要,并有助于告知工作流的哪些部分值得下一步关注。
  2. 构建产品,使生产产生证据: 产品必须捕获的不仅仅是输入和输出;它需要捕获从源材料到提取字段及其出处,再到下游提交和专家修正的完整路径。
  3. 创建 Codex 驱动的改进循环: 一旦生产问题变得可见且结构化,它们就可以转化为发现、定制 eval 和范围明确的工程任务。然后 Codex 可以帮助调查、提出更改、针对目标 eval 和回归 eval 进行验证,并比纯手动迭代周期更快地推进产品。

下面的租赁房产示例展示了该循环在实践中如何运作,引导您了解从业者修正如何成为结构化发现,然后成为 eval 目标,最后成为 Codex 范围的工程任务。

租赁房产示例

租赁房产收入在个人纳税申报的 Schedule E 中报告。从工程角度来看,提取它的任务描述起来简单,但做好却很难。系统必须读取杂乱的源材料(手写笔记、电子邮件、电子表格和其他客户文件),提取系统可以自信地映射到税务引擎的租赁房产字段,并保留足够的证据,以便从业者可以批准或修正结果。下面的简化示例展示了这些源文件和提取输出可能的样子。

租赁房产源包被规范化为带引用的字段,然后映射到下游税务引擎概念。

1. 从业者修正揭示故障

agent 预测值与已提交纳税申报中的实际值之间的差异可能反映真正的提取遗漏,但也可能是从业者的偏好、税务引擎中从往年申报结转的值,或在申报工作流中其他地方引入或更改的值。从业者帮助我们辨别这些情况,以便我们识别哪些操作需要从业者修正或阻止了提交。

由于我们可以详细查看这些修正,我们将审查过程从终端的事后故障步骤转变为持续的学习循环。我们设计了工作流,将专家操作捕获为结构化数据。现在,每次干预都通过准确记录 Tax AI 提议的内容、从业者修改的内容以及最终进入已提交申报的内容,来反馈到产品的改进循环中。

2. 产品轨迹将修正转化为 eval

对于像租赁房产这样的复杂工作流,系统必须保留源文件和已提交申报之间发生的情况。在此路径上,文档被组织、拆分和分类;租赁房产字段被提取并附带指向源材料的引用;这些值被映射到税务引擎中;从业者可能在提交前仍然修正它们。这些产品级别的轨迹使得调查故障发生的位置成为可能。为了将从业者修正转化为有用的评估目标,系统通过三个步骤处理它们:

租赁房产审查行将重复的产品故障与预期噪声分开,然后将可操作的情况转化为评估目标,为 Codex 提供改进方向。

3. 发现成为 Codex 的改进方向

第三个支柱是创建一个能够对这些新 eval 采取行动的工程循环。这就是 Codex 成为核心的地方。

假设我们的 eval 管道标记出 Tax AI 始终遗漏“公平租赁天数”字段,而从业者可靠地填写它。由于此发现已被打包成一个有针对性的 eval 集,包含代表性的源包和预期输出,Codex 可以直接在产品框架内调查根本原因。

Codex 并非仅处理次优的最终输出。它同时检查轨迹、eval、仓库和技能:

端到端的自我改进循环:生产轨迹揭示重复的字段级修正,这些修正成为故障信号,Codex 可以结合轨迹、eval、仓库和技能进行检查。可操作的模式成为有边界的 eval 和候选产品更改;不明确的案例路由回工程师进行审查。每个已交付的改进为下一个循环创造新的生产证据。

如何使用 Codex 构建此循环

租赁房产示例代表了一种更广泛的可重用模式:利用生产工件和轨迹来改进 agent 的能力。给定来自生产数据的经过审查的发现、源轨迹、预期的税务引擎输出、相关代码示例和 eval 命令作为一组输入,Codex 可以在数周和数月内显著提高性能和准确性。这建立在我们关于harness engineeringSymphony 工作中描述的原则之上,这些工作介绍了如何使任务对 Codex 可读、提供范围明确的上下文和工具,并将验证和人工审查作为环境的一部分。

这些证据不会自动成为 Codex 任务。从业者修正可能反映提取遗漏、映射问题、不支持的产品行为、税务判断或预期的工作流噪声。只有在重复的差异经过审查并分组为可操作的发现后,系统才会将它们转化为具有明确成功条件的边界任务。

我们将这种自动化应用于产品的一个有边界层。该层执行提取并将源文档映射到税务工作流。工程师仍然负责架构、产品决策和发布。从业者通过他们已经在做的工作来引导改进循环:修正提取的值、审查申报和批准最终提交。

对于 Codex 来说,结果不是一个模糊的警报,而是一个范围明确的工程任务,包含证据、可编辑的产品表面和明确的验证门。一个代表性租赁房产任务的上下文可以总结如下:

一个有边界的 Codex 任务环境将可写的工作树 [1] 与只读的生产上下文 [5] 分开。工作树包含 Codex 可以检查或修改的范围明确的产品表面 [2]、定义成功的目标 eval 和回归 eval [3],以及编码如何运行任务并尊重先前决策的可重用技能/文档 [4]。只读上下文提供生产轨迹、源文档、Tax AI 预测、最终确定的申报和税务引擎字段文档,以便 Codex 可以调查故障而不改变底层证据。

扩展到新领域

同样的循环也适用于租赁房产之外。租赁房产大约花了六周时间和大量的工程监督才达到 90% 的精确率和召回率,但这项工作产生了可重用的抽象、审查工件、eval 约定和实现模式,使得支持类似复杂的附表(如 Schedule C 和 Schedule A)变得更加容易。

Tax AI 证明了构建自我改进 agent 的路径。从业者通过提供服务产生高价值的反馈信号。产品工作流将这些信号保存为结构化证据。基于 eval 的工程系统在改进进入生产之前对其进行验证,而 agent 驱动的循环使系统保持持续的自我改进流程。

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

一位去年在税务准备上花费了 180 小时的高级会计师,今年只花了 15 小时。她将这部分时间用于给每位客户打电话,向他们解释申报内容,这是一年前无法实现的高接触服务水平。其余时间她用来接纳新客户并扩展新的服务产品。

现在,我们的团队正在将 Tax AI 的相同三部分设计作为蓝图,在 Thrive Holdings⁠(opens in a new window) 的其他领域构建工作流;例如记账和审计等会计工作流,以及 IT 帮助台自动化等运营工作流。跨领域和行业,自我改进 agent 的更广泛前景是成立的。最好的 agent 由人引导,随着时间的推移学会变得更有能力、更值得信赖、更有价值。

要了解有关参与此项目的 OpenAI 团队的更多信息,请联系我们

译自 OpenAI · 官方博客 · 录于 二〇二六年五月二十七日