从Function Calling到Agent模式：AI工具链的技术演进与实际选型

摘要（148字）：本文系统梳理了AI工具链的技术演进路径，从基础能力层（Function Calling）、协议标准化层（MCP）、业务能力层（Skill）到流程编排层（Workflow）和整合执行层（Agent模式）。Function Calling实现AI与物理世界的原子级交互，MCP致力于标准化工具访问协议，Skill封装可复用的业务能力，Workflow处理确定性流程，而Agent模式则

全宗

692人浏览 · 2026-02-24 15:36:22

全宗 · 2026-02-24 15:36:22 发布

从Function Calling到Agent模式：AI工具链的技术演进与实际选型

日期：2026年2月24日
阅读时间：约15分钟

写在前面

过去半年，AI工具链的概念层出不穷：Function Calling、MCP、Skill、Agent模式……这些术语之间的关系是什么？各自解决什么问题？作为实际写代码的开发者，我们该如何选择？

本文基于实际项目经验，尝试理清这条技术栈的脉络。不追求概念的新颖，只追求落地的清晰。

1. Function Calling：基础能力层

1.1 它解决了什么

大模型的核心能力是生成文本，但文本是静态的。当用户问"北京今天多少度"时，模型如果仅凭训练数据回答，要么是过时的，要么是编造的。

Function Calling让模型意识到自己的局限，并主动请求外部帮助。

1.2 工作机制

# 伪代码：Function Calling的完整流程

# 第一步：定义可用工具
tools = [{
    "name": "get_weather",
    "description": "获取指定城市天气",
    "parameters": {
        "type": "object",
        "properties": {
            "city": {"type": "string"}
        },
        "required": ["city"]
    }
}]

# 第二步：用户提问
user_input = "北京今天多少度？"

# 第三步：模型判断需要调用工具，返回结构化指令
response = model.chat(user_input, tools=tools)
# 模型输出：
# {
#   "function_call": {
#     "name": "get_weather",
#     "arguments": {"city": "北京"}
#   }
# }

# 第四步：你的代码执行实际调用
weather_data = call_real_api(city="北京")  # 真实的网络请求

# 第五步：将结果回传给模型，生成最终回答
final_answer = model.chat(
    f"天气API返回：{weather_data}",
    continue_from=response
)
# 输出："北京今天晴，25°C，适宜出行。"

1.3 关键认知

Function Calling是原子操作。从人类视角看，"查天气"是一个动作；但在代码层，它拆解为：

构造请求参数
发起网络调用
解析响应数据
异常处理

这些步骤对上层不可见，但构成了AI与物理世界交互的最小单元。

2. MCP：协议标准化层

2.1 为什么会出现

Function Calling解决了"能调用"，但没解决"怎么连接"。

假设你开发了一个天气查询服务：

给Claude用，要适配它的接口格式
给Cursor用，要再写一套适配
给Kimi用，又要改一遍

MCP（Model Context Protocol）试图成为AI工具访问领域的RESTful协议：一次实现，处处可用。

2.2 架构设计

MCP采用Client-Server分离架构：

┌─────────────────┐        ┌─────────────────┐        ┌─────────────────┐
│  MCP Client     │◄─────►│  MCP Server     │◄─────►│  外部资源       │
│ （AI应用：Claude/Cursor）│ （独立部署）     │        │（文件/API/数据库）│
└─────────────────┘        └─────────────────┘        └─────────────────┘

关键设计：

MCP Client：运行在AI应用侧（如Claude Desktop），负责连接管理
MCP Server：独立部署（本地或云端），通过标准输入输出或HTTP通信
安全隔离：Server作为代理访问外部资源，AI不直接接触敏感系统

2.3 与Function Calling的关系

关键澄清：MCP与Function Calling是互补而非层级关系。

维度	Function Calling	MCP
解决的问题	模型如何表达"我要调用工具"	不同AI客户端如何标准化调用工具服务
技术层级	模型能力层	通信协议层
依赖关系	可独立实现	可独立实现，也可结合使用
类比	系统调用（syscall）	RESTful API规范

MCP Server暴露能力时无需依赖Function Calling，二者可独立实现。例如，一个MCP Server可以直接暴露HTTP接口，由Client直接调用，不经过模型的Function Calling决策。

3. Skill：业务能力层

3.1 概念来源

Skill是Claude生态（含Claude Code及主应用）及部分大模型的能力封装机制。与MCP的技术标准化导向不同，Skill更偏向业务落地——它将工具调用、业务规则、执行逻辑封装为可复用的单元。

3.2 典型结构

email-skill/
├── SKILL.md              # 核心：定义业务逻辑
│   └── # 当用户要求发邮件时：
│       # 1. 先确认收件人地址
│       # 2. 检查主题是否合规（无敏感词）
│       # 3. 调用send_email API
│       # 4. 返回发送结果摘要
├── templates/
│   └── business_email.txt
└── scripts/
    └── validate_address.py

3.3 与MCP的对比

维度	Skill	MCP
核心问题	如何把工具能力转化为可落地的业务场景	如何标准化跨平台工具访问
实现方式	文本描述（SKILL.md）+ 可选脚本	JSON-RPC协议
触发逻辑	AI根据描述在Skill定义范围内自主决策	协议握手后显式调用
灵活性	高——AI动态调整执行步骤	中——接口固定，行为确定
复用范围	目前主要限于Claude生态	跨平台（任何支持MCP的客户端）

3.4 两者的关系

Skill与MCP是竞争与互补并存：

竞争场景：简单业务流程可用Skill快速描述，无需编写MCP Server
协作场景：Skill可以调用MCP Server提供的工具，组合使用
演进趋势：Skill可能底层采用MCP协议，实现跨平台兼容

4. Workflow：流程编排层

4.1 定义与特征

Workflow是预定义的、确定性的步骤序列，用于编排确定性任务。

开始 → 步骤A → 判断条件 → 步骤B/步骤C → 结束
              ↑
           （人工审核点/AI决策节点）

核心特征：

确定性：路径预先设定，核心决策由规则或人工主导
可审计：每一步可追踪、可回滚
混合决策：现代Workflow可嵌入AI决策节点（智能审核、条件判断），也可强制人工介入

4.2 与Skill、Agent的本质区别

模式	AI决策权	适用场景
Workflow	受预定义流程约束，AI辅助执行或局部决策	财务审批、合规检查、医疗诊断等需严格审计的场景
Skill	在Skill定义的范围内自主决策执行步骤	标准化业务操作（如生成周报、处理退款）
Agent	拥有端到端的规划权和执行权，人工仅做最终监督	开放式任务（如"帮我创业"、“优化业务流程”）

关键差异：Workflow中AI的决策权受流程约束；Skill中AI在封装范围内自主决策；Agent中AI拥有最高决策权。

4.3 实际案例：费用报销系统

Workflow方案：

员工提交 → AI提取发票信息 → 人工确认金额 → 自动流转审批 → 财务打款
              ↑                              ↑
           （AI辅助，规则固定）            （人工不可跳过）

Skill方案：

员工："帮我报销上周差旅"
AI：自主判断需要
  1. 查邮件找发票
  2. 识别金额和日期
  3. 匹配公司政策（Skill中定义的规则）
  4. 生成报销单
  5. 提交系统

Agent方案：

员工："优化下公司的报销流程"
AI：自主分析现有流程痛点，提出改进方案，甚至编写新系统代码

5. Agent模式：整合执行层

5.1 代表产品

Kimi OK Computer：基于工具调用与任务规划的Agent能力
Claude Code with Agent：结合Skill和Subagent的混合模式
AutoGPT：开源自主Agent框架

5.2 核心能力

Agent模式试图最小化人工干预：

用户输入："帮我策划一场从北京到东京的商务旅行，预算1万，下周五出发"

Agent自动执行：
  1. 查航班（调用机票API）
  2. 查酒店（匹配预算和位置）
  3. 查签证要求（搜索官方信息）
  4. 生成行程表（调用日历工具）
  5. 预订推荐（等待用户确认）
  6. 发送确认邮件（调用邮件服务）

5.3 现实约束

Agent模式目前仍有明显限制：

成本：复杂任务消耗大量token
可靠性：长链条任务中错误会累积
安全：需要沙箱环境防止误操作
监督：关键决策仍需人工确认

6. 技术栈全景与选型建议

6.1 完整映射

用户意图
    │
    ▼
┌─────────────────────────────────────────┐
│  Agent模式（整合层：自主规划+执行）       │
└─────────────────────────────────────────┘
        │              │              │
        ▼              ▼              ▼
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  Skill（能力层）│  Workflow（流程层）│  MCP（协议层）  │
└─────────────┘  └─────────────┘  └─────────────┘
        │              │              │
        └──────────────┴──────────────┘
                        │
                        ▼
┌─────────────────────────────────────────┐
│  Function Calling（基础层：工具交互）    │
└─────────────────────────────────────────┘
                        │
                        ▼
实际执行（代码/外部API）

层级说明：

Function Calling：基础层，所有工具调用的底层交互语言
MCP/Skill/Workflow：并行中间层，分别解决协议标准化、业务能力封装、流程编排
Agent：整合层，整合上述组件实现自主任务执行

6.2 选型决策树

开始
  │
  ├─ 任务是否为开放式（无固定流程，需自主规划）？ ──→ Agent模式
  │
  └─ 任务有明确执行规则 ──┬─ 流程需严格审计/人工介入？ ──→ Workflow
                          │
                          ├─ 需跨多个AI平台复用工具？ ──→ MCP（可结合Skill）
                          │
                          ├─ 有标准化业务流程可封装？ ──→ Skill
                          │
                          └─ 仅需单次/简单工具调用？ ──→ Function Calling