AI知识拓展-1

1.市面上的智能体agent

目前市面上的智能体可以分为 通用框架、垂直应用以及新兴协议三个维度来看。

LangGraph / LangChain:在工程实战中，LangGraph，它把 Agent 建模成状态机或有向图。相比传统的 ReAct 模式，它通过循环（Cycles）和状态（State）管理，解决了 Agent 容易跑偏的问题，是目前企业做生产级应用的首选。

Claude (Computer Use) / Devin:在应用端，Devin 或 Manus 刷新了大家对自主编程的认知。而 Anthropic 推出的 Claude Computer Use 更是开辟了新路径——让 Agent 像人一样通过视觉直接操作电脑桌面，这意味着 Agent 能够打破 API 的限制，直接接入人类现有的所有办公软件。

Anthropic牵头的MCP协议。它尝试统一AI与外部工具的连接标准。这会是未来Agent生态的一个关键转折点，解决了每个Agent都要重新写一遍插件接口的痛点。

ReAct 模式

核心逻辑：思考 (Reason) + 行动 (Act)

推导公式： Question -> Thought -> Action -> Observation -> Thought… -> Final Answer

ReAct 是 Agent 最基础的推理模式。它通过将推理（Reasoning）和行动（Acting）结合，让模型在每一步执行工具前先进行思考。优点是逻辑直观，能处理简单任务；缺点是容易陷入‘死循环’或‘复读机’模式，且对于非常复杂的、需要多步容错的任务，ReAct 的确定性较差。

状态机 (State Machine) / 有向图 (Directed Graph)

有向图 (Directed Graph)：由节点 (Nodes) 和 边 (Edges) 组成。节点是 Agent 要做的具体动作（比如“查数据库”），边是动作之间的指向（比如“查完后去写报告”）。
状态机 (State Machine)：在图中流转时，始终带着一个“账本”（State）。每个节点执行完后，都会更新这个账本。

LangGraph / LangChain

原生的 LangChain 主要是“链式（Chain）”结构，很难做循环逻辑

LangGraph 是基于 LangChain 之上的一个高级框架，它通过‘图’（Graph）的结构解决了 Agent 循环调用的难题。
我认为它最大的价值在于两点：
精细化控制：它能让我们像写传统业务逻辑一样，精确定义 Agent 在什么情况下该走哪条路。
持久化内存：它原生支持保存线程状态（Checkpointing），这意味着我们可以实现人工介入（Human-in-the-loop）和任务的中断重启。

2.Agent项目开发的框架

3.介绍一些AI大模型

GPT-5，引入了Thinking模式，能够进行超长链条的逻辑思考。GPT-5.4 Pro 版本在处理复杂代码审计和多步骤科研任务时，自我修正能力极强。
Claude 4 / 4.6 (Opus & Sonnet)，Agentic Coding能力是目前的行业标杆。
Gemini 3，核心优势在于原生多模态和超长上下文。
DeepSeek，引入了 Engram 记忆架构，解决了 Agent 在长对话中容易“断片”的问题。

4. RAG系统流程

RAG（Retrieval-Augmented Generation，检索增强生成）是一种把信息检索和生成式模型结合起来的 AI 系统架构。它的核心思想是：先从知识库中检索相关信息，再让大模型根据这些信息生成答案，从而减少大模型胡编的问题。RAG系统一般分为两个阶段，离线阶段，在线阶段

第一阶段，就是构建知识库，先收集需要让AI回答的问题资料（PDF 文档，Word，网页，数据库，Markdown，代码库），然后就是切分长文档拆成小块（按字数，按段落，按语义，滑动窗口），把每个 chunk 转换成向量，存入向量库。

对于存入向量库的资料，不同类型的资料是有不同的处理方式的，

对于结构化的数据（表格、数据库、JSON），并不是直接向量化，而是将表结构喂给模型，让模型写 SQL 去查。（这里的喂给模型是指的是并不是把它存入向量库，而是为了LLM让其自己去根据用户的问题生成对应的sql语句去查）Markdown转换： 如果表很小，转成Markdown格式喂给模型，因为LLM对Markdown表格的理解力最强。

那么对于结构化的数据如何处理，在agent项目中是要根据场景来判断的，

第一种情况：如果需要精确计算或强逻辑查询。 不会将其存入向量库，而是保留在关系型数据库中。会构建一个 Text-to-SQL 的 Agent 流程，只将表结构信息（Schema）暴露给 LLM，确保查询结果的准确。
第二种情况：如果结构化数据是作为背景补充。 比如产品参数表，采用向量 + 元数据（Metadata） 的方式。将产品的描述做向量化，而将价格、品牌等关键字段设为 Metadata。这样在检索时，可以通过向量找到类似产品，同时通过 Metadata 确保价格区间等过滤条件的准确。

如果 LLM 生成了错误的 SQL（甚至删库语句），在 Agent 系统设计中该如何防范？

首先就是权限隔离，Agent 链接数据库的账号必须是只读的，然后在SQL执行前可以添加语法逻辑校验并强制设置一个执行时间上限，最后就是自我修正，自动捕获错误信息，喂回LLM修正SQL，最后的最后就是人工验证了。

对于一些多模态数据以及图片资料，用视觉模型（如 Gemini 3 Flash 或 GPT-4o）将图片转为文字描述。Multi-vector： 同时存储图片的“摘要向量”和图片本身的“多模态向量”。

对于长文本数据采用 “Small-to-Big” 或 “Parent-Document” 策略。将文档切成极小的 Child Chunks（便于精确检索）和较大的 Parent Chunks（提供背景）。检索到小块后，返回给模型的是它对应的大块上下文。

第二阶段，就是在线阶段，由于用户的问题可能含糊不清，所以需要先扩展成更合适搜索的关键词，然后把问题向量化，再向量库里面计算余弦相似度，找到最相关的Top-K个片段，向量检索虽然快但精度有限，需要用 Cross-Encoder 模型（如 BGE-Reranker）对找回的片段进行二次精排。只把最有用的信息塞进 Prompt，节省 Token。LLM 结合 Prompt 和检索到的知识，输出回答。

Cross-Encoder（交叉编码器），把问题和文档硬拼接在一起，然后作为一个整体送进 Transformer 模型中。因为在 Transformer 的底层，问题里的每一个字，都会和文档里的每一个字进行 Self-Attention（自注意力）计算。模型能极其细腻地捕捉到上下文的逻辑关联、指代关系甚至语气。

RAG检索优化策略

对于RAG检索优化应该分成三个阶段，检索前，检索中，检索后

检索前，我们要对数据的质量进行一个优化，可以采用智能分片的策略，固定字符分片有可能会把一个完整的语义切断，可以采用Markdown/HTML 层次化切分或语义切分。

层次化分片就是按照逻辑结构分，一般调用规则解析器或者是版面分析器；语义分片需要调用嵌入模型，初切->向量化->相似度计算->切断

检索中，可以在向量检索的基础上增加关键词检索，向量检索模糊匹配，处理具体的数据时采用关键词检索；对提示词进行一个扩写，并行检索；通过LLM伪造的假答案去查。

关键词检索与元数据是有区别的，它是一种搜索引擎算法，直接在文章的正文内容里找词频，返回出现词频最高的几个段落，是算分的是一种概率匹配。

什么是 HyDE？如果大模型生成的“假答案”是错的怎么办？

所谓的HyDE采用的是向量空间语义对齐而不是事实的对齐，通过LLM生成与目标相近的文本，这样做的目的是用户的短问题和答案的长文档之间结构长差异很大，通过把问题转换成文档的形式去欺骗向量数据库让其匹配的更准确。

检索后，通过重排序对于初筛结果进行打分清洗，然后就是长文本的清洗，去掉检索中的冗余信息，只保留关键句子。

我们这里还要做一个区分，用户问题≠最终提交到LLM的提示词，agnet会拿着问题去做RAG，拼接RAG的检索结果和问题，送入LLM，这里所说的提示词压缩是说，在送入LLM之前，通过一个轻量级的组件检索文档，去除无关信息，减少token使用。

5.MCP和Function Calling

先说Function Calling，类似于大模型的手，提前把一堆工具的说明书（JSON Schema）塞给大模型。大模型在聊天时，如果觉得需要用工具，它就不再输出自然语言，而是输出一段符合说明书格式的 JSON 代码（比如：{"name": "get_weather", "location": "Beijing"}）。然后，你的后台代码拿到这段 JSON，去执行真正的天气 API，再把结果还给大模型。缺点是点对点的，如果要接入50个工具就要写50遍代码，换个LLM如果存在格式差异又要重写代码。

MCP就是提出了一种AI调用工具的统一接口标准，引入了服务端和客户端的概念，工具厂商自己写符合MCP标准的服务器，这个服务器里包含了所有的 API 逻辑和 Function Schema。只要大模型支持 MCP 协议，它一插上（连接）这个 Server，就能自动发现、自动读取里面所有的工具和数据。

MCP协议的核心内容

MCP核心内容是一架构，三基础，两通信

一架构就是前面说的C/S架构，

MCP Host（宿主/应用）： 比如你正在开发的一个带界面的 AI 助手网页端，或者像 Claude Desktop 这样的桌面应用。
MCP Client（客户端）： 嵌在 Host 里面，负责发起协议请求（比如：“服务器，你有哪些工具？”）。
MCP Server（服务端）： 这是一个轻量级的独立程序。它负责连接真正的外部（比如你的本地电脑文件、GitHub API、PostgreSQL 数据库）。

三个基础是说Server向Client提供的三种标准化能力

第一个是资源，就是让大模型只读数据，类似HTTP的GET请求，Server 暴露出来供大模型读取的数据源，URL格式，(例如本地跑一个MCP Server，把你的 src/components 目录暴露为 Resource。这样，大模型就能直接读取你本地的 Vue 或 React 组件代码，而不需要你手动把代码复制粘贴到聊天框里。)

第二个是工具，类似HTTP的POST请求。这其实就是标准化的Function Calling。Server 明确告诉大模型有哪些函数可以调用，以及参数格式。

第三个是提示词模板，Server 可以预先定义好一些复杂的系统提示词，让用户或大模型直接调用。

两个通信是Stdio(标准通信)和SSE over HTTP(服务器发送事件)

本地通信通常用标准通信，利用的是操作系统的进程间通信 (IPC)。当你的 AI 助手启动时，它会在后台作为一个子进程（Child Process）把MCP Server启动起来。然后，AI助手通过写入Server的stdin（标准输入）来发送指令，通过读取Server的stdout（标准输出）来获取结果。

这个本地通信是说我的agent和MCP Server都是部署在本地电脑上，但是LLM部署在云端上，如果云端直接链接我的数据库，得把数据库端口暴露到公网，这是危险的。数据流转过程如下：

6.如何写好的prompt

Prompt的本质是给LLM的说明书，想象一个场景你要让大模型写一段代码，可以这样构建Prompt

Role (角色设定)：赋予模型专业背景，激活特定领域的权重。你是一个拥有 10 年经验的资深xx架构师，精通xxx和xxx
Context (背景上下文)：交代任务发生的背景。我们现在需要开发一个后台管理系统，用于展示和管理xxx。
Task (明确任务)：具体要执行的动作。请编写xxx
Constraints (限制与边界)：防止大模型自我发挥。限制条件：1. 禁止使用第三方 UI 组件库（如 Element Plus），必须原生手写。2. 必须处理xxx状态。
Output Format (输出格式)：对于 Agent 来说，这是系统对接的命脉。格式要求：只输出完整的xxx单文件代码，不需要任何 Markdown 解释文字，不需要前言和总结

在写Prompt的时候，给LLM提供几个输入输出示例，展示一段标准的输入输出示例。强迫模型写出思考过程。以及最重要的防御性提示，也就是明确指出如果检索的上下文中没有相关信息请直接回答类似缺少数据无法回答的话语。

7.多轮对话的实现方案

LLM本身是无状态的，多轮对话的本质就是给大模型做一个后端的全局状态管理方案，我了解到的有这么几种实现方案。

滑动窗口 (Sliding Window)，原理：维护一个队列，每次只把最近的N轮对话（比如最近 10 条）拼接进Prompt里发给大模型。适用场景是简单的问答机器人、Demo 项目。但是会有Token爆炸的问题，上下文越变越长，API费用飙升，且响应变慢。而且一旦超过N轮，最早的重要信息（比如用户的名字、需求）就会被无情截断。

动态摘要 (Summary Memory) ，原理就是设计一个后台拦截器。当对话积累到一定长度，在后台触发一次静默的 LLM 调用，让模型把过去的对话压缩成一段简短的摘要。下次调用：将全局摘要 + 最近 1 轮对话发给模型。

向量检索 (Vector/RAG Memory) ，把过去的每一轮对话（甚至用户的偏好、习惯），都变成向量存入向量数据库。当用户发起新对话时，用当前问题去检索历史记录。

图框架状态持久化 (Stateful Checkpointing) ，结合LangGraph，利用框架原生的 Checkpointer，为每一个用户生成一个唯一的 Thread_ID。它不仅仅记住说了什么话，它连 Agent当前执行到了哪一个节点、工具调用到了一半的数据都完整持久化到了数据库（如 PostgreSQL）中。

Mem0 和 Zep

传统的向量数据库只是硬盘，它们不够聪明。 如果你先告诉 Agent我喜欢喝咖啡，过几天又说我戒了咖啡，现在只喝茶，普通的向量库会把这两句话都搜出来，导致大模型精神分裂。Mem0和Zep都是为了解决这个问题的。

Mem0主打记忆的自我进化，记忆的 CRUD（增删改查）：这是 Mem0 最强大的地方。它不仅能存，还能自动合并和更新记忆。就像上面喝咖啡的例子，Mem0 在底层会自动把喜欢咖啡的记忆修改为曾经喜欢咖啡，现在喜欢茶，而不是单纯堆砌数据。
        多层级记忆隔离 (Multi-level Memory)：它原生支持为不同的维度划分记忆：User Memory（记住某个特定用户的偏好），Session Memory（只管当前这半小时的聊天上下文），Agent Memory（Agent 自身的全局知识）
        图+向量的混合架构：它不仅存文本向量，还会自动提取实体关系（Graph），知道张三和李四是同事关系。

        Zep 的定位是如果你要应对高并发的 C 端用户（比如几十万人同时在用的陪伴型 AI），Zep 是首选。

        异步后台处理 (Asynchronous Processing)：这是 Zep 的王牌。普通架构下，Agent 聊完天还要花时间去生成摘要、做向量化，导致下一条回复很慢。Zep 把这些全部放到后台异步执行，完全不阻塞主对话链路，让聊天响应快如闪电。
        自带电池 (Batteries Included)：它是一个独立的微服务（用 Go 写的，极快）。你不需要自己去接 Embedding 模型，不需要自己搭向量库，Zep 内部全包了，直接提供 REST API。
        时间感知 (Temporal Search)：Zep 能理解时间的流逝（Decay）。它在搜索时会给最近发生的事情更高的权重。

8.LLM产生幻觉的原因及解决方案

LLM产生幻觉的原因大概有这三个方面：

1.LLM 的底层是Next-token prediction（预测下一个词的概率）。它不是关系型数据库，它的脑子里没有对错的概念，只有概率上哪个词接在后面最顺。LLM 本质上是一个压缩了海量语料的概率模型，而不是知识图谱。当它对某个领域的分布概率不确定时，它会基于语境生成看起来很通顺但违背事实的文本。

2.在 RLHF（人类反馈强化学习）阶段，为了让模型变得乐于助人，模型被训练成了尽量给你答案。由于训练阶段的奖励机制，模型往往具有讨好型人格。比起回答我不知道，它更倾向于生成一个看似合理的答案来满足用户的提问，这就直接导致了幻觉。

3.当你塞给它几万字的长文档时，它的注意力机制会衰减。在处理超长上下文时，LLM容易出现Lost in the Middle现象，忽略了中间的关键约束条件，导致前后逻辑矛盾或产生幻觉。

幻觉并不能完全的消除，我们要去做的是尽量去管控LLM，并给他兜底。

1.首先最重要的就是写好的Prompt，对LLM进行一个强制的约束，同时强迫其输出思考过程，延缓答案输出。

2.RAG检索知识增强，前面有详细的说明

3.基于LangGraph架构，可以去设计评估节点，对于输出的内容和原始资料进行一个比对，对于代码方面的输出，可以调用外部工具进行一个代码格式以及结果的一个先验。

9.推理模式的差异化设计

差异化设置的本质上是根据业务场景在推理速度，推理深度，计算成本之间动态平衡，在模型的内核有原生思维链模式和指令级推理模式

原生思维链模式 (Native CoT / Thinking Models)
代表模型： OpenAI o1/o3, DeepSeek R1。
模型在训练阶段就通过大规模强化学习（RL）学会了自我博弈和思考。它在输出最终答案前，会产生大量的内生思考 Token。适用于数学证明、复杂代码逻辑审计、需要极高准确率的科学发现。

指令级推理 (System Prompt CoT)
代表模型： GPT-4o, Claude 3.5 Sonnet。
模型本身是快思考模型，通过在 System Prompt 中加入 Let's think step by step 或结构化的 <thought> 标签来强迫模型按逻辑输出。适用于日常对话、简单的逻辑判断、高频的 API 调用。

在实际的开发情况下，不给所有任务都配备昂贵的推理模式，而是去设计一些自适应的路由推理，基于这种想法有这个吗两种方案：

1.先让快模型（如 GPT-4o-mini 或 Gemini Flash）给出一个初版答案。再让慢模型/推理模型（如 o1 或 R1）作为审计员，检查初版答案。

2.针对同一个问题，同时派发给三个不同的模型（一个擅长代码，一个擅长逻辑，一个擅长语言），然后由一个中控 Agent 汇总，通过一致性判断来抵消单个模型的幻觉。

10.思考：现在有一个企业级私有代码助手的需求。这个 Agent 需要能够读取公司内网的私有 Git 仓库，回答开发者的业务逻辑问题，并能根据现有的代码风格自动生成单元测试。你会怎么做？（架构选型、数据处理、工具集成、记忆管理）

在框架选取时，会去选择LangGraph 作为核心框架。因为代码生成和审计是一个高度非线性的过程，需要频繁的尝试-报错-修正。LangGraph 能确保 Agent 严格按照我设计的需求分析 -> 代码检索 -> 生成 -> 静态校验流程运行。

然后就是有关权限隔离和即插即用，肯定需要去部署MCP Server，通过本地stdio通信，不去向公网暴露接口，云端LLM只需要发出指令实现敏感数据和大脑的物理隔离

关于检索增强，对于代码的向量化应该是哟个专用的embedding模型，对于整体代码的解构应该利用AST去将函数调用，类继承关系存入图数据库，结果召回后进行一个重排序打分，避免幻觉。

然后就是推理模式，企业级的代码助手，采用混合推理效果更加，因为多元化的问题，需要的token成本是不一样的，减少成本的同时高效去完成任务。

最后就是防御性Prompt，Prompt层面要去定义禁止生成任何修改生产环境数据的代码，在中间件层去设计一个独立的Linter节点对代码进行静态分析，检测是否存在drop table等关键词。最后就是执行的关键动作必须要开发者手动确认。

Linter：是一类静态代码分析工具（如前端的 ESLint，Python 的 Pylint 或 Flake8）。它不需要运行代码，就能发现潜在的问题。接受上一个节点生成的代码，调用Linter工具进行校验。

AST：源代码结构的一种树状表示，保留代码的逻辑骨架，在RAG阶段可以利用AST去提取类名函数名和参数定义，去存入元数据，通过AST能够分析代码之间的映射，构建代码的一个关系依赖图。

11.Agent skills

skills并非是AI本身学过的东西，而是开发者赋予Agent的外部行动能力，成熟的agent需要四个维度的能力：

当agent的技能太多，就会面临上下文窗口压力和指令遵循度下降的问题，对于这个问题的解决，首先是技能路由，并不是一次给Agent很多技能，而是先让路由根据用户意图去筛选最相关的几个执行。同时要确保技能设计的原子化，确保一个技能单独完成一件事情，不做一个复杂的同时做很多事情的技能，然后就是去优化技能描述。

这里所说的技能路由有这么几种实现方式：

最简单基础的就是使用LLM内在的Function Calling能力，把所有的工具的描述塞进Prompt

基于语义索引的动态路由，当拥有很多skill的时候，就需要把 100 个工具的功能描述分别做成 Embedding（向量），存入向量库。用户提问时，先去向量库里搜，捞出最相关的 5 个工具，动态拼接到当前的 Prompt 中。

分级模型：一级模型（路由员）：先跑一个极快的低成本模型（如 GPT-4o-mini 或本地的 Llama 3），它的任务只有一个：分类。它判断用户是想的意图。
二级模型（执行员）：根据分类结果，跳转到对应的技能。比如分类是“财务”，那么 Agent 这一轮就只带上 read_excel 和 get_tax_rate 这几个技能。

12.MCP和skill区别

MCP 是一种标准化的工具分发协议。它让Skill的定义从私有化对接转变成了通用化接入。通过 MCP，我们可以实现工具的即插即用，而不需要为每个Agent手写Skill逻辑。