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 错误指南。