每次都要重讲一遍背景：智能体的资料预热层要定粒度与失效
一、这一层要解决的不是找不到，是反复重述
据公开报道，有产品把”个人知识空间”做成智能体的前置层，针对的问题描述得很具体：用户让智能体写周报、分析方案时，仍要先翻找资料、交代背景，换一个任务这套流程重来一遍，资料越多，反复处理的成本越高，词元也烧在这里。产品名与说法都按公开报道处理，它的实现方式、存储结构和任何效果数字我们都不做推断，也不评价它与同类方案的优劣。
我们关心的是这个层一旦被承认，工程上就必须回答的三个问题：沉淀什么粒度、什么时候过期、谁能改动。这三个问题不答，这一层会在几个月内退化成第二个网盘——里面什么都有，谁都不敢用，每次还是要重讲一遍。
很多企业客户在上一轮已经建了检索层，他们的第一反应是”这不就是 RAG 换个说法”。不是。检索层解决的是”知道去哪找”，预热层解决的是”这件事的背景能不能不用再说第二遍”。前者的单元是文档片段，后者的单元是带有信任状态的陈述；前者追求召回，后者追求可注入。目标不同，治理手段就不同。
二、四种粒度，各自的适用面与失效方式
第一种是原文片段。适合措辞本身有意义的场合：合同条款、客户原话、标准里的定义。它的失效方式最隐蔽——原文没变，但它的适用条件变了，于是每次注入都显得很有依据。所以原文片段必须绑定来源版本，光有出处不够，要能判断出处是否还是现行版本。
第二种是结构化事实。字段化的、可判定真假的陈述：某个接口当前的负责人、某个产线的节拍口径、某客户的结算方式。它最容易维护，因为可以按字段做校验和更新，也最容易做冲突检测。它的失效方式是字段口径变了但值没变。
第三种是结论卡片。带推理的产出：”某类缺陷集中在某个工序，原因是……”。这类东西最有用也最危险，因为智能体会把它当事实注入。结论卡片必须把”结论”和”支撑它的事实”分开存，注入时带上支撑项，并且默认过期。
第四种是任务模板。不是知识，是流程：写周报要看哪几项、做方案评审要先问哪三个问题。它的失效方式是流程本身改了而模板没改，导致输出结构看起来完整、内容却按旧规矩组织。
四种粒度的成本与风险完全不同结构，混在一个库里按同一套规则管理，是这一层最常见的失败原因。
三、三个成本项，第三个最贵
第一项是存储。它几乎可以忽略，或者更准确地说，它是唯一一项不需要操心的。第二项是注入上下文的词元：预热资产每次被带进会话都要付费，而且付费次数等于使用次数，不是入库次数，这也是为什么”沉淀得越多越好”是错的。第三项是过期内容误导带来的代价，它是唯一会外溢到业务上的成本：一次基于旧口径的产出，损失不只是那一次回答，还包括客户对整个系统的信任重估。
三者之间要做的取舍很清楚：注入预算是可控成本，误导是无底成本。所以我们主张在预算分配上偏向”少而准”，宁可让长尾内容走检索，也不让它常驻注入。
四、更新触发与检索层的分工
更新触发我们分四种档位。按来源版本更新最可靠，适用于结构化事实和原文片段，前提是来源本身有可判定的版本号。按时间过期适用于结论卡片，到期就自动降级为”仅供参考”或不注入。按被引用次数重估适用于所有内容：长期没被引用的资产要定期清理，它只占预算不产生价值。人工确认档是给影响大的资产用的，机器只能提示”可能过期”，改不改由署名的人决定，并且留下确认记录。
与检索层的分工要写在字段上，不能靠口头约定。我们的判据是两条轴：变化频率与调用频率。高频稳定进预热层，长尾易变留给检索层，两条轴都低的直接不沉淀。落到实现上，就是预热库里每一条都要有变化频率档、调用频次、注入预算上限三个字段，检索库那条则带来源版本与新鲜度。有了这些字段，边界是算出来的；没有这些字段，边界就是一句风格指南，很快就会有人往预热层里塞东西。
五、共享时的可见性与两个上线陷阱
多人共享这一层时，最先出问题的是写权限。结论卡片被 A 改了一版，B 的输出就变了，而 B 完全不知道，因为 B 看到的仍然是”我们空间的背景”。所以可见范围与写权限要分开定义：谁能读、谁能改、改完谁被通知，三件事缺一不可。改动必须留痕，并且留痕里要能回答”这条注入在哪个版本上生效过”——出问题时得能倒推出哪批输出受影响。
两个最容易踩的陷阱值得单列。第一个是把过期结论当事实注入，前面说过，防它的手段是默认过期加分层注入。第二个更棘手：预热内容会成为提示注入的入口。这一层里的文本是被信任的，会被自动带进上下文，于是任何能写入这一层的人，等于能向别人的会话里注入指令。防护手段是把写入通道收紧到少数来源、对外部来源的内容做标记与降权、注入时对非本人署名条目加提示约束，并把”这条内容是谁写的、是否外部来源”留在可观测字段里，而不是注入完就丢掉。
六、核心交付物：预热资产清单与度量
下面是我们建议随这套层一起交付的清单表，每一行是一种粒度，列出的字段就是实际能扳动治理的那几样东西。
| 字段 | 原文片段 | 结构化事实 | 结论卡片 | 任务模板 |
|---|---|---|---|---|
| 来源 | 文件名与出处段落 | 系统与责任人 | 支撑事实的引用清单 | 流程编号与定稿人 |
| 版本依据 | 来源版本号，缺则不入库 | 字段口径版本 | 结论与前提分离记录 | 流程版本 |
| 有效期 | 跟随来源版本，现行即有效 | 按字段校验，无固定期 | 默认到期，续期要署名 | 流程改版即失效 |
| 可见范围 | 空间全员或指定组 | 按字段敏感度分级 | 组内，改动需通知 | 全员 |
| 写权限 | 只读，导入通道受控 | 责任人本人 | 作者加指定复核人 | 定稿人 |
| 注入预算 | 截断上限，按字符计 | 单字段，量小 | 带支撑项，受总预算约束 | 结构骨架，不填内容 |
| 外部来源标记 | 有 | 有 | 有 | 有 |
效果度量不能只看省了多少。要看的第一项是同一任务的重复交代次数：用户在一次会话里被迫补充背景的次数，这是这一层的直接目标，可以从会话日志里按”用户在助手回复后再次陈述事实”的模式粗略统计。第二项是注入词元在总消耗里的占比与其变化，和回答质量放在一起看才有意义——单看下降，很可能只是注入变少了而质量同步下滑。因此必须同时盯一组反例指标：基于预热内容的输出被用户当场纠正的次数、引用过期来源的次数、以及用户主动绕开预热层重新交代的次数。这三个数只要有一个在涨，说明这一层正在从省钱变成增加返工。
洹拓在给企业客户做这类层时，通常建议从一个空间、一到两种粒度开始，先只上结构化事实与任务模板——它们最容易校验，也不容易误导。等更新触发和可见性这两件事跑通，再引入原文片段与结论卡片。顺序反过来，第一年攒下的东西大多要在第二年重做一遍清理。