当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”: [“上海有哪些好玩的”, “北京有哪些好玩的”]

}

]

要珍摄的是，上述扫数功能是很依赖模子基本才智的，比如其中的意图识别，比如这里用户一句话是：上海天气若何样，有什么好玩的？

这里就有几点要作念：

意图识别准不准，能不行准确知说念需要调用旅游Agent和天气Agent；关节词抽取准不准，能不行把旅游地点和其他参数拿出来，并给到其他Agent；回答得好不好，扫数的用具王人推崇精湛，但最终的回答好不好，这很根究全局休养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% 可靠的机票价钱查询和天气数据，而这种模子创造性阐扬是绝不测旨的。

综上，咱们接下来很长一段时候，王人会在细目性和创造性之间打交说念，全球加油吧！

本文由东说念主东说念主王人是居品司理作家【叶小钗】，微信公众号：【叶小钗】，原创/授权 发布于东说念主东说念主王人是居品司理，未经许可，拒接转载。

题图来自Unsplash开云体育，基于 CC0 条约。