O'Reilly Radar 提出 AI 栈"保存缺口"与 Orrery 参考架构

O'Reilly Radar· Monika Dvorackova·2026-10-08 18:54· 56 分钟前AI 评分42

AI 技术栈中的保存缺口：为何能力进步快于可重建性

AI 导读

O'Reilly Radar 文章提出 AI 系统存在"保存缺口"：运行时依赖（模型端点、检索数据、策略、工具契约等）在执行时才确定，现有基础设施只保存模型、代码、部署和观测记录，不保存某次执行的实际绑定关系。作者为此提出参考架构 Orrery，用于保存重建 AI 系统历史执行所需的运行时绑定与依赖状态，并区分了"可复现性"与"可重建性"两个概念。

正文

人工智能系统难以复现，因为其行为依赖于非确定性的模型，以及持续变化的数据、配置、策略和外部服务。但精确复现并不总是运营者、调查人员或审计人员所需要的。他们往往需要的是另一种东西：历史可重建性。核心论点是，可重建性是执行期间建立的一种系统属性，而非事后从残留的产物中推断出来。为了让这一属性具体化，本文引入了 Orrery——一种参考架构，用于保存重建 AI 系统过往执行所需的运行时绑定与历史依赖状态。

设想一项 AI 辅助的决策，在做出六个月后必须接受审查。重新运行系统可能会产生不同的答案，但调查人员可能仍需要确定当时使用的是哪个模型端点、策略、检索数据、工具契约和运行时配置。这就是本文所针对的问题。

AI 行业在评估能力方面仍然远胜于保存理解过往执行所需的知识。评估流水线追踪基准分数、任务成功率、检索精确率与召回率、工具调用成功率、延迟和成本，并且每次发布都变得更加精细。在实践中，这套机制往往归结为一个验收问题：这个系统能做什么？这个问题捕捉的是能力，而不是某次过往执行在系统变化之后是否仍然可被理解。

那个缺失的属性就是历史可重建性：能够确定使用了哪些依赖，以及某次特定执行是在何种条件下发生的。它与可复现性相关，但又有区别。可复现性问的是，在等效条件下能否再次产生某个结果。可重建性问的是，即便重复该执行不会产生完全相同的结果，原始执行的条件是否仍能被识别出来。

当一次具有重大影响的 AI 执行今天成功完成，却在六个月后受到质疑时，这一区别就变得重要。模型可能仍存在于注册表中。应用程序修订版本可能仍存在于 Git 中。追踪记录可能仍能识别出请求及其经过的服务。然而，这些记录都不一定能揭示是哪个模型端点服务了该请求、应用了哪些输入转换和运行时配置、哪些数据、特征状态或检索上下文进入了计算，或者由哪种策略状态所支配。在智能体系统中，缺失的历史还可能包括记忆、工具契约、委托和外部效应。即便记录了某个依赖标识符，它所指向的历史状态也可能已不再可用或无法解析。

问题在于，AI 运行时可能使用那些历史身份和关系未被保留的依赖项。这是一个架构问题，而不仅仅是日志记录问题。缺口存在于运行时使用的内容与周边基础设施被要求保留的内容之间。我称之为保留缺口。AI 技术栈保留了模型、代码、部署和观测结果，但并不要求某次特定执行的有效历史配置保持可用。组件可能仍然存在，而曾使它们构成同一次执行的关系却消失了。AI 运行时必须组装今天的执行；它未必被要求记住昨天究竟组装了什么。因此，可重建性必须在执行期间、在后续变更抹去赋予该执行有效配置的绑定之前就建立起来。

密封构建展示了相反的设计模式。它们在执行开始前就通过固定输入、版本和外部依赖来封闭依赖图。AI 运行时面临的是相反的情况：依赖图的一部分直到执行时才确定，因为模型端点可能通过可变别名解析，数据和特征状态会演变，运行时配置和策略会变化，检索到的上下文只有在请求被处理时才被选定。智能体系统通过记忆、工具、委托和外部效应进一步扩展了这张图。在密封构建中，依赖封闭是输入。而在现代 AI 运行时中，它的一部分可能是运行的输出。

版本控制记录源代码演变，事务日志记录状态转换，分布式追踪记录执行关系。这些机制保留了运行的不同视图，却没有保留其具有实质相关性的、特定于执行的配置。追踪可能保留执行流程，部署清单保留声明的应用状态，模型注册表保留模型修订版本。常常缺失的是关于哪些工件和状态在某次特定执行中被绑定在一起的记录。

依赖图不再在部署时封闭

部署记录的是执行开始前已知的配置。AI 系统更难重建，因为具有实质相关性的依赖是在执行期间被选定的，而不是在部署时固定的。在推理时，系统可能解析模型端点、输入转换、数据或特征状态、检索到的上下文、运行时配置、安全控制和策略。智能体系统通过记忆、工具、委托和外部效应扩展了这种组合。这些特定于执行的选择就是运行时绑定：关于该执行实际使用了什么的事实。

下面的例子让这一区分变得具体。设想一次假设的智能体执行，标识为 E891。在这次执行期间，系统检索两份文档，评估一项策略，调用一个工具，并产生一个外部效应。部署可能标识应用修订版本 8f31c2 和模型 v17，而执行本身绑定了提示 h31、检索索引 r42、实体 d182@17 和 d761@4、工具契约 h42、策略 v8，最终是效应 e3。部署系统不可能事先知道这整个集合，因为其中一些依赖是在执行推进过程中才被选定的。

当依赖发生变化时，部署所声明的与实际执行所使用的之间的差异就变得至关重要。模型别名可能解析为不同的结果，某个功能或数据源可能改变，预处理和运行时配置可能演进，策略 v8 可能变成 v9。在智能体系统中，检索到的上下文、记忆和工具契约会引入更多独立的变更。部署标识描述的是所声明的内容，但执行的历史记录必须描述实际使用的内容。除非在绑定关系发生时将其捕获，否则 E891 的有效配置无法从后续的系统状态中可靠地恢复。

当前状态是一种有损投影

一旦将运行时绑定视为执行的一部分，当前状态记录的局限性就变得清晰了。执行作用域的依赖闭包是所声明状态与运行时绑定的组合，这些绑定构成了某次特定执行的有效配置。

随着依赖发生变更，不同的历史执行可能留下相同的可观察证据。当前状态可能显示哪些产物仍然存在，却不揭示某次特定执行使用了哪种组合。一旦那些具有区分作用的绑定消失，历史就无法从残留之物中重建。系统可以保留其产物，却失去可重建性：一个标识符既不能证明某个依赖被使用过，也不能证明它所表示的历史状态仍然可用。因此，可重建性需要持久的绑定关系，以及对它们所标识的历史状态的持续访问。

存在不等于使用

产物的存在与其在某次特定执行中的使用是不同的事实。并发的版本、缓存、重试和异步变更使得仅凭某个产物在相关时间点存在就推断某次执行使用了它变得不可靠。

W3C PROV 已经提供了相关的语义区分：一个活动可以使用一个实体。因此，缺失的原语不是新的溯源词汇，而是一项运行时要求：记录某次特定执行使用了哪个依赖，并保留一个日后可解析的标识。

这一要求也暴露了可观测性的局限。OpenTelemetry 可以通过属性、链接、上下文和 baggage 传输依赖标识符，但编码一个标识符并不保留其历史含义。追踪可能保留执行拓扑，而解释它的那些标识却消失了。插桩可以携带保存元数据，但它无法保证持久存储或对所引用状态的持续解析。

因此，历史可重建性需要的不仅仅是保留的产物。对于一类已定义的执行和指定的保留期，系统必须保留两个属性：绑定完整性，即记录某次执行实际使用了哪些依赖版本和状态；以及解析完整性，即保持那些被记录的标识可解析到它们所表示的历史状态。

保存需要失败语义

一旦将可重构性视为系统属性，架构就必须定义当重构一次执行所需的记录未能到达持久存储时会发生什么。假设策略 v8 授权执行 E891 调用工具合约 h42，且该工具提交了效果 e3。如果使用记录未能到达持久存储，该操作成功，而效果、其策略、工具合约与执行上下文之间的历史关联则丢失。外部效果仍然存在，但历史记录不再能可靠地解释是哪个策略和工具合约授权了它。外部世界与历史记录已经分道扬镳。

图 2 说明了为什么这种情况不能被视为普通的遥测丢失。当外部效果已提交但相应的使用记录缺失时，架构并不保证历史可重构性。它只提供尽力而为的历史证据。

只有当架构定义了保存记录何时变为持久，以及如果无法存储时系统会做什么，可重构性才成为一项工程保证。

系统可以要求在提交效果之前先有持久的使用记录，通过事务性发件箱原子性地持久化效果意图和保存记录，隔离该执行以进行对账，或触发补偿操作。具体实现因应用而异，但保存失败必须有明确的语义，而不是消失在遥测中。

现有技术为这一层提供了构建模块。溯源和谱系模型表示关系，追踪传播执行上下文，注册表标识版本，内容寻址存储保存工件。然而，它们都没有创建运行时义务来保存重构所需的执行范围依赖闭包。

这一层是一个保存平面：即随着周围系统变化，保持一次执行的依赖闭包可识别的合约与机制。它定义了记录什么、记录如何变为持久，以及被引用的状态如何保持可解析。Orrery 将这一原则作为参考架构加以应用，其中在运行时绑定发生时捕获具有实质相关性的绑定，并将其与它们所引用的历史状态的可解析标识一起保留。

AIGov Core：作为受测属性的可重构性

AIGov Core 提供了这一原则的有限实现。其证据账本存储哈希链事件，而其重放引擎从存储的导出中重构治理裁决，而不查询实时状态。一个配套检查根据未解析的谱系、缺失的策略工件、版本漂移或重放失败，将导出标记为 Ready、Partial 或 NotReady。这表明可重构性可以被测试，但它并未解决完整的保存问题。系统只能重放已记录的内容；它无法恢复从未被捕获的运行时绑定。

保存缺口是指执行所依赖的内容与系统所持久化的内容之间的不匹配。要弥合这一缺口，需要一项运行时义务：每当执行绑定具有实质相关性的状态时，系统必须记录该绑定，为该依赖保留持久身份，并在规定的保留期内保留对其所指历史状态的访问。因此，可重构性并非能力或可观测性的副产品。它是一种架构属性，必须在执行期间被设计、测试并强制执行。

来源：O'Reilly Radar · oreilly.com