OWL 与 Palantir Ontology 经常因为共用“本体”这个名称，被放进同一张技术选型表。这样的比较从第一列就错了。OWL 是 W3C 标准化的知识表示语言，用于表达类、属性、个体和公理，并支持具有明确语义的逻辑蕴含；Palantir Ontology 是一套企业运营软件中的核心系统，把数据映射为对象与链接，再连接逻辑、动作、权限、应用和开发工具链。
前者主要回答“这些概念和关系怎样被精确表达、交换和推导”，后者主要回答“这些数据怎样成为人和 Agent 可以查询、分析、修改和协作的运营对象”。OWL 文件不会自动长出预算审批、搜索词迁移工作台和 Amazon Ads 写回适配器；Palantir 的对象、派生属性和 Action 也不能自动等价为 OWL 公理或描述逻辑推理。
因此，Amazon Ads 团队真正面对的不是 OWL 与 Palantir 二选一，而是三条建设路线：把开放形式语义作为长期资产，自建运营外壳；把 Palantir 作为运营后端，在它的对象和动作体系内交付应用；或者在确有跨平台复用与资产主权要求时，维护开放语义平面与 Palantir 运营平面的版本化投影。
只有语义、推理和跨平台复用需求，却没有复杂运营闭环，不应仅因“需要本体”采购 Palantir；只有对象、应用和动作，却没有可移植的定义与退出测试，也不应把平台便利误当成语义资产已经掌握在自己手里。
先给答案：三条路线分别适合谁
第一条是 OWL 优先。团队用 RDF/OWL 表达核心概念、关系和公理，用 SHACL 或等价约束定义数据与动作形状，用 SPARQL、规则引擎或推理器完成需要的计算，外接已有数仓、语义层、应用、工作流和 Amazon Ads 适配器。这条路适合已经有数据平台和工程能力、需要跨广告渠道或跨系统复用语义、重视开放标准和可移植性的组织。
第二条是 Palantir 优先。团队把广告、零售、库存、财务和供应链数据接入 Foundry，以 Object Types、Link Types、Interfaces、Functions、Actions 和权限构建运营对象，再通过 Workshop、OSDK 或 AIP 交付应用与 Agent。这条路适合决策链跨多个部门和系统、需要较强运营应用、权限和写回能力，并且能够承担平台采购、实施与治理成本的大型组织。
第三条是双平面投影。开放平面保存 URI、概念、关系、公理、shapes、来源和版本，Palantir 平面保存面向运营的对象、链接、派生属性、函数、动作、权限和应用；中间使用显式映射与测试过的投影编译器连接。它适合行业本体或核心语义必须被多个平台消费、存在监管交换或明确退出要求的组织，但同步、映射和双版本治理成本很高。
图 1：路线选择首先取决于业务闭环复杂度和语义主权，不取决于哪个名词更先进。
还有第四个经常被忽略的答案：暂时都不用。一个团队只管理少量 Sponsored Products，核心问题是报告粒度不清、成本指标口径不稳、人工流程没有审批和回查，那么先完成数仓、语义层和简单工作流更合适。架构成熟度不是所用名词的先进程度，而是解决问题的最小系统是否可靠。
两个 Ontology 来自两条技术谱系
OWL 2 Overview把 OWL 描述为用于本体的 Web Ontology Language。它的形式基础来自描述逻辑，关注类、属性、个体、公理、解释与蕴含。开放世界、非唯一名称以及不同 profiles 的计算取舍，都是为了让分布式知识可以在明确语义下组合和推理。
Palantir 的“Ontology”来自另一条路线。它先把分散数据映射为业务对象、属性和链接，让用户脱离底层表工作；随后将 Functions、Actions、Security 和应用连接到对象层，形成决策与执行系统。Palantir 当前的Ontology system 架构说明进一步把体系概括为 Language、Engine、Toolchain，并强调 data、logic、action、security 的四重结合。
这两个 Ontology 的交集是业务概念和关系，差异则远大于交集。OWL Language 有公开规范、模型论语义和多种独立工具实现；Palantir Ontology Language 属于平台元模型，表达对象、链接、动作、自动化和逻辑，并由专有 Engine 实例化，再由 Toolchain 服务应用开发。不能因为两者都能表示 Campaign contains AdGroup，就推导它们具有同一约束、推理和事务语义。
图 2：两条谱系在业务对象处相遇，却分别继承形式语义与运营执行的不同责任。
这一区分在 Agent 时代尤其重要。Agent 需要知道 campaign、target、ASIN 和 proposal 是什么，也需要通过工具执行调价、预算或否定动作。OWL 可以让概念和部分约束更加精确，但不会自动提供安全的业务工具；Palantir 可以把 Actions 暴露给应用或 Agent，但具体 Action 是否符合投放策略，仍取决于组织自己定义的对象、规则、权限和外部适配器。
先定义 Amazon Ads 运营系统的完整责任
讨论选型前，应把系统要承担的工作列完整。第一个责任是数据接入与对账：Amazon Ads API、异步报告、Marketing Stream、AMC、Seller/Vendor 零售数据、库存、价格、利润和内部商品主数据都有不同刷新频率、时区、币种和粒度。系统必须保留来源和版本，而不是把最新值覆盖成一张“黄金宽表”。
第二个责任是对象与语义：profile、marketplace、campaign、ad group、target、search term、advertised ASIN、purchased ASIN、placement、budget 和 attribution window 要有稳定身份；spend、sales、orders、ACOS、ROAS、TACOS、利润贡献和成熟度要有可计算定义。这里既包括主数据，也包括指标合同和时间语义。
第三个责任是策略与分析：搜索词发现、迁移、否定冲突、竞价上界、placement 调整、预算节奏、库存风险和新增客户分析需要规则、模型、方案模拟和证据解释。不同策略的目标和观察窗口不同，不能由统一阈值驱动。
第四个责任是运营应用：投手、品牌负责人、供应链、财务和审批人需要看到不同但一致的对象视图，处理候选、冲突、批准、异常和复盘。只有数据模型，没有面向工作的应用，语义仍停留在后台。
第五个责任是行动与可靠性：动作要有 before/after diff、基线版本、影响范围、数值上限、批准、幂等、远端回执、回查和补偿。Amazon Ads 是外部系统，任何平台内部的事务承诺都不能自动覆盖跨 API 的端到端一致性。
图 3：先把六项责任补齐，才能判断 OWL、Palantir 或现有技术栈各自承担哪一段。
第六个责任是安全和治理：读取广告表现、查看利润、执行预算调整和修改本体定义是不同权限；人和 Agent 都需要可识别身份和作用域。对象、规则、动作、应用和来源还要版本化、评审、测试并能够退出。
OWL 原生主要覆盖第二项中的形式概念、关系与推理基础，可以参与第三项的规则和验证；其余能力需要组装。Palantir 平台公开定位覆盖更广，但“平台提供能力”不等于“具体 Amazon Ads 产品已经建成”。数据接入、领域建模、适配器、策略规则、应用设计和组织治理仍是项目工作。
十个维度看清差异，而不是比较营销名词
第一个维度是元模型。OWL 的基本构件是 class、object/data property、individual 和 axiom；Palantir 的公开对象层包含 object type、property、link type、interface，并进一步连接 function、action 和 automation。两种元模型的目标不同，映射只能是有损或带扩展的，不能假设一一对应。
第二个维度是形式语义。OWL 2 有 W3C 推荐规范、Direct Semantics 与 RDF-Based Semantics，可以严格定义何时一个结论被本体蕴含。Palantir 文档描述了平台行为和对象能力，但公开材料不足以证明其 Ontology Language 等价于 OWL 的模型论语义。产品规则正确性应按平台契约测试，不能借 OWL 的形式性替它背书。
第三个维度是推理。OWL reasoner 擅长分类、实例检查、一致性和公理蕴含，不直接优化预算；Palantir 可以用 derived properties、Functions、模型、LLM 和 orchestration 计算业务逻辑，但这些计算不应统称为描述逻辑推理。二者都可能参与决策，却要保留结论类型。
第四个维度是约束验证。SHACL 针对 RDF 图输出明确 validation report，OWL 通过不可满足或不一致表达部分语义冲突；Palantir Action submission criteria、对象限制和 Functions 可以在动作时验证业务条件。数据形状、本体一致性和动作提交标准是三种门禁，不应互相替代。
第五个维度是数据运行时。OWL 是语言规范，不规定企业数据索引、查询扩展、流处理和写回存储。Palantir Ontology query compute说明对象集合可以通过 Search Around、aggregation、Ontology SQL、derived property 等方式计算，并由其对象存储和多种计算后端支撑。这里比较的是语言与平台，不是两个数据库性能。
第六个维度是动作和事务。OWL 可以描述 Action 类、前置条件和状态，却不执行 Amazon Ads API。Palantir Action Types把 action 定义为基于用户逻辑修改一个或多个对象的单次事务，并可包含 side effects。跨外部广告系统时，仍需确认 side effect 的超时、幂等和回查语义。
图 4：比较的目标是暴露不对称能力，而不是把十个维度压成一个采购总分。
第七个维度是权限与审计。OWL 标准本身不提供企业权限模型。Palantir 把安全放在对象、逻辑、动作和应用中，并提供 action log 等能力；但 Action Log 文档也明确，日志覆盖通过 action type 产生的编辑，旁路数据写入不会自动产生相同日志。这是架构边界，不是小功能差异。
第八个维度是应用交付。OWL 生态提供 Protégé、图数据库、API 和各种建模工具，运营应用通常要自行开发；Palantir 提供 Workshop、Object Explorer、OSDK 等产品面，把对象和动作直接用于应用。它降低的是集成和交付链长度，不免除产品设计。
第九个维度是开发和运维。开放路线可以按团队需要选择 Jena、RDFLib、GraphDB、Stardog、Neo4j、规则引擎和工作流，但版本兼容、部署、观测和安全由自己负责。Palantir 提供统一 toolchain 和平台运维模型，代价是需要接受平台范式、技能结构和商业边界。
第十个维度是可移植性。OWL 文档和 RDF 数据可被多个实现读取，但自定义规则、存储优化、应用和权限仍可能锁定；Palantir 提供 REST、SDK、JSON authoring 和数据开放格式，也不能由此推导复杂 Actions、Workshop 应用和权限可以零成本迁移。真正的可移植性只能通过退出演练证明。
路线一：OWL 优先，把语义当作可移植资产
OWL 优先不等于“所有数据都放入 RDF”。更实际的架构保留现有湖仓和语义指标层，只把需要跨系统复用的概念、关系、公理、形状、映射与决策引用放到开放语义平面。高频广告事实通过稳定 ID 和快照引用进入推理，避免每小时把大量指标物化为三元组。
这一平面可以用 OWL 表达 ExactKeywordTarget、ProductTarget、Campaign、AdvertisedProduct 和状态类别，用 properties 表达归属、投放、观察和约束关系；用 SHACL 检查 Proposal 的 profile、marketplace、对象基线、证据窗口和权限引用；用 SPARQL 或规则计算影响范围和资格；用 PROV-O 与时间词汇记录来源和有效性。
运营外壳需要自己建设。第一部分是查询和决策服务，把数仓指标、本体关系、规则和模型结果组装为类型化 Proposal。第二部分是工作流和审批，管理任务状态、人工判断和授权租约。第三部分是 Amazon Ads adapter，处理区域端点、限流、异步任务、幂等和远端回查。第四部分是面向投手的应用和可观测性。
图 5：OWL 优先获得的是开放语义资产；运营闭环仍需要完整外壳。
优势在于语义边界公开。概念 URI、shapes、能力问题、映射和测试可以进入 Git，多个工具能够消费同一资产，核心定义较容易与 Google Ads、零售、CRM 或供应链对齐。形式推理需要强表达时，也有不同 reasoner 和 profiles 可选。
代价同样明确。OWL 工程人才较少；开放工具之间并不自动无缝；完整企业运行时涉及身份、权限、应用、事务、索引和运维；过度追求形式表达会造成性能和可用性问题。团队必须愿意做产品和平台，而不是以为选择标准就省去了系统建设。
对于以 Amazon Ads 为主、已经拥有成熟数据平台的大型服务商，OWL 优先可以把“投放对象和策略合同”做成跨客户、跨渠道的知识资产，但每个客户 profile、marketplace 和权限仍要隔离。对单品牌小团队，这套投入往往超过收益。
路线二：Palantir 优先，把本体当作运营后端
Palantir 优先的价值主张不是“更强的 OWL”，而是缩短从数据到对象、从对象到应用、从判断到动作的距离。官方入门概念把数据层与对象层区分开：表格数据被转换为组织可理解的 objects 和 links，并可以定义 Actions 捕获用户决策。
Language 层定义 Amazon Ads 对象、链接、接口、动作和逻辑引用。Engine 层负责对象索引、查询、订阅、事务编辑、批量变更与写回等运行能力。Toolchain 让开发者和业务构建者通过 Ontology Manager、Workshop、Functions、OSDK 和 API 使用这些能力。文章使用“层”描述产品责任，不假设所有能力对每个版本、部署或许可证都可用。
图 6：Palantir 的本体价值来自 Language、Engine 与 Toolchain 的联动，而不只是对象建模。
对象层可以建立 Campaign、AdGroup、Target、ASIN、SearchTermObservation、RetailState 与 OptimizationProposal；Links 连接归属、观察、投放商品和证据。Interfaces 可把多个广告产品共享的属性抽象成可复用表面。Derived properties 和 Functions 计算跨对象指标或资格，但需要控制实时计算成本和版本。
Actions 把运营意图封装为可复用操作。例如 HarvestSearchTerm 不只是改一个属性，它可能创建 target、调整原结构 bid、写入 negative、生成 action log 并通知负责人。Submission criteria 检查当前用户、参数和对象状态；Function-backed Action 承载更复杂逻辑；side effect 或外部系统集成把决定推向 Amazon Ads。
权限和应用是一体化路线的重要价值。投手可以看广告对象和策略候选，供应链人员只看到库存与补货相关范围，财务能查看利润约束，Agent 以受限身份调用具体 Actions。Workshop 或自定义 OSDK 应用在同一对象模型上交付，不用每个前端重新解释表与权限。
但平台不会替组织定义正确业务。若把 search term 和 keyword 合成同一 Object Type，或把 placement ROAS 做成无时间窗口的属性，Palantir 只会更高效地传播错误。Actions 也必须处理 Amazon 外部 API 的不确定性；平台内 object edit 成功不代表远端预算已经确认。
Palantir 路线的经济性来自跨系统和跨角色复用。若团队只需要每周生成十个关键词建议，一个轻量服务足够；若同一对象模型同时支撑广告、库存、定价、供应链、财务、审批、场景模拟和 Agent，统一运营后端的边际价值才开始显现。
产品功能图：业务人员到底得到什么
第一类功能是对象工作空间。运营人员不从数据表开始，而从 ASIN、campaign、target 或 proposal 进入，看到与当前任务有关的表现、关系、风险、历史动作和负责人。对象视图必须显示数据更新时间和口径，避免“统一界面”掩盖来源差异。
第二类功能是策略队列。搜索词迁移、否定、竞价、placement 和 budget candidates 以 Proposal 对象存在，能够排序、分派、评论和批量审查。每个 proposal 连接证据、规则、模型版本和冲突；不是把一个大模型聊天窗口当作运营系统。
第三类功能是 scenario。投手可以在不改生产的情况下模拟迁移、否定和预算调整，观察结构影响、权限冲突和经营约束。Palantir 文档描述了 scenario 与运营应用的组合，但具体广告销售预测仍要使用经验证的模型，不能把结构模拟解释成收益保证。
图 7：产品价值落在角色工作流上，而不是一个孤立的 Ontology Manager 界面。
第四类功能是动作与审批。Action 表单和应用呈现参数、当前值、拟议值、影响对象、提交标准和权限；高风险动作进入审批，低风险可在额度内执行。提交后 Action Log 或独立决策日志记录谁在何时基于什么上下文做了什么。
第五类功能是开发和治理。本体负责人查看对象、链接、函数、动作和应用的依赖；数据工程师追踪 backing datasets 和 lineage；开发者用 OSDK 构建定制界面；安全人员检查数据、对象、逻辑与动作权限。成熟产品应让变化影响可见，而不是把 Ontology Manager 当成孤立配置中心。
路线三：双平面投影，只在有理由时组合
双平面架构的第一条规则是确定权威。开放平面拥有概念 URI、类层次、公理、shapes、定义、来源、版本和废弃策略；Palantir 平面拥有运营对象、链接、Functions、Actions、权限、索引和应用。两边都可以包含 Campaign，但负责的字段和变更方向必须清楚。
第二条规则是投影而不是自由同步。编译器读取一个已发布的开放本体版本，生成或校验 Palantir object/link/interface 的映射清单，再由人工评审应用。运行时对象数据仍由明确数据源进入 Palantir，不把所有实例反复导出回 OWL。Palantir 中新增的 action 不会自动变成 OWL 公理，而是通过扩展词汇或动作合同另行登记。
第三条规则是接受有损。OWL 的 union、intersection、restriction、property chain 或某些 cardinality 不一定在运营对象元模型中有直接对应；Palantir Action 的 submission criteria、side effects、权限和应用依赖也无法用基础 OWL 完整表达。映射清单需要标出 exact、derived、manual、unsupported 四种状态。
图 8：双平面不是自由同步，而是带版本、损失声明和验收测试的单向投影。
第四条规则是双版本测试。开放本体从 v12 升到 v13 时，先运行 OWL 一致性、SHACL 和能力问题，再生成 Palantir 投影差异，检查受影响对象、函数、动作、应用和 SDK。Palantir 运营变更若产生新的业务概念，应走提案流程回到开放平面，而不是由运行时静默反向覆盖。
双平面只有在三个条件同时存在时值得：语义确实需要跨平台或跨组织复用；核心定义必须拥有独立生命周期和退出能力；团队能够长期维护映射、测试和治理。若只是为了“既开放又先进”，它会带来两个模型、两套版本和更多组织争论。
Amazon Ads 领域模型不能照抄 API 资源树
Amazon Ads API 的资源和端点是集成合同，不是完整业务本体。照抄 API 会让模型围绕请求格式组织，难以表达观察、经营约束和决策。更稳妥的划分是五个业务域。
投放配置域包含 Profile、Portfolio、Campaign、AdGroup、Target、Ad 与 Creative。Target 再区分 keyword、product、audience 或自动 targeting expression。每个身份包含 marketplace、ad product、外部 ID、有效时间和数据来源。
流量观察域包含 SearchTermObservation、PlacementObservation、TrafficEventSummary、ConversionObservation 与 AttributionWindow。Observation 是带粒度、时间和版本的事实，不能直接成为 Campaign 的永久属性。hasHighROAS 也应是某个窗口和目标下的派生状态。
商品零售域包含 AdvertisedASIN、PurchasedASIN、InternalSKU、InventoryState、FeaturedOfferState、PriceState、ContentState 与 MarginPolicy。它把“是否值得继续买流量”纳入广告决策，但保持来源和负责人独立。
经营约束域包含 Objective、BudgetPolicy、RiskTier、MarketplacePolicy、ApprovalPolicy 与 ExperimentPlan。它解释相同指标为什么在新品探索、品牌防守和利润收割中导致不同动作。
图 9：API 资源只覆盖集成合同，运营对象还必须容纳观察、经营约束与决策记录。
决策记录域包含 Proposal、EvidenceSnapshot、Scenario、Approval、ExecutionAttempt、RemoteReceipt、RollbackPlan 与 OutcomeReview。Palantir 路线可以把它们实现为 Objects、Links 和 Actions；OWL 路线可以把核心语义和形状开放表达，再由应用数据库管理运行状态。
三条路线真正交付的资产并不相同
OWL 优先路线的第一类资产是规范：命名空间、概念定义、类层次、属性、公理、shapes、能力问题和版本策略。第二类是映射：Amazon 报告、广告 API、库存、财务字段怎样映射到领域概念。第三类是可执行语义：规则、查询、验证和测试。第四类才是外围产品：策略服务、工作流、应用和适配器。
Palantir 优先路线的资产结构不同。Object Types、Link Types、Interfaces、Functions、Actions 和权限配置组成平台内的运营语言；backing datasets、对象索引和 writeback 承担运行状态；Workshop 模块、OSDK 应用、AIP Logic 或 Agent 构成用户界面和自动化；Action Logs、lineage、health 和平台资源构成治理证据。它是一个连贯交付面，但大量资产与平台元模型绑定。
双平面路线必须明确哪些资产只写一次。概念定义、公理、外部 URI 和 shapes 由开放平面权威管理；面向 Palantir 运行的对象显示名、索引策略、derived property、Action、权限和应用由运营平面管理；映射规范和兼容测试由独立投影项目管理。若同一个规则可以在两边直接编辑，维护者迟早会面对无法判断谁覆盖谁的冲突。
“资产”还要区分源码与运行实例。本体定义可以进入 Git，实例数据仍受系统权限和保留策略管理；Action 配置可导出，历史提交、外部回执和应用状态可能需要另一套迁移方法；OSDK 类型可重新生成，业务应用行为不因此自动复现。选型评审必须按资产逐项检查，不接受一句“平台都支持导出”。
这一区分会改变项目里程碑。OWL 项目不能以 .owl 文件完成作为交付，至少要证明一个业务问题能查询、验证和解释；Palantir 项目不能以对象图漂亮作为交付，至少要让一个受限 Action 完成远端回查；双平面项目不能以双方都有 Campaign 概念作为交付，至少要通过版本差异和重建测试。
Palantir 产品架构映射到 Amazon Ads 后会发生什么
数据接入层需要区分配置、表现和经营事实。Campaign、AdGroup、Target 等配置适合形成可持续同步的对象 backing data；Search term、placement 和 advertised product 报告是按窗口产生的 observations；Marketing Stream 提供更细时效信号；AMC 面向隐私安全的事件分析；库存、价格和财务来自广告系统之外。所有数据都需要保留 profile、region、marketplace、timezone 和 currency。
管道层负责规范化和对账，而不是简单拼表。配置快照采用有效时间，表现事实保留报告日期与拉取版本，归因回填通过修订而不是覆盖进入，商品映射带置信度和来源。Palantir 可以提供数据变换、lineage 和调度能力，但领域管道仍需团队设计。错误粒度进入对象层之后，只会更容易被应用重复使用。
Ontology Language 层把数据资产变成对象、关系和动作入口。高频 observation 不一定全部索引为独立对象，可以按查询和审计需要选择对象、时序属性、聚合或外部计算。Campaign、ASIN、Proposal 和 Decision 通常值得成为对象；每个 click 是否成为对象则要基于实际工作负载，不能用“数字孪生”口号决定。
Ontology Engine 层为对象搜索、Search Around、aggregation、derived property、订阅和编辑提供运行能力。Amazon Ads 策略可能需要从一个 ASIN 查找所有 campaign，从一个 proposal 展开影响 targets，再调用函数读取成熟指标。查询设计要考虑对象集合规模、索引、派生计算成本和权限过滤，不能假设所有多跳关系都实时免费。
Logic 层包含确定性规则、优化器、统计模型和 LLM。竞价上界可以由利润和转化假设计算，冲突由关系规则发现，场景由优化器求解，解释由 LLM 生成。每种 Logic 都需要输入、版本、测试和权限。Palantir 把它们连接到 Ontology，不意味着它们获得相同的正确性保证。
Action 层把 Proposal 变成运营事务。平台内部对象编辑可以生成 action log，外部 Amazon Ads 写回通过 connector、webhook、function 或定制服务完成。系统需要把平台 action RID、外部 correlation ID、Amazon 对象 ID 和回读快照关联，才能在跨系统故障时定位。
应用层服务不同角色。投手处理候选和异常，商品团队确认 ASIN 适配，供应链处理库存风险，财务维护利润与预算政策，审批人审查高风险动作，平台团队治理对象和 Actions。统一应用不是所有人看到同一页面，而是在同一对象和权限模型上获得不同任务视图。
AIP 或 Agent 层最后接入。Agent 查询经过权限过滤的对象，调用只读 Functions 形成解释，通过受限 Action 提交提案。它不直接拥有底层数据、万能对象编辑或外部广告 token。模型上下文由任务相关子图构成，状态保存在 Proposal 和 Workflow 中，长任务可暂停、恢复和撤销。
OWL 侧的开放模型需要达到什么工程深度
一个只有类名和父子层级的 OWL 文件，很难承担长期语义资产。Campaign、Target、Observation、Proposal 和 Action 的定义需要明确自然语言说明、URI、scope 和 owner；关键 properties 说明 domain、range、方向和时间；同一关系与相似、映射、派生关系严格分开。
OWL 公理只表达适合开放世界和单调推理的知识。ExactKeywordTarget 是 KeywordTarget 子类、belongsToAdGroup 的 range 是 AdGroup，这些较稳定；“ACOS 低于目标就加价”涉及数值、窗口、目标和非单调策略，更适合规则服务。用 OWL 表达一切不会提高严谨性，只会把不同计算责任藏进难维护的公理。
SHACL 负责图形状和局部完整性。ProposalShape 可以要求 profile、marketplace、target object、evidence snapshot、risk tier 和 expiry；SearchTermObservationShape 要求粒度、窗口、来源与 advertised product。Shapes 也需要版本与测试，不能把所有业务异常都当作数据不合法。
映射层负责从报告和 API 资源生成 RDF 或语义引用。R2RML、RML、自定义转换或虚拟知识图都可以选择，关键是身份策略、时间和来源。映射变更会影响实例身份时必须迁移和回放，不允许直接重新生成图导致历史 proposal 断链。
推理层选择 profile。OWL 2 EL、QL、RL 和 DL 面向不同表达与计算特征，团队不应默认使用表达力最高者。若主要需求是类层次、属性规则和规模化实例推导，RL 或显式规则可能更实际；若核心是关系查询而非形式蕴含，SPARQL 或属性图即可。
应用层通过稳定服务消费语义，不直接绑定某个 triple store 的扩展语法。getProposalEvidence、validateActionInput、findNegativeConflicts 和 explainEligibility 这类业务 API 隔离底层实现，使团队可以替换 reasoner 或存储而不影响投放产品。
开放模型还要有发布链。每次变更生成语义 diff、兼容性评估、能力问题、正反例、SHACL 结果和受影响消费者；发布后监控未知类、无来源边、违反 shape 的实例和查询性能。所谓开放，不是把文件放到仓库，而是让语义能够被独立检查和持续演进。
双平面投影必须有一份可执行合同
投影合同第一部分是 identity mapping。每个开放概念映射到哪个 Palantir object type 或 interface，主键如何构造，profile 与 marketplace 如何进入作用域，哪些对象不能合并。映射必须有稳定 ID，不靠显示名称匹配。
第二部分是 property mapping。OWL data/object properties 映射到 Palantir properties、links、derived properties 或外部 function。每一项标记 exact、transformed、derived、manual 或 unsupported，注明数据类型、cardinality、null/unknown 语义和时间。不能映射的公理保留在开放平面，由验证服务提供结果。
第三部分是 constraint mapping。SHACL shapes 中哪些约束在数据管道校验，哪些在 Palantir Action submission criteria，哪些必须由 Function 检查。相同约束如果在多个位置实现，要有共同 rule ID 和一致性测试；否则错误消息和行为会逐渐分叉。
第四部分是 action mapping。开放语义可以定义 ActionContract、parameter、precondition、effect、risk 和 evidence requirement，Palantir 侧实现具体 Action Type、rules、Functions、side effects 和 log。合同不要求 OWL 执行事务，但允许独立审查一个动作是否仍符合组织语义。
第五部分是 version mapping。Ontology v13 对应 Palantir Ontology release p42，投影编译器版本 c7，Functions 与 Actions 有自己的版本。每个生产 proposal 保存这组版本。发布新版本时先生成 diff，再检查对象、链接、Functions、Actions、应用和 OSDK 消费者。
第六部分是 drift detection。定时读取 Palantir ontology metadata，与期望投影比较；发现对象、属性、link 或 action 未经流程变化时生成 drift，不自动覆盖。紧急生产修复允许先在运营平面实施，但必须有期限回补开放合同和测试。
第七部分是回滚。删除或重命名概念可能影响数据、索引和应用，不能只恢复一个 JSON 文件。合同为 breaking change 定义兼容期、旧新对象并行、数据迁移、SDK 更新和 action 停用顺序。回滚测试应包括已有 proposal 和历史日志仍能解释。
维护这份合同需要真实团队和工具投入。若组织无法指定 owner、持续运行 diff 和修复 drift，双平面不会带来主权，只会制造第二套过期文档。架构评审应把运营成本写进决策，而不是只展示理想状态图。
用搜索词迁移做一次端到端产品验收
无论选择哪条路线，都可以用同一验收场景比较。输入是一条来自自动 targeting 的 SearchTermObservation，它在成熟窗口中产生订单；账户已有多个可能承接的手动 ad groups，也存在若干 negative 和商品差异。系统需要形成迁移提案，但不能直接写生产。
第一步验证事实。系统从指定报告版本读取 search term、source target、advertised ASIN、purchased ASIN、clicks、spend、orders 和 sales，确认 profile、marketplace、currency、timezone、grain 和 attribution snapshot。任何口径不明都应停止，而不是让本体“补出”数据。
第二步验证对象。目标 ad groups 的商品集合、策略目的、状态和 campaign 控制边界必须可见；已有 targets 和 negatives 可被查询；内部商品与 ASIN 映射有来源。OWL 路线通过图查询和服务组装，Palantir 路线通过 Objects、Links、Search Around 与 Functions 获取，但业务问题相同。
第三步验证判断。系统产生支持和反对 claims，区分逻辑规则、路径影响、统计分数和人工确认。至少包含候选目标、匹配类型、初始 bid 上限、重叠 targets、negative 风险、库存与利润门禁、proposal expiry。审批人能够修改方案，却不能删除必要证据。
第四步验证动作。批准绑定对象、数值和有效期；提交前读取远端基线；创建 target 使用幂等身份；结果未知时先回读；需要 negative 或 bid 调整时按分步计划执行；部分成功保留现场。每个尝试连接平台 action/log 和 Amazon receipt。
第五步验证后果。系统不在第二天就宣布成功，而是等待约定成熟窗口，比较目标结构是否承接流量、原探索是否保留、新旧 target 是否竞争、总利润和库存是否符合边界。结果回到 Proposal 和规则评测。
OWL 优先路线的验收重点是语义能否独立验证和跨实现重放；Palantir 优先路线重点是对象、应用、权限和 Action 能否缩短可靠闭环；双平面重点是同一场景能否从开放定义投影并通过两侧版本测试。三者使用相同业务样本，才能进行公平比较。
零售就绪场景更能暴露平台价值与代价
当广告决策只涉及 campaign 和 target，专用工具很容易满足需求。零售就绪场景把对象扩展到库存、Featured Offer、价格、毛利、商品内容、补货计划和负责人，涉及的数据源、角色和动作明显增加，更适合检验企业运营本体是否有价值。
一个 RetailReadinessIssue 可能由库存覆盖不足、价格异常或 Featured Offer 不稳产生，连接受影响的 ASIN、ad groups、campaigns 和 pending proposals。投手需要暂停或限价，供应链需要补货，商品团队需要修复详情页，财务需要评估利润。各角色看到同一事件的不同视图。
OWL 路线可以用开放本体统一概念和影响关系，让不同系统共享 AccelerationBlocked、InventoryRisk 等定义；工作流平台负责分派任务与审批，广告适配器负责动作。优势是语义可被多渠道和系统复用，难点是把多个产品拼成一致体验。
Palantir 路线可以在一个对象层连接数据、Functions、Actions 和 Workshop 页面，并按角色权限呈现。库存状态变化触发 proposal 失效，应用通知负责人，受限 Action 调整投放并写入日志。优势来自端到端组合，难点是建模、性能、许可和平台治理，以及外部 Amazon 写回仍需可靠适配。
双平面在这里才可能展现理由：零售和商品本体已经被供应链、PIM、客服和其他广告平台使用，不能只存在 Palantir；与此同时，运营团队需要 Palantir 应用和动作。开放平面维护核心语义，Palantir 投影服务日常运营。若语义没有外部消费者，双平面价值仍然不足。
验收指标也从“模型是否正确”扩展到决策周期、跨团队交接、重复对账、错误动作、库存损失和恢复时间。平台项目只有在这些结果上提供增量，才值得扩展更多对象。对象数量、页面数量和 Agent 演示不构成业务成功。
多市场预算协同是运营本体的压力测试
多 marketplace、多品牌和多实体经营会引入时区、币种、税费、库存区域、利润政策、广告资格和审批链。一个市场的低 ACOS 不能与另一个市场直接比较，预算也不一定可以自由转移。系统需要把可比性和资金约束建模，而不是先统一换算后排序。
预算候选连接 campaign、objective、marketplace、currency、pacing、attribution maturity、inventory、margin、promotion、portfolio 和 account policy。优化器可以求解分配，但本体与规则必须先确定哪些对象允许比较、哪些资金不能跨域、哪些市场需要本地审批。
Palantir 的对象、scenario、Functions、Actions 和权限在这类场景有更强契合：用户可以在场景中调整资源，查看跨对象影响，再由授权人员执行。但模型和应用需要大量领域工作，且计算结果必须标注假设。平台提供 scenario 能力不等于业务优化器已正确。
OWL 优先路线可以把市场、币种、目标、预算约束和组织权限表达为开放语义，配合外部优化器和工作流。这种组合技术更多，却可能更适合已有优化平台和多云策略的组织。是否选择 Palantir，取决于现有能力缺口，而不是场景复杂就必然采购。
双平面路线在监管、跨法人或多平台交换时更有意义。核心预算政策、地区和实体定义在开放平面，Palantir 投影用于运营 scenario 与审批。投影必须防止敏感利润或账户信息被不适当地导出；开放语义不代表实例数据公开。
压力测试应覆盖规模、权限和恢复。大对象集合查询是否稳定；一个用户能否通过关系绕过数据权限；多个 Actions 是否产生一致日志；外部 API 部分失败后 scenario 与现实是否分离；汇率或归因回填后旧 proposal 是否正确失效。平台在正常演示里流畅，不代表在这些边界上可靠。
决策日志必须同时保存业务原因和协议事实
Palantir Action Log 可以记录 Action RID、type/version、时间、用户、编辑对象、side effects、scenario 与 revert 等信息，还能保存参数和相关对象属性。它适合把运营决定变成可查询对象，并支持跨应用展示“谁在何时改了什么”。
但完整 Amazon Ads 审计还需要业务证据与协议事实。业务证据包括 Proposal、规则、观察窗口、利润和库存状态、审批意见；协议事实包括 API endpoint、request hash、correlation ID、attempt、HTTP/业务响应、remote object version 和 readback。二者不应都塞进一个自由文本日志。
Action Log 与外部 ExecutionReceipt 通过稳定 ID 连接。平台内 Action 提交成功但外部超时时，日志显示业务动作已发起，receipt 状态是 unknown；远端回读确认后更新 receipt，不修改原始提交记录。若补偿发生，建立新的 CompensationAction 并链接原 action，而不是删除历史。
直接更新 backing dataset、人工控制台操作和外部系统变化可能绕过 Action。系统需要定期对账，把未知变化形成 ExternalDriftEvent，连接发现时间、当前状态和最后已知 action。审计不能只覆盖“走了标准路径的好学生”。
日志保留也受数据治理约束。顾客搜索词、利润和用户身份可能具有不同敏感级别；通用 trace 只保存必要引用，详细数据留在权限更严的来源。Agent 的完整自由思考不应进入审计，结构化证据、工具参数和状态变化才是可复核事实。
决策日志最终服务三类工作：生产恢复、业务复盘和规则评测。恢复需要协议级状态，复盘需要当时业务上下文，评测需要输入与期望不变量。任何一类缺失，系统都只能讲述发生了什么，不能可靠地重新执行或改进。
用 POC 而不是演示决定采购
Palantir 的销售演示可以展示对象、应用、场景和 Agent 的连贯体验，但采购判断必须由自己的数据和故障条件验证。POC 不应选一个只读仪表盘，因为多数数据平台都能实现；也不应一开始覆盖全账户，范围太大无法定位价值。
最合适的 POC 是一个闭环策略，例如零售就绪约束下的受限投放动作。它包含三到五个数据源、跨广告和商品对象、两到三个角色、一个只读影响分析、一个人工批准 Action 和一次外部回读。这个范围足以检验 Ontology 的复用价值，又能控制风险。
验收分为六组。数据组检查来源、粒度、刷新和对账；语义组检查身份、定义和能力问题；产品组检查运营人员是否能完成任务；动作组检查基线、幂等、部分失败和回读；权限组检查最小可见与可执行范围；工程组检查版本、lineage、测试、观测和恢复。
POC 还要有替代方案基线。用现有数据平台加一个轻量工作流实现同一场景，记录交付时间、维护面、用户体验和故障恢复。没有对照，平台项目很容易把“终于整理了数据”的收益归给某个专有能力。
采购问题应具体：哪些功能属于当前合同；对象、Actions、Workshop、OSDK、AIP、MCP、scenario 和所需计算怎样计费或限制；数据与元数据怎样导出；服务终止时保留多久；自定义代码和外部连接怎样迁移；哪些能力需要专业服务；性能和支持边界是什么。无法由公开资料回答的内容必须进入合同澄清，不做乐观假设。
最后执行一次缩小版退出测试。导出 POC 的对象定义、关键数据、规则说明和决策日志，在外部环境重建核心查询与 validation。目的不是立即迁移，而是把“可退出”从承诺变成已测量工作量。只有业务闭环、权限、恢复和退出都达到门槛，POC 才证明平台适合长期使用。
Action Type 应该被设计成事务合同
以搜索词迁移为例，Action 参数不应只有 query 与 bid。它至少引用 source observation、target ad group、match type、initial bid、source route treatment、证据快照和期望基线。提交标准检查 proposal 未过期、对象仍在原状态、目标商品适配、冲突已处理、执行者有权访问相应 profile。
Action effects 可以在 Palantir 内创建或更新 Proposal、TargetShadow 和 DecisionLog，也可能通过 webhook、function 或外部系统集成调用 Amazon Ads API。这里出现了事务边界：Palantir 内的 object edits 和外部 side effect 不一定形成一个全局原子事务。适配器必须使用幂等键记录请求，在超时后先读取远端状态，不直接重复创建 target。
图 10：内部事务与外部 API 之间存在断点，回读和补偿必须成为动作合同的一部分。
预算动作同样需要期望基线。若提案基于 daily budget 100，而审批期间人工已改为 150，系统不能把建议的 120 覆盖上去。Action 在提交前比较远端当前值和 snapshot，发现变化则转为 stale，重新评估影响和批准。乐观并发控制比“最后写入者胜出”更符合运营安全。
批量动作要处理部分成功。十个 targets 中六个创建成功、四个失败，不能把整个动作标成 failed 后重试十个。ExecutionAttempt 记录每个对象的 remote receipt，补偿或恢复只处理未确认部分。Action Log 记录业务动作上下文，外部适配器日志记录协议细节，两者通过 correlation ID 对齐。
撤销也不是简单反向调用。移除 newly created target 可能损失后续数据，恢复旧 bid 可能不再适合当前环境。RollbackPlan 应在执行前定义可逆操作、保留数据、停止条件和人工复核。对不可逆或高影响动作，系统只能输出提案，不开放自动化。
Palantir Action 能统一平台内的对象编辑、规则和日志，但 Amazon Ads 写回跨越外部系统。端到端可靠性仍取决于业务基线、幂等、部分成功处理、远端回读与补偿协议，不能由“单次事务”四个字替代。
权限不是最后一层包装
第一个权限是数据源权限。用户是否能读取广告表现、顾客查询、利润或库存原始字段，由数据治理决定。第二个是对象可见性：同一个 ASIN 对象可能向投手展示广告和库存状态，向财务展示利润，但不暴露不必要的来源明细。
第三个是逻辑执行权限。能查看 proposal 不等于能运行使用敏感模型或高成本计算的 Function。第四个是 Action 权限与 submission criteria：执行者既要有相关对象权限，也要满足角色、参数和当前状态条件。第五个是外部账号权限：Amazon Ads profile、区域和授权主体必须与平台身份映射。
Agent 应作为可识别主体运行，或在严格条件下继承发起人的授权作用域。一个长期 Agent 不应永久持有整个广告账户写权限，而应获取绑定 proposal、对象、数值上限和有效期的权限租约。审批撤销或证据过期时，未执行动作立即失效。
图 11：可执行范围是五层权限的交集，任何一层放宽都不能替代其他层授权。
权限还需要解释。拒绝动作时，系统应返回缺失的是对象读取、Function 调用、Action 提交、外部 profile 还是批准租约，而不是统一显示“无权限”。这种可诊断性是运营产品的一部分，也能帮助发现配置漂移。
写回 Amazon Ads：最危险的边界在平台之外
Amazon Ads API提供程序化管理和报告入口，但具体能力、区域、账户资格、异步生命周期和限流需要按官方文档与真实账号核验。Palantir 可以成为编排和运营层，却不能改变 Amazon 作为远端系统的事实。
写入链从已批准 Proposal 开始。Action Service 生成稳定 correlation ID 和幂等身份，Adapter 按 profile 与 region 选择端点，读取当前远端对象，与 expected baseline 比较，再提交最小变更。响应若明确成功，仍需读取目标对象确认；响应若超时或不确定，进入 unknown，不允许直接重试。
远端回读成功后，ExecutionReceipt 连接 Action、Proposal、对象、请求摘要和返回版本。后续报告进入后，OutcomeReview 在成熟时间评估动作影响。若外部状态与平台对象不一致，系统区分同步延迟、人工修改、部分失败和映射错误，再决定修复方向。
图 12：写回闭环的终点不是 HTTP 200，而是远端状态回读、逐对象对账和结果成熟后的复盘。
这个过程说明 Palantir 的 writeback dataset 与 Amazon Ads system of record 也不是同一个东西。平台对象可以保存运营编辑和计划状态，远端广告配置仍需持续对账。任何“单一真相源”都必须说清是业务计划、平台投影还是 Amazon 当前状态。
三个策略场景检验三条路线
第一个场景是单账户搜索词迁移。数据规模不大，主要对象是 search term、target、ad group 和 campaign，动作频率有限。OWL 可以精确表达对象和约束，但若团队没有跨渠道复用需要，关系数据库、语义层和类型化工作流已经足够。Palantir 为这个单点问题引入整个平台，投入通常不成比例。
第二个场景是零售就绪约束投放。广告团队需要连接库存、Featured Offer、价格、毛利、详情页、补货计划和 campaign 结构，并让供应链、商品、财务和投手共同处理异常。对象关系、权限、任务、应用和动作开始反复复用。此时 Palantir 优先可能缩短交付链；OWL 优先则适合已有强平台团队、希望语义跨渠道复用的组织。
第三个场景是多 marketplace、多品牌的预算与库存协同。系统需要汇率和时区、区域库存、利润政策、多个广告产品、归因窗口、预算审批、场景模拟和跨系统写入。运营复杂度足以支撑统一 Ontology 和应用平台的价值，但也使平台锁定和退出风险显著上升。若核心语义必须进入多个数据平台、合作方或监管流程，双平面才有清晰理由。
图 13：场景越跨域，一体化平台的边际价值越明显，但治理与退出成本也同步上升。
三个场景的分界不在广告花费绝对值，而在决策关系和组织协同。一个高花费但结构简单的单品牌账户，未必需要企业运营本体；一个花费较低却跨多个地区、供应链和合规边界的业务，系统复杂度可能更高。选型要按对象、系统、角色、动作和错误损失量化。
Agent 接入后，本体必须约束工具，而不是装饰上下文
把整份 OWL、对象定义或关系图塞进提示词，不会自动得到可靠 Agent。模型上下文只能帮助理解，真正控制行为的是可调用工具及其参数、对象范围、规则版本和权限。Agent 应先检索与当前任务有关的最小对象子图，再调用确定性验证和模拟工具，最后产生 Proposal。
OWL 优先路线可以从本体生成类型、枚举、关系查询和 shape 验证接口，让 Agent 面对 propose_search_term_migration 而不是自由拼 API 请求。Palantir 路线可以通过 OSDK、Ontology API、MCP 或 AIP 暴露对象和 Actions。两条路线都应把写操作限制在少量高层业务动词，不暴露万能 updateObject。
模型的建议与系统事实要分开。LLM 识别“waterproof hiking shoes”和“waterproof trail shoes”意图接近，只生成 SemanticSimilarityClaim；规则和人工确认后才可能形成 MigrationProposal。Agent 的自然语言解释引用结构化 fact、path、rule 和 receipt ID，不把模型内部推理文本当作审计证据。
长时程任务还要求状态外置。等待归因成熟、等待审批、等待 API 回读或跨周复盘时，任务状态存储在 Harness 和决策对象中，不依赖一个持续增长的对话。权限租约随阶段重新检查，模型或工具升级也不改变已经批准的动作范围。
采购和建设都要接受可退出性测试
“使用开放标准”与“系统可退出”不是同义词。OWL 数据可以导出，但如果关键规则写在某个供应商扩展、应用和权限依赖特定实现，迁移仍然昂贵。反过来，商业平台提供 REST、SDK、开放数据格式和元数据导出，也不表示运营系统可以原样在其他平台运行。
Palantir 2022 年的互操作白皮书提到 Ontology 定义的 JSON 下载、RDF/XML/TTL/OWL 等格式导入导出以及 REST API。当前互操作架构页也说明数据、元数据、语义和代码接口。这些是重要能力证据，但来自厂商，且“可以导出”不等于“业务行为可复现”。
退出测试应覆盖九类资产。原始与转换数据能否在外部读取；对象定义能否还原身份和关系；指标和 Functions 能否重算；Actions 的前置条件、side effects 与补偿能否重建；权限能否映射；应用是否有替代；Action Log 和历史决策能否保留；Agent 工具合同能否迁移；构建和部署是否依赖平台专属服务。
一次实际演练比文档表格更有价值。选择一个 ASIN、一个 campaign 和一个 SearchTermMigration proposal，在外部环境重建对象视图，运行一条只读查询，复现一个资格规则，验证一条 shape，模拟一次不写生产的 action。记录缺失信息和人工工作量，才能估算退出成本。
双平面架构也必须参加测试。开放本体若只有概念名，而关键关系、规则和动作只在 Palantir，所谓语义主权只是名义；Palantir 投影若无法从指定本体版本重建，编译器就不是可靠边界。可退出性是一项持续测试，不是采购合同附件。
什么时候应该用 Palantir，什么时候不该用
第一个判断是业务闭环是否跨系统。仅做分析和建议，不需要多人协作、方案模拟和受控写回，现有数据平台加轻量应用通常更合适。若广告、零售、库存、财务和供应链对象反复参与同一决策，统一运营层才可能产生复用收益。
第二个判断是对象与动作是否可复用。若每个策略都是一次性项目，构建企业 Ontology 会变成昂贵抽象；若 Campaign、ASIN、InventoryRisk、Proposal 和批准动作被多个应用、团队和 Agent 使用，平台投资更容易摊薄。
第三个判断是交付速度与平台能力。组织是否已经有成熟的数据、身份、工作流、应用和 DevOps；如果都有，Palantir 的重叠价值可能有限。如果这些能力缺失但运营问题高价值，集成平台可能更快，但要评估实施伙伴、人才和持续治理。
第四个判断是形式语义和互操作。需要复杂 OWL 推理、行业本体对齐或跨组织交换时，不能假设 Palantir 元模型自动满足；可以选择 OWL 优先或双平面。若重点是对象驱动应用和动作，形式推理很少，Palantir 优先更直接。
第五个判断是商业和退出边界。评估许可证、实施、算力、培训、平台团队、数据迁移、动作适配器、治理和退出演练，而不是只比较开发工时。业务价值不足以覆盖长期总成本时，最专业的结论就是不采购。
图 14：任何路线都必须先设否决条件和退出演练，避免沉没成本替代架构判断。
总拥有成本首先是组织成本
OWL 优先的显性软件成本可能较低，隐性成本却包括本体工程师、平台开发、权限、运维、应用、工作流和跨工具集成。开源组件减少许可证，不减少责任。团队还要持续处理标准与实现差异、性能、版本和招聘。
Palantir 优先把大量平台责任集中到产品中，却需要采购与实施投入、专门技能、数据建模和应用建设。平台能力越丰富，如果没有清晰产品边界，越容易同时创建大量对象、Actions 和应用，最后形成难以治理的“第二套企业系统”。
双平面成本最高：两套模型、映射编译器、兼容矩阵、双版本测试和跨团队评审。它不是折中方案，而是为语义主权、跨平台复用和运营交付同时付费。没有硬性理由，不应默认选择。
成本评估应与动作价值一起计算。一个系统每周影响多少预算和商品，减少了多少人工对账，缩短了多少决策周期，避免哪类高损失错误，支持多少团队和应用；这些收益是否来自本体，还是仅来自更好的数据管道和流程。只有把替代方案一起估算，才不会把平台所有收益都归给 Ontology。
分阶段交付：先证明一个闭环，再扩展对象宇宙
第一阶段统一身份和指标。选一个 marketplace、一个广告产品和一个业务目标，稳定 profile、campaign、target、ASIN、search term 与 proposal 的定义，建立来源、时间和对账。这个阶段不追求全域 Ontology。
第二阶段交付只读场景。搜索词迁移或零售就绪预警只能选一个，系统展示证据、冲突和影响，不写 Amazon Ads。比较运营人员判断，积累拒绝原因与能力问题。OWL、Palantir 或轻量方案都应参加同一验收。
第三阶段加入一个受限 Action。定义参数、submission criteria、权限、基线、幂等、回读、部分成功和补偿，先由人工批准。动作日志与外部回执必须可以关联。平台内部演示成功不算验收，正式结果以远端状态为准。
第四阶段扩展对象、角色和应用。只有首个闭环证明复用价值后，才接入库存、财务、供应链或其他广告产品。每次扩展都检查定义是否仍清楚、权限是否最小、性能是否稳定和退出演练是否可通过。
第五阶段接入 Agent。Agent 先作为只读研究者，再成为 proposal 生成者，最后才在额度内执行已验证动作。升级模型不自动扩大权限，Ontology 或 Action 版本变化可触发降级。成功指标是决策周期、错误损失、可解释和恢复质量，不是 Agent 调用了多少工具。
结语：语义资产要带得走，运营动作要管得住
OWL 与 Palantir 的争论如果停留在“谁更像本体”，对 Amazon Ads 没有实际帮助。OWL 提供开放、精确和可计算的知识表示基础；Palantir Ontology 提供把数据、逻辑、动作、安全、运行引擎和应用工具链结合起来的运营路径。它们解决的问题不同，也承担不同成本。
小而清晰的广告优化问题，数仓、语义层、规则和工作流可能已经足够。需要跨渠道语义复用和形式推理时，OWL 优先更有理由。需要跨广告、零售、供应链和财务交付运营应用与受控动作时，Palantir 优先才可能体现平台价值。只有语义主权和运营平台两项要求都足够强，双平面投影才不是过度设计。
最终选型要回答两句话：哪些业务定义必须成为组织可以独立带走的长期资产，哪些运营能力值得交给一个集成平台。前一句决定语义主权，后一句决定交付效率；把两句混成“组织要做本体”，项目迟早会失去边界。