交互式学习指南 · 10 章完整体系 · 2026

AI 架构 深度指南

从提示词工程到 Agent 系统,从 RAG 到 MCP。通过交互式演示,直观掌握现代 AI 应用的每一个关键概念。

开始学习 ↓
学习路径
十个章节,从基础到实战
每个章节包含交互式演示,帮你建立直觉而非死记概念。点击任意卡片跳转。
01

AI 能力图谱

LLM / RAG / Agent / Fine-tuning 的关系全景

入门
02

提示词工程

Prompt 设计、Few-shot、Chain-of-Thought

入门
03

上下文工程

窗口管理、信息密度、长上下文策略

入门
04

RAG 核心原理

查→拼→答 + 幻觉问题与缓解

中级
05

RAG 优化策略

Chunking、HyDE、Re-ranking

中级
06

RAG 进阶

Self-RAG & CRAG 自适应架构

高级
07

Agent 核心原理

四大组件 + 运行循环 + Guardrails

高级
08

Agent 设计模式

ReAct、Plan-and-Execute、Multi-Agent

高级
09

MCP 工具协议

Model Context Protocol — Agent 的 USB 接口

高级
10

技术栈与实战

RAG + Agent + MCP 统一选型与部署

高级
第一章

AI 能力图谱

点击下方节点,跳转到对应章节深入学习
LLM 大语言模型 核心引擎 · 理解与生成 提示词工程 Prompt · Few-shot · CoT 上下文工程 窗口管理 · 信息密度 Fine-tuning 能力内化 · 领域适配 信息增强 RAG 检索增强生成 查→拼→答 · 减少幻觉 行动赋能 Agent 智能体 自主规划 · 工具调用 能力模块 工具接入 MCP 工具协议 标准化接口 · 生态互联 Guardrails 减少幻觉
关系总结:LLM 是核心引擎;提示词工程和上下文工程是"驾驶技术";Fine-tuning 是"改装引擎";RAG 是给它一本随时查阅的百科全书;Agent 是给它手和脚让它自己干活;MCP 是让 Agent 能插上任何工具的标准接口。它们不是互斥关系,而是层层递进的增强。
第二章

提示词工程

Prompt Engineering — 与 AI 高效沟通的底层技能

为什么提示词重要

同一个 LLM,不同的提示词可以让输出质量天差地别。提示词工程不是"奇技淫巧",而是理解模型如何处理输入、如何生成输出的系统方法论。它是所有 AI 应用(RAG、Agent)的底层基础。

核心技巧

角色设定(System Prompt)

通过定义模型的身份、专业背景和行为准则,大幅提升输出的专业度和一致性。

❌ 没有角色设定

用户:解释一下什么是 TCP 三次握手
AI:TCP 三次握手是一种网络协议...(泛泛而谈)

✅ 有角色设定

系统:你是一位有 15 年经验的网络工程师,擅长用类比解释复杂概念。
AI:想象你和朋友打电话——你先拨号说"喂"(SYN),对方接起说"喂,听到了"(SYN-ACK),你确认"好,我们开始聊"(ACK)...

Few-shot 示例学习

在提示词中给出几个输入→输出的示例,让模型"照着做"。比口头描述格式要求有效得多。

任务:将产品评价分类为正面/负面/中性

示例 1:"这个手机太棒了!" → 正面
示例 2:"电池续航太差了" → 负面
示例 3:"还行吧,中规中矩" → 中性

请分类:"物流很快但包装有点破损" → ?
关键:示例要覆盖边界情况,2-5 个示例通常足够。示例的质量比数量更重要。

Chain-of-Thought 思维链

让模型"一步步思考"再给出答案,显著提升复杂推理任务的准确率。

直接回答

Q:小明有 5 个苹果,给了小红 2 个,又买了 3 个,吃了 1 个,还剩几个?
A:5个 ❌

CoT 逐步推理

让我一步步想:
1) 开始:5 个
2) 给小红 2 个:5-2=3
3) 买了 3 个:3+3=6
4) 吃了 1 个:6-1=5 个

触发方式:在提示词末尾加 "Let's think step by step" 或 "请逐步推理"。

结构化输出

要求模型以 JSON、XML 或特定格式输出,方便下游系统解析。在 RAG 和 Agent 系统中尤其关键。

// Prompt 指令
请分析以下文本的情感,以 JSON 格式返回:
{
  "sentiment": "positive/negative/neutral",
  "confidence": 0.0-1.0,
  "keywords": ["关键词列表"]
}
进阶:现代 LLM(如 Claude)支持 tool_use / function calling,可以直接定义输出的 JSON Schema,比在 prompt 里描述格式更可靠。

提示词的六层结构

角色身份
任务描述
上下文/示例
约束条件
输出格式
兜底指令

不是每次都需要六层齐全,但复杂任务中层次越完整,输出越可控。兜底指令如"如果不确定请说明"可以有效减少幻觉。

第三章

上下文工程

Context Engineering — 管理模型的"工作记忆"

什么是上下文工程

如果说提示词工程关注的是"说什么",上下文工程关注的是"在什么背景下说"。它是一门系统性地管理送入模型的所有信息的学问——包括系统提示、对话历史、外部知识、工具结果等。Andrej Karpathy 提出这个概念,认为它比单纯的提示词工程更重要。

上下文窗口的构成
System Prompt — 角色、规则、工具定义 ~5-15%
长期记忆 / 用户画像 ~5%
RAG 检索结果 — 外部知识 ~20-40%
对话历史 — 多轮上下文 ~20-30%
工具返回结果 — API / 搜索 ~10-20%
当前用户输入 ~5%
← 上下文窗口总容量(如 Claude: 200K tokens, GPT-4: 128K tokens)→

核心原则

🎯

信息密度最大化

每个 token 都很宝贵。去除冗余、压缩对话历史、只注入最相关的检索结果。质量 > 数量。

📐

位置感知

模型对开头和结尾的信息关注度最高("Lost in the Middle" 现象)。把最重要的信息放在头尾。

🔄

动态管理

对话变长时要主动裁剪旧消息、摘要化历史、只保留关键上下文。避免窗口溢出。

🧩

分层组织

System Prompt 定全局规则,RAG 结果提供事实,对话历史提供连续性——每层各司其职。

上下文 vs 提示词

提示词工程

关注"怎么说"——措辞、格式、技巧。
像写一封好邮件。

上下文工程

关注"带什么信息"——选择、组织、裁剪。
像准备一场会议的全部材料。

关键洞察:大多数 AI 应用的效果瓶颈不在模型能力,而在上下文质量。把正确的信息、以正确的格式、在正确的时机送给模型——这就是上下文工程的全部。RAG 本质上就是一种自动化的上下文工程。
第四章

RAG 核心原理

Retrieval-Augmented Generation — 查→拼→答

大模型的两个痛点

大语言模型存在两个根本局限:知识截止(训练数据有时间限制)和幻觉(可能自信地编造答案)。RAG 正是为了解决这两个问题而设计的。

交互演示:RAG 工作流程
用户提问
「公司最新的退货政策是什么?」
⚠ 普通大模型的回答
抱歉,我的训练数据截止到 2024 年,无法获取最新退货政策。我可能会给出过时或编造的答案……
系统通过语义相似度从知识库中匹配最相关的文档:
📄 员工手册 v3.2
📄 2026 退货政策 — 0.94
📄 产品目录 Q1
📄 客服 FAQ — 0.87
📄 财务报表
用户问题
+
检索文档
增强 Prompt
系统指令:根据参考资料回答,不确定请说明。
参考资料:[文档1] 30天无理由退货… [文档2] 退货运费规则…
用户问题:公司最新的退货政策是什么?
根据最新 2026 退货政策:自收货起 30天内 可无理由退货;电子产品需原包装;运费规则:质量问题公司承担,否则消费者承担。
📎 来源:2025退货政策、客服FAQ

幻觉问题与缓解

幻觉(Hallucination)是 LLM 生成看似合理但实际错误的信息。RAG 通过提供真实参考资料来约束模型,但并不能完全消除幻觉。

幻觉的三种类型

事实性幻觉 — 编造不存在的事实(如虚构的论文引用)。
忠实性幻觉 — 回答与提供的参考资料不符,模型"无视"了检索结果。
推理性幻觉 — 前提正确但推理链条出错,得出错误结论。

缓解策略

RAG 基础层:提供真实参考文档,要求模型基于文档回答。
Prompt 约束:加入"如果资料中没有相关信息,请说明"等兜底指令。
引用追溯:要求模型标注引用来源,方便人工验证。
Self-RAG/CRAG:让模型自我检查生成内容是否有依据(详见第六章)。
温度控制:降低 temperature 减少随机性,让输出更保守准确。
一句话总结:RAG 的核心思路就是三个字——查→拼→答。先从外部知识源中检索相关内容,再把它们塞进 Prompt,最后让模型基于真实材料回答。
第五章

RAG 优化策略

检索前 · 检索中 · 检索后 — Chunking、HyDE、Re-ranking

检索前是在"备好弹药"——构建高质量的向量空间。

Chunking 文档分块

文档太长会稀释语义,太短会丢失上下文。常见策略:固定长度切分、语义切分、递归切分、结构切分。通常加 10-25% 的重叠(overlap)保持上下文连续性。经验法则:客服 FAQ 用 chunk=128/overlap=10%,法律合同用 256/20%,技术文档用 400/15%,学术论文用 200/25%。

Embedding 模型选择

Embedding 决定语义空间质量。需考虑维度大小、多语言支持、领域适配。开源首选 BGE-M3;商用首选 OpenAI text-embedding-3 或 Cohere embed-v3。

Metadata enrichment 元数据增强

给每个 chunk 附加来源、日期、类别等元数据,检索时先过滤再向量匹配,缩小搜索范围。

检索中是在"打得更准"。

Hybrid search 混合检索

向量搜索擅长语义("退货"≈"退换货"),BM25 擅长精确关键词(SKU-1234)。两者结合用 RRF 融合排序效果最好。
向量检索
+
BM25
RRF 融合

HyDE 假设文档嵌入

让 LLM 先"假设性回答"问题,再用假设答案的向量去检索。因为假设文档和真实文档在向量空间中更相似,"文档 vs 文档"匹配比"短 query vs 长文档"更精确。类比:拿一段书的描述去图书馆找书,比拿书名找更准。

优点:零训练、即插即用、跨语言好。缺点:多一次 LLM 调用,对精确查询无优势。

Query transformation 查询改写

Query expansion:LLM 生成同义改写和子问题,多路召回合并。
Step-back prompting:把具体问题抽象为更宽泛的问题,检索更全面的上下文。

检索后是在"精选精炼"。

Re-ranking 重排序

初次检索用轻量 bi-encoder(快但粗),Re-ranker 用 cross-encoder 对 query+文档精细打分(慢但准)。先粗筛 Top-20,精排出 Top-5。常用:Cohere Rerank、bge-reranker-v2。

Context compression 上下文压缩

检索到的 chunk 中可能只有一两句话真正相关。压缩器抽取关键句子,减少 token 数量,降低成本且提升精度。

Chunking 交互演示

Chunk 大小150
Overlap %15%

不同场景的 Chunking 推荐

客服 FAQ

问答对简短独立。chunk=128, overlap=10%
小 chunk · 低重叠

法律合同

条款间有上下文依赖。chunk=256, overlap=20%
中 chunk · 中重叠

技术文档

代码示例和解释跨段落。chunk=400, overlap=15%
大 chunk

学术论文

论点层层递进。chunk=200, overlap=25%
高重叠

HyDE 假设文档嵌入详解

HyDE(Hypothetical Document Embeddings)的核心洞察:用户的问题和知识库文档"长得不像",但 LLM 生成的假设回答和知识库文档"长得很像"。

HyDE 四步工作流

1. 用户提问

"量子计算对密码学有什么影响?"——短 query,信息量有限。

2. LLM 生成假设性文档

"量子计算机利用 Shor 算法可以在多项式时间内分解大整数,这将使 RSA 和 ECC 面临威胁。后量子密码学正在研究基于格的密码……"
⚠ 可能不准确,但我们只需要它的"语义方向"

3. 用假设文档的向量去检索

假设文档和真实文档形态相似——都是长段落、专业术语密集。"文档 vs 文档"匹配更精确。

4. 丢弃假设文档,用真实文档生成回答

假设文档只是"指南针"——不需要自己是目的地,只需指对方向。最终回答基于检索到的真实文档。

HyDE 适合

探索性问题、概念性查询、跨语言检索、用户提问模糊宽泛的场景(研究助手、学术搜索)

HyDE 不适合

精确查找(订单号、SKU)、低延迟要求(实时客服)、LLM 对领域完全陌生的冷启动场景

经验法则:overlap 设在 chunk 的 10-25%。低于 10% 丢失边界上下文,高于 25% 存储膨胀收益递减。从 15% 开始实验。
第六章

RAG 进阶

Self-RAG & CRAG — 从固定流水线到自适应检索

核心机制:4 种反思 Token

Retrieve需要检索吗? IsRel相关吗? IsSup有依据吗? IsUse有用吗?

接收问题 → 判断是否检索

模型输出 Retrieve=yes/no,如果 no 则直接用自身知识回答。

并行生成 + 三维评分

对每个检索文档并行生成候选回答,同时输出 IsRel / IsSup / IsUse。

选择最优候选

综合评分用 beam search 选最高分候选。分数都低可重新检索。

训练方法详解

第 1 步:构建带反思标注的训练数据 — 用 GPT-4 等教师模型对现有指令跟随数据集做标注。给教师模型看 (问题, 文档, 回答),让它生成四种反思 token 的值。大约标注 15-20K 条数据。

第 2 步:扩展词汇表 + 微调 — 把反思 token(每种有 2-5 个可能值)作为特殊 token 加入词汇表。在标注数据上对 Llama 等基座做全量 SFT。模型学会在生成中"夹带"反思 token,既是内心独白也是控制信号。

第 3 步:推理时的可控性 — 可通过调整反思 token 权重控制行为:想要更多引用提高 IsSup 权重;想减少延迟调低 Retrieve=yes 阈值。这种可控性是 Self-RAG 区别于普通 RAG 的一大优势。

核心机制:检索评估器 + 三条路径

常规检索

和普通 RAG 一样先检索 Top-K。

评估器打分 → 分三档

T5-large 微调的评估器对每个结果打分。

Correct → 精炼后使用

高度相关,知识精炼器提取关键信息。

Incorrect → 丢弃 + Web Search

不相关,触发网络搜索兜底。

Ambiguous → 两路合并

保留两路结果合并送入 LLM。

训练与集成

检索评估器:基于 T5-large 微调二分类/三分类模型。训练数据从 QA 数据集(Natural Questions、TriviaQA)取 (问题, 文档) 对,用 GPT-4 标注 correct/incorrect/ambiguous。也可用启发式规则:文档包含标准答案的标为 correct。几千到一万条数据即可。

知识精炼器:不需要单独训练。将每个文档分解成细粒度"知识条"(knowledge strips),让评估器逐条打分,只保留高分条目。相当于自动做上下文压缩,显著减少噪声。

与 LLM 集成:CRAG 是即插即用的中间层,不修改 LLM。任何 RAG 系统都可以在检索和生成之间插入 CRAG 模块——这是 CRAG 相比 Self-RAG 的最大实用优势。

Self-RAG vs CRAG 对比

维度Self-RAGCRAG
核心思路模型内化反思能力外挂质检中间层
是否改 LLM是,全量 SFT否,LLM 不动
决策粒度token 级别query 级别
纠错方式并行候选 + 评分web search 兜底
适用场景高质量要求(研究)快速集成生产系统
简单记忆:Self-RAG 改"大脑",CRAG 改"流水线"。前者上限高成本也高,后者务实易落地。两者可组合使用。
第七章

Agent 核心原理

从被动应答到自主行动 — LLM + 感知 + 工具 + 自主决策循环

四大组成部分

🧠

大脑 — LLM

核心引擎,负责理解、推理和决策。

🔧

工具 — Tools

搜索、数据库、API、代码执行器。LLM 做不到的事通过工具完成。

📋

规划 — Planning

拆解复杂任务为子步骤,制定和调整执行计划。

💾

记忆 — Memory

短期(当前对话)+ 长期(持久化存储),积累经验。

运行循环

1
感知 Perceive

接收用户指令或环境输入,理解目标。

2
思考 Reason

LLM 分析情况,决定下一步。可用 CoT 或规划模块。

3
行动 Act

调用工具执行操作:搜索、运行代码、调 API 等。

4
观察 Observe

接收工具结果,评估是否达成目标。

5
判断 Decide

完成→输出。未完成→回到步骤 2。出错→调整策略。

↻ 循环直到任务达成或达到最大迭代

实时模拟:旅行规划 Agent

点击按钮观察 Agent 的"思考→工具调用→观察→再思考"循环:

Guardrails 安全护栏

Agent 能执行真实操作(发邮件、修改数据库、调用付款 API),因此安全护栏至关重要。

权限控制

明确定义 Agent 可以调用哪些工具、不能调用哪些。敏感操作(删除数据、发送邮件、付款)必须设置人工审批节点(human-in-the-loop)。实现最小权限原则。

输入/输出过滤

检测并拦截 prompt injection 攻击(恶意用户试图劫持 Agent)。对 Agent 的输出做内容安全审查,防止生成有害内容。可用专门的 guardrail 模型或规则引擎。

循环与成本限制

设置最大迭代次数(防止无限循环)、token 预算上限、超时机制。记录每次工具调用的日志用于审计。LLM 的不确定性会在多步中累积——每步 95% 准确率,10 步后只剩 60%。
核心原则:Agent 的自主性越高,护栏就要越严。先保证安全可控,再追求能力边界。

Agent vs 普通 LLM

普通 LLM

  • 输入 prompt → 输出文本
  • 单轮交互,无状态
  • 不能调用外部工具
  • 需要人类逐步指挥

像一个博学的顾问

Agent

  • 接收目标 → 自主完成
  • 多轮循环,有记忆
  • 能调用各种工具和 API
  • 自主规划和执行

像一个能干的全能助手

Agent vs RAG vs Fine-tuning

RAG

给模型"查字典"的能力。解决知识更新和幻觉问题。是一种信息增强策略。

Fine-tuning

改造模型的"大脑结构"。让模型学会新技能或适配领域。是一种能力内化策略。

Agent

给模型"手和脚"。让模型能规划和执行真实任务。是一种行动赋能策略。

它们不是互斥的:一个强大的 AI 系统往往三者兼备——Fine-tuning 让模型更懂领域,RAG 让它查最新资料,Agent 让它自主完成任务。Agent 是最外层的"骨架",RAG 和 Fine-tuning 是它的"内功"。

Agent 框架生态

通用框架

LangGraph / CrewAI

LangGraph 基于图的状态机,灵活度最高;CrewAI 专注多智能体协作,上手快。

代码智能体

Claude Code / Cursor

专注代码生成和编辑的 Agent,能读取项目、编写测试、修复 bug。

工具协议

MCP

Anthropic 提出的开放标准,统一接入各种外部工具和数据源。

研究框架

AutoGen / DSPy

AutoGen 多 Agent 对话框架;DSPy 声明式 AI 编程框架。

构建 Agent 的关键挑战

可靠性

LLM 的不确定性会在多步中累积放大。每步 95% 准确率,10 步后只剩 60%。需要充分的错误处理和回退机制。

成本控制

每次任务可能调用数十次 LLM,成本远高于单次问答。需合理设置最大迭代次数和 token 预算。

安全与权限

能执行真实操作(发邮件、改数据库),必须有明确的权限边界和人工审批节点。

可观测性

多步推理的黑箱问题。需要完善的日志、trace、中间状态可视化才能调试和优化。

第八章

Agent 设计模式

五种主流架构,各有适用场景

ReAct — 推理与行动交替

最经典的 Agent 模式,来自 2022 年的同名论文。模型交替进行 Thought(推理当前状态)和 Action(调用工具),每次行动后观察结果再推理。Prompt 格式通常是:Thought: 我需要查一下… → Action: search("xxx") → Observation: 搜索结果… → Thought: 根据结果…
Thought
Action
Observation
Thought
Answer
优:简单直观,推理过程完全可解释,易于调试。缺:严格串行执行,无法并行多个子任务,复杂任务效率低。
适用:问答系统、简单的工具调用场景、需要透明推理过程的任务。

Plan-and-Execute — 规划与执行分离

先用一个 Planner LLM 制定完整计划(步骤列表),再用一个 Executor Agent 逐步执行。关键改进:执行过程中如果发现计划有问题(某步失败或获得新信息),可以回到 Planner 重新规划(re-planning)。
Planner
Step 1
Step 2
Re-plan?
Done
优:全局视角好,适合复杂多步任务,Planner 可以用更强的模型而 Executor 用更便宜的。缺:初始规划可能基于不完整信息,需要良好的 re-planning 机制。
典型框架:LangGraph 的 Plan-and-Execute 模板、BabyAGI。

Multi-Agent — 多智能体协作

多个专精 Agent 各司其职,通过消息传递协作。核心思想是"分工产生专业性"——比如软件开发场景中,一个 Agent 负责写代码、一个负责代码审查、一个负责测试、一个负责项目管理。
Orchestrator
Coder
Reviewer
Tester
优:专业分工提高质量,可并行执行,易于扩展新角色。缺:Agent 间协调复杂,消息传递成本高,调试困难("谁说了什么导致了这个结果?")。
典型框架:AutoGen(微软)、CrewAI、ChatDev。

Reflexion — 自我反思

Agent 执行任务后,用另一个 LLM 调用(或同一个)对结果进行反思和评估,生成改进建议,然后带着反思记忆重试。类似于"做完作业自己检查一遍,发现问题再改"。反思记忆会持续积累,让 Agent 在后续尝试中避免重复犯错。
Execute
Evaluate
Reflect
Retry (improved)
优:能从失败中学习,质量逐轮提升,适合需要迭代优化的任务(如代码生成、写作)。缺:多轮调用成本高,可能过度反思陷入死循环。
适用:代码题、数学推理、需要逐步完善的创作任务。

Tool-Use Agent — 工具增强型

专注于工具调用的 Agent 模式。LLM 根据任务选择合适的工具、构造参数、解析返回结果。现代 LLM 的 function calling / tool_use 能力让这种模式越来越成熟和可靠。

核心能力链:工具发现(知道有哪些工具可用)→ 工具选择(判断哪个工具最合适)→ 参数构造(生成正确的调用参数)→ 结果解析(理解返回值并决定下一步)。

典型应用:Claude 的 computer use 和 MCP 集成、GPT 的 code interpreter、各种 API 调用场景。MCP 的出现让这种模式的工具接入成本大幅降低。
选型建议:从 ReAct 单 Agent 开始,先确保单步可靠。复杂任务用 Plan-and-Execute。需要专业分工时才上 Multi-Agent。一个做好 3 件事的 Agent 比声称能做 30 件事但不靠谱的更有价值。
第九章

MCP 工具协议

Model Context Protocol — Agent 的 "USB 接口"

什么是 MCP

MCP(Model Context Protocol)是 Anthropic 提出的开放标准,它为 AI 模型连接外部数据源和工具定义了一套统一的协议。类比:在 USB 标准出现之前,每个外设都需要专用接口;MCP 就是 AI 世界的 USB——一个标准协议,让任何 Agent 能接入任何工具。

❌ 没有 MCP

每接入一个工具都要写定制代码。N 个模型 × M 个工具 = N×M 种集成。维护噩梦。

✅ 有 MCP

所有工具实现统一的 MCP Server 接口。N 个模型 + M 个工具 = N+M 种集成。即插即用。

三层架构

Host 宿主
Client 客户端
Server 服务端
外部资源

Host(宿主应用)

用户直接交互的应用,如 Claude Desktop、IDE 插件、自定义 AI 应用。它发起需求,管理多个 Client 连接。类比:你的电脑本身。

Client(MCP 客户端)

在 Host 内部运行,负责与特定 Server 建立一对一连接。维护协议通信、能力协商。类比:电脑上的 USB 控制器。每个 Client 对接一个 Server。

Server(MCP 服务端)

对外暴露工具、资源和提示模板。每个 Server 连接特定的外部系统(数据库、API、文件系统等)。类比:USB 设备(鼠标、键盘、硬盘)。

Server 提供三种能力:
Tools — 可执行的操作(查询数据库、发邮件)
Resources — 可读取的数据(文件内容、API 响应)
Prompts — 预定义的提示模板

MCP vs 传统 API 集成

维度传统 API 集成MCP
集成方式每个工具单独写适配代码统一协议,即插即用
发现机制手动配置工具列表Server 自动声明能力
双向通信通常只有请求-响应支持双向实时通信
安全模型各自实现统一的权限和认证框架
可组合性低,互相独立高,多个 Server 自由组合

主流 MCP Server 生态

开发工具

GitHub / GitLab

代码仓库管理、PR 审查、Issue 跟踪

数据存储

PostgreSQL / Redis

数据库查询、缓存操作

办公协作

Slack / Gmail / Calendar

消息发送、邮件管理、日程安排

云服务

AWS / GCP / Cloudflare

云资源管理、部署、监控

知识管理

Notion / Confluence

文档读写、知识库检索

浏览器

Puppeteer / Browserbase

网页浏览、截图、数据抓取

关键洞察:MCP 的价值不仅是技术标准化,更是生态效应。当越来越多的工具实现 MCP Server,Agent 的能力边界就自动扩展——不需要为每个新工具写代码。这就是为什么说 MCP 是 Agent 生态的基础设施。
第十章

技术栈与实战

RAG + Agent + MCP 统一选型与部署建议

核心组件选型

向量数据库

Milvus / Qdrant / Pinecone

Milvus 开源高性能;Qdrant Rust 实现快;Pinecone 全托管。小规模用 Chroma 或 pgvector。

Embedding

BGE / E5 / OpenAI

开源首选 BGE-M3(多语言);商用首选 OpenAI text-embedding-3。

编排框架

LangChain / LlamaIndex

LangChain 生态大;LlamaIndex 专注 RAG;LangGraph 做 Agent 状态机。

Re-ranking

Cohere / BGE-Reranker

商用首选 Cohere Rerank API;开源用 bge-reranker-v2。

LLM

Claude / GPT-4 / 开源

商用首选 Claude 或 GPT-4o;开源用 Llama 3、Qwen 2.5。

Agent 框架

LangGraph / CrewAI

LangGraph 灵活度最高;CrewAI 多智能体协作上手快。

MCP SDK

官方 TypeScript / Python SDK

快速构建自定义 MCP Server,接入任何内部工具。

评估工具

Ragas / TruLens / Phoenix

RAG 效果评估、Agent trace 分析、可观测性。

推荐架构

文档解析
Chunk + Embed
向量数据库
检索 + Re-rank
Agent 编排
MCP 工具层

分阶段实施

MVP(1-2 周)

Chroma + LangChain + OpenAI Embedding + Claude。固定 chunk,无 re-ranking。跑通端到端。

优化(2-4 周)

混合检索 + re-ranking + 语义 chunking + overlap 优化 + 元数据过滤。

Agent 化(4-8 周)

引入 Agent 循环 + MCP 工具接入 + query 改写 + CRAG 评估模块 + 用户反馈循环。

生产级(8+ 周)

生产向量库(Milvus/Qdrant)+ 权限控制 + Guardrails + 日志监控 + A/B 测试 + 自动化数据更新。

评估体系

检索质量

  • Recall@K — Top-K 包含正确文档的比例
  • MRR — 正确文档排名倒数均值
  • NDCG — 归一化折损累积增益

生成质量

  • Faithfulness — 回答是否忠于文档
  • Relevance — 回答是否切题
  • Groundedness — 是否有依据
最重要的建议:不要试图一步到位。先用最简单的方案跑通,再用真实查询找瓶颈,有针对性地优化。RAG 效果 80% 取决于数据质量和 chunking 策略,而非框架选型。Agent 的核心挑战是可靠性,先确保每一步都可控。