前言

本篇博客用于记录本人学习Agent的过程以及理解，如有错误，欢迎批评指正！

目录

前言

一、Agent基础概念与运行机制

1.1 基础概念

1.2 运行机制

1.2.1 Agent与LLM单次调用的区别

1.2.2 自主决策能力

1.2.3 核心循环

补充

二、核心组件的技术实现

2.1 Tools（工具调用）

2.1.1 工具（Tools）的工程实现细节

2.2 Memory（记忆机制）

2.2.1 Short-term Memory（短期记忆）：上下文管理策略

2.2.2 Long-term Memory（长期记忆）：基于RAG架构的语义召回

2.2.3 状态持久化与故障恢复：Checkpointer机制

三、RAG架构与向量检索

3.1 RAG的产生背景与核心价值

3.2 RAG的完整链路

3.2.1 离线入库链路

3.2.2 在线检索链路

3.2.3 混合检索

3.2.4 Rerank重排序

1. 向量检索的局限

2. Rerank原理

3. 两阶段检索架构

四、从LangChain到LangGraph

4.1 LangChain AgentExecutor的黑盒痛点

4.2 LangGraph的状态图编排

4.3 中间件（Middleware）机制

五、工具标准化与多Agent写作

5.1 模型上下文协议MCP（Model Context Protocol）

5.1.1 MCP解决的架构与核心机制

5.2 Multi-Agent协作

5.2.1 单Agent架构的瓶颈

5.2.2 核心协作拓扑结构

5.2.3 A2A协议

六、RAG评估与调优

6.1 核心评估指标（以RAGAS为例）

6.2 评估驱动的工程优化闭环

总结

一、Agent基础概念与运行机制

1.1 基础概念

1. 通俗解释：Agent可以理解为一个可以调用工具、存储记忆、会任务规划的数字员工；

Agent的工作流可以理解成：听懂 ->拆分 -> 动手 -> 对账 -> 提交。

Agent ≈ LLM + Planning（任务规划） + Memory（记忆机制） + Tools（调用工具）

LLM：Agent的大脑，负责理解、推理，生成自然语言与结构化计划。

Planning：把模糊任务目标拆解成可执行的步骤，并在执行过程中进行动态调整。

Memory：短期上下文 + 长期知识，记录历史对话等信息，在多轮交互和复杂任务中保持连贯。

Tools：相当于Agent的手和脚，让大模型可以去真正调用外部接口并执行具体操作。

2. 细节补充：

Preception（感知）：将多模态输入转换成模型可用的表示，并抽取任务相关状态。

Planning（规划）：把目标拆分成子目标与步骤，可以是一次性计划或每步重计划。

Reflection（反思）：Agent对失败的执行结果进行复盘，生成检查清单或切换策略。

1.2 运行机制

1.2.1 Agent与LLM单次调用的区别

普通调用为：输入prompt，模型输出文本；

Agent的输出是下一步动作（调用工具、更新记忆等）再进入下一轮推理，形成多轮控制循环。

1.2.2 自主决策能力

模型再动作空间中选择下一步（调用工具、传递参数、是否退出循环结束）；

在信息不完整时决定说明还是先假设再验证；

在失败时重试、更换策略或请求接入。

1.2.3 核心循环

在绝大多数大模型框架当中，核心就是ReAct（Reason + Act），也就是推理和行动，也就是：

Thought（思考）：大模型对问题进行思考并做出分析，如：查询天气，需要调用工具；

Action（行动）：大模型输出调用工具的指令，系统得到指令并执行；

Observation（观察）：系统把结果返回给大模型；

Loop（循环）：大模型根据观察得到的信息，选择继续Thoght，最终回答用户；

Final Answer（回答）：将最后的结果以文本形式返回给用户。

在单轮回答时，模型容易产生幻觉，ReAct通过行动让模型注重外部证据。ReAct把思考过程和工具使用结合推进，让推理可监督、可纠错、可复现。ReAct和CoT（Chain of Thoght，思维链）的区别在于，CoT只在模型内部展开推理链，只能基于其训练时已有的知识库进行推理。

补充

1.并非所有Agent都为ReAct框架。ReAct的缺点为：如果任务过长，大模型容易跑偏；成本较高，延迟大、规划能力有限，复杂任务上可能确少全局最优计划。

还有几种种框架如下：

Plan-and-Execute（先计划再执行），由Planner（规划器）、Executor（执行器）、Replanner（重规划器）构成，Planner拿到复杂问题后，列出一张完整的Todo List；Executor根据清单一步步调用工具或执行子任务，收集每一步的结果；如果在执行时遇到了意料之外的错误，Replanner重新调整后续的清单。核心工作流程为：计划 -> 执行 -> 动态重规划的循环

Reflexion（反思框架），由Actor（执行者）、Evaluator（评估者）、Self-Reflection（自我反思模型）构成，Actor的核心是ReAct循环，负责调用工具、执行任务并生成完整的行动轨迹；Evaluator给Actor的表现打分，判断任务是成功还是失败；Self-Reflection当任务失败，复盘整个失败过程，用自然语言生成反思文本。Reflexion的工作流程是：执行 -> 评估 -> 反思 -> 重试的循环。

Multi-Agent（多Agent协作），使用多个专业的Agent协作完成复杂任务。

2.大模型本身没有执行动作的能力，大模型只会告知想要调用什么函数、传递什么参数，真正执行的是代码。Function Call（函数/工具调用）是让大模型输出结构化的工具调用指令，其本质是让大模型通过输出结构化的JSON来表达意图，再由外部代码执行操作，最后将结果传给模型进行下一轮推理。大模型的决策和外部代码的执行结合构成了完整的Function Call。

二、核心组件的技术实现

2.1 Tools（工具调用）

大模型的本质是让大模型通过输出结构化 JSON 表达意图，再由外部代码解析并真正执行。大模型只负责理解推理以及输出结果，无法真实调用外部接口或操作本地文件，只有通过外部编码将Tools赋予大模型，它才能真正执行相关操作。

2.1.1 工具（Tools）的工程实现细节

1. Description（工具描述）：大模型本身不知道外部有什么工具可以调用，因此必须在代码中定义一段清晰的description（包括名称、功能、使用场景）来告知模型。

2. Schema（参数约束）：工程上通常使用Pydantic或JSON Schema来严格定义工具入参，防止大模型在工具调用环节产生结构性幻觉。如当模型输出参数和强类型约束不一致将会被拦截并抛出异常，外部代码捕获错误并转化为自然语言回传大模型，大模型将在下一轮ReAct循环中进行自我修正。

3. Error Handing & Feedback（错误处理与回灌）：工具执行可能会遇到网络超时、API报错等错误，因此工程上需要捕获这些异常，并将错误信息打包成自然语言回传大模型，大模型看到报错进行反思，并在下一轮推理中修正参数或更换策略。

4.Human-in-the-loop（权限管控与安全拦截）：对于工具的权限遵循最小权限原则。发生高危操作时，Agent 的 State 状态会被强制挂起并持久化到数据库。系统会向前端发送一个审批请求。只有当人类点击“同意”后，外部代码才会通过Resume机制恢复执行。

2.2 Memory（记忆机制）

Agent记忆机制，核心是为了解决大模型的Stateless（无状态）与Context Window（上下文窗口）有限的物理限制。在工程架构中，Memory通常被划分为短期记忆、长期记忆与状态持久化三个维度。

2.2.1 Short-term Memory（短期记忆）：上下文管理策略

短期记忆负责维持当前Thread（会话）的连贯性，记录用户提问、模型思考和工具调用轨迹。随着对话轮数增加，上下文会接近模型的最大Token限制。短期记忆有两种处理方法：

1. 滑动窗口：仅保留最近的N轮对话，早期对话直接丢弃，保证上下文长度恒定。

2. 摘要压缩：当对话达到阈值时，出发后台调用LLM将历史对话总结为简短的摘要，用摘要替换冗长的原始记录，兼顾长记忆与低Token消耗。

2.2.2 Long-term Memory（长期记忆）：基于RAG架构的语义召回

长期记忆用于跨会话记住用于画像、偏好及历史经验。非结构化文本无法用传统数据库精准匹配，因此工程上通常映射为RAG（检索增强生成）架构：

1. 写入：将用户的长期偏好通过Embedding模型向量化，存入Vector Store（向量数据库）。

2. 检索：用户发起新会话时，系统将当前问题向量化，在向量库中进行语义检索，找回最相关的历史记忆注入Prompt中。

2.2.3 状态持久化与故障恢复：Checkpointer机制

现代Agent框架引入了Checkpointer（检查点）机制来实现底层存储保障：

1. 状态快照：在Agent执行流的每一个Node完成后，Checkpointer会自动将当前的State进行快照，持久化至数据库（如Redis、SQLite）。

2. 核心价值：通过thread_id实现多轮会话的物理隔离，同时支持故障恢复，若长任务终端，Agent可以从最近的Checkpointer恢复执行，避免重复调用浪费Token。

三、RAG架构与向量检索

3.1 RAG的产生背景与核心价值

LLM存在三大知识缺陷：

1. 知识截止：大模型训练数据有截止日期，日期后发生的事情不知道。

2. 私有数据无法触达：公司的内部数据、业务规则等大模型无法触及。

3. 产生幻觉：在没有相关知识时，大模型容易生成看似合理却完全错误的信息，在没有外部知识验证时尤其严重。

因此，RAG（Retrieval-Augmented Generation，检索增强生成）对于大模型来说是必要的。RAG的本质是：LLM在生成回答之前，先从外部知识库检索相关信息，将检索结果放入Prompt，让LLM基于事实回答。大致流程如下：

无RAG：用户问题 -> LLM -> 回答（容易幻觉）

有RAG：用户问题 ->检索相关知识 -> [问题 + 检索结果]-> LLM -> 回答（基于事实）

RAG的作用是给LLM补充外部知识，LLM负责理解与生成，RAG负责提供事实依据。

3.2 RAG的完整链路

3.2.1 离线入库链路

1. Load（文档处理）：解析PDF，TXT等。

2. Chunk（分块）：将长文档切分为短文本块，需要设置chunk_size和overlap。

3. Embedding（向量化）：调用Embedding模型，将文本块转为向量。

4. Store（入库）：将向量与Metadata（元数据）存入Vector Store（向量数据库），如Chroma，Milvus。

3.2.2 在线检索链路

1.Query（查询）：接收用户提问。

2. Query Embedding（向量化）：将用户的提问转化为向量，传递给向量数据库。

3. Retrieval（召回）：在向量库中比对，找出相似度高的Top-K文本块。

4. Rerank（重排序）：用Rerank模型对召回的Top-K结果进行二次精排，提升相关性。

5. Generation（生成）：将重排后的文本作为context注入prompt，交由大模型生成最终答案。

3.2.3 混合检索

纯向量检索存在精确匹配不足、专业术语召回差、专有名词遗漏的问题，因此需要混合检索。

混合检索 = 向量检索 + 关键词检索，向量检索用于抓取语义相关的文档，关键词检索用于抓取精确匹配的文档。

在混合检索中，向量检索和关键词检索会各自返回一个结果列表，两个检索的计算量纲不同，因此需要合并策略RRF（Reciprocal Rank Fusion）用于将两个列表合并成一个最终列表的算法。

3.2.4 Rerank重排序

在基础的RAG架构中，系统直接以来向量检索召回的Top-K结果进行生成。单纯的向量检索在应对复杂查询时，存在召回相关但是是不匹配的缺陷，为了提升上下文的匹配度，引入Rerank模块。

1. 向量检索的局限

基础向量检索使用的是Bi-Encoder（双塔模型），分别将用户Query和Document独立输入模型，各自生成向量并计算余弦相似度，模型只能判断两者宏观语义是否相似，无法进行细粒度的逻辑校验，会导致在专业场景下系统容易召回语义相似，但具体信息错误的文本。

2. Rerank原理

Rerank引入了Cross-Encoder（交叉编码器）模型，Cross-Encoder会将Query和Document拼接成一个序列同时输入模型，模型通过注意力机制，将Query和Document的每个token进行特征交叉计算，最终输出精准的相关性得分。

3. 两阶段检索架构

Cross-Encoder算力消耗大，无法提前将海量数据离线转化为向量，因此工程上通常采用两阶段架构：

召回阶段（Recall）：使用向量检索或混合检索，从知识库中筛出Top-K的候选集，此阶段关注高召回率，允许存在一定误差。

重排阶段（Rerank）：将粗筛出的Top-K文档逐一与Query拼接后输入Cross-Encoder模型进行精算，根据得分进行重排序，最终截取最相关的片段注入Prompt，此阶段关注高准确率。

Rerank机制在系统性能与生成质量之间取得最佳平衡，既避免了对全库进行精排，又有效过滤了粗排带来的噪声，是解决RAG幻觉、提高回答精准度的关键工程手段。

四、从LangChain到LangGraph

明确Agent核心组件后，需要将其编排成可执行的系统。Agent从早期的高度封装、难以插手的黑盒模式走向如今的高可控、可视化的状态图（State Graph）模式。

4.1 LangChain AgentExecutor的黑盒痛点

早期LangChain中，构建Agent主要依赖AgentExecutor，它降低了入门门槛，开发者只需注入Prompt，Tools和LLM，框架内部会自动驱动ReAct循环。这种设计有如下缺陷：

1. 控制反转缺失：AgentExecutor是一个封闭的循环体，开发者难以在循环节点中插入自定义逻辑。

2. 缺乏复杂流转能力：早期的框架只能处理简单的线性循环，难以支持复杂的条件分支。

3. 状态不可见：执行过程中的State被封装在内部，故障排查困难，无法实现断点恢复。

4.2 LangGraph的状态图编排

为解决黑盒导致的不可控，LangGraph引入了状态机（State Machine）的设计思想，将Agent编排“白盒”化。LangGraph的核心是把流程拆解成三个要素：

1. State（全局状态）：一个共享数据字典，存储对话历史和工具结果。所有节点都在字典中拿数据写数据。

2. Node（节点）：负责具体任务的函数，如调用大模型、执行搜索工具等。

3. Edge（边）：节点之间的连线，尤其是条件边（Conditional Edge），允许开发者根据当前的State动态决定下一步走向哪里。

核心优势：开发者拥有对执行流的掌控权，流程是可以按需拼装的。

4.3 中间件（Middleware）机制

现代Agent框架进一步引入中间件机制，拥有监控和拦截的能力。

机制本质：中间件允许开发者在节点执行的前后，自动触发拦截逻辑。

工程价值：提供了可观测行与治理能力，如可以使用中间件在每次大模型思考前写日志，或在工具执行后修改系统的全局状态。

五、工具标准化与多Agent协作

5.1 模型上下文协议MCP（Model Context Protocol）

5.1.1 MCP解决的架构与核心机制

在没有MCP之前，每一个AI应用都需要和外部服务单独写一套继承代码，N个大模型与M个外部工具就需要写N × M套代码，维护成本爆炸式增长。MCP是一套开放的、标准化的双向通信协议，将集成复杂度降为至N + M。

具体三层架构：

MCP Host：宿主应用（如Agent框架等AI应用），管理所有的MCP连接、全局权限控制以及用户交互页面。

MCP Client：与Server建立一对一隔离连接的客户端，负责会话管理，将Server返回的数据转换成Host认识的格式。

MCP Server：对外暴露具体工具能力的服务端，接收Client发来的请求，执行具体的操作并返回结果。

MCP Server可以暴露三类资源：

MCP的工具发现机制：

Agent启动时，扫描配置的MCP Server列表，向每个Server发送tools/list请求，Server接收后返回JSON格式的响应，Client接收到所有工具的Schema后，自动转化为Function Calling格式注入LLM上下文；运行时，大模型根据注入的工具列表输出调用指令，MCP Client将指令路由至对应的独立MCP Server进程，Server完成真实的API调用并返回结果。

5.2 Multi-Agent协作

随着业务复杂度上升，单一Agent架构逐渐触及性能和逻辑天花板，因此需要引入Multi-Agent（多智能体）。Multi-Agent通过将系统拆分为多个独立、专业的Agent节点，实现了复杂任务的协同。

5.2.1 单Agent架构的瓶颈

1. 上下文过载：单一Agent挂载过多工具或冗长系统指令时，大模型的注意力机制会遭到稀释，导致工具选择的准确性下降甚至出现幻觉。

2. 角色冲突：当任务要求同一个Agent既作为一个代码生成者又作为一个代码审查者，由于底层依赖相同的模型权重与提示词，会缺乏自省能力，难以发现自身存在的错误。

5.2.2 核心协作拓扑结构

多Agent框架通常通过角色拆分来应对上述瓶颈，主流拓扑结构包括：

Supervisor/Worker（主从模式）：系统存在一个Supervisor Agent，负责意图识别与任务拆解，随后将子任务分发给多个专属的Worker Agent执行。Worker Agent实际上是对特定Skill的封装，它们各自拥有专属的Prompt约束与特定的Tools集合。

Peer-to-Peer（平等协商模式）：不存在中心调度节点。多个Agent基于各自的专业视角，通过多轮消息传递进行协商与修改。

5.2.3 A2A协议

A2A的本质是解决分布式、异构Agent之间如何安全委派任务与写作的问题。

A2A的核心概念：

1. Agent Card（智能体名片）：每一个Agent发布一个JSON格式的描述文件，声明了Agent的名称、能力、支持通信接口、认证方式等。

2. Task（任务）：A2A中的工作单元，当一个Agent需要委派工作，它向另一个Agent发送Task，包含用户请求和必要的上下文。

3. Message & Artifact：Agent之间沟通使用Message，Artifact是执行过程中生成的具体产出或实际交付物，是任务完成的证明。

MCP是控制式协议：Agent <-> 工具（一个Agent连接多个外部服务）

A2A是委派式协议：Agent <-> Agent（多Agent协作）

两者为互补关系，不可互相替代。

六、RAG评估与调优

6.1 核心评估指标（以RAGAS为例）

RAG涉及检索与生成两个阶段，一旦最终回答错误，工程上需要准确定位是检索问题还是模型理解问题，因此需要引入量化的自动化评估体系。利用大模型作为裁判，对四个核心指标打分（0-1）：

1. 检索阶段（是否找全、找准）

• Context Recall（上下文召回率）：正确的文档碎片是否被检索
• Context Precision（上下文精确率）：检索出的有效信息是否排在最前面

2. 生成阶段（回答好不好）

• Faithfulness（忠实度）：模型回答是否完全依据检索出的context
• Answer Relevance（答案相关性）：模型的回答是否直接回应用户的Query

6.2 评估驱动的工程优化闭环

• 若Recall低：说明遗漏了信息；优化手段：引入混合检索（BM25）、增加Top-K召回数量。
• 若Precision低：说明噪声多；优化手段：引入Rerank重排序机制、优化Chunk切分。
• Faithfulness低：模型回答出现幻觉；优化手段：修改Prompt强约束、输出自校验、降低温度。

总结

本博客仅记录本人学习AI Agent过程中的一次知识梳理。

不足与后续计划（TODO）：
受限于目前的学习进度，本文在“工程化落地与部署”方面尚有欠缺，如：

• 高并发下的 API 服务化（FastAPI 异步模型与 SSE 流式输出）。

• 生产环境的系统稳定性（Guardrails 护栏机制、超时熔断控制）。

• 系统的容器化交付（Docker 与微服务架构）。