---
title: "為什麼工具介面要設計成 Agent 友善？從半導體良率測試談起"
url: https://stanleylin.tw/agent-friendly-interface-design/
author: 林毓晟（Stanley Lin，史大）
published: 2026-08-08
updated: 2026-08-09
categories: AI 與自動化
description: "Agent 友善不只接 API 或 MCP。從資料契約、最小權限、可重跑與人工接手，建立主管能驗收的 Agent 工作環境。"
---

# 為什麼工具介面要設計成 Agent 友善？從半導體良率測試談起

一個工具終於能跑時，我沒有立刻交付。我先故意拿掉一個必填欄位，再把同一筆資料送兩次。

真正花時間的不是把功能做出來，而是確認缺資料會怎樣、同一筆任務重跑會怎樣、外部服務沒回應時又由誰接手。

這個場景讓我想起晶圓良率工作（曾在晶圓研發做良率提升六年半）：設計只是起點，穩定產出必須靠可重複的測試條件。

我想把半導體的測試介面，翻譯成主管能驗收的 Agent 工作環境。

## 什麼是「Agent 友善介面」？

Agent 友善介面是讓代理程式能在明確權限內讀取輸入、執行動作、取得結構化結果、留下紀錄，並在不確定時交回人工處理。

它不等於只有 API，也不等於把後台帳號直接交給 AI。真正的條件包括資料格式、操作邊界、錯誤訊息、冪等與可追溯性。

很多人以為介面對人好用，Agent 就能直接操作，其實剛好相反。人能看懂模糊提示並自行補救，Agent 需要更明確的狀態與回應。

如果你是老闆（或要驗收系統的主管），Agent 做錯時，你能知道它讀了哪筆資料、用了哪個版本、執行了什麼嗎？

## 為什麼半導體良率測試能幫助理解 Agent？

兩者都不能只看單次成功，而要固定輸入、條件與判定方式，持續比較不同版本。沒有共同測試基準，改善就只剩感覺。

半導體測試會管理條件、結果與差異，目的不是追求一張漂亮報表，而是讓異常可以重現、判讀與修正。

Agent 也需要「測試集」：正常資料、缺欄資料、互相衝突的指令、權限不足與外部服務逾時。每一種都先寫預期結果。

測試結果必須分成明確正確、明確錯誤與需要人工判斷。不要為了自動化率，把第三類硬塞進前兩類。

這和[AI 驗收廚房的版次與品質管理](/ai-quality-harness-engineering/)可以合在一起使用：介面負責可操作，驗收負責可相信。

## Agent 友善工具至少要有哪五個設計？

至少要有固定資料契約、結構化結果、單一最小權限入口、完整執行紀錄與人工接手機制。五項缺一，維護成本就會回到人身上。

1. **資料契約**：欄位名稱、格式、必填與版本固定。
2. **結果狀態**：成功、失敗、等待與需人工判斷可區分。
3. **最小權限**：每個 Agent 只拿完成任務所需權限。
4. **執行紀錄**：輸入、版本、動作、時間與結果能回查。
5. **人工接手**：超出邊界時能建立任務，而不是自行猜測。

[Model Context Protocol 官方文件](https://modelcontextprotocol.io/docs/getting-started/intro)把 MCP 說明為連接 AI 應用與外部系統的開放標準。標準能降低連接差異，但企業仍要自己定義權限與驗收。

## 主管要怎麼驗收 Agent 友善，而不是只聽技術名詞？

請廠商現場跑五種異常，並交付權限表、資料字典、錯誤清單與重跑方式。能展示成功不夠，失敗後能恢復才是營運能力。

從 business owner 視角，介面設計費不能只和開發速度比較。還要算每次欄位改名牽動幾個系統、一次錯誤要幾人追查、原作者離開後誰能接手。

正式上線前，安排一位未參與建置的人依文件完成：送出測試、判讀失敗、撤銷權限、重跑任務。做不到的地方就是交接缺口。

資料契約也要有例子。日期究竟使用哪個時區、金額是否含稅、空值和零是否不同、同一請求重送能不能只執行一次，都應在介面旁說清楚。這些小欄位，往往才是跨系統最昂貴的誤會。

驗收文件也應標明每一種錯誤能否重試，以及重試前是否需要人工修正原始資料。

可再讀[GAS、n8n、Notion 三層架構的踩坑與解法](/gas-n8n-notion-internal-system/)。你的工具是在幫 Agent 工作，還是在把更多例外默默推給人？

## 做 Agent 友善介面，第一張驗收表要寫什麼？

先寫任務的輸入、允許動作、成功與失敗回應、可重跑條件、人工接手人。Agent 能不能連上系統只是開始，這五欄才決定它能不能被管理。

例如「新增客戶」不能只回傳成功或失敗；還要回傳建立的識別碼、被拒絕的欄位、是否已寫入，以及同一請求再送一次會不會重複建檔。

MCP 可以讓模型與工具交換脈絡，但它不替企業決定誰有權核准、哪些資料不能送出。把協定當治理，是另一種看似進步的責任外包。

如果你是產品負責人（或要承擔資安風險的主管），請廠商示範一次權限不足與重複送單。兩種狀況都能說清楚，才談得上 Agent 友善。