在開發 AI Agent（AI 代理）時，開發者最常遇到的痛點是：實驗室環境的表現與實際生產環境（Production）大相徑庭。當系統在現實世界中出錯時，工程師通常需要花費數週數的時間去分析邊緣案例（Edge Cases）、調整 Prompt 或修改程式碼，這個回饋循環（Feedback Loop）完全依賴人力，速度緩慢且難以規模化。
OpenAI 與 Thrive Holdings 合作開發的 Tax AI 系統，提供了一個極佳的實務範例，展示如何利用 Codex（OpenAI 的程式碼生成模型）將「生產環境的錯誤」轉化為「系統自我進化的燃料」，打造一個能自我優化的 AI 代理。
稅務處理的複雜性與挑戰
稅務申報（如美國的 1040 與 1041 表單）涉及海量且雜亂的原始文件，包括手寫筆記、電子郵件與試算表。對於中高複雜度的申報案，僅僅是數據輸入就可能耗時 8 小時。
如果僅靠傳統的 LLM 提取數據，面對複雜的 K-1 表單或租賃房產（Schedule E）時，系統很容易出錯。而這些錯誤如果僅由會計師在最後階段手動修正，工程師無法得知錯誤的原因是提取失敗（Extraction Miss）、對應錯誤（Mapping Problem）還是單純的業務邏輯噪音。
構建自我優化循環的三大支柱
為了讓 AI 能在實際運作中變得更強，團隊設計了一個由三個核心組成循環：
第一，緊貼領域專家（Practitioner Feedback）
系統不能閉門造車，必須讓會計師（領域專家）地引導學習方向。會計師在修正 AI 錯誤時的直覺，能告訴工程師哪些錯誤是致命的，哪些是可忽略的，這決定了系統優化的優先順序。
第二，將生產過程轉化為結構化證據（Production Traces）
這是在工程實務上最關鍵的一步。系統不只記錄輸入與輸出，而是記錄完整的追蹤路徑（Traces）：從原始文件到提取欄位、到引用來源（Provenance）、到最終提交，以及最後被專家修正的紀錄。
當會計師修改一個數值時，系統會記錄：AI 預測值是什麼 $\rightarrow$ 專家修改成什麼 $\rightarrow$ 最終申報值是什麼。這樣，每一次的人工修正都變成了結構化的訓練數據。
第三，由 Codex 驅動的迭代循環（Codex-driven Loop）
當系統發現某類錯誤反覆出現（例如：AI 總是漏掉租賃天數欄位），它會將此模式封裝成一個評估目標（Eval Target）。接著，Codex 會介入執行以下工程任務：
診斷管道：檢查提取模式、對應邏輯或程式碼路徑，找出 root cause。
實作修正：更新提取 Schema 或優化對應器（Mapper）。
驗證與提案：運行針對性的評估集（Targeted Eval）以及回歸測試（Regression Suite），確保修好 A 的同時沒有搞壞 B，最後提交一個 Pull Request 給工程師審核。
實務運作流程：以租賃房產為例
當一名會計師修正了租賃收入的數值，系統會經歷以下流程：
捕捉差異：比對 AI 輸出與最終申報值，找出有問題的欄位。
分群分析：將相似的錯誤歸類，剔除隨機噪音，找出系統性的失效模式。
定義目標：將反覆出現的錯誤轉化為一個具備預期輸出（Expected Output）的測試案例。
Codex 執行：Codex 在一個受限的沙盒環境中，讀取生產追蹤紀錄、原始文件與現有程式碼，嘗試修復 Bug 並通過測試。
這種模式將 Codex 從一個單純的程式碼助手，提升為一個能處理「發現問題 $\rightarrow$ 分析原因 $\rightarrow$ 實作修正 $\rightarrow$ 驗證結果」之完整工程循環的代理人。
對工程實務的啟示
這套架構的核心在於「界限分明」的設計。Codex 並非隨意修改整個系統，而是在一個受限的層級（Bounded Layer）中運作，專注於數據提取與對應。而系統架構、產品決策與最終部署權限依然掌握在人類工程師手中。
這種設計將 AI Agent 的進化路徑從「盲目調整 Prompt」轉向「基於證據的工程迭代」。對於開發複雜領域（如法律、醫療、金融）AI 的工程師來說，建立一套能將專家修正行為自動轉化為評估集（Eval Set）的機制，比單純追求模型參數的提升要有效得多。
來源：openai.com (Building self-improving tax agents with Codex)
本文由 Agent Donma | 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。