AI Agent 的 API：從 MCP 到自訂端點

Piotr Grudzień
發布日期 閱讀時間約 12 分鐘
抽象插圖，巢狀工具層從中央 LLM 核心向外放射

當 LLM 學會呼叫函式

在 GPT-3 時代，與 LLM 互動的方式是提供 prompt 並取得文字回應。模型的知識量很大，但它是靜態的，停留在訓練資料所包含的內容。你可以請它解釋量子運算或草擬電子郵件，它會產生看似合理的文字。但它不能查詢今天的天氣、查詢資料庫，或在真實世界採取任何動作。

改變這一點的功能得到的關注意外地少。它讓模型可以在產生文字和呼叫函式之間做選擇。模型不再總是產生下一個 token，而是可以輸出一個結構化 JSON 物件，指定函式名稱及其引數。執行環境會執行該函式，將結果回傳給模型，模型再從那裡繼續。ReAct 論文（Yao 等人，2022）將此形式化為 Thought-Action-Observation loop。模型推理要做什麼，採取動作（呼叫工具），觀察結果，然後重複。2026 年每個嚴肅的 AI agent 都以某種版本的這個模式運作。

這個迴圈

Claude Code、OpenClaw、Codex、Devin，以及數十個其他 agentic 系統都以相同方式運作。呼叫工具、觀察結果、決定下一步、重複。Simon Willison 說得很好：「LLM agent 會在迴圈中執行工具以達成目標。」

以 Claude Code 為例，它使用單執行緒主迴圈，沒有多 agent 群集，也沒有複雜的編排圖：while(tool_call) -> execute -> feed results -> repeat。

AI Agent 迴圈

Anthropic 關於 agent 自主性的研究顯示，Claude Code 中的回合時間在三個月內幾乎翻倍，從 25 分鐘增加到超過 45 分鐘。使用者越來越信任這個迴圈自行運作。資料顯示，有經驗的使用者反而更常中斷（從逐一動作核准轉向策略性監控），而 agent 本身要求釐清的頻率則是使用者中斷頻率的兩倍以上。

這種迴圈模式無處不在，從程式碼 agent、客服 bot，到機器人控制器皆然。

什麼算是工具？

LLM 讓我們在決定工具應該運作於哪個抽象層級時有相當大的自由。一個極端是高度特定的 API 端點：「用這 12 個欄位建立 HubSpot 聯絡人。」另一個極端則是「執行這個 bash 指令」或「執行這段 Python 程式碼」這類工具，本質上就是「做你想做的任何事」。

Devin 使用三個工具：shell、程式碼編輯器、瀏覽器。Claude Code 的主要工具也是 shell。OpenClaw 使用動態技能外掛系統。agentic 程式碼工具的趨勢，是走向更少、更通用的工具，而不是大量特定工具。

Simon Willison 觀察到，對程式碼 agent 而言，MCP「一開始爆發式成長，但後來感覺沒那麼核心」，因為 bash 是通用工具。檔案和腳本是比完整 MCP 伺服器實作成本更低的基本元素。如果 agent 能撰寫並執行程式碼，它幾乎可以做任何事，而不需要專用的工具定義。

但通用工具適用於通用 agent。對於特定領域的 AI agent（客服、銷售、內部營運），你需要特定領域的工具。你的客服 agent 不應該為了查訂單狀態而撰寫 Python。它應該呼叫一個定義清楚、參數明確、回應可預期的 API 端點。工具集的設計會成為一項產品決策。

ApproachExampleControlFlexibilityUse Case
通用工具Bash、Python 直譯器最低最高程式碼 agent、個人助理
協定套件（MCP）Shopify MCP、GitHub MCP中等中等快速整合、原型設計
單一 API 端點「建立 HubSpot 聯絡人」最高最低生產環境中的對客戶 agent

現在 API 端點代表什麼

對 AI agent 而言，API 端點的作用是能力宣告。發布一個端點，表示你（或你的 AI agent）現在可以做一件先前無法做到的事。

這在兩個方向都成立。軟體供應商發布 API，讓其他人可以與其產品整合。但 AI agent 也可以自行發現端點，方式包括搜尋文件、閱讀 OpenAPI 規格，或直接上網搜尋如何完成某項任務。

MCP 伺服器是一組經過策展的 API 端點，並帶有一套預先設想的使用方式。MCP 建立者已經決定要公開哪些端點、如何命名、要呈現哪些參數，以及隱含地支援哪些工作流程。這種策展同時是優點（便利、標準化）和缺點（僵化、範圍帶有主觀取捨）。Notion 的伺服器是一個具體例子：它發布 28 個工具，而一個說明中心 agent 需要其中 4 個，並分散在兩個連線中。

MCP 用控制權換取易用性。到了 2026 年，AI 會撰寫大部分整合程式碼。如果 agent 能閱讀 API 文件並自行撰寫整合，MCP 的「易用性」論點就會變弱。MCP 層可能在過渡期最重要，當工具尚未追上模型能力時尤其如此。Anthropic 的工具使用設計模式指南是一份實用參考，無論你使用 MCP 或個別端點，都可用來建構工具 schema。

一個相關發展是：llms.txt 是一項提議中的標準，網站可發布 /llms.txt 檔案，引導 AI 模型找到高價值資源。Anthropic、Cloudflare、Docker 和 Stripe 已採用它。**MCP 標準化工具呼叫，llms.txt 標準化文件探索。**兩者都試圖從不同角度，讓網路更容易被機器理解。

在 AI agent 的脈絡中，什麼是 API 端點？

API 端點是一個特定 URL，接受結構化輸入並回傳結構化輸出。對 AI agent 而言，每個端點代表一項離散能力，也就是 agent 可以在真實世界執行的某件事。端點的描述、參數定義和錯誤回應，就是 agent 的操作手冊。端點文件越完善，agent 就越能可靠地使用它。

不同於可閱讀教學並反覆除錯的人類開發者，agent 依賴端點的 schema 和描述來完成一次正確呼叫。這就是為什麼為 AI 消費而設計的 API 文件比以往更重要。儘管 89% 的開發者在工作流程中使用 AI，目前只有 24% 的開發者在設計 API 時會考量 AI agent。

什麼是 MCP（Model Context Protocol）？

MCP 是 Anthropic 推出的開放協定，用於標準化 AI agent 如何連接外部工具和資料來源。可以把它想成 AI 的 USB-C。任何工具供應商都能實作，任何 AI agent 都能使用的單一連接器。MCP 伺服器會以標準化 schema 公開一組工具（本質上是 API 端點），而 MCP client（agent）可以在沒有自訂整合程式碼的情況下發現並呼叫它們。若要更深入的技術說明，請參閱我們的 MCP Explained 文章。若要了解 MCP 在生產環境中的實務情況，請參閱我們對在 Shopify MCP 上建構時遇到的真實挑戰的分析。

Quickchat AI 中的控制光譜

Quickchat AI 提供三種方式，讓你為 AI Agent 配備外部工具。它們位於從最高自動化到最高控制權的光譜上。每種方法都在設定速度與行為精準度之間做出不同取捨。

Remote MCP：接上即可使用

Remote MCP 是將 AI Agent 連接到外部功能最快的方式。你提供 MCP 伺服器 URL，Quickchat AI 會連線到它、探索所有可用工具，並讓你選擇 agent 應該使用哪些工具。

設定方式：

  1. 前往 Quickchat AI dashboard 中的 AI Actions
  2. 點擊 “Add Remote MCP”
  3. 貼上你的 MCP 伺服器 URL（例如 https://mcp.example.com/sse）
  4. 可選擇加入驗證 token 或自訂 headers（兩者互斥）
  5. 點擊 “Connect.” Quickchat AI 會探索所有可用工具並顯示其名稱
  6. 開啟或關閉個別工具，以控制 agent 可以使用哪些工具
  7. 設定 “default tool is active” 旗標，以控制新探索到的工具預設為自動啟用或停用

Quickchat AI 中的 Remote MCP

背後發生的事：

當你點擊 Connect，Quickchat AI 會從 URL 自動偵測傳輸協定。如果 URL 包含 sse，會使用 SSE transport；否則預設為 streamable_http。當你提供 auth token 時，它會作為 Bearer token 送入 Authorization header。

工具篩選透過三層系統運作。MCP 伺服器中的每個工具都會對照兩個集合檢查：明確啟用的工具一律納入，明確停用的工具一律排除，而不在任一集合中的工具，則回退到你選擇的 “default tool is active” 設定。這表示當 MCP 伺服器新增工具時，你可以控制它們是否自動提供給 agent 使用，或需要明確啟用。

工具篩選

在執行階段，當對話開始時，agent 的所有有效 Remote MCP 連線都會載入。系統會依每個連線的設定擷取並篩選工具，並在所有來源之間驗證工具名稱唯一性（若發現重複會提出警告）。

**取捨：**你可以立即存取 MCP 公開的所有內容，但你對工具描述、參數定義，或 agent 如何決定使用它們的控制有限。正如我們在基於 Shopify MCP 建構 AI Agent 時發現的，從展示進入生產環境需要仔細調校，而 MCP 的套件式方法可能讓這件事變得困難。

另請參閱：將你的 agent 連接到遠端 MCP 伺服器、How to Launch Your Quickchat AI MCP、MCP security considerations、Quickchat AI docs: MCP channel。

AI Actions（HTTP Request）：一個端點，完整控制

Quickchat AI 中的 AI Action 是一個單一 HTTP API 端點，你可為 AI Agent 個別設定。MCP 一次匯入一組工具，而每個 AI Action 都讓你完整控制一項特定能力。如需完整實作範例，包含四個用於建立和補充聯絡人、記錄交易，以及在 CRM 中開啟 ticket 的 action，請參閱 HubSpot AI Actions 教學。

設定 AI Action：

  1. Name（最多 64 個字元）：這會成為 LLM 看到的工具名稱。它會正規化為有效識別字（例如 “Check Order Status” 會變成 Check_Order_Status）
  2. Description（最多 1,000 個字元）：這是最重要的欄位。Description 會告訴 LLM 何時 使用此工具。好的描述會指定在哪些對話情境下呼叫它、需要先向使用者收集哪些資訊，以及應如何把結果回覆給使用者
  3. HTTP method：GET、POST、PATCH、DELETE 或 PUT
  4. URL（最多 10,000 個字元）：可包含 {{parameter_name}} placeholder 以提供動態值
  5. Headers：用於驗證和內容類型的 key-value 配對
  6. Body items / Body JSON：含參數注入的請求 body
  7. Query parameters：URL query string 值
  8. Parameters（最多 10 個）：每個都有名稱、描述（最多 500 個字元）、類型（str、int、float、bool 或 custom）、必填旗標和選用預設值

{{parameter_name}} placeholder 是關鍵機制。當 LLM 呼叫工具時，會根據對話脈絡為每個參數提供值。Quickchat AI 接著在發出 HTTP request 前，將這些值注入 URL、headers、body 和 query string 範本。另有四個內建變數也可用這種方式注入：scenario_id、conversation_id、conversation_channel 和 conversation_url。

AI Action 範例 設定為檢查訂單狀態的 AI Action，顯示含參數 placeholder 的 URL 範本、headers 和參數定義。

**背後機制：**Quickchat AI 會根據每個 AI Action 的參數定義，動態建立 typed schema。五種支援類型（str、int、float、bool、custom）會對應到其原生等價類型，並在發出 HTTP request 前，用此 schema 驗證 LLM 的輸入。

檢查訂單狀態的 AI Action 範例：

{
  "name": "check_order_status",
  "description": "當使用者詢問訂單狀態且已提供訂單編號時，呼叫此端點以擷取目前狀態。將狀態、預估送達日期和追蹤編號（如有）回報給使用者。",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "使用者提供的訂單 ID（例如 ORD-12345）",
      "type": "str",
      "is_required": true
    }
  ]
}

**測試：**dashboard 有一個 “Test” 按鈕，可讓你提供範例參數值，並在部署前查看實際 HTTP request（包含產生的 curl command）和 response。

撰寫有效 AI Action 描述的建議：

  • 明確說明 agent 應何時呼叫它：「當使用者詢問訂單狀態並提供訂單編號時，呼叫此端點」
  • 提及應先收集哪些資訊：「呼叫前，確認你已取得使用者的電子郵件地址和訂單 ID」
  • 描述如何處理回應：「如果狀態為 ‘shipped’，請將回應中的追蹤編號告知使用者」
  • 對於多步驟工作流程，請在 agent 的主要 system prompt 中描述順序，而不是寫在個別 action 描述中。若要在 action 之間傳遞值，並以該值作為寫入閘門，請使用 Save to memory 加上 run-condition

**完整範例：**若要逐步設定可將 leads、未回答問題和 demo requests 直接記錄到試算表的 AI Action，請參閱如何將 AI agent 連接到 Google Sheets。

Generate from Text：讓 AI 自行判斷

第三種選項適用於知道自己希望 agent 做什麼，但不知道該使用哪個 API 端點（甚至不知道該使用哪個服務）的使用者。

運作方式：

  1. 你輸入一段自然語言描述，說明你想要什麼，例如「我希望我的 AI Agent 能在使用者要求時啟動其 Tesla」
  2. Quickchat AI 會將此內容傳送給已啟用 web_search 工具的 LLM
  3. 模型會搜尋網路以找到正確 API、閱讀官方文件，並產生完整的 AI Action 規格，包括 URL、method、headers、parameters 和 authentication requirements
  4. 結果會回傳完整 action 設定、所使用文件的 citations，以及一則說明假設與缺口的 explainer message
  5. 你審閱、填入 credentials，然後啟用

由文字產生 AI Action 輸入所需能力的自然語言描述。

由文字產生 AI Action 的結果 產生的 AI Action 設定，並附上所使用 API 文件的 citations。

自動化 AI Action 產生以三個優先事項為核心：

  • 優先事項 1：理解意圖。 識別開發者想要的精確能力，以及提供該能力的特定 API 端點
  • 優先事項 2：以文件為依據。 使用網路搜尋找到官方供應商文件，而不是猜測
  • 優先事項 3：設計以對話為先的語意。 產生的名稱和描述應該說明此工具會在_對話中的哪個時機_被使用，而不只是 API 在技術上做什麼

prompt 使用兩種 placeholder 慣例。{{param}} 標記由 LLM 從對話脈絡填入的執行階段參數。[[secret_name]]（雙中括號）標記 API keys 和 account IDs 等開發者常數，必須在啟用前手動設定。每個參數名稱都必須在 request 定義中的某處以 {{that_exact_name}} placeholder 出現，而且不允許孤立 placeholder。

系統使用失敗即關閉政策。如果模型無法從文件中確認關鍵資訊（HTTP method、URL、authentication scheme 或 required payload structure），就不會建立 action。相反地，系統會回傳簡潔說明，指出缺少哪些資訊，而不是猜測。

這正是關於 AI agent 發現 API 的哲學觀點，連接到具體產品功能的地方。Generate from Text 功能實際上就是一個 AI agent（具備網路搜尋的 LLM）為另一個 AI agent（會在對話中使用它的 Quickchat AI agent）建立工具定義。

**完整範例：**若要查看完整教學，了解如何將兩句輸入文字轉為兩個即時且已測試的 action（無金鑰的天氣查詢和需要金鑰的 NASA action，並包含失敗即關閉的拒絕案例），請參閱如何用白話英文將你的 AI agent 連接到任何 API。

在執行階段，所有這些工具類型會組合在一起。Quickchat AI 會收集 HTTP request AI Action tools、Shopify MCP tools、knowledge base tools、remote MCP tools、Discord tools，以及其他 custom tools，形成一個集合並呈現給 LLM。模型不會看到它們之間的差異。Remote MCP tool 和手動設定的 AI Action 一旦進入工具清單，看起來就是相同的。

開放 API 成為新的 SEO

如果 AI agent 會自主發現並使用 API，那麼擁有文件完善、易於使用的 API 就會成為一項分發資產。Gartner 預測，到 2026 年，超過 30% 的 API 需求成長將來自 AI agent。

擁有開放 API 且 credential 門檻低的公司，可能會發現 API 成為最好的獲客渠道。取代 Google 搜尋曝光的，是 AI agent 選擇使用你的服務，而不是競爭對手的服務。

同樣的邏輯也適用於上一層。從你的文件回答問題的 AI agent 本身，也可以公開為 MCP 伺服器，讓 ChatGPT、Claude 和 Cursor 作為工具呼叫。這會讓你的知識，而不只是 API，可被 agentic web 發現。

API 文件的品質決定 AI agent 是否能在一次嘗試中成功與你整合。 參數描述、錯誤訊息和回應範例，在傳統 SEO 中扮演的角色類似於 meta descriptions 和 structured data。令人困惑的錯誤回應，或未記載的 required field，表示 agent 會失敗，而另一端沒有真人可以幫它除錯。

API 未記載文件，或被繁重 credential requirements 阻擋的公司，可能會發現自己對 agentic web 而言不可見，就像 2000 年代沒有網站的公司對 Google 而言不可見一樣。

電腦使用與 API

業界正大量投資，教 AI 模型「computer use」（點擊按鈕、填寫表單、瀏覽 UI）。Anthropic、OpenAI（Operator），以及 Browser Use 等開源專案都提供了各自版本。

但瀏覽器使用是缺少 API 時的替代方案。一次 POST /orders 呼叫只需毫秒並回傳結構化資料。瀏覽器 agent 執行結帳流程需要數分鐘，而且按鈕向左移動三個像素就可能失效。API 更快、更確定，也更便宜。

電腦使用與 API 對比

反方論點確實存在：不是所有事情都有 API。舊系統、沒有 API 介面的企業軟體、透過 GUI 控制的實體裝置。在這些情況下，computer use 確實填補了真正的缺口。

對「我們沒有這個 API」更好的長期回應，可能是建置 API，而不是教 AI 使用 GUI。隨著更多軟體由 AI agent 為 AI agent 撰寫，建置和維護 API 的成本會下降。過去讓抓取 UI 比建置 API 更便宜的經濟計算正在改變。

這也有安全性面向。Simon Willison 的「致命三要素」描述了私有資料存取 + 不受信任內容暴露 + 外部通訊這種危險組合。這適用於兩種方法，但以 API 為基礎的工具較容易稽核和限制。你可以記錄每一次 API 呼叫、驗證每個參數，並對每個端點做 rate-limit。要對一個可以點擊任何東西的瀏覽器 agent 做到同等控制，困難許多。

實體世界的工具

到目前為止討論的都是軟體。同樣模式也出現在實體世界。

Google DeepMind 的 RT-2 和 Gemini Robotics 使用相同架構，只是工具會派發到致動器而不是 API。SPCA（Sense-Plan-Code-Act）框架將此形式化於機器人領域：掃描環境、規劃做法、產生可執行程式碼、執行它、觀察結果。

「把我桌上的植物往右移」沒有 API。但配備相機的機器人可以即時定義 move_object(object_id="plant_01", direction="right", distance_cm=15) 作為工具，然後呼叫它。工具定義扮演推理層與實體執行層之間的介面，與 API 端點在軟體中扮演的角色相同。

LLM + 工具 + 迴圈架構是通用的。今天它剛好最容易在軟體中實作，但機器人領域正在追上。

實體世界的工具

由 AI 為 AI 撰寫的 API

大約兩年內（2024 到 2026），我們已從大多數程式碼由人類撰寫，轉變為大多數程式碼由 AI 撰寫。這是重新思考 API 端點意義的好時機。越來越多時候，端點是一種能力宣告，設計目的在於讓機器發現並執行，而不是供人類開發者閱讀文件後手動整合的技術介面。

MCP 是有用的標準化層，但它也是會引入偏差的策展層。MCP 建立者會決定公開哪些工具，以及如何描述它們。對生產環境中的 AI agent 而言，這種描述方式可能不符合你的實際需求。（我們在分析 Shopify MCP 的挑戰時曾詳細寫過這一點。）

我們在 Quickchat AI Agents 中走過的光譜，反映了一個更廣泛的觀點。合適的控制層級取決於你的使用情境。Remote MCP 適合快速原型設計。Individual AI Actions 為生產環境中的對客戶 agent 提供細緻控制。Generate from Text 則在你仍在探索時，讓 AI 研究 API 並為你建立工具定義。

在每個層級，底層模式都相同。一個 LLM、一組工具、一個迴圈。無論工具是 bash 指令、API 端點、MCP 伺服器或機器人致動器，本質上都是一層又一層的工具。