一个 Amazon Ads 优化任务可能跨越数小时甚至数天：拉取报告，等待归因窗口，连接库存和利润，生成预算建议，交给投放负责人审批，再调用 API 执行。任务恢复时，campaign 仍在，acos 指标也仍在，系统却未必还处于原来的语义环境。API schema 可能升级，指标分母可能从归因销售改成净销售，ASIN 与 SKU 的映射可能换了版本，审批策略也可能收紧。
只保存对话和任务步骤，无法保证恢复正确。长时程 Agent 必须记住当时使用的 API、语义模型、本体、策略和数据快照，并证明这些版本在恢复时仍然兼容。 语义模型负责指标、粒度和执行路径，本体负责对象身份、关系和约束，两者演进速度不同，不能绑成一个版本号。双版本治理的目标，是让任务在语境发生变化时停止、迁移或重算，而不是在同名但已变义的对象上继续。
背景：长任务恢复时，环境已经不是原来的环境
广告优化不是封闭计算。campaign budget、Target state、placement multiplier 和库存会被人工或其他自动化同时修改；归因数据继续回填；Amazon Ads API 也有自己的兼容与发布节奏。Amazon Ads compatibility and versioning policy与 API release notes共同说明，集成方必须管理版本变化，而不能把端点当成永久不变的函数。
双版本书脊档案架把本节的判断压缩成可检查的关系：并列保存语义版本与本体版本。人物动作对应执行责任。
语义环境也在变化。团队可能把 profit_after_ads 从“售价减 COGS 和广告费”升级为扣除退款、履约变动费用和 marketplace fee；把 inventory_cover 从简单销量均值升级为带 lead time 与 reserve policy 的风险值；把 search term 收割从 7 天窗口改成成熟 14 天窗口。名称若保持不变，历史任务会悄悄读取新含义。
本体变化则更偏对象关系。新增 AutoTargetGroup 类、拆分 advertised ASIN 与 purchased ASIN、把 SellerOffer 从 ASIN 属性提升为独立实体、修改 NegativeKeyword 的作用域关系，都可能让旧查询路径失效。语义模型和本体经常在同一仓库，却不能因此假定同步演进。
长任务的 checkpoint 若只记录“已分析 37 个 campaign，下一步提交 12 个预算调整”，恢复时无法判断这 12 个候选是否仍成立。一个可用检查点必须包含版本依赖和外部状态指纹，并在继续前重新验证。
当下问题：同名指标和对象如何让任务悄悄变义
最隐蔽的事故来自兼容假象。字段仍存在，类型未变化，SQL 和 API 请求都能成功，因此技术监控认为任务健康；业务含义已经改变，结果却没有触发错误。比显式 400 响应更难处理，因为它会生成“成功执行”的错误动作。
策略快照三联夹把本节的判断压缩成可检查的关系：锁定指标、本体和策略的组合身份。人物动作对应执行责任。
第一种是假兼容指标。acos 过去使用 7 天 attributed sales，新版改用 14 天或净销售；查询仍返回 decimal。第二种是假兼容实体。asin 过去指 advertised ASIN，新版模型默认 purchased ASIN；Join 仍能匹配部分数据。第三种是假兼容策略。过去预算上限按 campaign，后来增加 portfolio ceiling，旧 Agent 仍只检查局部。
第四种是假兼容权限。用户仍能调用工具，但其 profile 授权或利润字段权限已经变化。若 Agent 沿用旧缓存，它可能泄露数据或执行越权动作。Amazon Ads API Policies提醒集成不仅受技术 schema 约束，也受平台政策和资格边界约束。
第五种是假兼容证据。Reporting FAQ涉及报告生成和更新，旧 checkpoint 中的 provisional 数据在恢复时可能已经回填。任务若直接执行旧建议，会忽略新事实；若静默改用最新数据，又失去原审批对应的证据。
双版本机制：语义模型与本体必须独立演进
语义模型版本管理可计算对象：facts、dimensions、metrics、time role、aggregation、join path、access policy 和 physical mapping。本体版本管理概念对象：Campaign、Target、SearchTermObservation、ASIN、SKU、Offer、Strategy、Evidence 及其关系和约束。两者通过明确依赖连接，例如 semantic model ads_profit_v4 依赖 ontology amazon_ads_core_v3.2。
为什么不共用一个 model_version？因为变化频率不同。财务可能只调整 contribution margin 公式，不改变 Campaign—ASIN 关系；Amazon 新增 Target 类型时，本体需要扩展，现有 ACOS 指标未必变化。绑在一起会造成无意义大版本，最终团队为了避免迁移而忽略版本号。
OWL 2 Overview涉及 ontology IRI、version IRI 与 imports，可为本体版本和依赖提供标准思路；SKOS Reference适合管理首选标签、别名、废弃术语和跨版本映射。工程上即使用 JSON/YAML 存储，也应保留等价的稳定身份和版本关系。
语义层可参考 dbt model versions的并行版本、latest version 与弃用思路，以及 dbt model contracts的字段和类型约束。但广告语义还需要业务兼容检查：指标公式、归因窗口、币种、成熟度或允许维度变化，即便 schema 未变，也可能是破坏性变更。
策略一：为每次投放决策冻结可重放合同
决策生成时创建 DecisionContract。它固定 task ID、profile、marketplace、目标对象 ID 与版本、数据 snapshot、API version、semantic model version、ontology version、strategy version、policy version、模型版本、提示模板哈希、审批要求和有效期。合同不可修改，变化通过新合同和 supersedes 关系表达。
历史决策取证桌把本节的判断压缩成可检查的关系：复原 Agent 当时看到的事实与规则。人物动作对应执行责任。
冻结不等于复制全部数据库。可以保存源报告 extract ID、仓库 snapshot 或 time-travel 指针、库存和 COGS 版本、查询计划与结果哈希。要求是能够重建当时可见证据，并证明重建结果未被后来转换覆盖。
PROV-O提供 Entity、Activity、Agent 与派生关系，PAV ontology进一步区分 provenance、authoring 和 versioning。应用到 Amazon Ads：数据快照和决策合同是 Entity，语义编译、模型分析、SHACL 验证、审批与 API 执行是 Activity，人、服务和 Agent 是不同责任主体。
合同还要区分建议有效期与数据成熟期。Amazon campaign recommendations guide说明推荐具有编辑、拒绝和过期边界。自建 Agent 的预算建议若等待两天审批，期间 campaign spend、库存和归因都可能变化。执行前必须检查合同是否过期，并重新评估变化是否跨过阈值。
可重放不意味着自动重做外部动作。重放默认只重建查询、指标和验证，API 写操作使用原执行记录核查，不因任务恢复再次发送。动作服务保存幂等键、请求与响应，状态不确定时先查询当前 campaign，而不是猜测上次失败。
策略二：用兼容矩阵和迁移计划控制升级
版本号只提供索引，兼容矩阵才决定任务能否继续。矩阵至少包含 API × semantic model × ontology × strategy × policy 的支持组合，并为每个组合给出 compatible、requires_recompute、requires_reapproval、requires_migration 或 blocked。
兼容性裂缝显微镜把本节的判断压缩成可检查的关系：识别字段同名但含义变化的破坏性更新。人物动作对应执行责任。
例如 ontology 从 v3.1 到 v3.2 只新增可选 SellerOffer 属性，旧查询可能兼容；若把 ASIN—SKU 从一对一改为带有效期多对多，依赖该路径的利润指标必须重算。semantic model 只修改描述文本，可以继续；若 TACOS 分母从 gross sales 改为 accepted net sales，即使输出类型相同，也必须新版本和重新审批。
Semantic Versioning的 MAJOR、MINOR、PATCH 可用于沟通，但不能机械套用。技术向后兼容不等于业务向后兼容。增加一个可选 dimension 可能改变 Agent 的查询选择，修正文档也可能改变同义词绑定。团队需要为 Amazon Ads 定义自己的 breaking change 分类。
迁移计划包括影响分析、双跑、回放、差异解释、消费者清单、审批、切换、观察和回滚。语义模型与本体先在 shadow 环境组合，使用真实 campaign、Target、search term、ASIN、placement、库存和利润样本回放。差异超出批准范围时停止，不以“新版更先进”覆盖无法解释的结果。
API 升级同样进入矩阵。release notes 触发契约扫描，识别新增、弃用和行为变化；执行器在沙箱账户做读写测试；未知枚举先进入 quarantine。只有 source adapter、ontology mapping、semantic model 和 action policy 都通过，生产 Agent 才允许切换。
策略三：让 Provenance 贯穿建议、审批与执行
一条预算建议应能回答：谁提出、基于哪些报告和库存、使用哪版指标和本体、通过哪些约束、谁批准、最终发出什么 API 请求、执行后观察到什么。若其中任一环只有自然语言摘要，事故复盘就会依赖猜测。
OpenLineage specification用 job、run、dataset 与事件描述数据血缘，适合连接抽取、转换和指标计算；PROV-O 更适合跨数据、策略和人员关系。两者可以共存：OpenLineage 记录 pipeline 事实，决策 provenance 记录语义解析、规则验证、审批和动作。
术语责任也要进入链路。DataHub Business Glossary和 OpenMetadata Glossary提供术语、关系、owner 与资产绑定的实现参考。对 Amazon Ads，ACOS、TACOS、profit、inventory cover、harvested search term 等术语应有 owner、定义、版本和适用范围。
provenance 不应只为审计服务。它还能回答变更影响：某个 metric version 被哪些 Agent、看板和策略使用；某条 ontology relationship 删除后，哪些 query plan 失效；某个 COGS 版本修正后，哪些预算建议需要重算。没有依赖图，迁移只能靠全量重跑或人工搜索。
执行后的观察也必须关联原合同。预算提高后，系统按预定窗口读取 spend、sales、利润、库存和 delivery 变化，区分 provisional 与 mature 结果。评测记录实际效果和边界是否触发，不能只记录 API 返回成功。
长时程状态机：何时继续、重算、重批或停止
任务状态至少包括 planned、evidence_ready、validated、awaiting_approval、approved、executing、observing、completed、stale 和 blocked。版本或外部状态变化会触发显式转换，而不是继续原步骤。
双轨发布站台把本节的判断压缩成可检查的关系：让语义与本体独立发布又共同验收。人物动作对应执行责任。
恢复流程先读取 DecisionContract，再查询兼容矩阵和当前 Amazon Ads 状态。如果只有非破坏性描述更新，任务继续；数据回填或指标变化则重新计算；建议数值或影响范围变化需要重新审批；对象删除、权限失效、未知 API schema 或本体路径不兼容直接 blocked。
检查点保存已完成事实和验证证据，不保存“应该没问题”的推断。模型对下一步的建议可以更新，已执行动作不可被新摘要改写。审批人看到的是新旧合同差异：哪些版本变了、结果变了多少、为何需要重批。
并发修改要用乐观锁或 etag。执行前比较 campaign budget、state、Target bid 与合同快照，若不同则重新规划。Agent 不得覆盖人工或另一个自动化刚做的变更，即使自己的建议在旧证据上仍然合理。
组织治理：版本不是数据团队的私有编号
语义模型 owner 通常由数据产品、分析工程和财务共同承担；本体 owner 需要投放领域专家、数据架构和平台工程；策略与动作权限由业务负责人和风险 owner 决定。一个团队单独改版本，其他团队事后适配，会让双版本治理退化为发布通知。
版本迁移对照灯箱把本节的判断压缩成可检查的关系：比较旧动作在新定义下是否仍成立。人物动作对应执行责任。
变更提案必须写业务影响，不只写 schema diff。比如“将 TACOS 分母改为 accepted net sales”要说明哪些 campaign 排名会变化、历史趋势是否重述、哪些 Agent 需要重批、何时停止旧版本。ontology 新增 SellerOffer 实体，要说明 Featured Offer 与库存决策路径如何变化。
TopQuadrant ontology governance和 Enterprise Knowledge 的治理文章索引可用于发现 steward、workflow 和变更管理实践，但它们是供应商材料。组织设计应由自身决策权和事故成本决定，不照搬工具角色。
每个版本设弃用窗口和使用遥测。旧版没有消费者后才能下线；仍有长任务引用时，保留只读重放能力或主动迁移。删除历史 schema 会让旧决策不可解释，存储节省通常抵不过审计损失。
评测与发布：用跨版本故障证明系统会停下来
回归集要覆盖非破坏性、需重算、需重批和完全阻断四类变更。样本包括 ACOS 窗口变化、币种换算策略变化、ASIN—SKU 基数变化、新 Target 类型、campaign 被人工暂停、权限撤销、库存快照过期和 API 返回未知枚举。
测试重点不是所有任务都继续，而是系统能在正确条件下停止。强行完成率越高未必越好；对于预算和负向投放，错误继续比明确 blocked 更危险。指标包括错误继续数、无必要重批率、重放一致性、迁移耗时、孤儿版本、未映射对象和 provenance 完整率。
发布采用双跑。旧版本继续服务生产，新版本在相同快照上生成查询与建议，比较结果、拒绝原因和动作资格。差异由领域 owner 解释并批准，再按 profile 或策略分批切换。出现异常时回滚版本指针，不覆盖新版本产生的证据。
社区关于 semantic layer 的讨论暴露业务定义维护和旁路查询问题；PPC 从业者讨论 AI 工作流则展示搜索词分析和竞价建议正在进入日常操作。这些材料用于发现真实需求，不能证明自动化有效或安全。
未来探索：让 Agent 理解变化，而不是只感知错误
未来 Agent 可以读取版本差异的机器语义：某个关系从一对一变成多对多，某个指标分母变化，某条策略提高审批等级。它不只是收到“版本不兼容”，还能生成影响分析和迁移建议。不过迁移计划必须由确定性检查和 owner 批准。
回滚坐标保险柜把本节的判断压缩成可检查的关系：保存可恢复的数据、规则与权限状态。人物动作对应执行责任。
语义与本体也可能形成标准化交换层，使 dbt、Cube、Snowflake、Databricks 和图系统共享部分实体、指标与 provenance。真正困难的不只是格式，而是业务兼容定义和治理权。没有 owner 和版本承诺，开放格式只会更快传播歧义。
长期还需要把模型、prompt、tool schema 与 eval set 纳入合同。模型升级可能改变对“可扩量”的解释，工具 schema 变化可能改变动作参数，评测集变化可能掩盖回归。它们与语义、本体版本关联，但仍独立发布，避免一个总版本掩盖根因。
一份最小兼容矩阵应该长什么样
矩阵不必一开始覆盖所有组合。可以先以正在运行的任务为中心，每行记录 consumer、semantic version、ontology version、API version、strategy version、policy version、支持状态、最后验证日期和 owner。没有消费者的理论组合不测试；有预算或负向写权限的组合优先级最高。
支持状态必须能驱动程序。compatible 允许继续但仍检查外部状态；recompute 丢弃旧结果并在原数据或最新数据上重算，由任务合同决定；reapprove 表示建议影响已变化；migrate 调用明确迁移器；blocked 停止并给出缺失依赖。不能只在 Wiki 表里写“可能不兼容”，运行时却默认继续。
每个状态配一个 Amazon Ads 样例。新增无关描述字段可 compatible；attributed sales 回填需要 recompute；预算建议从增加 10% 变成 25% 需要 reapprove；ASIN—SKU 关系升级为带有效期多对多需要 migrate；Target 类型无法映射则 blocked。样例比抽象定义更能让产品、投放和工程达成一致。
矩阵本身也版本化。规则改变后，旧任务按其创建时引用的兼容策略评估，除非安全策略要求强制升级。强制升级要留下原因和受影响任务清单，不能静默改变恢复结果。
不要把“长期记忆”误解为保存更多文本
长时程 Agent 常把阶段摘要写进向量库，恢复时检索相关段落。这可以帮助理解，却不能证明版本兼容。摘要可能遗漏 API、metric、ontology 和数据 snapshot，向量相似度也不会检查 campaign 当前状态。结构化合同是控制依据，文本记忆只是解释辅助。
任务需要保存的最小事实包括：目标、范围、禁止事项、当前状态、已验证产物、未决阻塞、版本依赖、外部对象指纹、动作幂等键和下一验证。模型推测、投放人员评论和后续建议分开存储，不与已核验事实混合。
恢复时先读取结构化状态，再按指针取原始证据，最后才让模型总结。顺序反过来，模型会先形成叙事，再选择支持叙事的记录。对于 budget、bid 和 negative target 这类会改变真实账户的动作，证据优先不是风格偏好，而是风险控制。
双版本治理的投入怎样衡量
版本系统会增加存储、测试和审批成本，不能把复杂度本身当成果。收益应从减少错误继续、缩短事故定位、降低迁移停机和提高历史可解释性衡量。若一个只读日报没有长任务消费者和写动作，可以使用较轻契约；涉及自动预算和流量阻断的模型，才需要完整兼容矩阵。
实施可以从事故代价最高的三条链开始：campaign budget、placement multiplier、negative targeting。统计过去版本变更造成的重跑、人工排查和错误动作，用它们设定基线。每次新版本发布记录受影响任务数、自动判定比例、重批次数和回滚时间。
治理成熟后，理想结果不是版本数量减少，而是变化影响更可预测。业务可以修改利润口径，平台可以新增 Target，Agent 可以升级模型；系统知道哪些任务继续，哪些必须停，并能把理由说明给真正承担投放结果的人。
还有一条容易遗漏的边界：历史可重放不等于历史规则仍可执行。组织可以保留旧 ontology、semantic model 和 strategy 以解释 6 个月前的预算决定，但执行服务只允许当前获批组合写入 Amazon Ads。旧版本进入只读档案，任何重放动作都生成新合同并重新审批，避免“为了复现”成为绕过现行治理的理由。
版本清理也要分层。临时构建产物可以删除，旧 schema 文档、迁移器、兼容判定和决策证据应按审计周期保留。一个版本没有线上消费者，不代表没有历史解释价值。删除前先验证所有 DecisionContract 仍有可解析路径，必要时将完整语义快照归档，而不是只留下 commit hash。
对外部服务商和多团队账户，还要在合同中固定责任边界：谁拥有 profile，谁批准策略，谁维护利润与库存，谁负责 API 失败和回滚。版本问题经常表现为技术不兼容，真正阻塞却是没有 owner。兼容矩阵没有责任人，就不会在截止日前产生迁移结论。
治理例会只讨论发生变化和存在风险的组合，不逐项朗读版本清单。系统提前生成受影响 campaign、运行中任务、待重批建议和无 owner 依赖，会议负责作决定。版本目录服务执行，决策记录服务问责，两者都比冗长汇报更重要。
总结概要：Agent 记住的应是可验证语境
长时程 Amazon Ads Agent 的记忆不是聊天记录，而是一套可重放合同：API、语义模型、本体、策略、权限、数据快照、审批和动作历史。恢复任务时，系统先验证版本与外部状态，再决定继续、重算、重批、迁移或停止。
演进谱系长卷把本节的判断压缩成可检查的关系：把每次投放决策连到可追溯版本祖先。人物动作对应执行责任。
落地顺序是：先给语义模型和本体建立独立版本，再为每次决策冻结合同和 provenance，随后建立兼容矩阵、迁移流程与跨版本回归，最后把状态机接到唯一动作入口。版本治理不会让策略停止变化，它保证变化发生后，Agent 不会假装自己仍理解原来的世界。