最近我们在首期 OceanBase Hours 活动上推出了面向 AI 时代的湖库一体 AI 数据库包含 OceanBase DataPilot 在内的全新 AI 产品家族同步亮相。作为 OceanBase AI 数据库面向业务用户的入口OceanBase DataPilot 的核心命题是“让不写 SQL 的人也能拿到可信、可解释、可复用的分析结果”。要兑现这个承诺Agent 需要一套既稳定又能生长的能力面既允许业务用户带着新问题进来自由探索又能把稳定的解法沉淀成可复用、可治理的资产。这也是这篇文章要展开的主线——OceanBase DataPilot 如何在 Palantir AIP 的 Ontology 思想启发下走出一条不完全一样的实现路径。 本文作者吉剑南卜吉OceanBase 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 上不行最终我们走了一条不太一样的路。图 1OceanBase DataPilot 与 Palantir AIP 的路径差异Palantir AIP 的启发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。图 2Palantir 自上而下预建 vs OceanBase DataPilot 自下而上沉淀这种做法背后有一个更本质的判断探索式问数是 OceanBase DataPilot 无法回避的第一现场。用户带着“这批订单延期主要受什么因素影响”“帮我看一下 A 品类销量为什么下降”“把这个分析生成看板”这类问题进来很多对象和指标只有在自由对话里被反复使用和修正后才看得出值不值得沉淀。要求所有问题都必须走预定义 Action等于把这个现场关掉。ActionOceanBase DataPilot 中的过程资产OceanBase DataPilot 里的 Action 不能只理解成“会改数据的动作”。更准确的定义是Action 是存放在 Ontology 中、可被 Agent 调用的参数化业务过程。它可以只读可以是一段复杂的分析 SQL也可以是一个多步骤的分析流程 DAG最外层暴露的是一组入参、一段说明和一个输出契约。Action 和 Function 在 OceanBase DataPilot 里是两类不同的资产。Function 回答“怎么算”——延期率、周环比、库存风险分、客户健康度这些是口径资产通常以 MetricFlow 语义层的形式定义。Action 回答“怎么做”——查延期订单、做周环比分析、排查异常、写回系统、触发审批这些是过程资产。一个 Action 内部可以调用多个 Function比如生成品类周环比分析这个 Action可能组合了周环比 Function、渠道拆分 Function 和几个查询步骤。图 3Function口径资产与 Action过程资产的分工关系按治理强度我们把 Action 分为三类。查询 Action 是最轻的一层处理“查某客户延期订单”这类只读检索治理重点是参数校验、行列级权限和 SQL 沙箱。分析 Action 处理“定位销量下降原因”这类多步推理治理重点在中间步骤可追溯、结果解释可验证。执行 Action 处理“推送工单”“触发审批”这类会产生副作用的动作治理最重——需要强权限、人工确认、全量审计和失败补偿。执行 Action 是从“分析系统”走向“行动系统”的边界。这条边界我们打算守得比较紧——只读治理还没稳定之前不适合贸然开放写操作这是 OceanBase DataPilot 现阶段的基本判断。Palantir 的 Action 主要由架构师和开发者在 Ontology 构建阶段设计。O ceanBase DataPilot 保留这条传统路径同时还必须走另一条Action 从验证过的成功分析里抽象出来。典型流程是这样的用户提出真实业务问题Agent 用当前空间可用的数据、指标和 SQL 能力完成分析用户确认或修正结果Agent 判断这个分析是否满足“高频、稳定、参数清楚、结果可验证”四个条件满足则提议保存为 Action并抽取描述、参数、过程、输出格式和测试样例用户确认权限和治理策略之后发布到子域或空间。图 4Action 从真实对话中沉淀的完整流程这样做的意义是把一次性的答案变成可复用的能力。业务 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 DataPilot AIP 的最终形态把前面这些拼在一起OceanBase DataPilot AIP 的最终形态可以分成两层能力。平台内置层由产品团队维护NL2SQL、指标计算、图表、报表、Workflow、知识检索、语义建模。这一层是所有空间共享的通用能力不因业务域不同而变化。空间自定义层由用户和 Agent 在使用中共同沉淀对象、指标、术语、分析流程、Action、模板、子域 Agent 配置。这一层是业务 know-how 的真正载体每个空间都不一样也应该不一样。图 5DataPilot AIP 最终形态——平台内置能力 空间自定义能力的分层架构在“永远只走预定义 Action”和“永远自由发挥”之间OceanBase DataPilot 要建的是一个可生长的中间层新问题先自由探索稳定解法沉淀为 Action子域 Action 聚合到空间 Ontology新 Agent 复用空间图谱写操作和外部集成在治理成熟后逐步开放。下一步做什么Ontology 承载 AI 能力面这个方向我们相信是对的但要真正跑通还有几件事要做。短期要把 Action 沉淀流程的自动化程度再推高一格。目前“识别高频稳定解法”还有相当比例是靠人工判断触发的我们希望 Agent 能基于对话历史更主动地识别沉淀时机。同时空间图谱的可视化和搜索也要尽快做出来让用户能看得见空间里沉淀了什么、还缺什么。中期要打通 OceanBase DataPilot 与 OceanBase 一体化能力的更多接口尤其是把执行 Action 的写回通道和外部系统集成能力做扎实。这是从“分析系统”走向“行动系统”的关键一步也是执行 Action 层能否真正被信任的前提。有一件事想讨论一下不同用户、不同子域各自沉淀出来的 Ontology如何治理冲突和合并这是自下而上路径最难的地方也是我们接下来重点要解的问题。欢迎带着你自己业务场景的样例找我们聊——真实场景是这条路走得通的唯一验证方式。立即试用 OceanBase 企业版体验国产数据库能力立即试用 OceanBase 企业版体验国产数据库能力