什么是 Context
Prompt 是指令，Context 是模型本次看到的全部信息。
一句话理解：Prompt 是你写给模型的指令，Context 是模型在这一次调用里能看到的全部信息；模型只能根据看到的东西做判断，看不到的就等于不存在。
很多团队第一次做 Agent，出了问题的第一反应是“改 Prompt”。改了十几版，效果还是时好时坏。原因往往不在指令写得好不好，而在于模型 那一刻根本没看到做对这件事所需的信息：退款政策上周更新过，但检索到的还是旧版本；用户三轮之前说过“只看企业版客户”，这句话已经被截断；工具返回了 3000 行支付流水，真正关键的那一条淹没在中间。
这一课先把“Context”这个词讲清楚。后面整个模块都建立在一个判断上：Agent 的效果，大部分取决于每一步的上下文里放了什么。
先看整个模块的全景：信息从多个来源汇入，经过“五问”设计进入上下文窗口，再用一组管理手段让窗口保持干净。
Prompt 与 Context 不是一回事
| Prompt（指令） | Context（上下文） | |
|---|---|---|
| 是什么 | 告诉模型“你是谁、要做什么、怎么做” | 模型本次调用能看到的全部 Token |
| 包含什么 | System Prompt、任务描述、输出格式 | 指令 + 工具定义 + 对话历史 + 工具结果 + 检索到的文档 + 文件 + 模型之前的思考与输出 |
| 谁来写 | 主要由人提前写好 | 大部分在运行时动态产生 |
| 变化频率 | 版本化，偶尔修改 | 每一步都在变 |
| 典型问题 | 指令含糊、互相冲突 | 信息缺失、过期、过多、冲突、难以阅读 |
Prompt 是 Context 的一部分，而且在一个跑了 20 步的 Agent 里，它往往只占很小一部分。剩下的大头是工具返回的结果、检索到的资料和不断累积的对话历史。
Anthropic 在工程博客里把这件事称为 Context Engineering：Prompt Engineering 关注“怎么写好指令”，Context Engineering 关注“在每一轮推理时，如何挑选并维护一组最合适的 Token”。前者更像一次性的写作任务，后者是贯穿 Agent 整个运行过程的持续工作。
模型没有记忆，每次都是“第一次见面”
理解 Context，最重要的直觉是：大模型 API 本身是无状态的。 模型不会“记得”上一轮说了什么。你看到的“连续对话”，是程序每次都把之前的消息重新发了一遍。
可以把模型想象成一位能力很强、但每次进门都会失忆的外包专家。你每次找他，都必须把相关材料装进一个文件袋递过去。他只看文件袋里的东西，看完给出判断，然后忘掉一切。
- 文件袋里没有的信息，他不知道。
- 文件袋里信息太多，他会看漏重点。
- 文件袋里放了过期的材料，他会基于过期信息做判断。
- 文件袋有容量上限，也就是 上下文窗口（参见 Token 与上下文窗口）。
Agent 的每一步推理，都是递一次文件袋。一个 Agent 跑 20 步，就是 20 次“装袋”。Context Engineering 做的事，就是设计好每一次装什么。
把“每一步都重新装袋”画出来，就是下面这样：
拆开一次调用：客服 Agent 的第 6 步
用户问：“订单 ORD-1024 的退款为什么一直没到账？”Agent 已经查了订单和退款记录，现在准备决定下一步。此刻模型看到的上下文大致是这样：
这张图说明了三件事：
- 指令只占一小块。 真正决定下一步判断的，是 ⑤⑥⑦ 这些运行时进入的数据。
- 每一块都有来源、时效和可信度。 订单 JSON 是系统实时数据，退款政策是某个版本的文档，用户画像可能是几个月前写入的。下一课会专门讲来源。
- 每一块都在消耗同一个预算。 工具定义占了 6k，比 System Prompt 还大；如果再把 3000 行支付流水原样塞进来，前面的重要信息就会被稀释。
Agent 答错时，先问“它看到了什么”
当 Agent 给出错误结论时，可以按下面的顺序排查。多数“模型不够聪明”的问题，其实落在前四类：
| 问题类型 | 表现 | 客服场景的例子 | 解决方向 |
|---|---|---|---|
| 信息缺失 | 模型猜测或编造 | 没查发票状态，就断言“银行还在处理，请再等等” | 补工具、补检索、改流程 |
| 信息过期 | 结论基于旧事实 | 检索到 v2 退款政策，而 v3 已生效 | 知识保鲜、版本元数据 |
| 信息过多 | 忽略关键细节 | 3000 行支付流水里漏看“退款单已被系统驳回” | 工具返回精简、摘要、按需加载 |
| 信息冲突 | 结论摇摆不定 | 订单系统显示“已退款”，用户说“没收到” | 明确优先级、标注来源 |
| 难以阅读 | 理解偏差 | 字段名是 st_cd=3，没有说明含义 |
工具返回可读字段 |
| 真正的推理错误 | 信息齐全仍判断错 | 规则和数据都在，仍算错了退款到账时限 | 拆步骤、交给程序计算、加验证 |
这张表也是和工程师沟通时的共同语言：先 打开 Trace，看模型这一步实际收到了什么，再讨论要不要改 Prompt 或换模型。Trace 的读法见 Tracing。
常见误区
- “模型会记住之前的对话。” 模型本身不记。能“记住”，是因为程序把历史重新放进了上下文，而历史会被截断、压缩或清理。
- “上下文窗口够大，全塞进去最省事。” 窗口大只说明装得下，不说明看得清。后面「上下文腐化」一课会讲，信息越多，模型对单条信息的利用率往往越低。
- “效果不好就改 Prompt。” 如果问题是信息缺失或过期，再精妙的指令也救不回来。先看 Context，再改 Prompt。
产品经理检查清单
评审一个 Agent 方案时，针对关键步骤问：
- 这一步做出正确判断，需要哪些信息？每一条从哪来？
- 这些信息是否在这一步 之前 就能进入上下文？
- 有没有哪一类信息特别大（工具返回、长文档、历史记录）？谁负责把它变小？
- 如果两个来源说法不一致，模型应该信谁？指令里写清楚了吗？
- 出错时，我们能否在 Trace 里还原模型那一刻看到的完整上下文？
练习
找一个你能看到调用日志的 AI 应用（自己的 Demo、Claude Code 的会话，或团队的 Agent 都可以），选一次“答得不好”的运行：
- 把那一次调用的上下文按上面 ①–⑧ 的类别拆开，估算每类大约占多少 Token。
- 用“问题类型”表格判断，这次失败属于哪一类。
- 写一句话：如果只允许改上下文、不允许改指令，你会怎么改？
延伸阅读
- Anthropic Engineering：Effective context engineering for AI agents
- Claude 文档：Context windows
下一步
下一课「上下文从哪里来」会逐一拆解对话、用户画像、记忆、知识、工具结果、文件与任务状态这些来源，以及它们各自的可信度与时效。