公司准备让 AI Agent 接手一部分项目工作，于是团队把聊天记录、会议纪要、产品文档、审批单和工单都接了进来。
资料越来越多，Agent 却没有越来越聪明。它能复述某次会议，却不知道哪个决定仍然有效；能找到一份 SOP，却不知道这次是否适用；刚解释完背景，换一个任务又要重新确认一遍。
问题往往不在于 AI“记得太少”，而在于企业把不同性质的信息混在了一起。
对 Agent 来说，Context 不是历史记录的总和，也不是越长越好的提示词。它是一套组织记忆：让 AI 知道发生过什么、现在认为什么、遇到问题应该怎么做，以及眼前这次任务究竟需要什么。
一、资料存在，不等于 Context 可用
企业并不缺信息。真正稀缺的是与当前行动匹配的信息。
一份会议纪要记录了讨论过程，不代表里面的每句话都已经成为结论；一篇项目复盘总结了经验，不代表它可以直接替代现行流程；一套两年前的操作手册即使检索命中，也可能把 Agent 带向错误动作。
如果把它们不加区分地塞进上下文窗口，模型需要临时判断哪些是事实、哪些是意见、哪些已经过期。信息越多，冲突和噪声也越多。
这和让新同事接手项目很像。把整个网盘开放给他，并不能让他立即进入状态。他仍然需要四类信息：项目经历、当前共识、工作方法，以及这一次任务的必要材料。
企业 Context 的第一步，因此不是扩容，而是分层。
二、四层记忆，分别回答四个问题
1. 情境记忆：之前发生过什么
情境记忆保存具体事件及其现场：谁在什么时间说了什么，发生过哪些变化，当时依据什么做出决定。
聊天、会议、项目流、审批、工单，都属于这一层。它的价值不只是“可搜索”，而是保留结论形成的路径。
例如，系统只记住“本期不上某功能”，以后很容易把它理解为永久结论。如果同时保留当时的预算、交付周期和参与角色，Agent 才能判断：这是长期原则，还是特定条件下的阶段选择。
情境记忆的问题是数量大、重复多、时效差异明显。它适合保留现场，却不适合直接承担全部判断。
2. 语义记忆：团队现在认为什么
语义记忆是从大量情境中沉淀出来的稳定知识，例如术语、规则、产品定义、标准流程和组织共识。
会议里反复解释的口径，经过确认后可以成为术语定义；多个项目中重复出现的判断，可以沉淀为设计原则；一次审批结论只有经过适用范围和有效期确认，才可能成为规则。
这层的重点是从事件中提炼共识，同时保留它来自哪里、何时生效、由谁负责。
否则，语义记忆只是另一种二手总结。经过多轮压缩和转述后，它可能越来越简洁，也越来越远离原始依据。
3. 程序化记忆：遇到这类事怎么做
知道规则，不等于能够执行。
程序化记忆保存的是处理方法：SOP、模板、工作流、工具调用策略和 Agent Skill。它把“我们知道什么”转换成“接下来做什么”。
例如，语义记忆可以告诉 Agent：线上发布必须经过审核。程序化记忆则要进一步说明：先检查哪些字段，由谁确认，调用什么工具，失败后停在哪里，哪些动作必须再次获得授权。
这一层决定 Agent 停留在建议层，还是能够进入执行层。缺少程序化记忆时，AI 可以说得头头是道，却无法稳定地把事情做完。
4. 工作记忆：这次任务需要什么
工作记忆是当前任务窗口里临时使用的少量信息。
它可能包括这次目标、当前进度、刚刚确认的约束、待处理文件和下一步动作。任务结束后，其中大部分内容不需要长期占据活跃上下文。
工作记忆强调的不是完整，而是最小且充分。信息太少，Agent 会缺少依据；信息太多，旧记录会稀释当前目标。
因此，同一个人处理“写周报”和“评审需求”时，应该拿到两套不同的 Context 切片。前者关心本周变化、阻塞和计划，后者关心用户问题、业务规则、方案边界和验收标准。
四层记忆可以对应为一组简单的问题：
- 情境记忆：发生过什么？
- 语义记忆：现在认为什么？
- 程序化记忆：应该怎么做？
- 工作记忆：这次需要什么？
四层分开治理，Agent 才不必每次都从一堆历史资料中临时拼答案。
三、Context 不是归档出来的，而是循环生长的
分层只是开始。工作每天都在变化，Context 必须跟着更新。
复杂项目中，一种有效的思路是向上蒸馏、向下回注。
向上蒸馏，是把大量具体经历逐步压缩成更稳定的判断。日报汇总为周报，周报汇总为月报，表面上是时间尺度变化，本质上是在删除重复细节，保留趋势、异常、决定和未解决问题。
向下回注，是让高层判断反过来改变后续记录。如果月度复盘发现“延期主要发生在需求口径未确认的项目”，那么下一轮日报就不应继续只写完成事项，而要明确记录口径状态、负责人和阻塞时间。
这两个动作必须同时存在。
只有向上蒸馏，Context 会变成越来越抽象的总结，最终看不到事实依据；只有向下记录，系统会积累大量流水账，每次使用都要重新理解。
一个完整循环应该是：
事件记录 → 周期提炼 → 形成判断 → 改变记录结构 → 产生更好的新记录
Context 的价值，不在于保存了多少历史，而在于历史是否逐渐改善了后续行动。
四、三种情况下，不能只做“总结”
蒸馏解决的是从经历中提炼知识，但真实工作还有三类常见问题。
讨论反复震荡：重构情境
团队围绕同一方案反复争论时，继续补会议纪要通常没有用。限制可能来自问题框架本身。
此时需要调整目标、边界或观察视角，再把已有信息重新放进去。例如，把“这个功能要不要做”改写成“哪个用户问题值得在当前阶段投入”，同一批材料会导向不同的判断路径。
情境重构不是修改历史，而是切换解题框架。原始记录仍然保留，但系统需要显式记录新的问题定义及其适用范围。
信息越来越重：引入遗忘与衰减
Context 如果只进不出，最终一定会变慢。
遗忘不是删除一切旧信息，而是调整信息进入核心上下文的优先级。低频、过期、已经被新规则替代的内容逐渐退出活跃区域；持续被引用、影响关键决策的内容获得更高权重。
这里要特别区分降低权重与删除证据。旧决策可以不再参与日常推荐，但在审计、复盘或解释历史时，仍然需要被找回。
多任务并行：按目标编排 Context
一个 Agent 同时处理周报、需求评审和客户答疑，不应该共用一份固定上下文。
更合理的方式，是先识别当前目标，再选择相关情境、规则和流程，最后按任务顺序组装。这就是任务驱动的 Context 编排。
它追求的不是每次提供最多信息，而是在有限窗口中提供最相关的一小部分。任务变化时，切片也随之变化。
五、企业落地，不要从“全量记忆”开始
如果一开始就规划覆盖所有部门、全部文档和所有工作流，Context 很容易变成另一个长期知识治理项目。
更现实的路径，是先选一个高频、高价值、结果容易验证的任务。例如需求评审、客户问题归因或项目周报生成，然后建立一个最小闭环。
第一，定义任务。明确 Agent 要完成什么，输出交给谁，什么情况必须停下来询问。
第二，盘点来源。找出支持这个任务的聊天、文档、规则、流程和实时数据，不追求全量接入。
第三，按四层分开。哪些是历史现场，哪些是当前共识，哪些是执行方法，哪些只在本次任务中临时使用。
第四，设计更新触发。新会议、新制度、执行失败和人工纠正发生后，分别更新哪一层，由谁确认。
第五，把结果写回。Agent 完成任务后，不只保存最终答案，还要记录引用依据、关键判断、执行结果和未解决问题，让下一轮蒸馏有材料可用。
这个闭环跑通后，再扩展到更多任务。否则，团队很容易先建设一个庞大的“记忆库”，最后仍然无法回答最基本的问题：这些记忆会在什么时刻，帮助 Agent 做出什么动作？
六、验收 Context，看它是否支持正确行动
Context 好不好，不能只看检索命中了多少文档，也不能只看模型是否记住了上次对话。
至少可以检查五个维度：
- 相关性：拿到的信息是否直接服务当前目标；
- 可信度：规则和结论能否回到原始记录与确认人；
- 时效性：过期内容是否退出当前判断；
- 可执行性：是否提供了明确流程、工具与停止条件；
- 可追溯性：行动完成后，能否解释用了哪些依据、做了哪些选择。
最终还要回到任务结果：Agent 是否减少了重复澄清，是否引用了当前有效规则，是否选择了正确流程，是否在信息不足时暴露缺口，而不是自行补全。
Context 工程真正要解决的，不是让 AI 看见企业的一切，而是让它在面对一个具体任务时，获得足够的信息、遵守明确的边界，并采取可检查的行动。
当经历能够沉淀为共识，共识能够转化为方法，方法又能按任务被准确调用时，AI 才真正开始进入组织的工作流。