OceanBase DataPilot AIP：Ontology 承载 AI 能力面的另一条路

我们为什么开始想Ontology这件事

OceanBase DataPilot 上线以来，用户问 Agent 的问题变得越来越复杂。

一开始大家问的是“上个月各渠道 GMV 多少”，一次 NL2SQL 就够了。慢慢地，问题变成了“帮我看一下 A 品类销量为什么下降”“把这批订单延期的原因归类，输出一份周报”“这个分析下周同一时间自动跑一遍并推给我”。

这类问题的共同点是：它不再是一次查询，而是一个完整的业务过程——里面有对数据的理解、对指标口径的对齐、对分析步骤的编排，最后还可能涉及写回和外部集成。

在做这些能力的过程中，我们看到两种失败模式反复出现。

• 第一种是 Agent 每次都从零开始，同一个问题问三次得到三种回答，业务无法信任结果。
• 第二种是想把每个问题都做成一个预定义的模板，结果模板永远做不完，用户还没来得及问，产品团队已经被维护成本拖垮。

带着这个困扰，我们研究了 Palantir AIP。Palantir 是一家把 AI 和企业运营流程结合得最彻底的公司之一，长期服务政府、金融、能源等对权限、审计和稳定性要求极苛刻的客户。

它的产品体系由三部分组成：Foundry 负责数据运营，Apollo 负责软件自动化部署，AIP 则是接在这套体系之上的 AI 能力层——按 Palantir 官方的定位，AIP 要把 LLM 能力嵌入企业已有的 security、audit 和 resource management 框架里，让 AI 真正进入业务运营流程。

我们研究它，不是为了照搬产品形态，而是因为它是“企业级 AI 能力面”这个问题目前最成熟的参考答案。

AIP 的核心不是聊天窗口，而是一个“进业务流程的 AI 操作层”——它给 Agent 提供了一个基于 Ontology 的能力面，让 AI 面对的是「客户」「订单」「审批」这样的业务对象，而不是散乱的表和 SQL。这套思想我们要借。但直接照搬到 DataPilot 上不行，最终我们走了一条不太一样的路。

Palantir API 的启发

Palantir AIP 建在 Foundry 之上。Foundry 负责数据接入、建模、权限、应用和工作流；AIP 把大模型接进这一整套能力，让 AI 进入企业已有的软件系统。用户问的不只是“这个数是多少”，还包括“现在该怎么办”“帮我生成处置方案”“把这个动作提交审批”“通知相关负责人”。Agent 要读业务对象、调计算口径、触发动作，每一步都落在权限、确认和审计里。

Ontology 是这一切的业务底座。它把客户、订单、设备、门店、指标口径、业务动作组织成一套可操作的对象世界。

模型负责理解和生成，Ontology 提供业务语义，治理体系控制 Agent 能看什么、能调什么、做完之后怎么留痕。位置很清楚：Foundry 提供数据和对象，AIP 提供 AI 使用这些对象的方式。

产品形态是一条完整链路：

• AIP Assist 帮平台建设者写代码、建管道、理解数据；
• Agent Studio 用来定义 Agent 面向谁、能看哪些对象、能调哪些 Function 和 Action、哪些操作必须人工确认；
• AIP Threads 是业务用户对话入口；
• AIP Logic 编排复杂流程。
• 审计贯穿全程。

这套设计里最值得学习的是“能力面”的抽象方式。表面上它和普通的 Function Calling 都是“LLM + 工具调用”，但差别在治理内建的位置。普通 Function Calling 里，每个 Agent 私有一组函数，审计是事后补的；AIP 里，Agent 面对的是 Ontology 中共享的对象、Function 和 Action，权限、校验、审计都内建在 Action 体系里。

这意味着，企业级的 AI 能力有了一套可复用的语义资产，而不是每个 Agent 各拼各的。

为什么OceanBase DataPilot不能照搬

差异不在于“要不要 Ontology”。我们和 Palantir 一致，都认为 Agent 应该面对 Ontology 里的 Object、Function、Action，而不是裸表和散乱的 SQL。真正的差异在于产品构建顺序。

Palantir 是自上而下的路径。企业先建设 Foundry Ontology，把对象、关系、Function、Action 全部建模；Agent Studio 再从这个全局 Ontology 里裁剪出某个 Agent 的能力面；用户最后在 Threads 里调用受控能力。

这条路径的前提是 Ontology 已经比较成熟——Agent Studio 做的其实是“从全集里切一块”。

OceanBase DataPilot 面对的场景不允许这样。我们服务的第一批业务用户，很少一上来就有一份完整的业务对象建模，更常见的状态是：几张核心表、一份不完整的指标口径文档、若干散落在个人聊天记录里的分析经验。如果要求他们把 Ontology 全部建完再启用 Agent，产品根本落不了地。

所以 OceanBase DataPilot 走的是自下而上的路径。用户在空间里创建子域 Agent——这里的“空间”指承载一个业务域全部数据、语义资产和 Agent 的容器；“子域 Agent”是空间内按业务场景切分的专属分析智能体，比如订单履约 Agent、库存分析 Agent、门店补货 Agent、经营日报 Agent。子域 Agent 上手不需要完整 Ontology，只要它工作范围内的表、初始知识和一段简单的业务约束就能开跑。

真正的 Ontology 是在使用中长出来的。用户提问、Agent 回答、用户确认或修正，反复几轮之后，一部分对象、关系、指标、术语被反复用到，它们才有资格进入 Ontology；一部分成功的分析被反复调用，才有资格沉淀为 Action。

这不是产品团队一次画完的静态模型，而是空间和 Agent 共同参与的动态资产。Agent 不只消费 Ontology，也参与生产 Ontology。

这种做法背后有一个更本质的判断：探索式问数是 OceanBase DataPilot 无法回避的第一现场。

用户带着“这批订单延期主要受什么因素影响”“帮我看一下 A 品类销量为什么下降”“把这个分析生成看板”这类问题进来，很多对象和指标只有在自由对话里被反复使用和修正后，才看得出值不值得沉淀。要求所有问题都必须走预定义 Action，等于把这个现场关掉。

Action：OceanBase DataPilot中的过程资产

OceanBase DataPilot 里的 Action 不能只理解成“会改数据的动作”。更准确的定义是：Action 是存放在 Ontology 中、可被 Agent 调用的参数化业务过程。它可以只读；可以是一段复杂的分析 SQL，也可以是一个多步骤的分析流程 DAG，最外层暴露的是一组入参、一段说明和一个输出契约。

Action 和 Function 在 OceanBase DataPilot 里是两类不同的资产。

Function 回答“怎么算”——延期率、周环比、库存风险分、客户健康度，这些是口径资产，通常以 MetricFlow 语义层的形式定义。

Action 回答“怎么做”——查延期订单、做周环比分析、排查异常、写回系统、触发审批，这些是过程资产。一个 Action 内部可以调用多个 Function：比如"生成品类周环比分析"这个 Action，可能组合了周环比 Function、渠道拆分 Function 和几个查询步骤。

按治理强度，我们把 Action 分为三类。

• 查询 Action 是最轻的一层，处理“查某客户延期订单”这类只读检索，治理重点是参数校验、行列级权限和 SQL 沙箱。
• 分析 Action 处理“定位销量下降原因”这类多步推理，治理重点在中间步骤可追溯、结果解释可验证。
• 执行 Action 处理“推送工单”“触发审批”这类会产生副作用的动作，治理最重——需要强权限、人工确认、全量审计和失败补偿。

执行 Action 是从“分析系统”走向“行动系统”的边界。这条边界我们打算守得比较紧——只读治理还没稳定之前，不适合贸然开放写操作，这是 OceanBase DataPilot 现阶段的基本判断。

Palantir 的 Action 主要由架构师和开发者在 Ontology 构建阶段设计。O ceanBase DataPilot 保留这条传统路径，同时还必须走另一条：Action 从验证过的成功分析里抽象出来。

典型流程是这样的：用户提出真实业务问题，Agent 用当前空间可用的数据、指标和 SQL 能力完成分析，用户确认或修正结果，Agent 判断这个分析是否满足“高频、稳定、参数清楚、结果可验证”四个条件；满足则提议保存为 Action，并抽取描述、参数、过程、输出格式和测试样例；用户确认权限和治理策略之后，发布到子域或空间。

① 用户提真实问题（「A 客户这季度有哪些延期订单？」）

  → ② Agent 自由分析（查数据 · 算指标 · 出结论）

  → ③ 用户确认或修正（验证结果正确）

  → ④ Agent 判断可沉淀（高频 · 稳定 · 参数清晰）

  → ⑤ 保存为 Action（描述 · 参数 · 权限 · 发布）

一次性答案 → 组织级能力

这样做的意义是把一次性的答案变成可复用的能力。业务 know-how 不再锁在个人聊天记录或临时 SQL 里，而是变成被治理起来的空间资产。

子域Agent和空间图谱如何互相生长

我们不打算做一个独立的 Agent Studio 产品，但要吸收它的核心理念：围绕业务子域配置能力面。

一个供应链空间里，通常会有订单履约 Agent、库存分析 Agent、门店补货 Agent、经营日报 Agent 等若干子域 Agent 并存。每个子域 Agent 都有自己清晰的边界——数据范围（哪些表、视图、数据源）、Ontology 范围（哪些 Object、Link、Function）、Action 范围（可调哪些查询、分析、执行 Action）、知识范围（文档、SOP、指标解释），以及行为约束（默认只读还是可执行、何时必须人工确认）。子域 Agent 配置的是业务能力面，prompt 只是其中一项。

子域和空间图谱的关系是双向的。子域 Agent 在真实问题中沉淀出对象、指标和 Action；这些资产稳定之后，进入空间级语义图谱；空间图谱又成为下一批新 Agent 的共享语义层，让新的子域 Agent 一开始就可以复用已有资产，并在使用中继续扩展。Ontology 因此是随使用不断增长的空间资产，不是一次性画完的静态模型。

运行时策略：优先复用，允许回退

保留自由生成能力之后，一个绕不开的问题是：Agent 在每一次对话里，到底什么时候用 Action、什么时候不用？

我们的策略是“优先复用，允许回退”。

Agent 收到用户输入后，先识别意图、涉及的对象、指标和参数；然后在当前子域和空间中检索可用的 Action。如果匹配置信度足够高，就优先调用 Action；如果参数缺失，向用户追问；如果没有匹配 Action、覆盖不全，或者风险等级偏高，就回退到自由分析。当自由分析产出一个稳定可用的解法之后，Agent 会主动询问用户是否愿意把它沉淀为新的 Action，进入前面说的沉淀流程。

匹配 Action 不能只看名称相似度。我们还要评估权限、对象范围、参数是否可以从上下文里稳定抽取、Action 是否已经通过测试样例、是否涉及写操作。任何一环存疑，都倾向于回退自由分析，而不是勉强套用一个不完全匹配的 Action。

分层治理：不能只靠Action一道闸口

自由生成保留下来之后，治理不能只靠 Action 一道闸口——因为大量分析发生在自由生成层。我们的做法是分层设防。

自由生成层默认只读，Agent 生成的 SQL 走沙箱执行，遵守表、字段、行级权限，同时对返回行数、执行时间、资源消耗都设硬约束，全过程留下查询记录和用户确认痕迹。

只读 Action 层入参强校验，绑定明确的对象和指标范围；Action 保存时校验 SQL 或执行体，支持测试样例和回归测试。

执行 Action 层的治理最严格：更严格的发布和调用权限、明确的副作用声明、执行前必须人工确认、幂等设计、全量审计，必要时支持回滚。

这三层不是替代关系而是叠加关系——同一个空间里，自由生成、只读 Action、执行 Action 会并存，Agent 根据问题类型和风险等级选择合适的路径。

OceanBase DataPiolt API的最终形态

把前面这些拼在一起，OceanBase DataPilot AIP 的最终形态可以分成两层能力。

平台内置层由产品团队维护：NL2SQL、指标计算、图表、报表、Workflow、知识检索、语义建模。这一层是所有空间共享的通用能力，不因业务域不同而变化。

空间自定义层由用户和 Agent 在使用中共同沉淀：对象、指标、术语、分析流程、Action、模板、子域 Agent 配置。这一层是业务 know-how 的真正载体，每个空间都不一样，也应该不一样。

在“永远只走预定义 Action”和“永远自由发挥”之间，OceanBase DataPilot 要建的是一个可生长的中间层：新问题先自由探索，稳定解法沉淀为 Action，子域 Action 聚合到空间 Ontology，新 Agent 复用空间图谱，写操作和外部集成在治理成熟后逐步开放。

我们下一步做什么

Ontology 承载 AI 能力面这个方向，我们相信是对的，但要真正跑通还有几件事要做。

短期要把 Action 沉淀流程的自动化程度再推高一格。目前“识别高频稳定解法”还有相当比例是靠人工判断触发的，我们希望 Agent 能基于对话历史更主动地识别沉淀时机。同时，空间图谱的可视化和搜索也要尽快做出来，让用户能看得见空间里沉淀了什么、还缺什么。

中期要打通 OceanBase DataPilot 与 OceanBase 一体化能力的更多接口，尤其是把执行 Action 的写回通道和外部系统集成能力做扎实。这是从“分析系统”走向“行动系统”的关键一步，也是执行 Action 层能否真正被信任的前提。
有一件事想讨论一下：不同用户、不同子域各自沉淀出来的 Ontology，如何治理冲突和合并？

这是自下而上路径最难的地方，也是我们接下来重点要解的问题。欢迎带着你自己业务场景的样例找我们聊——真实场景是这条路走得通的唯一验证方式。