上周，我翻我们数字员工的一条真实执行链路：一条消息进来，Agent 理解意图，调用 dws 能力执行，结果回到钉钉。全程没有「人看报表」这一环——数据的终点不是被谁看见，而是业务本身被改变。
这条链路短到不起眼。但它让我意识到，自己正在做一件大多数企业 AI 还没做成的事——同一时间，绝大多数企业的 AI 项目，正卡在「把结果给人看」这一步出不来。
最近读到「森林瀑布」的一篇长文《Palantir 还是太全面了》，把 Palantir 的官网和产品文档逐页扒了一遍。文章里有一句话，我认为点破了企业 AI 的分水岭：
「AI 到底连接到了什么。如果 AI 连接的只是一个搜索框，它还是聊天机器人。如果 AI 连接的是企业 Ontology、业务规则、Action 和真实业务系统，它才真正开始进入企业的操作层。」
一、两条链路：数据的终点是人，还是业务
把今天的企业软件画成两条链路，会发现一个残酷的分叉。
第一条，绝大多数企业正在走的：
数据 → 报表 → 人看结果 → 人做判断 → 人操作系统
系统负责「看清楚」。决策和行动，仍然在系统之外。
第二条，Palantir 在做的：
数据 → Ontology → 业务逻辑 → Action → 系统执行
区别不在于用了没用 AI，甚至不在于有没有知识图谱。文章里的判断很准：系统到底停在「帮助人决策」，还是开始具备「参与业务行动」的能力。
用一个例子看差别。传统的库存分析，AI 最多说到：「建议你把库存降下来。」然后呢？然后人去开会，人去查数据，人去另一个系统里改参数——链路在「人」这里断掉了。
Palantir 的 Action Type 试图把链路走完：发现库存异常 → 查询相关对象 → 判断是否满足业务条件 → 调用预定义 Action → 修改业务状态或触发后续流程。「该做什么」不再全部存在于人的脑子里，而开始被编码进系统的语义、规则和动作中。
「编码进语义层」具体长什么样？一个 Action Type 的最小结构是：
from dataclasses import dataclass
@dataclass
class ActionType:
"""把业务动作变成系统的一部分：编码『该做什么』进语义层。"""
name: str # 动作名，如「降低库存」
parameters: list[str] # 入参：目标对象、阈值
precondition: str # 业务条件：什么情况下触发
ontology_edit: str # 对 Ontology 的编辑：改哪个对象的状态
webhook: str | None = None # 触发外部系统行为
requires_approval: bool = True # 治理：高风险动作需人工确认
lower_inventory = ActionType(
name="LowerInventory",
parameters=["sku", "target_level"],
precondition="inventory.days_of_supply > 60",
ontology_edit="Inventory.status = 'replenishing'",
webhook="https://erp.internal/api/adjust-stock",
requires_approval=True,
)
# generated by hugo AI
注意 requires_approval 的位置：它在动作定义里，不在流程之外。审批是 Action 的一个字段，不是链路的一个断点。 这一点后面还会用到。
这就是从 分析型系统 走向 操作型系统。
| 分析型系统 | 操作型系统 | |
|---|---|---|
| 数据终点 | 人（看报表、做判断） | 业务本身（状态被改变） |
| 「该做什么」存在哪 | 人的脑子里 | 系统的语义、规则、动作里 |
| AI 的角色 | 智能问答 / 问数 / RAG | 调用 Action，参与业务运行 |
| 断点 | 人决定下一步（可能无限拖延） | 权限、审批、人工确认（治理内建） |
注意最后一行：操作型系统不是取消人的确认，而是把确认变成链路里被治理的一环。高风险动作依然要审批——但审批的是「执行」，不是「再研究研究」。
这张表可以直接当工具用。终点测试：沿任何一条数据链路走到头，看它最后落在哪。落在人看屏幕上，是分析型；落在业务状态被改变上，是操作型。
拿这个测试去量当下最热的几类企业 AI：BI 看板，终点是人；智能问答，终点是人；RAG 知识库，终点还是人。它们都很聪明，但全部停在同一个地方。这也解释了为什么很多 AI 项目上线三个月就被客户嫌「没价值」——不是不够聪明，是每条链路的终点都长在人身上。
二、用损失函数解释：只算梯度不更新参数，模型永远学不会
这个分叉，可以用上周 组织的损失函数 里的框架重新解释一遍。
那篇的结论是：组织要像训练模型一样，写出可微的损失函数，跑出完整的训练闭环——样本进来，损失函数算出差距和方向，得到梯度，反向传播更新参数。
现在把两条链路套进去：
分析型系统：
样本（经营数据） → 损失函数（AI 算出差距和方向）
│
▼
梯度停在人这里
✗ 参数从不更新
操作型系统：
样本（经营数据） → 损失函数 → 梯度
│
▼
反向传播：Action 更新业务状态
│
└──→ 新的样本回流
# generated by hugo AI
分析型系统的病根一目了然：梯度算出来了，但回传通道是「人」。 人会执行建议吗？会。但人的执行慢、有损耗、不可归因——等一个「建议」走完开会、排期、落地的全程，梯度早已在层层传递中衰减。损失降不下来，往往不是算得不准，而是更新参数的通道太慢太脆。
而 Agent Spec 是数字员工的劳动合同 里说的身份和边界，在这里有了第二个身份：它们不只是治理要求，它们是让梯度可以安全回传的前提——没有权限强制和问责链条，反向传播就会把误差更新到不该碰的参数上。
三、一个被低估的事实：执行层的原料，是结构化数据
顺着「执行」往下推，会撞上一个反直觉的结论——也是那篇文章里我认为最值钱的一句：
非结构化数据建模容易被高估，结构化数据的本体建模反而容易被低估。
今天谈大模型，大家第一反应是 PDF、邮件、会议记录、语音、图片——似乎 AI 最大的价值，是把非结构化数据「变成知识」。这当然重要。但 Palantir 的 HyperAuto 指出了另一条路：把企业已经存在的结构化业务系统（SAP、Salesforce、Oracle NetSuite），自动映射成 Ontology。
为什么这条路被低估？因为结构化数据有一个巨大优势：它是确定的。ERP 里的订单、库存、供应商，CRM 里的客户、商机、合同，MES 里的设备、工单、产线——本来就有明确的字段、主键、关系和业务约束。与其花巨大力气让大模型「理解一个表格」，不如直接把这些确定的结构映射成企业 Ontology。HyperAuto 就是干这个的：利用源系统的元数据，自动推断数据同步与转换逻辑，生成对应的 Ontology（V2 目前主要支持 SAP，V1 曾覆盖 Salesforce、Oracle NetSuite——据该文描述）。
更关键的是回报的落点：这条路撬动的不是「知识问答」，而是 库存、资金、订单、产能、供应链、排产、客户、合同——这些才是和企业经营结果直接相连的东西。
两条路的差别，一句话：非结构化数据要多走几步（抽取 → 结构化事实 → Ontology → 业务动作），而结构化业务数据可以直接进（业务系统 → Ontology → 业务动作）。只盯着非结构化，就会低估 Ontology 对整个结构化业务世界的价值。
四、务实的路径：不必复制全面的 Palantir，切下执行闭环那块
文章最后给出了一个务实的判断，我完全同意：对绝大多数企业来说，没有必要复制一个完整的 Palantir。更现实的路径，是切下它最有价值的一块——
结构化业务数据 → Ontology → 业务规则 → Action → Agent → 执行闭环
把这一块做深、做透、做轻。
而这一块，恰好是组织平台手里现成的牌。Databricks 逼近 Palantir，但最后一层藏在组织里 里我推演过：Ontology 最贵的那部分——行动权限和组织身份——只有在组织里才是现成的、活的、自维护的。Palantir 用 FDE 驻场把「该做什么」编码进客户的语义层；组织平台的机会，是让每个数字员工的日常执行，自动长出这一层。
Palantir 从本体长到 Agent，我们从 Agent 长回本体 里说过两条路线会在同一个地方汇合。现在可以看得更清楚了：汇合点就是这条执行闭环。谁先把「结构化数据 → 语义 → 动作 → 回写」跑成日常，谁的企业就先开始学习。
结论
企业 AI 的分水岭，从来不是模型的智商。
是数据的终点——停在看报表的人，还是抵达业务本身。
是梯度的归宿——停在复盘会上的共识，还是反向传播成一次真实的业务动作。
Palantir 用「全面」证明了这条路的价值；而执行闭环这一块，恰恰不必靠「全面」才能拥有。
你的企业里，AI 给出的最后一个「建议」，后来被执行了吗？欢迎留言聊聊。