当前位置：首页 > news >正文

万字深度解析 Agent 学习路线

news 2026/8/14 4:32:00

随着 AI Agent 岗位的兴起，以及对 AI 工具的普及，很多小伙伴都会面临一个问题：AI Agent 到底要怎么学？学到什么程度才算能写进简历？能不能有一个清晰的规划路线？

这不，它来了！我整理出了一份极其详细的资料，让小伙伴可以沿着一条完整主线来学习。

这篇文章不按“第一阶段、第二阶段”那种方式罗列知识点。那样很容易变成背目录，难以把整个脉络串起来。这里换一个角度：从一个真实 AI 系统需要交付的能力倒推，看看应该补哪些知识、做哪些项目，最后怎样把它讲成面试和简历里有价值的内容。

如果你只想先看完整知识体系，可以从这篇开始：AI 大模型面试备战路线。
如果你更想直接看项目，就先看：什么是超级 AI 智能体。

这篇路线适合谁

这篇文章主要面向已经具备 Web、数据库、缓存、消息队列等后端基础，希望转向Java AI / Agent 应用开发的工程师。阅读时不需要一次学完所有框架，先沿系统链路建立全局认识，再用项目逐段补齐能力即可。

后端学 Agent，要注意这七个层面

先看总图。七层能力从模型认知逐步走到生产工程化，每学完一段，都用一个可运行项目留下证据。

你要补的能力	解决什么问题	学到什么程度算过关
大模型基础认知	知道模型能干什么、不能干什么	能解释 Token、上下文、Temperature、幻觉、模型选型
模型接入层	把 LLM 接进后端服务	能做非流式、流式、超时、重试、降级、多模型切换
Prompt 和上下文工程	让模型稳定按你的业务规则干活	能管理系统提示词、结构化输出、上下文预算、Prompt 评估
RAG 知识库	让模型回答私有知识和时效知识	能做文档处理、切片、向量化、检索、重排、评估、更新
Tool Calling / MCP / Skills	让模型从“会说”变成“会做”	能把业务接口包装成工具，并做好权限、参数、错误处理
Agent 编排和记忆	让系统能处理多步任务	能理解 ReAct、Plan-and-Execute、Workflow、Memory、状态流转
生产级工程化	让 Demo 变成能上线的系统	能做网关、观测、成本、测试、安全、灰度和故障兜底

把 Agent 系统理解成一个“会调用模型的后端平台”。模型只是其中一环，真正决定项目效果的，是模型外面这一整圈工程能力。

阅读这张图的方法

上半部分是需要逐步补齐的系统能力，下半部分是用来证明能力的项目证据。学习目标不是“看过七个名词”，而是能把任意一次请求放回完整链路中，解释数据从哪里来、决策在哪里发生、失败后怎样定位。

从一个真实请求来看 Agent 系统到底长什么样

我们先把 Agent 系统给拆开来看一下，用户先在页面里输入这样一句话：

“帮我总结一下这份项目文档，并告诉我里面涉及哪些技术风险。”

一个成熟点的系统不会直接把这句话扔给模型。它大概率会走完下面这条链路：

接入层先做登录校验、限流、会话校验。
会话层加载历史上下文，决定要不要带最近几轮对话。
编排层判断意图：这是文档问答、摘要任务，还是开放式分析。
上下文层拼装规则、用户问题、文档片段、历史记忆、工具结果。
RAG 层做文档解析、分片、向量检索、关键词检索、重排序。
工具层可能调用数据库、搜索服务、文档解析服务或 MCP 工具。
模型层调用大模型，处理流式响应、超时、重试、结构化输出。
观测层记录 Token、延迟、检索证据、模型输入输出、工具调用。
输出层用 SSE 推给前端，最后补引用来源、推荐追问或错误提示。

两条不能交给模型越过的边界

没有可信证据时短路或澄清，不要让模型用“听起来合理”的内容补空白。
退款、发券、发邮件等高风险写操作必须经过后端鉴权和人工确认，不能把模型给出的参数当成授权结果。

这条链路里的每一步，都是后端工程要解决的问题。

所以学习 Agent，我会建议按“系统链路”来学：

系统位置	要学习的能力	最后能做什么
模型接入层	LLM API、Spring AI、流式输出、结构化返回	做一个稳定的 AI 对话接口
上下文层	Prompt、上下文工程、Token 预算、记忆裁剪	让模型拿到该拿的信息
知识层	RAG、Embedding、分片、混合检索、重排序	做企业私有知识库问答
工具层	Function Calling、Tool Calling、MCP、Skills	让模型能调用外部系统
执行层	ReAct、Plan-and-Execute、工作流、状态机	让 Agent 能分步骤做事
工程层	网关、限流、熔断、异步、可观测、成本控制	把 Demo 拉到生产
项目层	超级智能体、知识路由、图谱、Trace	把所有知识串成项目证据

第一步：先让模型调用变得稳定

一开始先不要就搞多 Agent 这种。第一步其实要求很低：直接就把大模型当成一个又慢、又贵、又不稳定的第三方接口来看待就可以，所以你需要先搞懂这些东西：

Token 是什么，为什么输入越长越贵？
上下文窗口是什么，为什么模型会“忘事”？
Temperature、Top-P、Max Tokens 这些参数会怎么影响输出？
流式输出为什么比同步等待体验好？
同一个接口怎么切 OpenAI、通义、DeepSeek、Qwen、本地模型？
模型超时、限流、返回半截 JSON 时怎么办？

对应的讲解可以按这个顺序看：

入门认知：大模型基础入门
工作原理：大模型工作原理剖析
核心概念：Token、上下文窗口、Temperature 等核心概念
能力边界：大模型能力边界与破局之道
开发环境：大模型开发环境搭建实战
Java 接入全景：Java 调用大模型全景图
Spring AI 入门：Spring AI 快速入门实战
流式输出：响应式流式输出详解
API 工程化：大模型 API 调用的工程化实践

这块学完以后，就要开始做一个小项目了，哪怕简陋点也是没有关系的。

项目 1：AI Chat Gateway

最小可交付版本

提供/chat普通接口和/chat/streamSSE 流式接口
支持配置切换模型供应商
记录每次调用的输入 Token、输出 Token、耗时、模型名
给模型调用加超时、重试、降级提示
前端能看到打字机效果

可以再进阶一点

加一个模型网关层，业务代码不直接依赖具体模型 SDK
加 Redis 缓存相似问题结果
加限流，防止某个用户刷爆 Token
加统一错误码，不要把模型报错原样甩给前端
增加模型调用审计表，记录请求来源、模型、耗时、Token、失败原因
把模型调用封装成内部 SDK 或 Starter，别让每个业务都重复接一遍

这时候你已经比“我会调 API”的人强一截了。面试官问你怎么做大模型接入，你能聊出线程池、SSE、超时、降级、计费，这就有点开始像后端项目的样子了，棒棒的！

第二步：要把 Prompt 当成业务规则，而不只是一段字符串

我发现很多人学 Prompt 的方式，是收藏一堆“万能的提示词模板”。只能说有点用吧，但不多。。。

在真实项目里，Prompt 更像业务规则。它会被产品修改、被运营调整、还要被安全要求约束，还要版本管理。不能硬编码在 Java 字符串里。

你需要掌握的是这些

Prompt 的角色、任务、上下文、输出格式怎么拆
Few-shot 什么场景值得加，什么场景只会浪费 Token
CoT、反思、自一致性这些技巧怎么用在工程里
怎么让模型稳定输出 JSON 或结构化对象
用户输入怎么隔离，防 Prompt Injection
Prompt 怎么外置、版本化、灰度和评估
上下文工程怎么把规则、记忆、RAG、工具结果拼在一起

如果你把这块做得要像样一点，通常会是下面的这个结构

系统提示词负责边界和风格。
任务提示词负责当前目标。
用户输入单独包起来，避免和规则混在一起。
RAG 证据、工具返回、历史记忆按优先级拼装。
输出格式明确到字段级，最好有 JSON Schema。
最后再做校验、修复和回退。

图里的上下两条线需要一起看：上面是一次请求怎样从业务进入模型，下面是版本、Token、延迟、成本和审计怎样贯穿整个调用过程。这样设计以后，业务代码只依赖统一网关和结构化契约，不需要跟某一家模型 SDK 绑死。

项目 2：Prompt 配置中心

你可以先做一个简单版

把系统提示词、任务提示词、输出格式模板拆开存储
支持变量注入，比如{userQuestion}、{knowledge}、{history}
给每个 Prompt 加版本号
保存每次模型调用使用的 Prompt 版本
输出 JSON 后做 Jackson 解析和 Bean Validation 校验
解析失败时最多重试 2 次，把错误原因反馈给模型修复
给 Prompt 配一组固定测试题，做回归评估
记录每次命中的 Prompt 版本、模型版本和输入摘要，方便排查坏的情况

如果你想更像生产项目的话

接入 Nacos / Apollo 做热更新
做 A/B 测试，对比两个 Prompt 的命中率和用户反馈
加一组固定评测题，每次改 Prompt 都跑一遍
对用户输入加标签包裹，比如<user_input>，降低注入风险
不要把长文本直接拼接进模板，尽量做字段化拼装
结构化输出失败后，允许有限次数的“格式修复”而不是无限重试

这块学完以后，你在面试时，就不要只说“我会 Prompt 工程”。现在你就可以这样来讲：

我们把 Prompt 当成业务规则管理，做了模板外置、变量注入、版本记录和输出校验。模型返回结构化结果后会先过 JSON Schema 和 Bean Validation，失败会进入有限次数的修复闭环。这样 Prompt 调整不用每次发版，也能追踪某次错误回答到底用了哪个版本。

第三步：RAG 要按生产真实的流程来学

RAG 可以说是后端转 AI Agent 最该认真，也是最难学的部分了。因为它是一整条的工程链路，里面设计到的功能实在是太多了。

很多 Demo 的 RAG 基本是这个流程：上传文档，切块，向量化，检索，生成。

如果是真实的系统，其实要麻烦得多：

PDF 解析出来全是乱行怎么办？
表格、图片、代码块怎么处理？
分片太大，检索不准；分片太小，答案没上下文。
用户问“它怎么配置”，没有历史上下文根本不知道“它”是谁。
向量检索能理解语义，但搜订单号、版本号、函数名很弱。
检索到了 20 段，哪些该喂给模型？
模型没拿到证据时，会不会自己编？
文档更新了，向量库怎么增量同步？
上线以后怎么证明效果变好了？

这些也只是 RAG 的一部分。

我建议你把 RAG 拆成离线和在线两条链路来看：

链路	主要工作	容易踩的坑
离线链路	文档解析、清洗、切片、向量化、索引构建、增量更新	垃圾文本入库、标题层级丢失、权限元数据缺失、更新不及时
在线链路	问题改写、意图路由、混合检索、重排序、证据拼装、生成回答	召回不准、证据太长、无证据还硬答、日志里看不出错在哪

离线链路决定“知识是否被正确保存”，在线链路决定“问题是否找到正确证据”。评估结果还要反向推动解析、分片、检索参数和索引更新，所以生产级 RAG 是持续迭代的闭环，不是一条跑完就不再变化的流水线。

1. 先处理清洗好文档

很多 RAG 出现问题时，其实并不是向量库的方面，而是在文档处理是太过于粗糙了

PDF 解析顺序乱，正文、页眉、页脚混在一起
表格丢失，导致关键信息没进知识库
图片里的文字没有 OCR
Markdown 标题层级被打平
代码块、配置块被切碎
文档版本、部门、权限、发布时间没有记录

2. 切片不能按字数一刀切

Chunk 切得太碎，语义断了；切得太大，召回不准，还浪费 Token。更靠谱的做法是结合标题层级、段落结构、语义完整性、Overlap、元数据和父子块。

比如技术文档可以按标题层级切，FAQ 可以按问答对切，合同条款可以按条款编号切，接口文档可以按接口维度切。不要一上来就固定 500 字数直接切，这样很容易把一个完整语义拆散。

3. 要知道 Embedding 和向量检索的原理

你倒是不需要手写 HNSW，但至少要知道：

Embedding 是把文本映射成向量
换 Embedding 模型通常要重建索引
余弦相似度、点积、L2 距离适用场景不同
ANN 是用近似换速度
IVF、HNSW 的核心思路是什么
向量库选型要看数据量、过滤能力、运维复杂度和生态支持

4. 只做向量检索是不够的

向量检索擅长语义相似，但对订单号、版本号、函数名、政策编号、专有名词就不行了。真实的生产里通常会组合多个功能：

向量检索：找语义相关
BM25 / ES：找关键词精确匹配
元数据过滤：控制权限、部门、版本、时间范围
RRF：融合多路召回结果
Rerank：对召回结果重新精排
Query Rewrite：把用户口语化问题改写成适合检索的问题
Intent Routing：决定问题走知识库、工具、闲聊还是澄清

5. RAG 必须有评估和更新机制

上线后肯定会遇到这些问题：用户说搜不到、答案引用错、文档更新了但知识库没更新、同一个问题今天答对明天答错。

所以至少要准备一批评估问题，并且看这些指标：

检索层：Hit@K、MRR、Recall、Precision
生成层：忠实度、答案相关性、幻觉率
业务层：用户采纳率、人工转接率、投诉率

学习顺序可以这样

先看整体：RAG 入门与核心原理
看架构演进：RAG 三代进化史与架构选型
看文档处理：文档预处理、读取、清洗与标准化
看解析工具：搞懂 Tika 才能做好 RAG 文档解析
看分片：文档切片策略选择
看 Spring 实战：分片代码实战 Spring 系列
看向量化：Embedding 向量化原理与模型选型
看索引算法：向量检索核心算法深度剖析
看数据库选型：向量数据库选型实战指南
看元数据：元数据的详细解析和元数据过滤场景
看查询改写：为什么要问题重写
看路由：查询的路由是必不可少的
看混合检索：混合检索的详细剖析
看重排序：重排序的好处是什么
看 GraphRAG：图结构 GraphRAG
看流水线：RAG 的组件拼接成流水线
看幻觉治理：RAG 系统幻觉治理实战
看评估：RAG 效果评估与量化指标
看更新：知识库动态更新工程实践
看踩坑：RAG 生产环境踩坑与调优经验

RAG 的实战项目不要做得太玩具了。我建议你做“企业文档知识库”这种功能，哪怕只有几份文档，也可以把链路做完整了。

项目 3：企业文档知识库

基础版

支持上传 PDF / Word / Markdown
用 Tika 或其他解析工具转文本
支持至少两种分片策略：固定长度分片、按标题层级分片
使用 Embedding 模型向量化
向量存储可以先用 PGVector
用户提问时检索 TopK 文档块
回答必须附引用来源
无证据时直接提示“资料里没找到”，不要让模型编

增强版

加 Elasticsearch 关键词检索
向量检索和关键词检索并行，再做 RRF 融合
加 Rerank，把最相关的证据排到前面
加元数据过滤，比如部门、版本、权限、文档类型
加问题改写，处理“刚才那个配置怎么改”这种追问
加评估集，用 Hit@K、MRR、答案忠实度去评估效果
做增量更新，文档变更后能重新解析和重建索引

想做得更有辨识度，可以参考这两个设计

核心架构设计：三层执行器、前置编排、混合检索、证据预算。
图数据库与知识路由：用 Neo4j 做文档结构图谱，用 Scope → Topic → Document 做知识路由。

RAG 项目到底能不能讲出深度，其实就是看你有没有处理这些细节。通过这些细节，面试官很快就能判断你到底是不是就跑了个玩具而已。

第四步：要让 Agent 既会说还会做

Agent 项目不能只停留在聊天，还要能真正做事。

做事的基础就是工具调用。比如用户问“帮我查一下这个订单为什么没发货”，模型不能只靠猜，它得去调用订单系统、库存系统、物流系统，拿到真实结果后再组织语言。

这里要搞清楚一个知识点：模型本身不执行工具。

模型负责判断：

要不要调用工具
调哪个工具
参数怎么填

真正执行工具的是你的后端程序。它拿到模型给出的 tool_call，去调用数据库、接口、搜索服务、文件系统，再把结果返回给模型。

这里有一个很重要的后端涉及的原则：权限一定不能交给模型判断。

模型可以决定“我需要查订单”，但能不能查、查哪个租户、查哪些字段、能不能执行退款或发券，必须由后端鉴权来控制。模型传来的参数也不能直接信任，仍然要做参数校验、权限过滤、敏感字段脱敏和审计日志。

项目 4：工具型 Agent

选择做一个“运维助手”或者“订单助手”都可以的。

基础要求

至少注册 3 个工具，比如查询订单、查询物流、查询用户信息
工具参数做强校验
工具执行前做权限校验，不相信模型传来的租户、用户和权限信息
工具执行加超时控制
工具失败后返回模型可理解的错误，不要直接抛异常
模型根据工具结果生成自然语言回答

进阶要求

加一个 MCP Server，把某类工具独立出去
接入 MCP Client，启动时自动发现工具
对高风险工具加人工确认，比如退款、发券、发邮件
记录每次工具调用的参数、耗时、结果、异常
限制单轮对话最大工具调用次数，防止 Agent 死循环
给写操作做幂等设计，避免模型重复调用造成重复扣款、重复发短信

第五步：要让 Agent 可控地完成多步任务

生产环境要的是可完成、可解释、可回滚、可限制。能用确定性流程解决的，就不要交给模型自由发挥。

你要掌握几类 Agent 思路

ReAct：边推理、边行动、边观察结果
Plan-and-Execute：先规划，再按步骤执行
Reflection：执行后自查并修正
Workflow / Graph / Loop：用工作流和图结构控制执行路径
Multi-Agent：多个 Agent 分工协作
Human-in-the-Loop：高风险节点让人确认
Memory：短期记忆、长期记忆、摘要压缩、容量治理

我把每个方式的特点列举出来，帮助大家更好的理解：

任务特点	更适合的方式	原因
流程固定，比如报销审核、工单流转	Workflow	路径清楚，稳定性优先
有少量分支，比如问题分类、知识库路由	规则路由 + LLM 辅助判断	成本低，可控性强
信息不完整，需要边查边判断	ReAct	每一步都能根据观察结果调整
任务很长，需要先拆步骤	Plan-and-Execute	先规划，再逐步执行
高风险动作，比如退款、发券、发邮件	Human-in-the-Loop	模型不能越过审批
跨领域协作，比如检索、分析、执行、审核	Multi-Agent 或多节点 Workflow	拆职责，但要控制复杂度

如果把 Agent 只理解成“一个 while 循环里不断调用模型”，很容易就失控了。更工程化的方式，是把任务拆成一张执行图：

LLM 节点：负责判断、生成、总结
Tool 节点：负责查数据、调接口
Router 节点：负责分流
Human 节点：负责人工审批
Memory 节点：负责读写上下文
Evaluator 节点：负责检查质量

这就是执行引擎和工作流要解决的问题。

项目 5：可控 Agent 执行器

你可以做一个简化版执行器

输入用户目标
先让模型生成最多 5 步计划
每一步只能选择白名单工具
每次工具调用后记录 observation
如果连续两次失败，停止并返回原因
如果要执行写操作，进入人工确认
每轮限制最大模型调用次数和工具调用次数
执行状态落库，服务重启后能恢复
每一步输出 Trace，能看到计划、工具、Observation、最终回答
支持暂停、继续和取消，不要只依赖内存里的循环

这里的重点不是让它完全自主执行，而是让它在你能控制的范围内完成任务。

你可以在面试里这么讲

我的 Agent 没有把全部控制权交给模型。外层执行器负责状态流转、工具白名单、调用次数限制、超时和持久化；模型只负责在有限上下文里做下一步决策。这样既保留了灵活性，也能避免死循环和高风险误操作。

第六步：如何从 Demo 到真正的生产级别

AI 应用上线后，最容易翻车的地方其实是边缘防护和工程治理没做好。

常见翻车的问题

同步调用模型，接口卡 30 秒，线程池被拖死
在事务里调用 LLM，数据库连接一直占着
没有限流，用户脚本刷接口，Token 账单炸了
没有降级，模型供应商一抖动，全站 500
没有观测，用户说回答错了，你不知道错在哪一步
没有评估集，每次改 Prompt 都靠感觉
没有审计，工具调用到底改了什么查不清

这部分建议认真看系统设计文档

总体架构：从 Demo 到生产的 AI 应用架构设计
大模型网关：大模型网关的设计与落地
API 工程：大模型 API 调用的工程化实践
语音 Agent：AI 语音 Agent 技术架构解析
系统设计速查：系统设计与工程化面试速查

生产级 AI 应用至少要拥有这些能力：

问题	后端处理方式
响应慢	SSE / WebFlux / 异步任务
模型超时	超时控制、重试、备用模型、友好降级
成本不可控	Token 统计、预算阈值、用户限流、语义缓存
输出不稳定	结构化输出、JSON Schema、校验、有限修复
Agent 死循环	模型调用次数限制、工具调用次数限制、状态机中断
RAG 答错	检索 Trace、证据评分、引用来源、评估集
数据泄露	PII 脱敏、权限过滤、审计日志、私有模型
集群重复处理	分布式锁、租约续期、幂等任务

这五层能力都横跨 Agent 的路由、RAG、工具、模型和输出链路。单独给某个节点加一条日志或一个超时还不够，治理信息要能够按同一个请求 ID 串联，才能在出错时完成发现、定位、隔离、恢复和复盘。

这部分其实是属于传统后端要考虑的问题。之前学的 Redis、MQ、限流、熔断、分布式锁、日志、监控、事务边界，这里就需要用起来了。

生产级 Agent 要考虑的 5 个方面

第一，可观测性。你要知道模型为什么这么答。

传统接口出问题，看日志、Trace、指标。Agent 更需要这些，因为中间多了模型决策、RAG 召回、工具调用、上下文拼装。至少要记录：

用户输入和会话 ID
触发的路由和执行节点
使用的模型、参数和 Prompt 版本
RAG 检索结果、分数、引用来源
工具调用名称、参数摘要、耗时、结果、异常
Token 消耗、费用估算、总耗时
最终输出和用户反馈

第二，成本控制。Token 就是钱。

一个用户问题可能触发意图识别、问题改写、RAG 检索、重排、工具调用、最终生成、输出审核。每一步都可能花钱、花时间。

常见优化手段有：

简单任务用小模型
高频相似问题走语义缓存
RAG 片段控制数量和长度
工具结果先摘要再喂给模型
对话历史做滑动窗口或滚动摘要
对高成本能力设置用户、租户、场景配额
按模型、业务线、用户统计 Token 和费用

第三，安全。Agent 能调工具以后，风险会突然变大。

只聊天时，最多是说错话；能调工具后，可能查错数据、发错消息、改错状态。生产里要有几条原则：

高风险操作必须人工确认
写操作要幂等
工具参数必须校验
权限必须在后端判断
Prompt Injection 要防
RAG 文档要做权限过滤
工具返回的敏感字段要脱敏
审计日志要完整

第四，测试。AI 应用也要回归。

不要觉得模型输出不稳定就没法测。可以测的东西很多：

输出格式是否符合 Schema
意图分类是否正确
工具是否选对
RAG 是否命中标准文档
低置信度是否拒答
越权请求是否拦截
Prompt Injection 是否失败
延迟和成本是否在阈值内

第五，发布与运行治理。上线不是把接口部署完就结束。

模型、Prompt、Embedding、切片策略和工具描述任意一项变化，都可能让线上效果发生漂移。发布时要保留模型与 Prompt 版本，先灰度小流量，再观察成功率、延迟、Token 成本、工具失败率和 RAG 评估指标。发现异常时，系统应能回滚配置、切换备用模型、暂停高风险工具，并保留问题请求的完整 Trace 供复盘。

生产底线

模型输出永远只是候选结果。权限、金额、租户、幂等、事务和审计必须由确定性的后端逻辑兜底；任何无法追踪、无法中断、无法回滚的 Agent，都不适合直接承担高风险写操作。

第七步：学一个完整项目，把知识串联起来

学 AI Agent 最怕碎片化。今天看 Prompt，明天看 RAG，后天看 MCP，每个都懂一点，但不知道它们在一个系统里怎么配合。

所以一定要做一个完整项目。

我开发的超级 AI 智能体项目，就很适合作为主线来学。它不是只展示“调用模型”，而是把很多生产级问题放在一个系统里处理：多层执行器、RAG 前置编排、混合检索、文档处理流水线、会话记忆、Neo4j 图数据库、知识路由、Agent 安全机制、全链路可观测和简历表达。

入口可以按这个顺序看：

项目介绍：项目介绍与核心价值
架构设计：核心架构设计
工程化：工程化技术概括
图数据库和知识路由：图数据库与知识路由
文档目录：文档和视频目录
简历参考：项目简历模板参考

这个项目里有几块内容特别适合后端同学重点看

三层执行器体系：不是所有问题都让 Agent 自己解决，而是歧义追问、知识问答、开放式 Agent 分场景处理。
RAG 前置编排：先做路由、改写、子问题拆分、知识域收缩，再进入检索。
双通道混合检索：PGVector 做语义，Elasticsearch 做关键词，RRF 融合，可选 Rerank。
证据预算和无证据短路：上下文窗口有限，证据要裁剪；没证据就别让模型编。
会话记忆策略：无记忆、滑动窗口、摘要压缩，不同场景不同取舍。
MCP 和 Skills：一个偏协议，一个偏能力包，都是扩展 Agent 能力边界的办法。
Neo4j 文档结构图谱：处理章节定位、邻接查询、结构化导航。
全链路观测：每次回答能看到编排、检索、工具、模型、Token、费用。
集群安全：Redis 租约、JVM 任务注册、租约续期，防止重复执行。

时间怎么安排

学习周期	核心目标	最终交付物	验收重点
30 天	建立 Agent 系统全局认识	一套能讲清楚的架构方案与项目话术	能沿请求链路解释模型、RAG、工具和工程治理
60 天	做出完整的业务闭环	企业知识库 + 订单工具助手	能运行、能引用、能追踪工具调用、具备基础评估
90 天	补齐生产级治理	网关、评估、成本、审计、灰度与回滚能力	能观测、能限流、能降级、能控制高风险操作