一個工具終於能跑時，我沒有立刻交付。我先故意拿掉一個必填欄位，再把同一筆資料送兩次。
真正花時間的不是把功能做出來，而是確認缺資料會怎樣、同一筆任務重跑會怎樣、外部服務沒回應時又由誰接手。
這個場景讓我想起晶圓良率工作（曾在晶圓研發做良率提升六年半）：設計只是起點，穩定產出必須靠可重複的測試條件。
我想把半導體的測試介面，翻譯成主管能驗收的 Agent 工作環境。
什麼是「Agent 友善介面」？
Agent 友善介面是讓代理程式能在明確權限內讀取輸入、執行動作、取得結構化結果、留下紀錄，並在不確定時交回人工處理。
它不等於只有 API，也不等於把後台帳號直接交給 AI。真正的條件包括資料格式、操作邊界、錯誤訊息、冪等與可追溯性。
很多人以為介面對人好用，Agent 就能直接操作，其實剛好相反。人能看懂模糊提示並自行補救，Agent 需要更明確的狀態與回應。
如果你是老闆（或要驗收系統的主管），Agent 做錯時，你能知道它讀了哪筆資料、用了哪個版本、執行了什麼嗎？
為什麼半導體良率測試能幫助理解 Agent？
兩者都不能只看單次成功，而要固定輸入、條件與判定方式，持續比較不同版本。沒有共同測試基準，改善就只剩感覺。
半導體測試會管理條件、結果與差異，目的不是追求一張漂亮報表，而是讓異常可以重現、判讀與修正。
Agent 也需要「測試集」：正常資料、缺欄資料、互相衝突的指令、權限不足與外部服務逾時。每一種都先寫預期結果。
測試結果必須分成明確正確、明確錯誤與需要人工判斷。不要為了自動化率，把第三類硬塞進前兩類。
這和AI 驗收廚房的版次與品質管理可以合在一起使用：介面負責可操作，驗收負責可相信。
Agent 友善工具至少要有哪五個設計？
至少要有固定資料契約、結構化結果、單一最小權限入口、完整執行紀錄與人工接手機制。五項缺一，維護成本就會回到人身上。
- 資料契約：欄位名稱、格式、必填與版本固定。
- 結果狀態：成功、失敗、等待與需人工判斷可區分。
- 最小權限：每個 Agent 只拿完成任務所需權限。
- 執行紀錄：輸入、版本、動作、時間與結果能回查。
- 人工接手：超出邊界時能建立任務，而不是自行猜測。
Model Context Protocol 官方文件把 MCP 說明為連接 AI 應用與外部系統的開放標準。標準能降低連接差異，但企業仍要自己定義權限與驗收。
主管要怎麼驗收 Agent 友善，而不是只聽技術名詞？
請廠商現場跑五種異常，並交付權限表、資料字典、錯誤清單與重跑方式。能展示成功不夠，失敗後能恢復才是營運能力。
從 business owner 視角，介面設計費不能只和開發速度比較。還要算每次欄位改名牽動幾個系統、一次錯誤要幾人追查、原作者離開後誰能接手。
正式上線前，安排一位未參與建置的人依文件完成：送出測試、判讀失敗、撤銷權限、重跑任務。做不到的地方就是交接缺口。
資料契約也要有例子。日期究竟使用哪個時區、金額是否含稅、空值和零是否不同、同一請求重送能不能只執行一次，都應在介面旁說清楚。這些小欄位，往往才是跨系統最昂貴的誤會。
驗收文件也應標明每一種錯誤能否重試，以及重試前是否需要人工修正原始資料。
可再讀GAS、n8n、Notion 三層架構的踩坑與解法。你的工具是在幫 Agent 工作，還是在把更多例外默默推給人？
做 Agent 友善介面，第一張驗收表要寫什麼？
先寫任務的輸入、允許動作、成功與失敗回應、可重跑條件、人工接手人。Agent 能不能連上系統只是開始，這五欄才決定它能不能被管理。
例如「新增客戶」不能只回傳成功或失敗；還要回傳建立的識別碼、被拒絕的欄位、是否已寫入，以及同一請求再送一次會不會重複建檔。
MCP 可以讓模型與工具交換脈絡，但它不替企業決定誰有權核准、哪些資料不能送出。把協定當治理，是另一種看似進步的責任外包。
如果你是產品負責人（或要承擔資安風險的主管），請廠商示範一次權限不足與重複送單。兩種狀況都能說清楚，才談得上 Agent 友善。
