万字深度解析 Agent 学习路线

随着 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 调用的工程化实践这块学完以后就要开始做一个小项目了哪怕简陋点也是没有关系的。项目 1AI Chat Gateway最小可交付版本提供/chat普通接口和/chat/streamSSE 流式接口支持配置切换模型供应商记录每次调用的输入 Token、输出 Token、耗时、模型名给模型调用加超时、重试、降级提示前端能看到打字机效果可以再进阶一点加一个模型网关层业务代码不直接依赖具体模型 SDK加 Redis 缓存相似问题结果加限流防止某个用户刷爆 Token加统一错误码不要把模型报错原样甩给前端增加模型调用审计表记录请求来源、模型、耗时、Token、失败原因把模型调用封装成内部 SDK 或 Starter别让每个业务都重复接一遍这时候你已经比“我会调 API”的人强一截了。面试官问你怎么做大模型接入你能聊出线程池、SSE、超时、降级、计费这就有点开始像后端项目的样子了棒棒的第二步要把 Prompt 当成业务规则而不只是一段字符串我发现很多人学 Prompt 的方式是收藏一堆“万能的提示词模板”。只能说有点用吧但不多。。。在真实项目里Prompt 更像业务规则。它会被产品修改、被运营调整、还要被安全要求约束还要版本管理。不能硬编码在 Java 字符串里。你需要掌握的是这些Prompt 的角色、任务、上下文、输出格式怎么拆Few-shot 什么场景值得加什么场景只会浪费 TokenCoT、反思、自一致性这些技巧怎么用在工程里怎么让模型稳定输出 JSON 或结构化对象用户输入怎么隔离防 Prompt InjectionPrompt 怎么外置、版本化、灰度和评估上下文工程怎么把规则、记忆、RAG、工具结果拼在一起如果你把这块做得要像样一点通常会是下面的这个结构系统提示词负责边界和风格。任务提示词负责当前目标。用户输入单独包起来避免和规则混在一起。RAG 证据、工具返回、历史记忆按优先级拼装。输出格式明确到字段级最好有 JSON Schema。最后再做校验、修复和回退。图里的上下两条线需要一起看上面是一次请求怎样从业务进入模型下面是版本、Token、延迟、成本和审计怎样贯穿整个调用过程。这样设计以后业务代码只依赖统一网关和结构化契约不需要跟某一家模型 SDK 绑死。推荐阅读入门提示词入门与核心概念设计原则提示词设计原则与实战技巧结构化框架结构化提示词框架与模板高阶策略高阶提示词优化策略Spring AI 实践提示词工程实践指南结构化输出结构化输出深度剖析上下文工程上下文工程实战指南RAG 场景 PromptRAG 场景提示词工程实战要注意 Prompt 不是越长越好信息密度才重要。你给模型塞一堆废话它并不会更聪明只会更贵、更慢甚至容易忽略真正有用的信息。项目 2Prompt 配置中心你可以先做一个简单版把系统提示词、任务提示词、输出格式模板拆开存储支持变量注入比如{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 解析顺序乱正文、页眉、页脚混在一起表格丢失导致关键信息没进知识库图片里的文字没有 OCRMarkdown 标题层级被打平代码块、配置块被切碎文档版本、部门、权限、发布时间没有记录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 必须有评估和更新机制上线后肯定会遇到这些问题用户说搜不到、答案引用错、文档更新了但知识库没更新、同一个问题今天答对明天答错。所以至少要准备一批评估问题并且看这些指标检索层HitK、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把最相关的证据排到前面加元数据过滤比如部门、版本、权限、文档类型加问题改写处理“刚才那个配置怎么改”这种追问加评估集用 HitK、MRR、答案忠实度去评估效果做增量更新文档变更后能重新解析和重建索引想做得更有辨识度可以参考这两个设计核心架构设计三层执行器、前置编排、混合检索、证据预算。图数据库与知识路由用 Neo4j 做文档结构图谱用 Scope → Topic → Document 做知识路由。RAG 项目到底能不能讲出深度其实就是看你有没有处理这些细节。通过这些细节面试官很快就能判断你到底是不是就跑了个玩具而已。第四步要让 Agent 既会说还会做Agent 项目不能只停留在聊天还要能真正做事。做事的基础就是工具调用。比如用户问“帮我查一下这个订单为什么没发货”模型不能只靠猜它得去调用订单系统、库存系统、物流系统拿到真实结果后再组织语言。这里要搞清楚一个知识点模型本身不执行工具。模型负责判断要不要调用工具调哪个工具参数怎么填真正执行工具的是你的后端程序。它拿到模型给出的 tool_call去调用数据库、接口、搜索服务、文件系统再把结果返回给模型。这里有一个很重要的后端涉及的原则权限一定不能交给模型判断。模型可以决定“我需要查订单”但能不能查、查哪个租户、查哪些字段、能不能执行退款或发券必须由后端鉴权来控制。模型传来的参数也不能直接信任仍然要做参数校验、权限过滤、敏感字段脱敏和审计日志。推荐阅读工具调用认知认识工具调用机制Spring AI 实战Spring AI 工具调用实战源码链路ToolCallback 源码解析工具设计工具设计原则与最佳实践可靠性从结构化输出到可靠的工具调用工具设计里最容易被忽略的是“给模型看的接口说明”。人类开发者能看懂queryData模型不一定能选对。工具名、描述、参数名、参数约束、返回格式都要清楚。一个模型更容易用好的工具通常有这些特点名称具体比如queryOrderDeliveryStatus比handle好描述写人话告诉模型什么时候该用、什么时候不该用参数尽量少枚举值尽量精简不暴露内部字段比如 token、requestId、operatorId返回值结构化但不要塞一堆无关的字段错误信息要能指导模型下一步比如“订单号格式错误”比“系统异常”更有用一个简陋的工具tool: handle description: 处理业务 params: data一个真正能用的工具tool: query_order_delivery_status description: 根据订单号查询订单当前发货状态、物流单号和异常原因。只用于用户询问订单发货、物流、配送异常的场景。 params: orderNo: string必填订单号长度 16-32工具越多就越需要标准化。Function Calling 适合在单个应用里快速接工具但企业里工具会分散在 HR、财务、CRM、文档、工单等不同系统里每个团队语言和部署方式还不一样。MCP 要解决的就是工具标准化接入问题。你可以把 MCP Server 理解成一类能力服务负责暴露工具、资源和提示Agent 侧通过 MCP Client 发现并调用这些能力。继续看MCP 入门揭开 MCP 协议的面纱技术关系MCP 与相关技术的关系通信机制深入 MCP 通信机制传输模式三种传输模式全面解读服务端Spring AI 构建 MCP 服务端实战客户端Spring AI 的 MCP 客户端开发指南企业实践MCP 企业级开发进阶技巧再往后可以了解 Skills。它和 MCP 不一样MCP 更像“工具能力怎么按协议接入”Skills 更像“Agent 在做某类任务时按需要打开的一份操作手册”。当 Agent 能力多了把所有规则都塞进 Prompt 里那上下文窗口很容易就满了。而 Skills 的思路是渐进加载先让 Agent 知道有哪些技能需要时再打开详细说明、参考资料和脚本。Skills 入门智能体为什么需要技能包目录结构Skills 目录结构全景图配置文件SKILL.md 核心配置深度剖析渐进加载四层渐进式加载机制揭秘Reference / ScriptReference 和 Script 实战指南Codex 管理使用 Codex 安装和管理 Skills这三个概念解决的是不同层面的问题Tool Calling规定模型怎样表达一次工具调用MCP负责把分散的外部能力标准化接进来Skills则把完成某类任务的方法、参考资料和脚本按需交给 Agent。无论入口来自哪里鉴权、参数校验、幂等和审计仍然必须由业务执行层负责。项目 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 节点负责检查质量这就是执行引擎和工作流要解决的问题。推荐阅读Agent 入门走进智能体的世界架构对比主流架构深度对比多智能体多智能体深度协作框架上手框架实战快速上手进阶特性Agent 进阶特性与源码探秘HarnessHarness 工程化实战工作流AI 工作流与执行引擎任务拆分复杂任务的分解之道框架取舍手搓 Agent 还是用框架规划能力如何赋予 Agent 规划能力多 Agent 路由多 Agent 协作与动态路由记忆架构Agent 记忆系统架构设计记忆存储记忆存储的工程实践记忆压缩记忆压缩与容量治理我个人更推荐后端同学先走“编排型 Agent”。也就是外层用确定性代码控制流程里面少量环节让模型决策。比如超级智能体项目的设计就很值得借鉴不是所有问题都扔给 Agent而是先做会话记忆加载、意图分析、问题改写、知识路由、歧义判断再决定走知识问答还是开放式 Agent。记忆系统也要早点理解。短期记忆解决当前会话上下文长期记忆记录用户偏好和历史摘要实体记忆保存结构化事实程序记忆沉淀可复用流程。但记忆不是越多越好还要考虑摘要压缩、容量治理、隐私和删除机制。多 Agent 不要过早的用。当一个 Agent 搞不定时可以拆路由 Agent、检索 Agent、分析 Agent、执行 Agent、审核 Agent但多 Agent 会带来通信、状态、成本、调试复杂度。很多业务用一个 Workflow 加几个工具节点就够了。项目 5可控 Agent 执行器你可以做一个简化版执行器输入用户目标先让模型生成最多 5 步计划每一步只能选择白名单工具每次工具调用后记录 observation如果连续两次失败停止并返回原因如果要执行写操作进入人工确认每轮限制最大模型调用次数和工具调用次数执行状态落库服务重启后能恢复每一步输出 Trace能看到计划、工具、Observation、最终回答支持暂停、继续和取消不要只依赖内存里的循环这里的重点不是让它完全自主执行而是让它在你能控制的范围内完成任务。你可以在面试里这么讲我的 Agent 没有把全部控制权交给模型。外层执行器负责状态流转、工具白名单、调用次数限制、超时和持久化模型只负责在有限上下文里做下一步决策。这样既保留了灵活性也能避免死循环和高风险误操作。第六步如何从 Demo 到真正的生产级别AI 应用上线后最容易翻车的地方其实是边缘防护和工程治理没做好。常见翻车的问题同步调用模型接口卡 30 秒线程池被拖死在事务里调用 LLM数据库连接一直占着没有限流用户脚本刷接口Token 账单炸了没有降级模型供应商一抖动全站 500没有观测用户说回答错了你不知道错在哪一步没有评估集每次改 Prompt 都靠感觉没有审计工具调用到底改了什么查不清这部分建议认真看系统设计文档总体架构从 Demo 到生产的 AI 应用架构设计大模型网关大模型网关的设计与落地API 工程大模型 API 调用的工程化实践语音 AgentAI 语音 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 天补齐生产级治理网关、评估、成本、审计、灰度与回滚能力能观测、能限流、能降级、能控制高风险操作时间安排的判断标准天数只是参考真正的进度看可验证产物接口是否跑通、引用能否回溯、失败能否定位、写操作是否受控、项目能否被清楚讲出来。某一阶段没有形成交付物就先不要急着堆下一个框架。30 天目标是能面试、能讲清项目第 1 周大模型核心概念Spring AI 快速入门流式输出Prompt 基础和结构化输出第 2 周RAG 基础文档切片Embedding向量数据库混合检索和重排第 3 周Tool CallingMCP 基础Agent 架构ReAct / Plan-and-Execute记忆系统第 4 周系统设计LLM 网关RAG 评估Super Agent 架构整理项目话术30 天的时间确实比较紧张所以目标是能把“一个企业级 Agent 怎么设计”给讲清楚。60 天目标是做出一个完整项目前 30 天学核心知识后 30 天来做项目。项目建议做“企业知识库 订单工具助手”支持上传文档支持知识库问答支持订单查询工具支持 SSE 流式输出支持引用来源支持工具调用日志支持基础评估集60 天做完你就有一个实际能运行的项目了。90 天把项目完善到生产级别到了这个阶段更多的是要实现工程化的方面LLM 网关多模型切换Prompt 版本管理RAG 评估报表语义缓存知识库增量更新高风险工具人工确认Trace 和成本统计灰度策略学习切忌着急。先把 RAG、Tool Calling、MCP、Agent 执行器这些主干能力学清楚再根据项目暴露的问题补细节。面试怎么讲简历怎么写AI 项目不要成这样熟悉 RAG、Agent、MCP了解大模型应用开发。我见过很多小伙伴都是这么写的这样写面试官根本不知道你具体做的功能是什么。可以写成这样基于 Spring AI 实现企业知识库问答系统支持文档解析、语义分片、PGVector 向量检索、Elasticsearch 关键词检索、RRF 融合排序和引用溯源针对无证据场景做短路处理减少模型幻觉。或者设计工具型 Agent 执行器支持工具白名单、参数校验、超时重试、调用次数限制和执行状态持久化对高风险工具调用加入人工确认节点避免模型误操作。或者对大模型调用链路做工程化封装支持 SSE 流式输出、多模型路由、Token 统计、超时降级和结构化输出校验通过调用日志和 Trace 记录定位 Prompt、检索、工具调用问题。面试回答也一样。尽量按“问题 → 方案 → 权衡 → 结果”来回答。比如面试官问“你们的 RAG 怎么做的”可以这样说我们把 RAG 分成离线和在线两条链路。离线侧负责解析、清洗、分片、向量化和索引构建在线侧先做问题改写再并行走向量检索和关键词检索最后用融合排序和重排序筛证据。生成阶段要求模型基于证据回答没有证据就短路。这样做主要是为了同时解决语义召回、精确匹配和幻觉问题。你看这里面的每句话其实都能被追问也都能展开来回答这样给面试官的印象才会好。如果你想对照简历写法可以看Nexus Agent 项目简历模板参考。常见问题要不要学 Python可以学一点但别焦虑。后端同学学 Python不是为了特意换语言学习 Agent 项目而是为了看懂一些 AI 开源项目、评估工具和脚本。比如 RAGAS、LangChain、LlamaIndex 这些生态里有很多 Python 内容。你至少要能看懂示例、改脚本、跑评估。但主项目完全可以用 Java 做。尤其是企业内部系统Spring Boot、MySQL、Redis、MQ、ES 这些技术仍然是很常见的。Go 后端怎么学核心概念其实都一样的。LLM API、RAG、Tool Calling、MCP、Agent 执行器、可观测性这些不依赖语言。区别在生态。Java 有 Spring AI、LangChain4j、Spring AI AlibabaGo 生态成熟度稍弱但做 API 网关、工具服务、MCP Server、异步任务完全没问题。我的建议是如果你主栈是 Go不要为了学 AI 硬去切换 Java。要不要学微调要了解但不要一开始就学这个。多数业务场景先用 Prompt RAG 工具调用就能解决。微调适合更垂直、更稳定、更高频的任务比如特定格式的生成、行业术语风格、分类抽取。它并不是万能的。你可以先看大模型训练与微调技术全貌知道 LoRA、QLoRA、后训练这些概念什么时候该出现就可以。模型怎么选开发阶段先选便宜、好调、中文能力够用的模型。上线前再用更强模型做验证。架构上通过 OpenAI 兼容协议或模型网关隔离供应商别把业务代码写死在某一家 SDK 上。可以看主流模型选型指南 和 大模型网关的设计与落地。最终学习清单第一层模型基础Token、上下文窗口、采样参数、模型选择能解释模型为什么会幻觉、为什么会遗忘、为什么会不稳定第二层模型接入Spring AI / HTTP SDKSSE 流式输出结构化输出超时、重试、降级第三层Prompt 和上下文Prompt 模板化Few-shot / CoT / 反思上下文工程Token 预算Prompt Injection 防护第四层RAG文档解析分片策略Embedding向量数据库混合检索Rerank引用和幻觉治理评估与更新第五层工具和协议Function CallingTool CallingMCP Server / ClientSkills 能力包工具安全和审计第六层Agent 执行ReActPlan-and-ExecuteWorkflow / Graph / Loop记忆系统多 AgentHuman-in-the-Loop第七层工程化的设计AI 应用分层架构大模型网关限流熔断成本控制全链路观测数据安全集群并发控制第八层项目的证据AI 对话网关智能简历 / 面试助手企业知识库问答工具型 Agent超级 AI 智能体学到最后你应该能做到两个能力能交付自己搭建一个比较完善的 AI 应用能够运行、观测、评估和处理失败场景而不只是跑通一个小 Demo。能表达在面试里把每个技术点放回系统链路中讲清楚——它解决什么问题、为什么这样设计、做过哪些权衡、出了问题怎样排查。