系統整合 · 實作指南
為代理可呼叫的每個工具訂立合約
用範圍明確的工具介面，將自然語言轉成受限制的操作。
避免萬能操作入口
假設服務台代理只有一個更新系統工具，接受任意網址與內容。初期看來省工，卻把目的地、權限和副作用全部隱藏。建議改成提出請求分派、讀取已批准狀態等業務工具，清楚寫明可接觸哪些紀錄、會產生什麼後果。與其要求模型小心行事，範圍明確的工具更容易測試，也較能讓客戶知道系統實際可以做什麼。
列出執行前必查事項
每個工具記錄必要參數、允許值、身份脈絡、前置條件、逾時與重試行為。未預期欄位應拒絕，不可直接轉交下游 API。公司和呼叫者身份來自已驗證脈絡，不由生成文字指定。結果也要結構化，分清拒絕、無效、暫時失敗與完成。下游錯誤訊息仍是資料，不能因為看似系統回應，就變成要求增加權限的新指令。
流程一覽
用故障清單驗證合約
驗收可測試缺少負責人、越權公司、過時版本、無效狀態值，以及提交後逾時。JSON 格式正確並不等於業務操作有效。以分派工具為例，要檢查目的員工仍屬於該客戶，並有權閱讀相關紀錄。OWASP 授權指引提供每次請求檢查存取的背景；本文把它轉為可執行的測試，讓合約不是文件上的願望。
限制工具也要管理版本
工具含義改變時要管理版本，不只是改欄位名稱才處理。舊隊列任務應有相容執行器，否則清楚標示需要遷移並停止。支援人員要有允許與拒絕操作的例子。工具太碎也會增加維護成本，因此按穩定業務目的分組，而不是每個按鈕都建一個工具。目標是把權限收窄到可理解、可驗證的範圍，而非堆積一份龐大工具目錄。
交付中的工具合約卡
交付時每個工具有一張合約卡，說明用途、允許紀錄、審核人和失敗路徑，技術參數結構與卡片共用版本編號。操作人員便能判斷新用途是否仍在原範圍，還是需要另行審查能力。卡片也應列出明確不做的操作，減少使用者因名稱太廣而誤解；這不是限制銷售，而是讓承諾可被實際系統支持。
來源與延伸閱讀
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。