大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



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

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都要重新写一遍插件接口的痛点。

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

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

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

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

1. LangGraph / LangChain，强调状态管理（State）和循环控制。
2. AutoGen / CrewAI，处理复杂的软件开发或多步研究任务，它擅长定义不同角色的对话协议。比如一个 Agent 写代码，另一个 Agent 跑测试，这种多智能体（Multi-agent）协作能显著提升复杂问题的解决率。
3. Python 的 Pydantic，核心卖点是类型安全。在生产环境中，模型输出的幻觉（格式错误）是最大的痛点，PydanticAI 通过结构化验证

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

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

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

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

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

如果 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检索优化应该分成三个阶段，检索前，检索中，检索后

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

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

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

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

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

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

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

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

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

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

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

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

三个基础是说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部署在云端上，如果云端直接链接我的数据库，得把数据库端口暴露到公网，这是危险的。数据流转过程如下：

1. 云端大脑发指令：请帮我读取本地 index.html 的内容。（通过 HTTPS 发回到你电脑上的 Client）。
2. 本地身体 (Client) 收到指令，它得去找 工具 (Server) 要数据。
3. Client 启动 Server 作为一个后台子进程。
4. Stdio 通信发生：Client往Server的stdin里塞一句 JSON：给我 index.html。
5. Server从自己的stdout吹出文件内容返给 Client。
6. 本地身体 (Client) 再把拿到的内容打包，通过网络发回给云端大脑。

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

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

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）中。

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

        它打破了传统 RAG 直接检索聊天记录的粗放模式，会在后台利用模型将用户的对话提纯为结构化的‘事实（Facts）’（比如用户的技术偏好或习惯），并支持按用户、会话、系统三个层级进行灵活的更新与隔离。如果业务场景是 C 端的私人助理或专属导师，Mem0 这种极轻量且高度定制化的记忆机制是**选择。

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

        Zep 则是主打高性能与异步处理的企业级重型记忆微服务。面对高并发场景，Zep 最大的架构优势是它将耗时的 NLP 任务（如滚动摘要、实体提取、向量化）从主业务链路中彻底剥离并异步执行。在检索时，它能结合‘语义相关度’和‘时间近度’动态组装出最优的上下文窗口。因此，在 B 端 SaaS 或高频交互的复杂工作流中，引入 Zep 能极大提升系统的整体吞吐量并有效控制 Token 成本。

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

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

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

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

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

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

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

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

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

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

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

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

在框架选取时，会去选择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能够分析代码之间的映射，构建代码的一个关系依赖图。

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

1. 行动能力，通过 Function Calling 或 MCP，Agent 可以操作物理世界或软件系统。
2. 检索与知识获取，利用 Google/Tavily 实时获取新闻，精准地从公司文档中提取信息。
3. 规划与反思能力，任务拆解，自我修正
4. 长期记忆管理，记住用户的偏好

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

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

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

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

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