工具呼叫、狀態儲存和審批恢復各有職責；把它們接起來，業務團隊才能知道誰批准了什麼、重試是否會重複執行。
OpenAI Agents SDK 提供了構建 Agent 應用的執行機制：模型接收指令，選擇工具，多輪執行，必要時把任務交給另一個 Agent，並保留追蹤記錄。對準備把 Agent 用進業務系統的團隊，關鍵選擇並不只是“用什麼框架”，還包括哪些動作可以自動繼續、哪些動作必須暫停，以及中斷後由誰恢復。
官方入門文件將 Agents、工具、交接和 guardrails 作為核心組成，也提供 sessions、tracing、沙箱和人工介入機制。SDK 是可程式設計的執行基礎；真正進入業務流程時，團隊需要把這些能力接到自己的身份、許可權、持久化和目標系統上。
先決定是否需要 SDK 管理執行迴圈
直接呼叫 Responses API，適合由應用自己控制模型迴圈、工具排程和狀態的情況。Agents SDK 則適合希望執行時管理多輪執行、工具呼叫、交接或會話的應用。兩條路徑可以在同一個產品裡共存，無需把所有請求一次性遷移。
這項選擇首先取決於團隊希望維護什麼。只有短暫回答的功能，未必需要複雜編排；會跨多個步驟、使用真實檔案或生成產物的任務，則更需要明確的執行狀態與恢復機制。開發框架可以降低重複實現的成本，但任務的業務終點仍要由應用定義。
例如，“工具返回成功”和“業務記錄已按預期更新”並非同一件事。前者是一次呼叫結果，後者需要目標系統的確認。把兩者寫成同一個完成標記，會讓後續的重試和稽核變得含混。
三種機制，各自回答不同問題
工具定義決定 Agent 可以呼叫什麼；guardrails 用於檢查輸入、輸出或相關約束；審批決定某次敏感動作是否獲得允許。三者應分別配置。
官方人工介入指南允許工具宣告需要審批。符合條件的呼叫會以 interruption 暴露，應用把執行轉為 RunState，取得批准或拒絕後再恢復。這個機制可以覆蓋交接後的工具，也可以覆蓋巢狀 Agent 工具內部產生的審批。
只在提示詞寫“傳送前詢問”，並不等於工具呼叫在執行層被阻斷。需要審批的動作，應在工具或執行策略中配置實際暫停條件，再由應用處理待審請求。與此同時，透過引數校驗也不意味著業務負責人已經同意。
稽核介面展示請求，可信狀態留在服務端
當任務暫停，稽核者需要看見動作物件、工具引數、預期影響和相關依據。完整執行快照可能包含執行狀態、待處理呼叫和敏感引數，適合留在應用控制的服務端儲存中。
官方指南特別指出，RunState 的反序列化不會替應用驗證提交者身份。收到一份格式正確的狀態，不等於它來自有權批准的人。服務端應驗證稽核者身份，確認其有權處理當前執行，再把提交的決定與服務端儲存的待審呼叫對應起來。
瀏覽器可以傳回決定和請求標識，不能讓瀏覽器替換工具引數或整份執行狀態。顯示工具名和引數時，也要當作待轉義內容處理。這樣，介面負責表達決定，執行時負責恢復執行，身份與許可權仍由應用控制。
多個人同時開啟同一請求時，還要避免重複消費。一個人已經批准並開始恢復後，另一箇舊頁面不應再次恢復同一份快照。需要的是儲存層能確認歸屬和當前狀態的原子轉換，而不是僅把按鈕變灰。
批准一次，不等於只執行一次
最容易漏掉的故障發生在外部動作已經完成、最新執行狀態尚未儲存的時候。程序此時中斷，如果從較舊的已批准快照恢復，工具可能再次呼叫。
官方文件明確區分審批與 exactly-once 執行。對付款、傳送訊息或業務寫入，應給邏輯動作一個穩定的冪等鍵，並讓目標端按其契約防止重複效果。重試時複用同一個鍵和相同引數，同時注意目標端的保留期限。
如果目標系統沒有可靠的冪等機制，恢復前先核對實際結果。普通查詢未返回結果，不一定說明上次沒有執行：結果可能延遲可見，舊請求也可能仍在執行。無法判定時應保留未知狀態，交給有權的人處理，而不是自動重放。
這也決定了稽核頁面需要展示什麼。除了“已批准”，還需要“是否已呼叫”“目標端是否確認”“結果是否確定”。把決定和執行結果分開，運營人員才知道下一步該補證還是重試。
長期批准要匹配許可權邊界
SDK 支援針對單次呼叫的決定，也支援在執行狀態中保留後續同類工具的持續批准。持續批准可以減少重複互動，卻需要理解匹配範圍。
官方指南指出，本地 shell 和檔案編輯工具的持續決定按工具型別和名稱匹配，未必按擁有它的 Agent 隔離。在不同執行器許可權不一致時，應優先使用逐次決定，並在新的許可權環境中使用新的審批上下文。不能因為兩個工具名稱相同，就預設它們有相同的訪問範圍。
長期等待的審批還應記錄 SDK 或 Agent 定義版本。恢復發生時，舊快照需要能夠進入匹配的程式碼路徑；否則，模型配置或工具定義變化可能讓原請求失去原來的含義。
從開發機制走向團隊交付
可以用 Buda 搭建圍繞真實資料和成果稽核的工作流程：先在 Agent 中準備檔案、約束和輸出要求，執行後檢查實際產物，再授權下一步動作。工作空間和 Drive 與記憶承接資料和持續上下文。是否採用 SDK 自建應用，應由產品需要控制的執行機制與團隊維護能力決定。
如果要自行開發稽核服務，先做一條能完整走通的路徑：待審工具呼叫進入服務端儲存；有許可權的人批准或拒絕；原執行恢復；目標系統回傳結果；結果再寫回同一任務。最後檢查程序中斷、重複提交和拒絕後的分支。一個漂亮的批准按鈕，只是這條路徑中的一環。
兩個常見實現決策
tracing 能否替代業務審計？
追蹤有助於除錯執行路徑。業務審計還需要身份、批准範圍、動作引數、目標端結果和最終狀態。把執行追蹤與業務任務關聯起來，保留兩者各自的職責。
每次工具呼叫都要人批准嗎？
按動作影響與既有授權劃分。已授權的低風險讀取可以自動繼續，敏感寫入或外部動作按工具策略暫停。重點是讓規則在執行層生效，並能解釋一次動作為什麼獲得允許。