文章目录
- 1 -> 引言
- 2 -> 先区分五种完全不同的信息
-
- 1. 规则
- 2. 事实
- 3. 方法
- 4. 状态
- 5. 证据
- 3 -> 上下文质量由四个属性决定
-
- 权威性
- 新鲜度
- 作用域
- 可复核性
- 4 -> 上下文装载不是全文检索
- 5 -> 上下文预算应该按任务阶段分配
-
- 规划阶段
- 实现阶段
- 调试阶段
- 审查阶段
- 恢复阶段
- 6 -> 冲突必须分成两类处理
-
- 指令与授权冲突
- 事实与证据冲突
- 7 -> Memory 的正确位置
- 8 -> 上下文污染是怎样发生的
-
- 把一次纠正当成永久规则
- 把 Agent 推断写入事实库
- 保存完整聊天而不提炼
- 跨租户召回
- 页面提示注入
- 9 -> 案例：一个持续三个月的产品项目
- 10 -> 衡量上下文系统是否有效
- 11 -> 常见误区
-
- 一切都存下来
- 只做向量搜索
- 把规则写得极长
- 依赖单个超长会话
- 自动学习所有人工修改
- 12 -> 落地检查清单
- 13 -> 结语
1 -> 引言
当 AI 输出不符合预期，人们最常见的反应是继续补充 Prompt。Prompt 越写越长，模型获得的信息似乎越来越多，但结果未必更稳定：旧规则与新要求冲突、背景材料淹没当前任务、个人偏好被误当成组织政策、搜索结果覆盖了正式文档，或者模型记住了一次偶然修改，却忘了真正不可违反的边界。
这些问题说明，AI 的瓶颈经常不是“缺少信息”，而是缺少上下文治理。上下文工程要解决的不是存储，而是五个问题：什么信息值得保存、谁有权修改、何时加载、如何处理冲突、使用后怎样验证。
Anthropic 将 MCP 设计成连接模型与外部数据、工具的开放标准，OpenAI、Google、微软等也逐步形成规则文件、Skills、Memory、连接器和 Agent 协议生态。共同趋势非常明确：模型能力之外，能否获得正确上下文已经成为 Agent 系统的核心基础设施。 
2 -> 先区分五种完全不同的信息
1. 规则
规则回答“允许怎样工作”。包括安全边界、目录权限、验证命令、发布流程、数据外送政策和人工审批要求。规则应该短、明确、可审计，不能依赖模型偶然回忆。
2. 事实
事实描述系统、业务和环境目前是什么样。包括架构、接口、客户口径、产品状态、数据字典和部署信息。事实有时间属性，应标注来源、更新时间和适用范围。
3. 方法
方法描述某类任务通常怎样完成，例如安全审查、市场研究、会议总结、博客制作和浏览器验收。适合沉淀为 Skill、模板、脚本或运行手册。
4. 状态
状态描述当前任务进行到哪里：已经完成的阶段、等待的决定、验证结果、预算和下一步。状态寿命较短，但决定长期任务能否恢复。
5. 证据
证据是支持当前判断的代码、命令输出、截图、来源段落、数据库结果和用户反馈。证据通常与一次任务相关，不能未经确认就永久升级为组织事实。
把五种信息混在同一份“超级 Prompt”中，会导致权威性和寿命混乱。更好的原则是：规则进入规则层，事实进入文档层，方法进入 Skill，状态进入任务记录，证据留在可追溯的工作材料中。
3 -> 上下文质量由四个属性决定
权威性
谁发布了这条信息，它是否有资格定义当前行为。安全政策通常高于个人偏好，当前用户也不能用一句临时要求绕过组织权限。
新鲜度
一年前的架构文档可能已经过期，昨天的命令输出也只代表被测环境。事实不能只看标题是否“正式”，还要看日期、版本和部署状态。
作用域
信息适用于整个组织、某个仓库、某个目录、某类任务、某个人还是当前会话。作用域越明确，越不容易误用。
可复核性
是否能找到原始来源、代码位置、数据查询或批准记录。无法复核的信息应该标记为推断或记忆，而不是包装成确定事实。
4 -> 上下文装载不是全文检索
RAG 经常被简化成“把问题转向量，再找最相似的文档”。但语义相似并不等于任务相关，更不等于权威。
成熟检索通常经过：
例如用户问“当前接口是否只读”，最相似的可能是一份旧设计稿，但真正需要同时检查当前路由、权限配置、部署版本和正式政策。代码可以证明被检查版本实现了写入，却不能证明写权限已经被批准。
5 -> 上下文预算应该按任务阶段分配
模型上下文再大也不是免费资源。信息越多，成本越高，关键约束越容易被埋没。可以使用分阶段装载：
规划阶段
只加载目标、边界、架构概览、关键规则和成功标准。
实现阶段
加载当前模块、接口契约、相关测试、局部历史和样例。不要一次读取整个仓库。
调试阶段
加载失败日志、最小复现、最近变更和对应运行时配置。
审查阶段
加载原始需求、确认计划、完整相关 diff、验证结果和范围外声明，避免把实现者的自我辩护当证据。
恢复阶段
加载已确认状态、完成项、失败原因、下一步和环境差异，而不是重新回放全部聊天。
这个过程可以称为上下文路由：根据任务类型和阶段决定信息从哪里来、以什么优先级进入、何时退出。
6 -> 冲突必须分成两类处理
指令与授权冲突
它决定“能不能做”。平台安全边界、组织政策和法律要求不能被个人偏好覆盖。当前用户可以在授权范围内调整任务，但不能默默扩大生产权限、客户数据访问或外送范围。
事实与证据冲突
它决定“实际是什么”。判断时比较直接证据、新鲜度、作用域和可复核性。当前代码说明被检查版本的实现；命令输出说明某个环境在某个时间的观察；生产行为还要核对部署、运行配置和监控。
两类冲突不能使用同一条“越新越优先”的规则。更新的日志不能授权危险操作，高权威政策也不能证明系统实际没有回归。
7 -> Memory 的正确位置
Memory 适合减少重复解释，例如：
- 用户偏好的文档结构；
- 经常使用的表达风格；
- 长期项目名称与常用缩写；
- 已被多次确认的低风险习惯；
- 经常合作的工具和格式。
Memory 不应承载：
- 唯一的安全规则；
- 生产凭据和客户数据；
- 当前系统架构的唯一真相；
- 权限、支付和合规边界；
- 尚未确认的推测。
记忆是召回辅助，不是强制执行机制。不可绕过的要求仍然需要权限、策略、CI、Hook 或人工审批。
8 -> 上下文污染是怎样发生的
把一次纠正当成永久规则
用户某次为了特殊场景修改格式，系统却把它推广到所有项目。
把 Agent 推断写入事实库
模型根据不完整资料得出结论，下一次又把自己的旧结论当成来源，形成循环确认。
保存完整聊天而不提炼
长对话包含试探、错误路线和过期决定，未来难以知道哪句话仍然有效。
跨租户召回
检索系统只按语义相似度搜索，没有先过滤权限和租户，导致客户数据泄露。
页面提示注入
网页、邮件和文档中的文字被当成系统指令，改变 Agent 目标或诱导外送信息。
治理措施包括来源标签、批准状态、版本、租户过滤、写入权限、到期时间和人工确认。未经确认的内容只能进入暂存区，不能自动成为权威事实。
9 -> 案例：一个持续三个月的产品项目
项目初期建立四类文档：项目背景、已批准需求、架构决定和术语表。团队规则规定哪些目录可改、必须运行哪些测试、哪些用户数据禁止外送。常见工作流制作成 Skills，例如发布检查和客户反馈归类。
每个迭代任务只加载当前需求、相关模块和最近决定。开发中产生的日志和方案属于临时证据；只有人确认的架构调整才写入决策记录。任务结束时生成简短 handoff：完成内容、验证、未解决风险和下一步。
当新任务与旧文档冲突时，系统不会自动选择一方，而是提示：旧决定的日期、当前代码证据和影响，请负责人确认是文档过期还是实现回归。
三个月后，Agent 不需要记住所有对话，却能通过稳定结构恢复项目。这就是上下文资产，而不是聊天记录堆积。
10 -> 衡量上下文系统是否有效
- 首次任务需要人工补充背景的次数；
- 因错误或过期上下文导致的返工率；
- 输出结论能够追溯来源的比例；
- 跨项目或跨租户误召回次数；
- 相同任务重复解释所花时间；
- 上下文中实际被使用的信息比例；
- 规则冲突被自动发现的比例；
- 状态恢复后重复执行步骤的次数；
- 未确认推断进入事实库的数量；
- 文档过期后被发现和更新的时间。
如果知识库不断增长，但人工解释和返工没有下降，它只是存储系统，不是上下文工程。
11 -> 常见误区
一切都存下来
原始资料可以归档，但进入 Agent 工作上下文前仍需筛选、分层和权限控制。
只做向量搜索
权限、版本、结构化关系和权威性无法只靠相似度解决。
把规则写得极长
越长越难发现冲突。规则层保留必须执行的内容，背景链接到正式文档。
依赖单个超长会话
会话会压缩、中断和过期。长期状态应有独立、可验证的载体。
自动学习所有人工修改
修改可能是一次性例外。先判断原因和作用域，再决定是否沉淀。
12 -> 落地检查清单
- 规则、事实、方法、状态和证据已经分层；
- 每条长期信息有来源、日期、作用域和负责人；
- 检索前先执行租户和权限过滤；
- 语义召回之后还有权威性和新鲜度排序；
- 冲突信息不会被静默覆盖；
- 当前代码、测试环境和生产事实被明确区分；
- Memory 不承载唯一安全与权限要求；
- 未确认推断不能直接写入事实库；
- 不可信外部内容与系统指令隔离；
- 长任务状态可以跨会话恢复；
- 过期内容有复审和淘汰机制；
- 输出能够关联实际使用的来源。
13 -> 结语
上下文工程的目标不是让模型“记住一切”，而是让它在正确时间知道正确的事，并且清楚这些信息来自哪里、是否仍然有效、能够支持什么行动。
当规则、事实、方法、状态和证据各自有稳定位置，Agent 才能减少重复解释而不牺牲治理；当上下文路由、权限和冲突处理建立起来，知识才真正从静态文档变成可以持续参与工作的生产资料。
感谢各位大佬支持！！！
互三啦！！！
