前两天，Manus 爆火，其邀请码一度被炒到上万元（道听途说的）。紧随其后，开源社区迅速推出了 OpenManus，短短两天内 GitHub Star 数量突破 15K+（开始写文章前还是 14.5 K），且仍在持续增长。这不仅反映了用户对 Manus 这种 AI Agent 的极大兴趣，更体现了 AI 应用在交互范式上的新趋势。
长期以来，我们主要通过 云端大模型（如 ChatGPT、Claude）与 AI 进行交互，但云端 AI 也存在一些不可忽视的局限性：
Manus 可能是人们想象中的 AI Agent。但更深层次来看，Manus 及其开源替代 OpenManus 的大火，反映了 AI 应用的三种核心交互范式正在逐步演进：
Function Calling → MCP（Model Context Protocol）→ AI Agent。
这三种范式代表了 AI 助手从简单 API 调用，到标准协议，再到完全自主智能体的演进路径
Function Calling 是 AI 与外部系统交互最开始的一种机制，它允许 LLM 在对话过程中自动调用 预定义的函数（API） 来执行某些任务。换句话说，Function Calling 让 AI 不仅仅是回答问题的助手，而是能够主动调用外部服务，执行特定功能的智能体。
Function Calling 充当了 AI 模型与外部系统之间的桥梁，不同的 AI 平台对 Function Calling 有不同的实现方式。例如：
实现 Function Calling 需要以下几个步骤：
Function Calling 的优势
✅ 低开发成本：
开发者只需定义 API，AI 便可调用，无需训练新模型。
✅ 可控性强：
开发者可以严格规定 AI 能调用的函数，确保安全性。
✅ 适用于单步任务：
适合天气查询、数据库查询、发送邮件等任务。
Function Calling 的局限性
❌ 缺乏上下文管理
❌ 不适用于复杂任务
❌ 不同 AI 平台互不兼容
以 Claude 官方描述为例子，大概是这样：
以 Anthropic 官方文档 使用 Claude 的工具功能 为例，使用 Claude Tool Use API 进行工具调用的完整示例如下：
在 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"]
}
}
]
}
在 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"
}
Claude 识别到 get_weather 工具可用于回答用户问题，并返回 tool_use 事件：
{
"role": "assistant",
"content": [
{
"type": "tool_use",
"id": "toolu_01A09q90qw90lq917835lq9",
"name": "get_weather",
"input": {
"location": "San Francisco",
"unit": "celsius"
}
}
]
}
此时，Claude 等待外部工具执行，然后返回结果。
在后端，我们接收到 get_weather 的调用信息，并查询天气 API（如 OpenWeatherMap），然后返回结果：
{
"role": "user",
"content": [
{
"type": "tool_result",
"tool_use_id": "toolu_01A09q90qw90lq917835lq9",
"content": "当前温度为 15°C，晴朗。"
}
]
}
Claude 解析 tool_result 并向用户提供最终回答：
{
"role": "assistant",
"content": "旧金山目前的温度是 15°C，天气晴朗。"
}
最终，用户收到的回复可能是：
★“旧金山目前的温度是 15°C，天气晴朗。”
Function Calling 解决了 AI 访问外部工具的问题，但它无法管理上下文、无法执行多步骤任务。因此，MCP 作为 Function Calling 的进化版本，提供了 更强的上下文管理能力，使 AI 可以在多个 API 之间进行协作，从而完成更复杂的任务。
MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 在 2024 年 11 月推出的开放协议，旨在提供一种标准化方式，让 LLM 访问外部 API 和数据源。相较于 Function Calling，MCP 具备 更强的上下文管理能力，使 AI 能够在多个 API 之间进行协作，从而完成更复杂的任务。
在过去的一年里，AI 模型（如 GPT-4.5、Claude Sonnet 3.7、DeepSeek R1）在推理能力和减少幻觉方面取得了显著进步。然而，尽管 AI 应用爆发式增长，它们仍然主要作为独立服务，而不是无缝集成到现有系统中。
例如：
设想一个真实的开发环境，如果 IDE 具备 AI 能力，它应当能够：
然而，这些功能的实现并非易事，因为：
MCP 提供了一个 开放、通用、可扩展 的协议，解决了 AI 无法高效集成现有系统 的问题。
在 MCP 之前，OpenAI 曾推出 Function Calling，但它仍然是封闭的 API 机制，无法形成通用标准。而 MCP 作为 行业标准，被多个技术社区和企业采纳，推动了 AI 在 IDE、云服务、数据库、API 生态 等多个领域的应用。
但是最终成不成，还得看社区的接受程度以及大厂是否加入。
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 架构图：
MCP Server 作为 AI Agent 的工具接口，告诉 AI 有哪些可用的服务，并提供 调用 API 的能力。
例如：
| 特性 | Function Calling | MCP |
|---|---|---|
| 调用方式 | 由 AI 直接调用 API | 通过标准化协议与多个服务交互 |
| 上下文管理 | 仅支持单次调用 | 具备 多轮交互 和 任务编排 能力 |
| 适用场景 | 简单任务（如查询天气） | 复杂任务（如 DevOps 自动化） |
| 可扩展性 | 需要为每个 API 定制代码 | 通用协议，可复用 |
MCP 不仅能调用 API，还支持：
在 MCP 之前，AI Agent 需要手动整合多个 API，开发者必须：
MCP 通过 标准化协议 解决了这些问题，使 AI Agent 可以自动发现、调用、管理 API，无需开发者手动配置。
AI Agent（人工智能代理）是当前可见的AI 交互范式的终极形态，它不仅仅是一个调用 API 的助手，而是一个 能够自主决策、执行任务，并持续优化自身行为 的自治智能体。相比 Function Calling 和 MCP，AI Agent 不再依赖用户的逐步指令，而是能够 自主规划任务，并动态调整执行方案。
我们可以用一个简单的对比来理解这三者的区别：
| 交互范式 | Function Calling | MCP | AI Agent |
|---|---|---|---|
| AI 角色 | API 调用助手 | 任务编排器 | 自主智能体 |
| 任务执行 | 需要用户明确指示调用 API | 可管理多个 API 交互 | 可自主决策、迭代任务 |
| 上下文管理 | 无记忆，每次调用独立 | 具备多轮交互能力 | 具备长期记忆，能适应变化 |
| 适用场景 | 单步 API 任务 | 跨 API 任务编排 | 复杂、多阶段任务（如自动化运营、智能助手） |
换句话说，AI Agent 具备真正的「智能」，它可以：
AI Agent 具备四项关键能力，使其区别于 Function Calling 和 MCP：
Agent 在接收到用户指令后，首先会进行 任务分解，确定达成目标所需的各个步骤。例如：
★用户需求：帮我预订一间符合我过去偏好的酒店，并用公司邮箱发送确认邮件。
传统 Function Calling 方式：
search_hotels API，查询符合条件的酒店列表。book_hotel API 进行预订。send_email API 发送确认邮件。AI Agent 方式：
search_hotels API 并筛选合适选项，根据历史数据自动推荐最优解。book_hotel API 自动完成预订，无需用户干预。send_email API 发送确认邮件，附带订单详情。Agent 无需用户手动执行每一步，而是自主规划整个任务链。
AI Agent 具备 动态 API 调用能力，它可以：
示例：
★任务：用户让 AI 预订一张去巴黎的机票，并选择最便宜的航班。
如果 get_flight_prices API 失败：
get_backup_prices API，但仍需用户介入。Agent 具备 自适应能力，可以 动态应对变化和失败情况。
Function Calling 和 MCP 都是「短期记忆」系统，每次请求都是独立的，而 AI Agent 具备 长期记忆能力，它可以：
示例：
★任务：用户让 AI 预订一张去巴黎的机票，并选择最便宜的航班。
下次用户预订机票，Agent 无需用户重复输入这些偏好，而是 自动优化查询条件。
AI Agent 具备 自主决策能力，它可以：
示例：
★任务：用户让 AI 规划一次日本旅行，包括机票、酒店和活动推荐。
Function Calling：
search_flights、search_hotels、search_activities API，并自己整合信息。MCP：
AI Agent：
Agent 具备的 自主决策能力，让 AI 真正具备“智能”。
OpenManus 是一个框架，当前还是是一个简单的框架，简单的实现了 AI Agent 的这 4 个能力。
OpenManus 通过 PlanningAgent 管理任务规划，其本身也是一个 LLM 的 API 请求，其 Prompt 翻译成中文，大概如下：
★你是一名专家级的规划代理，负责通过创建和管理结构化计划来解决复杂问题。
★你的工作包括：
分析请求，理解任务范围； 使用 planning工具 创建清晰、可执行的计划；根据需要执行步骤，使用可用工具完成任务； 跟踪进度并动态调整计划，确保任务顺利进行； 使用 finish结束任务，当任务完成时正式收尾。
★可用工具将根据任务不同而变化，但可能包括：
** planning**：创建、更新和跟踪计划（可执行命令：create、update、mark_step 等）。** finish**：任务完成时用于结束任务。
★请将任务拆解为逻辑清晰、循序渐进的步骤，并考虑任务的依赖关系及验证方法。
在 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"
在 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:]
在 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()
这四个核心能力通过不同的模块协同工作，形成了一个完整的智能代理系统：
随着 AI Agent 技术的发展，它可能会在多个领域发挥作用：
AI Agent 将彻底改变人机交互方式，从 被动响应 变为 主动辅助，甚至 完全自主执行任务。
从 Function Calling 到 MCP，再到 AI Agent，我们即将见证了 AI 交互模式的重大演进：
AI 未来的发展方向，已经从「回答问题」向「主动执行任务」转变。
随着 AI Agent 技术的成熟，未来，我们可能会看到：
以上。