DataFocus · 企业 AI 底座

让 Agent 理解你的业务，按你的权限使用企业知识。

连接业务数据库与企业文档，以业务本体统一组织知识，通过 MCP 等开放接口提供受控上下文，让企业知识的使用有依据、有边界、可追溯。

体验一个业务任务了解企业接入

两个版本：OT Flash 与 OT Heavy

S1订单履约风险提问人华东销售负责人快照 2026-09-25 10:00

问

9 月 28—30 日到期的华东订单，哪些可能延期？给我依据。不要改单，也不要发消息。

答

O-1001预计晚 2 天
按本企业的，这是预测风险，不是已经发生的违约。
O-1002当前资料未显示延期
这不保证之后一定准时。
O-1004资料不足
生产系统里还没有预计完成时间。暂时不能判断，也不应算作没有风险。

建议请生产计划补充 O-1004 的完工预计。O-1001 的跟进说明已起草，未发送。

S1 · 企业任务

同一项工作，需要数据，也需要业务知识。

订单在 ERP，生产进度在 MES，交付怎么算写在合同里。三处资料放在一起，才能判断风险；再按提问人的身份过滤，结果才能交给这位销售负责人。

订单约定交付预计完成判断依据

O-100109-2809-30预测延期 2 天按合同 A v2 的交付口径，预计晚 2 天。这是预测，不是违约，也不自动计算罚款。ERPMES合同 A v2

O-100209-2909-29未见延期依据当前快照没有延期迹象，不保证之后准时。ERPMES合同 A v2

O-100409-30无记录资料不足缺少完工预计。应补充核实，不能标为正常。ERPMES合同 C v1

示范企业的合成数据，快照 2026-09-25 10:00（UTC+8）

如果直接问 O-1003 呢？

问O-1003 能按时交付吗？

在体验页逐项核对依据

为什么接上数据库还不够

有了 Agent，企业仍要掌握自己的上下文。

当企业同时使用几种 Agent，谁来管理它们拿到的业务知识？每个入口各配一份，定义和权限很快就会对不上。通用 Agent 很能干，但下面这几个问题，它自己答不了。

对象
CRM、ERP 和合同里的“客户 A”，是同一家公司吗？
口径
“交付”算工厂完工、发货，还是客户签收？
有效知识
合同改过一版，现在该按哪一版？
可见范围
华东的销售负责人，能看到西区的订单吗？

能连接，不代表理解；能查询，不代表有权访问。

企业自己的上下文，不只看服务器放在哪里，还要看企业能不能：

定义业务对象和口径由负责人确认
批准变更生效前经过批准
维护规则变了，知识跟着更新
授权谁能看、谁能改，由企业决定
核验每个回答都查得到来源和版本
迁移定义、映射和政策应能导出

理解 · 业务本体

每个业务词，都按企业自己的定义。

DataFocus 用业务本体组织对象、关系和定义：客户拥有订单，订单关联生产任务和有效合同。每个字段有来源，每条定义有负责人。Agent 不用猜表名，查定义就行。

点一个词条查看定义

客户拥有订单；订单由…完成生产任务；订单受…约束有效合同

交付

ContractDoc · delivery业务口径

本示范企业所称“交付”，是指工厂完成生产并可交接；不含运输时长与客户验收。

所以“预计晚 2 天”是按这个口径作出的预测，不是已经发生的违约，也不自动计算罚款。

负责人: 销售运营（示范角色）
依据: 合同 A v2
状态: 已确认（示范）
用于: S1 风险判断

真实企业的交付口径，必须由自己的业务负责人确认。

从连接到追溯

连接让业务数据和业务知识参与同一个任务。
理解按企业的业务定义组织信息，不让 Agent 猜表。
授权共同的知识，不代表相同的可见范围。
调用提供有业务含义的能力，不裸露全库通道。
追溯知道知识怎样被使用，也知道它怎样变化。

授权 · 追溯 · S3

知识有版本，权限有边界，变更有记录。

售后规则从 24 小时响应改为 4 小时，新规则从 9 月 25 日零点起生效。负责人批准之前，Agent 仍按旧规则回答；批准之后，同一张工单的截止时间提前了 20 小时。

T-2001 · premium模拟数据

09-25 00:00POLICY-v2 业务生效（有效期起点）
09-25 09:00工单 T-2001 创建
09-25 10:00模拟快照；在此时批准规则
09-25 13:00v2 截止时间（4 小时）
09-26 09:00v1 截止时间（24 小时）

草稿写着 4 小时，但还没批准。Agent 给出的截止时间仍是 9 月 26 日 09:00，并注明依据 v1。

权限有边界同一套知识，不同身份看到不同范围。越权请求被拒绝，也不透露目标是否存在。
变更要批准草稿不改变 Agent 的答案。批准绑定具体版本和范围；版本一变，就要重新确认。
记录可追溯每次调用留下来源、口径和返回范围；每次变更留下前后版本、差异和批准人。

亲手批准一次规则更新查看信任与治理

调用 · 多个入口

入口可以换，企业知识不必重建。

员工用哪个 Agent，可以随团队习惯变化。业务定义和访问规则留在企业这一层，每个入口都按同一套口径和权限调用。措辞可以不同，事实和范围应该一致。

入口 A

O-1001 预计比约定晚 2 天，按工厂完工可交接的口径判断。O-1004 缺少完工预计，暂时无法判断。

入口 B

有一笔订单可能延误：O-1001，约 2 天，口径是工厂完成并可交接。另外 O-1004 没有生产预计时间，需要补充资料。

模拟数据示例：两个入口措辞不同，引用的定义、来源和范围相同。对话记录仍由各自入口管理。

选择你的工作入口

按客户端版本、运行方式和企业权限准备接入。以下名称用于帮助你选择和评估，不表示官方合作。

了解具体连接条件

建设 · S2

从一个业务任务开始，由人和 Agent 共同建设。

Codex 等 Coding Agent 可以检查来源、提出对象和关系、生成差异和测试。遇到说不准的口径，它应该停下来问；发布之前，由有权限的人批准。

通过模拟数据了解构建流程；连接自己的实例时，使用该版本开放的工具和已有授权。

查看构建方式体验构建流程

Coding Agent
检查来源
CRM 客户 · ERP 订单 · MES 生产任务 · 合同文档
Coding Agent
提出草稿
4 类对象 · 3 类关系 · 1 项口径待确认
Coding Agent
停下来问
“交付完成”指生产完成、实际发货，还是客户验收？这会改变风险判断，我不替你决定。

Coding Agent

差异与测试

源数据写入 0 · 权限不扩大

+ Customer → Order
+ Order → ProductionTask
+ Order → ContractDoc

负责人
等待批准
发布需要有权限的人确认。Agent 不能批准自己的变更。
业务 Agent
交给业务 Agent
发布后，另一个 Agent 用同一套定义执行 S1。

S4第一个项目做完，定义、映射和测试可以带到下一位客户；客户资料和授权不带走。看方案怎样复用

采用 · 两个版本

在你的环境中使用，从一个业务域开始。

DataFocus OT 提供两个版本，都带本体管理。OT Flash 用 Apache Doris 同时做内存计算和数据仓库，部署轻、查询快；OT Heavy 沿用 Hadoop、Hive、Trino 与 Iceberg，另外提供 ETL 与 AutoML。无论哪个版本，都先挑一个有数据、有文档、有业务负责人、结果能验收的任务。

OT = Ontology本体管理两个版本都有

DataFocus OT Flash

一个引擎，快速起步。

Apache Doris内存计算 · 数据仓库

Apache Doris 作为内存计算引擎，同时充当数据仓库。

本体管理

查询分析 以 Apache Doris 统一承载分析查询与数据仓库。

适合想先在一个业务域快速跑通，数据可以集中到一个分析引擎里的团队。

免费发行查看发行与下载

DataFocus OT Heavy

完整的大数据底座。

Trino分布式 SQL 查询

Apache Hive数据仓库

Apache Iceberg开放表格式

Apache Hadoop分布式存储与计算

沿用 Hadoop、Hive、Trino 与 Iceberg 架构，同时具备 ETL 与 AutoML。

本体管理
ETL
AutoML

ETL 数据抽取、转换与加载。
AutoML 自动化机器学习建模。

适合数据量大、已经在用大数据平台，还需要数据加工和建模的企业。

免费发行查看发行与下载

OT 指 Ontology（本体）。根据数据规模、现有技术栈和建设需求选择版本。

比较两个版本不想自己安装？使用云服务建设者与交付

内核: 闭源
采用方式: OT Flash 与 OT Heavy 均免费发行、本地部署
发行、商用与支持条款: 使用范围以对应版本的许可与服务条款为准
安装包: GitHub 免费获取安装镜像，版本与校验信息随发行公布
运行成本: 服务器、模型调用和第三方服务由使用方承担
实施方式: 免费自建、请建设者交付，或购买云服务

企业掌握知识与规则，让不同 Agent 参与工作。