企业官网建设流程全解析

Agent 到底是怎么工作的？把 RAG、工具调用和任务规划串成一条线

很多人第一次听到 Agent，会把它理解成“更聪明的聊天机器人”。

但 Agent 真正有意思的地方，不是它能把话说得更像人，而是它能围绕一个目标，自己决定接下来该做什么。

比如，用户提出这样一个要求：

请查一下售后手册里的退货规则，再结合这个订单的情况，帮我写一段客服回复。注意，先不要发送。

这已经不是单纯的问答了。系统需要查资料、查订单、对照条件、生成草稿，还要记住“不要发送”这个限制。

这篇文章就用这个例子，解释 Agent 背后的几块积木：RAG、向量、Function Calling、MCP、ReAct、Plan-and-Execute、记忆、护栏和微调。

先把 Agent 说清楚：它不是一个单独的模型

大语言模型（LLM）擅长理解文字和生成文字，但它通常只处理当前上下文里的信息。它不会因为“知道怎么查订单”，就真的拥有订单系统的权限；也不会因为“知道退款流程”，就自动完成退款。

Agent 可以理解为：

大语言模型 + 外部资料 + 可调用的工具 + 一套执行循环。

其中，大语言模型负责理解和决策，资料负责提供依据，工具负责连接外部世界，执行循环负责让任务可以一步一步推进。

所以，普通聊天更像是：

用户提问 → 模型回答

而 Agent 更像是：

用户提出目标 ↓ 模型判断需要什么信息 ↓ 查资料 / 调工具 / 追问用户 ↓ 观察结果，检查是否足够 ↓ 继续下一步，或交付结果

这里最关键的词是“判断”。Agent 并不是把所有工具都调用一遍，而是根据任务决定：这一步需要查知识库，还是需要查业务系统，还是已经可以直接回答。

用一个售后任务走一遍 Agent 的工作过程

假设系统里有两类信息：

• 售后手册：说明“什么条件下可以退货”。
• 订单系统：记录“这个订单什么时候买的、商品是否使用、是否已经发货”。

Agent 可能会这样推进：

1. 理解目标：用户要的是一段客服回复，而且明确要求“先不要发送”。
2. 确定缺少的信息：需要知道退货政策，也需要知道订单的实际情况。
3. 检索手册：找到退货期限、商品状态、特殊品类等相关规则。
4. 查询订单：获取订单日期、商品类别和当前状态。
5. 对照条件：判断订单是否符合手册中的规则。
6. 生成草稿：把结论写成客服可以直接使用的回复。
7. 执行边界检查：只生成草稿，不调用“发送消息”工具。

这几步并不一定全部由同一个模块完成。下面的概念，分别对应其中不同的环节。

RAG：让模型回答前先找资料

RAG 是 Retrieval-Augmented Generation，中文通常翻译成“检索增强生成”。它解决的是一个很实际的问题：模型需要参考一份外部资料，但这份资料不一定在模型原本的知识里。

比如模型不知道公司的最新退货政策，系统就可以先从售后手册中找到相关段落，再把这些段落和用户问题一起交给模型，让模型根据资料组织答案。

RAG 通常分成两段：

第一段：把资料准备好

系统会把文档清洗、切分成较小的片段，再为每个片段生成向量表示，同时保存原文、标题、页码、更新时间等信息。

这一步可以理解成给资料建立一个“可搜索的索引”。

第二段：收到问题后检索

用户提问后，系统会把问题也转换成向量，找出含义上比较接近的片段。实际系统还可能结合关键词检索、过滤条件和重排序，把更有用的内容排到前面。

最后交给模型的，通常是找回的原文片段，而不是一串孤零零的数字。模型再根据这些片段回答问题，并尽量保留来源和限制条件。

RAG 的核心不是“重新训练模型”，而是“回答这次问题时，先找相关资料”。因此，售后手册更新时，通常更新知识库比重新训练模型更直接。

不过，RAG 也不是准确率保证器。如果资料本身过期、切分不合理、检索结果不相关，模型仍然可能得到错误依据。所以 RAG 的效果不仅取决于模型，也取决于资料治理和检索设计。

向量：不是文本重叠，而是语义位置

文本经过嵌入模型（Embedding Model）处理后，会变成一串数字，这就是向量。

可以把向量想成一张“语义地图上的坐标”。

“商品买了以后怎么退？” “我想把刚买的东西退掉”

两句话用词不完全一样，但表达的意思接近，所以它们在语义地图上的位置可能也比较接近。

因此，向量距离更近，不等于两个文本的字面重叠度更高。它更接近于：在当前嵌入模型和计算方式下，两段文本被判断为相似的程度。

这也解释了为什么向量检索和关键词检索经常配合使用：

• 向量检索擅长找“意思相近但说法不同”的内容。
• 关键词检索擅长找订单号、产品型号、法规编号这类精确内容。
• 重排序模型负责把真正更有帮助的结果排在前面。

向量检索找到的是“可能相关的内容”，不是“已经证明正确的答案”。最终还要检查片段是否真的适用于当前问题。

Function Calling 和 MCP：一个是调用请求，一个是连接规范

当 Agent 需要查订单时，它不能只靠生成文字完成这件事。它需要使用外部工具。

Function Calling 是什么？

Function Calling 可以理解成模型发出一张结构化的“工具调用单”：

{"name":"get_order_status","arguments":{"order_id":"A123"}}

模型负责判断“要不要调用哪个工具，以及参数是什么”；真正执行查询的，通常是应用程序、后端服务或 Agent 运行环境。执行结果回来后，模型再继续处理。

所以你可以把 Function Calling 理解成一种调用接口或调用协议，它规定了调用名称、参数格式和返回结果的结构，但它本身不等于数据库，也不等于工具的实现。

MCP 是什么？

MCP（Model Context Protocol）更像一套标准化的连接方式。它解决的问题是：AI 应用如何用比较统一的方式发现和使用外部工具、资源与提示模板。

一个简单的比喻是：

Function Calling 像一张格式明确的调用单；MCP 像一套通用插头和通信规范。

两者可以一起出现，但不是同一个层次的概念：

在售后任务中，模型可以通过 Function Calling 请求查询订单；如果订单工具是通过 MCP 接入的，那么 MCP 负责约定这项能力如何被发现和连接。

ReAct：边做边看下一步

ReAct 可以简单理解为“推理与行动交替进行”。它不是一次性把完整答案想完，而是：

判断 → 行动 → 观察结果 → 再判断 → 再行动

例如：

1. 先判断需要退货政策。
2. 检索手册。
3. 发现特殊品类还需要额外规则。
4. 再检索特殊品类政策。
5. 发现订单信息不足。
6. 调用订单查询工具。

ReAct 适合信息不完整、结果可能改变下一步路线的任务。它的优点是灵活，缺点是步骤可能变多，调用次数和成本也可能增加。

Plan-and-Execute：先规划，再执行

如果任务步骤比较明确，Agent 也可以先列出计划，再逐步执行：

1. 找到退货政策。
2. 查询订单信息。
3. 对照规则判断是否符合条件。
4. 起草客服回复。
5. 检查回复是否越过了“不要发送”的限制。

Plan-and-Execute 的优点是路线清楚、方便观察进度；但计划不是圣旨。如果执行过程中发现资料缺失，仍然要允许 Agent 修改计划。

两种方式并不冲突。真实系统中经常是：先生成一个粗略计划，执行每一步时再用 ReAct 的方式根据结果调整。

记忆、评估和护栏：让 Agent 不只是“会做”，还要“做得稳”

记忆：记住任务状态

记忆不等于知识库。RAG 主要负责“从外部资料找知识”，记忆主要负责“保留对话、用户偏好和当前任务状态”。

例如，Agent 需要记住：用户已经确认了订单号、当前已经查过退货政策、最后一步只能生成草稿。

评估：检查结果是否真的合格

生成一段看起来通顺的文字，不代表任务完成。系统还可以检查：

• 回复是否引用了正确的政策条件。
• 是否遗漏订单状态。
• 是否做出了资料没有支持的承诺。
• 是否误触发了发送、退款等高风险动作。

重要检查最好由程序规则、测试用例或人工复核共同完成，而不是只让模型自己说“我检查过了”。

护栏与人工确认：给行动划边界

查询订单通常风险较低；发送消息、退款、删除数据则可能带来真实影响。一个稳妥的 Agent 不应该把“能调用”理解成“可以随便调用”。

这就是护栏和人工确认的作用：限制权限、校验参数，并在重要动作前要求用户确认。

RAG 和微调：一个补充资料，一个调整习惯

RAG 和微调经常被放在一起比较，但它们解决的问题不同：

如果公司的退货政策经常变化，RAG 更适合，因为更新知识库就能让回答参考新版本。

如果希望模型始终按照固定格式输出工单，或者稳定执行某种分类方式，微调可能更有帮助。

微调通常不是“把一本手册永久塞进模型”。即使做过微调，面对经常变化的业务规则，仍然需要可靠的资料来源。

把所有概念放回开头的任务

现在再看“查售后规则、结合订单、起草回复，但不要发送”这句话：

最后记住三句话

1. RAG 解决的是“模型回答时去哪里找依据”。
2. 工具调用解决的是“模型如何请求外部行动”，MCP 解决的是“这些能力如何被标准化接入”。
3. Agent 的核心不是多说几句，而是围绕目标循环执行、观察、检查和调整。

当你把这些概念放回一个真实任务里，它们就不再是一堆零散的术语：模型负责思考和表达，RAG 负责找资料，工具负责执行，规划负责安排步骤，护栏负责控制边界。Agent，正是这些部分协作起来之后形成的一套工作方式。