AI 開發

AI Agent 是什麼？2026 AI Agent 工作原理、Tool Calling、Function Calling 與 JSON 完整指南

JSONSort 2026-09-05 發布 2026-09-05 更新閱讀約 16 分鐘

2026 年幾乎每個 AI 產品頁都會寫「Agent」。但多數頁面把 聊天機器人、會呼叫函式的模型和 能跑完多步工作流的執行時混在一起。本文從定義出發：AI Agent 是什麼、它怎麼循環工作、Tool Calling 與 Function Calling 差在哪，以及為什麼這些層最終都落回 JSON。讀完後，你應能畫出一條可除錯的呼叫鏈，而不是再寫一段更長的 prompt。

閱讀前速覽

概念	一句話	JSON 落點
AI Agent	能規劃、調工具、把結果交給下一步的執行時	工作流状态 / handoff
Tool Calling	模型表達「要呼叫外部能力」的通稱	`tool_calls`
Function Calling	廠商 API 裡的工具呼叫實作	`tools[]` / `arguments`
JSON	步驟之間唯一穩定、可校驗的物件格式	Schema / payload

先記住分層：Agent 是執行時，Tool Calling 是能力層概念，Function Calling 是 API 幀，JSON 是它們共用的契約。

AI Agent 是什麼？

AI Agent 不是「更會聊天的大模型」。模型只負責生成文字（或結構化物件）；Agent 是把模型放進循環裡的執行時：觀察當前狀態、規劃下一步、呼叫外部工具、消化結果，再決定繼續、交接或結束。

2026 年一條能上線的 Agent，通常由三件套組成：

模型：推理、選工具、生成 Structured Outputs。
宿主（Host）：解析呼叫意圖、執行真實 API / 資料庫 / 檔案操作、回傳結果、攔住不合規的 JSON。
契約：工具參數、工具回傳值、handoff 物件、工作流狀態——幾乎全是 JSON。

缺了宿主，模型只能「建議」；缺了契約，多步流程會把半對的物件當成事實往下傳。Agent 的產品邊界在宿主，不在模型卡片。

和聊天機器人、普通 LLM 差在哪？

三個詞經常被寫成同一個功能。生產裡必須拆開：

普通 LLM：輸入一段話，輸出一段話。沒有工具，也沒有跨步狀態。
聊天機器人：把 LLM 接到對話 UI。輸出給人看；失敗時使用者自己重試。
AI Agent：輸出給系統執行。工具結果、下一跳路由、評測分數都是物件，不是散文。

判斷標準很簡單：如果下一步必須由程式執行、而不是由人讀懂，你就需要 Agent，而不是一個「看起來很智慧」的對話框。執行權在宿主；模型只提出呼叫意圖。

2026 年 AI Agent 怎麼工作？

主流循環仍然是 observe → plan → act → observe。變的是每一步都有型別，而不再靠「模型提到了退款」。

Observe：把使用者訊息、上一跳工具結果、當前 JSON 狀態放進上下文。
Plan：模型決定是直接回答、呼叫工具，還是把物件 handoff 給另一個 Agent。
Act：宿主執行 tool_calls，或按 handoff JSON 切換 Agent。
Observe again：工具結果以 role: tool 回傳；狀態物件更新後再進下一輪。

宿主還要做四件模型不會替你做的事：注入 tools[]、二次解析 arguments、用 Schema 校驗、在失敗時短路而不是「再試一次 prompt」。

生產棧已經收斂。Assistants API 於 2026 年 8 月 26 日退役；新程式走 Responses API + Agents SDK。DevDay 2026 預測把同一趨勢寫成三層：Structured Outputs 約束物件，Function Calling 表達呼叫，Agent 執行時編排二者。

多步任務不要只靠對話歷史「回憶進度」。把當前步寫成可恢復的 JSON：

{
  "step": 2,
  "agent": "billing",
  "last_tool": "lookup_order",
  "state": {
    "order_id": "A-1042",
    "status": "paid",
    "amount": 99.00
  },
  "next": "create_refund"
}

這類物件應先在本地格式化並做語法檢查，再和上週能跑通的定義做 JSON Diff。含使用者資料或金鑰的工具回應，不要貼到公開 JSON 網站。

Tool Calling 是什麼？

Tool Calling 是能力層通稱：讓模型在合適時機輸出機器可讀的「我要呼叫外部能力」，而不是用自然語言假裝已經查過資料庫。它不綁定某一家廠商的欄位名。

2026 年至少有三條實作都叫 Tool Calling：OpenAI 相容 API 的 Function Calling、Anthropic 等廠商的 Tool Use，以及 MCP 的 tools/list + tools/call。MCP Tool Schema vs Function Calling 寫過邊界：MCP 負責跨宿主供給工具，API 幀負責讓模型表達這一跳的意圖。

對開發者而言，Tool Calling 回答的是「模型能不能伸出手」；它不回答「手伸出去之後，參數和回傳值誰來校驗」。後者是 Schema 和宿主的工作。

Function Calling 是什麼？

Function Calling（OpenAI 文件現多稱 tools）是 Tool Calling 在廠商 Chat / Responses API 裡的具體實作。你在請求裡注入一組函式定義；模型若決定呼叫，就在回應裡返回 tool_calls。

典型工具定義（OpenAI 風格）如下。注意 parameters 已經是一份 JSON Schema 子集：

{
  "type": "function",
  "function": {
    "name": "lookup_order",
    "description": "Look up an order by ID",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {
          "type": "string",
          "description": "Order ID, e.g. A-1042"
        }
      },
      "required": ["order_id"],
      "additionalProperties": false
    }
  }
}

模型返回的呼叫意圖通常長這樣：

{
  "tool_calls": [{
    "id": "call_3c91",
    "type": "function",
    "function": {
      "name": "lookup_order",
      "arguments": "{\"order_id\":\"A-1042\"}"
    }
  }]
}

注意 arguments 仍是字串化的 JSON。宿主必須再做一次 JSON.parse，並用 Schema 校驗 order_id 的型別與格式。漏掉這一步，是 2026 年最常見的生產事故。除錯巢狀 JSON 時，用格式化並做語法檢查先看清括號和跳脫。

Tool Calling 和 Function Calling 怎麼區分、怎麼疊用？

兩者不是兩個互相替代的產品，而是不同層級：

Tool Calling：概念。凡是「模型輸出呼叫意圖、宿主執行」都算。
Function Calling：API 幀。欄位是 tools[]、tool_calls、role: tool。
MCP Tool Schema：供給協議。欄位是 inputSchema，經 stdio / SSE 轉到 MCP Server。

正確疊法：倉庫裡一份 Schema，匯出為 Function Calling 的 parameters 和 MCP 的 inputSchema。不要在 prompt 裡用散文維護第三份「幾乎一樣」的參數說明。細節見 MCP Tool Schema vs Function Calling 與 AI Agent 為什麼開始需要 JSON Schema。

為什麼 2026 年的 Agent 一切都落在 JSON？

自然語言只負責對使用者說話。機器之間的每一跳都必須可校驗、可 Diff、可回放。JSON 同時承擔五類物件：

工具定義：tools[] 或 MCP inputSchema。
呼叫意圖：tool_calls 裡的函式名 + 參數。
工具結果：查詢、寫入、外部 API 的回傳物件。這一層最常缺失。
Agent handoff：意圖、置信度、路由目標。Agents SDK 用它做路由，而不是用「提到了 billing」。
工作流狀態與評測：checkpoint、trace、eval fixture。長任務必須從 JSON 恢復，不能靠聊天紀錄猜進度。

JSON Schema 是這些物件的口徑。沒有口徑，Function Calling、MCP、A2A 會各自漂移出一份「看起來像」的定義。AI Agent 為什麼開始需要 JSON Schema 把 Schema 從文件寫成了執行時門禁；基礎語法見 JSON Schema 教程。

一次完整呼叫的 JSON 流水線

以「查訂單 → 退款」為例，2026 年一條保守、可測的鏈路是：

宿主把 lookup_order / create_refund 的 Schema 注入 tools[]，並打開 strict: true。
模型返回 tool_calls，arguments 仍是字串。
宿主 JSON.parse，按同一份 Schema 校驗；失敗則短路，不呼叫計費系統。
執行真實查詢，得到訂單物件。
以 role: tool 回傳——最好也是符合 Schema 的 JSON，而不是一段散文。
模型決定下一步：再調工具，或產出給使用者 / 下游 Agent 的 Structured Output。
若要換 Agent，寫出 handoff 物件，而不是在回覆裡「請 billing 同事處理」。

handoff 物件應像這樣穩定：

{
  "handoff": {
    "from": "triage",
    "to": "billing_agent",
    "intent": "refund",
    "order_id": "A-1042",
    "confidence": 0.91
  }
}

多 Agent 協作時，A2A Extensions 把能力寫進 Agent Card，用擴展頭協商。它不替代上面的流水線，只負責跨 Agent 派發。

2026 年該怎麼選型？

單體 App、內部閉環、工具少於十個：Function Calling 足夠。先把 Schema 和 strict: true 寫進 CI。
IDE / 平台 / 要插拔第三方工具：用 MCP 供給，API 層仍用 Function Calling 表達這一跳。
多個異構 Agent 要互相發現、協商擴展：加上 A2A，而不是再發明一套私有信封。
無論走哪條：工具參數、工具結果、handoff 都先寫成 JSON Schema，再匯出適配器。

不要等某次發布會「統一協議」。2026 年的穩定策略是分層，不是賭一個贏家。

常見誤區

把 Agent 當成更會聊天的 ChatGPT。 對話框可以演示；生產要的是可恢復的狀態機。
把 Tool Calling 和 Function Calling 當成兩個競品。 一個是概念，一個是 API 幀。MCP 是第三條供給層。
不校驗 arguments。 字串化 JSON、數字寫成字串、多餘欄位溜進計費，都發生在這一跳。
工具結果是自由文字。 下一跳會把「好像成功了」當成訂單狀態。
一次請求塞進 50 個工具。 Schema 又貴又容易選錯。超過十個就做路由或檢索。

FAQ

做 Agent 必須用 Function Calling 嗎？

不是。Function Calling 是最常見的 API 幀，但 MCP Tool Use、廠商 Tool Use 同樣是 Tool Calling。關鍵是宿主執行 + Schema 校驗，而不是欄位名叫 tools 還是 inputSchema。

Tool Calling 是不是 Function Calling 的新名字？

有的文件把二者混用。更乾淨的分法：Tool Calling 是通稱，Function Calling 特指 OpenAI 相容 API 的 tools / tool_calls 形狀。寫架構圖時分開畫，少很多爭論。

只用 JSON mode，不寫 Schema，夠不夠？

只保證「看起來像 JSON」，不保證欄位、型別、列舉合法。2026 年的 Structured Outputs 用 json_schema + strict 卡口徑。多步 Agent 裡，JSON mode 過不了評測集。

要不要等 DevDay 2026 再開工？

不必。9 月 29 日可能加深 Structured Outputs 和呼叫計畫，但不改變「先寫 Schema」這件事。現在把工具與 handoff 收進 git，發布會後只換適配器。

怎麼除錯工具和 handoff 的 JSON？

在瀏覽器裡格式化、檢查缺失的 required，再和上一版 Diff。JSONSort 本地執行、不上傳。不要把帶金鑰的工具回應貼到公開網站。

結論

AI Agent 是帶工具與狀態的執行時，不是更會說話的模型。Tool Calling 讓它伸出手，Function Calling 是最常見的那隻手的 API 形狀，JSON 是每一步交接時必須對得上的物件。

從今天起，先寫 schemas/tools/lookup_order.json，再寫更長的 prompt。模型會換，協議會增，口徑應該先穩定。