专栏 · Agent 工程手艺 › 第 211 期 · AI 产品 · 收录于 2026 年 9 月 14 日
Palantir 冲击:连接数据与 AI 的本体战略——Satoshi Yamauchi(Leading AI)
SY
Satoshi Yamauchi · GitHub
TL;DR · 三句话
- 一本体不是换个名字的数据模型，而是「名词 + 动词」一起定义的运营层：传统数据库设计只管名词（数据），把动词（业务逻辑与更新流程）丢给另一个应用层；Palantir 把对象 / 属性 / 关联（语义）和动作 / 函数 / 动态权限（动力）放在同一层定义，同时建好「看的模型」和「改的模型」，动作结果直接写回——数据从「只供查看」变成「直接驱动业务」。→ 详细
- 二能改写现实，就必须像管代码一样管业务规则：任何 schema 或动作行为的改动都走「工作分支 → 提交提案 → Approvals 评审（驳回就退回重改）→ 合并 main」，连工程师也不能直改生产，生命周期由平台强制执行、影子 IT 从结构上被杜绝，每次动作提交还会生成一个挂在被改对象上的 Action Log 对象永久留痕。→ 详细
- 三企业 AI 停在聊天机器人，是因为缺「共同语言」和「手脚」：本体让 LLM 只在已定义的动作范围内推理、只产出提案；连 AI FDE 自动搭本体也只能在用户权限内开分支、交人审——人的活从「连数据」升级为「审 AI 的提案是否符合业务意图」，而作者给的 5 个月落地路线里，提案审批与审计治理都排在接入 AI 之前。→ 详细
01
全书一句话定义：本体不是 IT 技术，而是「名词 + 动词」的运营层，靠「分支与审查」让 AI 安全动手
- 作者与定位：作者 Satoshi Yamauchi（山内怜史），SunAsterisk.inc 的商业设计师兼 AI 战略师、Leading.AI 创始人，本书是 Leading.AI 的一项开源研究。他开宗明义：要讲的 Palantir Foundry「本体」（Ontology）不是一项 IT 技术，而是一个运营层（operational layer，直接跑业务的那一层，而不是只存数据、出报表的那一层）——用名词（object 对象 / property 属性 / link 关联）和动词（action 动作 / function 函数 / dynamic security 动态权限）给现实世界建模，再通过分支与审查（branch-and-review）的治理流程，让 AI 能安全地作用于真实业务。全书口号：从「只供查看的数据」转向「直接驱动业务的数据」。→ 详细
- 三大核心信条：传统数据湖 / DWH（数据仓库）已沦为「只供查看的死数据沼泽」，Palantir 的范式建立在三条之上——① 运营层：让数据驱动现实，数据不是给人分析完再手动去推动现实的，本体是在系统里复刻业务的「数字孪生」；② 名词与动词融合，系统 = Object（名词）+ Action（动词），既要建模客户、零部件这类「状态」（语义，Semantics），也要建模下单、状态变更这类「动力要素」（Kinetics）；③ 现实的治理 = 给现实世界做版本控制，能改写真实业务的力量大到必须有绝对治理，「即便在 AI 自主提出方案的时代」，也要靠「分支」和「审查」同时拿到极致速度与治理。→ 详细
- 全书骨架：第一部分「问题与范式」（序章 + 第 1 章 Palantir 是谁 + 第 2 章本体是什么）→ 第二部分「行动的架构」（第 3 章图解架构 + 第 4 章治理）→ 第三部分「智能的命运」（第 5 章全球与日本案例 + 第 6 章本体 × AI 的未来 + 终章）。README 里另有一张作者自家 22 本系列开源书的推广表，与本书内容无关，略。→ 详细
02
序章的病灶：砸巨资建了数据湖和 BI，一线还在传 Excel、盯着屏幕手工重录
- 一线的荒诞场景：公司花巨额预算把各系统数据全抽进数据湖 / 数据仓库，上面再叠 BI（商业智能，出报表和仪表盘的工具），高管仪表盘天天更新；可到一线一看——经理边传 Excel 边问「这个仪表盘上的销售预测不对。原始数据在哪里？」；运营人员叹气：「我们用 AI 做了需求预测模型，可它没法和日常的订货系统打通，最后我只能一边看着屏幕一边手动录入。」基础设施建好了，业务流程照样割裂。→ 详细
- 根因：长期以来，数据只被当作「供分析用的静态快照（只供查看的数据）」。→ 详细
- 作者画的「断环」图：ERP / CRM 等业务系统 →（夜间批处理抽取）→ 数据湖 / DWH → BI 工具或 AI 模型 →（虚线）人看屏幕做决定 → 一线员工 →（虚线）手工重新录回业务系统。两段虚线就是断点：「存储与展示数据的地方」和「执行业务、写入变更的地方」完全割裂；只要这个结构性割裂在，AI 模型再先进，最后一步行动仍靠人手工重录，所以无法规模化。→ 详细
03
Palantir 的解法：把本体当运营层，让动作结果「立刻写回」形成闭环
- 学术定义打底：知识工程与语义网（semantic web，让机器读懂数据含义的一套标准体系）里最常被引用的本体定义，是 Gruber（1993）的「对概念化的明确规范说明」；Studer 等人（1998）把它扩展为「对共享概念化的形式化、明确的规范说明」。作者借此把 Palantir 的本体战略定位为一场「从根本上打破孤岛顽疾」的范式转变。→ 详细
- 闭环图：各类数据源 →（索引）→ 本体 / 运营层 →（调用名词与动词）→ 决策应用与 AI 模型 →（人的判断 + 自动化）→ 业务动作 →（结果立刻写回）→ 本体。和序章那张图只差一处，却是全部要害：最后一步不再是人手工重录，而是动作结果直接写回同一层，数据、决策、执行在一个回路里转起来。→ 详细
- 结论：从「只供查看的数据」到「直接驱动业务的数据」，是 AI 时代实现真正数字化转型的关键。→ 详细
04
Palantir 是谁：CIA 与战场里长出来的基因，定位是架在「数据盒子」和部门 SaaS 之上的「组织 OS」
- 出身：2003 年由 Peter Thiel（PayPal 联合创始人）与现任 CEO Alexander Karp 创立，早期投资方有 CIA 旗下风投 In-Q-Tel；首个平台 Gotham 服务美国国防部与情报机构（追踪恐怖分子网络、网络安全）。战场上数据孤岛是「直接导致人命损失与国家危机的致命缺陷」，要连起碎片数据、瞬间看清全局、立刻行动——Palantir 对「运营」与「治理」的执着由此锻造，基因与 AWS、Snowflake、Salesforce 截然不同。→ 详细
- 不是「数据盒子」：AWS、Google Cloud、Snowflake 卖的是低成本存算海量数据的「盒子」，怎么用数据驱动业务留给客户；Palantir 不取代盒子，而是架在其上，当「把数据转化为决策与行动的层」。→ 详细
- 也不是部门 SaaS：Salesforce、SAP 让销售、人力等单个部门提效，但部门级 SaaS 越多，全公司数据越孤岛化；Palantir 把各 SaaS 与遗留系统的数据整合成统揽全组织的「单一 OS」。→ 详细
05
Foundry 与 AIP：把战场本事搬进企业，本体是架构核心，AIP 在客户私网里接大模型
- Foundry（本书主角）为把国防与情报领域练出的数据整合与分析能力，搬进制造、金融、医疗、供应链等商业企业的复杂业务而生；Palantir 的 Architecture Center 文档写明，本体是整个架构的核心，设计目的不只是整理数据，而是表达「企业内部复杂且相互交织的决策」。→ 详细
- AIP（AI Platform）建在 Foundry 的本体地基之上，用来安全接入最新的大语言模型（LLM）；它运行在客户自己的私有网络里，给 AI 一个能安全执行真实业务任务的环境。→ 详细
06
FDE 实施模式：Palantir 被买单，靠的与其说是软件，不如说是「把工程师嵌进客户现场」
- 难点缠在部门冲突和历史包袱上：巨型企业的数据整合是「极其艰巨的工程」，缠着部门之间的冲突和数不清的遗留系统。作者的判断很直接：「比起出色的软件，Palantir 广受支持的最大原因更在于它的实施方式。」→ 详细
- 怎么嵌：按外部咨询机构 Everest Group 的分析，Palantir 把自家工程师直接派驻进客户的运营环境，在 Palantir 技术栈上搭生产级工作流；FDSE（Forward Deployed Software Engineer，前置部署软件工程师）一次只专注一个客户，和客户一起把工作流做到生产质量。FDE 的来龙去脉与本体地基见 ep106（Kevin Bai），Palantir 的组织哲学见 ep201（Shyam Sankar），这里不重讲。→ 详细
- 一线要快，治理是平台自带的：在现场飞快搭系统的同时，Foundry 平台本身就内建了治理理念——Ontology Proposals（本体提案）：改动先在从主版本（main）派生出来的分支上做，审查 / 批准之后才合并回 main，作者直说「类似于 pull request」（代码协作里「先提改动请求、别人审过才并入主线」的机制）；Foundry Branching（分支）：每个分支绑定到「单一本体」，从创建提案 → 审查 → 合并的整条生命周期被严格执行。言下之意：FDE 的「快」只发生在分支里，「定」必须过审，所以快不会把客户的主系统搞乱。→ 详细
07
AI FDE：「前置部署」从人延伸到 AI——AI 只能开分支、递提案，合并回主线必须人来批
- 是什么：「前置部署」这个理念正在从人延伸到 AI。Palantir 提供一款叫 AI FDE（AI 驱动的前置部署工程师）的交互式 agent，把业务人员的自然语言请求翻译成 Foundry 里的具体操作，接手建数据转换管道（pipeline，把原始数据清洗、转换成可用数据的流水线）、管理代码仓库、构建与维护本体这些活。→ 详细
- 流程图里的四个角色：业务专家对 AI FDE 说「用新数据建一个本体」→ AI FDE 头上的旁注是「严格遵守用户现有的权限」→ AI FDE 在本体上创建并构建一个工作分支 → 把分支提案交回业务专家审阅 → 业务专家再请审查者（Reviewer）评审 → 审查者人工批准后才合并到 main。整张图里，AI 能碰到的最远处就是「分支」，从不直接写主版本。→ 详细
- 怎么回应「AI 会不会失控」：作者承认，听到 AI 自动搭系统，有人会担心失控；但这项操作在设计上就有两道硬约束——「尊重用户现有的权限」（AI 替谁干活，就只拥有那个人的权限）和「始终提交分支提案以供审查」。这大幅降低了敏感数据被滥用或过度暴露的风险，让人和 AI 能安全协作。→ 详细
08
本体的心脏：名词（语义）+ 动词（动力）放在一起定义，把「看的模型」和「改的模型」合成一个
- 学术本体 vs 运营本体：Palantir 的本体虽建立在「作为知识表示的本体」这一通用概念上，却被设计成驱动组织运营的「运营层 / 数字孪生」；Foundry 官方后端文档把它定位为「组织的运营层」，把数据集这类数字资产和现实世界的资产、概念绑在一起，从而「作为数字孪生发挥作用」。→ 详细
- 凭什么「优于其他方案」：作者说最大原因是把系统定义为语义（Semantics：object、property、link）与动力（Kinetics：action、function、dynamic security）的整合。关键对比是这句：「通常，数据库设计止步于『名词（数据）』的设计，而『动词（业务逻辑与更新流程）』则被剥离到另一个应用层中。」Foundry 则把两类要素明确分开、又放在一起统一定义。——这正是本书与 207 老冯「本体 = 数据库建模换皮」论点正面相撞的分界线（本体与语义层之别见 ep99，agent 为何需要本体见 ep98）。→ 详细
- 名词的世界（语义，管「是什么」）：Object type（对象类型）表示现实世界里的一个概念（名词），以数据源为输入生成一个个对象实例；Property（属性）是对象的各项特性；Link type（链接类型）是对象类型之间的关系，支持一对一、一对多、多对多。→ 详细
- 动词的世界（动力，管「怎么变」）：Action（动作）是修改一个或多个对象属性的单个事务（事务：要么全改成、要么全不改的一次操作）；Action type（动作类型）里写好了可执行的变更集与副作用定义（改完这个会连带发生什么）；Functions（函数）是可快速执行的逻辑，支撑运营看板和决策类应用；Dynamic security（动态安全）被明确列为本体的动力要素之一，用来动态管控各项操作——权限被归在「动词」这一侧。→ 详细
- 结构图与一句话收束：图里两个框——名词框里 Object「拥有」Property、「连接」Link；动词框里 Action「修改属性」、Function「计算逻辑」，箭头都指向 Object。作者的收束：同时构建「用于查看的模型」与「用于变更的模型」，让数据模型把更新路径一并纳入、形成闭环，AI 与应用才能「毫不迟疑地」对现实世界执行安全操作。→ 详细
09
架构图解：五个后端服务分工——OMS 定 schema、Funnel 建索引、对象数据库居中、OSS 管读、Actions 管写
- 五大支柱（本体在物理上由「极其稳健的微服务」支撑，后端要同时处理语义〔定义〕与动力〔执行〕；按 Foundry 官方后端文档，以 Object Storage V2 为中心）：OMS（本体元数据服务）定义 object / link / action type，本体的 schema（结构定义）在这里定；Object databases（对象数据库）是心脏，存索引数据、跑查询、协调编辑；OSS（对象集服务）管「读」——搜索、筛选、聚合、加载；Actions 管「写」——把现实变化编辑进系统，支持复杂权限并生成动作历史日志；Funnel 读取数据源与用户编辑，索引进对象数据库。→ 详细
- 架构图：对象数据库居中高亮——Funnel 索引进来、OMS 以虚线提供 schema 参照、Actions 写入编辑，再由它把数据提供给 OSS 读出；读和写走两条不同的服务通道。→ 详细
- 索引化与物理约束：Funnel 把数据转成本体可用的索引写入 Object Storage V2，创建、修改对象实例并保持数据与元数据最新，分 batch（批处理，索引数据源数据或用户编辑）与 streaming（以 Foundry Streams 为输入，秒级到分钟级）两种；但流式 object type 目前不支持用户编辑，也不支持 MDO（多数据集对象），官方已明确列出，架构师必须心里有数。→ 详细
10
治理的出发点：数据一旦能驱动现实，错一次就不是「图表怪」而是「误订 1 万个零件」——安全从「藏起来」升级为「安全地动」
- 风险量级变了：数据成为运营层后，系统里的变更会立即驱动现实业务。分析型仪表盘数据出错，最坏不过「图表看起来有点怪」；可在靠本体自动下单、自动改状态的环境里，一次故障就直接酿成致命事故——「误订 10,000 个根本不需要的零件」或「让工厂产线停摆」。正因为拥有以压倒性速度改写现实的力量，Palantir 在平台底层嵌入了「远超一般 IT 工具」的强健治理与 fail-safe（故障安全：出错时默认滑向安全状态）机制。→ 详细
- 安全的定义被改写：传统企业 IT 里，安全主要是「隐藏数据」（访问限制 + 加密）；在本体驱动的架构里，安全被提升为「防止对现实世界造成错误变更与破坏」。核心问题收成一句：「谁能基于哪些数据、执行哪些业务逻辑（动作）？」对这些「动力要素」的严格管控，就是 Foundry 从军方和情报机构继承来的强韧治理的本质。→ 详细
11
分支与评审的生命周期：把软件工程的「版本控制 + 同行评审」搬进业务规则——连工程师也不能直改生产
- 搬的是什么：Palantir 把软件工程里久经检验的「版本控制」与「同行评审」最佳实践，直接带进数据建模和现实业务流程，核心是分支（Branching）与提案（Proposal）两套机制。Ontology Proposals（提案与审批）：凡是改动「现实世界的运营规则」——本体的 schema 定义，或动作的行为——「即便是工程师也无法直接改写生产环境」；改动必须在从主版本派生出的「工作分支」上安全地做、先测试，经评审与审批后才合并进主环境。→ 详细
- Foundry Branching（严格分支）：作者说这「相当于把开发中常用的 Pull Request 概念应用到了数据运营上」。分支与「单一本体」绑定、集中管理；从创建提案 → 评审 → 合并的整条生命周期在平台层面强制执行，所以影子 IT（业务部门绕开 IT 私自搭的系统或改动）和「特定人员未经授权的运营变更」能从结构上被杜绝——不是靠制度提醒，而是系统里根本没有绕过去的路。→ 详细
- 状态图：一个改动的一生：起点是「现实业务需求变了」→ 创建工作分支 → 在本体上改动（测试并编辑 schema）→ 提交提案（请求评审）→ 经 Approvals 应用进入「评审中」→ 两个出口：驳回 →「退回」→ 回到「在本体上改动」重做，构成循环；批准 → 合并到 main → 终点「立即反映到企业各系统」。整张图里没有「直接改 main」这条边。Palantir 官方视角的「怎么建、怎么管」见 210。→ 详细
12
Approvals 应用、行列级权限与 Action Log：谁批的、谁能看、谁改了什么，全部留痕
- Approvals 应用：大企业里「谁拥有审批权限」这件事本身就复杂。为了让部门负责人、合规官、数据所有者（data owner）这些多方达成共识，Foundry 提供专门的 Approvals 应用——集中管理审批工作流，把同行评审和合规检查无缝整合，让「变更在何时、由谁、出于何种理由获批」这个过程本身完全透明。→ 详细
- 比传统 DWH 细得多的「看」的控制：访问控制不止于 Restricted Views（RV，受限视图）做的「行级」控制，还官方支持用 MDO（多数据集对象类型）做「列级 / 属性级」控制。作者举的例子：「客户购买记录在全公司共享，但可识别个人身份的姓名与电话号码仅限特定部门查看」。另外，授权模型正从「依赖数据源的权限」转向「基于本体角色（ontology roles）」的模型——权限跟着业务概念走，而不是跟着底层数据表走。→ 详细
- Action Log：治理的最后一道防线：在 Foundry 里，每一次动作提交本身都被建模成一个 object type 并永久记录；日志对象与 Action type 一一对应，每次提交自动生成一条，写明由谁、何时、改写了哪些数据，并链接到被编辑的那个目标对象上，由此获得完整、近乎永久的可追溯性。换句话说，改动记录本身就是本体里的对象，和它改过的对象挂在一起。→ 详细
13
Airbus：500 万个零件的数字孪生让 A350 交付提速 33%，再长成 100 多家航司共用的 Skywise
- 问题：最先进的 A350 由约 500 万个零件构成，跨欧洲多个国家、工厂和无数供应商与团队制造；零件延误、质量问题的数据散落各处，「飞机完工之前的全貌」谁都看不清——作者称之为「数据孤岛的极限」。→ 详细
- 做法与结果：把分散数据整合进 Foundry 本体，把所有零件与排程之间的关系连起来，由此识别瓶颈、排定任务优先级，A350 交付提速 33%。→ 详细
- Skywise：Airbus 没止步于自家制造变革，和 Palantir 一起做了覆盖整个航空业的平台 Skywise，现已有 100 多家航空公司使用，在本体上处理 PB 级时序数据——每架飞机最多 20,000 个传感器、「每秒 20 到 100 个数据点」，用于零件故障预测与预防性维护，大幅降低航班取消风险。→ 详细
14
日本案例：SOMPO 把护理与理赔搬上本体，Fujitsu × Palantir 走「封闭网络里用 LLM」路线
- SOMPO 护理：作者称本体在日本正深入「优化社会基础设施」的使命。SOMPO Holdings 把 Palantir 作为「Real Data Platform（RDP，真实数据平台）」构想的核心；SOMPO Care 的护理机构把服务对象健康状况、员工排班、护理记录整合进 Foundry，不止于收集，而是帮一线员工判断下一步最佳行动（护理支援还是紧急应对）。→ 详细
- Sompo Japan 理赔：搭了基于本体的欺诈检测 + 理赔分诊（按优先级排序）系统；这一节收尾的数字是日本已有超过 8,000 人在日常工作中使用该平台，把一线「手工作业」换成本体上的「动作」。→ 详细
- Fujitsu × Palantir：Fujitsu 2023 年 12 月新闻稿称与 Palantir Japan 扩大全球合作，以突破日本特有的遗留系统环境——许多日本大企业出于云安全顾虑把数据锁在本地或私网里，正好用「AIP + Foundry」在客户封闭网络内安全使用 LLM；作者称金融、政府、制造等强安全行业的数据驱动业务正迅速落地。第 5 章自称依据「已公开的一手资料」，按参考文献，三个案例出处是 Palantir 官网案例页与 Fujitsu 新闻稿。→ 详细
15
企业 AI 为何停在「聊天机器人 + 会议纪要」：缺「共同语言」和「手脚」——本体用「已定义的动作」给 LLM 砌墙
- 病症与病因：全球企业都在抢着「在内部引入生成式 AI」，但大多止步于「内部聊天机器人」「会议纪要总结」这类表面效率。作者说原因很明确：AI 缺少驱动真实业务所需的「共同语言（本体）」和「手脚（动作）」。→ 详细
- LLM 的两个天花板：推理和自然语言能力再强，① 它没法直接操作现实系统——比如「A 公司快缺货了，从 B 仓库发 100 件过去」；② 它无法完全理解企业内部规章与复杂业务上下文，始终带着幻觉（看似合理的谎言）风险。这时本体成为 AI 的「坚实地基」：在 AIP 环境下，AI 读的不是「未经加工的杂乱数据」，而是按「名词（对象）」和「动词（动作）」严格定义、结构化过的本体。→ 详细
- 核心机制一句话：「由于 AI 只能在『已定义的动作』范围内进行推理和提议，上下文污染与幻觉被最大限度地排除，从而能够安全地在现实世界中执行动作。」这是作者的论断，书里没有给出幻觉率之类的量化数据；Palantir 内部怎么把「动作范围」落到 agent 工具上，见 208 的 Ontology MCP。→ 详细
- 两张对照图：传统 AI 用法——孤岛里的原始数据 →（直接访问 / 检索）→ 通用 LLM →（缺上下文）→ 幻觉 / 错误推断（标红）→（没法直接写入系统）→ 依赖人工，无法规模化；AIP + 本体——各类数据源 →（索引）→ 本体（名词与动词的定义）→（提供权限和结构化数据）→ AIP 上的 LLM →（只在已定义范围内推理）→ 动作提案 →（人工审核与批准）→ 业务被安全执行、立即反映到系统（标绿）。两图差在三处：喂给模型的是带权限的结构化本体而非原始数据；模型产出的是「提案」而非直接执行；中间多了一道人工审批。→ 详细
16
AI FDE 再登场：搭系统的成本被消掉，人从「连数据」升级为「审 AI 的提案是否符合业务意图」
- 从助手到工程师：Palantir 把 AI 从单纯的「用户辅助工具」提升为「亲自构建系统的工程师（AI FDE）」。过去搭数据集成底座，数据工程师要花大量时间连数据源、做映射（mapping，把一个系统的字段对到另一个系统的字段）、建管道；现在只需一句自然语言「用新的 CRM 数据构建客户本体」，AI 就把它翻译成 Foundry 操作指令，以 agent 身份自动创建数据管道并维护本体。→ 详细
- 「让 AI 搭系统危险吗？」作者答「不会」：理由是架构层面的三条——AI FDE 严格遵循用户既有权限；允许用户自己选择向模型开放哪些工具和数据（比第 1 章多出的一条）；做任何变更必定先创建「分支提案（Branch Proposal）」交给人审。→ 详细
- 人的角色被重新定义：人从「连接数据」这类繁琐活里解放出来，转向更高阶的角色——审核并批准 AI 建出的本体和 AI 提出的动作，确保它们「符合业务意图」。作者的落点：「正是因为有了本体这门共同语言，人类与 AI 才第一次能够安全、平等地协作，以可扩展的方式推动业务演进。」→ 详细
17
终章：用「名词 + 动词」重新定义自家业务——一份 5 个月的分步落地路线
- 转折点判断：我们正从「查看数据的时代」走向「数据直接驱动决策的时代」。无论 AI 多聪明，只要企业数据仍是「孤岛系统的残骸」，AI 的智能就到不了业务一线。所以构建本体不只是引入一套 IT 系统，而是用「名词」和「动词」重新定义自身业务，打造一门让人、AI、系统彼此对话的「全组织共同语言」。→ 详细
- 路线图总览（作者说以官方文档为依据）：起点「孤岛化的遗留 IT 资产」→ ① 理解结构与权限 → ② 最小化建模 → ③ 数据索引化 → ④ 设计审计与治理 → ⑤ 接入 AI 与应用 → 终点「驱动业务的鲜活引擎」。「看似宏大，但完全可以一步一步稳扎稳打地推进」。→ 详细
- 第 1–2 个月：第 1 月先搞懂 OMS / OSS / Funnel / Actions / 对象数据库各管什么，同时学 RV（受限视图）、本体角色这些 Palantir 特有的权限模型，夯实治理地基；第 2 月做最小化建模与分支操作——挑一个具体的小领域（作者举的例子是「单一产品线的库存管理」）动手设计 Objects / Links / Actions，关键是亲身走完一遍：给动作定义提交条件（submission criteria，满足什么条件才允许提交这个动作）与副作用，创建 Proposal，再审核、批准。→ 详细
- 第 3 月到第 5 月起：第 3 月验证数据管道——数据经 Funnel 索引进 OSv2（Object Storage V2）、可搜索可聚合，弄清批处理与流式的差异和各自物理限制后，验证数据的新鲜度与稳定性，确保扛得住实际运营；第 4 月设计审计与治理规则——为 Action 驱动的更新、动作日志生成、物化（持久化）定运营规则，启用 Action Log，核对「谁做的哪些编辑」如何反映进生产数据、如何被追踪，并与本公司合规要求对齐；第 5 月起接入 AI 与外部应用——让外部系统、AIP、自研应用都能安全读写本体，在 Developer Console 里生成 OSDK（Ontology SDK，让业务应用用代码直接调用本体的开发包），在恰当的 token（访问令牌）管控下从真实业务应用驱动本体。排序值得留意：提案审批在第 2 月就要亲手走通、审计治理在第 4 月，接 AI 排在最后。→ 详细
- 收尾金句：「数据只有与使用者的意图相连、转化为现实世界中的行动，才能为社会带来『影响力（Impact）』。」告别只能让人盯着分析结果看的遗留 IT 资产，以本体为新罗盘，把组织数据从「僵死的记录」变成「驱动业务的鲜活引擎」。→ 详细