你的智能体（agent）用上个季度的价格回答了客户的计费问题，复盘报告会将此归咎于模型。但不应该如此。Prompt 组装正确，检索评分很高，模型对所给的所有信息进行了合理的推理——而所给的一切在三天前都是真实的。在 CRM 导出、文档同步和向量索引重建之间的某个环节，“世界的当前状态”悄然变成了“截至周二的世界状态”，而你的技术栈中没有任何环节在衡量这种差异。
数据工程师在几年前就解决了这类问题。一个消费十张上游表的下游仪表板拥有血缘关系（lineage）、新鲜度检查以及一个在夜间任务出错时进行呼叫的轮值机制。你的智能体所消费的上下文窗口也是同样的东西——一个由文档、工单、代码、CRM 和记忆连接而成的物化视图（materialized view）——只不过没有人负责这个连接（join），没有任何东西衡量它的陈旧度，当它提供昨天的真相时，失败却被归类为“模型幻觉”。
上下文窗口是一个物化视图
剥离掉 AI 词汇，看看上下文组装到底在做什么。在请求时，编排器从几个上游系统中收集行——来自向量库的一段文档、来自 CRM 的客户记录、来自支持系统的最新工单、来自记忆库的先前对话摘要——将它们连接成一个去正规化的 blob，并提供给消费者。这就是一个物化视图。它有数据源、刷新策略（或者缺失刷新策略），以及一个完全信任它的消费者。
数据库的比喻并非装饰性的，而是具有诊断意义的，因为物化视图的每种失败模式都会在上下文流水线中出现：
陈旧读取。 视图在源数据更改之前刷新。你的文档在周日晚上重新嵌入，而定价页面在周一早上发生了变化。不一致连接。 不同的源反映了不同的时间点。CRM 记录显示客户已升级，但使用数据早于升级。智能体基于一个从未真正存在过的世界状态进行推理。血缘断裂。 源系统重组了其架构——有人重构了文档站点，重命名了 Confluence 空间——而视图悄无声息地提供不再指向任何内容的片段。没人负责刷新。 文档团队负责文档。平台团队负责向量库。智能体团队负责 prompt。中间的连接（即模型实际读取的东西）不属于任何人。
数据库通过刷新策略、快照隔离和依赖跟踪来处理这些问题。而上下文流水线大多靠“希望”来处理。
陈旧度对你的检索器在结构上是不可见的
这就是为什么它比普通的数据质量问题更糟糕：检索层对时间是盲目的。语义相似性不会随着事实的过时而衰减。一个废弃的 API 参考的嵌入（embedding）得分与当前的完全一样高——通常甚至更高，因为旧文档有更多时间被链接、重复并被改写进语料库。如果上季度的政策文档的措辞碰巧更接近查询，它就会排在本季度更新的文档之前被检索出来。
这意味着陈旧度不会让你的系统优雅降级。它会静默且自信地失败。没有错误日志条目，没有检索缺失，也没有置信度下降。在第一天用错误答案关闭了 40 张支持工单的智能体——这是一个真实的事件模式，由源文档重组后三天未刷新的索引引起——它在损坏的上下文之上进行了“完美”的推理。技术栈中的每个可观测性工具都显示为绿色。
随着规模的扩大，问题会变得更加复杂。一个包含一千个文档的知识库可以通过简单的全量重建保持亚小时级别的新鲜度。在十万个文档时，同样的架构会产生半天的陈旧度。在一百万个文档时，重建耗时太长，以至于多天的陈旧度变成了常态。在试点阶段有效的架构，正是那些在生产环境中悄然腐烂的架构。
一个令人不安的重构认知：被归类为“幻觉”的问题中有很大一部分根本不是幻觉。模型忠实地报告了上下文库告诉它的内容。上下文库提供的是昨天的真相。因此而归咎于模型，就像因为 ETL 任务没运行而归咎于仪表板一样。
借鉴数据工程的方法论
这都不需要发明新的学科。分析团队花了十年时间构建的正是上下文流水线所缺失的机制。有四个部分可以直接迁移。
血缘关系：了解什么喂给了窗口
对于你的组装器可以注入的每一类上下文，你都应该能够回答：它来自哪个源系统，上次同步是什么时候，中间经历了什么转换？如果智能体引用了一个价格，你应该能够通过该片段（chunk）、嵌入任务和源页面追溯到该 token——并在每个环节都打上时间戳。大多数团队现在还做不到这一点，这就是为什么上下文复盘需要几天时间：根本原因很少是一个损坏的东西，而是略微陈旧的索引、重组后的源数据以及从未预料到这两者的 prompt 共同作用的结果。
在实践中，这意味着要给每个检索到的片段打上源 ID、源修改时间和摄取时间作为元数据——并在每次智能体响应时记录这些时间戳。这成本很低，而且它能将“智能体说了些奇怪的话”从一种无法证伪的感觉转化为一个可追溯的数据事件。
新鲜度 SLI、SLO 和 SLA：衡量差距 数据团队借鉴了 SRE 三元组：SLI 是度量指标（从源变更传播到服务层的时间，以分钟计），SLO 是内部目标，SLA 是对用户可依赖的承诺。针对每个上下文来源应用这些指标，因为统一的新鲜度既无法实现，也没有必要：
事务型状态 —— 账户余额、订阅层级、未解决事件：以分钟计。这一层级通常根本无法承受批处理 ETL；它需要变更数据捕获（change-data-capture）或直接透读记录系统。某零售商的库存代理在早晨 ETL 运行和下午查询之间的 8 小时缺口中，出现了 2000 个单位的同步偏差 —— 这不是索引漏洞，而是层级匹配错误。运营知识 —— 定价页面、API 文档、运行手册、政策：以小时计。应在变更事件发生时进行增量重新嵌入（incremental re-embedding），而不是预定的全量重建。参考资料 —— 架构概览、历史决策、教程：数天到数周完全没问题。在这里支付实时基础设施成本是浪费。 层级比具体数字更重要。重点在于，“在 Agent 撒谎之前，这些数据可以陈旧到什么程度？” 变成了一个有负责人的设计输入，而不是一个无人选择的属性。
数据合约：让来源自我声明 源团队与上下文流水线之间的数据合约规定了 Schema、更新语义和新鲜度承诺 —— 关键是，还有告知破坏性变更的义务。文档网站的重新组织导致一半的向量索引无声地失效，这正是数据合约存在的意义：在合约下，“我们正在重组空间”是摄取流水线被告知的一个事件，而不是三周后通过检索质量下降才发现的事实。
合约还解决了所有权真空。签署合约强制要求在事件发生前而不是发生期间，回答“当这个来源陈旧时，谁负责？”这个问题。
回填策略：为出错做好计划 每个流水线最终都会提供错误数据 —— 损坏的转换、被污染的源、或者是重塑了整个向量空间的嵌入模型升级。数据团队将回填（backfill）视为一等公民能力：重新处理时间范围、重建受影响的分区、验证、切换。上下文流水线也需要同样的肌肉。当你发现周二的文档同步损坏了一个命名空间时，“重新运行所有内容并等待 12 小时”是停机；“使用一致的 ID 重新处理受影响的块并进行原子切换”则只是一个波动。如果你唯一的刷新机制是全量重建，那么你已经隐式地在长时间的陈旧窗口和长时间的维护窗口之间做出了选择 —— 只是你还没承认而已。
一致性是无人提及的新鲜度问题 在针对每个来源的新鲜度背后隐藏着一个更微妙的要求：跨源的一致性。当组装器（assembler）将来自一个系统的客户余额、来自第二个系统的风险评分和来自第三个系统的账户历史连接起来时，这些片段应该描述的是同一个时刻。如果不是，Agent 并不是在根据一个陈旧的世界进行推理 —— 它是在根据一个 不可能 的世界进行推理，这是一个由三个不同时间点组装而成的“缝合怪”状态。
数据库称之为快照隔离（snapshot isolation），而上下文流水线几乎普遍缺乏这种隔离。在构建真正的事务性上下文存储之外，有两种实用的缓解措施。首先，对需要连接在一起的来源对齐刷新频率 —— 如果 CRM 每小时同步一次，而使用数据每天同步一次，那么它们之间的每次连接在长达 23 小时内都是不一致的。其次，当无法保证一致性时，将时间戳暴露给模型：“截至 UTC 09:12 的余额，截至昨天 UTC 23:00 的使用数据”。模型处理明确带有日期的证据要比处理无声矛盾的证据好得多，而且面向客户的“截至今天早晨”总比一个自信的错误答案要好。
这也是为什么“仅仅改进检索”无法解决问题的真实论据。重排序（Reranking）、混合搜索和查询重写都只是优化了 哪些 片段被选中。它们都没有解决片段在 何时 是真实的，或者它们是否曾同时为真。
将下一次“幻觉”视为数据事件 这里有一个具体的开始方法，它只需要一个工程周，而不是重构整个平台。首先为流水线添加检测（instrument）：为每个块标记源修改时间（source-modified）和摄取时间（ingested-at）时间戳，并随每个 Agent 响应发出 max_context_staleness 指标。仅仅测量这一点就能让人清醒 —— 大多数团队从未见过这个分布，而且通常比任何人猜测的都要糟糕。然后将你的来源分类到三个新鲜度层级中，并根据用例可以容忍的程度检查每个层级的实际陈旧度。任何事务性状态流经批处理流水线的地方，你都发现了一个尚未报警的存活 Bug。
然后修改复盘模板。当 Agent 给出错误答案时，第一个问题不是“为什么模型编造了这个？”而是“这个说法在某个时间点是否真实 —— 如果是，是什么时候，是谁提供的？”你会发现，很大一部分质量事件都是披着幻觉外衣的新鲜度事件。这些是“好的”事件：与真正的模型失败不同，它们是确定性的、可追溯的，并且可以通过无聊但经过验证的数据工程来修复。
在 2026 年交付可靠 Agent 的团队不是那些拥有秘密提示词技术的团队。而是那些注意到 Agent 是数据平台的下游消费者，并像运行营收流水线一样严谨地运行上下文流水线的团队。模型读取视图提供给它的任何内容。掌控那个视图。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
