前两天，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 需要以下几个步骤：
-
定义可调用的函数 -
由开发者提供 API，并定义函数的名称、描述、输入参数和返回值。
-
-
AI 识别何时调用函数 -
当用户的请求涉及函数相关的任务时，AI 需要决定是否调用函数，并填充参数。
-
-
AI 生成函数调用请求 -
AI 生成结构化的 JSON 格式请求，向外部 API 发送调用指令。
-
-
外部 API 执行任务并返回结果 -
服务器或插件执行任务，并返回结果给 AI。
-
-
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 的能力。
例如：
-
AI 需要搜索 GitHub 代码库并创建 Issue。 -
MCP Server 提供 search_repositories 和 create_issue API。 -
AI 代理根据任务需求决定调用顺序。 -
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，开发者必须：
-
定义 Function Calling API，并为每个 API 编写调用逻辑。 -
管理 API 之间的上下文，确保多步任务正确执行。 -
处理不同 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 方式：
-
需要用户手动调用 search_hotelsAPI，查询符合条件的酒店列表。 -
需要用户手动筛选酒店，并调用 book_hotelAPI 进行预订。 -
需要用户手动调用 send_emailAPI 发送确认邮件。
AI Agent 方式：
-
自动查询用户历史预订偏好（如价格区间、酒店品牌、地理位置）。 -
调用 search_hotelsAPI 并筛选合适选项，根据历史数据自动推荐最优解。 -
调用 book_hotelAPI 自动完成预订，无需用户干预。 -
调用 send_emailAPI 发送确认邮件，附带订单详情。
Agent 无需用户手动执行每一步，而是自主规划整个任务链。
2. 动态 API 调用 & 失败恢复
AI Agent 具备 动态 API 调用能力，它可以：
-
根据需求，动态选择最优 API（无须用户手动指定）。 -
在 API 失败时，自动尝试替代方案，而不是直接报错。 -
根据实时数据调整策略，例如价格变动、库存变化等。
示例：
★任务：用户让 AI 预订一张去巴黎的机票，并选择最便宜的航班。
如果 get_flight_prices API 失败：
-
Function Calling：直接报错，用户需要手动重试。 -
MCP：可能会调用 get_backup_pricesAPI，但仍需用户介入。 -
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_activitiesAPI，并自己整合信息。
MCP：
-
可以让 AI 代理协调多个 API，但仍然需要用户逐步确认。
AI Agent：
-
查询用户偏好（如预算、喜欢的景点、过往旅行记录）。 -
生成最佳行程方案（自动选择航班、酒店、活动）。 -
主动与用户交互（如果用户不喜欢某个选项，Agent 会自动调整）。 -
动态优化计划（如果机票涨价，Agent 会推荐更便宜的替代方案）。
Agent 具备的 自主决策能力，让 AI 真正具备“智能”。
3.3 OpenManus 的 4 个能力体现
OpenManus 是一个框架，当前还是是一个简单的框架，简单的实现了 AI Agent 的这 4 个能力。
1. 任务分解与规划
OpenManus 通过 PlanningAgent 管理任务规划，其本身也是一个 LLM 的 API 请求，其 Prompt 翻译成中文，大概如下：
★你是一名专家级的规划代理，负责通过创建和管理结构化计划来解决复杂问题。
★你的工作包括：
分析请求，理解任务范围； 使用 planning工具 创建清晰、可执行的计划；根据需要执行步骤，使用可用工具完成任务； 跟踪进度并动态调整计划，确保任务顺利进行； 使用 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 交互模式的重大演进：
-
Function Calling（工具调用）：AI 作为 API 调用助手，适用于简单任务（如天气查询、数据库查询）。 -
MCP（模型上下文协议）：AI 具备上下文管理能力，可协调多个 API 执行复杂任务（如 DevOps 自动化）。 -
AI Agent（自主智能体）：AI 具备自主决策、长期记忆、任务规划能力，实现真正的智能交互。
AI 未来的发展方向，已经从「回答问题」向「主动执行任务」转变。
随着 AI Agent 技术的成熟，未来，我们可能会看到：
-
AI Agent 的崛起：Manus 只是开始，未来会有更多类似的 AI Agent 出现，并针对不同场景进行优化。 -
云+本地混合模式：本地 AI 负责隐私数据处理，云端 AI 负责复杂推理，两者结合提供最佳体验。 -
AI 操作系统的雏形：AI 不再只是一个聊天助手，而是一个真正的「数字助理」，能够管理用户的日常任务、自动执行操作，并与各种应用无缝集成。
以上。