將 Coding Agent 接入真實商業系統：Foundax 架構實踐

當我們談論在網店或企業軟件中引入 AI Agent 時，最初的設想往往非常直接：將各種業務能力封裝成一系列工具（Tools），讓大語言模型透過 Tool Calling 自動呼叫並完成任務。

然而，真實的商業場景充滿了無法預先列舉的動態需求。以一個常見的商家指令為例：「幫我篩選出庫存充足的商品，補充英文介紹，準備一個週末促銷活動頁面，完成後先讓我審閱，我可能要在畫布上微調文字和樣式。」

面對這類複合需求，單純依賴 Tool Calling 並非無法實現，但在頻繁的往返呼叫（Round-trips）中，上下文佔用、中間資料的搬運與協調成本會急劇上升，極易導致使用者等待過久或模型 Token 預算耗盡。因此，讓 Agent 編寫程式碼，將部分確定性的資料處理與邏輯組合集中在執行環境內完成，成為了我們探索的一條重要路線。

為什麼需要沙箱與程式碼執行？

在早期的探索中，我們發現單純依賴 Tool Calling 難以應付複雜的業務邏輯。當涉及多個 API 的組合或中介資料的處理時，強行依賴模型輸出最終的 API 呼叫序列，往往會導致上下文過載或執行中斷。

參考業界對 Agent 執行環境的實踐（例如 OpenHands 的通用工作環境與 Anthropic 關於 Code Execution 的研究），Foundax 採用了「業務沙箱（Sandbox）」架構。

我們將 Agent 的工作模式從「直接呼叫業務 API」轉變為「在帶有 Shell 和檔案系統的沙箱內編寫腳本」。在這個架構下：

• 平台（Host）的職責： 負責處理身份與授權、提供業務 Schema 和資料視圖（Data Views），並管理執行環境及其最終產物。
• Agent 的職責： 在沙箱內閱讀經過授權的資料，透過編寫程式碼來進行實體關聯、資料篩選與批次運算，最終產生具體的修改提案（Proposal）或頁面原始碼。

這種做法將明確的單一任務交給 Tool Calling，而將複雜的中間資料處理交給 Code Execution。兩者並非互相排斥，而是互補組合。進一步的演進細節，可以參考我們的另一篇文章：我們為什麼讓業務 Agent 像 Coding Agent 一樣工作。

執行成功不等於業務寫入

將 Coding Agent 引入業務系統，最危險的假設是「程式碼跑通了，就可以直接寫入資料庫」。

在 Foundax 的架構中，狀態（State）的變更是嚴格分層的。Agent 在沙箱中執行的腳本產生的是一個「修改提案（Proposal）」，而非直接的資料庫操作。我們將整個工作流拆分為三個獨立階段：

1. 沙箱執行（Execution）： Agent 撰寫腳本並運行，確認邏輯無誤。
2. 用戶確認（User Confirmation）： 商家在介面上預覽結果（例如翻譯好的文案、生成好的網頁）。
3. 業務寫入（Business Write）： 確認後，系統透過原有的業務服務（Business Services）執行真實寫入。

這個分離至關重要。因為在 Agent 生成結果到用戶最終確認的這段時間內，系統的底層資料（例如某個商品的即時庫存或價格）可能已經發生變化。所有的業務寫入都必須在最後一刻，重新校驗當前的權限、版本與約束條件。我們不會因為快照（Snapshot）中的測試執行成功，就繞過業務系統原有的校驗機制。

從原始碼到可視化編輯：狀態的分離與追蹤

當 Agent 生成了前端程式碼（如一個促銷活動頁面），商家的工作並未結束。他們通常需要在生成後，利用畫布（Canvas）持續修改文字和樣式。同時，網店後台的商品資料會不斷更新，Agent 未來也可能再次被喚醒以修改原始碼。

過去，為了讓生成的頁面支持「可拖拽、可點選」的編輯，平台往往會發明一套專用的節點樹、目錄約定或自訂表達式（DSL）。但這會導致內部工程師使用的技術棧與 Agent 生成的產物徹底割裂，維護成本極高。

Foundax 的決策是：復用內部的基礎建設，讓 Agent 直接生成標準的 React 程式碼。

我們不再另立一份脫離原始碼的「可編輯頁面樹」。相反地，平台依靠編譯器來分析普通的 React 程式碼，並在運行時觀測派生出編輯索引（Edit Index）。這意味著：

• 編譯索引和畫布預覽只是原始碼的「派生副產物」。
• 普通的 React 程式碼雖然可運行，但平台編譯器會決定哪些表達式支援可視化反向編輯，並將使用者的畫布操作安全地映射回原始碼。

更重要的是，我們必須在架構上嚴格區分專案狀態（Project State）與業務狀態（Business State）：

• 專案狀態： 包含頁面原始碼、樣式引用、以及受到支援的 UI 實例覆蓋（Instance Overrides）。這些屬於版本化的專案範疇。
• 業務狀態： 商品售價、庫存數量、促銷規則等，屬於業務服務。

當商家在畫布上點擊一個商品卡片並修改其字體顏色時，修改的是 UI 實例（專案狀態）；這絕不等於修改了該商品在資料庫中的真實售價（業務狀態）。專案的修改和業務的變更擁有各自獨立的校驗、提交與復原（Undo/Redo）機制。關於這一部分的編譯器與追蹤演算法設計，詳見：如何讓 AI 生成的前端程式碼支援可視化編輯。

總結：建立清晰的職責邊界

將 Coding Agent 接入商業系統，本質上是一場關於「邊界與授權」的架構設計。

平台不需要、也不應該期望 Agent 能夠完美無瑕地一次性處理所有底層狀態的變更。相反，平台需要承擔起準備資料視圖、維護沙箱環境、校驗版本衝突，以及區分 UI 專案狀態與業務狀態的責任。

只有當基礎設施能夠穩定地處理授權與資料還原，我們才能放心地讓 Coding Agent 在沙箱內發揮其程式碼編寫與邏輯組合的潛力，最終為使用者交付一個既智能又安全、且具備持續可維護性的商業系統。

延伸閱讀

• 由生成網頁到交付業務：設計 Agent 的工作環境