Context Engineering 关注每一步推理应该获得哪些信息，以及这些信息如何随任务变化而更新。Context rot 描述上下文增加时，有效召回和利用信息可能下降的现象。企业知识库需要追求资料相关、来源明确和版本正确，而不是把所有文件一次性塞给模型。
上下文工程与提示词工程有什么区别？
提示词工程主要处理如何表达要求，上下文工程还要决定业务数据、检索结果、工具定义、历史消息和中间状态如何进入模型。一个提示词写得再清楚，也无法弥补检索到了错误版本合同或遗漏关键价格条款的问题。
Anthropic 在 2025 年 9 月的工程文章中讨论了这种变化。该词并不是本月才出现，但对企业知识应用仍很实用，因为用户真正需要的是基于正确材料完成工作，而不是得到一段结构漂亮却来源混乱的回答。
Context rot 是否意味着长上下文没有用？
不是。长上下文能容纳更多信息，但容纳能力与有效利用能力不能直接画等号。不同模型、任务和材料结构下，退化表现并不相同，不能用一个固定比例概括所有情况。
假设员工询问现行差旅标准，输入中同时包含多个年份的制度、聊天补充和历史审批案例。资料越多，冲突与干扰也越多。若没有标明生效时间和规则优先级，模型可能引用最容易读到的一段，而不是当前有效规定。
企业知识应先补齐哪些信息？
先保留文档来源、版本、生效时间、业务对象和权限范围。这些字段不只是检索筛选条件，也帮助回答者判断材料是否适用于当前问题。没有这些基础信息，模型只能从正文语气中猜测文件权威性。
本体建模可以把客户、产品、合同、条款与责任主体的关系表达清楚。例如同一名称可能对应不同法人或不同产品版本，系统应通过稳定标识关联，而不是只靠文本相似度。关系清楚之后，检索与回答才能更有针对性。
怎样让模型按需读取资料？
先给足以识别问题的摘要、目录和对象标识，再由工具加载相关原文。这里的“按需”不是任意省略材料，而是在保留可追溯入口的前提下，控制每一步进入推理的信息。
例如分析一份设备故障报告，可以先定位设备型号、时间和故障码，再读取对应维护记录和说明书章节。若一开始混入全厂所有设备的历史，模型不仅处理成本增加，还可能把不同设备的处理方式相互套用。
长任务的历史记录怎样保存？
把已确认事实、当前目标、尚未解决的问题和输出索引整理为简短状态，同时保留可回查原文。摘要用于继续执行，原始记录用于复核，两者承担不同职责。
摘要也可能出错，因此重要数字、客户身份和决策约束应有来源位置。发生冲突时可以重新读取原始材料，而不是让模型在不断压缩的历史摘要中继续推导。只保留漂亮总结却丢掉依据，会让后续纠错变得更难。
如何验证信息管理是否改进了回答？
固定一组业务问题，分别检查答案是否正确、证据是否来自有效文档、引用是否落在对应段落，以及材料不足时有没有明确说明。仅检查回答是否出现关键词，无法判断模型是否理解了规则。
可以设计有意包含旧版文件、相似客户和缺失附件的案例，观察系统是否正确筛选。还应记录检索命中与最终引用之间的关系：若资料已经找对而答案仍错，应改生成与校验；若根本没找对，则先修检索和数据组织。
小团队如何避免把知识库越做越重？
先围绕一个可验收的问题域组织材料，例如售后政策问答或项目资料整理。列出经常被问的问题、可信来源和更新负责人，优先解决文档过期与定义冲突，而不是先追求收集量。
随后复用现有低代码表单、文档存储和权限配置，逐步加入对象关系与按需检索。上下文工程的成果应体现在用户能得到可核验的答案，并能继续完成业务动作，而不是后台显示已经导入了多少文件。
当材料相互矛盾时，回答应如何呈现？
先指出冲突的具体对象与来源，例如两份制度分别适用于不同年份、部门或地区。能确定生效关系时使用当前适用版本，并保留依据；无法确定时将问题交给资料负责人确认，而不是把两段规则拼成一个从未存在过的新结论。
对于知识库运营，可以记录哪些问题反复触发冲突，把它们作为文档治理的优先项。每次修正文档后，重新检查相关测试问题和引用，避免旧内容仍在索引或摘要中被使用。这样上下文管理就形成了从用户问题、来源定位到知识更新的闭环，工程团队也能区分检索系统没有更新和原始资料本身仍有歧义这两种完全不同的原因。
官方资料与核验范围
本文资料核验日期为 2026 年 10 月 17 日。下列日期指对应公告或工程文章的发布日期，不代表概念首次出现；产品可用范围、版本与接入条件请以官方当前说明为准。文中业务案例为帮助理解而设计的假设示例，不是实测成绩或客户交付承诺。