上一篇把语义层解释为业务问题与数据执行之间的编译器。它解决了一个重要但有限的目标：同一个问题在对象、指标、时间、权限和版本确定后，能够生成同一份可验证的查询计划。到这里，系统仍然只是回答问题。
当答案继续触发动作，系统的性质会发生变化。“美国站哪些 campaign 值得加预算”与“把这些 campaign 的预算提高 20%”只差半句话，工程责任却完全不同。前者的错误可能让用户看到一个不准确的排名；后者的错误会消耗真实预算、改变竞价学习、影响库存节奏，并可能在多个客户账户产生连锁后果。
大模型并不承担这部分确定性。它可以理解目标、组合工具和处理例外，却不能仅凭一次推理证明当前用户有权修改这个 profile，不能证明数据已经度过归因窗口，也不能保证重试不会执行两次。模型越擅长调用工具，运行时越需要把企业语义变成硬边界。
Agent 进入生产以后，企业语义不再只是“模型应该知道什么”，而是“系统允许它在什么状态下，以什么证据、权限和责任执行什么动作”。 指标、实体、本体、政策、工具和动作必须汇合为同一份运行合同；缺少其中任何一类，Agent 都只能安全地停留在建议层。
本文以 Amazon Ads 投放为完整案例，讨论从语义查询到决策提案、从提案到受控动作、从单次调用到跨归因周期长期任务的运行架构。厂商产品仍会进入分析，但不按品牌罗列，而是按它们把语义推进到“检索、查询、推理、决策、行动”的哪一层来比较。
一、先区分五种结果：检索、回答、查询、决策与行动
智能产品常把五种不同结果放在同一个聊天界面里。用户问“为什么美国站广告利润下降”，系统可能返回一段制度文档、一个查询结果、一条原因推断、一个调价建议，甚至直接修改预算。界面连续不代表责任连续。
检索返回相关材料，例如广告归因说明、利润政策或历史复盘。它的核心指标是相关性、权限、新鲜度和来源。Glean、Coveo、Elastic、Atlan、Alation、Google Knowledge Catalog 等产品主要在这一层提供能力。
回答把检索内容与模型知识组织成解释。它需要引用证据、标出不确定性，但不一定访问结构化事实。大模型在这里可以发挥通用知识优势。
图 1：检索、回答、查询、决策和行动逐级增加证据与后果（概念示意）
查询把问题编译为结构化请求并计算当前数据。它依赖指标、实体、时间、关系和访问策略。Cognos、Power BI、Oracle Analytics、Looker、Tableau Semantics、Snowflake Semantic Views、Databricks metric views、ThoughtSpot、Cube、dbt 与 Wren AI 主要解决这类语义。
决策在查询结果之上应用目标、约束、预测和取舍，输出带证据的 Proposal。例如“campaign A 建议增加 15% 预算，预计多消耗 200 美元；若库存覆盖低于 18 天则失效”。它不是一个更长的答案，而是可以被审批和复盘的业务对象。
行动修改真实系统。它需要当前状态检查、授权、幂等、限额、回执、回查和补偿。Palantir Ontology 的 Actions、ServiceNow workflow、SAP 的业务流程、Microsoft Fabric IQ operations agent 等路线之所以受到关注，是因为语义开始越过分析边界，进入运行世界。
五层可以由同一平台覆盖，也可以由多种系统组合。重要的是每次结果都带类型，不能让一段模型文本悄悄升级为动作参数。查询通过不代表决策通过，决策获批也不代表执行时状态仍然有效。
二、企业 Agent 需要六本账，而不是一个超级 Prompt
把所有规则、示例和接口说明写进 system prompt，早期原型看起来很快。进入生产后，Prompt 会同时承担领域知识、查询模板、权限、策略、异常处理和工具说明，任何改动都可能影响全部行为。更严重的是，Prompt 不擅长表示动态状态和强制约束。
一个可治理运行时至少需要六本彼此关联、又独立版本化的账。
1. 对象账：系统讨论的到底是谁
对象账保存稳定身份、类型、关系和生命周期。Amazon Ads 中 SearchTermObservation 是一次在特定报告窗口观察到的顾客查询，不等于 KeywordTarget；AdvertisedASIN 与 PurchasedASIN 承担不同归因角色；同一个 campaign ID 还要放在 profile、marketplace 和广告产品命名空间中理解。
对象账可以由主数据、语义模型、本体或运营对象层承载。它必须处理别名和映射，却不能把业务上不同的东西为了 Join 方便而合并。若身份不稳定，Agent 无法计算影响范围，也无法在执行前确认目标还是原对象。
2. 指标账：系统依据哪一种表现
指标账保存公式、聚合、时间、币种、来源和适用域。ACOS、ROAS、TACOS、CPC、CVR、new-to-brand、贡献利润和库存覆盖天数都要有版本。一个指标值必须能够回到分子分母与数据快照，而不是只保留最终小数。
图 2：对象、指标、政策、能力、决策与执行共同传动（概念示意）
指标账还要记录成熟度。Amazon Ads 的归因转化可能在点击之后到达；最近几天的 sales 与 orders 仍会回填。系统可以展示 provisional 数据，但不能在策略要求 stable-only 时把它混入长期预算判断。
3. 政策账：组织愿意接受什么取舍
政策账把目标和边界写成可执行条件。新品可能容忍较高 ACOS 换取发现，成熟商品要求贡献利润，品牌防守关注流量保护，清库存活动接受另一组边界。政策不能只是“降低 ACOS”这样的自然语言目标，而应引用指标版本、适用对象、阈值、观察期、例外和审批级别。
4. 能力账：Agent 到底能调用什么
能力账登记工具、输入输出 schema、数据权限、写权限、风险等级、成本、超时、幂等支持和依赖。MCP 可以标准化工具发现与调用，但工具描述来自 server，客户端不能把描述本身当作可信业务语义。MCP tools 规范建议保留人类拒绝工具调用的能力，也提醒 annotations 不能天然被信任。
5. 决策账：为什么产生这个 Proposal
决策账保存意图、候选对象、证据快照、语义计划、策略版本、预期收益、风险、反证、失效条件与人工判断。它连接“查询正确”与“动作合理”。未来结果变差时，团队需要知道当时看到了什么，而不是只看一段聊天记录。
6. 执行账：外部世界实际发生了什么
执行账保存动作计划、批准租约、幂等键、请求、响应、远端状态、重试、补偿与回查。Amazon Ads API 返回成功只说明请求被接受到某一步，运行时还应再次读取对象状态，确认预算、bid 或 negative target 已达到期望值。
六本账不能混成一张日志表。对象和指标演进较慢，政策可以按运营周期变化，能力会随接口版本改变，决策与执行则持续增长。它们通过稳定 ID 和版本快照关联，才能既复盘旧动作，又允许新版本继续演进。
三、市场产品的分水岭：语义有没有进入运行时
上一篇按产品路线拆开分析语义、headless 语义、目录、本体和搜索。本篇换一个角度：产品把语义推进到哪里。
停在检索和上下文：找到正确材料，但不替你执行定义
Glean 的企业搜索和 knowledge graph、Coveo 的 relevance 能力、Atlan 的 active metadata、Alation 与 Informatica 的治理上下文，能够让 Agent 找到术语、负责人、血缘、文档和相关资产。这一层对于“知道去哪里查”非常重要，却不自动生成唯一指标计划。
图 3：检索、查询、推理与行动线路在不同能力站点换乘（概念示意）
IBM watsonx.data intelligence 与 Semantic Automation Layer 值得放在这里和下一层之间看。SAL 用业务术语与描述增强元数据，使自然语言可以更好地发现表和视图；watsonx BI 又进一步从增强元数据形成反映业务逻辑的 semantic data model。IBM 的产品线说明目录语义可以成为查询语义的输入，但两者仍是不同责任。
进入查询编译：业务语言被转换为受治理计算
Tableau Semantics 的 structured semantic query、Snowflake semantic views、Databricks metric views、Power BI semantic models、Oracle semantic models、LookML、MetricFlow、Cube 与 Wren MDL 都允许上层请求业务对象和指标，再由引擎解析物理查询。
这类产品的生产价值取决于能否暴露计划和拒绝非法请求。Snowflake 在 2026 年 8 月建议从 Cortex Analyst 迁移到 Cortex Agents，并说明 Agent 继续使用相同 semantic views 和 verified queries；Tableau Next 的 MCP 暴露 semantic models、metrics 与分析能力；Wren 提供 dry-plan 和 dry-run。它们都在把语义从静态说明推进为可检查的执行中间层。
进入对象和推理：系统理解关系、状态和影响范围
W3C RDF/OWL/SHACL/SPARQL 生态、Stardog、Ontotext GraphDB、TopBraid EDG、PoolParty、Neo4j 与 RelationalAI 主要让语义进入关系查询、约束或推理。Ontotext GraphDB 的推理文档区分规则集和 materialization；SHACL 输出验证报告；Neo4j GraphRAG 把图检索提供给生成式应用。它们解决的不是同一种“推理”，实施时必须区分逻辑蕴含、图遍历、规则计算、统计预测与 LLM 推断。
RelationalAI 以关系知识图谱和声明式逻辑连接数据、规则与决策计算，适合需要复杂依赖、优化和可评分决策的场景。它不是通用 BI 替代品，也不因使用“ontology”或“decision intelligence”就自动拥有业务 Action；执行边界仍需具体设计。
进入运营动作：对象、逻辑、权限和工作流共同生效
Palantir Ontology system把 data、logic、action、security 作为同一运行系统的四部分，Actions 和 Functions 直接连接对象与外部系统；ServiceNow Workflow Data Fabric把数据产品、稳定合同、Knowledge Graph、workflow 和 AI agents 放在工作平台中；SAP Knowledge Graph 为 Joule 与业务 Agent 提供 SAP 语境；Microsoft Fabric IQ 则把 semantic model、ontology、graph、data agent 与 operations agent 组合在预览体系中。
这类平台的价值不只是模型更丰富，而是对象能进入权限、应用和动作。但“平台支持写回”不能代替业务方案。Amazon Ads 的 regional endpoint、API 限流、异步报告、远端状态、部分成功、归因延迟和客户审批仍需要领域适配器与 Harness 处理。采购一套运营平台，不会自动获得安全的投放 Agent。
四、从语义查询到动作，需要三种中间产物
上一篇强调自然语言不能直达 SQL。进入行动后，还要增加两次编译：查询结果不能直达策略动作，策略建议也不能直达外部 API。
第一种产物：Semantic Request
Semantic Request 固定查询意图、对象、指标、时间、范围和访问上下文。它由语义编译器生成，经过模型存在性、关系路径、聚合、权限和成本检查后，才转为 SQL、SPARQL、KQL 或 API read plan。
第二种产物：Decision Proposal
图 4：Semantic Request、Decision Proposal 与 Action Plan 逐舱验签（概念示意）
Decision Proposal 把观察提升为决策候选。它至少包含：目标对象、before state、证据、策略版本、候选变化、预期结果、风险、影响半径、反证、失效时间和是否需要审批。Proposal 是不可变快照；新的数据到来后产生新版本，而不是覆盖旧判断。
第三种产物：Action Plan
Action Plan 在批准时生成，保存具体工具、参数、顺序、补偿、幂等键、授权租约和 preflight。它引用 Proposal，却必须重新读取当前状态。如果 campaign budget 已被人工修改、库存跌破边界或批准租约过期，Action Plan 应失效并回到决策阶段。
三种产物的拆分避免了“一个 Agent 包办全部”。查询 Agent 可以只有只读权限，策略引擎生成 Proposal，审批服务授予短期能力，执行 worker 按计划调用 Amazon Ads API。任何模型输出都不直接成为写请求；真正执行的是已验证的类型化计划。
从自然语言到行动至少要经历两次可拒绝的语义编译：问题编译为查询计划，结论编译为动作计划。一次生成到底的 Agent 无法证明自己在哪一层犯错。
五、Amazon Ads 的运行时对象，不能照着 API 资源表抄
API 资源是系统集成边界，不是完整业务本体。Campaign、AdGroup、Target 等资源可以直接映射一部分对象，但投放决策还需要观察、策略、提案、批准和执行记录。若只照着 API 建模，系统会知道“能修改什么”，却不知道“为什么应该修改”。
一个实用的运营模型可以分为五个域。
广告配置域保存 Profile、Marketplace、Portfolio、Campaign、AdGroup、Ad、Target、NegativeTarget、PlacementAdjustment、Budget 与 BidStrategy。对象身份采用 provider + region + profile + ad_product + remote_id 组合，而不是只用远端数字 ID。
图 5：账户、投放、意图、商品经营和证据时间跨域连接（概念示意）
顾客意图域保存 SearchTermObservation、TargetMatch、QueryCluster、BrandTerm、CompetitorTerm 与 RelevanceJudgement。Search term 是观察到的顾客输入，keyword target 是广告主配置，二者通过某次匹配观察关联，不能合并成同一实体。
商品经营域保存 ASIN、SKU、Offer、InventorySnapshot、PriceSnapshot、FeaturedOfferState、COGSVersion、MarginPolicy 与 RetailReadiness。广告对象与商品对象通过 advertised role 和 purchased role 分别连接。
测量证据域保存 ReportArtifact、MetricObservation、AttributionWindow、DataMaturity、CurrencyRate、CoverageAssessment 与 ReconciliationRun。每个指标值都引用来源、grain、窗口和快照。
决策执行域保存 StrategyPolicy、DecisionProposal、ApprovalLease、ActionPlan、ExecutionAttempt、RemoteReceipt、OutcomeObservation 与 ReviewCase。这里把建议、授权、执行和后果变成一等对象。
五个域不是为了把系统画得复杂，而是阻止关键概念被压进一张“campaign_daily_performance”宽表。宽表适合查询，不能独立表达搜索词迁移后的结构变化、一次预算调整的批准期限，或一个执行请求与远端回执之间的关系。
对象身份需要时间，而不只需要主键
业务对象会改变状态和归属。Campaign 可以从 enabled 变为 paused，ASIN 的 Featured Offer 与库存持续变化，服务商对 profile 的授权也可能撤销。运行时不能只查询“当前表”，还要知道 Proposal 生成时看到的版本。
因此对象引用至少包含 object_id、observed_at、source_version 和 effective_interval。静态身份与动态快照分开：Campaign 身份保持稳定，budget、state、strategy 等属性通过版本或事件变化。执行前比较 Proposal 的 baseline 与当前版本，发现差异后按策略重新计划，而不是盲目覆盖。
关系也有来源、置信度和有效期
SKU 到 ASIN 的映射、search term 到 query cluster 的归类、campaign 到经营目标的归属，并非都像数据库外键一样确定。关系需要标记 asserted、derived 或 predicted，保存来源、置信度、验证人和有效期。模型预测的“竞品词”不能与人工确认的 brand term 获得相同执行权。
OWL 可以表达类、属性与部分逻辑公理，PROV-O 可以描述来源活动，SHACL 可以验证 Proposal 形状；属性图也可以直接把证据放在节点和边上。技术选择不同，关键要求相同：运行时必须区分事实、规则推导、统计预测和 LLM 判断。
六、语义层、本体、知识图谱和策略引擎怎样分工
很多架构在这里失控：团队把所有东西都塞进知识图谱，或者反过来要求指标层承担全部关系推理。更稳妥的分工按问题性质确定。
语义指标层负责高频聚合计算。Spend、clicks、attributed sales、orders、ACOS、TACOS、CPC、CVR、contribution margin、inventory cover 等定义在这里，使用数仓或 lakehouse 的列式计算能力。它维护 grain、join path、time role 和 access policy。
本体与图层负责跨域身份、关系、类别、约束和影响范围。它回答哪些 target 可能争夺同一 query cluster，哪些 campaign 依赖同一 ASIN，修改一个 negative exact 可能影响哪些探索路径，某 Proposal 是否缺少必须证据。
图 6：语义层、本体图、策略引擎与 Harness 逐级收紧动作（概念示意）
策略引擎负责目标与取舍。它根据商品阶段、利润、库存、品牌目标和风险等级选择策略，并输出可解释 Proposal。规则、优化算法、预测模型与 LLM 可以共同参与，但必须标注每个结论的类型。
Harness负责长期执行。它保存状态、调度步骤、调用工具、处理重试、获取批准、限制权限、记录轨迹和复盘结果。它不重新定义 ACOS，也不自行推断对象关系；它消费已发布的语义资产。
应用层负责把复杂性转成运营工作。投手需要看到候选、证据、冲突、风险与可修改参数；审批人需要看到影响和上限；数据 steward 需要处理映射缺口；平台 owner 需要观察运行失败。一个聊天框无法取代这些角色界面。
这五层可以部署在一个平台中，也可以组合。Palantir 试图用 Ontology Language、Engine 和 Toolchain 覆盖对象、逻辑、动作、安全与应用；Microsoft Fabric IQ 在 OneLake 上组合 semantic model、ontology、graph 与 agents；ServiceNow 从数据产品和工作流进入；自建路线则可能使用 dbt/Cube/Wren、图数据库、策略服务和 Temporal/Durable Functions 一类工作流引擎。选型前应先画责任图，再讨论产品。
七、三个投放策略，怎样被翻译为语义运行合同
抽象架构只有经过真实策略才有意义。下面选择搜索词迁移、placement 调整和预算节奏三个常见策略，展示同一运行时怎样处理不同语义。
策略一：搜索词迁移不是“复制为 exact”
Amazon Sponsored Products targeting 指南区分顾客 shopping query、keyword target、automatic targeting、manual targeting 和 negative targeting。一个在自动投放中产生订单的搜索词，只是一个表现观察，不自动等于应该创建 exact keyword。
提案首先确认观察成熟度：点击、订单、销售额是否经过策略要求的窗口；其次确认对象资格：商品是否仍可售、库存与利润是否允许扩大；再次检查结构冲突：目标 campaign 中是否已存在等价 keyword，其他 campaign 是否已有同一目标，原 ad group 是否会与新 exact target 竞争。
然后策略决定迁移后的原路径如何处理。可以保留自动 target 继续发现，降低原路径 bid，或增加 negative exact 进行流量隔离。三种选择对应不同业务目标，不存在通用“收割模板”。Action Plan 可能包括创建 target、等待远端可见、再创建 negative、回查两侧状态；其中任何一步失败都需要明确补偿或人工处理。
图 7：对象身份、分类、冲突、窗口、库存与利润共同形成 Proposal（概念示意）
Proposal 的证据不能只写“过去十四天 ACOS 18%”。至少应包含 search term 原文和规范化形式、matched target、advertised ASIN、点击与转化、成熟窗口、利润边界、现有冲突路径、建议结构变化和预计影响。只有这样，审批人才能判断系统迁移的是一个真实机会，还是把偶然订单固化成长期结构。
策略二：placement 调整必须重建最终竞价边界
Sponsored Products 的 placement bid adjustment 与基础 bid、dynamic bidding strategy 共同影响最终可接受竞价。Amazon Ads 的竞价策略说明在 2026 年 7 月更新，列出 dynamic down only、fixed、rule-based 以及 audience bid 等选择；官方 best practices 还说明 placement 包括 top of search、rest of search 和 product pages。
如果 Agent 只看到 Top of Search ROAS 较高就增加 placement multiplier，它会忽略 campaign 下全部 target 的联动、基础 bid 差异和动态竞价上调。运行合同必须先计算最大调整后 bid，并用目标利润、转化率和平均订单贡献推导可承受 CPC。若 placement 报告只有 campaign × placement 粒度，系统也不能宣称某一个 keyword 在 Top of Search 的效果。
图 8：基础竞价、动态竞价和位置调整共同决定最终暴露（概念示意）
Proposal 应分别展示观察、因果假设和动作。观察是某 placement 在成熟窗口内的聚合表现；假设是增加可见度可能带来可接受的边际转化；动作是有限幅度调整并设置观察期。三者不能写成一句“因为 ROAS 高，所以加价”。执行后需要比较流量结构、CPC、转化和利润是否按预期变化，并区分市场波动与动作影响。
策略三：预算节奏需要跨小时状态与延迟归因
Amazon Marketing Stream提供小时级 campaign 指标与变更消息，适合日内观测；预算与竞价规则指南说明 schedule-based 和 performance-based 规则。拥有更及时数据不等于可以用未成熟销售实时优化。
预算策略需要两条时间线。快速时间线观察 spend、click、budget consumption、竞价和库存异常，用于防止过早耗尽或系统故障；慢速时间线等待转化和利润成熟，用于校准分时曲线和下一周期策略。若把小时级 ROAS 当作稳定反馈，系统会在转化尚未回填时反复压低预算。
长期任务每天或每小时产生 checkpoint，记录数据水位、策略版本、已执行动作和下一观察时间。任务跨日运行时不依赖聊天会话；模型可以在某一步重新参与诊断，但业务状态保存在 Durable State 中。批准也不是永久布尔值，而是绑定对象范围、金额上限、策略版本和失效时间的 lease。
图 9：小时消费与归因成熟分别对齐快照、消息和延迟转化（概念示意）
三个策略说明：搜索词迁移以身份和结构冲突为核心，placement 调整以竞价乘法链与聚合边界为核心，预算节奏以双时间线和持久状态为核心。通用 Agent 框架无法替代这些领域语义，但一个统一 Harness 可以复用批准、幂等、轨迹和回查能力。
八、长时程任务不是更长的上下文窗口
投放优化需要等待数据成熟、人工审批和外部系统状态，常跨越数小时或数周。把所有消息保存在一个超长会话中，不能保证任务可靠。上下文窗口解决模型一次推理能看到多少内容，长时程运行时解决任务暂停后如何继续、版本变化时如何迁移、重复消息如何去重。
一个长期任务至少要有 task_id、状态机、输入快照、当前步骤、策略版本、语义版本、授权租约、外部幂等键、重试计数、等待条件和取消原因。每一步输出结构化事件，下一步从事件恢复，而不是要求模型复述此前全部推理。
MCP 2025-11-25 规范引入实验性 Tasks，用 task handle、polling 和 deferred result 表达昂贵或批处理请求；2026 年 7 月发布候选继续讨论 task 生命周期。这说明连接协议开始考虑持久任务，但企业仍需自己定义业务状态机、存储、授权和补偿。协议中的 task status 不能告诉系统 Amazon Ads 归因是否成熟。
图 10：观察、提案、审批、等待、执行、验证与补偿经过检查点（概念示意）
典型状态可以是 observing → evidence_ready → proposed → awaiting_approval → preflight → executing → verifying → cooling_down → reviewed。从任何状态都可能进入 rejected、expired、cancelled 或 needs_intervention。状态转换由确定性条件触发，LLM 只能在允许的节点生成候选或解释异常。
版本变化是长时程任务的难点。任务提出时绑定 metric v3 和 policy v7，审批前 policy 升级到 v8。系统不能默默套用新规则，也不能永远按旧规则执行。每类变更要有迁移政策：安全边界收紧时强制重新评估；文案或同义词变化可以继续；指标公式变化通常重新生成 Proposal；工具 schema 变化必须重新计划 Action。
九、权限必须从“用户能否调用 API”推进到“能力租约”
传统应用常用角色决定用户能否访问页面或接口。Agent 会动态选择工具和参数，仅靠“有写权限”过于宽泛。一个投放运营人员可能有权调整自己负责的 profile，却无权查看全部利润；有权在 10% 以内调 bid，却不能暂停品牌防守 campaign；自动任务可能只在工作日和特定预算范围内运行。
能力租约把授权缩小为一次任务需要的最小范围。它包含主体、工具、对象集合、字段或动作、数值上限、用途、策略版本、签发者和到期时间。执行 worker 每一步验证租约，不能因为上游 Agent 曾获批就永久持有账户 token。
MCP Authorization规范 HTTP 场景的 OAuth 发现、resource indicator 与 scope 流程；这些机制适合建立连接层授权。企业动作仍需在业务层进一步约束 profile、campaign、金额和状态。OAuth scope campaign:write 不是“允许把这五个 campaign 的预算提高不超过 15%”。
图 11：主体、账户、对象、动作、上限、时间、次数、幂等和撤销共同对齐（概念示意）
Palantir 的 object permissioning 把 ontology resources 与 objects/links 权限分开，Actions 也可按用户和条件控制；ServiceNow 将外部 data fabric tables 纳入熟悉的平台访问控制；Tableau、Snowflake、Databricks 等分析平台也强调语义模型的访问策略。不同产品实现可以借鉴，最终要验证策略作用时点：模型看见数据前、计划生成前、SQL 执行时还是结果返回后。
对于第三方 Amazon Ads 服务商，还要把客户隔离作为对象语义的一部分。Profile 不只属于 marketplace，也属于客户合同和代理授权。任何缓存、向量索引、query example、日志和评测样本都要保留 tenant boundary，不能只在最终 API 调用时切换凭证。
十、动作语义的核心是前置条件、后置条件和可补偿性
工具 schema 通常说明参数类型，却不完整表达业务动作。update_campaign_budget(campaign_id, amount) 可以验证金额是数字，不能说明何时允许增加、当前预算必须等于什么、调用成功后要观察什么。动作语义需要比函数签名更丰富。
一个 Action Contract 至少包含：
- 目标对象与基线：操作哪个版本的 campaign，预期当前 budget 和 state 是什么。
- 前置条件：Proposal 未过期、数据成熟、库存与利润仍满足、授权租约有效、未处于冷却期。
- 参数约束：绝对值、变化比例、组合上限、currency 与 marketplace 规则。
- 副作用范围：会修改哪些远端对象，是否创建新的 target 或 negative，是否触发其他工作流。
- 幂等语义：相同动作如何识别，重复请求是返回原结果、拒绝还是安全合并。
- 后置条件：远端回查应看到什么状态，多久内完成验证。
- 补偿与人工接管：部分成功、超时或状态冲突时怎样处理。
- 观测合同：之后在哪些时间点用哪些指标评估结果。
图 12：前置条件和版本快照与回执、后置条件及补偿对接（概念示意）
Palantir Object edits and materializations说明 Actions 可用于对象属性、链接和对象创建删除，并可从应用或 API 触发；Functions on objects将对象类型生成代码绑定。这个设计说明对象与动作可以共享类型系统，但外部 Amazon Ads side effect 的端到端幂等和确认仍需适配器负责。
动作还要区分可逆、可补偿和不可逆。降低一个 bid 通常可通过反向更新恢复，但期间错失的流量不可追回；创建 negative 后删除可以恢复资格，却无法补回已经错过的竞价；预算过度消耗更不能通过把数值改回就撤销成本。UI 中的“撤销”如果只代表发送反向 API，必须明确说明它不是业务后果回滚。
因此，风险分级不能只看操作名。一次 5% 的 bid 变更在单个 campaign 上风险较低，在一万个 target 上影响巨大；一次暂停在缺货商品上可能是保护动作，在品牌防守上可能造成明显损失。风险函数应考虑对象数量、预算暴露、可逆性、证据质量、时效和客户策略。
十一、把推理分账：逻辑蕴含、规则、模型和 LLM 不能混为一谈
“图推理”与“Agent 推理”常被混用。生产系统需要记录结论来自哪种机制，因为它们的可证明程度、更新方式和失败模式不同。
声明事实来自权威数据源或人工确认，例如 campaign 属于某 profile、ASIN 当前库存为 300。逻辑蕴含由 OWL 公理、规则或关系约束推出，例如所有 ExactKeywordTarget 都是 ManualTarget；其正确性依赖公理和推理器语义。图计算通过路径、连通性、社区或中心性发现结构，例如多个 campaign 通过相同 query cluster 与 ASIN 形成竞争子图。
确定性业务规则按已发布政策计算，例如库存覆盖低于 14 天时禁止扩量。统计预测估计转化率、流量或边际收益，输出概率与校准信息。优化求解在预算与约束下寻找方案。LLM 推断适合解释非结构化证据、提出假设和组合工具，但输出必须进入后续验证。
图 13：逻辑、规则、统计模型和 LLM 保留不同输入与校验方式（概念示意）
一个 Proposal 可以组合多类结论，却不能把它们压成统一 confidence。逻辑规则通过并不代表统计预测准确，LLM 解释合理也不代表数据完整。证据图应为每个 claim 记录 claim_type、method、inputs、version、confidence_or_status 与 counterevidence。
这种分账会直接改善调试。若系统错误地把竞品词当品牌词，应检查分类模型或人工标签；若重复创建 keyword，应检查对象身份和 Action 幂等；若 ACOS 汇总错误，应检查指标计划；若遗漏库存风险，应检查 policy dependency。把所有失败归咎于“模型幻觉”只会让团队不断更换模型，核心系统保持不变。
十二、RAG、语义层、本体和 Agent Memory 各自保存什么
企业常把四者都描述为“给模型上下文”，导致重复建设。
RAG 索引适合保存大段非结构化资料，按问题检索相关片段。它处理的是相关内容发现，来源、权限和新鲜度必须额外治理。语义层保存机器可执行的指标、维度、关系和查询约束，目标是稳定计算。本体保存概念身份、关系、类别、公理与约束，目标是跨域解释和推理。Agent Memory 保存经过确认的使用经验、任务状态或历史决策，目标是让未来交互延续，但它不应覆盖权威定义。
以“品牌词 campaign 是否应该增加预算”为例：RAG 找到品牌投放策略文档；语义层计算成熟窗口内的贡献利润和预算损失机会；本体确认 campaign、query cluster、ASIN、库存与品牌策略的关系；Memory 找到上次相似调整的 Proposal 和结果；Policy 决定当前条件下是否可提案；Harness 执行、等待并复盘。
图 14：文档、计算合同、关系约束和任务状态各归其位（概念示意）
如果只用 RAG，文档能被找到但公式未必可执行；只用语义层，数字正确但不一定理解跨对象影响；只用本体，关系清晰但高频聚合成本可能不合适；只用 Memory，旧经验可能越过新政策。组合的关键是明确 source of truth，而不是把所有内容复制进同一个向量库。
Agent Memory 还需要写入门。用户临时说“以后预算都加 30%”不能直接成为组织政策；一次成功 SQL 也不能自动成为跨客户黄金查询。候选记忆应保留来源和作用域，经过验证后才提升为 reusable example；任务状态与语义定义分别存储，避免“记住了上次对话”被误认为“知道当前规则”。
十三、生产评测必须看轨迹、状态和业务后果
传统 LLM 评测常比较最终答案与参考答案。行动 Agent 的最终结果可能恰好正确，但路径已经违反权限或依赖错误数据。需要同时评估结果、轨迹、可靠性和业务护栏。
结果维度检查选中了哪些 campaign、建议幅度、理由和数值是否正确。轨迹维度检查是否先取授权 scope，再选择合法指标与关系，是否在动作前完成 preflight，是否调用了禁止工具。可靠性维度检查超时、重复消息、进程重启、部分失败与外部状态变化时能否恢复。业务护栏维度检查库存、利润、预算上限、客户政策和冷却期是否被执行。
测试集应覆盖三层样本。单元层验证指标公式、关系和政策；情景层模拟搜索词迁移、placement 调整、预算节奏等完整工作流；生产回放层使用脱敏的历史事件和实际失败。每次语义、策略、工具或模型升级都在同一数据快照上回放，区分能力提升与行为漂移。
故障注入比普通成功样本更重要。至少包括：归因迟到、报告重复、时区跨日、币种错误、COGS 缺失、库存快照过期、ASIN 映射冲突、同一 search term 多路径竞争、权限撤销、批准过期、API 429、请求超时但远端已成功、工具 schema 升级、模型输出额外参数、任务重启和补偿失败。
图 15：解析、计划、决策、授权、执行和后果共同检测危险捷径（概念示意）
评测结果也需要按风险加权。推荐一个错误标签与把一百个 campaign 预算翻倍不是同一严重度。可以记录每条轨迹的最大潜在损失、实际暴露、可逆性和人工拦截点。系统上线门槛应以严重违规为零、关键恢复路径全部通过为基础，再优化平均成功率。
生产观测不只看 token、延迟和错误码。还要跟踪语义覆盖率、拒答原因、Proposal 接受率、人工修改幅度、执行确认时间、回滚/补偿率、策略后果、不同客户和 marketplace 的偏差，以及定义版本变化造成的结果漂移。只有这些指标能说明 Agent 是否真的帮助业务，而不是更快地产生建议。
关于 Agent 数据基础设施的一篇社区架构梳理也把可追踪的检索、工具调用与上下文列为生产责任。这类材料适合补充工程团队正在讨论的痛点，但本文只把它当作需求侧证据；具体协议、权限和运行保证仍以标准、产品手册和可复现实验为准。
十四、企业语义的边界会怎样继续变化
大模型会继续吸收公开标准、产品知识和行业经验，企业无需长期维护大量百科式说明。工具可以在调用时提供当前 schema 和文档，搜索系统可以找到最新政策，模型本身也更擅长处理自然语言差异。企业语义不会因此消失，而会集中到四类不可外包的边界。
第一是承诺边界：组织正式采用哪个定义、政策和动作上限。第二是状态边界：此刻库存、预算、授权和任务处于什么状态。第三是责任边界：谁发布、谁审批、谁执行、谁承担后果。第四是差异化边界：企业独有的客户分层、利润策略、运营经验和反馈回路。
未来的语义系统可能不再要求人手工维护每个同义词和映射。Agent 会从查询、文档、仪表盘、代码和反馈中生成候选，自动发现定义漂移和缺失关系。Google OKF v0.2 对 generated、verified、freshness 和 attestation 的区分提供了一种上下文治理方向；IBM SAL、Alation、Informatica、Atlan 等元数据产品也在自动化语义丰富。但生产发布仍需要明确的人或政策主体。
语义边界还会从“数据含义”扩展到“能力含义”。Agent 需要知道工具能做什么、风险如何、成本多少、是否支持幂等、输出证据是什么。MCP、OpenAPI 和各类 SDK 能提供接口结构，企业仍需附加用途、权限、状态和后果。Action Contract 很可能成为与 metric contract 同等重要的资产。
最后，语义会越来越运行时化。过去模型发布后较少变化，未来每次任务会按用户、时间、对象和政策构造一个最小可见语义子图。系统不把全公司本体塞进上下文，而是编译出当前任务需要的 entities、metrics、policies、tools 和 examples，并附带版本与权限。语义层从静态中心模型变成受治理的上下文编译器。
十五、产品路线选择：不是自建或采购，而是责任怎样组合
如果团队已经拥有成熟数仓和 BI 模型，主要目标是自然语言问数，应先强化指标合同、中间表示和查询验证。Power BI、Cognos、Oracle、Looker、Tableau、Snowflake、Databricks 或 headless 产品都可以成为起点，没有必要为了 Agent 立即重建完整本体。
如果问题集中在跨域身份和影响分析，例如广告、商品、库存、利润与供应链关系复杂，且 SQL Join 难以表达稳定路径，可以增加图或本体层。选择 OWL/SHACL、Stardog、GraphDB、TopBraid、Neo4j 或 RelationalAI 时，要明确需要的是形式蕴含、约束验证、图算法还是声明式决策计算。
如果目标是交付跨角色运营应用和写回闭环，Palantir、ServiceNow、SAP、Microsoft Fabric IQ 等平台更接近问题，但必须评估现有数据生态、部署边界、许可、领域适配器、平台技能和退出成本。平台的“统一”价值只有在对象、逻辑、权限和动作被多个场景复用时才能抵消迁移和锁定成本。
如果希望保留核心语义主权，可以采用双平面：开放或代码化语义资产保存稳定 ID、指标、关系、shapes、政策与测试；具体平台保存高效执行、应用和动作映射。双平面不是免费保险，它需要投影编译、版本对账和退出演练。只有明确存在跨平台消费或监管交换要求时才值得承担。
采购验证应使用真实业务切片，而不是厂商演示数据。给每个候选平台同一组 Amazon Ads 问题和动作：计算稳定 ACOS、识别搜索词冲突、生成库存受限预算 Proposal、执行一个小范围调价、模拟超时重试、撤销授权、升级指标版本并回放旧决策。记录每一步需要多少自定义、哪些边界无法表达、能否导出和复现。
十六、从零落地的十二周路径
第 1—2 周：选择一个闭环。 不做全域 Agent，选择搜索词迁移或预算扩量之一。收集二十到五十个真实决策案例，包括成功、拒绝和事故。确定业务 owner、数据 owner、执行 owner 与风险审批人。
第 3—4 周：建立最小语义合同。 定义核心对象、grain、指标、时间、关系和权限。为每个定义补充来源、版本和测试。建立 Semantic Request schema，先让系统稳定回答，不接写权限。
第 5—6 周：建立 Proposal。 把策略从 prompt 中抽出，形成版本化 Policy；设计证据、反证、失效条件和影响半径。运营人员在界面中审查并修改 Proposal，修正进入评测集，不直接进入生产政策。
第 7—8 周：建立 Action Contract。 为一个低风险动作实现 preflight、能力租约、幂等键、远端回查和审计。使用沙箱或小额账户，故意注入超时、重复请求和状态冲突。
第 9—10 周：建立长时程状态机。 把等待归因、人工审批和冷却期从会话中移出，使用持久事件与 checkpoint。验证进程重启、模型切换、政策升级与授权撤销。
图 16：金标准、语义合同、Harness 和影子运行逐段设置退出门（概念示意）
第 11—12 周：影子运行和业务评测。 Agent 生成 Proposal 但不执行，与人工决策并行比较。评估覆盖率、正确拒答、人工改动、潜在损失和真实业务结果。只有关键风险场景通过，才逐步开放受限执行。
这条路径的验收标准不是“聊天很流畅”，而是任何一个动作都能回答六个问题：使用了哪版语义，基于哪份数据，采用哪条政策，谁批准了什么范围，远端实际发生了什么，后续结果是否符合预期。
十二周以后，团队至少应留下哪些可复用资产
试点的价值不只是上线一个 Agent，而是形成下一条策略可以复用的运行底座。第一项资产是领域包，包含对象、指标、时间角色、关系、同义词和拒答条件。它不需要覆盖全部 Amazon Ads，只覆盖已经验证的决策域，但每个定义都能追溯 owner 与来源。
第二项是问题与查询包。每个真实问题保存自然语言变体、Semantic Request、合法逻辑计划、结果样例和不可回答反例。SQL 只是特定数据平台上的物理实现，不能代替前面的语义金标准。更换 Snowflake、BigQuery 或其他仓库时，逻辑合同仍应保持。
第三项是策略包。它包含 Policy、参数、适用对象、证据要求、风险级别、例外和历史版本。搜索词迁移、placement 调整和预算节奏分别维护自己的策略，不把全部规则堆进一个全局 prompt。策略包还保存人工修改的原因，用于后续评审，而不是直接自动学习。
第四项是动作包。每个受控动作都有 Action Contract、工具 schema、preflight、幂等、补偿、回查和能力租约模板。新策略若复用“调整 campaign budget”，不必重新开发可靠性机制，只需声明新的 Proposal 与政策依赖。
第五项是评测包。它包括静态样本、状态机情景、故障注入、历史回放和业务结果指标。模型、工具、语义或政策任何一层变化，都可以选择受影响集合回归，而不是每次只做人工冒烟测试。
第六项是证据与运行账。Proposal、Approval、ActionPlan、ExecutionAttempt、Receipt、Outcome 和 Review 形成不可变关联。它既服务审计，也服务产品迭代：哪些建议经常被拒绝，哪些边界造成过多人工介入，哪些策略在何种商品阶段有效，都可以基于结构化事实分析。
如果十二周后只留下一个聊天应用、一组 prompt 和几张效果截图，项目还处于演示阶段。可复用资产的判断标准是：新增第二个策略时，是否能沿同一对象、权限、状态、动作与评测框架交付；更换模型时，已验证语义与业务控制是否仍然成立。
这些资产还需要有明确的发布关系。领域包和策略包进入版本库，查询包与评测包进入持续验证，动作包进入受控部署，运行账留在审计存储。生产环境只引用已发布版本；草稿可以被 Agent 用来提出建议，但必须带非生产标记，不能获得 Action 权限。这样，研究、建模、评审和运行形成一条清楚的晋级路径，团队既能快速试验，也不会让一次对话中的临时想法直接进入客户账户。
十七、常见失败方式，以及为什么它们看起来都很合理
把 schema 全塞给模型。 原型最快，但 schema 不包含指标、粒度、关系合法性和策略。数据库越大，相关表选择越不稳定。
用更多示例代替模型。 示例能提高相似问题成功率，却会携带旧口径，也无法证明新问题适用。确认示例应引用语义版本并接受回归。
把知识图谱当作万能数据库。 图适合关系和影响分析，不自动适合大规模事实聚合、权限和事务。高频指标仍应由合适的分析引擎计算。
把所有规则写进本体。 OWL、SHACL、规则引擎和策略服务有不同语义。强行统一会让业务规则难以调试，也可能引入不可控推理成本。
让一个 Agent 既查询又执行。 权限面过大，错误无法归因，也难以加入独立批准。只读分析、Proposal、授权和执行应解耦。
只记录 prompt 和最终响应。 无法复盘实际绑定的指标、路径、工具和版本。必须保存结构化中间产物与远端回执。
把 API 成功当作业务成功。 外部系统可能异步、部分成功或随后被人工修改。需要远端回查和结果观察。
用最终 KPI 直接训练策略。 市场、季节、价格和库存同时变化，不能把所有结果归因给 Agent。至少保留基线、对照、因果假设和不确定性。
追求零拒答。 在粒度缺失、权限不足或数据未成熟时强行给答案，会把产品可用性指标推向业务风险。拒答需要具体、可修复，而不是被消灭。
中场结论：框架只有进入运行现场才算成立
当 Agent 只负责找资料，语义主要是相关性和来源；当它开始问数，语义变成指标、实体、时间和查询计划；当它参与决策，语义还要包含目标、政策、证据和反证；当它修改系统，权限、状态、幂等、回执和后果也成为语义的一部分。
Amazon Ads 把这条演进表现得非常清楚。Search term 与 keyword 的身份差异决定迁移是否正确，placement 与基础 bid 的乘法链决定调价上限，归因延迟决定何时可以评估，库存与利润决定流量是否值得购买，客户授权决定谁能对哪个 profile 做什么。任何一项都不能只靠模型常识。
市场上的产品正在沿不同路径靠近运行时：IBM 把传统业务元数据、语义自动化和自然语言 BI 连接起来；Snowflake、Tableau、Databricks、Cube、dbt 与 Wren 把语义变成查询编译；Stardog、GraphDB、Neo4j、TopBraid 与 RelationalAI处理关系、约束或推理；Palantir、Microsoft、SAP 和 ServiceNow 把对象、Agent、权限与行动放入运营平台。它们不是一条榜单，而是不同责任组合。
Agent 时代真正稀缺的不是更多“知识”，而是能够在变化中保持有效的企业承诺：哪个定义生效、哪份状态可信、哪项政策允许、哪位主体负责，以及哪个动作已经在现实世界得到确认。
语义层若停在术语表，无法支撑行动；本体若停在关系图，无法承担运营；Agent 若没有 Harness，只是一次性模型调用。三者通过版本化的 Semantic Request、Decision Proposal 和 Action Plan 连接起来，企业才拥有一条从问题、证据、判断到行动的可审计链。
把框架压到运行现场：八组推演
前面的分层只有经过真实任务、故障和组织协作才有意义。下面八组推演分别检查端到端预算动作、多 Agent 协作、三种数据节奏、安全、性能、产品 POC、事故复盘与人类责任，避免架构只在正常流程中成立。
运行推演一：一次预算扩量任务在系统里怎样完整流动
为了避免架构停留在模块名，下面把“给符合条件的 campaign 增加预算”展开为一次完整运行。示例中的阈值只是说明结构，不是普遍适用的投放建议。
第一步，接收意图。 用户选择美国站的某个客户，并提出“扩大昨天多次提前耗尽、最近两周仍有利润的 campaign”。入口层先绑定当前用户、客户租户、profile 集合、marketplace 和只读会话。模型可以解析“提前耗尽”和“仍有利润”的候选含义，但不能自行创造指标。
第二步，编译 Semantic Request。 “提前耗尽”绑定到经批准的 budget depletion observation，包含本地日、小时数据覆盖和异常排除；“最近两周”绑定到完整的十四个 profile local days，并按策略剔除尚未成熟的归因日期；“利润”绑定 contribution-after-ads 的当前生产版本。编译器显示绑定结果，歧义时要求用户选择。
第三步，生成查询计划。 指标层分别计算 campaign 日级花费与归因销售、小时级 budget consumption、advertised ASIN 覆盖、库存与 COGS。计划器先在各自 grain 聚合，再通过受治理的 Campaign—AdvertisedProduct 路径组合结果。它不会直接连接小时流、search term 明细与库存快照。
第四步，验证证据。 Reconciliation 检查总 spend 与权威报表是否在容差内，数据水位是否到达要求，利润映射覆盖率是否超过策略门槛。若一个 campaign 中只有 70% 的销售能映射到 COGS，它被标记为 coverage insufficient，而不是用其余 70% 推断整体利润。
图 17：从业务目标到回执和事后验证保留失败分流（概念示意）
第五步，构造 Decision Proposal。 策略引擎读取 candidate、portfolio ceiling、库存边界、冷却期和最近动作，计算建议幅度。Proposal 保存 before budget、建议 after budget、依据、排除原因、预期增量消耗、最大风险、失效时间和观察计划。LLM 可以把结构化依据解释成人类可读文本，但文本不是 source of truth。
第六步，风险分级。 系统按对象数量、金额变化、客户政策、可逆性和证据质量决定是否需要人工批准。单个低预算 campaign 的小幅调整可能进入预授权通道；跨多个 portfolio 的大规模扩量必须由账户负责人批准。风险分级规则本身有版本和 owner。
第七步，签发能力租约。 批准服务没有把 Amazon Ads token 交给规划 Agent，而是签发仅允许本次任务修改指定 campaign、变化不超过 Proposal 上限、在十分钟内有效的 lease。执行 worker 持有平台凭证，但每次调用必须验证 lease 与当前对象。
第八步，preflight。 Worker 重新读取 campaign 当前 budget、state、portfolio 与 profile 授权，并检查库存和紧急暂停标记。如果基线已改变，Action Plan 失效；系统回到重新提案，而不是强行覆盖人工修改。
第九步，调用与确认。 Worker 生成幂等键、记录请求、调用 Amazon Ads API，保存响应。超时不会立即重试，它先查询远端状态判断请求是否已经生效。确认成功后写入 RemoteReceipt；部分失败进入受控补偿或人工接管。
第十步，进入观察期。 快速观测检查 campaign 是否异常耗尽、库存是否突变、API 状态是否被外部修改；慢速观测等待归因成熟后评估贡献利润和边际收益。系统把结果与 Proposal 预期比较，形成 OutcomeObservation 与 ReviewCase。
这十步中，模型可能参与第一步的意图解析、第五步的解释和异常诊断，却不负责持有状态与授权。即使更换模型，任务也能从 checkpoint 恢复；即使模型服务暂时不可用，已经批准的确定性执行仍可按组织政策决定继续、暂停或转人工。
运行推演二：多 Agent 不应共享一段“大家都懂”的上下文
企业系统可能同时存在数据 Agent、投放策略 Agent、库存 Agent、财务 Agent、审批 Agent 和执行 Agent。把它们接到同一个群聊或共享向量库，并不会自然形成协作。每个 Agent 的目标、权限和证据时效不同，未经类型化的消息很容易造成语义漂移。
数据 Agent 的合同是生成 Semantic Request 与可对账结果，不得建议写动作；策略 Agent 消费已验证观察和 Policy，输出 Proposal；库存 Agent 只对 RetailReadiness 提供带时间戳判断；财务 Agent 提供利润边界，不暴露不必要的成本明细；审批 Agent 验证职责分离；执行 Agent 只接受 Action Plan 和能力租约。
Agent 之间传递的不是长篇自然语言，而是带 schema、版本、来源和签名的对象。自然语言摘要供人阅读，结构化 payload 供机器验证。如果库存 Agent 只返回“库存健康”，策略 Agent 不知道这个判断何时生成、采用哪种日销量、对哪些 ASIN 成立；正确结果应包含 retail_readiness_policy_id、as_of、covered_asins、exceptions 和 evidence_refs。
图 18：五类 Agent 只交换带 schema、版本、权限和证据的信封（概念示意）
共享语义也不是让所有 Agent 看见全量模型。Context Compiler 根据任务和主体裁剪最小语义子图：数据 Agent 获得允许查询的 metrics 和 paths，审批 Agent 获得 Proposal、风险与责任关系，执行 Agent 获得具体 Action schema、对象基线和 lease。最小上下文同时降低 token、泄露和错误工具选择。
多 Agent 冲突必须有确定性仲裁。库存 Agent 认为应暂停，品牌策略 Agent 认为应维持曝光，系统不能让两个模型互相说服到超时。Policy 明确安全约束优先级、可协商目标和升级路径：硬库存禁投覆盖增长目标；品牌防守例外需要更高级批准；无法自动决断时生成 ReviewCase。
通信协议只能承载这些对象，不能定义它们。A2A、MCP、消息队列或工作流引擎都可以传输任务和工具调用，企业仍要发布 Proposal、Policy、Lease、Receipt 等业务 schema。把“接入多 Agent 协议”写成协作完成度，会重复 MCP 与业务语义混淆的问题。
运行推演三：实时、批处理和事务不应被一个“智能层”抹平
Amazon Ads 运行同时包含三种节奏。报告与订单重算属于批处理，Marketing Stream 和库存变化接近事件流，预算与 bid 更新则是面向外部 API 的命令。三者的数据保证不同，语义层必须让差异可见。
批处理强调水位和重算。一个日期分区完成不代表归因成熟，迟到转化可能触发后续版本。事实表应保留 observed_at、loaded_at、source_report_id 和 maturity 状态；语义请求选择的是某个稳定策略，而不是简单 MAX(date)。
事件流强调顺序、重复和缺口。Marketing Stream 事件用于快速诊断，不能假设 exactly-once 到达。消费端使用 event identity、去重和 watermark，检测长时间无消息。小时级 spend 与 campaign 变更是快速信号，销售归因仍按慢速事实校准。
图 19：不同水位、重试和一致性保证在证据满足时汇合（概念示意）
命令强调意图和确认。Action Plan 是本地希望发生的变化，RemoteReceipt 是远端接收结果，ConfirmedState 是回读后的事实。三者必须分开。网络超时可能让本地不知道远端是否已修改；如果直接重试，就可能重复创建 target 或覆盖新的人工值。
这也是为什么“实时 Agent”不是越快越好。某些保护动作——例如发现 campaign 异常暴增、商品不可售或授权撤销——可以依据快速信号立即停止；扩量和利润优化则应等待成熟证据。运行时为每个 Policy 声明所需数据速度和稳定度，避免统一追求毫秒响应。
缓存同样需要语义化。查询缓存 key 不应是用户原句，而应由规范化 Semantic Request、数据 snapshot、metric version、policy version 和 access context 构成。Proposal 缓存还要包含当前对象基线和失效时间。不同 tenant、权限或币种的结果绝不能因为自然语言相同而共享。
运行推演四：安全问题不只来自恶意 Prompt
Agent 安全讨论经常聚焦 prompt injection，但企业动作的风险面更宽。恶意文档可以诱导模型调用工具，错误目录权限可以让模型看见另一个客户的数据，过宽 OAuth scope 可以让低风险 Agent 获得写权限，陈旧 Policy 可以让合法工具执行过期规则。
威胁模型至少覆盖五条路径。第一是输入污染：外部文档、搜索词文本或商品内容包含指令。它们必须作为数据引用，不得与系统指令混合。第二是语义污染：Agent 自动生成的术语、关系或查询例子未经验证进入生产模型。第三是能力提升：低权限任务借助另一个 server 或间接工具获得更高权限。
第四是跨租户泄露：缓存、记忆、日志、向量索引或评测样本丢失 tenant scope。第五是执行竞态：批准后对象状态改变，任务仍按旧基线写回。传统输入过滤只能缓解第一条，完整防护依赖来源分级、发布门、最小语义子图、能力租约、preflight 与审计。
MCP 的授权规范处理 HTTP 连接中的授权服务器发现、resource indicator 和 scope，工具规范建议界面清楚展示调用并保留人类拒绝。企业还应验证 server identity、固定允许的工具版本、对输出做 schema 校验，并把 tool annotations 视为不可信提示。对写动作，模型提出的任何 tool name 和参数都必须与 Action Plan 中的白名单一致。
审计日志还要防止只记录成功路径。被拒绝的工具调用、越界参数、过期 lease、preflight 冲突和人工取消都是重要安全信号。若系统只记录最终 API 成功，团队看不到 Agent 是否反复尝试过危险动作。
隐私与最小披露也属于语义编译。财务 Agent 可能只需返回“利润边界通过/不通过”和 policy ID，不必把供应商成本提供给投放 Agent；外部服务商可以看自己管理的 profile 指标，却看不到集团其他账户。输出 schema 应从源头限制字段，而不是让 LLM 看到全部内容后要求它别说。
运行推演五：性能与成本优化也必须保持语义等价
Agent 查询容易产生大范围扫描、多轮试错和重复工具调用。为了提速，团队会增加缓存、预聚合、向量检索和路由。任何优化如果没有语义合同，都可能悄悄改变答案。
预聚合必须尊重可加性。Spend、clicks 和 orders 可以在合法 grain 上求和，ACOS 与 CVR 需要聚合分子分母后重算，inventory snapshot 选择最后有效状态，distinct reach 与 new-to-brand 可能无法从低粒度预聚合简单合成。语义引擎应知道哪些 rollup 与原查询等价。
模型路由也有语义风险。为了缩小上下文，Cortex Agents、Genie、Wren memory 或自建检索会先选择相关 semantic view、model 或 schema items。漏选模型可能导致错误拒答，选错模型可能生成一个形式正确但含义不同的结果。评测要单独测 routing recall 和 scope precision，不能只看最终 SQL。
成本策略应成为查询合同的一部分。一个用户要求导出一年 search term 明细时，系统可以提示预计扫描和等待时间，提供 campaign 汇总或转异步任务；不能未经说明用采样结果冒充精确答案。近似计算必须标明方法、误差和不适用动作。
动作成本也不只是一笔 API 调用。频繁调整可能破坏投放学习，过多 Proposal 会增加人工审批负担，过长观察期会降低响应速度。运行时应跟踪每种策略的 query cost、tool calls、人工分钟和业务收益。Agent 节省的操作时间若被语义维护与异常处理完全抵消，系统还没有达到可持续状态。
运行推演六：如何做一次不被厂商演示带偏的 POC
语义与 Agent 平台的演示通常选用干净数据、明确问题和成功路径。企业 POC 应反过来选择最容易暴露边界的场景。
第一组是定义冲突。准备两个同名 ACOS、两种归因窗口、一个已退役指标和一个不同币种 profile，观察平台如何让用户选择、如何版本化以及是否会自动猜测。
第二组是关系冲突。准备多对多 SKU—ASIN 映射、没有联合 grain 的 search term 与 placement 报告、跨 campaign 的相同 query cluster，观察系统能否拒绝错误 Join 并解释原因。
第三组是权限冲突。让用户有 campaign 表现权限但无 COGS 明细权限，测试系统能否使用已批准利润指标而不泄露成本；撤销 profile 授权后，检查缓存、记忆和正在运行任务是否同步失效。
第四组是动作故障。模拟 API 超时但远端成功、部分 target 创建成功、批准后 budget 被人工修改、工具 schema 增加必填字段，检查幂等、preflight、补偿和人工接管。
第五组是迁移。导出模型、指标、关系、测试、Policy 和历史 Proposal，在一个隔离环境重建关键查询；然后替换执行引擎，检查逻辑结果是否保持。若厂商只允许导出名词和描述，不允许重现查询和动作，就不能宣称核心语义已经可移植。
POC 评分按前述责任轴分别记录：检索、查询、关系推理、政策、动作、权限、版本、可观测与退出。不要压成一个加权总分，因为某一硬性边界失败就足以否决自动执行。例如平台问数体验再好，只要无法隔离客户 profile，就不适合服务商生产环境。
运行推演七：从一次看似正常的事故倒推缺失语义
假设系统在周一上午把二十个 campaign 的预算分别提高 20%。API 调用全部成功，审计页面也有记录。当天花费增长，三天后财务发现其中六个 campaign 的贡献利润明显恶化。仅凭结果，很容易把事故归因于模型预测不准。
完整复盘要逐层倒推。先看执行账：二十次请求是否与批准的 Action Plan 一致，有无重复调用，远端回查是否确认，是否有人在执行后再次修改。若执行完全一致，问题不在工具可靠性。
再看决策账：Proposal 当时引用哪些 campaign、数据快照、库存状态、利润指标与 policy；六个失败对象是否存在共同排除条件。若 Proposal 使用 contribution_after_ads_v3，而财务复盘采用 v4，必须分别按两版计算，不能直接说当时判断错误。
接着看指标账：v3 是否把退款按下单日而非退款发生日处理，COGS 映射覆盖率是否达到阈值，币种转换日期是否一致。若六个 campaign 集中投放刚调价的 ASIN，可能是利润数据有效期没有进入计划，不是预测模型问题。
图 20：从异常预算倒查回执、计划、审批、提案、语义和数据快照（概念示意）
再看对象账：campaign 与 advertised ASIN 的关系是否完整，执行前是否有新商品加入 ad group。Proposal 可能基于生成时的商品集合，审批后 ad group 被人工扩充；preflight 只比较了 budget，没有比较成员版本，导致动作作用范围扩大。
然后看政策账：scale_profitable_campaigns_v7 是否只要求 campaign 聚合利润通过，没有规定所有关键 ASIN 都满足零售就绪。若如此，系统忠实执行了一个不完整政策。修复应增加 dependency 和 coverage 条件，而不是只在 prompt 中补一句“注意库存”。
最后才看模型：它是否错误解释了原因、排序或幅度。即使模型预测贡献了一部分误差，前述语义缺口仍需分别修复。否则更换模型后，同样的成员变化和指标有效期问题还会再次发生。
事故处理应产生四类资产：新增的失败样本进入评测集，政策或指标修复形成新版本，未结束任务按迁移规则重新评估，历史 Proposal 保留旧版本并链接复盘。不能回写旧记录让事故“看起来从未发生”。
这套倒推揭示了 Agent 系统的重要性质：结果只是证据链的末端。没有六本账和结构化中间产物，团队只能在 prompt、模型、数据和 API 之间猜测；有了分层，事故可以归因到具体合同，修复也能被回归测试。
运行推演八：人类在回路中，不等于每次都点确认
很多方案用“human in the loop”概括治理，实际只是在工具调用前弹一个确认框。若审批人看不到语义版本、数据成熟度、影响范围和替代方案，点击确认只是把系统责任转移给人。
有效的人类参与有四种不同位置。第一是定义治理：领域专家批准指标、关系与政策，使 Agent 不必在每次任务重新询问。第二是异常裁决：当映射冲突、证据不足或多个目标竞争时，人处理无法自动归一的案例。第三是高风险批准：审查具体 Proposal 的范围、收益与损失。第四是结果复盘：根据真实后果调整政策和评测。
系统应尽可能把稳定判断前移到定义治理，而不是制造大量低价值点击。已经由财务批准的贡献利润公式，不需要每个投手重复确认；预授权范围内的小额动作可以自动执行；超过金额、覆盖不足或跨客户的 Proposal 再升级审批。这样人类把注意力放在不确定性和责任上。
批准界面也应允许结构化修改。审批人把 20% 改为 10%，系统记录修改字段和理由，生成新的 Proposal/Action Plan 版本；不能只把一条自然语言评论追加到聊天。长期统计哪些参数经常被修改，可以反向发现策略过于激进或语义缺失。
撤销权同样需要设计。任务尚未执行时撤销 lease；部分执行时停止剩余步骤并进入补偿评估；已经执行并产生业务后果时，只能创建反向动作和复盘，不能把历史删除。界面要清楚区分“取消任务”“撤回授权”“恢复配置”和“逆转业务后果”。
真正的人机协作不是 Agent 提建议、人负责背书，而是双方在同一套对象和证据上工作：机器负责持续计算、检查和记录，人负责定义目标、处理价值冲突和承担高风险判断。语义层让双方说的是同一件事，Harness 让决定按照约定进入现实。
总结：企业语义最终要接受现实世界的检验
两篇文章从同一个问题出发：业务人员说出的概念，怎样被机器稳定理解。第一篇把答案落在 Semantic Request 和可验证查询计划，本篇继续把答案编译为 Decision Proposal 与 Action Plan，并用对象、指标、政策、能力、决策和执行六本账保存责任。
运行推演说明，真正的边界不在聊天界面。预算扩量要经过数据成熟、Proposal、能力租约、preflight、远端确认与结果观察；多 Agent 要交换版本化对象而不是共享一段模糊上下文；批、流和命令要保留不同时间与一致性保证；安全、性能和人工参与也必须进入合同。
企业语义的最终验收不是“Agent 能否解释业务”，而是任意一次真实动作能否被准确限定、可靠执行、完整复盘，并在定义、数据、权限或外部状态变化时安全停止。
做到这一点，模型可以持续升级，查询引擎和运营平台也可以替换；组织最重要的资产——它如何定义事实、作出判断并承担行动后果——仍然留在自己可验证的系统中。