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 參與工作。