当前 LLM 与 AI 应用交互的三大范式：从工具调用到自主智能的进化之路

前两天，Manus 爆火，其邀请码一度被炒到上万元（道听途说的）。紧随其后，开源社区迅速推出了 OpenManus ，短短两天内 GitHub Star 数量突破 15K+（开始写文章前还是 14.5 K），且仍在持续增长。这不仅反映了用户对 Manus 这种 AI Agent 的极大兴趣，更体现了 AI 应用在交互范式上的新趋势。

长期以来，我们主要通过 云端大模型（如 ChatGPT、Claude）与 AI 进行交互，但云端 AI 也存在一些不可忽视的局限性：

• 隐私问题：云端模型需要上传数据，部分用户对数据安全存疑。

• 响应速度：本地 AI 可以减少延迟，提供更流畅的用户体验。

• 个性化：本地 AI 可以更深入理解用户需求，而云端模型通常是通用的，个性化能力有限。

Manus 可能是人们想象中的 AI Agent。但更深层次来看，Manus 及其开源替代 OpenManus 的大火，反映了 AI 应用的三种核心交互范式正在逐步演进：

Function Calling → MCP（Model Context Protocol）→ AI Agent。

这三种范式代表了 AI 助手从简单 API 调用，到标准协议，再到完全自主智能体的演进路径

1. Function Calling：AI 作为「插件调用器」

Function Calling 是 AI 与外部系统交互最开始的一种机制，它允许 LLM 在对话过程中自动调用 预定义的函数（API） 来执行某些任务。换句话说，Function Calling 让 AI 不仅仅是回答问题的助手，而是能够主动调用外部服务，执行特定功能的智能体。

Function Calling 充当了 AI 模型与外部系统之间的桥梁，不同的 AI 平台对 Function Calling 有不同的实现方式。例如：

• OpenAI 的 GPTs：允许开发者定义自定义函数，GPT 在需要时调用这些函数。

• Anthropic Claude 的 Tool Use：支持类似的工具调用机制，Claude 可以基于用户请求自动选择合适的工具。

• 阿里百炼（Qwen）的插件：提供插件机制，让 LLM 能够调用外部 API 执行任务。

1.1 Function Calling 的基本流程

实现 Function Calling 需要以下几个步骤：

1. 定义可调用的函数

• 由开发者提供 API，并定义函数的名称、描述、输入参数和返回值。

2. AI 识别何时调用函数

• 当用户的请求涉及函数相关的任务时，AI 需要决定是否调用函数，并填充参数。

3. AI 生成函数调用请求

• AI 生成结构化的 JSON 格式请求，向外部 API 发送调用指令。

4. 外部 API 执行任务并返回结果

• 服务器或插件执行任务，并返回结果给 AI。

5. AI 解析结果并回复用户

• AI 结合 API 返回的数据，生成最终的用户响应。

1.2 Function Calling 的优缺点

Function Calling 的优势

✅ 低开发成本：

开发者只需定义 API，AI 便可调用，无需训练新模型。

✅ 可控性强：

开发者可以严格规定 AI 能调用的函数，确保安全性。

✅ 适用于单步任务：

适合天气查询、数据库查询、发送邮件等任务。

Function Calling 的局限性

❌ 缺乏上下文管理

• Function Calling 不具备记忆能力，每次调用都是独立的，无法跨会话存储调用历史。

• 例如，用户问："昨天查的天气怎么样？" AI 可能不会记得之前的查询。

❌ 不适用于复杂任务

• Function Calling 适用于边界清晰、描述明确 的任务，但对多步骤任务、推理任务支持较差。

• 例如："帮我订一个符合我过去偏好的酒店，并用公司邮箱发确认邮件。" 这个任务涉及搜索、筛选、邮件发送，Function Calling 很难完成。

❌ 不同 AI 平台互不兼容

• OpenAI、Claude、Qwen 的 Function Calling 机制不同，开发者需要针对不同平台编写不同的 API 适配逻辑。

以 Claude 官方描述为例子，大概是这样：

1.3 Claude 工具调用示

以 Anthropic 官方文档 使用 Claude 的工具功能 为例，使用 Claude Tool Use API 进行工具调用的完整示例如下：

1. 定义工具

在 API 请求中，我们需要定义 Claude 可调用的工具。例如，我们定义一个 天气查询工具 get_weather，用于获取指定城市的天气信息。

示例工具定义 (tools 参数)：

{

"tools": [

{

"name": "get_weather",

"description": "获取指定城市的当前天气",

"input_schema": {

"type": "object",

"properties": {

"location": {

"type": "string",

"description": "城市名称，例如 '北京' 或 'San Francisco'"

},

"unit": {

"type": "string",

"enum": ["celsius", "fahrenheit"],

"description": "温度单位，'celsius' 或 'fahrenheit'"

}

},

"required": ["location"]

}

}

]

}

2. 发送用户请求

在 API 请求中，我们可以提供用户的输入，例如：

{

"model": "claude-3-opus-20240229",

"messages": [

{

"role": "user",

"content": "旧金山现在的天气如何？请使用 get_weather 工具获取信息。"

}

],

"tools": [

{

"name": "get_weather",

"description": "获取指定城市的当前天气",

"input_schema": {

"type": "object",

"properties": {

"location": {

"type": "string",

"description": "城市名称，例如 '北京' 或 'San Francisco'"

},

"unit": {

"type": "string",

"enum": ["celsius", "fahrenheit"],

"description": "温度单位，'celsius' 或 'fahrenheit'"

}

},

"required": ["location"]

}

}

],

"tool_choice": "auto"

}

3. Claude 触发工具调用

Claude 识别到 get_weather 工具可用于回答用户问题，并返回 tool_use 事件：

{

"role": "assistant",

"content": [

{

"type": "tool_use",

"id": "toolu_01A09q90qw90lq917835lq9",

"name": "get_weather",

"input": {

"location": "San Francisco",

"unit": "celsius"

}

}

]

}

此时，Claude 等待外部工具执行，然后返回结果。

4. 服务器执行工具逻辑

在后端，我们接收到 get_weather 的调用信息，并查询天气 API（如 OpenWeatherMap），然后返回结果：

{

"role": "user",

"content": [

{

"type": "tool_result",

"tool_use_id": "toolu_01A09q90qw90lq917835lq9",

"content": "当前温度为 15°C，晴朗。"

}

]

}

5. Claude 处理工具结果并回复

Claude 解析 tool_result 并向用户提供最终回答：

{

"role": "assistant",

"content": "旧金山目前的温度是 15°C，天气晴朗。"

}

最终，用户收到的回复可能是：

"旧金山目前的温度是 15°C，天气晴朗。"

Function Calling 解决了 AI 访问外部工具的问题，但它无法管理上下文、无法执行多步骤任务 。因此，MCP 作为 Function Calling 的进化版本，提供了 更强的上下文管理能力，使 AI 可以在多个 API 之间进行协作，从而完成更复杂的任务。

2. MCP：AI 时代的协议标准

MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 在 2024 年 11 月推出的开放协议，旨在提供一种标准化方式，让 LLM 访问外部 API 和数据源。相较于 Function Calling，MCP 具备 更强的上下文管理能力，使 AI 能够在多个 API 之间进行协作，从而完成更复杂的任务。

2.1 为什么 MCP 可能会是一个突破？

在过去的一年里，AI 模型（如 GPT-4.5、Claude Sonnet 3.7、DeepSeek R1 ）在推理能力和减少幻觉方面取得了显著进步。然而，尽管 AI 应用爆发式增长，它们仍然主要作为独立服务，而不是无缝集成到现有系统中。

例如：

• AI 仍然无法同时完成 联网搜索、发送邮件、发布博客 等多个任务，尽管单个任务的实现并不难。

• AI 无法直接与 IDE、数据库、云服务 等现有工具集成，开发者仍需手动操作。

设想一个真实的开发环境，如果 IDE 具备 AI 能力，它应当能够：

• 查询本地数据库，辅助开发者理解数据结构。

• 搜索 GitHub Issue，判断某个问题是否是已知 bug。

• 自动 Code Review，并将 PR 反馈发送到 Slack 或邮件。

• 查询并修改 AWS、Azure 配置，实现自动化部署。

然而，这些功能的实现并非易事，因为：

• 企业级数据敏感，需要严格的访问控制和权限管理。

• 缺乏开放、通用的协议，导致 AI 很难与不同的服务对接。

MCP 提供了一个 开放、通用、可扩展 的协议，解决了 AI 无法高效集成现有系统 的问题。

在 MCP 之前，OpenAI 曾推出 Function Calling ，但它仍然是封闭的 API 机制 ，无法形成通用标准。而 MCP 作为 行业标准 ，被多个技术社区和企业采纳，推动了 AI 在 IDE、云服务、数据库、API 生态 等多个领域的应用。

但是最终成不成，还得看社区的接受程度以及大厂是否加入。

2.2 MCP 组成

MCP 由以下五个部分组成：

| 组件 | 作用 |

|------|------|

| MCP Host | 运行 AI 模型的应用，如 Claude Desktop、Cursor |

| MCP Client | 在 Host 内部，管理与 MCP 服务器的通信 |

| MCP Server | 提供 工具、数据源、API，供 AI 调用 |

| Local Data Sources | 本地数据，如 文件系统、数据库 |

| Remote Services | 远程 API，如 GitHub、Slack、AWS |

下图是官方提供的 MCP 架构图：

2.3 MCP 如何与 AI Agent 交互？

MCP Server 作为 AI Agent 的工具接口 ，告诉 AI 有哪些可用的服务 ，并提供 调用 API 的能力。

例如：

1. AI 需要搜索 GitHub 代码库并创建 Issue。

2. MCP Server 提供 search_repositories 和 create_issue API。

3. AI 代理根据任务需求决定调用顺序。

4. AI 通过 MCP 查询本地日志 → 搜索 GitHub Issue → 创建新 Issue → 发送 Slack 通知，形成完整的自动化工作流。

2.4 为什么 MCP 比 Function Calling 更强？

1. Function Calling 的局限性

| 特性 | Function Calling | MCP |

|---------|-----------------|------|

| 调用方式 | 由 AI 直接调用 API | 通过标准化协议与多个服务交互 |

| 上下文管理 | 仅支持单次调用 | 具备 多轮交互 和 任务编排 能力 |

| 适用场景 | 简单任务（如查询天气） | 复杂任务（如 DevOps 自动化） |

| 可扩展性 | 需要为每个 API 定制代码 | 通用协议，可复用 |

MCP 不仅能调用 API，还支持：

• 跨服务任务管理（如 AI 在 IDE 内操作代码，同时管理云端资源）。

• 持久化上下文（AI 可记住任务状态，避免重复操作）。

• 标准化 API 交互（不同 AI 平台可共用 MCP 服务器）。

2. MCP 解决了 AI Agent 的碎片化问题

在 MCP 之前，AI Agent 需要手动整合多个 API，开发者必须：

1. 定义 Function Calling API，并为每个 API 编写调用逻辑。

2. 管理 API 之间的上下文，确保多步任务正确执行。

3. 处理不同 API 返回的数据格式，防止解析错误。

MCP 通过 标准化协议 解决了这些问题，使 AI Agent 可以自动发现、调用、管理 API，无需开发者手动配置。

3. AI Agent：完全闭环的智能体

3.1 什么是 AI Agent？

AI Agent（人工智能代理）是当前可见的AI 交互范式的终极形态 ，它不仅仅是一个调用 API 的助手，而是一个 能够自主决策、执行任务，并持续优化自身行为 的自治智能体。相比 Function Calling 和 MCP，AI Agent 不再依赖用户的逐步指令 ，而是能够 自主规划任务，并动态调整执行方案。

我们可以用一个简单的对比来理解这三者的区别：

| 交互范式 | Function Calling | MCP | AI Agent |

|-------------|----------------|------|----------|

| AI 角色 | API 调用助手 | 任务编排器 | 自主智能体 |

| 任务执行 | 需要用户明确指示调用 API | 可管理多个 API 交互 | 可自主决策、迭代任务 |

| 上下文管理 | 无记忆，每次调用独立 | 具备多轮交互能力 | 具备长期记忆，能适应变化 |

| 适用场景 | 单步 API 任务 | 跨 API 任务编排 | 复杂、多阶段任务（如自动化运营、智能助手） |

换句话说，AI Agent 具备真正的「智能」，它可以：

• 自主规划任务：无须手动指定 API 调用顺序，AI Agent 可根据目标自动生成执行步骤。

• 动态调整策略：如果 API 失败或结果不符合预期，Agent 可以自主尝试其他方法，而不是直接报错。

• 长期记忆 & 适应性 ：Agent 具备 长期记忆，可以在不同任务之间保持上下文，甚至学习用户的偏好。

3.2 AI Agent 的核心能力

AI Agent 具备四项关键能力，使其区别于 Function Calling 和 MCP：

1. 任务分解与规划

Agent 在接收到用户指令后，首先会进行 任务分解，确定达成目标所需的各个步骤。例如：

用户需求：帮我预订一间符合我过去偏好的酒店，并用公司邮箱发送确认邮件。

传统 Function Calling 方式：

1. 需要用户手动调用 search_hotels API，查询符合条件的酒店列表。

2. 需要用户手动筛选酒店，并调用 book_hotel API 进行预订。

3. 需要用户手动调用 send_email API 发送确认邮件。

AI Agent 方式：

1. 自动查询用户历史预订偏好（如价格区间、酒店品牌、地理位置）。

2. 调用 search_hotels API 并筛选合适选项，根据历史数据自动推荐最优解。

3. 调用 book_hotel API 自动完成预订，无需用户干预。

4. 调用 send_email API 发送确认邮件，附带订单详情。

Agent 无需用户手动执行每一步 ，而是自主规划整个任务链。

2. 动态 API 调用 & 失败恢复

AI Agent 具备 动态 API 调用能力，它可以：

• 根据需求，动态选择最优 API（无须用户手动指定）。

• 在 API 失败时，自动尝试替代方案，而不是直接报错。

• 根据实时数据调整策略，例如价格变动、库存变化等。

示例：

任务：用户让 AI 预订一张去巴黎的机票，并选择最便宜的航班。

如果 get_flight_prices API 失败：

• Function Calling：直接报错，用户需要手动重试。

• MCP：可能会调用 get_backup_prices API，但仍需用户介入。

• AI Agent：会 自动重试或切换至备用 API，如 Skyscanner、Google Flights，甚至尝试不同日期。

Agent 具备 自适应能力 ，可以 动态应对变化和失败情况。

3. 记忆 & 长期学习

Function Calling 和 MCP 都是「短期记忆」系统 ，每次请求都是独立的，而 AI Agent 具备 长期记忆能力，它可以：

• 记住用户偏好（如常住城市、喜欢的航司、预算范围）。

• 根据历史交互优化决策（例如某个用户偏好五星级酒店，Agent 会优先推荐）。

• 跨任务共享信息（预订航班后，Agent 还会提醒用户预订酒店）。

示例：

任务：用户让 AI 预订一张去巴黎的机票，并选择最便宜的航班。

• Function Calling / MCP：会查询机票，但不会记住用户的航班偏好。

• AI Agent：会记住用户过去的航班选择，例如：

• 偏好直飞，而非转机。

• 偏好下午航班，而非早晨航班。

• 偏好特定航司（如国航或法航）。

下次用户预订机票，Agent 无需用户重复输入这些偏好 ，而是 自动优化查询条件。

4. 自主决策 & 反馈迭代

AI Agent 具备 自主决策能力，它可以：

• 根据环境变化调整策略（如价格变动、天气影响）。

• 在多种可能性中选择最优解（如多个 API 返回不同结果时，Agent 可权衡选择）。

• 与用户交互，智能迭代（如果用户不满意推荐，Agent 会优化结果）。

示例：

任务：用户让 AI 规划一次日本旅行，包括机票、酒店和活动推荐。

Function Calling：

• 需要用户手动调用 search_flights、search_hotels、search_activities API，并自己整合信息。

MCP：

• 可以让 AI 代理协调多个 API，但仍然需要用户逐步确认。

AI Agent：

1. 查询用户偏好（如预算、喜欢的景点、过往旅行记录）。

2. 生成最佳行程方案（自动选择航班、酒店、活动）。

3. 主动与用户交互（如果用户不喜欢某个选项，Agent 会自动调整）。

4. 动态优化计划（如果机票涨价，Agent 会推荐更便宜的替代方案）。

Agent 具备的 自主决策能力 ，让 AI 真正具备"智能"。

3.3 OpenManus 的 4 个能力体现

OpenManus 是一个框架，当前还是是一个简单的框架，简单的实现了 AI Agent 的这 4 个能力。

1. 任务分解与规划

OpenManus 通过 PlanningAgent 管理任务规划，其本身也是一个 LLM 的 API 请求，其 Prompt 翻译成中文，大概如下：

你是一名专家级的规划代理，负责通过创建和管理结构化计划来解决复杂问题。
你的工作包括：

1. 分析请求，理解任务范围；
2. 使用 planning 工具 创建清晰、可执行的计划；
3. 根据需要执行步骤，使用可用工具完成任务；
4. 跟踪进度并动态调整计划，确保任务顺利进行；
5. 使用 finish 结束任务，当任务完成时正式收尾。
   可用工具将根据任务不同而变化，但可能包括：

• planning：创建、更新和跟踪计划（可执行命令：create、update、mark_step 等）。
• finish：任务完成时用于结束任务。
  请将任务拆解为逻辑清晰、循序渐进的步骤 ，并考虑任务的依赖关系及验证方法。

2. 动态 API 调用 & 失败恢复

在 OpenManus 的 toolcall 的调用中，如下：

async def act(self) -> str:

try:

result = await self.execute_tool(command)

self.step_execution_tracker[tool_call_id]["status"] = "completed"

except Exception as e:

logger.warning(f"Failed to execute tool: {e}")

# 失败恢复机制

self.step_execution_tracker[tool_call_id]["status"] = "failed"

• 支持动态工具调用

• 包含错误处理和恢复机制

• 工具执行状态追踪

3. 记忆 & 长期学习

在 schema.py 中通过 Memory 类实现：

class Memory(BaseModel):

messages: List[Message] = Field(default_factory=list)

max_messages: int = Field(default=100)

def add_message(self, message: Message) -> None:

self.messages.append(message)

if len(self.messages) > self.max_messages:

self.messages = self.messages[-self.max_messages :]

def get_recent_messages(self, n: int) -> List[Message]:

return self.messages[-n:]

• 维护对话历史

• 支持消息存储和检索

• 实现上下文记忆管理

4. 自主决策 & 反馈迭代

在 agent/base.py 中实现：

async def step(self) -> str:

# 思考和决策

should_continue = await self.think()

if not should_continue:

self.state = AgentState.FINISHED

return "Task completed"

# 执行动作

result = await self.act()

# 检查是否陷入循环

if self.is_stuck():

self.handle_stuck_state()

• 自主思考和决策能力

• 循环检测和处理

• 状态管理和迭代优化

• 支持反馈调整

这四个核心能力通过不同的模块协同工作，形成了一个完整的智能代理系统：

• 规划模块负责任务分解

• 工具调用模块处理动态执行

• 记忆模块维护上下文

• 基础代理类实现决策逻辑

这种设计使得系统能够灵活应对各种任务，并在执行过程中不断优化和调整。

3.4 AI Agent 的应用场景

随着 AI Agent 技术的发展，它可能会在多个领域发挥作用：

• 智能办公助手：自动处理会议安排、邮件回复、文档整理、报告输出。

• 自动化 DevOps：监控服务器状态、自动执行 CI/CD、处理告警。

• AI 财务顾问：分析用户消费习惯，提供投资建议。

• 个性化 AI 助手：根据用户习惯优化推荐，如智能家居控制、健康管理等。

AI Agent 将彻底改变人机交互方式 ，从 被动响应 变为 主动辅助 ，甚至 完全自主执行任务。

4. 从 Function Calling 到 AI Agent，AI 交互范式的最终进化

从 Function Calling 到 MCP ，再到 AI Agent，我们即将见证了 AI 交互模式的重大演进：

1. Function Calling（工具调用）：AI 作为 API 调用助手，适用于简单任务（如天气查询、数据库查询）。

2. MCP（模型上下文协议）：AI 具备上下文管理能力，可协调多个 API 执行复杂任务（如 DevOps 自动化）。

3. AI Agent（自主智能体）：AI 具备自主决策、长期记忆、任务规划能力，实现真正的智能交互。

AI 未来的发展方向，已经从「回答问题」向「主动执行任务」转变。

随着 AI Agent 技术的成熟，未来，我们可能会看到：

• AI Agent 的崛起：Manus 只是开始，未来会有更多类似的 AI Agent 出现，并针对不同场景进行优化。

• 云+本地混合模式：本地 AI 负责隐私数据处理，云端 AI 负责复杂推理，两者结合提供最佳体验。

• AI 操作系统的雏形：AI 不再只是一个聊天助手，而是一个真正的「数字助理」，能够管理用户的日常任务、自动执行操作，并与各种应用无缝集成。

以上。