Cloudflare Agents 接 MCP elicitation 時：把使用者輸入留在可確認的邊界內

2026-07-18

AI

Cloudflare

/

MCP

/

AI

/

開發工具

當 MCP tool 缺少一個欄位時，最糟的處理方式不是報錯，而是讓 agent 猜一個值、把不完整資料送到外部系統。Cloudflare 在 2026-07-13 更新 Agents，讓透過 addMcpServer 連接的 MCP server 能發出 elicitation request；Agent 可以在處理 tool call 的途中向使用者要求補充輸入。

這讓工作流更順，但也多了一個必須設計的邊界：elicitation 適合收集結構化、非敏感的補充資料；一旦會影響權限、金錢、外部寫入或敏感資料，就應改成清楚的確認與受控流程。

先確認缺的是資料，還是同意#

表面上看起來都是「問使用者一個問題」，實際上有兩種完全不同的需求：

agent 缺少的東西	合適做法	例子
結構化、非敏感資料	form-mode elicitation	報表日期範圍、專案名稱、通知頻道
對不可逆或有影響行為的同意	顯示明確摘要並要求確認	刪除資料、送出付款、發布到正式環境
秘密或認證資料	專用 credential／secret 流程	API key、密碼、OTP、私鑰
需要人判斷的例外	提供上下文與取消路徑	合併衝突、帳務例外、違規內容處理

Cloudflare 的公告特別把 form mode 描述為收集結構化、非敏感資料。這不只是 UI 建議，也是一個很好的 API 設計界線：不要因為表單能出現，就把任何資料都塞進同一條互動管道。

讓 schema 說出使用者真正要填什麼#

elicitation 的價值在於它可以把問題具體化。與其讓 agent 問「請告訴我部署資訊」，不如要求 server 提供可驗證的欄位、合理預設與用途說明。概念上，問題應接近這種形狀：

1
{
2
  "environment": "preview",
3
  "region": "apac",
4
  "notify": false
5
}

這不是特定 Cloudflare API 的完整 payload，而是輸入設計原則：欄位命名要能被人讀懂、可選值要有限制、預設值要能被檢查。若 environment 會決定是否部署到正式環境，就不應把 production 藏在預設值裡。

在送出 tool call 前，保留最後一層確認#

form mode 收到資料後，agent 仍應在有副作用的 tool call 前做一次檢查。可以把流程拆為：

server 請求缺少的非敏感欄位。
Agent 顯示已整理的值，讓使用者更正或取消。
若動作會寫入、發布或改變權限，顯示目標系統與影響摘要，再要求確認。
確認後才呼叫具副作用的 tool，並回傳可追蹤的結果或識別碼。

不要把「使用者填過表單」當成「使用者已同意所有後續動作」。前者補全資料，後者授權一個具體行為；在可稽核的工作流中，兩個事件應可分辨。

敏感資料不要改走 elicitation
如果 tool 缺少 token、密碼、OTP、私鑰或其他 credential，應停止並導向產品既有的 secret 或帳號授權流程。不要要求使用者在一般表單欄位輸入，再讓 agent 轉送給 MCP server。

測試時，刻意驗證取消與不完整輸入#

接入前可用一組小型案例測試，而不是只測「全部填對」：

缺少必填欄位時，server 是否只詢問必要資料？
使用者取消時，agent 是否真的不呼叫後續寫入工具？
送入不支援的選項時，是否回傳可理解的欄位錯誤？
預設值是否會被清楚顯示，而不是悄悄套用？
具副作用的動作，是否有目標與影響摘要可供確認？

這些測試不需要大型測試環境。先用 preview project、假資料與一個可觀察的 mock tool，確認取消路徑沒有副作用，再接到真正的系統。

讓 elicitation 成為補資料的工具，而非繞過審核的捷徑#

Cloudflare Agents 對 MCP elicitation 的支援，適合把「缺一個日期、名稱或選項」從猜測改為結構化提問。把它放在正確位置：表單負責補齊非敏感資料；確認畫面負責取得對特定行為的同意；secret 與帳號授權則維持在既有的安全通道。這樣 agent 才能加速工作，而不把責任邊界一起自動化掉。