中文内容
- 可衡量的自我改进
- 问题
- 我们的方法:一个由三部分组成的循环
- 出租物业示例
- 1. 从业者的纠正揭示了一个失败点
- 2. 产品轨迹将纠正转化为评估
- 3. 这一发现成为 Codex 需要攻克的难题
- 如何使用 Codex 构建这一循环
- 扩展到新领域
2026年5月27日
Engineering用 Codex 构建自我改进的税务代理
技术团队成员:Aravind Srinivasan 与 Samay Shamdasani(Thrive Holdings),Arthur Fernandes Araujo 与 John de Wasseige(OpenAI)
Thrive Holdings 与 OpenAI 如何通过将从业者专业知识与 Codex 驱动的循环相融合,为 Crete 会计师共同开发 Tax AI
真实世界的系统在生产环境中的表现不同于实验室环境,会以部署前难以预料的方式出现故障。团队往往在上线后才发现这些故障,然后花费数周时间检查边缘案例、调整提示,并将生产反馈转化为持久的产品改进。这一反馈循环是手动且缓慢的,只有在工程师推动时才会改进。但如今,借助精心设计的评估基础设施、对从业者和真实世界环境的直接访问,以及 Codex 的前沿智能体能力,你可以构建能够自我改进的智能体。
在这篇文章中,我们将解析如何使用 Codex 构建这种类型的智能体。在过去六个月里,OpenAI 的前线部署工程师和研究人员与 Thrive Holdings 的工程师协作,为 Crete(在新窗口中打开)旗下由 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)基于定制评估、由 Codex 驱动的迭代循环,以实现持续且更快速的产品开发。我们希望,我们的经验能对其他构建者有所帮助,尤其是在那些从业者专业知识对于塑造整体系统及其所处理数据的质量至关重要的领域。
问题
当我们推进到报税准备中更困难的部分(K-1 表、出租房地产附表,以及需要跨多个源文件核对数值的税务表格)时,一个显而易见的问题是,真正的挑战在于产品能否让复杂的生产故障变得可见、可理解并且可采取行动。
在产品早期,大部分校正都是手动完成的。从业人员可以纠正系统错误,但产品并未捕捉完整的上下文:申报前更改的数值可能反映的是一次真实的提取遗漏、映射问题、缺少产品支持,或预期中的工作流噪声。梳理这些情况仍然需要工程团队跟进。工程师可以使用编码代理,但系统当时尚未被设计为在改进循环中有意义地使用 AI。我们没有足够的信号来识别正确的攻坚方向。
我们的方法:一个由三部分组成的循环
这促使我们围绕三大支柱来设计系统:
- 贴近从业人员:实际执行工作的人需要引导产品学习的方向。他们的直觉和理解揭示了哪些错误重要,并帮助判断接下来工作流中哪些部分值得重点关注。
- 构建产品,使生产过程能够生成证据:产品不能只捕获输入和输出;它需要捕获从源材料、提取字段和出处,到下游提交和专家纠正的完整路径。
- 创建由 Codex 驱动的改进循环:一旦生产问题变得可见且结构化,它们就可以转化为发现、定制化评测和范围明确的工程任务。随后,Codex 可以帮助调查、提出变更、针对目标评测和回归评测进行验证,并推动产品以比纯手动迭代周期更快的速度向前发展。
下面的出租房产示例展示了该循环在实践中如何运作,带你了解从从业者纠正如何转化为结构化发现,再转化为评测目标,最后成为由 Codex 界定范围的工程任务。
出租房产示例
租赁房产收入在个人所得税申报表的 Schedule E 中申报。从工程角度看,提取这类收入的任务描述起来很简单,但要做好却很难。系统必须读取杂乱的源材料(手写笔记、电子邮件、电子表格以及其他客户文件),提取系统能够有把握地映射到税务引擎的租赁房产字段,并保留足够的证据,以便从业人员能够批准或更正结果。下面的简化示例展示了这些源文件和提取输出可能是什么样子。
1. 从业人员更正揭示了一项失败
代理预测值与已提交纳税申报表中的实际值之间的差异,可能反映了真实的提取遗漏,但也可能是从业人员偏好、税务引擎中从上一年申报表结转的数值,或是在申报工作流的其他环节引入或更改的数值。从业人员帮助我们辨别这些情况,使我们能够确定哪些操作需要从业人员更正,或会阻止提交。
由于我们能够详细看到这些更正,我们将审核流程从一个终端式、失败后的步骤转变为一个持续学习循环。我们设计了该工作流,将专家操作捕获为结构化数据。现在,每一次干预都会通过精确记录 Tax AI 提出了什么、从业人员修改了什么,以及最终进入已申报税表的内容,反馈到产品的改进循环中。
2. 产品轨迹将更正转化为评估
对于像出租房产这样复杂的工作流,系统必须保留从源文件到已申报税表之间发生的情况。在这一路径上,文档会被整理、拆分和分类;出租房产字段会被提取,并附带指向源材料的引用;这些值会映射到税务引擎中;而从业人员在申报前仍可能对其进行更正。这些产品级轨迹使得调查故障发生位置成为可能。为了将从业人员的更正转化为有用的评估目标,系统分三步处理这些更正:
- 捕获差异:将 Tax AI 的输出与已申报税表进行比较,生成字段级审核行,用于捕获预期值、预测值,以及差异是否看起来具有可操作性。
- 对相关失败进行分组:将相似的审核行分组,以区分反复出现的产品失败和预期的工作流噪声。例如,反复出现的从业人员更正可能表明 Tax AI 经常漏掉公平出租天数字段、错误处理“其他费用”,或混淆同一来源资料包中的多处出租物业。
- 将重复模式转化为评估目标:一旦经过审核和衡量,重复出现的发现就会成为 Codex 明确的改进评估目标。
3. 该发现成为 Codex 需要攻克的难题
第三大支柱是创建一个能够针对这些新评测采取行动的工程闭环。这正是 Codex 变得关键的地方。
假设我们的评测流水线标记出 Tax AI 持续遗漏“公平出租天数”字段,而从业者会可靠地填写该字段。由于这一发现已经被打包成一个有针对性的评测集,包含具有代表性的源材料包和预期输出,Codex 可以直接在产品脚手架内调查根本原因。
Codex 并不是只处理一个低于标准的最终输出。它会结合检查 trace、eval、repo 和 skills:
- 调查流水线:检查源材料包、抽取 schema、映射器行为和代码路径,以确定问题是不受支持的字段、遗漏的抽取模式、源选择问题、映射器缺口,还是评分器问题。
- 实施有针对性的修复:扩展提取架构,改进租赁房产文档的来源选择,更新税务引擎映射器,或者在预期的工作流噪声被计为失败时优化评分器。
- 验证并提出方案:重新运行有针对性的评估,运行更广泛的回归测试套件,并提交候选拉取请求供工程团队审查。
- 闭环处理:将反复出现的从业者纠正转化为可衡量的工程任务。如果证据不明确或无法安全地自动化处理,该案例会转回产品团队,而不是被强行纳入闭环。
如何使用 Codex 构建这一循环
租赁房产示例体现了一种更广泛的可复用模式:利用生产工件和轨迹来提升智能体的能力。给定来自生产数据的已审查发现、源轨迹、预期的税务引擎输出、相关代码示例以及评估命令作为一组输入,Codex 可以在数周和数月内显著提升性能和准确性。这建立在我们关于 harness engineering 和 Symphony 的工作中所描述的原则之上,这些工作逐步说明了如何让任务对 Codex 清晰可理解,提供有范围限定的上下文和工具,并将验证与人工审查保留为环境的一部分。
这些证据不会自动成为 Codex 任务。执业人员的纠正可能反映的是提取遗漏、映射问题、不受支持的产品行为、税务判断,或预期的工作流噪声。只有在反复出现的差异经过审查并归类为可执行发现之后,系统才会将其转化为具有明确成功条件的有界任务。
我们将这种自动化应用于产品中一个有界层。该层执行提取,并将源文档映射到税务工作流中。工程师仍然负责架构、产品决策和发布。执业人员通过他们已经在做的工作来引导改进循环:纠正提取值、审查申报表,并批准最终申报。
对于 Codex,结果不是一个模糊的警报,而是一个有范围界定的工程任务,包含证据、可编辑的产品界面以及明确的验证关口。一个具有代表性的出租房产任务的上下文可概括如下:
纯文本
1/candidates/FIND-RENTAL-0042/2│3├── repo/ [1]4│ └── branch: codex/fix-rental-00425│ │6│ ├── AGENTS.md7│ │8│ ├── tasks/FIND-RENTAL-0042/9│ │ ├── task.yaml10│ │ ├── EXEC_PLAN.md11│ │ └── RESULTS.md12│ │13│ ├── app/tax-ai/rental-income/ [2]14│ │ ├── agent.ts15│ │ ├── schema.ts16│ │ ├── provenance.ts17│ │ └── mapper.ts18│ │19│ ├── evals/ [3]20│ │ ├── datasets/fair-rental-days.yaml21│ │ ├── suites/fair-rental-days.yaml22│ │ ├── suites/rental-income-regression.yaml23│ │ └── graders/rental-income.yaml24│ │25│ ├── skills/ [4]26│ │ ├── eval-runner/27│ │ └── tax-field-docs/28│ │29│ └── docs/ [4]30│ ├── architecture/31│ └── task-environments/32│33└── scoped-tools/ [5]34 ├── production-trace35 ├── source-artifacts36 └── tax-engine-docs
一个有边界的 Codex 任务环境将可写工作树 [1] 与只读生产上下文 [5] 分离开来。工作树包含 Codex 可以检查或修改的限定范围产品界面 [2]、定义成功标准的目标评估和回归评估 [3],以及可复用的技能/文档,用于编码如何运行任务并遵循此前的决策 [4]。只读上下文提供生产追踪、源文档、Tax AI 预测、已最终确定的申报表以及税务引擎字段文档,因此 Codex 可以调查故障,而不会更改底层证据。
扩展到新领域
同样的循环也适用于出租物业以外的领域。出租物业用了大约六周时间,并需要大量工程监督,才达到 90% 的精确率和召回率,但这项工作产出了可复用的抽象、审核产物、评估规范和实现模式,使支持同样复杂的税表(如 Schedule C 和 Schedule A)变得更加容易。
Tax AI 证明了一条构建自我改进型智能体的路径。从业者在交付服务的过程中生成高价值反馈信号。产品工作流将这些信号保留为结构化证据。由评估支撑的工程系统会在改进进入生产环境之前对其进行验证,而由智能体驱动的循环使系统保持在持续自我改进的流程中。
Thrive Holdings 的架构使我们能够在特定行业中复制这种环境。Holdings 既是所有者也是运营者,因此我们的联合工程团队能够直接与从业者合作,并接触 Crete 等企业内部的生产数据;我们不是作为供应商,而是作为合作伙伴。这意味着技术、产品和服务都位于同一个体系之下,帮助我们更快推进并打造卓越产品。
一位资深会计师去年花了 180 个小时准备税务工作,而今年只花了 15 个小时。她把节省下来的部分时间用于给每一位客户打电话,并逐步向他们讲解其纳税申报表,提供这种一年前还无法实现的高接触度服务。其余时间则用于接手新客户,并拓展新的服务项目。
我们的团队现在正共同将 Tax AI 的同一套三段式设计作为蓝图,用于在 Thrive Holdings (在新窗口中打开)旗下其他领域构建工作流;包括记账和审计等会计工作流,以及 IT 服务台自动化等运营工作流。跨越不同领域和行业,自我改进型智能体的更广泛前景依然成立。最优秀的智能体由人来引导学习,随着时间推移变得更有能力、更可信、更有价值。
要了解更多参与该项目的 OpenAI 团队信息,请联系。
- 正文:2026
- 正文:Codex
作者














