Amazon Ads 自动化最危险的时刻，往往不是模型完全不懂投放，而是它只掌握了局部事实。某个 campaign 的 Top of Search ROAS 正在上升，推荐提高 placement multiplier；同一 ASIN 却只剩数天可售库存，下一批货还没有确定入仓日期。单看广告报表，扩量有依据；把利润、库存和补货放进来，这个动作可能立刻失去资格。
这类事故不能靠提示词里的“请谨慎”解决。模型负责提出候选动作，确定性约束负责判断动作是否有资格进入审批和执行。 本体说明 campaign、Target、ASIN、库存、利润和策略之间的关系，SHACL 检查图中是否满足结构与数值约束，策略引擎处理权限、审批和运行环境。三层必须分工，否则规则会变成难维护的脚本堆，或者变成一张无法阻止 API 调用的治理海报。
背景：推荐越来越快，确定性边界反而更重要
Amazon Ads API 支持程序化管理 campaign、budget 与 bid，官方 API 介绍也把自动化优化列为典型用途。预算规则指南说明日程型和表现型规则可以在特定时期或达到 ROAS 等门槛时调整预算与竞价。平台能力减少了人工操作，但没有替广告主判断毛利、库存和现金边界。
投放提案安检台把本节的判断压缩成可检查的关系：把 Agent 建议先变成待验证关系图。人物动作对应执行责任。
推荐速度提高后，错误动作的传播速度也提高。小时 spend 可以很快进入系统，转化仍需归因成熟；库存快照可能延迟，COGS 可能刚换版本；一个 campaign 还可能同时推广多个利润结构不同的 ASIN。若自动化直接读取聚合 ROAS，再执行 campaign 级预算增长，局部高表现会放大到全部 Target。
Amazon campaign recommendations guide保留了编辑、拒绝、过期和持续监控等产品边界。这一设计很有价值：推荐不是命令，它有适用对象、证据时点和有效期。自建 Agent 若把“生成建议”和“获得执行授权”合并，反而退回了更粗糙的控制模式。
业务上真正需要的不是更多阈值，而是明确的动作资格。提高 bid、增加 budget、调整 placement、添加 negative target、暂停 campaign，风险结构不同。每类动作都应有自己的证据要求、最大变化、审批等级、回滚方式和冷却期。SHACL 可以把其中确定、可验证的部分写成机器约束。
当下问题：阈值脚本为什么挡不住业务事故
常见规则是“ROAS 大于 4 则预算增加 20%”“ACOS 高于目标且点击超过 20 则降价”“库存少于 7 天则暂停”。这些规则容易实现，也容易失控。阈值来自哪里、适用于哪个 marketplace、哪个商品阶段、哪种归因窗口、何时到期，通常没有进入代码的输入结构。
六道经营边界栅栏把本节的判断压缩成可检查的关系：并列预算、库存、利润、新鲜度、归因和批准约束。人物动作对应执行责任。
第一个缺陷是对象错配。campaign 级 ROAS 达标，不代表其中每个 ASIN 都能扩量；ASIN 级库存健康，也不代表所有 seller offer 都拥有 Featured Offer。规则若不知道动作作用域与证据粒度，就会用上层平均值替下层对象做决定。
第二个缺陷是缺少数据状态。spend 已到、sales 尚未回填时，ACOS 暂时升高；库存接口失败时，系统沿用昨天的可售数量；COGS 未匹配时，利润被当成零或沿用默认毛利。脚本仍会给出布尔结果，因为它没有“证据不完整”这种一等状态。
第三个缺陷是规则之间没有组合语义。Amazon 帮助页对预算规则的说明涉及多规则同时生效的场景。自建系统若又叠加 campaign budget、portfolio ceiling、账户现金上限和大促策略，单条规则正确并不代表组合结果安全。需要检查最终动作，而不是逐条检查局部增量。
第四个缺陷是执行绕过。团队可能在数据平台中建立完整指标，却允许 Agent 直接调用 Amazon Ads API；也可能在 UI 里展示审批，后台重试任务却只凭旧 token 重放请求。治理若不位于唯一动作入口，就不是门禁，只是建议。
约束机制：本体、SHACL 与策略引擎各管一层
本体负责描述世界：Campaign 包含 AdGroup，AdGroup 配置 Target，Target 推广 AdvertisedProduct，AdvertisedProduct 映射 ASIN/SKU/Offer，策略动作作用于其中某个对象，EvidencePackage 连接报告快照、库存、利润和审批。它回答“谁与谁有关”，不直接回答当前用户是否有权限执行。
SHACL Recommendation用 NodeShape、PropertyShape 和 constraint component 验证 RDF 数据图。它适合表达：BudgetIncreaseAction 必须只有一个目标 campaign；百分比不得超过策略上限；证据包必须包含成熟的归因窗口；每个目标 ASIN 必须有新鲜库存；高风险动作必须带审批 ID。验证结果还能给出 focus node、path、severity 与 message，便于解释拒绝原因。
SHACL Advanced Features提供规则和更复杂的节点表达能力，但不能因为“能写”就把所有业务逻辑塞进去。需要访问实时账户余额、组织角色或外部审批系统的规则，更适合放在 policy engine。需要计算预测断货概率或增量价值的部分，属于模型或分析服务。Shape 只检查它们的输出是否存在、版本是否合法、置信边界是否满足。
OWL 2 Profiles提醒架构师在表达能力和可计算性之间取舍。Amazon Ads 行动门禁不需要追求最强推理，反而应让关键约束可预测、可测试、可在发布前运行。能用枚举、数量、范围和明确关系表达的，不必引入难解释的开放世界推断。
策略引擎负责主体、资源、动作和环境。Open Policy Agent展示通用 policy-as-code 模式，Amazon Verified Permissions则提供 Cedar 下的授权模型参考。它们不是 Amazon Ads 内置能力，但能帮助划清边界：SHACL 验证决策对象是否合格，授权策略判断这个操作者能否在当前环境执行。
策略一：把预算和竞价边界写成可验证 Shape
预算增长动作可以建成 BudgetIncreaseAction，属性包括 target campaign、current budget、proposed budget、currency、effective window、reason、evidence、strategy version、requested by 和 approval。Shape 不只检查 proposed > current，还检查币种一致、增长幅度不超过当前策略上限、campaign 属于获批 portfolio、动作窗口不与另一个未结束动作重叠。
断库存红牌现场把本节的判断压缩成可检查的关系：阻止向不可售 ASIN 继续加价。人物动作对应执行责任。
placement 调整需要计算乘法链。基础 bid、Top of Search multiplier、Rest of Search multiplier 与动态竞价共同决定潜在竞价上界。Shape 可以要求动作包必须携带 effective_max_bid，并验证它不超过 ASIN 利润模型给出的 max CPC。这样能防止每个局部倍率都在范围内，组合后却越过损失边界。
规则的数值对象必须带单位和货币。20 可能是美元预算、20% 增幅或 20 个库存单位；只验证 JSON number 没有意义。预算 Shape 应要求 MoneyValue 绑定 currency，比例使用明确小数范围，日期使用 profile timezone，所有上限引用策略版本。跨 marketplace 执行前先分解成各 profile 动作，不能用集团人民币上限直接比较美元 campaign budget。
还要检查动作节奏。一次增加 20% 合法，不代表 10 分钟内连续执行 5 次仍合法。约束需要读取 action history，验证冷却期、当天累计增幅和未完成观察窗口。历史不是日志附件，而是资格判断的一部分。
策略二：把库存与利润纳入动作资格判断
库存门禁不应只有 available_units > 0。可售、预留、在途、不可售和预计到仓具有不同含义。动作包至少给出 inventory snapshot time、decision available units、需求预测、补货 lead time、reserve policy 与 stockout risk。快照过旧或在途日期不确定时，扩量动作进入拒绝或人工复核，而不是沿用上次值。
预算越界测量门把本节的判断压缩成可检查的关系：比较动作差异与剩余风险额度。人物动作对应执行责任。
利润门禁同样需要版本。广告前贡献应扣除有效 COGS、平台及履约变动费用、折扣和预期退款。campaign 同时推广多个 ASIN 时，不能用平均毛利证明全部扩量安全；若 spend 无法可靠分配到商品，系统只能给 campaign 级风险区间，不能伪造精确净利润。
Shape 可以要求每个受影响 ASIN 都存在 ProfitabilityAssessment，并带 effective COGS version、accepted revenue definition、attribution maturity 和 confidence range。它不负责预测利润，而是拒绝缺字段、过期版本和越界结果。数据质量由 dbt data tests或 Great Expectations验证，本体约束再判断这些数据是否足以支持动作。
一个实用规则是把动作资格分为 allow、limit、hold。库存和利润证据完整且在边界内，可 allow；库存趋紧但仍需维持品牌防守，可 limit bid 或 budget 上限；快照过旧、Featured Offer 丢失、利润版本缺失或断货风险过高，直接 hold。三态比真假更贴合投放业务，也为恢复提供明确条件。
负向投放也受经营约束。某 search term 暂时高 ACOS，却在新品阶段贡献高价值查询发现；添加 negative phrase 可能阻断一组长尾。高覆盖负向动作必须给出预计受影响 Target、成熟订单、利润和探索价值，不能只凭 spend 阈值自动执行。
策略三：用分级审批和证据包控制执行
动作风险由影响范围、可逆性、金额、证据成熟度和对象重要性共同决定。单个低 spend Target 小幅降 bid，可能无需人工；campaign 级 budget 增长、placement 大幅调整、核心品牌词负向和 portfolio 级暂停，需要审批。审批不是一律加人，而是在风险跃迁处增加独立判断。
SHACL 形状模具台把本节的判断压缩成可检查的关系：用形状约束检查节点、关系和值域。人物动作对应执行责任。
每次建议生成不可变 EvidencePackage，包含对象快照、报告版本、指标合同、库存与利润版本、模型输出、Shape 验证、策略判断、预期效果、最坏损失、观察窗口和回滚条件。PROV-O可用于组织 Entity、Activity 与 Agent 的派生关系，使建议、验证、审批和执行能够串回同一证据链。
执行服务只接受已通过所有门禁的 decision ID，不接受任意 campaign ID 和新 budget。它重新读取当前状态，检查证据是否过期、对象是否已被他人修改、审批是否仍有效，然后生成带幂等键的 Amazon Ads API 请求。重试前查询动作状态，避免超时后重复增加预算。
Amazon Ads compatibility and versioning policy意味着执行器还要固定 API 版本和 schema。Shape 基于旧字段通过，不代表新版本请求仍合法。升级先跑契约测试，再切换执行流量；遇到未知字段或枚举，默认停止而不是猜测映射。
审批结果也要回流。投放人员拒绝建议时，记录原因是库存、利润、品牌策略还是证据不足；系统把它用于评测和规则改进，但不能让模型直接改写硬门禁。硬约束变更仍走版本、评审与回归。
工程落地：从 Shape 目录到唯一动作入口
代码仓库建议分为 domain ontology、shape library、policy、strategy profile、test fixtures 与 action service。每个 Shape 有 owner、版本、适用广告产品、严重级别和失效条件。Shape 变更通过代码评审，不允许在运行时由 LLM 临时生成并立即生效。
违规原因码票据机把本节的判断压缩成可检查的关系：输出可审计的失败原因而非模型解释。人物动作对应执行责任。
pySHACL适合 Python 数据和 Agent 服务，Apache Jena SHACL适合 Java 体系，RDFLib可处理 RDF 图与查询。选型取决于现有栈，治理语义应保持一致。复杂场景先建立最小图投影，不必把全部广告明细转成三元组。
运行链可以是：语义查询生成候选动作；Evidence Builder 固定输入版本；SHACL Validator 检查结构、范围和依赖；Policy Engine 检查权限与审批；Action Service 重新核对当前状态并执行；Observer 在窗口结束后评估结果。任一阶段失败，都返回结构化原因并停止后续步骤。
测试要包含正例、负例和组合事故。正例证明合法预算调整能通过；负例覆盖缺失币种、过期库存、未成熟归因、利润越界和无审批；组合事故验证单条规则都合法但总增幅超限。还应做 mutation testing，故意删除关键约束，确认测试会失败。
验证与评测：门禁是否真的减少错误动作
不能只统计“Shape 通过率”。真正指标包括危险动作拦截率、合法动作误拒率、人工审批负担、执行失败、重复副作用、回滚次数、证据过期率和从拒绝到补齐证据的时间。规则太松会漏事故，太严会让投放系统失去响应速度。
离线用历史 campaign、Target、ASIN、库存和利润快照回放。对每次真实动作构造当时可见证据，比较门禁是否会阻止后来被证明有害的扩量，同时检查是否错过有效机会。Learning SHACL Shapes from Knowledge Graphs研究自动学习 Shape，但生产约束仍应由领域 owner 审批；历史相关性不能自动升级为硬规则。
上线先 shadow mode：系统生成验证结果，却不阻断人工操作。积累误拒与漏检后，再让低风险动作强制经过门禁，高风险动作保留审批。每个版本用相同回放集比较，不以“规则更多”作为成熟度。
社区对语义层可靠性的 Reddit 讨论和关于关键词利润分析的 Substack 文章可用于发现旁路、维护和 TACOS 分析问题，但不提供 Amazon Ads 硬事实。关键能力与字段以 Amazon、W3C 和实际账户验证为准。
未来探索：约束可以学习，但不能自行获得权力
系统可以从历史审批和事故中发现候选 Shape，例如某类低库存 ASIN 在预算增加后频繁断货，或某类 placement 动作常越过利润边界。模型负责聚类、解释和生成候选规则，领域专家决定是否纳入策略，以及适用对象和到期时间。
确定性门与概率性脑双舱把本节的判断压缩成可检查的关系：分离规则拒绝与模型判断。人物动作对应执行责任。
还可以发展风险自适应门禁。规则稳定、影响小、可逆的动作减少人工；新广告产品、未知 schema、重大预算或跨 marketplace 动作提高审批等级。自治程度随着证据积累变化，而不是由一个全局开关决定。
约束本身也需要 provenance。每个 Shape 记录来源、提出者、批准者、适用版本、回归结果和替代关系。删除规则不是清理文件，而是一次治理变更，需要解释为何不再保护原边界。
一组值得先落地的十二条硬约束
第一批 Shape 应选择没有争议、事故代价高且能稳定验证的条件。预算增长动作必须绑定唯一 campaign 和 profile；动作币种必须与 profile 一致；建议值必须大于当前值且不超过策略上限；同一 campaign 在冷却期内不得重复扩量；证据包必须包含归因成熟状态；所有受影响 ASIN 必须存在有效库存快照；利润模型必须绑定有效 COGS 版本；库存和利润覆盖不足时不得自动执行；高风险 placement 调整必须有审批；负向 phrase 必须给出影响集合；暂停动作必须声明恢复条件；API 请求必须携带幂等键和当前对象版本。
这十二条不追求覆盖所有投放智慧。它们保护的是结构完整、版本一致和最小经营边界。诸如“目标 ACOS 应为多少”“新品应该探索多久”仍由 strategy profile 决定，Shape 只要求策略存在、适用范围正确并经过批准。把判断题与完整性检查分开，规则库才不会因业务策略变化频繁重写。
每条约束配三类测试数据：最小通过样本、只违反该约束的单一失败样本、同时违反多条约束的组合样本。验证报告应稳定返回 focus node、constraint ID、业务化 message 和修复建议。若一条规则只能由写它的人看懂，它还不具备生产治理价值。
事故响应也必须经过同一门禁
预算异常消耗或错误负向投放发生时，团队容易要求“先暂停全部 campaign”。紧急 containment 可以简化审批，却不能绕过对象解析和影响范围。系统至少确认 profile、campaign 集、当前 state、已发生 spend 和恢复责任人，并为批量暂停生成可回滚清单。
紧急策略应是独立版本，权限更窄、持续时间更短。它允许停止新增风险，不允许顺手重构 bid 和 budget。事故解除后，恢复动作重新读取最新库存、利润和 Target 状态，不能机械恢复到事故前数值，因为期间 campaign 和市场可能已经变化。
门禁日志帮助区分三类根因：规则正确且成功拦截，规则缺失导致动作通过，规则存在但执行入口被绕过。第一类用于证明控制有效，第二类进入 Shape 设计，第三类优先修复架构。事故复盘若只讨论模型为什么建议错误，会忽略更严重的问题：系统为何允许未经完整证据的建议直接改变投放。
最终，SHACL 的作用不是替业务决定，而是保证每次决定都携带业务声称需要的证据。它把“业务通常会看库存和利润”变成“没有库存和利润版本，动作服务就不会接受请求”。从经验到制度，差别就在这一步。
约束发布还需要灰度。新 Shape 先在历史证据包上回放，再进入 shadow mode，只记录原本会拦截的 Amazon Ads 动作；投放和风险 owner 复核误拒后，才对低风险账户强制执行。出现大量未知对象或误拒时，回滚的是 Shape 版本，不是删除验证日志。每次灰度都应固定账户范围、起止时间和成功指标。
对规则性能也要设预算。验证图若包含整个账户所有历史 search term，动作入口会因延迟失去可用性。运行时只投影本次 campaign、受影响 ASIN、有效策略和最近证据；全账户一致性放到异步巡检。局部验证与全局审计使用同一 ontology ID 和 Shape 版本，结果才能互相解释。
最后检查旁路。控制台人工操作、批量文件、定时脚本和 Agent API 都可能修改 budget、bid 或 negative target。若组织无法把所有入口收敛，至少用持续对账发现未携带 decision ID 的变更，并将其标为 unmanaged action。门禁覆盖率需要可量化，否则“所有自动化都受治理”只是一句无法验证的承诺。
门禁负责人每月抽查被允许、被限制和被拒绝的动作各一组，确认 Shape 的文字解释与真实 Amazon Ads 后果一致。抽查发现口径偏差时，先冻结相关自动化，再修规则和回归集，不让模型用新的自然语言解释掩盖旧约束的缺陷。
总结概要：规则的价值在于拒绝不完整证据
Amazon Ads Agent 的建议可以是概率性的，预算、库存、利润和权限边界必须是可执行的。阈值脚本失败，不是因为条件写得少，而是对象、作用域、数据状态、规则组合和唯一执行入口没有被共同治理。
灰度启用封条板把本节的判断压缩成可检查的关系：从影子校验、人工批准走向有限自动化。人物动作对应执行责任。
落地顺序应当克制：先定义动作对象与证据包，再用 SHACL 编码少量不可妥协的不变量，用策略引擎处理授权和审批，最后把所有写操作收敛到同一个 Action Service。门禁不是为了让系统少做事，而是让它在证据不完整、组合风险过高或语义不兼容时有能力明确拒绝。能可靠说“不”，才是自动化开始承担业务责任的标志。