【Agent笔记 | 第六篇】Agent关键组件

目录

[一、 Agent 关键组件的实现原理](#一、 Agent 关键组件的实现原理)

[1. 记忆（Memory）](#1. 记忆（Memory）)

[2. 工具调用（Tool Calling / Function Calling）](#2. 工具调用（Tool Calling / Function Calling）)

[3. 知识库检索（RAG - Retrieval-Augmented Generation）](#3. 知识库检索（RAG - Retrieval-Augmented Generation）)

[二、 Agent 包含的具体状态 (States)](#二、 Agent 包含的具体状态 (States))

[三、 Agent 工具调用的完整业务流程](#三、 Agent 工具调用的完整业务流程)

[四、 SSE 推送事件结构中的字段 (Tool Calling 阶段)](#四、 SSE 推送事件结构中的字段 (Tool Calling 阶段))

[五、 MCP (Model Context Protocol) 详解](#五、 MCP (Model Context Protocol) 详解)

[1. 交互流程](#1. 交互流程)

[2. 通信连接方式](#2. 通信连接方式)

[六、 Agent 什么时候查询向量知识库？怎么查？](#六、 Agent 什么时候查询向量知识库？怎么查？)

查询阶段 (When)

查询方式 (How)

---

一、 Agent 关键组件的实现原理

1. 记忆（Memory）

记忆通常分为短期记忆和长期记忆，本质是对上下文的管理。

• 短期记忆（Short-term Memory）： 实现方式最简单，就是维护一个对话历史的数组（如 [{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]），并在每次请求 LLM 时将其作为 Context 传入。由于 Token 限制，通常会配合滑动窗口（Sliding Window）或文本摘要（Summarization）技术来截断旧消息。

• 长期记忆（Long-term Memory）： 依赖外部存储。通常将用户的关键偏好、历史核心事件转化为文本，通过 Embedding 模型向量化后存入向量数据库（Vector DB）。下次交互时，先通过语义相似度检索出相关的历史记忆，再注入到当前 Prompt 中。

2. 工具调用（Tool Calling / Function Calling）

• 底层依赖： 依赖于经过特定微调的 LLM，使其具备"理解函数签名并输出结构化参数"的能力。

• 实现机制： 开发者在代码中预先定义好工具的名称、描述和参数结构（通常是 JSON Schema）。将这些定义连同用户的 Prompt 一起发给 LLM。如果 LLM 判断需要使用工具，它不会生成普通文本，而是生成一段 JSON，告诉 Agent："请帮我执行这个函数，参数是这些"。Agent 框架拦截到这个指令，在本地或远程执行对应的代码，拿到结果后再交还给 LLM。

3. 知识库检索（RAG - Retrieval-Augmented Generation）

• 实现步骤： 1. 解析与切块（Chunking）： 将文档（PDF、Word）按段落或固定长度切分。

  2. 向量化（Embedding）： 将文本块转化为高维浮点数数组。

  3. 入库： 存入 Milvus、Pinecone 等向量数据库。

  4. 检索： 用户的提问也被向量化，并在数据库中计算相似度（如余弦相似度），召回 Top-K 的文本块。

  5. 生成： 将召回的文本块作为补充背景知识（Context），拼接在用户的 Prompt 中发给 LLM。

二、 Agent 包含的具体状态 (States)

在复杂任务中（特别是基于状态机架构如 LangGraph 或 AutoGen），Agent 通常在以下状态中流转：

状态名称	描述说明
INIT (初始化)	接收用户输入，加载系统提示词（System Prompt）和可用工具列表。
THINKING (思考/规划)	LLM 正在分析问题，决定是直接回答，还是拆解任务，亦或是调用工具（ReAct 模式中的 Thought 阶段）。
ACTION (行动)	Agent 挂起 LLM 的生成，开始实际执行工具代码、查询数据库或调用外部 API。
OBSERVATION (观察)	Agent 获取工具执行的返回结果，检查结果是否符合预期，是否需要重试或报错。
RESPONDING (响应)	工具调用结束，LLM 根据工具返回的数据生成最终的自然语言回复。
AWAITING_INPUT (等待)	任务需要人类确认（Human-in-the-loop），或者一轮对话结束，等待用户下一次输入。

三、 Agent 工具调用的完整业务流程

这是一个经典的 "用户 -> LLM -> Agent 业务层 -> LLM -> 用户" 的三明治结构：

1. 发起请求： 用户输入"帮我查一下北京今天的天气"。

2. LLM 意图识别： Agent 将用户输入和预定义的工具列表（如 get_weather）发给 LLM。LLM 判断需要调用天气工具，返回一个特殊的响应（tool_calls），包含函数名 get_weather 和参数 {"location": "Beijing"}。

3. Agent 拦截与执行： Agent 业务层解析到这个特殊的响应，暂停对话。它调用本地写好的 get_weather 函数，请求气象局 API，得到结果 {"temp": "25C", "condition": "Sunny"}。

4. 结果回传： Agent 将这个结果打包成一个角色为 tool（或 function）的消息，追加到对话历史中。

5. 二次请求： Agent 拿着包含工具结果的完整对话历史，再次请求 LLM。

6. 生成终答： LLM 读取到工具返回的数据，总结并输出最终给用户的话："北京今天天气晴朗，气温25度。"

四、 SSE 推送事件结构中的字段 (Tool Calling 阶段)

当使用 Server-Sent Events (SSE) 流式输出时，工具调用会被拆分成多个 chunk。以 OpenAI 的规范为例，典型的事件结构如下：

• 状态标识： 前端通过判断返回内容中是否包含 tool_calls 字段来判定当前是否在调用工具。

• 核心字段：

  • id: 工具调用的唯一标识符（如 call_abc123）。

  • type: 通常是 function。

  • function.name: 调用的函数名称。

  • function.arguments: 参数的 JSON 字符串。由于是流式输出，这个 JSON 字符串是按片段（chunk）拼凑 过来的，前端或 Agent 框架需要将它们拼接完整后再解析（JSON.parse）。

五、 MCP (Model Context Protocol) 详解

MCP（模型上下文协议） 是 Anthropic 推出的一项开源标准，旨在解决 AI 模型与各种数据源、工具"直连"的标准化问题，避免为每个数据源写定制化的对接代码。

1. 交互流程

MCP 采用 Client-Server 架构：

• MCP Host (客户端)： 你的 Agent、IDE（如 Cursor）或聊天界面（如 Claude Desktop）。

• MCP Client： 建立在 Host 内部，负责与 Server 维持连接。

• MCP Server (服务端)： 轻量级程序，直接连接本地文件、数据库、外部 API 等，向外暴露资源和工具。

标准流程：

1. 握手与发现： Client 连接 Server，发送 initialize 请求。Server 返回它支持的协议版本和能力。Client 请求 tools/list 或 resources/list，获取 Server 能提供的工具和数据列表。

2. 交互（工具调用或数据读取）： Agent (Client) 决定调用某个工具，发送 tools/call 请求（附带参数）。

3. 执行与返回： Server 执行实际逻辑，将结果返回给 Client，Agent 再将结果喂给 LLM。

2. 通信连接方式

MCP 规定了底层基于 JSON-RPC 2.0 协议，主要通过两种传输方式连接通信：

• Stdio (标准输入输出)： 适用于本地环境。Agent 通过子进程启动 MCP Server，直接通过 stdin/stdout 流进行 JSON 消息的收发。这种方式极其安全且低延迟。

• SSE (Server-Sent Events) over HTTP： 适用于远程环境。Agent 通过 HTTP 请求连接远程的 MCP Server，Server 通过 SSE 推送消息，Client 通过 HTTP POST 发送消息。

六、 Agent 什么时候查询向量知识库？怎么查？

查询阶段 (When)

向量知识库的查询通常发生在两种场景下：

1. 前置拦截（Pre-Retrieval / 传统 RAG）： 在把用户的 prompt 发给 LLM 之前。Agent 接收到用户输入后，立刻拿去查向量库，将查到的资料强行插入 prompt 中，然后再整体发给 LLM。这种方式延迟低，适合纯问答型的知识库 Agent。

2. 工具化查询（Tool-based Retrieval）： 发生在 Agent 的 THINKING / ACTION 阶段。开发者将"查询知识库"封装成一个工具（Tool）。让 LLM 自己决定需不需要查资料，以及用什么关键词去查。这种方式更智能，适合处理复杂、多步骤的任务。

查询方式 (How)

一套完整的查询动作通常包含以下步骤：

1. Query 优化（可选）： 用户的原始问题可能很简略（比如只输入"配置方法"）。Agent 会先用 LLM 根据上下文对问题进行重写（Query Rewrite）或生成假设性答案（HyDE）。

2. 向量化： 调用 Embedding 模型将优化后的查询转化为向量。

3. 向量检索（初筛）： 在向量数据库中进行近似最近邻（ANN）搜索，通过计算余弦相似度（Cosine Similarity），快速召回 Top 10-20 的片段。

4. 混合检索（可选）： 结合传统的关键词 BM25 检索，将文本匹配和语义匹配的结果合并，提高召回率。

5. 重排序（Reranking - 精筛）： 使用专门的 Reranker 模型（Cross-Encoder），对初筛出的文档与 Query 的相关性进行精确打分，保留最相关的 Top 3-5。

6. 组装 Context： 将最终筛选出的文本片段注入到 Prompt 中。