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。模型会换，协议会增，口径应该先稳定。