Agent 开发基础

日常生活中, 像豆包这样的 AI 应用: 我们可以和它打字聊天, 也可以直接语音对话, 还可以让它写代码 / 改文章 / 做总结, 甚至还能让它生成图片. 这些能力被整合在一起, 给人一种错觉: "反正都是大模型", "所有模型效果应该都差不多", ... ... 这种错觉就是典型的把 "产品能力" 和 "模型能力" 混在了一起.

产品什么功能都有并不代表一个模型就可以实现这些全部功能. 产品背后的逻辑往往是: 不同类型的模型分别负责不同能力, 再由系统把这些能力组合, 编排, 封装, 最终展现在一个统一的产品界面中.

二. 模型分类

不同模型之间的差别, 在以下3个方面:

输入是什么形式
输出是什么形式
擅长处理哪一类信息

基于这个视角, 我们可以对常见的 AI 模型做一个非常清晰的分类:

大语言模型 (LLM)

大语言模型擅长做的事情非常明确: 理解自然语言, 并生成自然语言. 它的典型能力包括: 总结一段文字, 翻译一段文字, 修改/润色/扩写内容, 根据语言描述生成代码 ... ...

一句话总结大语言模型的特点: 输入文本 + 输出文本

多模态模型

多模态模型是在大语言模型的基础上, 能力进一步拓展的一类模型. 它不再只能处理文本, 而是还可以理解或生成: 图片, 音频, 视频. 它的典型能力包括: 看图说话, 图片内容理解, 文生图, 文生视频 ... ...

注意: 多模态 != 更聪明

多模态的本质含义是模型能处理的输入和输出形式变多了, 但是在逻辑推理和判断能力上并没有发生质变.

向量模型

向量模型和前面两类模型有一个非常本质的区别是: 它们不负责生成内容.

向量模型的输出不是一句话, 不是一张图片, 而是一组数字 (向量) --> 这组数字表达的不是内容本身, 而是一段文本在语义空间中的位置.

可以这样理解: 向量模型不负责给答案, 它只负责帮你找到"该看的内容".

总结

将这三类模型放在一起对比, 它们的分工其实非常清晰:

大语言模型: 负责把话说清楚
多模态模型: 让模型不止理解和生成文字
向量模型: 判断内容之间是否相关, 相似

好, 我们现在知道了模型只提供能力, 那么: 是谁在控制流程? 是谁决定什么时候用哪种模型? 是谁在判断"下一步该做什么" ? --> Agent

三. Agent 概念

像一次性任务比如: "翻译一段文字", "总结一段话" 这类任务不依赖中间状态, 不需要多步推进, 一个输入一个输出就能完成, 非常适合直接交给大模型去完成.

但是多步骤任务如: "查数据库 -> 分析数据 -> 查邮件" 这类任务本质上是一段过程, 一段过程需要关注这几个问题: 我们要完成什么目标? 我们现在已经做到哪一步了? 我们接下来应该做什么? 但是模型本身并不会关心这些问题, 这就需要引入 Agent 这个概念: Agent 是一个带着目标, 会分步骤推进任务的 AI 行为单元. Agent 关注的不是 "如何回答一句话", 而是 "如何把一件事情做完".

四. Agent 和 Workflow 的区别

Agent(智能体) 和 Workflow(工作流) 经常会被放在一起来讨论, 它们看起来很像, 但是在架构层面有非常关键的区别:

Workflow 工作流

Workflow 的流程是写死的: 整个工作流是提前设计好的, 每一步做什么, 顺序如何都是固定的, 模型只在某些节点被调用完成某项任务, 而不能发挥决策作用.

Workflow 的优点是:

可控
稳定
易于调试

Agent 智能体

Agent 中, 模型对过程拥有决策权. 模型不再只是被调用的工具, 它需要根据当前状态决定下一步行动, 整个任务的推进过程是动态的.

相比 Workflow, Agent 至少多了3层意识:
- 目标意识: 现在要完成什么任务
- 状态意识: 当前做到哪一步了
- 行动意识: 下一步做什么? 是否需要调用工具? 是否可以结束任务?
Agent 执行逻辑: Agent Loop -- 把做事抽象成一个循环

while (true) {
    if (think()) { // 1.判断当前状态,是否需要继续
        excute(); // 2.执行动作 (可能是 调用工具,生成内容 等) 
} else { 
    break; // 3.目标已完成 或 无需继续 
    } 
}

五. 智能体系统和Agentic

智能体系统

随着任务复杂度的提升, 我们很快会发现, 单独一个 Agent 不可能完成所有事情, 这就需要引入多个 Agent 相互配合来完成. 当一个系统中出现多个职责清晰的 Agent, 他们相互配合完成同一个目标, 这就引出了一个更大的概念: "Agentic System" (智能体系统)

Agentic

Agentic 是一个非常新的概念 (最近两年出现), 这是 AI 首次被当成 "长期运行的系统组件" 来使用的. Agentic 讨论的不是用哪个模型 / 写什么提示词, 而是更偏系统级的问题, 例如:

如何拆解任务
如何管理状态
如何控制不确定性
如何让多个 Agent 协作
如何让 AI 在系统中稳定运行

从这个角度来看, Agentic 其实是后端领域的问题.

六. 工具调用

概念

Agent 可以决定下一步做什么, 但是真正的事情, 必须由真实的系统来执行, 例如:查询数据库, 调用系统接口, 读写文件等等. 这些真实的操作, 模型本身是做不到的, 这就需要 工具调用 ("Tool Calling") 来解决.

AI 与系统的分工

AI 如何真正做事? 无论一个模型看起来多么智能, 它们始终都停留在"生成内容"这一层, 无法在真实世界真正的执行一些行为, 如: 真正查询数据库, 真正调用系统接口, 真正读写文件等等.

上述这些行为模型永远无法完成, 只能让系统去做. 所以模型和系统之间就有着天然的分工:

模型负责判断与决策
系统负责真正的执行

那么整个 Agent 系统的分工就非常清晰了, 一句话来讲: "AI 决定应该做什么, 程序决定怎么做"

工具调用

最原始最直接的方式: 工具调用

为了能让 AI 能够影响真实系统, 我们需要建立系统和模型之间的联系, 最简单的方式就是: 提前写好一组函数, 把它们作为"工具"提供给模型, 模型调用这些函数去完成某些功能. 例如: 查询数据库 queryDatabase(sql) ; 发送邮件 sendEmail(to, content)

这些函数的内部具体怎么实现 (逻辑怎么实现, 怎么连接数据库, 怎么处理异常 ...) AI 完全不知道也不需要知道, AI 只需要知道三件事:

有哪些工具
这些工具是干什么的
需要传递什么参数才能调用这些工具

然后再给 AI 喂一条非常关键的规则: "在执行任务的过程中, 如果你认为需要使用某个工具, 那就告诉我要调用哪个工具, 以及对应的参数是什么". 当 AI 按照约定返回工具名称和参数结构之后, 系统就可以:

解析 AI 的返回
调用真实的函数或接口
获取执行结果
把结果再交给 AI

AI 再根据工具的执行结果, 继续推进任务. 这种写作方式, 就是我们常说的 "Tool Calling" 或 "Function Calling". 它的核心思想并不复杂: AI 本身不执行具体操作, 而是"请求"系统去执行具体操作.

七. MCP

工具越来越多, 各种新的问题又会出现: 这么多工具, 如何统一管理和描述? 新增一个工具要不要修改一堆提示词? 工具只能是我项目里的函数吗, 能不能是别人已经写好的工具?

随着工具越来越多, 此时工具本身就会变成新的复杂源头. 此时我们意识到: 工具不一定必须存在于我们的项目代码里.从系统角度来看:

查询数据库是一种能力
发邮件是一种能力
调第三方接口也是一种能力

至于这项能力是本地函数还是远程服务都不重要. 对于 Agent 来说, 重要的是能力如何描述, 模型如何去调用.

在这样的背景下, 就引入了 MCP 这个概念, MCP 解决一个核心问题: 如何把工具从项目内部函数变成 "可被 AI 统一使用的外部能力".

这里就发生了一个非常关键的转变: Agent 不再依赖 "我写了什么函数", 而是依赖 "系统对外暴露了什么能力".

Tool Calling 解决的是 "能不能被调用", 而 MCP 关注的是 "能力如何被组织和管理".

八. RAG

概念引入

那么, 知道这些以后, 还有一个问题尚未解决: AI 如何知道在当前任务下, 该调用哪个工具. 这就需要引入另外一个核心内容: 向量模型, 向量数据库, RAG. 工具调用解决的问题是 "能不能做", RAG 解决的问题是 "知不知道".

前面我们知道了 AI 如何请求系统做事, 通过工具调用和 MCP, Agent 已经可以: 查询数据库, 调用接口, 发送邮件, 操作真实系统等.

但是如果我们真正开始写 Agent, 很快就会遇到另一个问题: AI 怎么知道"该怎么查", AI 要怎么写 SQL? 要写一条正确的 SQL, 至少需要知道: 有哪些表, 表的结构, 表之间的关系 ... ... 但是这些东西模型是并不知道的.

无论这个模型有多强, 它都不可能天然知道: 数据库结构, 表结构, 系统内部流程等等. 模型的训练数据主要来自于通用世界. 所以, 如果在没有任何额外信息的情况下, AI 几乎不可能生成完全正确的 SQL.

这里我们就会想到最直接的一个想法: "那我把所有数据库结构全部塞进提示词里不就行了?" 这个方案在校系统里可能还能勉强工作, 但是只要系统稍微复杂一点, 就会立刻遇到限制:

提示词长度有限制
数据库结构本身很长
每次任务只需要其中极小一部分信息

关键的是: 即便我们把所有信息都给了 AI, 它也并不需要全部. 所以真正的问题在于: 在所有系统知识中, 哪一小部分和当前任务是相关的? --> 这一部分正是向量模型发挥作用的地方, 我们之前提到过向量模型用来衡量内容之间在语义层面上是否相关, 所以他也很擅长解决一个关键问题: "这些内容, 和当前问题像不像?"

RAG 将系统知识变成"可检索的文本". 我们可以将系统中那些例如: 数据库表结构说明, 字段含义, 业务规则, 内部流程文档整理成一段文本, 然后使用向量模型把这些文本转成向量, 存入向量数据库. 在需要时, 按语义进行检索. 不是让模型"记住", 而是让模型"查到".

RAG (Retireval - Augmented Generation, "检索增强生成") 关键在"检索"上. 它解决了一个非常现实的问题: 模型不需要记住整个系统, 只是在它需要的时候, 看见该看的那一页.

RAG 的更多细节

RAG 常常被描述为: "给模型加一个长期记忆", "让 AI 记住你对的私有数据". 这些说法有道理, 但并不完全准确. 一个更加精确的说法是: 知识库不是模型的记忆, 而是系统为 AI 准备的一本"随查随用"的说明书. 那些知识并不属于模型本身, 也不需要被"学会", 被永久记住. 它们只是在某些任务需要的时候, 被系统检测出来临时提供给模型做参考.

用 RAG 的方式组织系统知识, 会立刻获得几个非常实在的收益: