第一章　大模型的能力：预测下一个 token

它能改写邮件、解释报表、编写程序，也可能一本正经地写出不存在的依据。理解这些表现，可以从一个简单动作开始：根据已有内容，预测下一个 token。但要解释能力从哪里来，还需要看看这个动作背后的网络、训练和计算。

1.1 一次回答，是怎样写出来的

打开聊天窗口，输入“请解释净息差”，屏幕上很快出现一段回答。对模型而言，输入首先要经过分词器（tokenizer），变成一串 token。token 是模型处理文本的基本单位，可能是一个字、一个词、一部分单词，也可能是标点或空格。每种 token 对应词表里的一个编号；它与人习惯的“一个字”“一个词”没有固定换算关系。同一段中文使用不同分词器，token 数也可能不同。

模型接收这些编号后，计算词表中各个候选 token 接在后面的概率。系统选出一个，把它接回已有序列，再计算下一步。这个反复“用已有内容生成后续内容”的过程叫自回归生成。直到产生结束标记、用完输出预算，或遇到其他停止条件，一次回答才告一段落。这里讲的是常见文本生成路径；图片、音频等输入还会经过各自的编码处理。

模型估计的是：在当前输入和已学规律下，什么内容适合接着出现。为了接好一段代码，它需要利用变量关系；为了完成证明，需要处理前提与步骤；延续人物对话时，还要把握角色和语境。长期训练会形成支持这些任务的能力，而生成时仍以 token 为单位推进。候选的概率描述生成倾向；一句话是否符合事实，还需要证据来判断。

选取候选时，系统可以取最高概率项，也可以按分布采样。采样给不同候选保留机会，因此相同问题可能产生不同措辞。温度（temperature）通常用来调节分布的集中程度：降低温度往往使选择更集中，提高温度往往让更多候选有机会出现。调低温度适合需要较稳定表达的任务，但事实准确性还取决于模型能力和资料。即使总选最高概率候选，也可能反复得到同一个错误答案。

1.2 Transformer：把前文变成可计算的关系

Transformer 是一类神经网络结构。它接收 token 序列，逐层计算其中的信息关系，再给下一 token 的候选打分。理解这条计算链，可以先看每一步处理的对象：起初是词表编号，进入网络后是一组组向量，最后才变成候选概率。

第一步是嵌入（embedding）。模型按 token 编号，从嵌入表中取出对应向量。向量就是一列数字，例如示例中的 [0.2, −0.4, 0.7]；真实模型的向量通常长得多。嵌入表本身属于学习到的参数，同一个 token 进入网络时有一个起始表示。随后各层会根据语境改变它的表示，因此英文 bank 在“bank loan（银行贷款）”与“river bank（河岸）”里可以形成不同的上下文表示。

模型还需要知道各片段的相对或绝对位置。把“客户向银行付款”改成“银行向客户付款”，相同词语表达了不同方向。位置信息参与网络计算，帮助模型处理这种差别；具体怎样加入，随架构而异。

注意力（attention）负责跨位置结合信息。读到“存款增加，其成本也上升”时，对“其”的解释需要借助前文。网络让当前位置与可见位置计算匹配分数，再按权重汇集信息。不同层、不同注意力头可以形成不同的组合；模型能否最终处理好指代，取决于整个网络学到的表示。

与之配合的前馈网络（FFN）在每个位置上继续变换向量。可以粗略理解为：注意力让不同位置交换信息，FFN 对交换后的表示做进一步加工。经过多层处理，最后位置的向量包含了可用于预测的上下文信息。输出层给词表中的候选各打一个分数，再把这些分数转成总和为 1 的概率。1.1 节讨论的采样从这里接手。

2017 年《Attention Is All You Need》提出 Transformer，原论文面向机器翻译，采用编码器—解码器结构。后来的许多生成式 LLM 使用以解码器为主的变体。图 1-1 画的是后者的简化生成路径，保留了注意力、FFN 与输出预测的计算关系。[1]

1.3 能力来自训练：pretrain 与 post-train

模型的参数或权重包括嵌入表、注意力中的变换矩阵、FFN 和输出层等数值。一次训练更新通常先用当前权重计算输出，再将结果与训练目标比较，最后依据差距调整参数。训练程序会把这种差距表示为数值，通常称为“损失”。经过许多轮更新，模型逐渐提高在训练任务上的表现。

模型在许多批次的数据上反复进行这些更新。某一条样本对数值的影响往往很小，积累起来却会改变它对词语、概念和解题方式的处理。训练后的权重可以保存为一个新版本，供后续请求使用。普通对话则通常拿已有权重计算；用户提供的新材料首先改变的是本次输入。

预训练：从文本本身取得训练目标

预训练（pretrain）利用大规模数据学习广泛规律。对常见自回归语言模型，文本本身就能提供下一 token 的目标：取一段内容，把每个位置的前文作为条件，原文紧接着出现的 token 就是该位置的训练标签。模型为真实后续 token 分配的概率越低，对应的预测损失通常越大。这个做法让大量普通文本可以用于训练，无需人工先为每句话编一道问答题。[9]

用同一个小例子来看：训练资料里有“余额从 100 增至 108，增长率为 8%”。在读到答案之前，模型需要预测后续片段；训练程序将预测与原文的真实 token 比较，并更新参数。真实切分可能把数字和符号拆成多个 token。大量类似的金融说明、数学推导和程序中都存在可重复的关系，模型在预测任务中逐渐学到这些关系的表示。与此同时，资料中的错误、偏差和遗漏也会影响学习结果。

后训练：进一步学习怎样响应任务

后训练（post-train）是在已有模型基础上继续塑造能力和行为的统称。开发者可能希望模型更好地遵循用户要求、给出清楚解释、使用工具或处理多步问题，因此会改变训练数据、目标与反馈方式。SFT、偏好优化和 RL 都可以参与后训练；它们可分阶段组合，也可交替使用，具体路线取决于模型目标。

监督微调（Supervised Fine-Tuning，SFT）提供成对的任务与示范回答。延续刚才的问题，输入是“余额从 100 增至 108，增长率多少？请列出公式”，示范回答是“(108 − 100) ÷ 100 × 100% = 8%”。训练时通常先给模型问题和示范回答已经展开的部分，让它预测接下来应出现什么，再根据与示范的差距调整参数。这相当于把“怎样完成要求”也放进了学习材料：哪些数字应进入公式、基数是什么、用户要公式时应如何表达。

SFT 的结果是，模型在类似输入下更倾向于生成与示范相符的响应。它可以学习风格，也可以学习解题和工具使用模式；质量取决于示范本身、样本覆盖和优化过程。只有一道标准答案，覆盖不了今后所有条件变化。

偏好优化从比较中取得方向。如果同一道题有“8%”和“按期初余额计算，(108 − 100) ÷ 100 = 8%”两份回答，评审可以在用户明确要求公式时选择后者。偏好数据描述的是在特定要求下，哪份回答更合适。利用这些数据的一种路线是训练奖励模型，再用于强化学习；还有直接利用偏好对优化模型的方法。这样得到的信号带有评价者与评价标准的选择。[10]

强化学习（Reinforcement Learning，RL）让模型根据当前策略生成尝试，再利用奖励改进策略。对于这个算术题，可以由程序核对答案；对于代码，可以运行测试；对于开放写作，也可以由人或评判模型给出信号。优化算法根据这些反馈调整参数，使获得较高奖励的行为在后续训练样本中更有机会出现。当这类强化学习利用人类反馈时，常称为基于人类反馈的强化学习（Reinforcement Learning from Human Feedback，RLHF）。人类可以比较回答，再由奖励模型把这些判断用于更多训练样本；最终的参数更新仍由训练程序完成。

奖励设计会决定优化往哪里走。如果只核对答案中出现的数字，“8%”与“8 个百分点”可能被粗糙的检查器同样放过；如果检查数值、单位和解释，信号就更接近这道题的要求。下面的模拟可以切换评价标准，观察同一批候选的得分变化。真实 RL 还要把奖励转成参数更新，过程远比这个小例子复杂。

2022 年 InstructGPT 展示了一条具体路线：收集人工示范进行 SFT，再收集回答排序，训练奖励模型，并据此做强化学习。论文帮助解释了对话助手为什么需要专门学习怎样响应用户意图。今天的后训练可以使用不同的数据来源和优化方法，SFT 与 RL 的先后顺序也随方案而变。[3]

训练知识的时效同样取决于数据与更新。参数中的信息可能来自预训练，也可能在后续训练中被补充或改变；标称“知识截止日期”只是理解覆盖范围的参考。产品若临时检索了最新网页，也能据此回答近期问题。要判断新知识从哪里来，可以分别查看模型版本和这次请求使用的资料。

1.4 两种“推理”：运行模型，与解决问题

中文资料常把 model inference 和 reasoning 都译作“推理”，它们却指向不同层次。model inference 指利用训练好的模型，对输入执行计算并得到输出；reasoning 指从条件出发进行推导、比较、规划或问题求解。让模型续写“您好”，也在进行 inference，却未必涉及复杂 reasoning。推理模型同样需要通过 inference 才能运行。

以常见的自回归 Transformer 为例，一次运行通常包括两个阶段。Prefill（预填充）处理已知输入，建立内部状态，并利用最后位置的输出预测第一个新 token。因为输入内容已经存在，多个位置可以并行计算，同时各位置仍受因果遮罩限定。Decode（解码）则不断生成新 token。后一个 token 依赖前一个结果，常规生成路径因此包含连续的步骤。

这解释了两种不同的等待体验：上传很长的材料后，要等一会儿才出现第一个字；回答开始后，又以一定速度逐步输出。前者常与输入处理、排队及其他准备工作有关，后者与生成过程有关。界面上的“思考中”还可能包含检索、工具调用或产品展示策略，要分辨时间花在哪里，需要查看对应的执行记录。

1.5 为什么运行也需要算力：GPU 与 KV Cache

每次回答都要实际运行前面那条网络计算链。以向量和矩阵相乘为例，一个输出数值可能要把许多输入分别乘以权重，再相加；一个输出向量包含大量这样的数值，网络又有许多层。GPU拥有大量并行计算单元，适合同时做这些重复的数值运算。它的高带宽显存还可以快速提供计算所需的数据，因此常用于大规模模型服务。CPU 和其他加速器也能完成这些计算，适合哪种硬件取决于模型规模和服务要求。

一个容量例子能让数字具体些：70 亿个参数，每个按 16 位即 2 字节保存，仅权重就约需 140 亿字节，也就是十进制的 14 GB。运行时还要留空间给中间结果、KV Cache 和其他开销。较低精度存储可以减少一部分占用；长输入或同时服务更多请求，则会带来新的内存需求。

算力、显存容量和显存带宽分别回答“算得多快”“装得多少”“搬得多快”。Prefill 时，多段已知输入位置可以一起处理，较容易组织成大批矩阵运算；Decode 时，一个请求每轮只产生少量新位置，却仍需访问本轮计算所用的权重和历史状态。在小批量生成中，数据供给速度常常成为瓶颈。合并多个请求可以提高计算利用率，同时也会增加状态占用和调度需求。[4]

KV Cache在这里起到复用作用。生成新 token 时，需要利用前文的 K、V；已经计算好的历史状态可以保存下来，下一步直接读取，只为新增位置计算新的状态。这样省去了反复计算历史位置的工作。生成依然需要经过各层计算并访问缓存，所以长上下文还会增加读取和存储负担。缓存中保存的是网络中间张量，含义与可供人阅读的事实摘要不同。

下面以 8 个输入 token、8 个输出 token 演示。Prefill 处理输入，预测第一个输出；接着把刚生成的 token 送回网络，预测第二个，如此继续 7 次。完成时已处理的不同位置共 15 个：原输入 8 个，加上用于预测后继输出的前 7 个输出。最后一个刚输出的 token 尚未被送回网络。这也是模拟中缓存位置数为何比输入和输出总数少 1。

复用还可以发生在不同请求之间。若后续请求具有相同前缀，并满足模型版本、缓存匹配和生命周期等实现条件，服务可以复用对应 KV 状态，减少重复的 prefill。前缀缓存（prefix caching）因此适合反复处理相同说明或长文档的场景。新问题对应的回答仍要继续生成，原有前缀也仍属于逻辑上下文。缓存是否生效、保留多久，由具体服务决定。[5]

1.6 CoT 与 reasoning：中间步骤如何帮助求解

1.3 节的题目直接给出余额 100 和 108，写出增长公式就能回答。现在把题目改成：“余额起初为 100，先增长 20%，再下降 10%，最终余额和相对最初的增幅各是多少？”这次需要先确定每一步的计算基数。直接把 20% 减去 10% 会得到 10%，而第二次变化实际上发生在已经增长的余额上。

思维链（Chain of Thought，CoT）通常指以一串中间推理步骤组织求解。在生成过程中，已经写出的中间结果会进入后续计算的条件。模型写出 120 后，下一步可以围绕 120 展开；再写出 108 后，就有了计算总增幅的材料。分步过程把一个问题拆成了可继续使用的小结果，也使“第二次到底以什么为基数”这类错误更容易被检查。

2022 年的 CoT 论文研究了在提示中提供带中间步骤的示例，发现这种方法改善了所测试的大模型在算术、常识和符号推理等任务上的表现。上面的例子说明了为什么这类提示可能有用；真实任务能改善多少，还取决于模型与问题。后来推理模型的训练进一步学习求解策略，例如怎样分解问题、回头检查或尝试另一条路线。[6]

测试时计算：把额外计算用在哪里

测试时计算（test-time compute）指运行模型解决任务时投入的计算。一个方向是沿同一条路线多做几步：分析条件、计算、检查，并在发现问题时修正。另一个方向是生成多个候选解法，再进行选择。仍用上一图的题目：一种解法逐次更新余额，从 100 到 120 再到 108；另一种把两次变化写成因子相乘，1.2 × 0.9 = 1.08。两条路线各自完成求解，比较最终结果可以互相核对。Self-Consistency 研究则进一步探索多条路径的汇总：让模型对同一题独立采样多条推理路径，每条路径得出一个最终答案，出现最多的答案相当于获得最多票数，以此作为汇总结果。候选之间仍可能共享同一个错误，因此票数本身也需要结合任务判断。[11]

还可以把计算用于验证。对于这个例子，系统能运行算式检查数值；对于程序任务，能运行测试并把失败信息交回模型。一次候选生成、一次外部验证、一次据反馈修订，可以共同组成求解过程。这条路线会在第三章与 Agent 循环接上。额外计算是否值得，要看它增加了多少正确率，以及带来了多少等待与资源消耗。

产品呈现的思考摘要帮助读者了解大致进度，可检查的步骤则帮助判断解答。模型内部还有大量向量计算，其完整因果过程无法从一段自然语言解释直接读出。实际评估应落到条件是否用对、中间结果是否成立、结论是否回答了问题。这道题里，只要把第二次下降的基数误写为 100，语言再流畅也会算错。

1.7 幻觉怎样出现，又怎样核对

幻觉（hallucination）指模型生成了看似合理、实际失实或缺少所需依据的内容，例如编出一条条文、错配一个年份，或把资料没有支持的判断写成确定结论。回答的语言形式可以很完整：专业术语、机构名称和引用格式都齐全，问题出在这些文字对应的事实与证据。

这与前面学过的机制相连。预训练的重要任务是根据前文预测原文接下来的 token，由此学到语言模式和大量知识；资料中哪些具体陈述适用于眼前业务，还要靠当前证据判断。当问题要求给出精确答案，而可用信息不足时，模型可能把熟悉的术语、数字形式和解释套路组合成一段流畅内容。一旦未经核实的判断已经写出，后续生成又会以它为条件继续展开，错误便可能延伸到解释和引用中。

检索和引用有助于把判断落到材料上。拿到来源后，还要核对所引段落是否确实支持这句话，版本、时间和适用范围是否吻合。检索漏掉修订文件，或模型把正确片段接到错误主张旁，仍会造成失实回答。证据充足时可以明确作答，证据不足时则保留缺口，并据此继续查找。

训练目标用于调整模型行为，业务验收检查具体任务是否完成且有依据。在“余额 100 增至 108”的练习里，答案数字正确是一项训练信号；实际分析还要确认余额口径、期间和单位。沿着“依据—方法—执行—结论”往回看，能把资料缺口、计算错误和生成失实分别定位。

每次回答的质量还取决于模型眼前的信息。第二章打开一次请求的上下文，看看提示词、知识库和记忆怎样进入模型。

第二章　模型上下文里都有什么：提示词、知识库、记忆和上下文工程

同一个模型，为什么在陌生问题上泛泛而谈，拿到几页资料后却能分析得有模有样？第一章解释了它的能力从哪里来。本章打开一次请求，看看它此刻获得了什么信息，以及这些信息是怎样被选进来的。

2.1 Context 是本次工作材料，context window 是容量边界

上下文（context）是模型生成时可利用的当前输入信息。在文本对话里，它通常包含指令、历史消息、参考材料，以及系统补充的信息；多模态模型的上下文还可能含图像、音频等表示。你在输入框里刚打出的那句话，往往只是其中一小部分。模型继续生成时，已经生成的 token 也会成为后续生成的条件。

上下文窗口（context window）描述模型能够处理的序列长度上限，通常以 token 计量。文件可以长期存在硬盘或知识库里，窗口则限制一次运行能使用多少信息。一次请求要为输入和接下来的生成安排预算；具体产品还可能分别限制输入、输出，以及推理 token 的使用方式。查看窗口规格时，需要一起看这些额度怎样分配。

为便于理解，假设模型 A 只有 10,000 token 的总预算，指令和对话历史占 2,000，参考资料占 6,000，那么留给本次继续生成的空间就少了。真实系统会在接近限制时选择拒绝请求、截断、压缩，或只装载部分历史，具体行为取决于实现。聊天页面仍然显示的内容，不一定全部出现在每一次模型调用中。

2.2 拆开一次请求：输入框后面还有什么

设想你问：“结合上次讨论，解释这季度净息差的变化。”在调用模型前，应用可能先找出上次讨论的摘要，再读取报表、选取相关方法说明，最后把这些内容连同你的问题组织成请求。这个组装过程可以叫 context assembly（上下文组装）。你只输入了一句话，模型实际收到的材料可能有好几页。

应用会按任务选择其中的内容。比如只问“净息差是什么意思”，读一段指标定义就够了；要解释某家银行的变化，则还要取回期间一致的数据。回答有问题时，可以沿着材料的路径检查：文件是否读入、相关片段是否选中、摘要是否保留了条件，以及模型如何使用这些内容。这样能区分资料准备出了问题，还是模型理解出了问题。

2.3 Prompt：把意图变成可执行的输入

提示词（prompt）是引导模型完成任务的输入。这个词有宽窄两种用法：有人把发给模型的全部输入都叫 prompt，也有人专指其中的任务指令。本书讨论提示工程时，主要指目标、约束、背景、示例与输出要求如何表达；讨论上下文时，则关注这一整套信息以及它的动态变化。

提示词首先要说清楚打算拿模型的回答做什么。“分析这份材料”可能意味着摘要、找问题、做比较或写建议。换成“面向未读过原文的同事，解释两份材料的分歧，并区分事实与推测”，读者、任务和证据要求就具体了。示例还能展示难以用规则说清的风格，这与第一章的上下文学习相连。

提示工程与上下文工程紧密相关；按本书的用法，前者是后者的重要组成部分。前者关注怎样表达要求；后者还要决定取哪份文件、加载多少历史、何时调用检索、保留哪些结果。用户把问题写得再清楚，如果系统塞入过时资料或漏掉关键附件，模型仍可能答错。反过来，材料齐全但任务含糊，也容易得到一篇正确却无用的长文。

2.4 Knowledge：参数知识、外部知识与眼前证据

说“模型有知识”时，至少要区分三个位置。参数知识来自训练，分布在模型权重中，支持语言和概念运用；精确查原文通常要借助外部资料。外部知识存放在文件、网站、数据库或知识库里，可单独更新。本次证据则是从外部材料中实际送入当前上下文的内容，模型可以在回答时引用、比较和推断。

制度文件在确认数据分级、所用平台与账号、用途和留存方式均符合机构要求后，才进入上传与处理环节。应用通常会保存文件、提取文字，有的还会建立检索索引。涉及内部资料时，应使用获批环境；未经批准，不将资料传到外部 AI 工具。提问时，系统读取全文或取回相关片段，把它们放入模型当前输入。模型据此解释新制度，更新的是本次回答所用的材料；训练权重是否更新，则取决于是否另行进行了训练。产品所列的知识截止日期，帮助我们估计参数知识的时效。若要核实某条具体规定，仍要查它的原始发布文件、修订日期和适用范围。

三个位置可以协作：参数知识帮助模型理解“净息差”这个概念；外部报表提供特定银行的数字；进入上下文的报表片段提供本次分析依据。若从参数知识中学到的常见说法与当前有效文件冲突，应结合来源、日期和适用范围判断，不能因为模型语气肯定就采纳旧说法。外部文档也可能有错，因此“有引用”提供的是可检查的线索，而非正确性的保证。

2.5 RAG：回答之前，先找相关材料

检索增强生成（Retrieval-Augmented Generation，RAG）把检索得到的外部材料用于生成回答。2020 年的 RAG 论文研究了参数模型与外部可检索知识结合的方法；今天，这个词还广泛用于“先检索，再把证据交给模型回答”的系统设计。[15]

可以把常见的文档 RAG 分成两段工作。建索引发生在资料入库或更新时：系统解析 PDF、网页等文件，按段落或章节拆成片段（chunk），保存来源和日期，再建立便于查找的索引。查询发生在用户提问时：系统检索候选片段，筛选、排序，把选中的内容连同问题交给模型。原文一般仍保存在文件库里，索引负责帮助系统找到它。

切片大小会影响后面的每一步。假设一段规定先写“住宿上限为 500 元”，下一句又写“仅适用于 A 类城市”。若两句被拆开，检索只返回第一句，回答就容易漏掉适用范围。若整本手册都算一个片段，每次又会带回大量无关材料。因此，切片常要照顾标题层级、完整条款和表格结构，必要时保留相邻内容。

Embedding：把句子变成可以比较的向量

Embedding（嵌入）是将信息编码为一组数字。第一章里，token 的向量表示用于模型内部计算；这里通常由嵌入模型把一段文字编码为检索向量。资料片段可以预先编码，提问时再用兼容的查询编码方式生成问题向量，随后比较它们的相似度。Sentence-BERT 等研究说明了怎样训练可用于语义比较的句子表示。[21]

看一个二维的例子。问题“为什么存款利率下降？”用向量 Q = (1, 0) 表示；现行片段 A“资金价格下行”为 (0.95, 0.31)，现行片段 B“存款成本率口径”为 (0.8, 0.6)；旧版片段 C“存款利率下降与存款成本率”为 (1, 0)，片段 D“办公楼租金”为 (−0.6, 0.8)。这些数字由编者手工设置，下一项检索交互也使用同一组候选。

余弦相似度比较向量的方向。Q 沿着第一维，与 A 的相似度为 0.95 ÷ √(0.95² + 0.31²)，约等于 0.951。实际系统使用模型生成的完整向量进行计算。这些向量表示由模型训练得到，因此换嵌入模型、换语言或换任务，都可能改变检索效果。语义接近只说明值得进一步阅读；一句“利率没有下降”也可能与“利率下降”很接近，最终仍需核对具体说法。

关键词、语义、混合检索与重排，各自做什么

问“存款成本率的定义是什么”，原文里的“存款成本率”很有辨识度，关键词检索可以直接找到定义条目。问“资金为什么变便宜了”，相关材料可能写的是“付息成本下行”，语义检索就有机会找回这段用词不同的解释。混合检索把两路候选合并，再按分数或名次等方式排序，以兼顾精确词语和语义关系。[16]

重排（reranking）发生在初步检索之后。一种常见方式是把“问题 + 某个候选片段”一起交给重排模型，逐项评估它对问题有多大帮助。与预先算好片段向量、提问时快速比较相比，这一步能更细地考虑问题和片段之间的关系，计算成本也较高，因而常用于前几十个候选，而非对整个资料库逐条执行。[22]

版本适用性可以单独处理。假设旧版“存款成本率口径”的词语匹配很好，但查询问的是今年现行口径，系统就可以依据生效日期、失效日期和业务范围先缩小候选范围，再检索或排序。若问题改成“比较去年与今年的口径变化”，两版都应保留。过滤解决适用范围，相关性排序解决哪段更有帮助；二者配合才能把合适证据送入上下文。

有时第一轮查回的材料只解决一半问题。例如解释成本变化，还需要补查存款结构。这时谁来决定下一轮查什么？第三章会把检索放进 Agent 的行动循环。

2.6 LLM Wiki：把读过的资料整理成可以继续使用的知识

查到一段资料，可以解决眼前的问题；读过几十份相关材料后，人们往往还希望留下一份整理结果。LLM Wiki就是让大模型协助维护互相链接的知识页。Karpathy 在 2026 年 4 月发布构想，用原始资料、整理后的 Wiki 和组织约定来描述这种做法。它是一种知识管理实践，具体目录、页面和维护流程可以按任务调整。[17]

用一个虚构的公司资料库来看。2025 年公告说“零售业务包含消费金融”，2026 年公告宣布“消费金融调整为独立报告分部”；两份公告中的统计表也随之变化。只保存两个摘要，读者仍要自己拼出影响。Wiki 可以把这些信息整理到“消费金融”“报告分部”“历史口径变化”三页，每页回答一个相对稳定的问题。

双向链接可以直接写在相关页面上，也可以由阅读软件根据已有链接显示“哪些页面提到了我”。这样，阅读“消费金融”时能找到分部分类；打开分类页，也能回到涉及的业务。链接连接的是文件和概念，效果取决于页面内容是否准确、关系是否有用。

新公告到来时，维护工作包括核对和修订。若旧页写“消费金融属于零售业务”，应把它改成带时间范围的陈述，并补上调整后的归属；相关比较表也要检查。若两份同期材料相互冲突，则先保留各自出处、注明分歧，继续查找解释。直接用新摘要覆盖旧摘要，可能把历史分析需要的口径一起删掉。

Wiki 与 RAG 可以一起工作：系统先检索主题页，从已有整理了解问题，再沿原文链接核对；也可以直接在原始公告中检索。前者节省重复梳理的工夫，后者更接近证据细节。知识页适合积累，维护时仍需检查日期、引用和关联页。资料集很小时，仅用清楚的目录和原文可能就已经足够。

2.7 Memory：保存过去，选择什么带到现在

记忆（memory）通常指系统保存并在后续使用的交互信息。应用可以保留会话历史，保存尚未完成的任务进展，也可以把偏好和经验写入跨会话存储。会话级状态同样可以持久保存，供下次打开任务时恢复。保存的范围、写入时机和取回方式由产品实现决定。[18]

记忆如何生效，可以顺着一条具体记录看下去。假设用户在报告任务里说：“以后给新同事写说明时，请把缩写解释一遍。”一个支持长期记忆的系统，可能经历以下过程。这个例子描述可采用的设计，具体产品未必有完整的所有步骤。

任务状态也可以按类似方式保存。研究一份报告做到一半，系统写下“已读 A、B 两份材料，C 尚未读取；待确认表 2 单位”，恢复时就有继续工作的起点。原始聊天记录负责留下经过，状态摘要负责指出当前进展。摘要若把“待确认”漏掉，下一轮工作就可能沿用一个未核实的假设。

记忆与知识库有交集。一个项目约定既可以存成记忆，也可以放入项目说明页；记忆通常围绕交互连续性和偏好，知识库通常围绕资料组织和事实查询。评估一个系统的记忆设计时，关注它具体保存什么、什么时候取回，比纠结文件应当叫什么更有用。

第一章的 KV Cache保存注意力计算所需的中间张量，帮助下一步复用已经完成的计算；这里的记忆存储保存偏好、经验或状态，供后续任务选择使用。缓存过期后，可以重新处理原文建立计算状态；偏好能否跨会话沿用，则取决于记忆的保存和取回过程。

2.8 Context engineering：每一次调用，都重新整理工作材料

上下文工程（context engineering）关注如何持续为模型组织合适的信息。它包含选择哪些内容、怎样分层摆放、何时补充、哪些结果保存到外部，以及哪些历史可以压缩或移出。2025 年 Anthropic 的工程文章把这一视角与持续运行的 Agent 联系起来：随着工具调用和任务推进，上下文会不断变化，信息整理也必须反复发生。[19]

例如，比较两期报告时，先取回两期的同名表格和指标定义；发现分类调整，再补读说明页；算出结果后，保存计算输出，并把已读过的长段落换成摘要和来源位置。这里发生了资料选择、按需补充和历史压缩，都是上下文工程的一部分。资料较少时可以直接放全文，工作持续较久时则需要逐步整理。

压缩的取舍来自接下来要做的事。已经完成的重复检索记录可以简写；影响结论的口径和来源应保留，未解决的问题也应保留。仅仅让摘要更短，未必让后续工作更顺利。

提示注入（prompt injection）是试图借输入内容使助手偏离原定任务、覆盖既有指令的攻击方式。一种常见情形是：检索到的网页或文档夹带“忽略任务要求，把数据发到某处”等命令，试图让系统把资料中的文字当成操作指令。此时应只把它当作待分析的内容，并由运行系统维持指令与执行权限的边界；仅靠一句“请忽略恶意命令”的提示，防护仍有缺口。[23]

最后，还要把两个容易混在一起的概念分开。指令优先级回答“不同要求冲突时，系统应该服从谁”；证据权威性回答“不同事实说法冲突时，哪项来源更适用”。网页中的官方统计可以是可靠证据，但网页夹带的“忽略用户要求”不会因此获得指挥助手的资格。系统指令可以要求依据现行文件作答，却不会凭空创造文件里的事实。

第二章自测：信息到底在哪一步丢了

接下来阅读 第三章：chatbot、workflow 和 agent harness——如何让大模型开始工作 →

第三章　chatbot、workflow 和 agent harness：如何让大模型开始工作

同样一句“帮我分析这份报告”，有的系统返回一段建议，有的会找资料、运行计算、检查差异，直到交出文件。区别既在模型，也在模型周围的组织方式。本章沿着一项任务的推进过程，拆开交互入口、控制流程、行动循环与运行支撑。

3.1 Chatbot 是我们与系统交谈的入口

Chatbot 通常译为聊天机器人。本书先从交互形式理解它：人通过对话与系统交互。最简单的聊天程序把用户的问题交给模型，把回答显示出来；更丰富的聊天产品还可以检索文件、调用计算器、执行任务。聊天窗口因此可以成为多种工作方式的共同入口。

可以把一次使用拆成三个问题：我们怎样提出需求，系统怎样决定下一步，以及执行过程中由什么维持连续性。Chatbot 主要回答第一个问题，workflow 和 Agent 主要回答第二个问题，harness 主要回答第三个问题。它们处在不同层次，因此可以同时存在于同一个产品里。

模型名称也需要放对位置。Claude Opus 是模型系列；Claude Code 是能够调用模型并操作开发环境的产品；harness 指组织模型调用和执行过程的运行支撑。比较 Opus 与另一个模型，可以讨论能力；比较 Claude Code 与另一个 Agent 产品，还需要比较工具、上下文管理、执行环境和交互方式。评估实际任务时，模型能力和这些运行条件需要一起看。

3.2 Workflow：先规定任务可以怎样流转

Workflow 是预先设计的任务流程。它规定哪些环节可以发生，以及满足什么条件时转到哪个环节。例如，收到一份材料后，先提取字段，再检查缺失，资料完整就生成摘要，否则返回补充请求。流程可以是直线，也可以有分支、循环和并行步骤。

流程可以预先规定，其中某些步骤交给模型完成。“判断材料属于哪一类”可以由模型完成，“按类别选择分析模板”可以由普通程序完成，“生成解释”又可以调用模型。模型给出的分类或文字可能存在波动，但系统允许经过哪些节点，通常已由开发者定义。这是理解 workflow 最有用的角度。

Anthropic 在 2024 年的工程文章中，用“预定义代码路径”与“模型动态决定推进方式”区分 workflow 和 Agent。本书沿用这个划分来解释系统结构。真实系统往往混合使用两种方式：大流程固定，某个资料调查环节由 Agent 自主推进。[24]

Workflow 的价值在于路径清晰、接口稳定、容易定位失败环节；代价是要提前覆盖可预见的情况。Agent 允许现场选择路径，但也增加了选择错误、重复尝试与成本失控的可能性。路径稳定的任务可以保留固定流程，需要调查未知情况的环节再引入动态决策。

3.3 Agent：让观察结果影响下一步行动

本书中的 Agent 指围绕目标，通过模型参与决策并使用工具、依据环境反馈持续推进任务的系统。一个典型循环是：收到目标与当前状态，模型提出行动，系统执行行动，取得结果，再将结果交给模型决定继续、调整或结束。复杂行为由多次模型调用和环境交互串联起来。

假设系统要找到某条指标的最新版定义。第一次搜索得到旧文档；模型注意到发布日期不符，于是改用新的年份搜索；第二次得到更新通知，又沿通知读取附件；最后对照定义后回答。在这个过程中，用户给出的是查清定义的目标；模型根据旧文档、更新通知和附件逐次选择下一步。

模型在循环里负责理解与提出动作，运行系统负责把动作落到工具，并提供结果。模型也可以提出“任务完成”，但可靠系统还要依据任务标准检查完成状态。若目标是生成文件，完成条件可以包括文件已保存、内容齐全，以及必要检查已经通过。

3.4 Plan 与 ReAct：组织任务和随反馈调整

Plan 是计划：把目标拆成步骤，列出依赖、待核实问题与完成条件。计划既可以由人给出，也可以由模型生成，再保存在任务状态中。它的作用是使长任务有方向，并把尚未解决的问题留在视野里。计划本身仍然可能漏项或建立在错误假设上。

ReAct 把 reasoning 与 acting 放在同一推进过程里，强调推理、行动、观察之间的交替。原论文在 2022 年提出这一方式：推理帮助选择行动，行动获得的信息再帮助修正后续判断。这个名称指推理与行动交替的模式；在界面中，可以用行动理由、工具记录与阶段结果呈现进度。[26]

Plan 与 ReAct 可以组合。先列“找定义—找数据—核口径—写结论”的计划，再在“找定义”这一步根据搜索结果连续调整查询；如果发现前后两期采用了不同统计范围，就重新安排“核口径”，甚至暂停原来的比较。高层计划保持目标，局部循环应对未知。

这里也能看出 CoT 与 Agent 的差别：在一次模型响应中写出若干推理步骤，并不必然发生外部行动；反过来，Agent 可以执行多轮工具调用，而界面只呈现简要理由与进度。阅读执行过程时，可以沿着来源、行动与结果检查系统做了什么。界面上看得见的说明，长短受产品如何展示过程影响。

3.5 Harness：使一次次模型调用成为连续工作

Harness 可以理解为 Agent 周围的运行支撑。它负责启动模型调用、接通文件访问等工具、等待工具和保存进度。软件决定何时调用模型、给它哪些信息、怎样执行动作、接到错误后怎么办，并在结束时留下可检查的结果。

它通常涉及上下文组织、工具路由、任务状态、执行环境、错误处理、时间与调用预算。这些安排共同决定任务怎样持续运行，权限控制也在其中。相同模型如果得到更清楚的工具反馈、更完整的阶段产物和更有效的恢复机制，就可能完成原先做不完的任务。这种提升不要求改变模型权重。

当任务跨越多个上下文窗口时，状态尤其重要。对话记录回答“之前说了什么”，任务状态回答“现在做到哪里、哪些结果已验证、哪些事情仍未完成”。压缩上下文时，需要保留目标、关键决定、有效证据的位置与下一步；完整文件可以继续放在外部环境，必要时再读。压缩会丢失细节，保留下来的原始产物可供后续重新核对。

Anthropic 在 2025 年 11 月的长任务实验中，使用初始化与后续增量工作的安排，并用任务记录和产物帮助跨会话衔接。这是一种适合该实验任务的衔接办法；其他系统可以采用不同的状态存储与恢复方式。[27]

3.6 Agentic RAG：让检索也参与行动循环

第二章的基础 RAG 是“检索相关材料，再据此生成”。Agentic RAG 把检索放入动态决策过程：先判断需要什么证据，再选来源和查询方式；读到结果后检查是否足够，必要时改写查询、拆成子问题或补查其他来源，最后综合回答。这里的 agentic 描述检索流程的组织方式，所用模型与检索设施可以有多种组合。

例如，要比较两个时期的流动性指标，直接搜索指标名可能已经能找到数字，但无法说明口径是否相同。系统可以进一步找附注：若定义变化，再寻找可比数据；若只有一方披露，明确留下缺口。新的检索由当前证据暴露的问题触发。研究型 Agent 的工程实践提供了多步搜索与资料综合的例子；本书把这种可调整的取证方式概括为 Agentic RAG。[28]

循环需要停止条件。目标中的问题已获得充分证据、合理搜索后仍有资料缺口，或预算已到上限，都可以触发停止，但最终回答应说明是哪一种。否则系统可能不断改写查询，获得大量相似材料，却没有增加有效证据。对一个有明确答案和固定来源的问题，简单 RAG 往往已经足够。

3.7 把 Agent 当初级员工：理解交接，也理解边界

“初级员工”是一个有用的工作比喻：给清楚的目标和背景，允许完成中间步骤，查看产物并提供反馈，由它安排中间动作。交接时说明背景、资料位置与完成条件，系统才能把这些要求带入后续动作。

这个比喻也有适用范围。Agent 的常识与任务判断来自模型及当前信息，经历的连续性则依赖系统保存和取回状态。它可能在难题上表现惊人，又在简单文件路径或过期口径上犯错；不同任务的能力分布也不均匀。一次演示展示了一条成功路径；换一批材料后是否稳定，需要继续观察。

训练损失描述模型对训练目标的拟合，业务验收则检查具体任务中的事实、口径、计算和执行结果。可靠性应通过代表性的任务集合衡量：是否完成目标，结果是否正确，证据是否可追溯，花费多少时间与调用，有没有不必要的人工补救。需要看多次运行的表现，也要保留失败案例。例如，一份说明写得流畅，却引用了旧版指标定义，评估时就应记录为证据使用问题。对 Agent 的评估通常同时查看执行轨迹与实际结果。[29]

继续阅读 第四章：工具与 Skill 如何扩展行动能力。

第四章　agent 的工具和 skills：给 agent 配上手脚

第三章把工具看作 Agent 能够采取的动作。这一章放大一次动作：模型如何提出调用，软件如何执行，Skill 又怎样提供任务方法。最后再看系统的改进发生在哪里，理解“记住了”“学会了”与“递归自我改进”之间的距离。

4.1 Tool：把语言判断接到外部世界

Tool 是系统提供给模型使用的外部能力。搜索工具获取资料，文件工具读取或写入内容，计算工具执行公式或代码，浏览器工具观察页面并进行操作。它们的共同之处，是让任务获得模型生成文字之外的输入或结果。

工具扩展能力有两条路径。一条是获得信息：读取最新文件、查询数据库、观察屏幕，使模型接触训练时没有见过的材料。另一条是执行操作：让程序计算结果，或把文件写到指定位置。工具执行依赖运行环境与权限。例如，发送邮件需要可用的邮件接口、账号连接和相应授权。

使用计算器时，选择公式与确认输入仍由任务分析决定。假设模型把年利率误当成月利率，计算器可能非常准确地算出一个基于错误输入的结果。计算器这类工具能让特定运算更稳定、可复现，仍需要正确的问题、参数、口径和结果解释；检索和其他工具也可能返回不完整或错误的结果。错误可能出现在动作选择之前，也可能出现在返回结果之后。

读写能力还需要区分。查询一份报表主要改变系统掌握的信息，覆盖一份报表则改变外部状态。因此，执行记录可以列出所用工具、读取内容、外部改动及返回结果。取得工具结果后，模型再根据任务要求解释或继续处理。

4.2 Function calling 与 MCP：提出请求和接通能力

Function calling 是模型以结构化方式提出工具调用请求的一种机制。系统先给模型可调用工具的名称、用途和参数约束；模型依据任务，输出要调用的工具以及对应的输入值；应用或运行平台执行对应程序，再把结果送回模型。随后模型可以生成回答，也可以提出新的调用。[30]

例如，工具说明“查询指标值”需要指标名和日期。模型输出的请求可能是“指标=某余额，日期=某月末”。运行系统拿到这份请求后向数据源查询，再将数值、单位、统计范围与时间返回模型。一次调用因此留下请求、执行结果和后续处理三个可观察的部分。

MCP，即 Model Context Protocol，是让应用与外部能力提供方交换信息的一套开放协议。使用者面对的应用是宿主（host），它通过内部的协议客户端（client）连接能力服务端（server）；服务端可以提供工具、资源和提示模板。MCP 主要约定能力如何被发现、调用以及返回结果。任务如何推进，由应用的流程或 Agent 决策；应用也可以直接调用自有接口。[31]

把两者放在一次请求里看更清楚：模型通过 tool calling 提出“读取文件”；运行系统把它路由到相应接口；如果接口由 MCP server 提供，调用与结果便沿 MCP 通信。前者关注模型如何表达行动，后者关注系统之间如何交换能力与结果。连接建立后，系统可以按需选择工具、读取资源，再将选出的结果交给模型。

4.3 Skill：把可复用的方法和资源带到现场

这里的 Skill，主要指 Agent Skills 这类可被兼容的 Agent 发现和加载的能力包。它通常以目录组织，以 SKILL.md 提供名称、适用说明和任务指导，还可以携带参考资料、模板与脚本。脚本和其他资源按任务需要附带。[32]

Tool 让系统能够做某个动作，Skill 提供一套可复用的方法。例如，读取表格的工具可以告诉系统单元格里有什么；一份报告核对 Skill 可以提示如何查找版本、确认口径、处理差异并组织结果。Skill 所包含的脚本还可能承担具体计算，但执行它仍然需要实际运行能力。

加载 Skill 会把相关指导与资源带到当前任务中，模型继续使用已有权重处理它们。例如，Skill 指导先读取共享盘资料，实际读取仍依赖共享盘连接和文件权限。拿到资料后，模型要结合内容执行指导，并检查产物是否满足要求。

这些概念按主要角色区分，在具体文件与系统中可以组合。同一段指标定义可以出现在知识页和 Skill 参考资料里；同一份流程既可以作为给模型的说明，也可以被实现为固定工作流。关键在于：任务真正运行时，这段内容是在提供证据、给出指导，还是实际控制执行。

4.4 从发现到加载：为什么许多 Skill 能共存

如果每次任务都把所有操作手册放进上下文，窗口很快就会拥挤，也会带来无关指令的干扰。Agent Skills 使用渐进式加载的思路：先让系统知道有哪些 Skill、分别适合什么；任务匹配时读取详细指导；只有遇到具体需要，才读附带资料或运行脚本。[32]

可以把它想成先看目录，再翻相关章节，必要时打开附录。目录用于发现；正文提供详细指导；参考资料按当前步骤继续读取。不同产品如何列目录、触发匹配、缓存内容会有差异，本书讲的是这种组织原则。

这一机制把 Skill 与第二章的上下文工程连接起来：系统保存的资源可以很多，本次进入上下文的只需与任务相关的一部分。代价是选择本身也可能失败。如果描述太宽泛，系统可能误选；如果任务与描述用词差异很大，也可能漏选。因此，可以从发现、加载、理解和执行几个环节观察一个 Skill 在当前任务中的作用。

4.5 有工具与有 Skill：读懂一个小例子

设想一个系统已经有文件读取、计算和写入工具，任务是“比较两份同名指标表”。只有工具时，它具备取数与相减的能力，却可能不知道这项工作最容易错在哪里。如果加载的 Skill 提醒先确认数据期间、单位、统计范围和版本，它就多了一套可参考的方法。

实际运行时，模型需要把指导转化为动作：先读取表头与说明，再取相关数据；如发现单位不同，调用计算工具进行换算；最后写出对照结果。若遇到 Skill 没有覆盖的情形，还需要回到模型的一般能力与当前证据作判断。Skill 为任务提供方法，但执行质量仍要看具体结果。

同一个例子也说明，改善系统时，要按任务选择适合的机制。重复任务可能适合沉淀 Skill；稳定且要求严格一致的转换，可能更适合程序；一次性的开放问题，可能只需要清楚的上下文；需要经常更新的事实，可能放在知识库更合适。理解这些机制，才能判断改善发生在哪里。

对使用者来说，读懂一个 Skill 最重要的是知道：它针对哪类任务，带来了哪些方法和资源，依赖什么外部能力，哪些结果仍需核实。这些信息有助于判断它适合当前任务的哪一部分。

4.6 从积累经验到 RSI：系统究竟改变了什么

当一个系统越用越顺手，我们常说它“学会了”。但至少有几种不同变化：保存了你的偏好，增加了资料，改进了任务指导，修复了工具代码，或者真的通过训练更新了模型参数。它们都会影响表现，却使用不同机制，也有不同的验证方式。

RSI 是 Recursive Self-Improvement，本书译为“递归自我改进”。这里的“递归”强调：系统产生的改进又能改变系统后续进行改进的能力，形成反馈。要研究这样的循环，需要跟踪修改怎样影响后续改进过程，以及效果能否在任务中复现。

2025 年 5 月 29 日首次发布的 Darwin Gödel Machine（DGM）研究，提供了一个有边界的例子：在底层模型权重保持固定的实验中，编码 Agent 修改自身代码，并用编码任务评估变化；不同版本被保留和探索，用于寻找更有效的工具与工作方式。论文报告了在所用编码基准上的提升；实验在沙箱（与外部隔离的受控运行环境）中进行，并有人工监督。这一结果适用于论文所设置的编码任务和实验条件；更广泛、长期持续的自我提升仍需进一步研究。[34]

判断一个版本是否改好，需要看任务结果。如果系统只对已经反复见过的例子更好，可能是过拟合；如果它改变了评分规则却没改善任务结果，可能是指标失真；如果新版本提高成功率却把成本增加很多，就需要把分数与成本一起比较。持续改进需要稳定的比较条件、未参与修改的测试任务、成本记录和可回退的版本。新版本在实际任务中的结果变化，为是否采用提供依据。

回到 全书回顾，把模型、上下文、运行系统与能力扩展放在同一张图中。

看到一个 AI 系统，先分清它的四层

四章讨论的是同一个系统的不同部分。模型生成判断，上下文提供当前材料，运行系统推进任务，工具与 Skill 扩展行动能力和可复用方法。它们需要组合，也可以分别改进。

当助手表现变好时，可以先辨认三种变化。模型改进可能来自新的权重、训练方法或运行时求解方式；信息改进可能来自更准确的检索、更好的资料组织与记忆；系统改进可能来自工具、Skill、流程和错误恢复。现实产品经常同时改变几项，比较时可以保持任务与材料相同，逐项观察调整后的结果。

例如，同一份报表，昨天解释含糊，今天却答得很好：可能换了更强的模型，也可能只是补上了指标定义；能够连续修改代码，可能得益于模型能力，也离不开文件、执行工具和任务状态。更快则可能来自缓存或硬件。先定位变化发生在哪一层，再谈“更聪明”“更懂我”或“学会了”，判断会更准确。

把一项工作交给 AI 时，交接什么、核对什么

可委托的范围取决于已有资料、工具能力和岗位授权。下面以 ALM、司库与风险分析中的常见工作为例；所用资料须先符合序章的数据准入要求。

正式口径的认定、限额的设定与调整、交易指令和对外发布，都涉及机构授权和责任承担。系统即使具备执行接口，也要按对应流程使用。把“整理材料、提出建议、执行操作、批准采纳”分别说清楚，任务交接才完整。

需要回查名词或新闻节点时，使用下面的术语索引与发展时间轴。