Agent八股/核心概念

技术栈只是实现工具，核心是流程设计和架构思维

The lack of hands-on human coding introduced a different kind of engineering work ,focused on systems,scaffolding and leverage.
人类不再需要亲手写逐行代码，这催生了一种全新的工程工作，它聚焦于系统设计、脚手架搭建与杠杆放大。
Human steer.Agents execute.
人类掌舵，智能体执行。

八股知识底座（面试高频点）

├──Agent基础概念/提示词工程/上下文工程/驾驭工程
├──Agent的发展
├──常见的Coding Agent
├──OpenClaw
├──RAG（ 1技术方案 2RAG不准/延迟高3向量数据库/向量模型4文档切分5上下文拓展）
├──提示词注入攻击
├──Skill
├──MCP/A2A
├──Runtime（1Agent范式2意图识别3路由转发4WorkFlow 5LangGraph ）
├──大模型常见问题（1大模型幻觉 2大模型常见范式3大模型循环思考4大模型权限安全5大模型的成本预算）
├──

---

1 Agent基础理解

目的是能够达到根据目标进行任务拆解，路径选择，以达到目标。
Agent=LLM + 记忆上下文(Memory) + 工具调用(Tools/FC) +运行时（Runtime） + 状态管理(State)

PromptEngineering:提示词工程，说话方式
ContextEngineering:上下文工程，提供信息
HarnessEngineering:驾驭工程，指定约束

对应的概念：
（1 上下文工程：负责在大模型收到请求前，对上下文信息（比如说对话信息，向量数据库信息，函数回调信息）进行筛选，压缩的操作。
（2 提示词工程：让大模型能够接收更准确的指令，更好的完成任务。
（3 驾驭工程：让大模型处于一个约束体系当中，类似马匹与缰绳的关系。Harness+LLM= Agent。这个LLM就是那匹马。
实际上有很多都是交叉的，有的属于提示词工程也属于驾驭工程，有的属于上下文也属于提示词工程。目的都是为了更好的使用最低层的LLM。

实际的落地：1 上下文压缩 2 RAG检索 3 意图分析 4 上下文的存储
实际的落地：1 Skill的描述 2 提示词严格约束（提示词注入防御，提示词冲突）3 系统的角色设定
实际的落地：1 工具执行 2 状态管理 3 链路设计 4 Agent范式：ReAct推理执行，Plan and Excute计划执行，Reflexion反思改进。让大模型先去规划，或者先去思考，然后再执行任务。

简单的区分：（了解）
设计时：属于提示词工程
运行时：属于驾驭工程
数据相关：属于上下文工程
如果说设计时就能确定的问题，归提示词工程，在运行时才会出现的问题，归驾驭工程，所有和数据相关的问题，归上下文工程

驾驭工程

阿里在最近推出一个AgentScope Java 1.1。Harness Framework
设计的思路：将下一轮怎么办，下一天怎么办，上下文怎么管，状态丢了怎么办这一系列的工程答案打包起来，而不是每一个Agent项目都各自发明一遍。
核心支柱：

1 数据规范+目录结构
Workspace工作空间：定义了智能体的事务来源文件，比如说Agent人设，记忆，会话日志，知识库，技能等，相当于是智能体的数据仓库结构。WorkSpace可以存放位置
2 读取抽象层
AbstractFileSystem抽象文件系统：定义了一套通用的文件IO接口，负责读写WorkSpace当中的文件。WorkSpace的数据可以存放在本地磁盘，远端的不同位置，这套接口都适用。

---

2 Agent发展历程

将Agent发展历程串联起来：（了解）
起初还没有真正的Agent，就是简单的大预言模型，能够根据用户的描述去推理思考，然后进行回答，但是对于实际的任务无法完成，后续就衍生出了FC/Tools工具调用的概念，以及后续针对复杂业务场景的WorkFlow/Skill。以及为了工具与智能体之间交互的MCP，再然后就是实际的Agent落地，比如26年年初爆火的OpenClaw小龙虾，千问送奶茶，都是Agent落地思想的集中体现。

---

3 常见的写代码Agent

几个常见的写代码Agent：（了解）
opencode开源codingAgent框架
gemini cli/codex cli 属于是官方开源的cli Agent
但是claude code则是属于一个官方完整的coding Agent
openclaw呢则是偏向个人使用的AiAgent。
opencode / Gemini CLI / Codex CLI：Agent 外壳开源，可以研究和二次改造。
Claude Code：更像官方成品工具，可以扩展，但不是拿来改底层 Runtime 的框架。

---

4 Openclaw（小龙虾）

Openclaw（小龙虾）个人助手型的Agent
概念：是一个把网关+Runtime运行时这个架构做到极致的生产级Agent。

爆火的原因我认为有两个：
1 上手门槛极低，不需要过多的专业领域知识做支撑。（适合本地轻量化）
2 刷新了大家对AI落地的认知，原先大家还停留在对话机器人，但是这样的一个以任务驱动为导向的AI落地产品，AIAgent服务，就显得格外亮眼。同期的爆火产品还有千问的送奶茶服务。
后续还了解了底层的一些设计：

（1 结构
整体结构分为两层：GateWay网关层与Runtime运行时。
网关相当于是一个大门，给Agent提供了一个与外界沟通的标准化通道，负责外交部分。
Runtime运行时则相当于Agent内部的大堂经理，需要去组织内部的运营，负责内政部分。

（2 记忆存储：
1 记忆存储分为了三层，短期，中期，长期
短期记忆：也就是当前对话的记忆
中期记忆：跨对话的记忆，每一天交互的日志文件。（YYYY-MM-dd.md，每一天的交互日志记录）
长期记忆：智能体的身份档案。（Memory.md，存储用户身份信息，偏好等）
补充：Dreams.md 梦境机制
默认关闭，每天定点去对记忆去进行总结筛选，将高价值的内容写入Memory.md，反思过程记录在Dreams.md当中。
Dreams.md不是给OpenClaw用的，对OpenClaw来说只是会在这个阶段当中提取重要的或者值得记录的数据然后放入Memory当中，但是不会自动去读取这个md，目的是给用户进行翻阅的，用户可以在这里了解智能体的整体走向。

2 记忆存储形式发生了变化，不直接使用传统的MongoDB等数据库进行存储，而是借助md的形式，但也不是完全不用，毕竟数据库的功能还是很强大的，他借助了轻量数据库SQLite去加快了检索的速率。

作用之一：创建并维护索引（FTS5，B+树），实现对数据的快速定位。（相当于一个存数据，一个存索引）（SQLite：一种轻量级的嵌入式关系数据库，底层是C语言。FTS5全文倒排索引。）
MD原始文件经过规则解析，提取基础元数据（这里也可以选择借助大模型进行语义增强），然后创建B+树索引，实现高效筛选定位，再借助分词器对拆解后的MD正文去做分词操作最后基于分词结果构建FTS5全文倒排索引。

结构展示：

~/.openclaw/memory/
├── agent_12345.sqlite          # SQLite索引数据库（仅索引，非存储）
├── MEMORY.md                   # 长期记忆（身份与核心偏好）
├── DREAMS.md                   # 梦境机制报告（非记忆，仅人类审阅）
└── memory/                     # 中期记忆目录（所有历史活动日志）
├── 2026-05-27.md
├── 2026-05-28.md
├── 2026-05-29.md           # 今天的日志，会话启动时自动加载
└── 2026-05-30.md           # 明天的日志，会在明天第一句对话时自动创建

状态机的实现：（每一个任务执行过程都要不同的状态记录，会实时记录到磁盘当中，便于后续继续进行执行。）

---

5 RAG：检索增强生成

RAG：检索增强生成
简单理解就是给大语言模型挂一个外部知识库，让他能够开卷考试。专业一点就是检索外部知识，将上下文输入给大模型，提高生成信息准确性。
检索：搜集资料/增强：增加大模型的输入信息量/生成：大模型的自然语言生成

内容分点：
1 技术方案
2 RAG不准/延迟高
3 向量数据库/向量模型
4 文档切分
5 上下文拓展

1 检索技术方案

一种是基于语义去向量检索。
一种是基于分词、倒排索引做字面的匹配以及相关性打分排序的关键词全文检索。
比如说ES，PgSQL的FTS关键词全文检索+打分排序。

2 RAG不准与延迟高

RAG不准
思路：提示词部分->文档切分->检索->返回
1 提示词优化，就像Trae当中的那个优化提示词按钮。
2 文档切分优化，选择合适的切分策略。
3 借助Hybrid混合检索，基于向量检索与关键词全文检索，再结合过滤打分等机制。
4 对于未知或者模糊的返回结果直接说不清楚。

RAG的延迟高（了解）
借助缓存存储
降低召回数量
流式输出（实际的问题并没有解决）

3 向量数据库与向量模型

（1 向量数据库的选择：
Redis，pgSQL+vector，pgSQL+FTS，ES，MongoDB
是否需要关键词+向量混合检索？

├─ 是 → 项目是否已有ES？
│   ├─ 是 → 首选 Elasticsearch
│   └─ 否 → 核心数据是否在PG？
│       ├─ 是 → 首选 PostgreSQL(pgvector+pg_jieba)
│       └─ 否 → 是否用MongoDB Atlas？
│           ├─ 是 → 可选 MongoDB 向量
│           └─ 否 → 优先 PostgreSQL
└─ 否（仅纯向量检索）
├─ 向量量 < 100万 → 已有Redis用Redis，已有PG用PG
├─ 100万 < 向量量 < 1000万 → 首选 PostgreSQL
├─ 1000万 < 向量量 < 1亿 → 首选 Milvus
└─ 不想运维 → 首选 Pinecone

（2 向量模型的选择：
Embedding Model 可以用大厂的API，当然预算充足或者有特定的要求也可以自己去基于Ollama（一个可以执行基于 Transformer 模型架构设计的运行环境，支持CPU，GPU）实现本地部署。

（3 实际的向量数据库：
Elasticsearch：已有 ES 做全文检索时首选，一站式实现关键词 + 向量混合检索，中小商用标配。
PostgreSQL：无 ES 且核心数据存 PG 时首选，一库多用，彻底消除跨库同步问题。
Redis：内存级向量检索，仅适合小体量热点数据，追求极致低延迟的缓存场景。
Pinecone派恩・扣恩）：纯托管零运维向量库，适合不想投入运维的团队和海外云原生项目。
Milvus（米尔沃斯）：国内开源专业向量库，海量数据高并发首选，运维复杂度较高。
MongoDB：仅适合 MongoDB Atlas 云用户，零同步成本，自托管场景绝对不推荐。

向量相似度算法：余弦相似度，欧几里得距离，曼哈顿距离。1 看两个向量之间的夹角2 空间中两点的直线距离3 各维度的距离差值加起来

4 文档切分策略

文档切分（chunking）的策略？
（1 按照递归字符+滑动窗口重叠
（3 按照语义切分
（4 固定长度切分（可以按照字符或者Token）
（5 代码切分/PDF，先多模态识别再切分

补充：递归字符切分+滑动窗口重叠：按照段落，换行，标点先进行语义的切分，滑动窗口切片重叠切分。在Langchain当中已经内置实现，也是默认的文档且分器。
需要配置三个参数，一个是块大小，一个是重叠大小，一个是语义优先级大小。
一个分割示例：块大小为20，重叠部分为5，并设置对应的分隔符优先级。
原句：北京是中国的首都。它有着悠久的历史。故宫是著名的景点。长城也非常壮观。每年都有很多游客来参观。
块1（18字符）：北京是中国的首都。它有着悠久的历史。
块2（14字符）：久的历史。故宫是著名的景点。
块3（13字符）：名的景点。长城也非常壮观。
块4（17字符）：非常壮观。每年都有很多游客来参观。

5 上下文拓展方式

RAG召回时的上下文拓展方式：（基于递归+滑动窗口重叠）
（1 相邻块拓展：切分成许多块之后，不但检索回命中的，还对应的检索携带前后几个块，便于大模型理解。（分块的大小不是很大，需要手动的去编写检索的代码，更加适配一些PDF，Word转文本非结构化的文档）
向量召回 TopN 核心块 → 每个块拓展前后 N 个相邻块 → 合并去重 → 送入大模型；
（2 父子文档拓展：两层切分，一个父层一个子层，子层做向量化，父层存储数据，检索时召回子层对应的父层数据。（langchain框架内置，生产级别推荐，更加适配md这种结构化的文档）

---

2 提示词注入攻击

提示词注入攻击？
=1 （直接）用户直接输入强制执行的指令，让智能体执行特定任务。
=2 （间接）表面合法实际上是隐藏Boss。

解决方案：
-1 借助标签，将用户的输入包裹在XML标签当中，优先级低于预先编写的约束。
-2 重写检查，借助低层次的大模型进行提示词重写检查，对一些敏感，越狱的词汇进行过滤。
-3 严格约束，权限约束严格一点，比如说一些MCP工具的使用权限，必须用户身份为管理员。

例子：
（1 让AI去调用转账的工具 2 让AI直接忽视之前的命令。
（ 1 将指令藏在需要解析的网页，图片当中让Ai去读取，翻译，润色。2 比如说让AI将一个黑客的故事，黑客如何入侵网站，或者给让AI给我非法网站，然后骗他说我不看）

---

3 Skill

Skill
概念：面向特定业务场景的能力包，包含详细的操作流程指导，相当于是一套完整的解决方案。（可以理解为由LLM驱动的WorkFlow，WorkFlow属于Skill内部的一部分）
怎么去编写对应的skill：定义好业务的生效场景，遇到业务场景如何去做。比如说读取什么Skill文档，执行什么脚本

组成成分：
1 skill.md：定义流程能干什么事情
2 references：参考资料参考数据
3 scripts：资源脚本
4 assets：其他的材料

加载机制：
Skill的名称以及描述（这部分是始终加载的）
Skill当中的信息（按需加载）
其他的资源/脚本（按需加载）

---

4 MCP与A2A

MCP与MCPServe以及A2A
MCP：模型上下文协议，属于一种协议，是用来规范Agent与外部能力的交互，比如说Tool工具，资源Resource，提示词prompt
MCPServer是实现MCP的服务端程序，可以实现多语言的开发并且支持互用。（Agent基于MCPClient客户端去进行调用，如果SpringBoot服务想要调用，可以直接集成MCP的依赖然后将方法进行注册）

A2A:
A2A全称是是智能体间协议，用于智能体之间的调用协作。

---

5 AgentRuntime 执行引擎

AgentRuntime 执行引擎
├── 1. 往哪走（决策设计策略）【大脑】
│   ├── 核心作用：接收用户提示词，通过决策体系判断任务方向、分发任务
│   ├── 智能体范式
│   │   ├── ReAct：边思考边执行，动态迭代，适配未知场景
│   │   ├── Plan and Execute：全局先规划，适合长链路复杂任务
│   │   ├── Reflexion：关键节点反思纠错，提升执行准确率
│   │   └── 落地组合：全局规划 + 局部迭代 + 节点反思
│   ├── 意图识别：对用户需求做分类，支持规则匹配、LLM识别、混合识别
│   └── 路由分发：简单场景用if-else路由，复杂多轮场景用图结构条件边路由
├── 2. 走哪条路（流程设计策略）【骨架】
│   ├── 核心作用：通过工作流约束任务边界、管控整体执行流程
│   ├── WorkFlow工作流：业务流程设计图纸，规定执行阶段、顺序、衔接与循环规则
│   └── LangGraph图编排（核心实现）
│       ├── State：全局共享状态，支持多轮接续、断点续跑
│       ├── Node：执行业务逻辑的处理单元
│       └── Edge：条件边/普通边，实现分支、跳转、动态循环
└── 3. 靠什么走（组件设计策略）【手脚】
└── 依托各类核心组件支撑整体运行：记忆管理、上下文工程、提示词工程、FC工具调用、RAG向量检索，完整驱动Agent Runtime执行

概念：AgentRuntime运行时相当于是一个全局的指挥中心，比如说一次任务中从哪里开始、经过哪些节点、调用哪些工具、保存哪些状态、什么时候继续、什么时候结束，实现任务生命周期的精细化管理。

Runtime运行时的设计：
我认为应该从三个方面思考：往哪走，走那条路，靠什么走。
1 往哪走：提示词进来了，进行决策，去进行意图识别，路由转发。
2 走哪条路：根据业务场景设计出对应的WorkFlow工作流。
相当于一个是导航指引，一个是地图路线。共同组成了GPS系统。
3 靠什么走：上下文工程，提示词工程，驾驭工程，FC/Tools工具调用，RAG向量检索等技术将这个运行时机制整体给跑起来。

（1 Agent范式

1ReAct（推理执行）：边推理边执行，走一步看一步。不断的思考-行动-观察，再思考，再行动，再观察以达到最终的任务。（很方便，但是存在死循环以及预算的问题）
2 Plan and Execute：（计划执行）先对整体任务做出全局规划，再按计划逐步推进，适合解决长链路、多步骤的任务。
3 Reflexion：（反思改进）对执行结果进行反思，提炼出经验以及约束，注入后续思考，达到反思改进的效果，适合解决执行错误但是不长记性的问题。
实际的项目落地可以将三者进行结合，全局做Plan and Execute进行全局规划，在局部进行ReAct思考执行，在关键节点再去进行Reflexion分析评估纠错。
4 ToT（Tree of Thoughs）：将问题的解决方案建模为树结构，每个节点代表一个想法，择优选取（解决方案过于单一固定的问题）–作为拓展

先意图识别，再路由转发

（2 意图识别策略

意图识别策略？
概念：本质上解决的是分类问题，对用户提示词当中的需求进行分类。
常见的实现策略：
1 提示词的关键词筛选或者正则匹配
2 大模型去分析意图
3 二者结合：关键词的规则判断结合LLM的意图识别

（3 路由分发策略

路由分发策略？
根据意图标签分析出需要路由的业务处理器。如果说简单一点，直接借助ifelse的条件判断，如果涉及多轮交互，那就需要结合图结构，借助条件边的思想去进行路由转发。

（4 WorkFlow工作流

Agent的Workflow工作流如何理解？
WorkFlow是一个设计理念，针对具体的业务流程设计对应的工作流。比如说干工程，要先把设计图设计好，再去找工程进行一步一步的完善，LangGraph是实现动态WorkFlow的工人。
实际的落地：比如说客服系统，RAG系统，Skill内部对于不同场景的流程规划，这些都是对WorkFlow的体现。
核心是实际的过程处理，WorkFlow相当于是一个设计图，需要结合很多组件，用来规定任务按什么阶段推进、每一阶段做什么、各阶段之间如何衔接，以及哪些环节允许动态决策和循环。

（5 LangGraph

介绍一下langGraph？（Graph+State）
核心是图结构+State进行流程的精细管理。
三个核心要素：
State：执行状态（比如说当前已经查询天气，还未去调用邮件Tool工具进行邮件发送，可以快速读取状态接着之前的任务去工作，而不是从头开始)
Edge：根据State执行状态来路由Node节点，进行跳转。
Node：处理逻辑的Python函数。
各个步骤都是一个节点，每一条边就是一个策略，状态在节点之间流转，将状态进行记录，之间根据状态切换抉择路线

通俗理解：
用户设置目标就像给出目的地；
Graph 是完整地图，定义有哪些节点和可走路径；
Workflow 是预设路线，适合固定流程，但如果没设计异常分支，就无法自动切换路线；
Runtime 像导航系统，会根据当前 State 在 Graph 或 Workflow 中选择下一步，比如说前面出现交通事故然后切换路线；
LLM 像大脑，负责理解和推理；
Tool /Function Calling像交通工具，负责执行具体动作；
Memory 像驾驶经验，提供历史偏好；
Skill 像驾驶手册，指导 Agent 在特定场景下如何处理任务。

---

6 大模型常见问题

大模型可能出现的问题

（1 大模型幻觉

什么是大模型幻觉？大模型幻觉如何去进行解决？
大模型实际上不知道，但是硬答，没查到硬编，工具没调成功自己编
输入层->推理层->输出层

1 提示词约束，不知道就是不知道
2 RAG 回答必须基于检索内容，并携带引用来源。将事实性的查询交给工具处理，不让模型自己分析。
（RAG设计也要注意提高RAG的准确率，提示词可以优化，选择合适的切分策略，RAG策略采用混合检索，返回结果要有根据）
3 在最终的兜底返回要做严格的校验，并且如果不知道可以直接返回未知，而不是自己造。

（2 大模型相关范式

说说大模型相关的范式？
提示词工程范式：

大模型范式：（生成符合人类意图的文本）
预训练+微调范式：借助海量数据去做通用学习，再借助标注数据把通用模型变成领域模型
提示词工程范式：通过设计更加准确的提示词，让大模型更好的执行任务。

智能体范式：（自主完成复杂的任务）

单智能体
1ReAct（推理执行）：边推理边执行，走一步看一步。：目光短浅。
不断的思考-行动-观察，再思考，再行动，再观察以达到最终的任务。（很方便，但是存在死循环以及预算的问题）

2 Plan and Excute：（计划执行）先对整体任务做出全局规划，再一步一步的完成任务。：目光长远。

3 Reflection：（反思改进）对执行结果进行反思，达到反思改进的效果。：让大模型长记性

实际的项目落地可以将三者进行结合，全局做Plan and Execute进行全局规划，在局部进行ReAct思考执行，在关键节点再去进行Reflection分析评估纠错。

4Self-Refine（自我优化）：先生成答案再自己迭代修改

5 ToT（Tree of Thoughs）：将问题的解决方案建模为树结构，每个节点代表一个想法，择优选取（解决方案过于单一固定的问题）–作为拓展

补充 CoT（思维链）知识不断的思考，但是不去调用工具。

2 多智能体协作
分工协作

应用范式：
1 上下文学习/提示工程范式：根据提示词调控模型的行为
2 RAG范式：让模型先检索再回答
3 工具调用范式：让模型真正的去做事
4 Agent智能体范式：让大模型结合多种能力实现解决复杂任务的能力。

（3 循环思考问题

如何解决循环思考问题？
1 设置最大步数
2 设置最大工具调用次数
3 设置时间限制

（4 权限安全问题

如何解决权限安全的问题？
将权限不由大模型进行判断，将权限交给后端系统进行判断

（5 成本控制

如何对成本进行控制？
模型分层+Token限制
避免每次都去走高质量的大模型，可以分任务，一些简单的可以使用小模型，一些复杂的再去用大模型，并且对Token的用量加以限制。

（6 大模型微调

大模型微调：（了解）
借助特定场景或者领域的数据集，进行二次训练，调整模型的部分参数，让模型在特定场景之下有更加优异的表现或者性能。
RAG是属于给大模型一个参考书进行翻阅，实时查询数据。微调是让大模型改变原有的一些习惯。

---

10 对话记忆管理

对话记忆管理：
(1 规则记忆：系统提示词，角色约束，工具约束，Skill说明（git+md）
(2 会话记忆：
单纯的对话记忆，将对话的交谈过程完整记录——可直接存放在MongDB当中，实现会话记录回显
（想实现短期记忆可以直接从MongDB当中读取最近N轮即可，中期记忆借助collection，对会话进行提取，避免上下文太长）
长期偏好记忆：从会话当中提炼出用户偏好，建立用户画像——可以存MongDB，也可以Mysql，pgsql，看实际的业务设计了。
（这些偏好可能是固定的，比如你说你是谁，喜欢用Java，属于用户偏好，但是你说很多次你的手机是什么牌子，可能也未必属于偏好）
长期跨对话语义记忆：可以基于向量数据库进行RAG长期语义检索。
（比如我之前说我写过一个智能体项目，里面是关于医院预约挂号的，智能体以后举例子可能都会提到这个，这种方案不一定需要实现，适用于一个用户会多次交流的场景。（但是需要去把握存储的数据量精细程度）
(3 检索记忆：文档分块，向量模型向量化（向量数据库pgsql+pgvector/MongDB+MongDB vector）
(4 业务记忆：业务数据存储在对应的关系型数据库即可（MYSQL，Pgsq，Redisl等）

---

三 本地实际落地学习demo

如何把大模型、记忆、检索、工具、业务流程和运行时调度组合成一个完整 Agent 系统。

几个核心模块的设计：
1 Runtime运行时
2 Memory记忆存储
3 RAG检索增强生成
4 Tool/Skill工具调用能力

1 AgentRunntime运行时调度设计

项目当中的AgentRunntime运行时调度如何设计的？
我在项目当中借助了意图驱动与状态机的方式。
用户请求首先进入 FastAPI API，然后由 ChatService 做接口适配，真正的核心调度交给 AgentRuntime。
AgentRuntime 可以理解为整个智能体的运行时调度中心，它负责决定当前请求应该如何处理、走哪条业务链路、是否需要检索知识库、是否需要调用工具。
对话前会加载未完成的pending operation待完成操作，然后借助MemorManager记忆管理区处理用户的输入，用户的短期上下文，用户的会话摘要，用户的长期记忆，这里对上下文采用了多层的记忆存储方式。
然后请求到达意图路由的部分，根据用户的意图，上下文的记忆，分发到不同的业务处理器当中，不同 Handler 负责不同业务场景。
1 如果是知识类问题，进入 RAG 检索链路。
2 如果是需要调用业务系统的问题，进入工具调用链路，调用对应的Tools。
3 如果是需要多轮交互的流程类问题（像课程预约），进入 LangGraph 编排的业务流程。将校验，确认，预约等一系列流程抽象成节点Node，然后再借助条件边Edge，根据State状态决定下一步的走向，注册完成后共同组成一个Graph的结构。

2 记忆化分层

记忆化分层：
分为短期原始对话、中期增量摘要、长期用户偏好、跨对话语义记忆四层结构共同支撑上下文（还对语义冲突做了对应的应对方案）

简化版：
第一层：短期记忆：保存完整的对话记忆。
第二层：中期记忆：借助滑动窗口维护最近上下文，历史上下文生成对话摘要进行存储。
第三层：长期用户记忆：构建用户画像。
第四层：跨对话记忆：存储重要事实。
在调用大模型时，会把系统提示词，用户偏好，会话摘要，最近的上下文，跨对话记忆Topk，工具的调用结果，一起进行封装。

处理语义冲突：从两个方面去设计（1提示词工程 2 上下文工程）***************************************************
提示词工程：==========================
(1 在项目当中的提示词当中设置好全局的记忆优先级。比如说当前的用户输入与用户记忆，最近会话与长期记忆。

上下文工程：==================================
（2 长期用户记忆：主要是针对用户的画像随时可能会发生变化，我本地没有用直接覆盖的方式，而是借助软删除维护多个状态。
借助Active、Outdated、conflicted、deleted状态来控制记忆是否可用。使用时，先筛选置信度，再置信度达标的前提下去判断状态。
出现了conflict就说明语义无法分辨，就不放入提示词当中，如果出现了outdated就说明这个偏好已经被淘汰了，也不放入提示词，如果说出现deleted说明被用户显示删除，同样不放入，只有出现active才放入提示词。
（3 跨对话记忆需要做到相同去重，相似归并，中等相似度降权。
（4 会话摘要，在做增量修订维护最新摘要时，需要以新消息为准。

完整版：
（1：对话记忆（短期记忆）：存储完整的对话信息。
（2：会话摘要（中期记忆）：
分为两层：
1 借助滑动窗口机制去维护短期上下文，保留最近几轮对话，前面的历史对话生成摘要，实现对长上下文的压缩。
2 单独维护一个完整的上下文摘要，在对话结束后会将对话摘要与滑动窗口内部的对话生成摘要，并生成跨对话记忆与长期用户记忆。
（3：用户偏好（长期记忆）：
计算出偏好的key，再计算出置信度，再与数据库当中的偏好进行比对，设置对应的状态值。
（4：跨对话记忆：保存一些用户描述的事实，存入向量数据库，后续按需进行召回。

3 Hybrid RAG混合检索

Hybrid RAG混合检索
设计的核心思想是：双路召回+融合排序+过滤筛选

我本地做混合检索没有使用ES数据库，而是使用了PgSQL的一些拓展，pgvector/pgsearch，但是性能上还是比不上ES。

PostgreSQL 本体
├─ full-text search：关键词全文检索
└─ pgvector 扩展：向量语义检索

流程：=======================================================
使用Pgvector拓展实现语义向量检索，基于PgSQL的FTS做关键词全文检索。
两种方式各自召回Top20，然后基于RRF倒数融合算法合并结果，再进行排序，最后筛选出Top5给大模型。
（使用内置函数ts_rank_cd/ts_rank，检索关键词并打分，然后再将两者检索后的数据筛选出Top20，先进行去重然后合并，因为两种检索方式的打分标准不同，这里基于RRF倒数排名融合去按照排名的方式进行排序，最后再进行Rerank进行再次排序得到最终需要的Top5。过程当中还结合元数据的字段标签进行类型筛选。）

全文检索前置：
文档 → chunk分词 → to_tsvector将文档进行加工 →存入 search_vector → GIN 索引
（需要配置对应的zhparser分词器，只做一次表配置，之后永远只存原始文本，PG 自动帮你完成分词、生成索引、更新同步所有事）

向量检索前置：
文档 → chunk切分 → embedding 模型 → embedding 向量化并存储向量数据库 → pgvector 向量索引

（4 结构图

用户问题
↓
Query Rewrite / 意图识别 （这里可以根据情况加权限过滤）
↓                              ↓
向量检索 Dense Retrieval                 Full-Text / ILIKE 检索兜底
↓                                                                     ↓
候选片段 TopN                                           候选片段 TopN
↓                                                                         ↓
└───────             合并去重        ───────┘
↓
RRF 分数融合（基于排名）
↓
metadata_filter 元数据过滤（限制文档）
↓
rerank 重排序
↓
返回 TopK 文档片段
↓
组装 Prompt 给大模型回答

（5 字段设计

rag_chunks
├─ id
├─ doc_id
├─ title
├─ section
├─ content
├─ metadata
├─ embedding        → 给向量检索用
└─ search_vector    → 给全文检索用

打分：
用户问题
↓
plainto_tsquery(‘simple’, query)用户问题加工成检索条件
↓
search_vector @@ plainto_tsquery(…)判断是否命中
↓
ts_rank_cd(search_vector, plainto_tsquery(…))命中进行打分评判
↓
按相关性分数排序
↓
返回 Sparse TopN

4 Tools/FC

Tools/FC
基于SpringCloud的微服务，Nacos的服务注册，服务发现，再结合Agent的智能体进行结合。
Agent 只调用统一网关 API，网关通过 Nacos 找到具体微服务实例，再把请求转发过去，将功能封装成对应的Tool实现调用链路。

5 存储方案对比

1
借助MongDB存中期的对话，以及短期的持久化，长期存储在PGSQL当中，然后Redis做缓存
借助Es去实现向量数据库，实现混合检索，向量检索与基于关键词全文检索（分词，倒排索引，BM25打分排序等操作）
2
借助MongDB存储中期短期长期对话，不借助Redis，借助Pgsql存储实际的业务以及借助PgSQL存储向量，并基于内置的FTS+tsrank实现关键词全文检索。也就是借助PgSQL实现Hybrid混合检索。（适合简单Demo）
3
借助MongDB存储中期长期短期对话，借助Redis存向量实现向量检索，然后再借助ES去实现关键词全文检索。（双检索引擎，并且原生数据存储是在MongoDB当中，存储一定的一致性风险）