当AI助手从单一工具调用进化到智能体（Agent）架构，其核心挑战在于意图识别与工具调度的无缝衔接。通过解析Manus等实例，我们看到尽管技术框架趋于成熟，但在效率与可靠性之间仍需权衡。未来，AI Agent的故事虽美好，但生产级应用仍依赖于工作流的精准控制。

首先，OpenAI这张图AI发展预测图，是比较经典的：

而国内的分隔符应该是两个事件点：DeepSeek发布、Manus发布，DeepSeek标志国内模型推理能力到位了能做Agent的水平、Manus是第一次将Agent应该有的样子呈现出来，虽然表现不太好，但大家的预期都很高。

具体模型基础能力无非两点：模型推理能力、上下文长度；

而智能体如Manus在这个基础上，需要做的，或者说工作量最大的部分是提供各种工具，如图所示：

Agent架构的核心是围绕两点展开：意图识别以及工具调用：模型会根据用户聊天的内容判断意图，而后选择调用合适的工具，并保证工具的调用质量。

从这个角度看Agent（如Manus）的实现似乎很简单，比如最简单的空气查询工具调用：

只不过，用户的意图会很多，他在查询天气后，马上可能会关注旅游相关信息，如果智能体要做好这个工作，又不得不提供对应的工具，有两个工具的时候，整体复杂度就提升了：

这里会对应两个工具调用：

[
 {
   “tool_name”: “weather”,
   “tool_desc”: “查询某地的天气”,
   “tool_examples”: [“上海天气怎么样”, “北京天气怎么样”]
 },
 {
   “tool_name”: “travel”,
   “tool_desc”: “某地的游玩计划”,
   “tool_examples”: [“上海有哪些好玩的”, “北京有哪些好玩的”]
 }
]

要注意的是，上述所有功能是很依赖模型基本能力的，比如其中的意图识别，比如这里用户一句话是：上海天气怎么样，有什么好玩的？

这里就有几点要做：

1. 意图识别准不准，能不能准确知道需要调用旅游Agent和天气Agent；
2. 关键词抽取准不准，能不能把旅游地点和其他参数拿出来，并给到其他Agent；
3. 回答得好不好，所有的工具都表现良好，但最终的回答好不好，这很考究全局调度Agent的能力；

至此再回归Agent架构的两个核心难点意图识别与工具调用，大家应该就有所感受了，意图识别准确是表现好的基础，工具组织合理是最终输出的保证。

而这里就仅仅2个工具，就有些复杂之感，Manus最初发布就包含了20多个工具（现在就更多了）：

[
  {
    “name”: “message_notify_user”,
    “description”: “向用户发送无需回复的消息。用于确认收到消息、提供进度更新、报告任务完成或解释方法变更。”
  },
  ……
  {
    “name”: “file_str_replace”,
    “description”: “替换文件中的指定字符串。用于更新文件中的特定内容或修复代码错误。”
  },
  {
    “name”: “file_find_in_content”,
    “description”: “在文件内容中搜索匹配文本。用于查找文件中的特定内容或模式。”
  },
  ……
  {
    “name”: “idle”,
    “description”: “特殊工具，表示已完成所有任务并即将进入空闲状态。” 
}
]

Manus提示词部分是有点多的：

# 关于 Manus AI 助手
## 简介
我是 Manus，一个被设计用来处理多种任务的 AI 助手。我致力于在各种场景下，为你提供有用、翔实且多样化的支持。
## 我的使命
我的主要目标是：通过提供信息、执行任务和给出建议，帮助你更顺利地达成目标。我希望成为你在问题求解和任务执行中的可靠伙伴。
## 我处理任务的方式
当接到一个任务时，我通常会：
1. 分析你的请求，理解你真正想要的是什么  
2. 将复杂问题拆分成更小、更易处理的部分  
3. 为每个步骤选择合适的工具和方法  
4. 在执行过程中保持与你的沟通畅通  
5. 以清晰、有条理的形式呈现最终结果  
## 我的性格特征
– 以“帮助你解决问题”为导向
– 注重细节，追求完备
– 能适应不同类型用户的需求
– 面对复杂问题时保持耐心
– 对自己的能力与限制保持诚实
## 我擅长帮助的领域
– 信息收集与研究
– 数据处理与分析
– 内容创作与写作
– 编程与技术问题排查
– 文件管理与组织
– 网络浏览与信息抽取
– 网站与应用的部署辅助
## 我如何“学习”
我会从交互与反馈中不断优化自己的行为模式，在任务中积累经验。每一次协作，都会帮助我更好地应对未来类似的问题。
## 沟通风格
我会尽量做到：
– 说明清晰、逻辑严谨
– 根据你的偏好调整技术深度
– 在需要时使用较技术化的表达
– 在适合的场景使用更口语化、易懂的表述
## 我坚持的价值观
– 尽可能提供准确、可靠的信息
– 尊重用户隐私与数据安全
– 以负责任的方式使用技术
– 对自身能力边界保持透明
– 持续改进和自我迭代
## 如何更好地与我协作
我们的协作会更高效，如果你能：
– 尽量清晰地描述任务与预期结果
– 在必要时给出中途反馈，便于我调整方向
– 将复杂需求拆分成更明确的子任务
– 在已有成功经验的基础上，逐步尝试更复杂的挑战
我随时准备协助你处理各种任务，也期待和你一起，完成更多有趣、有价值的事情。

这些东西已经有了很高的复杂度，而且后续的上下文工程应用也极其复杂，是不利于大家更好的学习理解Agent的，从学习的目的来说的话，早期的OpenManus是比较不错的，足够简单，我们今天就来拆解一番，依旧是站在意图识别和工具调用的角度：

一、AI Max

Agent架构是典型的AI Max架构：能用AI全部用AI，也就是常见的那句话：告诉我你要什么，不要告诉我怎么做，意思是模型最终为结果负责。

只不过这里其实是有些“讨巧”的嫌疑，因为模型怎么做全部以工具（Function Calling/MCP）的方式预定义好了，所以这里更确切的说法是：

给我足够的能力（工具），并且告诉我你要干什么，接下来你不要管了，我会自己根据你给我的工具去完成你的任务，如果不能完成，大概率是你工具不行（不够或者不足），小概率是我（模型）没调度好。

所以，工具不止决定了Agent的上限，也决定了Agent的边界，如果工具能力不支持，比如没有支付、没有复杂检索，那么Agent在这块一定表现得不好。

这也是为什么我们会说：Agent模式中，用户无穷的意图，需要用我们有限的工具去做控制

这里需要再次强调的是意图识别很重要，预定义的工具很重要，他们背后是模型系统性的提示词(决定如何调用工具的系统)很重要，这也是Agent架构核心：规划 + 记忆 + 工具调用的精髓，其中记忆与意图识别的关系很大，但我们简单场景下记忆不是非常重要：

• 规划（Planning） ：任务分解、子任务生成及自我反思；
• 记忆（Memory） ：长期记忆存储与上下文管理，用于处理复杂任务；
• 工具（Tool） ：通过API或外部工具增强Agent的能力（如搜索、文件操作，代码执行等）；

这个图也是比较经典而全面的，他是可以把Agent是什么说清楚的：

一、你有一些工具（Function Calling/MCP 预定义的工具集），里面有非常详细的说明书，在用于与模型对话时会被用到，比如“今天几号，天气如何”；

二、模型会做意图识别，发现用户想做天气查询，这个刚好命中工具库里面的工具，然后模型获取关键参数调用工具；

三、拿到工具调用信息后，回传给模型，模型根据完整上下文输出结果；

至此流程结束，很清晰明了，这里也可以看出来，虽然工具是主要工作量，但是调度一块的架构设计却是准入基础，这里就涉及到了Think + Act模式了…

二、ThAct模式

这里还有很多其他架构（复杂）模式，但总体都类似：意图识别后调用工具。

think阶段实现决策。模型会根据上下文判断当前应该执行哪个工具，若不需要执行工具，则视为任务完成；

要注意的是：Think的结果不是一个工具调用，而是一组工具调用。

act阶段执行模型的决策结果。先执行模型选择的工具，并将执行结果作为上下文，记录到消息中，传递到下一个think阶段；

这里是需要在一个循环里面重复执行，知道所有工具都调用结束，当然，每次循环可以对外输出日志：

这里举个例子，用户请求是：帮我看看下周末去上海机票多少钱，再查查天气。那么这里的流程是：

用户：帮我查下周末去上海的机票，再看看天气适不适合旅游
Think 1: 
– 主要意图：旅行规划
– 子任务：[机票查询, 天气查询, 旅游建议]
– 当前焦点：先获取基础信息
– 工具选择：search_tickets (参数: 目的地=上海, 时间=下周末)
Act 1: 调用机票搜索工具 → 返回多个航班选项
Think 2:
– 已获取机票信息
– 下一步：确认天气条件
– 工具选择：get_weather (参数: 地点=上海, 时间=下周末)
– 注意：需要具体到日期，因为下周末包含周六周日两天
Act 2: 调用天气工具 → 返回周末天气：晴，25-30度
Think 3:
– 信息整合分析
– 推理：天气适宜，机票价格合理
– 生成建议：推荐出行，并建议携带轻便衣物

理论知识就到这了接下来我们做下简单实现，比如做一个天气 + 旅游双工具智能体：

三、简单实现

因为Agent只需要关注天气和旅行，逻辑会非常清晰：意图错乱概率小 + 工具很少，但这个已经具备了 多工具 + 多步调用 + 汇总回答 的特性。

1. 预设工具

第一步当然是提前将所有工具都准备好：

[
  {
    “tool_name”: “weather”,
    “tool_desc”: “查询某地某天的天气情况”,
    “tool_params”: { 
    “city”: “城市名称，如：上海”,
      “date”: “日期，如：2025-11-30”
    },
    “tool_examples”: [
      “帮我查一下上海明天天气”,
      “北京这周末冷吗”
    ]
  },
  {
    “tool_name”: “travel”,
    “tool_desc”: “根据城市和时间，给出简单的本地游玩建议”,
    “tool_params”: {
      “city”: “城市名称，如：上海”,
      “date”: “日期，如：2025-11-30”
    },
    “tool_examples”: [
      “上海有什么好玩的”,
      “周末去北京的话有什么景点”
    ]
  }
]

2. 调度提示词

工具预设结束后，就是如何去调度的总控，之前Manus那个提示词太长，这里写个简单的：

你是一个「旅行小助手」，可以帮用户完成两件事：
1. 查询某个城市在某一天的天气；
2. 根据城市和时间，给出简单的本地游玩建议。
你可以使用下面两个工具来完成任务：
– weather：用于查询天气
– travel：用于生成游玩建议
使用规则：
– 当用户询问天气时，一定要调用 weather 工具，而不是自己胡编。
– 当用户询问要玩什么、推荐行程时，一定要调用 travel 工具。
– 当一句话里同时包含天气 + 游玩需求时，可以依次调用两个工具。
输出格式：
– 如果需要调用工具，请不要直接回答用户，而是返回一个结构化的工具调用计划（包含工具名和参数）。
– 工具执行完成后，你会拿到工具返回的数据，再结合上下文，用自然语言给用户一个整合后的回答。回答时不用再提自己调用了哪个工具。

3. Think/Act循环

在上述基础下，实现一个最小循环，很多朋友不是程序员，我们这里直接上伪代码：

loop:
1）把“用户输入 + 历史对话 + 工具列表 + System Prompt”丢给模型
2）看模型输出：
   – 如果它说「需要调用工具」，并给出了工具名 + 参数 -> 进入工具执行
   – 如果它直接给了自然语言回答 -> 说明任务完成，结束 loop
3）如果调用了工具：
   – 真正去请求对应 API（weather / travel）
   – 把工具返回结果填回对话历史里（比如加一条「工具返回」消息）
   – 回到第 1 步继续，让模型在新上下文下再 Think 一次
# 下面是简要代码
 while True:  model_output = call_llm(context, tools)if model_output.type == “tool_call”:
    tool_name = model_output.tool_name
    tool_args = model_output.tool_args
    tool_result = call_tool(tool_name, tool_args)
    context.append(
      f”[{tool_name} 调用结果]: {tool_result}”
    )
    # 继续下一轮循环，让模型看到工具结果再思考
else:
    # 认为这是最终回答
    answer = model_output.text
    break

整体流程是：模型 → 规划工具调用 → 工具执行 → 结果喂回模型 → 最终回答

回顾

上述代码逻辑非常简单，甚至说他就是一个Function Calling，但他已经有了Agent的雏形了，比如用户说：

下周末去上海玩，帮我看看机票大概多少钱，再查查天气，有什么好玩的？

这对Agent就是一个多步任务，包括了机票查询、天气查询、游玩攻略，只不过系统并没提供机票相关工具，所以Agent会略过。Agent内部执行流程是这样的：

1）意图识别

模型首先根据用户这句话做意图识别，根据提示词工具使用规则，会输出两个规则调用及参数，比如：

我要调用：weather(city=上海, date=下周末)

2）工具执行

我们拿着这个调用参数，去请求天气API，得到结果（比如“多云 26-30℃，有阵雨”）。再把结果塞回上下文：

[weather 调用结果]：上海下周末多云，有阵雨，温度 26-30℃…

重复上述逻辑，调用旅游工具返回结果，生成最终回答：

3）最终回答

最终，模型现在上下文里同时有：

• 用户原始需求
• 天气信息
• 景点信息

可以组织出一段自然语言回答，比如：

下周末上海多云有阵雨，气温在 26-30℃，适合室内 + 短途户外结合。
你可以考虑第一天逛上海博物馆、南京东路，晚上去外滩看看夜景，第二天去迪士尼或者崇明岛

以上就是最简单的执行了…

四、结语

Agent架构的本质，是在大脑越发聪明的模型与精准可控的工具之间找到的最佳平衡点。

这一切看上去是非常的美好，只不过实际上当前Agent却不太能解决生产级应用，Agent的真实情况是什么呢？

从技术架构看，Agent 依赖意图识别和工具调用的完美配合，在这套技术架构下会存在两个问题：

第一，效率低

模型为了保证稳定性，会一再确认，这样会很耗Token，这也就意味着他很花钱，随意经常出现让Manus去做个PPT，结果Token就花完了的情况；

第二，需要试错

并不是因为模型做了很多缺点，结果就一定可控，那还真不是的，这意味着每次Agent给出结果的好坏是需要用户做二次确定的！

从这个角度来说，Agent其实比较适合人机协作，比如AI编程里面的结对编程，所以Cursor这类Agent就很火。

另一个点，他既然适合不断调教，那就肯定不太适合一次性给出很稳定的回答，所以在现阶段生产级别的应用里面，但凡需要用到AI的地方，都不大可能是Agent模式。

当前生产环境用得最多的还是AI 工作流，它通过预设的 SOP，解决模型的不确定性。

以之前的天气工具为例，一个旅行规划 Workflow 会强制拆解为“机票查询→天气检查→景点推荐”三个标准化步骤，每个步骤注入领域知识（如航空公司 API 规范、天气预报数据源校验），确保输出的一致性和可预期性。

从商业和实用视角来说：Agent融资潜力大，AI 工作流解决实际问题，无论是技术团队对新技术的好奇害死VC的Agent倾向性，很多公司都不得不讲Agent的故事。

而且AI Agent的故事还特别好讲，并且这家伙成本还奇低！一个只有天气和旅行两个工具的 Demo Agent 就能拍出惊艳宣传片；

其背后暗示的是无限可能性；但现实中，客户需要的是 100% 可靠的机票价格查询和天气数据，而这种模型创造性发挥是毫无意义的。

综上，我们接下来很长一段时间，都会在确定性和创造性之间打交道，大家加油吧！