0基础Agent开发课
从零开始掌握AI Agent开发全链路：Python基础、数学基础、LLM原理、RAG、Function Calling、MCP协议、Agent框架（LangChain/LangGraph）、模型微调、生产化部署，面向零基础学员设计。
课程目录
按顺序学习，每章结束后可以做对应测验
AI全景认知
AI全景认知导读
> 欢迎来到第1章。这是整门课最轻松的一章——没有代码，没有数学公式，只有概念和故事。
AI技术全景图-从传统ML到大模型
> **本文适合谁**：完全没有AI背景的读者。读完这篇，你会知道"AI/机器学习/深度学习/大模型"这几个词是什么关系，以及你将要学的东西在整个AI世界里处于什么位置。AI发展经历了三个时代——本文带你把这段历史串起来，从中理解为什么我们现在能用ChatGPT这样的工具。
深度学习核心概念-神经网络直觉理解
> **本文适合谁**：对"神经网络"这个词感到神秘的读者，以及想理解"为什么深度学习这么厉害"的零基础程序员。读完这篇，你会对神经网络是什么、为什么能学习、为什么叫"深度"、以及为什么AI需要GPU，有清晰的直觉理解——不需要看一行数学公式。
强化学习是什么-从游戏AI到Agent决策
> **本文适合谁**：对"强化学习"这个词好奇，但不知道它和ChatGPT、和Agent有什么关系的读者。读完这篇，你会明白：强化学习是如何从游戏AI一路演变到ChatGPT背后的训练技术，以及它为什么和你将要写的Agent系统有直接的逻辑联系。
核心名词解释-Token-RAG-Agent-MCP
> **本文适合谁**：刚接触AI开发、被各种术语搞晕的读者。读完这篇，你会对课程中反复出现的核心词有清晰的直觉理解，不再看到这些词就发懵。
加餐-AWS权威定义速查手册
> **本文适合谁**：读完第1章基础文章后，想要一份"官方版"定义对照表的读者。AWS（亚马逊云服务）是全球最大的云服务商之一，他们整理的 AI 概念定义准确、权威，适合作为参考。
Cursor-AI原生代码编辑器
> **时效说明**：本文内容以 2026 年 3 月为基准。Cursor 版本迭代极快，使用前建议查阅最新文档 `cursor.com/docs`。
Claude-Code-终端里的AI工程师
> **时效说明**：本文内容以 2026 年 3 月为基准，当前版本 v2.1.86。Claude Code 更新极快，使用前建议查阅最新文档 `code.claude.com/docs`。
Harness架构深度解析
> **[进阶选读]** 本篇深度解析 Claude Code 的底层架构设计。如果你的目标是快速上手用好 Claude Code，可以先跳过，等用顺手之后再回来读。读完之后，你对 CLAUDE.md、Hooks、MCP 的理解会上一个台阶——知道自己在调什么，而不只是知道怎么调。
Java转AI-Agent学习路线
> 适用对象：有 Java 开发经验，希望转型 AI Agent 开发方向的工程师
Harness 架构实战指南
Harness 不是 Agent 框架，也不是 RAG，它是一种**让 LLM 驱动复杂工作流、自动完成质量闭环**的工程架构模式。
AI全景认知 · 章节测验
完成本章测验，检测你对"AI全景认知"的掌握程度
Python基础
Python基础导读-AI开发者的Python地图
> **本章阅读时间**：约2.5小时（共15篇）
Python快速入门-零基础版
> **本文适合谁**：从来没写过 Python 的人。读完这篇，你能看懂 Python 代码，能写出可以运行的 AI 小程序，能继续学本章后面的内容。
Python包管理与项目结构-AI项目的工程化实践
> **本文适合谁**：想把 Python AI 项目管理得像 Java Maven 项目一样规范的工程师。读完本篇，你能建立一个依赖锁定、环境隔离、配置安全的 AI 项目骨架。
Python类型注解与运行时类型检查
> **本文适合谁**：熟悉 Java 强类型系统、想理解 Python 类型注解在 AI 项目中如何工作的工程师。读完本篇，你能用 Type Hints + pydantic 写出类型安全的 AI 应用代码。
Python装饰器与函数式编程-AI开发必备技能
> **本文适合谁**：理解 Java 注解（@Annotation）机制、想搞清楚 Python 装饰器如何工作的工程师。读完本篇，你能看懂 LangChain 的 `@tool`、FastAPI 的 `@app.get`、LangSmith 的 `@traceable` 背后的原理。
asyncio异步编程
> **本文适合谁**：有 Java 多线程或 CompletableFuture 经验、想理解 Python asyncio 的工程师。读完本篇，你能用 async/await 并发调用 LLM API，理解为什么不能在 async 函数里用同步库。
pydantic数据校验-AI开发的隐形利器
> **本文适合谁**：了解 Java Bean Validation（@NotNull、@Valid）的工程师，想理解 pydantic 如何在 AI 项目中工作的开发者。读完本篇，你能用 pydantic 处理 LLM 的结构化输出，不再被 KeyError 和 TypeError 困扰。
Python生成器与迭代器-内存高效的数据处理
> **本文适合谁**：了解 Java Iterator 或 Stream API 的工程师，想理解 Python 生成器如何处理流式 LLM 输出和大数据集的开发者。读完本篇，你能实现 LLM 流式输出处理，并构建内存高效的数据处理流水线。
Python上下文管理器与文件操作-资源安全管理
> **本文适合谁**：了解 Java try-with-resources 和 AutoCloseable 的工程师，想理解 Python `with` 语句和上下文管理器的工作原理。读完本篇，你能安全管理 AI 项目中的资源：HTTP 连接、临时文件、数据库连接。
Python日志与调试-AI应用的可观测基础
> **本文适合谁**：熟悉 Java log4j/SLF4J 的工程师，想建立 AI 应用可观测性的开发者。读完本篇，你能调试 LLM 的输入输出、记录 token 消耗、用结构化日志支撑生产环境问题排查。
pytest实战-如何测试AI应用
> **本文适合谁**：有 JUnit + Mockito 测试经验的 Java 工程师，想学习如何测试 AI 应用的开发者。读完本篇，你能用 pytest 测试包含 LLM 调用的 Agent，学会 mock LLM API，掌握 AI 应用测试的特殊策略。
Python并发模型-GIL-threading-multiprocessing-asyncio
> **本文适合谁**：有 Java 多线程（ThreadPoolExecutor、CompletableFuture）经验的工程师，想理解 Python 并发模型的开发者。读完本篇，你能为 AI 应用的不同场景选择正确的并发方案。
httpx与韧性设计-AI应用的HTTP客户端实践
> **本文适合谁**：有 Java OkHttp/RestTemplate/Resilience4j 使用经验的工程师，想构建生产级 LLM API 客户端的开发者。读完本篇，你能配置合理的超时、实现正确的重试策略，处理 LLM API 的限流场景。
pandas数据处理-AI项目的数据预处理实战
AI 项目中有一个规律几乎从不失效：70% 的时间花在数据上，30% 的时间花在模型上。无论是准备训练数据、预处理 RAG 文档、还是分析 LLM 输出日志，最终都要落到一张表格上：读取、清洗、过滤、统计、导出。pandas 就是做这件事的标准工具。
Python性能优化-从profiling到numpy向量化
Java 开发者第一次跑 Python 批处理任务，往往会被它的速度惊到——不是惊叹快，而是惊叹慢。处理 10 万条 Embedding 请求，Python 循环版本需要几分钟，而 numpy 向量化版本只需要几秒。这不是语言本身的天花板，而是使用方式的差异。
Java工程师转Python-AI开发跨越指南
> **定位**：本篇是专为 Java 工程师设计的思维转换指南，不讲 Python 语法，讲的是"用 Java 思维写 Python 会遇到什么坑、Java 的哪些经验可以直接复用"。
Python基础 · 章节测验
完成本章测验，检测你对"Python基础"的掌握程度
数学基础
数学基础导读
> **本章阅读时间**：约30分钟（共4篇）
线性代数直觉理解-向量矩阵与AI的关系
> **本文适合谁**：对线性代数完全陌生、或者曾经学过但早就忘光了的读者。不需要任何数学背景，只需要知道加法和乘法。目标是读完后能看懂"神经网络的本质是矩阵乘法"这句话的含义。
微积分与梯度下降-AI训练的数学引擎
> **本文适合谁**：完全不懂微积分的读者。目标不是让你会计算导数，而是让你理解"模型是怎么学习的"这件事背后的数学直觉。读完后你应该能明白：为什么学习率太大会让训练不稳定，为什么需要反向传播，以及`loss.backward()`这行代码在做什么。
概率论基础-贝叶斯思维与不确定性
> **本文适合谁**：对概率感到陌生的读者，或者觉得"概率跟AI有什么关系"的读者。读完后你将明白：为什么LLM每次输出不一样、Temperature参数是什么意思、LLM为什么会产生幻觉。这些问题的答案都在本文里。
优化理论入门-损失函数与梯度下降实战
> **本文的定位**：这是第3章数学基础的最后一篇，属于实战篇。把前面三篇学过的数学工具（线性代数的矩阵运算、微积分的梯度、概率论的损失函数）组合起来，看一个完整的训练过程是什么样的。同时深入理解过拟合问题——它是机器学习中最常见、最重要的挑战之一。
数学基础 · 章节测验
完成本章测验，检测你对"数学基础"的掌握程度
传统机器学习
传统机器学习导读
> **本章阅读时间**：约40分钟（共5篇）
监督学习入门-线性回归与分类
在深度学习和大模型出现之前，机器学习就已经在解决大量真实世界的问题了。这一篇的目标是让你真正理解监督学习的工作原理，而不仅仅是会调用API。
决策树与随机森林
> **本文适合谁**：了解基本编程、想知道"为什么神经网络之外还要学树模型"的读者。树模型在表格数据上至今仍是首选，理解它也是理解集成学习这一核心思想的最佳切入点。
模型评估与调参-避免过拟合
模型训练完了，怎么知道它好不好？怎么让它更好？这是被很多初学者轻视、但实际上极为关键的一步。
sklearn实战-鸢尾花分类与房价预测
两个完整项目，从数据加载到模型保存，把前面学过的所有概念串联起来。
传统ML与LLM的边界-什么时候用哪个
有了LLM，还需要传统ML吗？答案是：需要，而且经常需要组合使用。这篇文章给你一个清晰的决策框架。
传统机器学习 · 章节测验
完成本章测验，检测你对"传统机器学习"的掌握程度
深度学习基础
深度学习基础导读
> **本章阅读时间**：约1小时（共6篇）
神经网络基础-从感知机到多层网络
神经网络是深度学习的基石，也是所有大语言模型的底层结构。这篇文章从最简单的单个神经元出发，逐步建立起对神经网络工作原理的完整认知——不只是"怎么用"，更是"为什么这样设计"。
PyTorch入门-张量操作与自动求导
PyTorch是深度学习领域的标准工具。理解它的设计哲学，比会用它的API更重要。
CNN图像识别-卷积的直觉理解
> **本文适合谁**：理解了神经网络基础、想知道"计算机是怎么看懂图片的"的读者。不需要数学背景，重点是建立对卷积和层次化特征提取的直觉。
RNN与序列模型-从循环神经网络到LSTM
理解RNN，就理解了为什么Transformer要这样设计。这篇文章从"为什么"出发，带你彻底搞懂序列建模的进化史。
Transformer架构详解-从RNN到注意力机制
Transformer是所有大语言模型的基础架构。理解了它，就理解了ChatGPT和Claude在计算层面的工作原理。
深度学习与LLM的关系-你需要懂多少
学完本章，你对神经网络、Transformer、注意力机制有了基本认识。但你可能还有一个问题：这些知识我真的用得上吗？作为 Java 工程师转型做 AI 应用开发，我需要把深度学习钻研到什么程度？
深度学习基础 · 章节测验
完成本章测验，检测你对"深度学习基础"的掌握程度
LLM基础
LLM基础导读-理解语言模型的工作原理
> **本文适合谁**
大模型发展历程-从GPT-1到2026
> **本文适合谁**
从N-gram到Transformer-语言模型的进化史
> **本文适合谁**
LLM工作原理-Token与Transformer
> **本文适合谁**
Transformer自注意力机制-直觉理解不需要数学
> **本文适合谁**
分词器详解-Token才是LLM的基本单位
> **本文适合谁**
Temperature等核心参数详解
> **本文适合谁**
LLM的幻觉问题
> **本文适合谁**
主流模型对比-GPT-4o-Claude-DeepSeek怎么选
> **本文适合谁**
Embedding向量化原理-语义搜索的数学基础
> **本文适合谁**
LLM上下文窗口管理-长对话与长文档处理策略
> **本文适合谁**
LLM训练三阶段-预训练-SFT-RLHF
> **本文适合谁**
推理模型解析-o1和DeepSeek-R1的思考机制
> **本文适合谁**
LLM推理优化-KV-Cache量化与Flash-Attention
> **[进阶选读]** 本文适合想深入理解 LLM 内部机制的读者。KV Cache、量化和 Flash Attention 是 LLM 推理优化的三大技术，理解它们能帮你理解为什么不同模型的推理速度和成本差异如此之大。路径 A 的读者可以跳过。
采样策略详解-Greedy-BeamSearch-TopK-TopP
> **[进阶选读]** 本文适合想深入理解 LLM 内部机制的读者。理解贪心搜索、束搜索、Top-K、Top-P 的区别，才能在不同场景下做出正确的参数选择。路径 A 的读者可以跳过。
模型评估基准解读-MMLU-HumanEval-Chatbot-Arena
> **[进阶选读]** 本文适合想深入理解 LLM 内部机制的读者。看懂 AI benchmark 数据，才能从营销噱头中找到真实有用的模型选型信息。路径 A 的读者可以跳过。
位置编码与RoPE-LLM怎么知道词在哪个位置
> **[进阶选读]** 本文适合想深入理解 LLM 内部机制的读者。理解位置编码，能解释为什么现代 LLM 能支持超长上下文，以及上下文窗口扩展的工程原理。路径 A 的读者可以跳过。
残差连接与LayerNorm-深层网络稳定训练的秘密
> **[进阶选读]** 本文适合想深入理解 LLM 内部机制的读者。了解深层网络如何保持稳定训练的底层机制。路径 A 的读者可以跳过。
MoE混合专家架构-DeepSeek为什么又快又便宜
> **[进阶选读]** 本文适合想深入理解 LLM 内部机制的读者。理解 MoE 架构，能解释为什么 DeepSeek 能以极低成本实现高性能，以及未来大模型的架构趋势。路径 A 的读者可以跳过。
注意力机制的数学直觉-QKV矩阵在做什么
> **[进阶选读]** 本文适合想深入理解 LLM 内部机制的读者。深入理解 Q/K/V 矩阵计算的具体过程，适合想从数学角度理解自注意力的读者。路径 A 的读者可以跳过。
LLM基础 · 章节测验
完成本章测验，检测你对"LLM基础"的掌握程度
API入门与模型调用
API入门导读
> **本章阅读时间**：约25分钟（共5篇）
第一次调用大模型API-从零开始
理论读再多，不如跑一次代码。本篇的目标是让你在 30 分钟内完成第一次 LLM API 调用，拿到真实的模型响应，理解请求和响应的结构。
多轮对话的消息历史管理
LLM API 是**无状态的**（即每次调用都是全新的，服务器不保存上一次的对话内容）。每次调用都是独立的，模型不记得上一次你问了什么。要实现多轮对话，你需要自己管理消息历史，把完整的对话记录发给模型。
流式输出与SSE集成
等待 LLM 生成完整响应再显示，用户体验很差——特别是长文本需要等待 10-30 秒。流式输出（Streaming）让模型的回答逐 Token 出现，用户看到的是"打字机"效果，感知延迟从秒级降到毫秒级。
结构化输出与预填充技巧
LLM 的默认输出是自由文本。但在实际应用中，经常需要模型输出 JSON（一种常见的数据格式，用大括号和键值对组织数据，例如 `{"name": "张三", "age": 25}`）、特定格式的数据，或者以特定开头开始回答。这篇讲几种让模型输出可预测格式的技术：Prompt 约束、JSON 模式（response_format）、以及 pydantic 验证。
API密钥安全管理与环境配置
API 密钥（Key）是访问 LLM 服务的凭证，就像银行卡密码，泄露后果严重：攻击者可以用你的密钥消耗你的配额，产生大量费用，甚至访问你的账户数据。密钥安全管理是 AI 应用工程化的第一道防线。
API入门与模型调用 · 章节测验
完成本章测验，检测你对"API入门与模型调用"的掌握程度
Prompt工程
Prompt工程导读-与LLM有效沟通的艺术
> **本文适合谁**
Prompt-Engineering入门
> **本文适合谁**
Few-shot与CoT思维链
> **本文适合谁**
ReAct模式详解-Agent的行动逻辑
> **本文适合谁**
System-Prompt设计指南
> **本文适合谁**
结构化输出-让LLM返回可靠的JSON
> **本文适合谁**
Prompt安全与注入攻击防范
> **本文适合谁**
Prompt模板工程化管理-从硬编码到可维护
> **本文适合谁**
思维链进阶-Tree-of-Thoughts与Self-Consistency
> **本文适合谁**
角色扮演与人设设计-让Agent有稳定的行为风格
> **本文适合谁**
Prompt评估体系-从感觉优化到数据驱动
> **本文适合谁**
Prompt-Chaining-把复杂任务拆成流水线
> **本文适合谁**
长Prompt的结构化-XML标签与分节设计
> **本文适合谁**
多轮对话的Prompt管理-保持上下文一致性
> **本文适合谁**
Zero-shot与Few-shot选择指南-实际项目中如何决策
> **本文适合谁**
Prompt工程 · 章节测验
完成本章测验，检测你对"Prompt工程"的掌握程度
工具使用与Function-Calling
工具使用导读
> **本章阅读时间**：约25分钟（共3篇）
LangChain-Tools工具调用
上一篇（Function-Calling 详解）讲了工具调用的底层原理——JSON Schema 格式定义工具，LLM 返回工具调用请求，开发者代码执行后把结果放回消息历史。这套机制是正确的，但用起来有点繁琐：需要手写 JSON Schema，需要手动维护消息历史，需要手动分发和执行工具。
LangChain-OutputParser结构化输出解析
LLM 返回的永远是字符串。但程序要的是结构化数据——Python 的 dict（字典）、list（列表）、Pydantic 对象（带类型约束的数据类），可以直接操作、直接传给下游函数的东西。
Function-Calling详解-LLM与外部世界的接口
LLM 本身是一个纯文本的输入输出系统，无法执行代码、查数据库、调 API。Function Calling（函数调用，也叫工具调用 Tool Use）是连接 LLM 和外部世界的机制：LLM 决定"需要调用哪个工具、传什么参数"，开发者负责实际执行，然后把结果返回给 LLM。
工具使用与Function-Calling · 章节测验
完成本章测验，检测你对"工具使用与Function-Calling"的掌握程度
MCP协议
MCP协议导读
> **本章阅读时间**：约20分钟（共3篇）
MCP协议详解-工具调用的行业新标准
2024 年之前，AI 工具调用领域长期处于碎片化状态。
动手写第一个MCP-Server
理论够了，直接上手。本篇从零开始，实现一个完整的 MCP Server，然后在 Claude 桌面版中验证它工作。
MCP生态与常用Server实践
写 MCP Server 之前，先看看哪些已经有了——大部分常见场景都已经有人实现了，不用重复造轮子。
MCP协议 · 章节测验
完成本章测验，检测你对"MCP协议"的掌握程度
RAG与向量数据库
RAG导读-让LLM知道你的私有知识
> **本章阅读时间**：约2小时（共17篇）
RAG原理与实现-从零搭建企业知识库
**本文适合谁**：刚接触 RAG 的程序员，或者知道 RAG 是什么但没有亲手跑过完整流程的人。读完本文，你能理解 RAG 的底层逻辑，并跑通一个完整的企业知识问答系统。
文档分块策略-Chunking对RAG效果的决定性影响
**本文适合谁**：已经跑通了基础 RAG（第 01 篇），但发现检索结果不够好——要么返回的内容太冗杂，要么答案被莫名截断。这篇文章讲的就是问题出在哪里，以及怎么解决。
Embedding模型选型
**本文适合谁**：已经跑通基础 RAG，但发现中文场景下检索质量不够好，或者需要评估不同 Embedding 方案的成本和性能权衡的读者。
向量数据库选型-Chroma-Milvus-PGVector
**本文适合谁**：RAG 系统准备或已经上线，需要从原型阶段（Chroma）迁移到生产级向量存储的读者，或者想了解不同向量数据库适用场景的开发者。
RAG优化技术-混合检索与重排序
**本文适合谁**：基础 RAG 已上线，但发现对精确关键词（订单号、产品型号、人名）的查询效果不好，或者总体检索精度不够满意的读者。本篇是必读五篇中最重要的优化篇。
GraphRAG-基于知识图谱的RAG增强
> **[进阶选读]** 本篇适合已完成必读五篇（01-05）、希望解决**多跳推理**问题（如"A 公司的创始人和 B 公司的 CEO 有什么共同背景"）的读者。如果你的 RAG 系统主要用于单文档事实查询，可暂时跳过。
RAG生产架构-从原型到企业级系统
> **[进阶选读]** 本篇适合 RAG 原型已验证有效、准备推向生产环境的读者。涵盖并发处理、增量索引更新、语义缓存、监控与成本控制等工程化话题。
多路召回与融合排序-RAG检索质量提升
> **[进阶选读]** 本篇适合已掌握基础混合检索（第 05 篇）、想深入理解 RRF 融合算法原理、或者在生产环境中对检索质量有更高要求的读者。
RAG评估实战-用RAGAS量化检索与生成质量
> **[进阶选读]** 本篇适合 RAG 系统已上线、需要系统评估和量化优化效果的读者。RAGAS 是目前最主流的 RAG 评估框架，学完本篇能对你的 RAG 系统做定量分析，而不是凭感觉判断好坏。
Parent-Document-Retriever与多向量索引
> **[进阶选读]** 本篇深入讲解父子分块的内部机制和多向量索引技术。如果你在第 02 篇中理解了父子分块的概念并希望深入实现细节，或者遇到了"检索精准但上下文不足"的问题，请阅读本篇。
Self-RAG与CRAG-让RAG系统自我纠错
> **[进阶选读]** 本篇适合遇到以下问题的读者：检索出来的文档质量参差不齐，模型有时候会用不相关的内容编造答案。Self-RAG 和 CRAG 让系统能主动判断"这次检索结果是否可用"并在不够时自动纠正。需要有 LangGraph 基础。
HyDE与查询改写-从Query端提升RAG检索质量
> **[进阶选读]** 本篇适合已掌握基础 RAG 和混合检索、希望从"用户问题"端进一步提升检索质量的读者。HyDE（假设文档嵌入）和查询改写是两种不修改索引、只优化查询的技术，适合知识库不便频繁更新的场景。
文档预处理全攻略-OCR-PDF解析与表格提取
> **[进阶选读]** 本篇适合需要处理非纯文本文档（扫描版 PDF、含表格的 Word/PPT、带图片的手册）的读者。真实企业文档往往格式复杂，预处理质量直接决定 RAG 的上限。
HNSW深度解析-向量检索为什么这么快
> **[进阶选读]** 本篇适合对向量检索算法原理感兴趣、或者需要在大规模数据（千万级以上向量）场景下调优检索性能的读者。对于大多数业务开发者，了解结论（使用 HNSW 索引、调整 ef 参数）即可，不需要深入本篇的算法细节。
Agentic-RAG-让Agent自主决定何时检索什么
> **[进阶选读]** 本篇适合已掌握基础 RAG 和 LangGraph 基础、希望构建智能化 RAG 系统的读者。Agentic RAG 让 Agent 自主判断"这个问题需要检索吗"、"检索结果够用吗"、"需要多次检索吗"，是 RAG 走向智能化的关键一步。
多模态RAG-处理图片表格和混合文档
> **[进阶选读]** 本篇适合需要处理含有大量图表、产品图片或技术图纸的企业文档的读者。纯文本 RAG 无法处理图片里的信息，多模态 RAG 用视觉模型弥补这个盲区。
RAG安全与数据权限控制-多租户知识库设计
> **[进阶选读]** 本篇适合在企业内部部署多用户 RAG 系统的开发者，特别是需要解决"不同部门只能看各自文档"、"敏感文档不能泄露给普通员工"等数据隔离问题的场景。
RAG与向量数据库 · 章节测验
完成本章测验，检测你对"RAG与向量数据库"的掌握程度
Agent基础
Agent基础导读-从自动化脚本到自主智能体
> **本章阅读时间**：约2.5小时（共20篇）
什么是AI-Agent-从自动化脚本到自主智能体
在理解 Agent 是什么之前，先回到一个最根本的问题：为什么已有了自动化脚本、传统程序和简单 LLM，还需要 Agent？
AI智能体发展史-从符号主义到LLM驱动的Agent
*AI Agent 发展时间线 — 从1950年代符号主义到2023年 LLM Agent 元年的技术演进*
Agent三大范式-ReAct-Plan-and-Solve-Reflection
范式（Paradigm）是一种思维框架，它决定了 Agent 面对任务时的基本行为模式——先做什么、怎么决策、何时停止。
Plan-and-Solve范式-先规划再执行的Agent设计
本章深入讲解 Plan-and-Solve 范式的设计思想、完整代码实现，以及与 ReAct 的适用场景对比。
Reflection反思机制-让Agent自我迭代优化
本章介绍 Reflection 范式的核心思想、提示词设计要点、完整实现，以及成本收益的权衡分析。
Agent的记忆系统-短期记忆与长期记忆
LLM 有一个基本的物理限制：上下文窗口（Context Window）。模型在每次推理时只能"看到"有限数量的 token——GPT-4o 是 128k，Claude 是 200k，即便是最大的模型也有上限。
上下文工程-Context-Engineering比Prompt工程更重要
*Context Engineering 全景图 — Context Window 的六大组成部分及其管理策略*
Workflow-vs-Agent-什么时候用哪个
*Workflow vs Agent 对比 — 左侧为确定性Workflow特点，右侧为自主Agent特点，以及选择决策依据*
手写ReAct-Agent-用100行Python理解Agent核心循环
本章从零实现一个 ReAct Agent，不依赖任何框架。通过手写实现，可以清晰理解 Agent 循环的每一个环节，从而在使用 LangChain（一个用于构建 AI 应用的 Python 框架，封装了 LLM 调用、工具调用、链式执行等常用功能）等框架时，能准确判断问题出在哪里。
从零手写一个Agent框架-理解Agent的本质
本章不使用任何框架，从零编写一个能实际运行的 Agent——大约 120 行 Python，包含工具注册、LLM 调用、循环逻辑、错误处理。通过手写实现，可以清晰理解 LangChain（一个构建 LLM 应用的开源 Python 框架，封装了 Agent 循环、工具调用、链式执行等复杂逻辑）那个循环到底在干什么，以及框架封装了哪些工程问题。
Agent评估体系-怎么知道你的Agent够不够好
评估软件系统的质量，通常有清晰的方法：单元测试、集成测试、性能基准。这些方法的共同前提是：对于给定的输入，存在明确的"正确输出"，可以用程序自动验证。
PEAS模型与Agent设计框架
*PEAS 模型——Performance（性能度量）、Environment（环境）、Actuators（执行器）、Sensors（传感器）*
工具设计原则-让Agent能力边界清晰
工具是 Agent 能力的边界——Agent 能做什么，完全由它拥有哪些工具决定。一个设计不良的工具，后果可能比没有这个工具更糟：LLM 无法判断何时调用它，调用时参数错误，调用后得到的返回值无法理解，最终导致 Agent 陷入循环或给出错误答案。
多模态Agent-处理图片音频与文本的Agent
*多模态 Agent 架构——文本/图片/音频输入经多模态 LLM 统一处理，调用不同类型工具*
Tool-Retrieval-工具太多时Agent如何找到合适工具
*Tool Retrieval 流程——语义编码后向量匹配候选工具，LLM 精选最合适的一个*
Agent可观测性-用LangSmith追踪Agent思考过程
> LangSmith 是 LangChain 官方提供的 Agent 可观测性平台，可以可视化地记录和展示 Agent 每一步的思考过程、工具调用情况和 LLM 输入输出，帮助开发者调试和优化 Agent。
Human-in-the-Loop-何时让Agent暂停等待人工确认
*Human-in-the-Loop 决策流程——基于风险评估决定自动执行、请求澄清还是人工审批*
多Agent协作-Orchestrator-Worker与Supervisor模式
*两种多 Agent 模式对比——Orchestrator-Worker（集中控制）与 Supervisor 分层（层级管理）*
Agent长期运行-状态持久化与任务断点续跑
大多数 Agent 教程演示的是一次性任务：输入一个问题，Agent 思考几秒钟，返回答案，结束。这类任务的生命周期只有几秒到几分钟。
LLM应用调试指南-从print到系统化排查
LLM 应用的调试和传统代码调试有根本性的区别：传统代码的 bug 是确定性的，同样的输入必然产生同样的错误；LLM 应用的问题是概率性的，同样的 Prompt 可能 80% 的时候正常、20% 的时候出错，而且出错的方式还不一样。
Agent基础 · 章节测验
完成本章测验，检测你对"Agent基础"的掌握程度
LangGraph
LangGraph导读-有状态Agent的设计哲学
> **本章阅读时间**：约1.5小时（共12篇）
LangGraph入门-为什么Agent需要状态机
在构建多步骤 AI Agent 时，一个常见的挑战是流程控制：如何让 Agent 在执行过程中，能够根据中间结果做出不同的决策，而不是完全依赖 LLM 自行判断下一步做什么。
LangGraph-Conditional-Edge条件分支与循环控制
在构建搜索型 Agent 时，一个常见的需求是：如果搜索结果不够充分，就换个关键词再搜一次；如果内容足够了，就直接生成答案。
LangGraph-Human-in-the-loop人机协作设计
在构建生产级 Agent 时，一个核心问题是：哪些操作可以让 Agent 自动执行，哪些操作必须经过人工确认？
LangGraph-Subgraph子图与模块化设计
随着业务需求增长，LangGraph Agent 的节点数量会不断增加。当一个 Agent 拥有三十多个节点，所有节点堆在同一个 State 里，`build_graph()` 函数写了两百行，维护就变得很困难——每次改动都需要理解整张图的结构，生怕一条边写错了整个流程就乱了。
LangGraph-Persistence持久化与断点续跑
任何需要几分钟以上的 Agent 任务，如果不做持久化，都是在赌运气。服务器重启、容器 OOM、网络超时，任何意外都会让任务从头来过。生产环境没有"重跑"这个选项，或者说代价很高。
LangGraph-Stream流式输出与实时反馈
Agent 后端逻辑做得再好，如果没有实时反馈，用户感知到的就是"这个系统很慢、很卡"。用户发了一个问题，然后面对空白界面等了两分钟，没有任何进度提示，不知道程序是在跑还是卡住了——这是很多 Agent 应用的真实状态。
LangGraph-Multi-Agent多智能体协作架构
单个 Agent 的能力有天花板。当任务足够复杂、足够专业，或者足够长时，单 Agent 开始暴露它的结构性缺陷。Multi-Agent 架构（多智能体架构：多个 AI Agent 各司其职，协同完成单个 Agent 无法独立胜任的复杂任务）不是技术炫技，而是在特定场景下解决单 Agent 无法解决的问题的工程方案。
LangGraph错误处理与容错机制
生产环境中，Agent 的失败不是"如果"的问题，而是"什么时候"的问题。网络超时、LLM API 限流、工具调用返回异常数据、下游服务不可用——这些都是日常。没有容错机制的 Agent，在压测时会崩，在凌晨偶发流量高峰时会崩，在 OpenAI API 降级时会崩。
LangGraph实战-构建一个研究报告生成Agent
前几篇文章分别讲了状态机、条件分支、人机协作、子图、持久化、流式输出、Multi-Agent 和错误处理。本篇把这些知识综合起来，构建一个完整的实战项目：**研究报告生成 Agent**。
LangGraph-Send-API并行任务与MapReduce模式
*LangGraph Send API MapReduce 模式——dispatcher 分发任务，Workers 并行执行，Reducer 合并结果*
LangGraph高级状态设计-Reducer与状态分层
*LangGraph 三层状态设计——全局状态、节点私有状态、子图状态，以及三种 Reducer 合并策略*
LangGraph-Command-现代路由方式
*LangGraph Command 对比条件边——Command 对象将路由与状态更新合一，代码更简洁*
LangGraph · 章节测验
完成本章测验，检测你对"LangGraph"的掌握程度
LangChain
LangChain导读-AI应用开发的瑞士军刀
> **本章阅读时间**：约1小时（共10篇）
LangChain核心概念-LCEL链式调用
LangChain 的文档里有一段示例代码：
LangChain-Memory对话历史管理
LLM 没有记忆。每次调用都是独立的：接收一段文本，处理完，输出一段文本，然后这次调用就结束了。下次调用，它对上次发生了什么一无所知。没有状态，没有持久化，每次都是白板。
LangChain-Retriever检索器深度解析
RAG（检索增强生成）应用的标准构建流程是：文档切块、embedding（嵌入：把文本转成一串数字向量，相似内容的向量在数学上距离相近）、存向量库、用户问题来了做向量检索、把检索结果塞进 Prompt、让模型回答。这个流程跑通之后，效果通常还可以，但往往有 30% 的问题回答不好。
LangChain-Callback回调与链路追踪
LLM 应用在生产环境中有一个典型的可观测性（可观测性：能够通过日志、追踪等手段了解系统内部运行状态的能力）困境：传统服务出了问题，看日志、查 trace（调用链路记录），链路清清楚楚。LLM 应用中间多了好几个非确定性的步骤——System Prompt、RAG 检索、模型推理——出了问题不追踪链路，根本没法排查。
LangChain文档加载与处理-DocumentLoader全解
构建 RAG（检索增强生成）知识库的第一步是把各种格式的文档加载成统一的数据结构。这一步往往被低估——PDF 里的表格解析乱码、Word 文档的页眉页脚混入正文、网页 HTML 标签残留……这些问题如果不在加载阶段处理好，后续的分块、检索都会受到影响。
LangChain-TextSplitter文本分割策略详解
文档分块（chunking）是 RAG 系统里最容易被忽视、但对效果影响最大的环节之一。一个常见的误解是：换一个更好的 Embedding 模型可以解决检索效果差的问题。实际上，分块策略做得不好，再好的 Embedding 也无法弥补——把一段完整的解释劈成两半，或者把几千字的文档塞进一个 chunk，都会导致检索质量大幅下降。
LangChain-Agent完整实战-从工具定义到部署
前几章分别讲了 Tools、Memory、Retriever、Callback 等组件，本章把它们组合起来，构建一个完整的、生产可用的 Agent。目标是搭建一个能查天气、搜索新闻、执行数学计算的助手，并覆盖工具定义、错误处理、调试和部署的全流程。
LangChain-LCEL高级模式-分支降级与自定义Runnable
前几章介绍了 LCEL 的基本链式调用。实际生产环境中，链不是线性的——需要根据输入条件路由到不同分支，需要在主链失败时自动切换备用模型，需要注入自定义的 Python 逻辑。本章系统讲解 LCEL 的高级模式，让链具备生产级的健壮性。
LangSmith-LLM应用的全链路可观测性
一个 RAG 链给出了错误的回答，原因可能有十种：检索到的文档不相关、Prompt 指令被误解、模型在某个步骤幻觉、格式化出错……用 print 语句排查，要在代码里插入几十个断点，重跑十几次才能定位。这是 LLM 应用开发的特有痛点：传统的 logging 对文本输入输出有效，对"模型在哪一步开始偏离"无能为力。
LangChain-Text-to-SQL-让LLM直接查数据库
企业中大量有价值的数据存在关系型数据库里，但能写 SQL 的人远比有业务问题的人少。产品经理想知道"上周各地区的退款率是多少"，需要找数据分析师，等排期，写查询，出报告——整个链路可能要几天。Text-to-SQL 技术让 LLM 充当 SQL 翻译器，用户用自然语言提问，系统自动生成并执行 SQL，返回自然语言结果。
LangChain · 章节测验
完成本章测验，检测你对"LangChain"的掌握程度
框架与平台对比
框架对比导读-选择合适的工具
> **本章阅读时间**：约35分钟（共5篇）
LangChain-vs-LlamaIndex-vs-AutoGen-框架选型指南
进入 AI 应用开发领域，面对 LangChain、LlamaIndex、AutoGen、CrewAI、LangGraph 等众多框架名称，往往令人无从下手。搜索 RAG 教程，用的是 LlamaIndex；搜索 Agent，大多是 LangChain；搜索多 Agent 协作，AutoGen 和 CrewAI 交替出现；搜索复杂工作流，又有观点认为 LangGraph 才是正解。
Dify-Coze-n8n低代码Agent平台对比
在理解具体平台之前，先把握低代码 Agent 平台存在的根本逻辑。
Spring-AI入门-Java开发者的AI落地捷径
对于基于 Spring Boot 构建的系统，如果需要在现有服务中集成 AI 问答功能，通常面临两种方案的选择：
LlamaIndex深度使用-RAG专项框架指南
在知识库问答、企业文档检索等场景中，LlamaIndex 的设计粒度比 LangChain 更细。LangChain 的 RAG（检索增强生成：先从知识库检索相关文档，再让 LLM 基于这些文档回答问题）实现偏向快速拼装，LlamaIndex 则将整个数据流水线拆分成清晰的层次，每一层都有独立的接口可以替换和扩展。
AutoGen框架-微软的多Agent对话系统
AutoGen 是微软研究院推出的多 Agent 框架，其核心理念与 LangChain 或 LlamaIndex 都有本质区别：后两者的 Agent 是"工具调用循环"，而 AutoGen 的 Agent 是"通过对话协作完成任务"。
框架与平台对比 · 章节测验
完成本章测验，检测你对"框架与平台对比"的掌握程度
模型微调
模型微调导读
> **本章阅读时间**：约1小时（共5篇）
微调入门-什么时候需要Fine-tuning
System Prompt 写了几百个字，模型输出格式还是偶尔出错；few-shot 放了十几个示例，某种边界情况就是处理不好；换了最强的模型，客服语气依然不够准——到了这一步，才轮到微调登场。
LoRA原理与实战-用最少参数微调大模型
在讲 LoRA 的原理之前，先说它为什么重要。
QLoRA-在消费级GPU上微调LLM
LoRA 把微调 7B 模型的显存需求从 84GB 降到了约 16-24GB。这已经很好了，但还不够——RTX 3060（12GB）、RTX 3070（8GB）这类更便宜的消费级 GPU，还是装不下。
微调数据集准备与质量评估
*微调数据集准备完整流程 — 从原始数据到训练就绪*
微调效果评估与部署
微调完了，怎么知道效果好不好？怎么部署到生产？
模型微调 · 章节测验
完成本章测验，检测你对"模型微调"的掌握程度
MLOps与模型部署
MLOps导读
> **本章阅读时间**：约25分钟（共5篇）
MLFlow模型版本控制与实验管理
*MLFlow 四大核心组件架构——Tracking/Projects/Models/Registry 的关系与功能*
模型推理优化-量化剪枝与加速
训练好的模型如何在生产环境高效运行？
TorchServe与ONNX-模型部署框架
把训练好的模型变成可以调用的 API 服务。
vLLM生产部署-高性能LLM推理服务
Ollama 让本地跑大模型变得极其简单，但它的设计目标是开发者单机使用，不是高并发服务。当多个用户同时发请求时，Ollama 是串行处理的——一个请求跑完才处理下一个，QPS（Queries Per Second，每秒处理的请求数量）极低，根本撑不住生产流量。
本地部署LLM-用Ollama跑DeepSeek和Qwen
*Ollama 本地部署架构——用户→Ollama API→本地模型→GPU/CPU 推理的完整流程*
MLOps与模型部署 · 章节测验
完成本章测验，检测你对"MLOps与模型部署"的掌握程度
生产化部署
生产化部署导读-从Demo到生产的距离
> **本章阅读时间**：约2小时（共17篇）
FastAPI构建AI服务
RAG 系统调通之后，下一步是将其包装成服务，提供 HTTP 接口供前端调用或与其他系统集成。
流式输出SSE实现
LLM 生成文本的原理是一次生成一个 token（大概一个词或半个词），然后把 token 拼起来返回。
LangSmith与Langfuse-AI应用的可观测性
传统 Web 应用的监控日志包含足够的调试信息：HTTP 状态码、响应时间、报错堆栈。但对于 AI 应用，当用户反馈"回答质量很差，完全答非所问"时，HTTP 日志里只有 `200 OK`，响应时间 3.2 秒。服务正常在跑，没有报错，但问题到底出在哪一步？是向量检索没找到相关文档？是找到了但 Prompt 写得不好？还是 LLM 本身的问题？
RAG评估-用RAGAS量化你的知识库质量
RAG 系统有大量可调参数，每个参数都会影响最终效果：chunk size（文档切块大小）、overlap 大小（相邻块的重叠内容，防止信息在切割处丢失）、切分策略、top-k（每次检索返回最相关的前k个文档）、相似度阈值、embedding 模型、reranker（重排序器，对初次检索结果再次精排提升准确性）、Prompt、LLM 选择……这些参数的组合是指数级的，不可能全部手动试。
Token成本控制-生产环境的省钱指南
Token 成本是 AI 应用商业化的关键变量。在不控制 token 消耗的情况下，多个消耗来源叠加在一起，会产生远超预期的 API 费用：system prompt 写得又臭又长、对话历史没有截断、RAG 每次塞了过多文档、批处理任务用实时 API 跑……每一项单独看都觉得"没多少"，叠在一起就是巨额账单。
AI应用的错误处理与重试策略
LLM API 在生产环境中面临多种失败场景：限流、超时、连接失败等。不同类型的错误需要不同的处理策略——盲目重试不仅无效，还会浪费配额、加剧服务器压力。本章系统介绍 LLM API 的错误分类、重试策略、超时配置、降级方案和熔断机制。
Docker部署AI服务
AI 服务的环境依赖比普通 Web 服务复杂得多：Python 版本、CUDA 版本、langchain 及其数百个传递依赖，任何一项不一致都可能导致"本地能跑、服务器报错"的问题。Docker 通过把应用和它依赖的所有环境打包成一个镜像，从根本上消灭了这类环境差异问题。
AI应用的安全与权限控制
AI 应用存在一类典型的安全漏洞：对话历史存在 Redis 里，key 是 `chat_history:{session_id}`，而 `session_id` 由前端生成。攻击者通过枚举 session_id，能读到其他用户的对话记录。没有用户身份绑定，没有访问控制，数据完全暴露。
异步任务队列-Celery处理AI长任务
AI 应用与普通 Web 服务有一个根本性差异：响应时间。调用 GPT-4 生成一份报告可能需要 30 秒，跑一次 RAG 检索加推理可能需要 10-20 秒，批量处理文档可能需要几分钟。而 HTTP 协议默认超时通常是 30 秒，Nginx 默认是 60 秒，大量请求会直接超时失败。
Redis缓存策略-降低LLM调用成本
LLM API 调用是 AI 应用最主要的成本来源。GPT-4o 每百万输入 token 约 2.5 美元，一个中等规模的企业应用每天可能消耗数百万 token。更头疼的是，相当一部分调用是重复的：同样的问题被不同用户反复提问，同样的文档被反复 Embedding，同样的系统 prompt 每次都要计入 token 计数。
AI应用监控告警-生产环境的健康保障
普通 Web 服务的监控关注 HTTP 状态码、响应时间、QPS。AI 应用需要在此基础上监控一批特有指标：LLM API 的调用成功率、token 消耗趋势、Embedding 延迟、RAG 检索质量、以及 Agent 的工具调用失败率。这些指标和成本直接挂钩，也是定位问题的关键线索。
Kubernetes部署AI服务-从单机到集群
前一章介绍了用 Docker 打包 AI 服务。Docker 解决了"把应用和它的依赖打包在一起"的问题，但它解决不了更复杂的问题：流量高峰时如何自动增加实例？某个实例挂了如何自动恢复？多个服务之间如何发现对方？如何不停机更新模型？
AI应用灰度发布与AB测试-模型升级不停机
普通的 Web 服务发布，验收标准相对明确：接口响应时间在 200ms 以内，错误率低于 0.1%，就可以放量。AI 服务的验收标准复杂得多——新版本模型的代码一行没变，但它给用户的回答可能变好了，也可能在某些特定场景悄悄退化了。这种不确定性让 AI 服务的发布变成了一件需要精心设计的工程活动。
AI应用分层架构与扩展-从单机到企业级
一个 AI 应用从本地运行到支撑真实用户，不是简单地把代码搬上服务器。它面临的问题和传统 Web 应用有根本性的不同：LLM 调用平均需要 5-15 秒，每次调用花费真金白银，输出结果具有不确定性。这三个特点决定了 AI 应用的架构设计必须从一开始就考虑分层——不是为了炫耀复杂度，而是为了生存。
AI应用成本治理-从个人项目到组织级管控
第5篇《Token成本控制：生产环境的省钱指南》讲的是**怎么少花钱**——压缩对话历史、选小模型、开缓存。这些技术手段在个人项目里运转得很好：你自己写代码，自己知道每天大概花了多少，看一眼账单心里有数。
AI应用反馈闭环-从上线到持续改进
一个 AI 应用上线那天，是它质量最高的那天。
模型版本管理-AI应用的依赖升级策略
每个 Java 程序员都做过依赖升级：把 `spring-boot` 从 2.7.x 升到 3.x，跑一遍测试，修几个编译错误，发布。行为是确定的，测试能覆盖，风险是可量化的。
生产化部署 · 章节测验
完成本章测验，检测你对"生产化部署"的掌握程度
AI伦理与安全
AI伦理与安全导读
> **本章阅读时间**：约1小时（共4篇）
AI伦理核心原则-公平透明与隐私保护
在进入技术细节之前，先看几个真实案例。这些不是假设的风险，而是已经在现实中造成了伤害的问题。
AI安全攻防-对抗样本与模型防护
在进入技术细节之前，先看几个真实案例，理解为什么这些攻击是真实威胁：
AI合规实践-数据安全与行业规范
*AI 合规四大维度——数据安全/隐私保护/行业规范/审计追踪的核心要求*
Agent安全与对齐-生产环境的风险控制
*Agent 常见安全风险（左）与对应防护措施（右）的左右对比*
AI伦理与安全 · 章节测验
完成本章测验，检测你对"AI伦理与安全"的掌握程度
前沿方向
前沿方向导读-AI生态的快速演进
> **本章阅读时间**：约50分钟（共7篇）
Agentic-RAG-让Agent自主决策检索策略
> **时效说明**：本文内容以 2026 年 3 月为基准。
Multi-Agent多智能体协作
> **时效说明**：本文内容以 2026 年 3 月为基准。
A2A与ANP协议-多Agent时代的通信标准
> **时效说明**：本文内容以 2026 年 3 月为基准。A2A 协议由 Google 于 2025 年 4 月发布，ANP 协议处于早期阶段。
Computer-Use-Agent操控桌面的新范式
> **时效说明**：本文内容以 2026 年 3 月为基准。Computer Use 由 Anthropic 于 2024 年 10 月发布，截至 2026 年 3 月仍处于快速演进阶段，生产应用需谨慎评估。
CrewAI框架-角色协作式多Agent开发
> **时效说明**：本文内容以 2026 年 3 月为基准。CrewAI 是截至 2026 年 3 月最流行的角色协作式多 Agent 框架之一，API 持续演进，使用前建议查阅最新文档。
Claude-Code-Skills-可复用的AI工作流
> **时效说明**：本文内容以 2026 年 3 月为基准。Claude Code Skills 是 Claude Code 的扩展机制，功能仍在持续演进，使用前建议查阅最新文档。
OpenClaw-本地优先的个人AI助手平台
> **时效说明**：本文内容以 2026 年 3 月为基准。OpenClaw 几乎每天发布新版本（版本格式如 `2026.3.24`），功能演进极快，使用前建议查阅官方最新文档。
前沿方向 · 章节测验
完成本章测验，检测你对"前沿方向"的掌握程度
Claude-Code实战教程
Claude-Code实战教程导读
> **本章阅读时间**：约180分钟（共13篇，内容详尽）
Claude-Code是什么和为什么用它
> **时效说明**：本文内容以 2026 年 3 月为基准。
安装与登录
> **时效说明**：本文内容以 2026 年 3 月为基准。
国内API配置
> **时效说明**：本文内容以 2026 年 3 月为基准。
第一次使用
> **时效说明**：本文内容以 2026 年 3 月为基准。
工作原理
> **时效说明**：本文内容以 2026 年 3 月为基准。
三种交互模式
> **时效说明**：本文内容以 2026 年 3 月为基准。
CLAUDE.md项目说明书
> **时效说明**：本文内容以 2026 年 3 月为基准。
项目目录结构
> **时效说明**：本文内容以 2026 年 3 月为基准。
Hooks自动化钩子
> **时效说明**：本文内容以 2026 年 3 月为基准。
MCP连接外部工具
> **时效说明**：本文内容以 2026 年 3 月为基准。
Skills和子代理
> **时效说明**：本文内容以 2026 年 3 月为基准。
斜杠命令速查
> **时效说明**：本文内容以 2026 年 3 月为基准。
实用技巧总结
> **时效说明**：本文内容以 2026 年 3 月为基准。
Claude Code实战教程 · 章节测验
完成本章测验，检测你对"Claude Code实战教程"的掌握程度