检索增强生成 RAG 与 Language Agents 完全指南

引论：从生成到检索，从对话到行动

当你和 ChatGPT 聊到第 20 轮，发现它把上周和你讨论过的项目细节全忘了；当你问它"昨天 NeurIPS 接收名单出来了吗"，它老老实实回答"我的知识截止到 2024 年初"；当你让它"帮我把这个 GitHub repo 的 bug 修了并提个 PR"，它只能输出一段 Markdown 而无法真正 git push。这三个失败案例分别对应 LLM 的三大根本局限，也分别催生了本教材的三大主题：记忆（Memory）、检索（Retrieval）、行动（Action）。

0.1 LLM 三大根本局限

把 LLM 看成一个被冻结在某个时间点、被装进玻璃罐里、只会说话不会动手的"博学百科全书"，它的局限就一目了然：

0.2 两条增强路径：知识 vs 行动

面对三大局限，社区在 2020–2025 期间发展出两条平行但日益融合的路径：

路径 A — RAG：与其逼模型把整个维基百科压进权重，不如让它需要时再查。检索器（Retriever）负责"找资料"，生成器（Generator）负责"读资料、写答案"。这条路径解决了知识冻结和幻觉。

路径 B — Language Agents：与其只让模型"说话"，不如赋予它"动手"的能力——调用 API、读写文件、点击按钮、操作机器人。这条路径解决了无身体。

但 2024 年之后，两条路径开始融合：在现代 Agent 框架里，"检索（search/retrieval）"被建模为一种工具调用，RAG 不再是一个静态 pipeline，而是 Agent 自主选择"什么时候检索、检索什么、检索多少次"的过程。这就是 ReAct、Deep Research Agent、Perplexity Pro 等系统的共同范式。本教材的内在逻辑也正是这条融合线。

0.3 本教材的阅读地图

• RAG 优先（第 1 部分）：奠定"检索 + 生成"的工程基础，建立 BM25 → DPR → ColBERT → FID 的演进感。
• Agent 框架（第 2 部分）：先看全景再看细节，建立 Planning/Memory/Tools/Environment 四大支柱的心智地图。
• 三大支柱细化（第 3–5 部分）：分别深挖推理、记忆、工具。
• 应用与评估（第 6–7 部分）：从论文回到工程，看 Agent 真实落地的形态、数据、benchmark。
• 动手实战（第 8 部分）：100 行代码亲手写一个 Coding Agent，把所有抽象概念落到 Python 里。
• 对比与开放问题（第 9 部分）：把 RAG、Long Context、Fine-tune 三种方案放到同一张决策表上，并展望未来。

第一部分：问答系统与 RAG 的演进

本部分按"难度阶梯"展开：阅读理解（给定段落找答案）→ 开放域问答（给定语料库找答案）→ RAG（给定整个互联网生成答案）→ 工业级 RAG（带引用、抗幻觉、可审计）。每一步都对应一个工程组件的诞生：BERT 抽取器 → BM25/DPR 检索器 → 端到端联合训练 → FID 生成器 → 后验证（RARR）。理解这条历史线，对设计自己的 RAG 系统会少走很多弯路。

1.1 阅读理解：SQuAD 与 BERT QA

阅读理解（Reading Comprehension, RC）是 RAG 的"原子任务"：给定一段 passage 和一个 question，模型在 passage 中找出（或生成）answer。它是 RAG 中"Reader"组件的源头。

2016 年 Rajpurkar 等人发布的 SQuAD（Stanford Question Answering Dataset）让这个任务标准化：107,785 个问题，每个问题的答案保证是 passage 中的连续片段（span）。形式上：

1.1.1 特征工程时代（pre-2017）

BERT 之前，主流方法是候选生成 + 多类逻辑回归：

1. 枚举 passage 中所有可能的答案 span $(a_1, a_2, \dots, a_M)$；
2. 对每个 span 抽取特征 $\phi(p, q, a_i) \in \mathbb{R}^d$，特征包括：词重叠、bigram 匹配、句法依存路径长度、命名实体匹配、问句类型与答案类型的兼容性等；
3. 训练 softmax/logistic 分类器。

这些手工特征需要语言学家和 NLP 工程师联合设计，又脆弱又难迁移。

1.1.2 BERT QA 的优雅解法

BERT (Devlin et al., 2019) 把 RC 简化为预测两个位置：把 question 和 passage 拼接成 [CLS] Q [SEP] P [SEP]，对 passage 中每个 token 的最终隐状态 $T_i$，分别预测它作为答案 start 和 end 的概率：

推理时枚举所有 $(i, j)$ 满足 $i \le j \le i + L_{\max}$（防止答案过长），取 $P_{\text{start}}(i) \cdot P_{\text{end}}(j)$ 最大者。BERT-large 在 SQuAD 1.1 上达到 91.8 F1，超过人类标注者（91.2 F1）。

1.2 开放域问答：从给定段落到整个互联网

RC 的致命局限：passage 是给定的。但用户的真实问题往往是"华沙 1933 年讲波兰语的居民有多少？"——没人会贴心地把对应的维基百科段落附在问题旁边。开放域问答（Open-Domain QA, ODQA）把这个假设去掉了：

2017 年 Chen et al. 的 DrQA 是 ODQA 的里程碑：它把 ODQA 拆成两步——

这个简单的两阶段架构主导了后续 8 年的 RAG 研究。它的优雅在于关注点分离：检索器解决"在哪里"，读取器解决"是什么"。但它也埋下两颗地雷：

1. 误差级联：检索器召回失败 → 读取器无论多强都救不回来。
2. 训练割裂：检索器是无监督的 TF-IDF，读取器在 SQuAD 上有监督训练，两者没有共同目标。

1.5 节我们会看到如何用端到端联合训练同时拆掉这两颗地雷。

1.3 Retriever-Reader 框架的形式化

把 1.2 节的图变成数学语言：给定文档集合 $\mathcal{D} = \{D_1, \dots, D_N\}$ 和问题 $Q$，目标是输出答案串 $A$。

这个分解的计算优势是：retriever 处理 $|\mathcal{D}|=10^7$ 量级文档，必须快（毫秒级）；reader 只处理 $K$ 个候选，可以慢但准。如果让一个神经网络在 $10^7$ 个文档上做 cross-attention，需要 GPU 集群跑数小时——把检索剥离出来，这一步在单台 CPU 上几十毫秒搞定。

下面表格总结历代经典实现的选择：

注意 EM 分数从 25 涨到 60 用了 5 年——而retriever 几乎没换（都是 BERT 双塔），主要是 reader 在不断变强、目标变成生成、训练变成联合。这暗示了一个工程直觉：检索召回到 90% 就已经够好，瓶颈在生成器对多文档的融合能力。Fusion-in-Decoder（1.6）和 Lost in the Middle（1.7）会继续讨论这一点。

1.4 检索器全谱：BM25 / DPR / ColBERT

检索器的核心问题是：给定 query $q$ 和文档 $d$，输出一个相关性分数 $s(q, d)$。下面按"速度从快到慢、精度从粗到细"排列三大主流方案。

1.4.1 BM25：稀疏检索的统治者

BM25（Best Matching 25，Robertson & Walker, 1994）是 TF-IDF 的强化版，至今仍是工业搜索的默认基线，原因有三：不需要训练、不需要 GPU、对未见词（OOV）天然鲁棒。

BM25 的两个工程优点：

• 词频饱和：分子分母同时含 $f(t,d)$，当词频很大时趋于 $k_1+1$，避免一个高频词主导分数。
• 长度归一化：$\frac{|d|}{\overline{|d|}}$ 项让长文档不会自动得高分。

实现上用倒排索引（inverted index）：对每个词 $t$ 维护一个文档列表，query 来时只扫描出现 query 词的少量文档。Elasticsearch、Lucene、Tantivy 都基于此。对 21M 维基百科文档做一次检索仅需 50–100 ms。

BM25 的死穴是词汇鸿沟（vocabulary mismatch）：query "汽车" 检索不到只写"轿车"的文档。这正是密集检索（dense retrieval）登场的契机。

1.4.2 DPR：稠密双塔检索器

Dense Passage Retrieval（Karpukhin et al., 2020）用两个 BERT 编码器分别把 query 和 passage 映射到 $\mathbb{R}^{768}$，用内积做相似度：

训练目标是对比学习（contrastive learning）：让正样本 $(q, p^+)$ 的相似度高于一批负样本 $(q, p^-_1, \dots, p^-_n)$：

双塔（bi-encoder）的核心计算优势：passage 编码离线完成（21M 个向量预先算好存到向量数据库），query 来时只需算一个编码 + 用 FAISS/ScaNN 做近似最近邻（ANN）搜索，毫秒级。

DPR 实证（图见 PDF 第 19 页）：只用 1k 个 Q/A 对训练就能击败 BM25；用 60k 对训练 top-20 准确率达 85%，远超 BM25 的 75%。

1.4.3 ColBERT：晚交互的折中

双塔的代价：编码时 query 和 passage 没有交互，所有信息压成一个 768 维向量，可能丢细节。Cross-encoder（query 和 passage 拼接进同一个 BERT）保留了完整交互但无法预计算——每个 (q,d) 对都要跑一次 BERT，21M 文档完全跑不动。

ColBERT（Khattab & Zaharia, 2020）提出晚交互（late interaction）：每个 passage 不压成一个向量，而是为每个 token 都存一个向量，得到 $\{h_{p,1}, \dots, h_{p,m}\}$。query 来时为每个 query token $h_{q,i}$ 找最匹配的 passage token，然后求和：

实践中检索 pipeline 常做两阶段：BM25 或 DPR 召回 top-1000 → ColBERT/Cross-encoder rerank top-10。这是工业搜索（Vespa、ElasticSearch + LLM rerank）的标准范式。

1.5 端到端 RAG：Lewis 2020 与联合训练

DPR/FID 时代检索器和生成器是分阶段训练的。Lewis et al. (2020) 的 RAG 论文提出一个优雅的端到端方案：把检索看作潜变量，对它做边缘化，让梯度同时流过生成器和 query encoder。

对 generator 参数 $\theta$ 的梯度直观——每个候选文档都参与生成；对 retriever 参数 $\eta$ 的梯度通过 $p_\eta(z \mid x)$ 流回 query encoder（passage encoder 由于规模问题保持冻结）。

RAG-Token 是 RAG-Sequence 的细粒度版本：每生成一个 token 都重新边缘化所有文档。这两个变体在 NaturalQuestions 上达到 44.5 EM，比 closed-book T5 (36.6) 强 8 个点，证明非参数化记忆 + 参数化生成的组合优于把所有知识压进权重。

1.6 Fusion-in-Decoder：抽取转生成

RAG 在 BART 上 prepend 一个 passage 作为 context，K=5 时输入长度尚可。但如果想用 K=100 个 passage，BART 的 1024 上下文根本塞不下。Fusion-in-Decoder（FID）（Izacard & Grave, 2021）巧妙绕过这点：

关键洞察：Transformer 编码器复杂度 $O(L^2)$ 对长度敏感，但解码器对编码长度只是线性（cross-attention）。FID 把 N 个 passage 分别编码（cheap），再让解码器对拼接后的 N×L 序列做 cross-attention（doable）。

结果：FID-large（770M 参数）在 NaturalQuestions 51.4 EM，超过 GPT-3 (175B) 的 29.9 EM。这是 RAG 文献里反复被引的"小模型 + 好检索 > 大模型 closed-book"的强证据。

1.7 Lost in the Middle：长上下文的反直觉发现

2023 年 Liu et al. 论文 Lost in the Middle 给 RAG 社区泼了一盆冷水：即便你能塞 100 个 passage 进 GPT-4 的 32k 上下文，模型也不一定会读。

实验设计：人为构造一个场景，正确答案藏在第 $k$ 个 passage 里，其他 $K-1$ 个是干扰项。变化 $k$ 看准确率：

这个 U 型曲线对工程实践意味深长：

• 排序很重要：把最相关的 passage 放在 context 开头（或结尾），而非中间。
• "更多 passage" 不一定更好：从 K=10 加到 K=30，retriever recall 上升但端到端准确率几乎不动——多塞进去的文档可能让真相沉到中间。
• Long-context 模型不能替代好检索：Claude 100k、GPT-4 128k 都呈现 U 型，pure long context 不是银弹。

1.8 LLM + 实时网络检索：Perplexity 范式

2023 之后，Perplexity、You.com、Bing Chat、ChatGPT Search、Gemini Deep Research 等产品把 RAG 推向消费级。它们的共同范式：

1. 用户问题 → LLM 改写成 1–N 个搜索 query；
2. 调用 Google/Bing API 拿到 web snippets；
3. 抓取（fetch）若干完整网页 → 切片 → 重排；
4. 把 top-N 段拼进 prompt，让 LLM 生成带引用的答案；
5. 显示引用 footnote，用户可点击溯源。

与传统 RAG 的区别：

• 语料动态：从固定 Wikipedia 转向整个 web，索引由搜索引擎维护；
• 检索由 LLM 主动发起：query 改写、多轮检索都由 LLM 决策——已经是初级 Agent；
• 引用强制：UI 层强约束模型必须给来源。

Gemini Deep Research、Anthropic 的 Claude with web 进一步把这变成多轮 Agent 行为：先规划研究大纲 → 分多轮检索 → 综合写报告。这正是第 2 部分 Language Agent 的雏形。

1.9 引用准确性与幻觉评估

RAG 系统看似"有理有据"，但 Liu et al. (2023) 的评估给出惊人结果：

• 引用精度：模型引的来源中，真正支持对应陈述的比例。74.5% 意味着 1/4 的引用是"挂羊头卖狗肉"。
• 引用召回：模型陈述的事实中，有引用支撑的比例。51.5% 意味着一半陈述是"无凭据生成"——这就是幻觉。

用户主观感受 4.5/5（很满意），但客观可验证度只有 50–75%。这是 RAG 工程师必须正视的鸿沟：看起来对 ≠ 真的对。

1.10 RARR：先生成、再检索、再修订

Gao et al. (2023) 的 RARR（Retrofit Attribution using Research and Revision）提出反向思路：与其先检索再生成，不如先让 LLM 自由生成（保留流畅性），再逐句生成 query 去检索证据，最后让 LLM 检测分歧并改写：

RARR 的优势：可以包装在任何已有 LLM 输出上做 post-hoc 真实性校正，无需重训。这思路后来演化成 Anthropic 的 Citation API、OpenAI 的 Search-with-Citations。

第二部分：Language Agent 通用框架

RAG 教会 LLM "查资料"，但仍只是问答。真实世界里我们希望 LLM 能"帮我订机票"、"修这个 bug 然后提 PR"、"在 Excel 里跑数据透视表"——这些任务要求模型与环境交互、维护状态、做多步规划。这就是 Language Agent。本部分先建立全局框架，第 3–5 部分再分别深挖三大支柱。

2.1 从 LLM 到 Agent：observe-think-act 循环

把 LLM 与 Agent 的本质差异画在一张图里：

形式化地，Agent 是一个映射：

RL 老法师可能会问：这不就是经典的Markov Decision Process (MDP) 策略 $\pi(a \mid s)$ 吗？是。但 Language Agent 有三个独特之处：

1. 观察和动作都是自然语言——降低工程门槛，提升 zero-shot 泛化；
2. 策略由预训练 LLM 给出，无需从零学习 $\pi$，prompt 即策略；
3. 历史窗口有限——这就引出第 4 部分 Memory 的必要性。

2.2 四大支柱：Planning / Memory / Tools / Environment

Lilian Weng (2023) 的经典 blog post 总结的 LLM-powered Agent 框架（与本课程一致）：

2.3 认知架构 CoALA 视角

Sumers & Yao (2024) 的 Cognitive Architectures for Language Agents (CoALA) 框架把 Agent 类比为认知科学意义上的智能体，提供更系统的分类：

• Memory：工作记忆（context window）+ 长期记忆（episodic/semantic/procedural）；
• Action space：内部动作（reasoning、retrieval、learning）+ 外部动作（环境交互）；
• Decision-making：基于 LLM 的策略，循环 propose-evaluate-select-execute。

关键洞察：reasoning 本身被建模为一种内部动作（修改工作记忆），与tool call（修改环境）平级。这种统一视角让 ReAct（3.4 节）的"思考即动作"显得自然。

第三部分：推理与规划

Planning & Reasoning 是 Agent 的"大脑前额叶"——决定下一步做什么。本部分从最基础的 CoT 开始，逐步推进到 Self-Consistency、ReAct、Reflexion、多 Agent 辩论。我们会看到一个清晰的能力跃迁：纯推理 → 推理+行动 → 推理+反馈 → 多智能体协商。

3.1 LLM "推理"的本质：System 1/2 隐喻

认知科学里 Kahneman 把人类思维分为：

• System 1（直觉）：快速、自动、并行——"3+5=?" 你脱口而出 8；
• System 2（推理）：缓慢、串行、需努力——"17×23=?" 你要列竖式。

LLM 的朴素 forward pass 类似 System 1：每个 token 都用固定计算量。而 CoT 等技巧通过生成中间步骤 让模型把"答案"前的若干 token 当成"思考"，模拟 System 2。

对 Agent 而言，推理服务于行动。Yao et al. 总结了两条收益：

1. 泛化（Generalization）：在新环境里靠常识做出合理决策——"盐没了，找酱油"；
2. 对齐（Alignment）：让动作可解释、可审计、可纠正。

3.2 Chain-of-Thought 复盘

Wei et al. (2022) 的 Chain-of-Thought (CoT) 在 PEFT 教材已详述，这里只回顾对 Agent 设计最关键的点：

CoT 的几个反直觉特性：

1. 涌现：模型规模 < 60B 时几乎无效，超过阈值后跳跃式提升（Wei et al. 2022b）；
2. 中间步骤可不严密：Self-Consistency 显示即使个别推理错误，多数表决仍提升精度；
3. "Let's think step by step" 是 zero-shot 触发器（Kojima et al., 2022），无需 few-shot 例子。

3.3 Self-Consistency：边缘化推理路径

Wang et al. (2023) 提出对 CoT 解码做一个简单但威力巨大的改进：

GSM8K 数学推理上，single CoT 56.5% → Self-Consistency 74.4%，几乎追平当时的微调 SOTA，无需任何梯度更新。代价是推理成本 ×N。

3.4 ReAct：把推理本身当作动作

ReAct（Yao et al., 2023）是 Agent 时代的奠基性工作。核心思想：让 LLM 在每一步交替输出 Thought（推理）和 Action（动作），Action 由环境执行返回 Observation，循环直到 Finish。

对比三种范式：

下面是 ReAct 在 HotpotQA 上的真实轨迹（PDF 第 36 页）：

关键看到的几个工程问题：

• 命名实体歧义：搜索"Front Row"返回多个不相关条目，需要 disambiguate；
• 纠错能力：模型自己发现搜索失败、自己改 query；
• 显式终止：以 Finish[] 显式结束循环，避免无限对话。

ReAct 在 HotpotQA 上的表现：CoT 29.4 EM，Act 25.7，ReAct 27.4，ReAct→CoT-SC 35.1。表面看 ReAct 单独不如 CoT，但失败模式分析揭示真相：

ReAct 用推理错误（可纠正）置换了 CoT 的幻觉（不可纠正）——这正是把 retrieval 引入 reasoning 链的核心价值。

3.5 Reflexion：用自然语言强化学习

Reflexion（Shinn et al., 2023）把 ReAct 推进一步：让 Agent 在失败之后 用语言总结教训，写入长期记忆，下次尝试时把"教训"前置到 prompt。

实例（PDF 第 39 页 ALFWorld 任务）：

实证结果：ALFWorld 任务上 ReAct only 在 5 轮内停在 75% 左右；加上 Reflexion，10 轮迭代后达到 97%。幻觉和低效规划比例显著下降。

Reflexion 的本质：用语言代替梯度。传统 RL 通过梯度更新策略参数，Reflexion 通过把"教训文本"prepend 到 prompt 改变 LLM 的条件分布。这是 LLM 时代非参数化学习的代表范式。

3.6 多 Agent 辩论与 Orchestrator 协调

3.6.1 Multi-Agent Debate

Du et al. (2023) 提出多 Agent 辩论（MAD）：让若干 LLM 实例对同一问题独立给出答案，然后看到彼此的回答并迭代修正。多轮后收敛到共识。

示例（PDF 第 42 页珠宝问题）：

• Round 1: Agent 1 算出 225，Agent 2 算出 595（应当为 595）。
• Round 2: Agent 1 看到 Agent 2 的解法，发现自己"红宝石数量"算错（误用 175-35-35=105 而非 175-35=140），承认 错误，更新为 595。两方达成共识。

MAD 在 GSM8K、Biographies factual recall 等任务上比 Self-Consistency 再提 5–10 点。但代价是 2–4 倍 token，且对"权威 Agent 主导对话"很敏感。

3.6.2 Orchestrator 模式

Microsoft 的 Magentic-One（2024）展示了另一类多 Agent 设计：用一个 Orchestrator Agent 制定 task-specific 计划，然后调度专家 Agent（FileSurfer、Coder、WebSurfer、ComputerTerminal）。它已不是"多模型平等辩论"，而是有层级的工作团队。这种模式在工业 Agent 框架（LangGraph、AutoGen、CrewAI）中是主流。

第四部分：记忆机制

给 LLM 一个 128k 上下文窗口，它就能记住一切吗？1.7 节的 Lost in the Middle 已经否定了这个幻想。本部分系统讨论 Agent 如何外置记忆：分类、写入、检索、整合，并研究三个范式系统——Generative Agents、Voyager、MemGPT。

4.1 为什么 Context Window 不够用

就算 LLM 真有无限上下文，也至少有三类问题：

1. 容量：Generative Agents 一天 1000+ 事件，模拟 10 天就超 10k 行；
2. 检索：上下文里有 10k 事件，但当前问题只与其中 5 条相关，attention 会被淹没（1.7 节）；
3. 跨会话：用户今天和你聊的偏好，明天新开会话就忘——session 间需要持久层；
4. 成本：每次推理把 128k token 都送进去，API 费指数级飙升。

所以现代 Agent 普遍把 LLM 上下文当成工作记忆（短期），外置一个长期记忆，按需取用。

4.2 记忆的认知三分法

认知科学（Tulving 1972 等）把人类长时记忆划分为：

三者的工程对应：

• Episodic → append-only 事件流 + 加权检索；
• Semantic → 对事件流做 LLM 反思 提取高层概念，存为图/树；
• Procedural → 可执行代码库，用 embedding 检索后直接 invoke。

4.3 Generative Agents 与斯坦福小镇

Park et al. (2023) 的斯坦福小镇是 LLM Agent 应用的破圈之作：25 个由 LLM 驱动的居民在一个像素游戏世界中生活，能自发产生规划早餐、和朋友吃饭、组织情人节派对 等涌现行为。

4.4 Episodic Memory 的检索分数设计

Park et al. 的关键工程贡献：用三个分数的加权和决定从 memory stream 中取哪些事件：

PDF 第 48 页的示例（Isabella 计划情人节派对）：

问 "你最期待什么"，检索回这三条 → LLM 生成自然回答："我最期待自己在 Hobbs Cafe 办的情人节派对！"

4.5 Semantic Memory：反思树

纯事件流容易"只见树木不见森林"。Generative Agents 引入反思（reflection）机制：当近期事件累积的重要性超过阈值，触发 LLM 在记忆上 reasoning，生成高层抽象：

反思和观察混在同一个 memory stream 里，检索时一视同仁，但反思在语义检索时更可能匹配抽象问题（如"你了解 Klaus 吗"）。这是把 LLM 推理本身作为知识压缩的范式。

4.6 Procedural Memory：Voyager 技能库

Wang et al. (2023) 的 Voyager 是 Minecraft 中的 GPT-4 Agent，三大组件：

1. Automatic Curriculum：自动生成"下一步该学什么"的目标（Mine wood → Make crafting table → Mine diamond）；
2. Iterative Prompting：用 GPT-4 写 JavaScript 代码控制游戏，run-feedback-refine 直到通过；
3. Skill Library：成功的代码作为命名技能 存入向量库；新任务先 embedding 检索复用。

关键代码片段（伪 JS）：

async function combatZombie(bot) {
  // Equip a weapon
  const sword = bot.inventory.findInventoryItem(
    mcData.itemsByName["stone_sword"].id);
  if (sword) {
    await bot.equip(sword, "hand");
  } else {
    await craftStoneSword(bot);   // ← 调用已存在的技能
  }
  // Craft and equip a shield
  await craftShield(bot);          // ← 调用已存在的技能
  ...
}

技能调用形成层次化：基础技能（mine wood）被中级技能（make crafting table）调用，再被高级技能（combat zombie）调用。Voyager 在 24 小时无人干预下学到 60+ 项技能，平均探索区域 2.3× 于其他基线。

Procedural memory 的本质：把 trial-and-error 的成本一次性付清，之后零成本复用。这是 Agent 实现"持续学习"的最实用范式。

4.7 MemGPT：OS 风格的虚拟上下文

Packer et al. (2024) 的 MemGPT 把操作系统的虚拟内存思想搬到 LLM：

核心机制：把 prompt 划分为 4 块，其中 Working Context 由 LLM 通过 function call（如 archival_insert、archival_search、main_context_replace）主动 read/write。当 FIFO Queue 即将溢出时，触发一次"自我反思"把旧消息总结后丢进 archival storage。

评估（DMR, Deep Memory Retrieval）：

MemGPT 给出最实际的洞察：固定 8k window + 好分页 > 200k window 直塞。后者在 100+ 文档时性能崩塌；MemGPT 几乎不受影响。这与 1.7 节 Lost in the Middle 完全吻合。

第五部分：工具使用

RAG 把"查资料"封装为工具调用是显然的；但 Agent 时代 tool use 还要解决计算（calculator）、代码执行、API 调用、读写记忆、操控 GUI 等异构需求。本部分讨论三种学习工具调用的范式，从最早的 Toolformer 到工业级的 Gorilla。

5.1 工具：把世界折叠进 token 序列

把 LLM 看成一个文本生成器，工具调用意味着在文本流中插入一段"魔法 token"：

The New England Journal of Medicine is a registered trademark of [QA("Who is the publisher of NEJM?") → Massachusetts Medical Society] the MMS.

当解码器生成 [QA(...) 这种模式时，runtime 暂停 LLM，把括号里的 query 交给真正的 QA 系统执行，把结果以 → ... 形式回填，再让 LLM 续写。这种"暂停 → 调用 → 回填 → 续写"是几乎所有现代 tool use 框架的共同骨架（OpenAI Function Calling、Anthropic Tool Use、MCP 协议都不例外）。

剩下的问题就两个：

1. How to learn when to call：模型怎么知道何时该插入魔法 token？
2. How to scale to many tools：当工具数量从 5 增长到 50,000 时怎么办？

Toolformer 解决前者，Gorilla 解决后者，ToolkenGPT 提供中间方案。

5.2 Toolformer：自监督学习何时调用 API

Schick et al. (2023) 的 Toolformer 提出极简但优雅的方案：让 LLM 自己给自己生成训练数据。

关键洞察：API 是否有用 ≡ 它能否帮模型预测下一个 token。这是把"工具学习"完全 reduce 到 perplexity 优化的妙手，不需要人工标注。

Toolformer-6.7B 在 SQuAD/Google-RE/T-REx 上超越 GPT-3-175B：

支持的工具：QA 系统、计算器、维基检索、翻译、日历。每个工具只需几个 demonstration，self-supervised pipeline 自动生成训练集。

5.3 ToolkenGPT：工具即特殊 Token

Hao et al. (2024) 的 ToolkenGPT 走另一条路：把每个工具视为一个新词表项（toolken = tool + token），学习一个 embedding。

训练时把工具名作为目标 token 出现在文本里，模型学到何时输出 toolken。推理时分两阶段：

1. Reasoning mode：常规生成；
2. 当 toolken 概率高于阈值，切换到 Tool mode：用 few-shot demonstration 让模型生成参数；
3. 执行工具，回填结果，回到 Reasoning mode。

优势：

• 可扩展性：新增工具只需新加 toolken embedding 训练，无需触碰主权重；
• 组合性：toolken 与原生 token 在同一 softmax 空间，可与 CoT 自然交织。

5.4 Gorilla：把 LLM 接入 16,000 个 API

Patil et al. (2023) 的 Gorilla 直面"工具规模"问题。它的训练数据集：

• 从 TorchHub (94)、TensorFlow Hub v2 (626)、HuggingFace (925) 抓取 API 文档，共 1,645 个 API；
• 用 self-instruct 让 GPT-4 为每个 API 生成 10 个 {instruction, API} 对，共 16,450 个训练样本；
• 在 LLaMA-7B 上 fine-tune，得到 Gorilla。

关键创新：检索增强训练。把 API 文档放入 BM25 retriever，训练时把 top-1 检索结果 prepend 到 prompt，让模型学会"看文档调 API"。推理时同样配合 retriever 使用，可处理训练时未见过的 新 API。

评估指标 = Accuracy（API 选对）÷ Hallucination（API 不存在）。Gorilla-7B 击败 GPT-4 在 zero-shot 设定下：

• 0-shot：Gorilla 70% 准确率，幻觉 10%；GPT-4 ~40% 准确率，幻觉 40%；
• BM25-retriever：所有模型大幅提升，但 Gorilla 的提升斜率最陡。

Gorilla 的工程含义：tool use 不必把所有工具签名塞进 prompt——可以靠 retrieve（5.1 节 RAG！）按需召回 5–10 个候选工具，再让 LLM 选。RAG 和 Agent 在 tool use 这一层闭合。

5.5 工具调用的稳健性与安全

这一节常被论文忽略，却是生产环境最痛的地方：

5.5.1 Model Context Protocol (MCP)

2024 年底 Anthropic 提出的 MCP 是工具生态的标准化尝试：把"工具 = 一个 MCP server"，定义统一的 manifest、schema 和 transport 协议。开发者写一个 MCP server 后，任何 MCP-compatible 客户端（Claude Desktop, Cursor, etc.）都能调用。这正在成为 2025 年 Agent 工具的事实标准，相当于 USB 之于硬件。

第六部分：Agent 应用全景

四大支柱（Planning/Memory/Tools/Environment）是抽象骨架。本部分把它们映射到真实环境：代码仓库、网页、桌面 OS、物理世界。每种环境定义不同的观察空间和动作空间，催生不同的工程权衡和 benchmark。

6.1 数字 vs 物理世界的分类

6.2 Coding Agents：SWE-bench 与 SWE-agent

6.2.1 SWE-bench：现代 Coding Benchmark

Jimenez & Yang (2024) 的 SWE-bench 是 Coding Agent 的金标准。任务定义：

关键点：评估是基于真实测试的执行结果——不是字符串匹配，不是 LLM-as-judge，而是真正跑测试。这避免了"看起来对但跑不通"的 false positive。

典型任务（PDF 第 61 页）：

• Issue：sklearn 中 GBDT 因 warm start 导致 data leak；
• Codebase：sklearn/、examples/、setup.py、reqs.txt 等 1000+ 文件；
• Agent 输出：修改 sklearn/gradient_boosting.py + helper.py；
• Eval：原本失败的 3 个测试（join_struct_col, vstack_struct_col, dstack_struct_col）应通过，原本通过的测试不能退化。

SWE-bench-Verified 是 OpenAI 与原作者合作筛选的 500 个高质量子集，更可靠。

6.2.2 SWE-agent：第一个能做 SWE-bench 的 Agent 框架

Yang et al. (2024) 的 SWE-agent 的核心贡献是Agent-Computer Interface (ACI)：为 LLM 设计专门的 shell-like 操作集，而不是裸 bash：

ACI 的设计哲学：environment-engineering 比 prompt-engineering 更重要。给 LLM 一个对它友好的接口（小步长、清晰边界、强反馈），它的表现 1.5–2× 提升。

6.2.3 SWE-bench 战绩进化

SWE-bench Verified 上的进展速度令人咋舌：

这种 1 年从 13% → 70% 的进展并非单纯模型变强：Agent harness、ACI 设计、数据生成（见 7.2 节 SWE-smith）都贡献巨大。

6.3 Web Agents：WebArena / Mind2Web

Web Agent 让 LLM 在浏览器里完成任务，如"找一张从纽约到多伦多的单程机票"。

6.3.1 观察与动作空间

• 观察：可以是 (a) 完整 HTML DOM 树（结构化但冗长，单页 50k+ token）；(b) 截图（直观但需多模态模型）；(c) accessibility tree（轻量替代，约 5–15k token）；(d) screenshot + DOM 混合。
• 动作：click(element_id)、type(element_id, text)、scroll(direction)、hover、goto(url)、go_back 等。

6.3.2 主要 Benchmark

WebArena 上 GPT-4 + ReAct 2023 时仅 14% 成功率；2024 末多模态 + DOM 混合 Agent 已达 35–50%；2025 年 Claude 4 / GPT-5 Computer-use 模型在 live web 上 ~50–65% 复杂任务成功率。

6.4 Computer-use Agents：OSWorld

Web 之外还有更广阔的桌面世界——Word/Excel、IDE、Photoshop。OSWorld（Xie et al. 2024）是 369 个跨 Ubuntu/Windows/MacOS 应用的真实任务，例如：

"用过去几天我的银行交易更新提供的文件夹里的记账表格。"

Agent 需要：

1. 读取银行交易截图（OCR + 视觉理解）；
2. 打开 LibreOffice Calc；
3. 找到表格的合适位置；
4. 填入数据，保存。

动作空间：键盘 + 鼠标 + 快捷键，即 pyautogui 风格的 GUI 操作。评估通过 execution-based check：对比终态文件/系统状态与 oracle。

2024 年 GPT-4V + 最强 Agent harness 在 OSWorld 上 ~10–15%；Anthropic Claude 3.5 Sonnet Computer Use beta 跳到 ~22%；2025 年 GPT-5/Claude 4 系列 ~35%。距离生产可用仍有距离，但增长曲线陡峭。

6.5 物理世界：机器人与 VLA

本课程主要讨论数字世界，物理 Agent 我们只略述。VLA (Vision-Language-Action) 模型 如 RT-2、Pi-0、OpenVLA 把 LLM 思想搬到机器人：

• 输入：相机图像 + 自然语言指令（"把红色方块叠到蓝色方块上"）；
• 输出：连续的 joint action token 序列（把 6-DOF 关节角度离散化为 token，与文本同一个 vocabulary）；
• 训练：互联网级图像-文本预训练 + 机器人 teleoperation 数据微调。

核心挑战与数字世界 Agent 一致：泛化、长 horizon、数据稀缺。后两个问题第 7 部分会展开。

第七部分：Agent 数据与评估

"Where do we get the data?"——这是过去 5 年所有 Agent 研究者最头痛的问题。LLM 预训练有整个互联网，但带 action 标签的 trajectory 数据 几乎不存在。本部分先讨论数据获取的三条路径，再以 SWE-smith 为案例研究，最后讨论评估的根本困难。

7.1 三条数据来源路径

7.1.1 人类演示的痛点

• 基础设施成本：录制一个 Excel 任务需采集屏幕 + 键鼠 + 应用程序状态，部署到 N 个 OS；
• 专家时间：编程任务需要 senior engineer 标注，时薪高；
• 覆盖：人能想到的任务远少于真实长尾分布。

7.1.2 Synatra：把网络教程变 trajectory

Anthropic + Stanford 的 Synatra（Ou et al. 2024）观察到：网上有大量 how-to 教程（"如何在 PayPal 取消订阅"），它们包含间接知识——足以推断出 trajectory：

步骤：(1) 抓取大量教程，(2) LLM 把每步映射到 actionable command，(3) 在真实/模拟环境中 replay 验证。这种合成数据训练出的 web agent 在 Mind2Web 上接近用 SFT + 人工 demo 的 baseline，但数据成本 1/100。

7.1.3 Internet-scale 的潜力与挑战

YouTube 教程视频、Twitch 游戏直播录像、GitHub commit history 都蕴含巨量 Agent-relevant 数据。挑战：缺乏精确的 action label（视频里点了哪儿、键盘按了什么）。最新的工作（如 DeepMind SIMA、Adept Action Transformer）用 vision foundation model 反推 action，逐步把这条数据流变得可用。

7.2 案例研究：SWE-smith

Yang et al. (2025) 的 SWE-smith 是把 7.1 三条路径融合的代表作。目标：为任意 Python GitHub 仓库自动合成 100s–1000s 训练任务。

4 种 bug 合成策略：

1. Procedural Modification：编程式改函数（删 if 分支、反转条件、改运算符）；
2. LM Generated：让 LLM 故意引入符合 issue 风格的 bug；
3. Combine Bugs：把已有 bug 跨文件组合；
4. PR Mirroring：从真实 PR 的"修复"反推"bug"。

训练设置：

• Experts：Claude 3.5/3.7、GPT-4o（生成数据）；
• Student：Qwen 2.5 Coder Instruct；
• 训练：Rejection Sampling Fine-Tuning（RFT）——只保留 experts 真正解决任务的 trajectories；
• 结果：SWE-agent-LM-32B 在 SWE-bench Verified 上 40.2%，与 GPT-4o (39%)、Claude 3.5 (40.7%) 等闭源模型持平。

SWE-smith 的核心 take-away：训练数据可以是模型自己（或更强模型）合成的；agent 训练越来越像 RL self-play。

7.3 Agent 评估的四大挑战

7.4 评估方法学：基准/LLM-as-judge/众包

7.4.1 Execution-based benchmark

最可靠：定义一个 oracle 检查器（unit test、状态比对、API 调用日志）。SWE-bench、WebArena、OSWorld 都属此类。缺点：每个任务都要写 checker，成本高，且无法覆盖"多解"。

7.4.2 LLM-as-judge

用一个更强的 LLM 评估 agent 输出。如 MT-Bench、AgentBench 部分子集。优点：便宜可扩展；缺点：

• 位置偏置：偏好先出现的答案；
• 风格偏置：偏好冗长答案；
• 能力上限：judge 自己就答错的题目无法评估。

缓解：双向交换位置、强 schema 输出、人工抽检校准。

7.4.3 众包评估

给真人看 trajectory 让其打分。Chatbot Arena 是著名例子。优点：最贴近用户感知；缺点：贵、慢、不可复现。Agent 任务对众包评估特别难——评估者要懂 SQL、懂 Excel、懂某网站的业务逻辑。

第八部分：实战 — 100 行代码写一个 Coding Agent

本部分对应 PDF 第 70–72 页 John Yang 的 bonus 教学。我们把"Agent"这个概念拆到最小骨架，用 ~100 行 Python 实现一个可用的 coding agent，让它能在 bash 环境里查文件、编辑、运行测试。然后讨论从"玩具"到"生产"还差哪些工程。

8.1 Agent loop 的极简内核

Agent 在最根本的层面就是一个 while loop：

messages = [{"role": "user", "content": "Help me fix the ValueError in main.py"}]
while True:
    lm_output = query_lm(messages)
    print("LM output:", lm_output)
    messages.append({"role": "assistant", "content": lm_output})  # 记住 LM 说了啥

    action = parse_action(lm_output)  # 从输出里抠出 action
    print("Action:", action)
    if action == "exit":
        break

    output = execute_action(action)   # 在环境里执行
    print("Output:", output)
    messages.append({"role": "user", "content": output})  # 把环境输出回灌

循环的本质 = observe（环境输出） → think（LM 思考） → act（执行动作）。这正是 2.1 节 Agent 形式定义的最直接实现。

8.2 三个核心函数实现

整个 agent 就靠 query_lm / parse_action / execute_action 三个函数。

8.2.1 query_lm — 把消息列表丢给 LLM

from openai import OpenAI

client = OpenAI(api_key="your-api-key")  # 或设 OPENAI_API_KEY 环境变量

def query_lm(messages):
    response = client.responses.create(
        model="gpt-5.1",
        input=messages,
    )
    return response.output_text

关键点：

• 消息列表是累积的——每轮都把完整历史送进去；
• 使用 responses.create（新版 API）或 chat.completions.create（经典）都可以；
• System prompt 必须有（实战中务必加），告诉模型动作格式。例如：

SYSTEM_PROMPT = """You are a coding agent. Each turn, you MUST end your message
with exactly one action wrapped in <bash_action>...</bash_action>.
You will see the output in the next user message.
When done, output <bash_action>exit</bash_action>."""

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},
    {"role": "user", "content": user_task},
]

8.2.2 parse_action — 抠出可执行命令

import re

def parse_action(lm_output: str) -> str:
    """Take LM output, return action."""
    matches = re.findall(
        r"<bash_action>(.*?)</bash_action>",
        lm_output,
        re.DOTALL,
    )
    return matches[0].strip() if matches else ""

这里用 XML 风格标签是个工程小技巧：

• 不会与代码内容冲突（不像 ```bash 在分析 Markdown 代码时常误判）；
• 易 regex 提取；
• Anthropic 推荐的 Claude tool-call 格式正是 XML，对它特别友好。

更稳健的做法（生产推荐）：用 OpenAI/Anthropic 的 native function calling API，让模型直接吐 JSON action，跳过 parsing。

8.2.3 execute_action — 真正去做事

import subprocess
import os

def execute_action(command: str) -> str:
    """Execute action, return output."""
    result = subprocess.run(
        command,
        shell=True,
        text=True,
        env=os.environ,
        encoding="utf-8",
        errors="replace",
        stdout=subprocess.PIPE,
        stderr=subprocess.STDOUT,  # 合并 stderr 到 stdout，agent 能看到错误
        timeout=30,                # 防止挂死
    )
    return result.stdout

这一段是整个 agent 的"权力中心"：subprocess.run 给了 LM 真实的 shell。务必注意：

• timeout：防止 LLM 让 agent 跑 while true；
• shell=True：方便但不安全，生产环境用 list argv + sandbox；
• 合并 stderr：agent 能看到 stack trace 才能 debug。

8.2.4 完整可运行版本

"""minimal_agent.py — 一个真能 fix bug 的 Coding Agent
依赖：openai>=1.0
运行：OPENAI_API_KEY=sk-... python minimal_agent.py
"""
import os, re, subprocess, sys
from openai import OpenAI

SYSTEM_PROMPT = """You are a coding agent inside a bash shell.
Each turn you must end your reply with exactly ONE action:
<bash_action>your shell command here</bash_action>
When the task is complete, output:
<bash_action>exit</bash_action>"""

client = OpenAI()

def query_lm(messages):
    return client.responses.create(model="gpt-5.1", input=messages).output_text

def parse_action(lm_output):
    matches = re.findall(r"<bash_action>(.*?)</bash_action>", lm_output, re.DOTALL)
    return matches[0].strip() if matches else ""

def execute_action(command):
    if command.strip() == "exit":
        return ""
    try:
        return subprocess.run(
            command, shell=True, text=True, env=os.environ,
            encoding="utf-8", errors="replace",
            stdout=subprocess.PIPE, stderr=subprocess.STDOUT, timeout=30,
        ).stdout
    except subprocess.TimeoutExpired:
        return "[Timeout after 30s]"

def main(task, max_steps=20):
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": task},
    ]
    for step in range(max_steps):
        print(f"\n=== Step {step+1} ===")
        lm_output = query_lm(messages)
        print("LM:", lm_output)
        messages.append({"role": "assistant", "content": lm_output})

        action = parse_action(lm_output)
        print("Action:", action)
        if action == "exit":
            print("Agent finished.")
            break

        observation = execute_action(action)
        print("Obs:", observation[:500])
        messages.append({"role": "user", "content": f"<observation>{observation}</observation>"})

if __name__ == "__main__":
    task = sys.argv[1] if len(sys.argv) > 1 else "List files in current dir then exit"
    main(task)

这 ~50 行代码就能让 Claude/GPT 在你的电脑上跑命令、修 bug、跑测试。把它放在 sandbox（Docker 容器）里运行，就和 SWE-agent 的核心循环没有本质区别——只是少了 ACI（6.2.2）和并行管理。

8.3 从 minimal 到 production 的工程清单

把上述 50 行扩成可上线的系统，至少需要加：

第九部分：总结、对比与开放问题

9.1 RAG vs Long Context vs Fine-tune：决策矩阵

当 PM/老板问你"给 LLM 加领域知识应该选哪种方案？"——这张表是最实用的决策起点：

9.2 Agent 的核心开放问题

1. 长 horizon 可靠性：50 步任务里只要一步错，全盘崩。如何让 Agent 在 100+ 步任务上保持 >80% 成功率？（当前 OSWorld 多步任务成功率 ~30%）
2. 真正的"持续学习"：Voyager 的技能库还是单仓库；如何让 Agent 跨任务、跨用户积累技能而不冲突？
3. 多 Agent 协作的可信度：MAD 容易出现"群体盲从"（一个错答被其他 agent 复述）；如何设计可信赖的协作协议？
4. 动作空间设计：bash < SWE-agent ACI < ?——是否存在一种"对 LLM 最优"的动作 IR？
5. Agent 安全：prompt injection、tool misuse、目标偏离（goal drift）；2025 后期成为热点。
6. 评估方法学：如何摆脱 benchmark hacking，让 evaluation 跟得上模型进化速度？
7. Generalist vs Specialist：一个 super agent 能否取代 10 个 specialist；编辑器 agent 和 web agent 共享多少参数？
8. 成本-能力曲线：当前一次 SWE-bench trajectory 几美元；如何在保持能力下降低 100×？

9.3 配套阅读与下一步

课程内联系

• Lecture 09 PEFT：本教材 9.1 决策矩阵的"Fine-tune"列详见 lecture09_peft_textbook.html；LoRA/QLoRA/Prefix-tuning 的完整推导都在那里。
• Lecture 11 Evaluation：本教材 7.3–7.4 讨论的 agent 评估困难，与 LLM 通用评估学共享方法论，详见 lecture11_evaluation_textbook.html。

外部进阶资源

• LLM Powered Autonomous Agents — Lilian Weng 2023 经典博客（本教材 2.2 节图源）
• Cognitive Architectures for Language Agents — Sumers & Yao 的 CoALA 框架论文
• Language Agents: Foundations, Prospects, and Risks — EMNLP 2024 tutorial (Su, Yang, Yao, Yu)
• SWE-bench Leaderboard — 实时跟进 Coding Agent SOTA
• Building Effective Agents — Anthropic 2024 年的工程经验总结

动手项目建议

1. RAG 入门：用 Chroma + LangChain 构建一个 "聊我的 PDF" 系统，~200 行 Python，1 个下午；
2. Agent 入门：把 8.2.4 的 50 行 minimal_agent 跑通，让它 fix 一个真实的 sklearn bug；
3. 研究项目：从 SWE-bench-Lite 挑 30 个任务，对比 ReAct vs Reflexion 在你修改的 prompt 下的 success rate；可以作为一个 final project。