Agent vs Function Calling：工具调用范式演进对比

Agent与Function Calling是指两种不同的LLM工具调用范式。Function Calling（函数调用）是LLM API原生支持的、将外部函数描述为结构化JSON Schema并由模型选择调用的单向执行模式；Agent（智能体）则是基于循环推理（Reasoning-Action-Observation循环）的自主执行范式，模型可以自行判断何时调用工具、解析结果、多步规划并修正错误。两者在调用机制、控制权归属、错误处理能力上存在本质差异，适用于不同的应用场景。

术语表

1. 架构对比

1.1 Function Calling 架构

Function Calling是LLM API内置的轻量级工具调用机制。工作流程为单向线性：

用户输入 → LLM解析 → 模型选择工具 → 返回结构化参数 → 应用侧执行 → 结果回填 → 最终回复

核心特征：

• 单轮调用：一次用户请求触发至多一次工具调用
• 应用侧执行：模型仅输出工具选择结果，实际执行由宿主应用完成
• 无状态循环：不维护连续的多步推理上下文
• API原生支持：OpenAI、Claude、Gemini等主流API均原生支持

1.2 Agent 架构

Agent架构在LLM之外增加了循环控制层。工作流程为循环迭代：

用户输入 → [思考 → 行动 → 观察]ⁿ → 满足终止条件 → 最终回复

核心特征：

• 多步循环：同一任务可触发多次工具调用，上一步结果是下一步的输入
• 自主决策：模型自行判断何时调用工具、调用哪个工具、何时终止
• 错误重试：工具调用失败后可自动分析原因并尝试替代方案
• 上下文累积：完整的推理链和工具结果保持在对话上下文中

2. 分类维度对比

3. Tool Schema 定义对比

Function Calling定义工具时使用JSON Schema描述参数结构：

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "获取指定城市的天气",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {"type": "string", "description": "城市名称"},
        "unit": {"type": "string", "enum": ["celsius","fahrenheit"]}
      },
      "required": ["city"]
    }
  }
}

Agent框架中工具的Schema扩展了执行上下文信息：

{
  "tool": {
    "name": "search_web",
    "description": "搜索互联网获取实时信息",
    "parameters": { /* JSON Schema */ },
    "execution": {
      "timeout_ms": 15000,
      "retry_on_failure": true,
      "max_retries": 3,
      "side_effects": false
    }
  }
}

4. 执行流程差异

4.1 Function Calling 执行流程

1. 用户: "北京今天多少度？"
2.   → LLM接收消息+工具Schema
3.   → LLM输出: tool_call(get_weather, city="北京", unit="celsius")
4.   → 应用执行 get_weather("北京","celsius") → {"temp": 28, "condition": "晴"}
5.   → 执行结果回填给LLM
6.   → LLM输出: "北京今天28°C，晴。"

4.2 Agent 执行流程

1. 用户: "帮我规划周末北京两日游，预算2000元"
2.   → Agent推理: 需要查询北京景点、天气、交通、住宿
3.   → 调用 search_web("北京周末旅游攻略")
4.   → 观察: 返回景点列表
5.   → 调用 get_weather("北京","2026-06-20")
6.   → 观察: 天气数据
7.   → 调用 search_web("北京经济型酒店")
8.   → 观察: 酒店价格信息
9.   → 汇总推理，生成完整行程规划
10.  → 输出最终回复

5. 框架支持对比

6. 选型决策因素

7. 局限与演化方向

• Function Calling的局限：无状态、无推理链、无错误恢复、工具间无依赖关系管理；复杂任务需大量应用层胶水代码
• Agent的局限：上下文开销大（推理链条增长导致token膨胀）、偶发循环死锁（模型反复调用同一工具）、时延高、成本不确定
• 演进趋势：静态Schema → 动态工具发现（MCP/OpenAPI）；单一范式 → 混合模式（Function Calling作为Agent的基础原子操作）；开发范式趋同（统一的Tool接口标准）

参见

• MCP协议详解 — 标准化工具接口规范
• Agent框架横向对比 — 主流Agent框架架构比较
• OpenAI Function Calling API文档
• LangGraph Agent Executor实现源码
• Anthropic Tool Use规范