一、摘要

中国企业正加速拥抱人工智能，但绝大多数的 AI 项目止步于”一个聊天窗口 + 一个搜索框”——问答质量不稳定、跨系统数据无法打通、AI 能说不能做。症结不在于模型能力不足，而在于企业数据缺少一个统一的语义层。

DSClaw 企业级 AI 协作平台，以”知识中台 + 多智能体”架构，为企业构建从数据接入、语义建模到 AI 协作的完整闭环。底层 DSKMP 知识中台将散落在各系统中的异构数据转化为有关系的业务对象；上层 DSClaw 多智能体编排引擎模拟跨领域专家协同，完成复杂分析、故障诊断与任务执行。

这不是一个 AI 问答工具，这是一个理解你业务的数字操作系统。

二、行业挑战：企业 AI 落地的三层断裂

过去三年，大语言模型的能力以指数级跃迁。但在企业现场，AI 项目的成功率仍然极低。我们观察到，失败几乎全部集中在三道结构性断裂上。

数据层的断裂

一条产线上，设备运行参数在 DCS 中，维修记录在 ERP 的工单模块中，操作规程在共享盘的 PDF 里，备件库存又在另一个独立的系统中。同一个”离心泵”，在四个系统里有四个名字：P-301、2号泵组、裂解进料泵、离心泵A区3号。

这些系统不互通、不互认、不互译。数据在，但对 AI 而言，它们是四个完全不相关的世界。

语义层的断裂

即使把数据接入了，AI 看到的仍然是”表”而不是”业务”。一张名为 t_work_order_2023 的表，字段是 eqp_code VARCHAR(32)、fault_type TINYINT、start_time DATETIME。AI 不知道这是工单表、不知道 fault_type=3 代表”轴承异常”、不知道 eqp_code 和那边的”P-301″是同一个东西。

数据有了，语义没有。AI 的回答只能基于关键词匹配，无法基于业务逻辑。

协作层的断裂

即使打通了数据、建好了语义，大多数 AI 方案仍然停在”给出一个回答”。但企业真正需要的是：发现问题 → 分析根因 → 关联 SOP → 生成工单 → 通知责任人 → 跟踪闭环。这需要多个 AI Agent 分别干活再互相校验，而不是一个模型从一而终。

三层断裂的核心根因，指向同一个缺失：企业数据没有”本体”（Ontology）。

三、设计理念：让企业数据拥有”本体”

什么是企业数据的”本体”

“本体”（Ontology）一词来自哲学，研究”存在是什么”。把它引入企业信息系统，回答一个最基础的问题：你公司里到底有哪些东西？它们之间是什么关系？

Palantir 将 Ontology 做成了其产品体系的核心——不是数据库表的集合，而是企业业务的数字孪生。它将分散在几十个系统中的原始数据，映射为具有明确业务含义的对象（如”设备””工单””物料””人员”），定义每个对象的属性（如设备的型号、位置、运行状态），并明确对象之间的关系（如 设备 → 产生 → 工单，工单 → 需要 → 备件，备件 → 存放于 → 仓库）。

有了这一层，AI 就不再是对着几千张表的字段做匹配，而是在一个有语义的业务世界中进行推理。

走同样的方向，走不同的路

Ontology 的理念正确，但 Palantir 的落地路径——由 FDE（Forward Deployed Engineer）逐一手工定义 Object Type 和 Link——更适合高度结构化、预算充裕的军方和金融机构。

中国企业面对的是完全不同的现实：大量知识以非结构化文档形式存在（操作规程、维修手册、应急预案），IT 系统建设碎片化严重，专门的 AI 建模人员极度稀缺。

DSKMP 知识中台因此选择了一条更适配中国企业的路线：

以 NLP 自动抽取替代手工建模，以产品化部署替代驻场服务。

路径不同，目标一致：让企业数据从”表”变成”对象”，让 AI 从”猜”变成”懂”。

DSClaw 的定位：为 AI 协作提供统一语义

有了 DSKMP 提供的统一知识模型，DSClaw 的多个 AI Agent 就不再是各说各话。每个 Agent——无论它负责查 DCS 数据、检索维修规程、还是关联历史工单——都在同一个语义模型上工作。它们共享同样的实体定义、同样的属性体系、同样的关系网络。

这使得多智能体协作从”互相传文本”升级为”在同一张业务地图上分头搜索、交叉验证”。

四、产品架构

第一层 · 数据接入

连接是企业 AI 的第一步，也是最容易在 Demo 和现实之间断裂的一步。DSClaw 提供统一的数据接入网关，支持：

• 结构化数据源：MySQL、PostgreSQL、Oracle、SQL Server、国产数据库（达梦、人大金仓、OceanBase）

• 非结构化数据：PDF、Word、Excel、图片（含 OCR）、扫描件

• 实时数据源：MQTT、OPC UA、Kafka（对接 DCS / SCADA 等工业时序数据）

• 业务系统：REST API 接入 ERP / OA / MES 等存量系统

关键安全设计：所有数据接入均采用单向只读采集，杜绝反向控制风险。

适配 OT / IT 物理隔离场景，支持安全数据网关 + 工业防火墙白名单的部署模式。

第二层 · DSKMP 知识中台

这是整个平台的数据语义层，也是区别于市面上所有”AI 知识库”产品的核心。

• 实体抽取：从非结构化文档和数据库字段中，自动识别业务实体——设备、物料、工位、人员、工序、故障类型。内置行业预训练模型，支持制造、化工、能源等垂直领域的实体识别。

• 关系构建：识别实体之间的关联——设备属于产线、工艺包含工序、故障对应 SOP、备件关联供应商。支持从文档文本中自动抽取关系，也支持人工定义业务关系规则。

• 属性提取：为每个实体自动提取关键属性——设备的型号、功率、安装日期、上次检修时间；物料的规格、供应商、安全库存阈值。

• 知识融合：解决”同一实体在不同系统中叫不同名字”的问题。通过实体对齐与消歧算法统一为一个知识对象。

• 图谱查询：以图数据库为底层存储，支持 Cypher / SPARQL 等标准查询语言，支持自然语言转图查询。

第三层 · DSClaw 智能协作层

在统一语义模型之上，DSClaw 提供完整的 AI 协作能力：

• 多智能体编排：设计理念来自”专家会诊”模式。用户提出一个问题，编排引擎将其拆解为多个子任务，分发给不同领域的 Agent 分别处理——数据 Agent 查 DCS，文档 Agent 查规程，图谱 Agent 查关系，推理 Agent 做综合判断。各 Agent 结果汇总后进行交叉裁决。

• SOP 智能导航：将长篇操作规程自动拆解为步骤化、卡片式的操作指引，与实时数据联动进行参数越限检查和防错拦截。操作人员不是”看文档做”，而是”跟着系统走、做一步确认一步、超限自动拦截”。

• 知识问答：不同于关键词检索，基于 DSKMP 语义模型进行多跳推理。用户问一个问题，系统会自动关联：设备实体 → 运行参数 → 历史故障图谱 → 同类设备维修记录，给出有依据的根因分析。

• Action 执行：AI 不止给出结论，还能在授权范围内执行操作——生成工单、触发通知、调整排产建议。所有 Action 均记录审计日志，支持人工审批节点插入。

五、核心能力

从碎片文档到结构化知识

传统 AI 知识库的本质是向量检索——文档切片后扔进向量数据库，用户提问时做相似度匹配。问题很明显：文档碎片之间没有关系，AI 不知道”轴承异常”和”更换轴承的操作规程”之间的因果链。

DSKMP 的做法不同：

不切片，先抽取——从文档中识别出实体、属性、关系

以图的方式组织知识——实体是节点，关系是边

AI 回答问题时，走的是图谱推理路径，而非关键词匹配

从”找到一段可能相关的文字”变成”理解业务对象之间的因果关系”。

从单点问答到多智能体协作

单个 LLM 面对复杂工业问题时能力有限：它不了解实时 DCS 数据，不知道当前设备运行状态，不清楚历史同类故障的处理结果，也不懂最新修订的规程。而这些信息分别存在于不同系统。

DSClaw 的解法：不指望一个模型搞定一切。为不同知识域配置专用 Agent，由编排引擎做任务分发和裁决。Agent 之间不是简单拼接各自的输出，而是在统一语义模型上交叉校验——数据 Agent 说的”当前振动值超标 3 倍”和文档 Agent 检索到的”振动超标处理规程”通过图谱 Agent 的语义关联自动匹配。

从只能说到也能做

“AI 能回答问题”和”AI 能替人干活”之间，隔着一个 Action 层。

DSClaw 在处理完一个分析任务后，可以输出结构化的 Action——生成工单、触发通知、创建任务、发起审批。这些 Action 的语义（操作对象、执行条件、预期结果）由 DSKMP 定义，执行的触发流程由 DSClaw 编排。

安全和审计是 Action 层的基石：所有 Action 支持人工审批节点、执行回滚设计、全链路审计日志。

私有化与安全部署

• 全量私有化部署：所有组件（大模型推理、知识图谱、Agent 引擎）均可在企业内网运行

• OT / IT 安全隔离：单向安全数据网关 + 工业防火墙白名单，只读不回控

• 信创兼容：支持国产 CPU / GPU、国产操作系统、国产数据库

• 权限体系：对接企业 LDAP / AD，支持基于角色的资源访问控制，知识与 Agent 能力按组织架构分级

六、从理解到执行：完整协作闭环

以一次典型的设备故障排障为例，展示DSClaw的完整工作链路：

▎用户问

“P-301 泵振动超标，需不需要停机？”

▎① 语义解析 DSKMP

识别实体：P-301 → 裂解进料泵 → 转化装置 → 合成氨车间

锁定知识域：振动分析、离心泵故障、联锁规程

▎② 任务分发 DSClaw Orchestrator

Agent A → 查询 DCS：当前振动值、历史趋势、关联参数

Agent B → 检索知识图谱：同类设备历史故障及处理结果

Agent C → 检索操作规程：振动超标对应的联锁阈值和处置 SOP

Agent D → 检查备件库存：如需要更换轴承，备件是否在库

▎③ 交叉裁决 Multi-Agent Verdict

Agent A 报告：振动值 7.2 mm/s，超标准值 2.1 倍

Agent B 报告：过去 12 个月出现过 3 次类似情况，2 次为轴承磨损

Agent C 报告：运行规程规定 ≥7.0 mm/s 需降负荷，≥9.0 mm/s 触发联锁停机

Agent D 报告：轴承备件库存 3 套，安全库存以上

→ 裁决结论：当前不必立即停机，降负荷运行，24 小时内停机检修

▎④ 输出与执行

· 用户看到：结论 + 依据摘要 + 每一个 Agent 的详细分析

· 系统执行：一键生成工单、通知值班长审批

▎⑤ 知识沉淀

· 本次排障过程自动写入知识图谱，成为最新故障案例

· 下次同类问题发生时，Agent 将拥有更丰富的参考依据

七、与 Palantir Ontology 的理念对照

我们不回避对标。Palantir 在”企业数据语义化”这个方向上做出了全球最好的产品体系。Ontology 是 Palantir Foundry 和 AIP 的基石——它让上层 AI 不是对着几千张表做概率匹配，而是在一个具有清晰业务语义的对象世界上进行推理。

DSKMP + DSClaw 要解决的是同一个问题。但我们走的路线不同：

我们尊重 Ontology 的成就。但我们认为，在中国制造业、化工业、政务等场景下，DSKMP 的”自动抽取 + 产品化部署”路线是更现实、更可行、更适合规模化复制的方式。

八、结语

企业 AI 的真正落地，从来不取决于一个更大参数的模型，而取决于企业是否拥有了一个可以被 AI 理解的数字世界。

DSKMP 让这个世界里的每台设备、每份工单、每条规程，都有名字、有身份、有关系。

DSClaw 让多个 AI Agent 在这个世界上协作，完成从理解到判断到执行的完整闭环。

我们想做的不是又一个搜索框或者聊天窗口，而是一个真正理解你业务的数字操作系统。

让数据有语义，让 AI 能协作，让决策可执行。