核心概念
2026 年 5 月 27 日，OpenAI、Thrive Holdings 與 Crete Professional Alliance 發布案例研究，揭示如何以 Codex 為核心建構「自改善稅務代理」。系統在數週內將申報稿件的準確率從約 25% 提升至 97%，同時讓一位資深會計師的年度稅務備案工時從 180 小時縮短為 15 小時。
背景與合作架構
- OpenAI 於 2025 年 12 月取得 Thrive Holdings 的股權，正式進入企業財務軟體市場
- Thrive Holdings 負責整合 Codex、設計 eval 基礎設施與從業者回饋迴圈
- Crete Professional Alliance 提供真實生產環境：30+ 家會計師事務所、7,000 份 1040/1041 稅務申報表
自改善迴圈的三大組件
核心是一個閉環的自改善機制（Self-Improvement Loop），而非傳統的人工微調週期：
- 生產軌跡捕捉（Production Traces）：系統持續記錄從業者對每筆申報稿件的現場修正，作為結構化失敗訊號
- 失敗模式分析（Failure Signals → Evals）：Codex 同時讀取追蹤記錄、現有 eval 套件、程式倉庫與 Agent Skills，識別可重現的錯誤模式，並自動生成邊界測試（Bounded Evals）
- 候選修改生成（Candidate Changes）：Codex 依據 evals 提出程式層面的修改建議，通過驗證後自動部署，形成「從觀察到測試再到實現」的閉環
這套設計的關鍵突破：從業者的修正行為本身就是訓練訊號，不需要額外標注或人工整理，大幅降低人力成本與迴圈延遲。
eval 基礎設施設計原則
Thrive 的 eval 基礎設施採用「多維度評分器」策略：
- 確定性檢查：欄位值格式、法規碼對應、計算正確性
- 語義評分（LLM-as-Judge）：申報邏輯合理性、稅務說明的完整性
- 迴歸防護：每次 Codex 提交修改前，自動執行完整 eval 套件，防止改善舊錯誤時引入新問題
人工審核保留在關鍵節點，主要用於捕捉自動評分器遺漏的邊緣案例。
關鍵要點
- 準確率：從試點初期約 25% 提升至數週後的 97%，驅動力是生產修正資料而非人工標注
- 效率提升：每位從業者節省約 1/3 的稅務備案時間；處理吞吐量提升約 50%
- 個人影響：一位資深會計師從 180 小時縮至 15 小時，釋放出的時間用於開發新客戶與深度服務
- 三部件設計（Three-Part Blueprint）：Traces 捕捉 → Eval 轉化 → Codex 實現，正被 Thrive 複製到記帳、審計與 IT 幫助台等其他業務線
- 股權整合模式：OpenAI 直接入股垂直應用公司（Thrive），以股東身份推動深度技術整合，有別於單純 API 授權
可與 財務團隊 × Codex：五大財務文件自動化場景 和 OpenAI × PwC：AI Agent 重塑 CFO 辦公室 對照閱讀，了解 Codex 在財務場景的不同切入方式。
實務應用
Crete Professional Alliance 試點
試點聚焦美國 1040（個人所得稅）與 1041（遺產信託）申報，這兩類稅種規則複雜、欄位繁多，是傳統稅務軟體最難自動化的區域。30 家事務所在同一套系統下運行，產生了足夠密度的跨機構修正資料，加速了 eval 收斂速度。
可複製的工作流程藍圖
Thrive 將同一架構應用於：
- 記帳（Bookkeeping）：對帳分類準確率提升
- 審計（Audit）：異常偵測與底稿初稿生成
- IT 幫助台：工單分類與標準問題自動解答
三個場景共用相同的 Traces → Evals → Codex 框架，說明這套設計具備跨領域複製性。可對照 Codex 安全生產部署：沙盒、審批工作流與可觀測性 了解 Codex 在企業生產環境的安全架構。
對 AI 落地的示範意義
這個案例打破了「AI 代理需要大量人工標注才能達到生產品質」的預設：在有從業者真實操作的場景中，生產資料本身就是最好的訓練訊號。設計問題從「如何收集標注資料」轉變為「如何捕捉並結構化生產修正軌跡」。
延伸觀點
OpenAI 技術食譜文件（Self-Evolving Agents Cookbook）與 Agent Improvement Loop 教學揭示了這套模式的通用架構。兩篇文件共同強調：單一評分指標容易被優化策略「游戲化」，因此 eval 基礎設施需要結合確定性驗證（如計算正確性）與語義評分（LLM-as-judge），才能防止準確率數字失真。
第二個跨來源共識：Codex 在自改善迴圈中的角色不是生成內容，而是實現改善建議。系統的智能在 eval 設計與失敗模式識別，Codex 負責的是最後一哩路——把「已驗證的改善方向」轉化為程式碼變更。這與傳統「AI 寫程式」的框架截然不同：eval 優先，實現在後。
麥肯錫的企業 AI 研究（2025）指出，大多數 AI 試點在真實生產環境中失敗的原因是「無法隨新資料演化」。Thrive 的設計直接回應了這個問題：以生產修正為驅動，eval 套件隨業務資料成長，而非依賴靜態測試集。這與 Agentic AI 企業落地現實：基礎建設障礙與突破策略 描述的落地障礙形成對照。
反向連結
以下頁面引用了本頁：