一、模型与能力

1.产品与模型

在开始真正的Agent开发之前，需要先把一些容易被误解、却会影响后面理解的基础概念梳理清楚。本节并不讨论任何实现细节，只需要：从最基本的视角，搞清楚AI模型的能力边界。

只有先弄明白模型到底能做什么、不能做什么，后面Agent工具、RAG这些概念，才会站得住。
如市面上常见的通用大模型，看起来“什么都会”，几乎不可能只靠一个模型完成。
在真实系统中，它们背后往往是：
·不同类型的模型，分别负责不同能力
·再由系统把这些能力组合、编排、封装
·最终呈现一个统一的产品界面中
因此，为了避免这种混淆，我们需要从一个更基本的视角去看待AI模型，无论模型多复杂，它们所做的事都可以抽象成一句话：根据输入，生成输出。
不同模型之间的差别，不在于“会不会生成”，而在于：
·输入是什么形式
·输出是什么形式
·擅长处理哪一类信息
基于这个视角，我们可以对目前常见的AI模型，做一个非常清晰的分类。

2.大语言模型（LLM）

大语言模型擅长于：理解自然语言，并生成自然语言。
如：
1.总结一段内容
2.翻译一段话
3.根据内容生成代码
这些任务都有一个共同点：输入是文本，输出也是文本。

3.多模态模型

在大预言模型发展的基础上，出现了能力进一步扩展的一类模型，那就是多模态模型。
这类模型不再只处理文本，还可以理解或生成：
·图片
·音频
·视频
因此可以看到现在的常见的通用模型在逐步增加一些新的能力形式：
·看图说话
·图片内容理解
·根据文字生成图/生成视频
这里需要强调一点，多模态的本质含义只是模型能处理的输入和输出形式变多了，而不是在底层逻辑或者推理能力上发生了质变。

4.向量模型

相比前两类模型，向量模型对大多数普通用户来说并不显眼，如果你没有接触过AI或Agent开发，很可能意识不到这类模型的作用及存在。

向量模型和前面两类模型，由一个非常本质的不同点，实际上并不负责生成内容。
向量模型的输出：不是一段文字，而是一组向量（计算机理解的数字）

这段数字表达的并不是“内容本身”，而是：一段文本在语义空间中的位置，两段内容在语义层面上有多相似。

正因如此，向量模型通常被用在一些“幕后但关键”的场景中：搜索、推荐、聚类、RAG（向量检索增强生成）。可以这样理解，向量模型不负责给答案，它负责帮你找到”想要看的内容“。

5.三大类模型如何实现调配

三类模型放在一起对比，分工其实非常清晰，各有自己擅长处理的领域。因此我们在很多AI产品中感受到的”全能”，并不是某一个模型什么都会，而是这些不同能力被组合在一起。

前面已经说过，模型本身只会对你给它一个输入，生成一个输出，其余的问题并不关心。而当我们希望AI完成一个有目标、有步骤的任务时，我们就需要引入一个新的概念——Agent。

二、Agent

我们已经理清了一件事：模型只是能力，而不是“做事的主体”。无论是大语言模型、多模态模型，还是向量模型，它们本质上都只是在做一件事：根据输入，生成输出。但是当我们开始尝试让AI解决真实问题时，很快就会发现一个现实的问题，很多任务，根本不是“一问一答”就能够成功解决的。

1.”一次回答“解决不了的任务

我们对大模型提出一个任务：从数据库中查询一些数据，再对这些数据进行分析，最后把分析结果发送到指定的邮箱。

将这个任务完整地丢给一个模型，让它”直接回答“，很可能会得到的结果是：一段看似合理的分析，甚至附带了一条SQL语句，最后补充上一句”我已将结果发送至邮箱“
但是实际上：数据库并没有被查询，输出的SQL语句并没有根据真实数据，邮件也并没有发送出去。

这是为什么呢？并非模型能力不够，而是这个任务就不适合用于”一次输入，一次输出“的方式能够完成。

2.问题不在模型，而在任务本身

任务可以被简单分为两类：

一次性任务（Stateless Task）

这类任务的特点是：不依赖中间状态、不需要多步推进、输入和输出之间是强因果关系。
如：总结一段文字、翻译一段文本、根据描述写一段代码。这些任务可以由模型直接完成。

多步骤任务（Stateful Task）

而之前所提及的那个”查数据库→分析→发邮件“的任务，明显属于另一类。
特点是：有明确的最终目标、需要分步骤完成、每一步都依赖前一步的结果、中间过程必须和真实系统交互。

这类任务，本质上是一段过程，而不是一次回答，而只要任务变成了“过程”，就意味着我们需要一个东西来回答下面三个问题：
1.我现在要完成什么目标？
2.我已经做到哪一步了？
3.接下来该做什么？

3.Agent出现的真正原因

正是在这种背景下，Agent这个概念开始正式出现
在不同的框架下，可以看到对Agent的各种定义：
·有的强调“高度自治”
·有的强调“长期运行‘
·有的强调”能自我规划“
从工程角度抽象，，Agent的核心其实非常质朴，Agent是一个带着目标、会分步骤推进人物的AI行为单元。关注的不是”怎么回答一句话“，而是”如何把一件事情真正做完“。

4.Agent和Workflow的本质区别

在使用AI的过程会看到：Workflow（工作流）、Agent（智能体）两者放在一起对比。
它们看起来很像，但在架构层面，有一个非常关键的区别

Workflow：流程是人写死的

在Workflow中，整个执行流程是提前设计好的，每一步做什么，顺序如何，都是固定的，模型只是在某些节点被调用。

例如：1.查询数据库2.调用模型分析数据3.调用发邮件接口
模型在Workflow中，不决定”下一步是什么“，只是被动参与某一步。
Workflow的优点是：
·可控
·稳定
·易于调试
但它的灵活性非常有限

Agent：模型对过程拥有决策权

而在Agent模式中，模型不再只是被调用的工具，它需要根据当前状态，决定下一步行动，整个任务的推进过程，是动态。

Agent会持续思考：
·当前目标是否已经完成
·现有信息是否足够
·是否需要调用工具
·是否需要继续推进，还是可以结束
换言之，Workflow决定”怎么做“，Agent决定”下一步做什么“，这也是判断一个系统是否”Agentic“的最核心标准之一。

5.Agent至少多了三层”意识“

和普通的聊天式AI相比，一个Agent至少需要具备三层最基本的”任务意识“：
1.目标意识：我现在要完成的任务是什么？
2.状态意识：我已经做到哪一步了？当前手里有什么信息？
3.行动意识：接下来应该做什么？是否需要调用工具？是否可以结束任务？
正是这三层意识，让Agent从”回答者“，变成了”执行者“。

6.当Agent不够用时

随着任务复杂度的提升，很快会遇到一个问题，一个Agent，未必适合所有事情。
有些任务更偏向：
·计划与拆解
·信息检索
·数据分析
·结果总结
当系统中出现，多个职责清晰的Agent，它们相互配合完成同一个目标时，我们就进入了一个更大的概念：Agentic System（智能体系统）。

7.Agentic不是”模型技巧“，而是系统设计

Agentic是一个新概念，浮现出了大量高质量的文章，并非因为模型发生了改变，而是AI第一次被当成”长期运行的系统组件“对待并使用。

Agentic系统讨论的，不是用哪个模型，写什么提示词，而是更偏系统级的问题。
例如：
·如何拆解任务
·如何管理状态
·如何控制不确定性
·如何让多个Agent协作
·如何让AI在确定的系统中稳定运行
我们可以发现，Agentic其实是后端领域的问题

8.Agent要“做事”，就必须和真实世界进行交互

我们已经得知，Agent可以决定下一步做什么，但真正的事情，依然必须由真实系统来执行。
例如之前所说的：查询数据库、调用接口、发送邮件、读写功能。这些功能都是模型本身做不到的

那么Agent是如何“请求”这些能力的？系统有事如何安全、可控地把这些能力交给AI使用的？

这正是我们要讨论的核心内容：工具调用以及MCP。