Teaching Coding Agents to do Spreadsheets - Nuno Campos, Witan Labs

試算表看似簡單，但 AI 處理起來意外困難。根本原因在於視覺化本質的差異。人類打開 Excel 檔案時能直觀識別「這是收入表、那是假設、那是圖表」，完全無需思考；但 LLM 無法看到視覺結構，遇到「找收入」的要求時，必須推理淨收入還是毛收入、涉及哪季哪年、數字是直接輸入還是某個公式的結果。這多層推理需求遠超開發團隊初期預期，也解釋了為何早期準確率只有 50%。

團隊最初嘗試了多代理架構，由中樞編輯代理統籌五步流程：定義終態、規劃、執行、驗證。這個設計改善了錯誤發生的時間點——不再是執行中出錯，而是規劃階段出錯，後者更容易修正。然而實踐中發現此架構過度剛性。發現階段只運行一次，無法重新訪問遺漏的資訊；代理間的資訊各自獨立，無法流通共享；整體上就像一條組件固定的流水線，無法應對實際的複雜情況。

隨後團隊試遍了當時能想到的所有表示法。SQL 理論上很有前景——幾十年的歷史、LLM 訓練資料豐富、代理擅長 SQL——但實踐證明不適用；XML 因為是 Excel 檔案的磁碟格式，也被寄予厚望，結果也失敗；許多其他嘗試亦步亦趨。但這些死胡同並非完全無果，兩個想法在後來的 REPL 內部得到了應用：CSV/TSV 視圖在獨立使用時效果不佳，但作為更大方案的一部分卻被頻繁使用；HTML 引入了版面和格式的概念，啟發了渲染引擎的構建。

最大的突破發生在第五個多月。團隊沒有繼續增加工具，反而將累積的約 15 個工具合併成單一工具——一個 Node.js REPL。所有原先的工具功能轉變為可供代理組合的 JavaScript 函數。為何選 JavaScript？因為它易於沙盒化、LLM 非常熟悉，Python 應該也能工作。而試算表的實際處理仍用 C# 實現——這架構的妙處在於分工清晰，腳本語言用於代理交互，成熟語言用於核心業務。

效果立竿見影。改革前，代理探索一份試算表通常需 10-15 次工具呼叫。由於順序執行，這些呼叫常常超時；即使支援平行工具呼叫，結果也無法組合。改革後，代理在單次呼叫內組合所有操作，同時拿到結果。更妙的是 REPL 提供持久狀態：代理呼叫一次定義變數、看結果、花時間推理、下次呼叫時變數依舊存在。這改變了代理的寫法——它們停止寫 50 行的冗長腳本，轉而寫短小精悍的程式片段，在每段執行後穿插推理。結果是代理更快得到正確答案。

架構還帶來另一個好處：擴展性。發現需要新功能（比如追蹤公式依賴）時，只需在 REPL 內增加方法，透過 TypeScript 類型定義檔通知代理即可。無需修改工具模式、無需協調工具間的交互，工作量大幅下降。

數字說話：準確率從 50% 升至 74%（REPL 導入）。後續的改善幅度較小但持續累積——優化模糊搜尋、新增公式追蹤函數、改進系統提示、修復各類 bug——最終達到 92%。超時問題也幾乎消失，從常見的 5 分鐘超時降至基本零發生。

講者強調了反饋循環的根本重要性。編碼代理之所以表現卓越，是因為能執行編譯器、lint 工具、測試框架後反覆迭代。試算表同樣需要此循環。團隊構建了兩個關鍵引擎：公式引擎計算公式結果，渲染引擎將試算表範圍渲染成圖像（含所有格式與版面）。這形成驗證機制——代理執行修改後，能看到結果確認是否正確，若不正確就修正公式或格式。但這循環的有效性完全取決於引擎的保真度。若引擎只實現了 50% 的 Excel 公式功能，代理會寫出看似可行但實際無法計算的公式，得到錯誤結果或報錯，代理反而被誤導。所以高保真引擎是必須的。

評估本身也經歷了演進。初期用 LLM 當裁判，簡單易行但有缺點：無法判斷準確率變化究竟源於代理進步還是評估者風格改變。團隊隨後引入決定性比較方法。以黃金試算表為基準定義輸入輸出，測試代理生成的試算表是否在同樣輸入下產生相同輸出。此方法更客觀可信。當然，也不是完全放棄 LLM——在無法建立決定性比較的場景中，LLM 評判仍然必要。

最後一個重要發現：基礎設施 bug 常被誤認為推理失敗。代理反覆重試、看起來卡住了，實際可能是工具出錯、提示裡有錯誤範例讓代理忠實遵循、或工具本身故障讓代理不斷嘗試繞過。花時間深入檢視執行追蹤往往能發現真相。