首先，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 是比较不错的，足够简单，我们今天就来拆解一番，依旧是站在 意图识别和工具调用 的角度：

unsetunsetAI Maxunsetunset

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

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

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

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

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

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

1. 规划（Planning）：任务分解、子任务生成及自我反思；

2. 记忆（Memory）：长期记忆存储与上下文管理，用于处理复杂任务；

3. 工具（Tool）：通过API或外部工具增强Agent的能力（如搜索、文件操作，代码执行等）；

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

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

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

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

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

unsetunsetThAct模式unsetunset

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

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

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

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

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

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

用户：帮我查下周末去上海的机票，再看看天气适不适合旅游

Think 1:
-主要意图：旅行规划
-子任务：[机票查询，天气查询，旅游建议]
-当前焦点：先获取基础信息
-工具选择：search_tickets(参数:目的地=上海，时间=下周末)

Act 1:调用机票搜索工具→返回多个航班选项

Think 2:
-已获取机票信息
-下一步：确认天气条件
-工具选择：get_weather(参数:地点=上海，时间=下周末)
-注意：需要具体到日期，因为下周末包含周六周日两天

Act 2:调用天气工具→返回周末天气：晴，25-30度

Think 3:
-信息整合分析
-推理：天气适宜，机票价格合理
-生成建议：推荐出行，并建议携带轻便衣物

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

unsetunset简单实现unsetunset

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

一、预设工具

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

[
{
"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":[
"上海有什么好玩的"，
"周末去北京的话有什么景点"
]
}
]

二、调度提示词

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

你是一个「旅行小助手」，可以帮用户完成两件事：
1.查询某个城市在某一天的天气；
2.根据城市和时间，给出简单的本地游玩建议。

你可以使用下面两个工具来完成任务：
-weather：用于查询天气
-travel：用于生成游玩建议

使用规则：
-当用户询问天气时，一定要调用weather工具，而不是自己胡编。
-当用户询问要玩什么、推荐行程时，一定要调用travel工具。
-当一句话里同时包含天气+游玩需求时，可以依次调用两个工具。

输出格式：
-如果需要调用工具，请不要直接回答用户，而是返回一个结构化的工具调用计划（包含工具名和参数）。
-工具执行完成后，你会拿到工具返回的数据，再结合上下文，用自然语言给用户一个整合后的回答。回答时不用再提自己调用了哪个工具。

三、Think/Act循环

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

loop:
1）把“用户输入+历史对话+工具列表+System Prompt”丢给模型
2）看模型输出：
-如果它说「需要调用工具」，并给出了工具名+参数->进入工具执行
-如果它直接给了自然语言回答->说明任务完成，结束loop
3）如果调用了工具：
-真正去请求对应API（weather/travel）
-把工具返回结果填回对话历史里（比如加一条「工具返回」消息）
-回到第1步继续，让模型在新上下文下再Think一次

#下面是简要代码
whileTrue:
model_output=call_llm(context，tools)
ifmodel_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内部执行流程是这样的：

一、意图识别

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

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

二、工具执行

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

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

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

三、最终回答

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

1. 用户原始需求

2. 天气信息

3. 景点信息

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

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

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

unsetunset结语unsetunset

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%可靠的机票价格查询和天气数据，而这种模型创造性发挥是毫无意义的。

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