原文: English original · Anthropic/OpenAI 官方

Thrive Holdings 和 OpenAI 如何为 Crete 会计师共同开发 Tax AI：把一线从业者的专业知识，与 Codex 驱动的迭代循环结合起来。

真实世界的系统在生产环境中的表现，往往不同于实验室里的表现。它们会以部署前很难预见的方式出错。团队通常要等到发布之后才发现这些失败，然后再花数周检查边缘案例、调整 prompt，并把生产反馈转化为持久的产品改进。这个反馈循环既手动又缓慢，而且只有工程师主动推动时才会前进。

但今天，只要有经过周密设计的评测基础设施、能够直接接触从业者和真实环境，再加上 Codex 的前沿 agentic 能力，我们就可以构建会自我改进的 agents。

在本文中，我们会拆解自己如何用 Codex 构建这类 agent。在过去六个月里，OpenAI 的 forward deployed engineers（前线部署工程师）和研究人员，与 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、schedules 和更难边缘案例的复杂申报。每一项新能力节省的单份申报时间都高于上一项，因为它接手的任务更难，也更耗费人工时间。直到今天，我们仍在看到持续进展。

接下来，我们会介绍双方团队如何依托三个关键支柱，把 Tax AI 共同工程化为一个可自我改进的系统：1）专家从业者反馈；2）生产 trace，也就是从输入到最终输出的结构化历史；3）一个由 Codex 驱动、基于定制评测的迭代循环，用来支持持续且更快的产品开发。

我们希望，在那些从业者专业知识对整体系统质量及其处理数据至关重要的领域，我们的经验能对其他构建者有所帮助。

图片：随着 Tax AI 扩展到更复杂的申报，达到 75%、90% 和完全填写正确水平的已评分申报占比，在整个报税季持续上升。

问题

当我们推进到税务准备中更难的部分时，例如 K-1、出租房地产 schedules，以及需要在多个源文件之间核对数值的税表，一个事实变得很明显：真正的挑战在于，产品能否让复杂的生产失败变得可见、可理解、可行动。

在产品早期，大多数更正都是手动完成的。从业者可以更正系统错误，但产品没有捕获完整上下文：申报前某个值被修改，可能反映的是真正的提取遗漏、映射问题、缺少产品支持，也可能只是预期内的 workflow 噪声。要理清这些情况，仍然需要工程团队跟进。工程师可以使用 coding agents，但系统尚未被设计成能在改进循环中有意义地使用 AI。

我们没有足够的信号来识别真正值得攻克的目标。

我们的方法：一个三段式循环

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

  1. 贴近从业者：真正做这项工作的人，需要引导产品学习什么。他们的直觉和理解能揭示哪些错误重要，并帮助判断 workflow 中接下来哪些部分值得聚焦。
  2. 把产品构建成能让生产创造证据的系统：产品必须捕获的不只是输入和输出；它需要捕获从源材料，到提取出的字段及其出处，再到下游提交和专家更正的完整路径。
  3. 创建由 Codex 驱动的改进循环：一旦生产问题变得可见且结构化，它们就可以变成发现、定制评测和有边界的工程任务。随后，Codex 可以帮助调查、提出变更、用定向评测和回归评测验证这些变更，并推动产品以快于纯手动迭代周期的速度前进。

下面的出租物业示例展示了这个循环在实践中如何运转：它会带你了解一次从业者更正如何成为结构化发现，随后成为评测目标，最终成为一个由 Codex 界定范围的工程任务。

出租物业示例

出租物业收入会在个人纳税申报表的 Schedule E 上报告。从工程角度看，提取这类信息的任务描述起来很简单，但要做好很难。系统必须读取混乱的源材料，包括手写笔记、电子邮件、电子表格和其他客户文件；提取系统能够有信心映射到税务引擎的出租物业字段；并保留足够证据，让从业者可以批准或更正结果。

下面的简化示例展示了这些源文件和提取输出可能是什么样子。

图片：出租物业源文件包会先被规范化为带引用的字段，然后再映射到下游税务引擎概念。

1. 一次从业者更正揭示了失败

agent 预测值与已提交纳税申报表中的实际值之间的差异，可能反映真正的提取遗漏，但也可能是从业者偏好、税务引擎中从往年申报表结转的值，或是在申报 workflow 其他环节引入或修改的值。从业者帮助我们辨别这些情况，这样我们就能识别哪些动作需要从业者更正，或者会阻塞提交。

因为我们能够详细看到这些更正，所以我们把审阅过程从一个终结性的失败后步骤，转变成一个持续学习循环。我们设计了 workflow，将专家操作捕获为结构化数据。现在，每一次干预都会准确记录 Tax AI 提出了什么、从业者修改了什么，以及最终进入已提交申报表的是什么，并把这些信息反馈进产品的改进循环。

2. 产品 trace 将更正转化为评测

对于出租物业这样的复杂 workflow，系统必须保留源文件和已提交申报表之间发生了什么。沿着这条路径，文档会被组织、拆分和分类；出租物业字段会被提取，并带有指向源材料的引用；这些值会被映射到税务引擎；而从业者在申报前仍可能更正它们。这些产品级 trace 让我们能够调查失败发生在哪里。

为了把从业者更正转化为有用的评测目标，系统分三步处理它们：

  • 捕获差异：将 Tax AI 的输出与已提交申报表比较，生成字段级审阅行，用来捕获期望值、预测值，以及该差异看起来是否可行动。
  • 分组相关失败：相似的审阅行会被分组，以便将反复出现的产品失败与预期内的 workflow 噪声区分开来。例如，重复的从业者更正可能表明 Tax AI 经常遗漏 fair-rental-day 字段、错误处理“other expenses”，或在同一个源文件包中混淆多个出租物业。
  • 将重复模式转化为评测目标：一旦经过审阅和衡量，重复发现就会成为清晰的评测目标，供 Codex 改进。

图片：出租物业审阅行会将反复出现的产品失败与预期噪声分开，然后把可行动案例转化为评测目标，让 Codex 有一个明确的攻关目标。

3. 发现成为 Codex 的攻关目标

第三个支柱，是创建一个能够对这些新评测采取行动的工程循环。这正是 Codex 变得关键的地方。

假设我们的评测 pipeline 标记出 Tax AI 持续遗漏 “fair rental days” 字段，而从业者会稳定补上它。因为这个发现已经被打包成一个定向评测集，包含有代表性的源文件包和期望输出，Codex 就可以直接在产品 scaffold 内调查根因。

Codex 并不是只面对一个较差的最终输出。它会把 trace、评测、repo 和 skills 放在一起检查：

  • 调查 pipeline：检查源文件包、提取模式、mapper 行为和代码路径，以判断问题是不支持的字段、遗漏的提取模式、源选择问题、mapper 缺口，还是 grader 问题。
  • 实施定向修复：扩展提取模式、改进出租物业文档的源选择、更新税务引擎 mapper，或者在预期内的 workflow 噪声被计为失败时细化 grader。
  • 验证并提出方案：重新运行定向评测，运行更广泛的回归套件，并提出一个候选 pull request，供工程团队审阅。
  • 闭合循环：把一次反复出现的从业者更正转化为可衡量的工程任务。如果证据含糊，或者无法安全自动化，这个案例会被路由回产品团队，而不是被强行推进循环。

图片：端到端的自我改进循环。生产 trace 浮现出重复的字段级更正，这些更正会成为失败信号，让 Codex 能与 trace、评测、repo 和 skills 一起检查。可行动模式会成为有边界的评测和候选产品变更；含糊案例则路由回工程师审阅。每一次已发布的改进都会为下一个周期创造新的生产证据。

如何使用 Codex 构建这个循环

出租物业示例代表了一种更广泛、可复用的模式：使用生产 artifacts 和 trace 来提升 agent 的能力。给定来自生产数据的已审阅发现、源 trace、期望的税务引擎输出、相关代码示例，以及作为一组输入的评测命令，Codex 可以在数周到数月内实质性提升性能和准确率。

这建立在我们关于 harness engineering 和 Symphony 的工作中描述的原则之上。这些工作介绍了如何让任务对 Codex 可读，如何提供有边界的上下文和工具，以及如何让验证和人工审阅成为环境的一部分。

这些证据不会自动变成 Codex 任务。一次从业者更正可能反映的是提取遗漏、映射问题、不受支持的产品行为、税务判断，或预期内的 workflow 噪声。只有在重复差异经过审阅，并被分组成一个可行动发现之后，系统才会将它们转化为一个有边界、成功条件清晰的任务。

我们把这种自动化应用在产品的一个有边界层。这个层负责执行提取，并将源文档映射到税务 workflow 中。工程师仍然负责架构、产品决策和发布。从业者则通过他们本来就在做的工作来引导改进循环：更正提取值、审阅申报表，以及批准最终申报。

对 Codex 而言，结果不是一个模糊告警，而是一个有证据、有可编辑产品模块、有明确验证关口的有边界工程任务。一个有代表性的出租物业任务上下文可以概括如下：

/candidates/FIND-RENTAL-0042/
│
├── repo/                                                   [1]
│   └── branch: codex/fix-rental-0042
│       │
│       ├── AGENTS.md
│       │
│       ├── tasks/FIND-RENTAL-0042/
│       │   ├── task.yaml
│       │   ├── EXEC_PLAN.md
│       │   └── RESULTS.md
│       │
│       ├── app/tax-ai/rental-income/                          [2]
│       │   ├── agent.ts
│       │   ├── schema.ts
│       │   ├── provenance.ts
│       │   └── mapper.ts
│       │
│       ├── evals/                                          [3]
│       │   ├── datasets/fair-rental-days.yaml
│       │   ├── suites/fair-rental-days.yaml
│       │   ├── suites/rental-income-regression.yaml
│       │   └── graders/rental-income.yaml
│       │
│       ├── skills/                                         [4]
│       │   ├── eval-runner/
│       │   └── tax-field-docs/
│       │
│       └── docs/                                           [4]
│           ├── architecture/
│           └── task-environments/
│
└── scoped-tools/                                           [5]
    ├── production-trace
    ├── source-artifacts
    └── tax-engine-docs

一个有边界的 Codex 任务环境，会把可写 worktree [1] 与只读生产上下文 [5] 分开。worktree 包含 Codex 可以检查或修改的有边界产品模块 [2]、定义成功标准的定向评测和回归评测 [3]，以及编码了如何运行任务、如何尊重既有决策的可复用 skills/docs [4]。

只读上下文提供生产 trace、源文档、Tax AI 预测、最终申报表，以及税务引擎字段文档，这样 Codex 就可以在不改变底层证据的情况下调查失败。

扩展到新领域

同一个循环也适用于出租物业之外的场景。出租物业大约用了六周时间，并需要大量工程监督，才达到 90% precision 和 recall；但这项工作产出了可复用的抽象、审阅 artifacts、评测约定和实现模式，使支持 Schedule C 和 Schedule A 等类似复杂 schedules 变得更容易。

Tax AI 证明了一条构建自我改进 agents 的路径。从业者通过交付服务生成高价值反馈信号。产品 workflow 将这些信号保留为结构化证据。由评测支撑的工程系统会在改进进入生产前验证它们，而由 agent 驱动的循环则让系统保持持续自我改进。

Thrive Holdings 的结构让我们能够在特定行业复制这种环境。它既持有企业，也运营企业，因此我们的联合工程团队能够直接与 Crete 这类企业内部的从业者和生产数据合作；我们不是以供应商身份进入，而是作为伙伴共同工作。这意味着技术、产品和服务都在同一屋檐下，帮助我们更快行动，并构建卓越产品。

一位去年花了 180 小时做税务准备的高级会计师，今年只花了 15 小时。她把节省出的一部分时间用于给每一位客户打电话，并带他们逐项了解自己的申报表。这种高接触度服务在一年前还无法实现。剩余时间则被她用来承接新客户，并扩展到新的服务项目。

现在，我们的团队正在把 Tax AI 中同样的三段式设计作为蓝图，用于构建 Thrive Holdings 旗下其他领域的 workflow：包括记账和审计等会计 workflow，以及 IT help desk 自动化等运营 workflow。跨越不同领域和行业，自我改进 agents 的更广泛前景依然成立。

最好的 agents 是由人引导的，它们会随着时间推移学会变得更有能力、更值得信任，也更有价值。

如需了解更多参与该项目的 OpenAI 团队信息，请联系我们。

作者

Aravind Srinivasan、Samay Shamdasani、Arthur Fernandes Araujo、John de Wasseige