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

AI Agent 是什麼：和聊天、工作流差在哪

最小定義只需要三件事：目標（用戶要完成什麼）、感知（當前上下文與工具回執）、行動（調用哪一個工具、填什麼參數，或給出最終答覆）。大模型負責在每一步選擇行動；運行時負責執行工具並把觀察寫回上下文。沒有循環、沒有工具、沒有可校驗的參數形狀，只是聊天。

和聊天機器人的差別不在模型商標，而在停止條件。聊天一輪問答就可以結束。Agent 在拿到工具結果之前，通常不應宣稱任務完成——它可能先查發票、再彙總、再問你確認。和傳統工作流的差別在於邊是誰畫的：n8n / Temporal 的下一跳由人預先連好；Agent 的下一跳由模型根據當前這份 JSON 觀察決定。工作流可預期、可回放；Agent 更靈活，也把「參數填錯」變成一等故障。

2026 年常見形態包括：編碼 Agent（編輯器裏讀文件、跑測試、改補丁）、客服與內部運營 Agent（查訂單、開工單）、以及多 Agent 編排（一個規劃者把任務交給專長 Agent）。形態不同，契約相同：工具邊界用 JSON Schema 寫清，arguments 與 result 都是可 parse 的 JSON。Apple 把同一函數同時暴露給 App Intent 與模型工具，見Apple AI Agent 與 JSON。

2026 工作原理：觀察 → 決策 → 調工具 → 再觀察

把演示視頻裏的「智能」拆開，一條典型 Agent 循環只有五步：

1. 用戶目標進入上下文（自然語言 + 可選系統約束）。
2. 運行時注入工具清單：每個工具有 name、description 和一份 JSON Schema（parameters / inputSchema）。
3. 模型返回 tool_calls（要調哪個函數、arguments 是什麼）或最終文本 / Structured Output。
4. 運行時 JSON.parse arguments，執行本地函數、HTTP 或 MCP tools/call，把 result JSON 寫回消息列表。
5. 模型再看結果，決定下一工具或結束。超過 maxSteps、用戶取消或 Schema 失敗則停。

循環的形狀本身也可以寫成配置，而不是埋在框架魔法裏。下面這份 JSON 只描述 hops 與停止條件，不包含任何業務字段——業務字段屬於各工具自己的 Schema。

{
  "loop": "agent",
  "maxSteps": 8,
  "stopWhen": ["final_answer", "max_steps", "user_cancel", "schema_fail"],
  "hops": [
    { "kind": "model", "emits": "tool_calls | text" },
    { "kind": "runtime", "emits": "tool_result JSON" },
    { "kind": "model", "emits": "next_tool | final JSON" }
  ]
}

故障幾乎總髮生在第 3→4 步：arguments 是字符串卻被當成對象、數字寫成字符串、漏 required、或工具名與緩存的清單不一致。模型「夠聰明」解決不了契約漂移。無狀態 MCP 下每次請求自帶協議元數據，但 arguments 形狀仍取決於你餵給模型的那份 Schema。

Tool Calling 與 Function Calling：同一件事的兩套名字

工程上它們是同一機制：模型不直接碰數據庫，而是發出一份「請調用某某函數、參數如下」的結構化請求，由運行時執行。產品名詞在 2023–2026 年間換了幾輪，對照如下：

OpenAI 後來把 functions 收進 tools，並加上 strict。Anthropic 叫 tool_use / input_schema。Gemini 叫 function declarations。MCP 用 JSON-RPC tools/call。名字不同，arguments 都是 JSON object。把「Function Calling 過時了」寫成遷移理由通常是錯的——過時的是舊字段名，不是機制。

同一份發票搜索工具，OpenAI strict tool 的寫法如下。注意 strict 下所有 properties 必須列入 required，否則模型可以合法地省略你以爲有默認值的字段：

{
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "description": "Search invoices by date range and status",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "startDate": { "type": "string", "format": "date" },
        "endDate": { "type": "string", "format": "date" },
        "status": {
          "type": "string",
          "enum": ["draft", "sent", "paid", "void"]
        }
      },
      "required": ["startDate", "endDate", "status"],
      "additionalProperties": false
    }
  }
}

模型若決定調用，典型 tool_calls 項長這樣。arguments 仍是字符串，運行時必須先 parse 再校驗，不要直接 JSON.parse 失敗就當模型故障——先分清是語法壞了還是 Schema 不合。分類法見AI 生成 JSON 錯誤指南。

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "arguments": "{\"startDate\":\"2026-01-01\",\"endDate\":\"2026-01-31\",\"status\":\"paid\"}"
  }
}

JSON 爲什麼是 Agent 的契約語言

一條 Agent 流水線裏至少有三份 JSON，形狀應來自同一份 canonical Schema：

1. 工具定義：name / description / parameters（或 MCP inputSchema）。
2. 模型 arguments：選中的鍵值，常以字符串形式出現在 tool_calls 裏。
3. 工具結果：運行時寫回的 ok / result 或錯誤信封，供模型決定下一跳。

還可以有第四份：模型最終答覆的 Structured Output。它描述「給用戶或下游系統的答案長什麼樣」，不是「調用 searchInvoices 要什麼」。兩份 Schema 語法相同、語義不同，應分文件、分版本。詳見AI Structured Output 教程。

工具執行成功後，回執建議固定信封，而不是把下游 HTTP 原文原樣丟給模型。下面的 result 只暴露業務需要的字段；原始響應進日誌。模型看到穩定形狀，重試與彙總纔可預期：

{
  "toolCallId": "call_8f3a",
  "name": "searchInvoices",
  "ok": true,
  "result": {
    "count": 2,
    "items": [
      { "id": "INV-1042", "total": 1280.5, "currency": "USD" },
      { "id": "INV-1048", "total": 640.0, "currency": "USD" }
    ]
  }
}

2026 各棧：OpenAI、Anthropic、Gemini、MCP

沒有「一個 Schema 走天下」，但 Tool Calling 的數據結構在收斂：arguments 是 JSON object，契約基於 JSON Schema 子集。

MCP 是發現與傳輸，不是類型系統。inputSchema 聲明形狀，Server 仍要本地 parse + Schema 校驗。字段對照與一份 Schema 三處複用，見MCP 與 JSON Schema。多 Agent 互調走 A2A 的 message/send，技能清單裏同樣掛 Schema——那是 Agent 對 Agent，不是模型對工具。對照A2A vs MCP。

無狀態 MCP 去掉 Session 之後更適合水平擴展，但不會自動修好 arguments。緩存了舊 tools/list，就會把錯誤形狀寫進調用。協議細節見Stateless MCP 解析。

落地校驗與 JSONVue 實操

每個 hop 固定三步：parse → Schema → 業務規則。模型再聰明，也不替代這三步。

1. arguments 字符串：JSON.parse；失敗則記下 raw 與 tool_call id，返回可重試的錯誤信封。
2. 對照 parameters / inputSchema 做 Draft 2020-12 校驗，輸出 path 與 keyword。
3. 業務門：日期範圍合法、枚舉與權限匹配、外鍵存在。通過後再打下游 API。

聯調時把三份 JSON 並排：模型吐出的 arguments、你發給 MCP 或 HTTP 的 body、Server 實際使用的對象。形狀不一致，問題幾乎總在適配層。瀏覽器裏：JSON 格式化確認 parse；JSON Schema 校驗對 arguments 與 Schema 文件；JSON Diff對比模型 arguments 與下游 body。固定 fixture：valid、missing-field、wrong-enum，CI 與手工排查共用。

延伸閱讀：MCP 與 JSON Schema、Structured Output、AI JSON 錯誤指南、A2A vs MCP。

常見問題 FAQ

總結與下一步

AI Agent 在 2026 年可以概括成：模型在循環裏選擇行動，運行時執行工具，JSON Schema 描述每一跳的形狀。Tool Calling 與 Function Calling 是同一機制的產品名詞；MCP、A2A、Structured Output 管的是不同 hop，不要共用一份文件硬套。

下一步：列出你係統裏的三份 JSON（定義、arguments、result），確認它們是否同源 Schema；用 JSONVue 跑通一條 valid / 缺字段 / 錯誤枚舉。協議細節讀 MCP 文，最終答覆形狀讀 Structured Output，失敗分層讀 JSON 錯誤指南。