Prompt、Context、RAG、Memory，模型的输入从哪里来？
你让助手比较两版产品指南。它输出了一张整齐的表，却把旧版限制写到了新版上。你补了一句“认真核对”，结果依旧。此时，究竟该继续改提示词，接知识库，还是给助手加记忆？
这几个选择会改变不同的东西。先把一次模型调用展开，问题就容易定位。
下面继续使用入门篇的 Atlas Notes 合成文档。A 版免费导出支持 CSV，B 版增加 Markdown，两版导出都要求联网。我们的任务是比较导出格式和共同限制。这些是教学材料中的设定。
一次回答之前，模型实际拿到了什么
把本轮上下文想成当前工作台。工作台上可能同时摆着任务说明、产品原文、前一次工具返回，以及需要参考的用户偏好。每样材料有自己的用途。
| 摆上来的内容 | 在这个任务中做什么 |
|---|---|
| “比较免费版导出格式，保留联网条件” | 给出目标与约束 |
| A、B 两版第一页原文 | 提供产品事实 |
| “已经读到 A，还需要取得 B” | 帮助接续当前工作 |
| 用户保存的“先给比较表，再解释” | 提供表达偏好 |
Context（上下文）描述这一次调用所携带的输入。 Prompt（提示词）在本文中侧重其中表达任务、规则和示例的部分。有些 API 或资料也会把整个模型输入称为 prompt，阅读时要先核对作者采用的含义。
这意味着，产品原文、历史消息和工具说明都可以参与上下文。工程上还要检查完整编码请求，因为工具定义可能通过独立字段发送。仅打开一份系统提示词文件，无法得知模型最终收到了哪些材料。
提示词怎样改变任务，材料怎样改变依据
假设两版原文都已进入输入，助手却混淆免费版与企业版。可以把要求写具体一些。
比较两版免费版的导出格式。
把共同的联网条件单独列出。
企业版能力另列，保留对应版本和原文依据。这段文字帮助模型注意比较口径。它本身没有提供任何新版产品事实。如果输入里只有 A 版，模型仍需取得 B 版原文，才能判断新增了什么。
同样，只把两份文档粘进去，却没有说明比较目标，模型可能花很多篇幅介绍与导出无关的功能。要求与材料各有作用，二者也需要相互匹配。
一次朴素的排查可以从这里开始。先检查问题是否说清楚，再检查回答所需的原文是否真的进入了实际请求。这样能把“表达没有引导好”和“压根缺少资料”分开处理。
看起来相同的答错，可能发生在不同位置
继续看“把旧版限制写到新版上”这个现象。为了说明排查方法，下面把输入条件分成三种教学情况。
第一种情况，两版原文都在，任务只写了“比较一下”。助手把免费版和企业版放进同一列，读者自然会误会。此时可以把比较对象、维度与输出要求写清楚，再观察同一份材料下的回答。修改提示词主要在改变任务的组织方式。
第二种情况，任务已经写清楚，输入却只有 A 版。你反复强调“准确”“不要遗漏”，仍然无法给模型提供 B 的原文。应该沿资料读取路径检查 B 是否取得、是否被截掉、是否误用了同名旧文件。继续叠加形容词，只会让一个缺资料的请求变得更长。
第三种情况，B 的正文也取得了，但整理阶段把“导出需要联网”压缩掉了。模型看见的便笺只有“B 新增 Markdown”，便可能写出过宽的结论。此时要修正的是材料在进入输入之前的选择与转述，原始检索结果本身可能完全正确。
三个案例最后都可能表现为表格中的一格写错，调整的位置却各不相同。一个可用的调试习惯，是同时保留用户问题、关键原文和实际请求的对应关系。先说明缺失发生在哪一段，再选择修改要求、重新取材或恢复被省略的条件。
还要留意问题有没有得到足够支持。材料只说“B 支持 Markdown”，可以支持一项存在性判断。要说“B 比 A 新增 Markdown”，还需要核对 A。比较、排名和“只有”这类表达，对资料覆盖范围的要求通常更高。
资料很多时，RAG 怎样参与这张工作台
只有两页指南时，直接读取就很合适。若资料库有数千份产品手册，每次全部装入输入会带来成本、延迟和噪音，此时需要先寻找相关材料。
RAG（检索增强生成）把检索接入生成过程。系统根据问题寻找资料，取得需要的内容，装进模型可用的输入，再生成回答。其基本思想可以追溯到 Lewis 等人的检索增强生成论文。原始论文
检索可以使用关键词、向量或混合方法。一个任务已经知道文档与页码时，直接读页也有价值。向量库是实现选择之一，是否值得引入，要看资料与查询特点。
对 Atlas Notes 而言，这条路径可以这样理解。
问题涉及离线编辑
→ 检索相关指南与页码
→ 读取命中的原页
→ 把原文和版本信息放进本轮上下文
→ 模型比较条件并组织回答其中，搜索摘要帮助定位，原页承担具体依据。若检索命中了 B，但后续输入只留下一个标题，模型仍然缺少比较所需的正文。若取回了过期版本，回答也可能建立在错误时点上。
因此，调好召回只是其中一步。还要追问选中的内容能否被读取、实际送入模型的是什么，以及它是否支持最终结论。
找到了相关内容，还要找到能回答这个问题的内容
检索往往按相似程度或词项匹配程度排列结果，用户问题却可能要求完整比较。二者之间需要一次有意识的检查。
假设我们用 Markdown 搜索 Atlas Notes。B 版直接提到它，容易被找到。A 版没有这个词，也就可能完全不出现在结果里。只读这一组命中，能够说明 B 写了什么，却无法完整比较两版的变化。任务已经指定 A、B 时，可以分别读取两份已知文档，再围绕相同字段整理。
另一个常见情况，是资料切得太小。搜索片段包含“支持 Markdown”，限定它的“免费版”“联网导出”却在上一段。模型即使准确复述当前片段，也可能把能力范围扩大。因此，选取片段时要考虑标题、相邻条件和版本信息能否一起保留。片段越长，单次能携带的候选越少，这是一项需要随任务调整的取舍。
| 读者要判断什么 | 应当额外检查什么 |
|---|---|
| B 是否支持 Markdown | 该句对应的版本、版本内套餐和适用条件 |
| B 相比 A 改了什么 | 两版是否都已取得，比较维度是否一致 |
| 两版是否都能离线导出 | 与导出有关的联网条件，避免套用离线编辑说明 |
| 哪些格式完全不支持 | 是否覆盖相关条款，搜索未命中能否代表明确否定 |
这些检查也解释了为什么“检索得分很高”不能直接变成“答案有充分依据”。排名用于安排阅读顺序，具体主张还要回到相应条款。没有命中时，系统可以继续换查询、读目录或沿已知文档回查。一次空结果只说明本次查询的观察。
公开示例中的检索器采用词项匹配，并在已允许的文档集合内搜索。它足以演示查询词怎样影响命中，也让读者容易检查整个过程。真实资料库若有同义词、多语言或长文档问题，可以再评估语义检索、混合排序与更细的切分方法。固定检索实现
长期记忆怎样参与下一次任务
现在用户明确要求“以后比较产品时，先给表格”。系统可以把这项偏好保存为长期记忆。下次研究开始时，先找到相关且有效的记忆，再把适用内容加入当前输入。
Memory（记忆）关注跨任务保存和再使用。Context 关注本轮输入。一次召回可以把二者连接起来。记忆存储与业务知识库有时会共用检索技术，但它们保存的对象和更新方式需要分别理解。
| 内容 | 下次使用前主要核对什么 |
|---|---|
| 用户偏好“先给表格” | 是否仍适用，本次是否另有要求 |
| 上次读过的指南 | 版本、来源和本次问题是否匹配 |
| 上次比较的结论 | 支撑条件是否变化，是否需要回到原文 |
把“B 版支持 Markdown”存下来，并不能保证未来的 C 版继续如此。用户偏好也无法证明产品能力。保留信息时，需要保留它的来源、范围和用途。
记忆还应允许纠正与遗忘。旧记录已经更新，后续输入却继续带着旧摘要，模型仍可能沿用旧偏好。真正影响回答的是最后进入本轮请求的内容。
知识库、记忆与微调，怎样按变化选择
“让助手知道更多”是一种笼统的产品愿望。落实到工程时，最好继续追问，究竟是什么需要变化，以及变化多久发生一次。
如果用户今天上传 B 版指南，下一分钟就要比较，当前任务直接读取很自然。资料要供许多任务反复查询时，再把它组织进可检索的知识库。我们希望保留的是可更新、可追溯的产品事实，文档身份与版本仍然重要。
如果需要记住用户偏好，例如默认先给表格，应考虑这项偏好怎样被明确保存、适用于什么问题、如何更正。用户在一次报告中说“这次只给结论”，也可以只是当前任务的局部要求。要长期积累哪些信息，需要有相应的产品行为与更新规则。
如果需要持续适配一种行为，例如在稳定任务中遵循特定输出习惯，可以评估提示示例、工具约束，以及合适条件下的训练。微调会改变参数中的行为倾向，投入还涉及数据整理、评估和后续维护。对于经常变化、需要逐条追溯的产品事实，运行时取得原文仍有独立价值。
这些方法也可以组合。一个经过领域适配的模型，可以同时检索最新指南、召回用户偏好，并接收本次明确要求。它们在不同位置发挥作用，设计时应分别说明什么负责更新、什么负责选择，以及读者最后怎样回到依据。
可以做一个很简单的思考实验。把同一个模型接到不同版本的原文，它能获得的信息就变了。把同一份原文交给同一个模型，改变比较要求，它关注的维度也会变。再加入“先给表格”的偏好，输出顺序可能改变。把这几种变化分开，讨论“更聪明”时就能说出具体想改善的部分。
四个概念怎样放在一起
它们之间存在包含和供给关系，可以用一份简化输入说明。
当前模型输入
任务与规则 ← 提示词
相关原文 ← 直接读取或检索取得
历史背景 ← 当前对话和适用记忆
最新观察 ← 本轮工具结果上下文工程要处理这些材料的选择、组织和维护，包括顺序、容量、回读方式，以及哪些信息值得继续携带。Anthropic 对上下文工程的讨论也将关注点扩展到提示词之外的整个输入维护过程。上下文工程说明
微调改变的是模型参数，与运行时取得原文处于不同层面。对于刚更新的内部指南，先检查能否取得正确版本通常更直接。对于特定行为的持续适配，才需要进一步评估训练方案和相应数据。
上下文能装得更多，为什么仍然需要整理
在这个案例里，最省心的输入似乎是把全部聊天、全部指南和全部记忆一起发给模型。资料量很小时，这确实容易实现，也方便人工检查。随着任务变长，容量、费用和阅读噪音会同时出现。
即使请求装得下，材料之间也可能互相干扰。旧指南与新指南混在一起，模型需要分清版本。用户几轮前的要求已经改过，输入仍要清楚呈现哪一项适用于当前任务。工具返回了一大页导航文字，相关条款却只有两行，保留整页也会增加选择负担。
整理上下文时，可以先分清三类内容。当前目标和有效约束应当容易找到。支持比较的原文需要保留身份和回读入口。已经完成、暂时无需展开的过程，可以压缩成简短记录，必要时再取得详情。
例如，早期已经读过 A，当前正在核对 B 的联网条件。工作便笺可以提醒“已经取得 A，B 的导出条件仍需回查”，并保留原页引用。下一次需要写最终表格时，再沿引用取得具体条款。这样既能减少重复携带，也让关键判断有机会回到完整依据。
整理同时付出了再次读取的成本，也依赖保存位置仍然可用。若只有两份短文档，直接保留全文可能更划算。任务长到需要选择和压缩时，应优先保护目标、原始条件与可回查性，再观察哪些内容确实可以暂时移出输入。
这里也能看到四个概念的连接。提示词说明现在要做什么，检索与读取供应相关原文，记忆补充适用背景，上下文构建把它们组织成这一次真正发出的请求。我们最终要检查的是这份请求里的内容关系。
在 Open ETF Agent 中观察一次
本文采用已发布的 v0.26.0。先按固定版本 README 准备 Node.js 26.8.1–26.x 并安装依赖，然后执行下面的离线例子。固定版本 · 当前使用入口
git clone https://github.com/hpoenixf/open-etf-agent.git
cd open-etf-agent
git checkout v0.26.0
npm ci --ignore-scripts --no-audit --no-fund
npm run build
npm run demo -- --case retrieve-reread --query "Markdown"终端会返回本次任务目录，里面有 report.md 与 run.jsonl。前者可以检查内容和来源，后者记录过程事件。Markdown 只命中 B 版，报告会保留这项覆盖限制。换成查询 offline editing，再观察命中的原页与报告依据怎样改变。
这个例子采用预设动作模拟模型选择，真实执行检索、读取和保存。它适合观察资料进入研究链路的机制。真实模型如何选择材料、是否理解正确，需要另外评价。检索与上下文实现
运行完以后，可以按同一问题对照两次输出。先找报告依据里出现了哪些文档版本，再看正文保留了哪些限定条件，最后回看过程记录中的查询与读取。Markdown 和 offline editing 的差异，能让“查询影响候选、读取提供原文、生成使用当前输入”这条链路变得具体。
还可以构造一张自己的排查记录，只保留三个问题。想比较的对象是否都已覆盖，模型实际可见的文字是否保留了关键条件，最终结论是否超出了这些条件。发现 B 没有读到时先补读，发现免费版与企业版混用时回到对应条款，发现输出顺序不合习惯时再调整表达要求。
这个观察方法也适用于工作中的合同、产品手册和内部制度。每个任务需要核对的条件不同，但都可以沿“问题、材料、当前输入、结论”逐段寻找变化。等具体位置明确后，再决定要改哪个环节，通常比同时更换提示词、检索器和记忆方案更容易解释结果。
当回答出问题时，可以依次检查四件事。任务要求是否具体，关键原文是否存在于本轮输入，检索是否取得了适用资料，旧记忆是否仍然合适。找到发生变化的位置，才知道下一步该调整什么。
接下来进入《Agent 进阶：读懂十个核心模块》，把这份输入关系接回实际代码。
延伸阅读包括 LienJack 的概念串讲，它启发了本篇对相近概念关系的选题。本文以 Atlas Notes 和公开实现重新组织案例与解释。Prompt、Context、RAG 到底是什么