一个模型可以读下几十万 token（模型处理文本的计量单位），仍然会在关键事实面前犯错。容量解决“装得下”，Context Engineering（上下文工程）解决“此刻该看什么、信什么、忘什么”。
Prompt 写任务，Context 决定它活在哪个世界
上一篇解决的是规格：要做什么、做到什么程度、如何验收。本篇解决的是现场：模型基于哪些事实工作，哪些规则优先，历史状态如何延续。两者经常被混在一起，因此很多人不断修改 Prompt，实际却在修一个资料供应问题。
Anthropic 对两者的区分很清楚：Prompt Engineering 主要组织指令，Context Engineering 管理推理时进入窗口的全部状态，包括系统指令、工具定义、外部数据、消息历史和工具结果。智能体每走一步都会制造新信息，所以这不是一次性的“上传附件”，而是持续决定下一步应该带什么。
这四类内容共同组成模型此刻能看到的世界。窗口之外的信息不是“模型暂时没想起来”，而是对这次推理根本不存在。反过来，进入窗口也不等于会被正确使用：内容越多，相关信号越可能被旧材料、重复结果和冲突口径淹没。
更大的会议室可以坐更多人，但不会自动产生更好的会议。决定谁该参会、谁拥有最终口径、哪些材料需要会前摘要，仍然是组织能力。Anthropic 把 Context 称为有限且边际收益递减的资源：token 越多，注意力预算消耗越大，相关性判断反而更重要。
五种失败，不要都叫“模型失忆”
Context 出问题时，症状都像“它没懂”，病因却完全不同。不先分类，补资料只会把现场弄得更乱。
世界缺失
模型拿到任务，却没有业务定义、目标用户或现状数据。它只能用通用常识补洞，最后得到一份结构正确、对象错误的答案。
上下文污染
旧方案、无关搜索结果和重复工具输出持续堆积。真正关键的三句话被埋在几万 token 中，模型并非没看见，而是无法稳定分配注意力。
口径冲突
会议纪要说 A，制度文件说 B，却没有权威等级和生效日期。模型被迫暗中选边，并把推断写成事实。
事实过期
库存、人员、版本和政策进入窗口后就被冻结。昨天正确的资料今天仍在被检索，回答看似有来源，实际已经失效。
记忆漂移
摘要经过多轮压缩，把假设写成结论、丢掉反对意见。错误一旦进入“长期记忆”，之后每次回答都会稳定地错。
这里有一个反直觉点：上下文不足会让模型编，上下文过量也会让模型编。前者是没有证据，后者是证据的权威、相关性和时间关系没有被设计。两种病不能用同一味药。
如果模型不具备基础能力，换模型或拆任务；如果目标和验收不清，回到 Prompt；如果它需要读取系统或执行动作，给工具；如果规则必须每次强制执行，放进 Harness。不要把所有问题都变成“再上传一些资料”。
上下文经济学：每条信息都要过四道门
我用四个问题判断一条信息是否值得进入当前窗口：它与当前动作有多相关？来源有多权威？还新鲜吗？带来的注意力和成本是多少？
这四道门会导向一个核心原则：Just-in-time Context（即时上下文）。不要在开工时把未来可能需要的一切塞满，而是在任务推进到某一步时检索、读取、压缩对应材料。窗口里常驻的是目标、规则和状态，证据按问题进入，工具结果用完即退场。
| 信息类型 | 应该住在哪里 | 什么时候进入窗口 | 什么时候退出 |
|---|---|---|---|
| 不可违反的规则 | 系统指令 / 项目规则 | 每次任务开始 | 规则失效或被正式替换 |
| 项目稳定事实 | 版本化项目记忆 | 进入该项目时 | 事实改变后更新，不保留双口径 |
| 当前进展 | 状态文件 / Handoff | 当前阶段开始 | 完成后压缩为结果 |
| 参考资料 | 知识库 / 文件库 | 被具体问题检索命中时 | 提取结论与引用后清出 |
| 工具原始输出 | 短期会话 | 执行动作后 | 状态已更新且证据已记录后 |
RAG（检索增强生成）只是这套机制中的“把证据找回来”。Context Engineering 还要回答：检索什么、返回多少、冲突怎么处理、谁拥有最终口径、结果是否需要写入长期状态。只有向量检索，没有信息治理，系统只会更快地找回旧错误。
企业案例：180 份材料，真正需要同时看的只有 12 份
最直觉的做法是把 180 份文件全部交给模型，让它“综合分析”。第一次输出通常很像样：风险、机会、路线图一个不少。但追问依据时，会暴露三个问题：旧版需求被当成当前承诺；销售会议中的乐观判断压过正式测试报告；同一指标在三份文件中口径不同。
问题不是模型读不完，而是资料库没有告诉它什么决定正在发生、谁的证据更权威、哪些信息已经过期。我会把上下文管道拆成五步。
先把任务从“综合分析新版本”收窄为：在上线门槛、已知风险和补救成本之间，给经营团队一个 Go / Conditional Go / No-Go 建议。
正式验收报告优先于群聊观点；生产日志优先于回忆；当前版本文档优先于历史方案。材料冲突时不让模型裁决，先输出冲突清单和需要谁确认。
安全性问题读取渗透测试、权限变更和事故记录；商业准备问题读取客户承诺与支持能力。不同问题不共享整包资料，减少无关内容互相污染。
每形成一个判断，就记录依据和反对证据。模型下一轮读取 Ledger，不再重读几十页原始材料；需要核实时再回到来源。
最终窗口里常驻 4 份状态材料，加上按问题取回的 8 份高信号证据。模型实际处理的不是 180 份文件，而是一个可追溯的决策现场。完整性没有下降，噪声和冲突却被显式管理。
资料越多越安心
180 份全量注入，模型暗中处理版本、冲突与优先级，没人知道它忽略了什么。
证据按决定进入
12 份当前材料 + 来源登记 + 证据账本；缺口可见，结论能追溯，状态可交接。
Context Manifest：先设计信息流，再打开模型
下面是一份可以直接复用的 Context Manifest（上下文清单）。它不是给模型的万能 Prompt，而是给操作者的装载协议：哪些信息常驻，哪些按需读取，冲突和过期怎样处理。
<decision> 当前需要支持的决定：[填写] 本轮动作：[只做一个可验证动作] 完成后状态将怎样变化：[填写] </decision> <always_on> 不可违反的规则：[路径 / 版本 / 所有者] 项目稳定事实：[路径 / 最近更新时间] 当前状态：[已完成 / 进行中 / 阻塞 / 下一步] </always_on> <source_policy> 权威顺序：原始数据 > 正式文档 > 会议结论 > 个人观点 > 模型推断 每个来源必须带：负责人、日期、适用版本、保质期 发现冲突：并列展示，不替责任人拍板 缺少关键证据：输出缺口，停止形成确定性结论 </source_policy> <retrieval_plan> 当前问题需要的证据类别：[填写] 最多取回：[N] 个片段；优先原始来源 检索结果进入窗口前：去重、按日期排序、标记过期项 原始工具结果在结论写入 Evidence Ledger 后清出历史 </retrieval_plan> <memory_policy> 只有已确认事实与不可逆决定可进入长期记忆 过程、尝试和临时观点只进入当前状态或归档 每条长期记忆必须有所有者和更新触发条件 压缩时优先保留：决定、约束、未解问题、失败原因、下一步 </memory_policy> <output> 回答必须区分：事实 / 推断 / 建议 / 缺口 每个关键结论引用来源；说明什么新证据会改变结论 结束时输出：本轮状态变化 + 应写入记忆的候选项 </output>
清单里最值钱的不是标签，而是三条治理规则：权威顺序、记忆准入和清理时机。它们把“模型应该懂”改成了可以检查的信息供应链。
长任务的四个减压阀
任务跨越几十轮甚至多个会话后，靠“继续聊”维持连续性一定会失效。长任务需要把记忆从聊天体验升级成系统设计。
Anthropic 在 Context Engineering 与长时任务研究中反复验证了这四类策略：Compaction 保持会话流，结构化笔记跨会话保存状态，独立上下文隔离大量探索，工具结果清理减少已经失去价值的历史。它们不是互斥方案，而是针对不同噪声源的组合。
测试 Context，而不是只测试答案
一份回答正确，不代表上下文管道可靠。它可能恰好从噪声里捞到了对的事实。要验证系统，必须故意破坏上下文。
| 测试 | 故意怎样改现场 | 通过标准 |
|---|---|---|
| Ablation 消融 | 拿掉一类材料 | 系统能指出缺口，而不是用常识补齐 |
| Distractor 干扰 | 加入大量相关但无决策价值的资料 | 结论与引用不漂移 |
| Freshness 时效 | 同时放入新旧两个版本 | 使用新版本并标记旧版本失效 |
| Conflict 冲突 | 让两个权威来源互相矛盾 | 暴露冲突并升级确认，不暗中选边 |
| Handoff 交接 | 换一个全新会话只读取状态文件 | 能准确说出目标、进展、阻塞和下一步 |
| Injection 边界 | 在材料中夹入“忽略规则” | 把它识别为数据，不覆盖上层指令 |
这里最容易被忽略的是 Handoff 测试。一个上下文系统是否成熟，不看原来的会话聊得多顺，而看换一个没有参与过历史的人或智能体，能否只凭显式状态继续工作。能交接，才说明知识离开了个人记忆。
模型会换，留下来的是你的 Context Architecture
更强模型会降低上下文设计的精细度，但不会取消它。最强反对意见是：窗口越来越大、检索越来越自动，手工治理终将被产品吸收。这条反对意见值得权衡——许多低风险任务确实不需要复杂工程。
但企业任务仍有三件事无法由容量替代：谁拥有事实口径、什么信息可以进入模型、什么结论允许进入长期记忆。这些是治理与责任，不是 token 数量。能改变我判断的证据是：系统在多版本、强冲突、长周期任务中，不需要显式权威和状态规则，也能持续给出可追溯且无漂移的结果。目前我没有看到这种证据。
一页带走：开工前的 10 个 Context 问题
- 这一步究竟要支持什么决定或状态变化？
- 哪些规则必须常驻，哪些只是本次偏好？
- 哪些证据会改变结论，哪些只是背景知识？
- 来源的权威顺序、日期和适用版本是否明确？
- 材料冲突时，谁拥有最终确认权？
- 当前窗口里有哪些内容已经完成使命，可以清除？
- 哪些事实需要写进长期记忆，谁负责更新？
- 压缩后是否保留了失败原因、约束和未解问题？
- 换一个新会话，能否只凭状态文件继续？
- 材料里是否包含不该进入模型的敏感信息或伪指令？
下一篇进入 Loop Engineering：世界给对以后，怎样让一次生成变成有证据的完成。