640 (7)_副本.jpg

在AI Agent浪潮席卷产业的当下，企业级AI落地的核心诉求已从“模型性能突破”转向“实际价值落地”，而如何让AI真正转化为企业可感知、可量化的生产力，成为行业共同面临的核心课题。

为此，滴普科技(1384.HK)创始人、执行董事、董事会主席兼CEO赵杰辉结合公司多年在AI价值落地领域的一线实践，推出了如何完成企业AI价值落地系列文章，本文作为系列文章的第三篇，重点聚焦于多个 AI 员工如何在企业里「一起做得对」——团队级协同的工程依据应该长什么样。

这是赵杰辉作为滴普科技创始人发布的第三份，也是最后一份产业观察。

正文如下：

前两篇文章先后讨论了智能体记忆和本体大模型。第一篇《记忆，是智能体的「灵魂」》讨论的是 AI 在企业里「记什么」；第二篇《本体大模型，企业级智能体落地的产品化探索》讨论的是 AI 在企业里「怎么想」。这一篇要往下推一层 —— 多个 AI 员工如何在企业里一起做对一件事。

一 · 三个判断

企业 AI 落地正在进入一个新阶段。

单点 AI Agent 在演示里很惊艳，但在真实业务里完成不了「一个相对完整的业务场景」。一次新品铺货决策要跨商品企划、货品运营、电商运营、品牌总监；一次产线故障处置要跨产线工程师、运维工程师、工艺工程师、研发工程师；一次政务接待要跨咨询、政策匹配、跨部门协调、合规审核——没有任何单个 AI 员工能独立完成。

落地的真实形态，是 AI 员工团队组成一个覆盖完整业务场景的「企业领域智能体」。

把这件事的工程实质讲清楚，需要三个核心判断。

判断一 · 本体作为语义层，承载业务语义层 Plan 能力

一个完整业务场景的所有语义知识，合起来是一个本体。一家企业有多个完整业务场景，就有多个本体，例如对于一家工业制造企业来说，维修场景一个本体、质量管理场景一个本体、生产计划场景一个本体、新品铺货场景一个本体。每个本体里沉淀的，是这个业务场景的全部语义知识：实体、关系、决策路径、历史归因、失败模式。

这些本体的建立和存储，在滴普科技的产品体系里都由 Deepexi 企业大模型完成——这是第一篇文章讲的「本体范式记忆」在工程层的具体形态。Deepexi 既是本体的建立者，也是本体的承载者。每个本体对应一个企业领域智能体的边界。

承接第二篇文章的「两层 Plan 架构」:Deepexi 基于这些本体形成业务语义层 Plan 能力 —— 在企业具体业务场景里完成长任务规划的能力，决定「在这个业务场景里该怎么想」；通用执行层 Plan 由接入的通用大模型承担，决定「具体调用什么工具、怎么执行」。两层 Plan 在 DeepexiOS 内部协同。

判断二 · 从 Skills 到 AI 员工，再到 AI 员工团队（企业领域智能体）协同

每个 AI 员工对应企业组织本体里的真实岗位（商品企划经理、运维工程师、可靠性工程师等），不是 AI 时代发明的新角色，而是现有岗位的对象化——客户的业务负责人看到一个 AI 员工团队，能立刻在自己的组织架构图上找到对应位置。

每个 AI 员工 = 多个基于企业本体语境的 Skills组合。Skill 不是孤立的函数，是企业本体的语义到能力的延伸—— 「门店聚类 Skill」知道这家企业的门店本体怎么定义,「故障树匹配 Skill」知道这台设备的本体节点上挂着什么历史归因。Skills 之所以能「懂业务」，是因为本体已经把企业的语义底座沉淀好了。

多个 AI 员工组成 AI 员工团队，完成一个相对完整的业务场景，这就是企业领域智能体。AI 员工之间的协同，由 FastAGI 企业智能体平台在本体语义层上承载——协同的内容不是 task，是带本体语义的业务流；协同的角色不是 Agent，是企业组织本体里真实岗位的对象化。

判断三 · 这三件事合起来，我们把它叫做 AgentOS

AgentOS 是一个让企业领域智能体真正在生产里跑起来的产品形态。它的内涵是：基于企业本体形成业务语义层 Plan 能力 + 多 AI 员工协同运行时的基础设施。

我们认为，AgentOS 会成为继操作系统、数据库、中间件之后，AI 时代的又一个产业层级品类——它定义的不是「某家公司的产品」,而是「企业级 AI 落地必须存在的一种产品形态」。

滴普科技在 AgentOS 这个品类下做的产品实现，叫 DeepexiOS —— 由 Deepexi 企业大模型 + FastAGI 企业智能体平台组合而成。Deepexi 负责本体的建立、存储与业务语义层 Plan,FastAGI 负责多 AI 员工协同的编排，两者在 DeepexiOS 里完成企业级 AI 员工团队的完整落地。DeepexiOS 同时支持通用大模型按需接入，作为通用执行层 Plan 的承担者，与 Deepexi 协同完成企业级长任务。

DeepexiOS 对外只呈现一个产品形态：一个能完成完整业务场景的 AI 员工团队。它承载这个团队的创建、运行、治理、协同——这就是我们把 DeepexiOS 命名为「AI 级企业操作系统」的工程内涵。

文章后面所有的讨论，都建立在这三个判断上。

下面用两个真实场景——制造业的产线设备故障诊断，零售业的新品上市铺货——把企业领域智能体的形态讲透。两个场景代表了企业级协同的两种典型形态 —— 前者是「多源数据 + 强时效 + 多岗位」的事件响应协同，后者是「高信息密度 + 跨部门 + 不可逆」的决策协同。

二 · 真实场景 A · 产线设备故障诊断

第一个场景来自制造业 —— 产线设备故障诊断。在真实生产线上，它的形态是：链路长（横跨「事件—判断—执行—验证—学习」的完整闭环）、岗位多（产线工程师、运维工程师、运维主管、研发工程师等）、时效紧（停机时间直接转换为产能损失）、判断难（同一个现象可能对应多种根因）。

滴普此前公开过的设备故障诊断研究中指出过三个核心挑战 —— 准确率依赖人工经验、多岗位协同沟通成本高、缺少故障沉淀。这三个挑战，单一 AI Agent 都解决不了，正是多 AI 员工协同发挥价值的场景。

以某高端装备制造商的产线为例，一次「升降机在上升过程中出现异响」事件，展开 8 个 AI 员工的协同链路。

按制造业产线里真实存在的岗位映射，团队由 8 个 AI 员工组成：巡检与发现员（产线工程师/巡检方向）、初判与隔离员（运维工程师/响应方向）、根因诊断员（运维/研发工程师）、工艺影响分析员（工艺工程师）、处置方案生成员（运维工程师/处置方向）、验证与回检员（产线工程师/验证方向）、复盘与沉淀员（运维工程师/复盘方向）、运维主管 AI 员工（运维主管，协调角色）。

协同链路的核心骨架：

● 第 1 棒，巡检与发现员从振动传感器异常频谱、电机电流抖动、产线工程师班组群上报这三路输入里关联出异常事件，产出带多源证据的事件报告

● 第 2 棒，运维主管 AI 员工做路由分发 —— 把事件同时分发给初判与隔离员、根因诊断员要求并行启动，记录审计 trace。这是协同链路的关键工程决策：在原有「人协同」模式下两者是串行的，AI 员工协同模式下两者可以并行，整条链路的关键路径从「串行加总」压缩到「最长子链」，时效优势直接体现

● 第 3/4 棒（并行），初判与隔离员快速输出分级结论（本次为 P1 级）；根因诊断员同时多假设并行评估。根因诊断员之所以能做精准判断，关键在于它读取的是 Deepexi 提供的「设备本体视图」 —— #L-003 不是「一台升降机」，而是带着完整型号属性、维护历史、故障模式库、关联工序的本体节点。它给出的不是「建议更换轴承」这种通用结论，而是带候选根因、置信度、证据链的结构化诊断

● 第 5 棒，工艺影响分析员独立评估业务影响—— 降功率运行是否影响产品质量、停机是否延误订单、是否启用备用设备。两个 AI 员工并行工作但共享同一份设备本体和订单本体，产出可以直接合并，不需要二次沟通

● 第 6 棒，处置方案生成员综合上面四棒的输出生成处置工单。常规处置派发给现场运维工程师，复杂处置升级给人—— 通过预填了完整证据、诊断、处置选项、风险评估的卡片推送给运维主管

● 第 7 棒，验证与回检员监控设备重新启动后的振动、电流、温度数据，确认根因被真正消除。验证未通过则回路反馈给根因诊断员 —— 协同链路中的反向闭环

● 第 8 棒，复盘与沉淀员把本次故障的完整链路整理为结构化故障案例，形成归因初稿，沉淀进设备故障模式库

三 · 真实场景 B · 新品上市铺货

第二个场景来自零售业 —— 新品上市铺货。每年春夏、秋冬两季，品牌新品上市是零售企业的高风险决策节点。一批新品如何在线下门店和电商渠道之间分配首铺量，涉及商品企划、货品运营、电商运营、品牌总监等多个部门并行协同。

这件事有四个真实特征：信息密度高（数百个新 SKU × 数百家线下门店 × 多个电商平台的组合决策）、跨部门强（任何一个角色都无法独立完成）、决策性质从 0 到 1（没有真实销售数据，所有判断都基于历史代理证据）、不可逆（首铺出货即固定）。

以某全球性鞋服零售集团的春夏新品上市为例——这一季要把 300+ 个新 SKU 在 60+ 个城市的 800+ 家线下门店和 5 个主流电商平台之间分配首铺量。

按企业里真实存在的岗位映射，这个团队由 6 个 AI 员工组成：商品企划 AI 员工、货品运营 AI 员工、电商运营 AI 员工、货品主管 AI 员工（协调角色）、数据分析 AI 员工、汇报材料 AI 员工。这 6 个角色全部是零售企业里本来就存在的真实职能。

协同链路的核心骨架：

● 第 1 棒，商品企划 AI 员工启动，横向调用数据分析 AI 员工拉取历史同期销售复盘，产出本季企划方案

● 第 2 棒，货品主管 AI 员工做路由分发 —— 把企划方案的线下版分发给货品运营 AI 员工、电商版分发给电商运营 AI 员工

● 第 3 棒（并行），货品运营 AI 员工对 800+ 门店做线下铺货决策，电商运营 AI 员工同时决定电商首发策略 —— 两者并行工作但读取同一份商品本体视图，这是协同能并行的前提

● 第 4 棒，货品主管 AI 员工做冲突检测与合并，有冲突推送回对应员工修正（反馈回路），无冲突合并为全渠道铺货方案

● 第 5-6 棒，汇报材料 AI 员工组装三件交付物，品牌总监审核时看到的是预填了完整证据 + 备选方案的卡片，做最终拍板。决策结果回写到协同链路，成为这个 AI 员工团队后续训练的真实标注数据

两个场景合起来，呈现了企业级 AI 员工团队协同的所有关键工程要素 —— 多源数据关联、并行处理、横向调用、共享本体上下文、冲突检测与合并、反向反馈回路、人机协作、supervisor 治理、审计回溯、知识沉淀。这些要素是协同基础设施的真实需求清单。

四 · DeepexiOS 的三个工程创新点

AgentOS 这个产业品类本质是一个让企业领域智能体真正在生产里跑起来的产品形态。下面用三个工程创新点，把滴普科技在 AgentOS 这个品类下的实现（也就是 DeepexiOS = Deepexi 企业大模型 + FastAGI 企业智能体平台）讲清楚。

每一个创新点都对应前两个场景里的具体环节，而不是悬浮的功能列表。

创新点一 · 本体大模型作为语义记忆与 Plan 的核心

回到前两章的场景 —— 两个场景里，多个 AI 员工读取的「商品本体视图」「设备本体视图」是同一份；故障诊断里运维主管按「#L-003 在工序本体里属于关键工序」做语义化路由；根因诊断员的「轴承磨损概率 60% / 润滑不足概率 35%」作为带本体节点引用的 Plan 中间状态传递给处置方案生成员。

这些事的工程原点，是 Deepexi 企业大模型作为语义记忆与 Plan 的核心。

通用层框架用共享文件系统让 subagent 之间传递信息，文件里的内容是开发者塞进去的；DeepexiOS 里的本体视图是 Deepexi 预先把企业本体从分散系统抽取、对齐、统一好的 —— 协同发生之前，本体已经在那里。每一个 AI 员工读取的不是「自己理解的语义」，是 Deepexi 沉淀好的本体。

Plan 上下文在 AI 员工之间传递，也是带本体节点引用的 —— 不只是「建议补货 50 件」，而是「建议补货 50 件，基于门店本体节点 #shop-W-0312 在品类本体 #cat-A 的历史动销分布，置信度 0.78」。所有推理都能精确追溯到本体的具体节点，这是审计可追溯性的真正基础。

这一项的工程含义是：Deepexi 不是「AI 员工调用的一个工具」，是整个协同链路的语义底座 —— 协同里所有的「看到」「路由」「传递」「引用」，都建立在 Deepexi 沉淀好的本体之上。

创新点二 · Skill 的企业本体语境 + AI 员工岗位映射

回到前两章的场景 —— 新品铺货里「店型聚类 Skill」基于门店本体、故障诊断里「故障树匹配 Skill」基于设备本体；新品铺货的 6 个 AI 员工对应零售岗位、故障诊断的 8 个 AI 员工对应制造运维岗位；多个 AI 员工组成完整业务场景的 AI 员工团队。

这些事讲的是同一件事 —— Skill、AI 员工、AI 员工团队三层结构，全部长在企业本体上。

通用层框架的 Skill 是一个带 prompt 和工具调用的函数，不知道这家企业的语义定义。DeepexiOS 的 Skill 是带企业本体语境的能力单元 —— 它的输入参数、内部逻辑、输出结构，都嵌入企业本体的语义约束。同一个「门店聚类 Skill」在不同零售客户那里都能用，只需要各自的门店本体定义不同，Skill 代码不需要改。首次部署就是「懂业务的状态」，不需要靠学习循环慢慢逼近。

AI 员工往上一层 —— 它对应企业组织本体里的真实岗位，而不是开发者定义的 abstract concept。「大区货品运营 AI 员工」在企业组织本体里属于「华东大区货品部」，上级是大区货品主管，平级是电商运营。权限边界自动由组织本体推导，协同关系自动由组织本体决定。

AI 员工再往上两层 —— 多个 AI 员工组成 AI 员工团队，完成一个相对完整的业务场景。这个团队的边界，就是这个业务场景对应本体的边界。Skill → AI 员工 → AI 员工团队，三层都是本体的延伸。业务负责人能直接读懂这个 AI 员工团队的结构，因为它就是他们现实部门的镜像。

创新点三 · 协同治理与编排的本体驱动

回到前两章的场景 —— 两个场景都明确写了运维主管 / 货品主管在审计日志里记录本次流程的 trace_id、参与的 AI 员工列表、每步决策的依据；故障诊断里「初判与并行根因分析同时启动」是基于设备本体里 #L-003 当前订单优先级的本体决策；新品铺货里「两份方案要做冲突检测后才能合并」是基于商品本体渠道分层硬约束的本体决策。

这两件事 —— 协同审计的本体级 Trace、协同编排的本体驱动 —— 本质上是同一个工程理念：在 DeepexiOS 里，协同治理与协同编排都由企业本体决定，而不是由开发者配置。

通用层框架的 trace 记录「agent 调用 + 工具调用 + LLM 响应」的工程级 trace。DeepexiOS 的 trace 是带本体节点引用的业务级 trace —— 不只是「sub-agent-3 调用 search_db」，而是「货品运营 AI 员工（组织本体节点 #role-PB-W）对商品本体节点 #A123 在门店本体节点 #shop-W-0312 上的铺货决策，基于动销本体子图 #subgraph-2024Q1」。监管来查、合规来审、出问题来追责时，这种业务级 trace 才能直接对话，而不需要业务专家做二次翻译。

通用层框架把「协同编排」留给开发者写代码定义。DeepexiOS 把「协同编排」做成本体可推导的工程对象 —— 谁该并行、谁该串行、何时引入反馈回路、何时升级到人，都由本体决定：故障诊断里「初判可以和根因诊断并行」是因为设备本体里两者的输入不互相依赖；新品铺货里「线下方案和电商方案必须经过冲突检测才能合并」是因为商品本体里的渠道分层是硬约束；两个场景里「复杂处置升级给人」是因为决策本体里这一类操作的风险等级超过阈值。

这一项是 DeepexiOS 与所有通用层框架最大的差异：它们把协同治理和协同编排作为开发者配置项，DeepexiOS 把它们作为本体可推导的工程对象。

三个创新点的共同特征，可以用一句话概括 —— 每一项都是企业本体在协同运行时层的强耦合，而不是单纯的协同基础设施工程优化。这是 DeepexiOS = Deepexi 企业大模型 + FastAGI 企业智能体平台，与通用层多智能体框架的根本差别。

五 · DeepexiOS 与通用模型之间的 token 协同

讲清楚 DeepexiOS 的三个工程创新点之后，接下来要回答一个产业里被反复问到的问题 —— DeepexiOS 怎么和通用大模型协同工作？

这件事的工程实质，要回到第二篇文章里讲的「两层 Plan 架构」。

两层 Plan 在 token 层面的协同

DeepexiOS 内部的 token 流转，本质上是两类 token 在两层 Plan 之间的协同：

● 业务语义层 token —— 由 Deepexi 企业大模型生成与消费。每一个这种 token 都携带企业本体语义，精确指向商品本体的某个节点、门店本体的某个层级、设备本体的某个故障模式、客群本体的某个细分。它们承载「在这家企业里该怎么想」

● 通用执行层 token —— 由接入的通用大模型生成与消费。每一个这种 token 不携带企业语义，但承载「具体调用什么工具、怎么写 SQL、怎么调 API、怎么生成自然语言摘要」等通用执行能力

一次 AI 员工团队完成完整业务场景的工作，在 token 层面是这两类 token 的有序协同。

何时由 Deepexi 处理、何时路由给通用模型，由 DeepexiOS 的 FastAGI 协同层根据本体语义决定：

● 涉及「企业本体里这个节点是什么意思」「这家企业历史决策本体里有什么先例」「这家企业的失败模式库里有没有相似案例」—— 路由给 Deepexi，在业务语义层生成 token

● 涉及「把这段需求转成 SQL」「调用 ERP API 拉数据」「把这份分析结果写成 PPT 大纲」「生成 Excel 模板」 —— 路由给通用大模型，在通用执行层生成 token

回到新品铺货的场景：商品企划 AI 员工向数据分析 AI 员工提出「我需要去年同期同品类、同价格段的销售复盘数据」这个需求时，「同品类」「同价格段」的精确含义 —— 在 PMS 里叫什么、在电商系统里叫什么、在 POS 里叫什么、它们在商品本体里如何对齐 —— 这些理解由 Deepexi 完成；实际的 SQL 拼装、跨系统数据拉取、聚合计算 —— 这些执行由通用大模型完成。两层在 FastAGI 的协同下完成整个数据查询。

回到故障诊断的场景：根因诊断员评估「#L-003 升降机上升异响」的候选根因时，「#L-003 是哪台升降机、它上周做过什么保养、它在工序本体里属于哪一级、过去 24 个月这型号设备的同类故障归因分布是什么」 —— 这些理解由 Deepexi 完成；调取传感器历史数据、做频谱分析、生成结构化诊断报告 —— 这些执行由通用大模型完成。

Token 经济的工程含义

这种「两层 token 协同」的产业意义，要回到之前讲到的 Token 经济。

企业级 AI 落地要在经济上算得平，要同时回答两件事：成本端的 token 单价能不能压下来，和价值端的 token 业务密度能不能提上来。

通用模型把成本端 token 单价压下来。基础模型厂商通过 MoE、量化、蒸馏、推理优化等工程努力，把通用 token 的单价持续下降 —— 这是产业公共的工程成就，所有人都受益。

DeepexiOS 把价值端 token 业务密度提上来。Deepexi 生成的每一个业务语义层 token，都携带企业本体的精确语义 —— 它指向的不是「运动鞋」这个公开互联网概念，而是这家企业里「运动鞋」在商品本体里的精确定义、它的渠道分层硬约束、它的客群本体定位、它的历史决策档案。这种 token 的「业务密度」，远高于任何通用模型在没有企业本体加持下能生成的 token。

两件事合起来，才是企业级 AI 真正算得平的工程路径 —— 通用模型把单位 token 的成本端压低，DeepexiOS(Deepexi + FastAGI）把单位 token 承载的业务价值密度抬高。两层 token 在 DeepexiOS 内部协同工作，各自做自己擅长的事。

这个 token 协同的产业判断有一个推论 —— 企业级 AI 落地不需要「自研一个比 GPT 更强的通用模型」，也不应该走这条路。通用模型这一层的能力会随基础模型厂商的迭代被快速通用化。企业级 AI 真正的工程价值，在于把通用模型的能力和企业本体精确耦合起来 —— 这是 DeepexiOS 站在产业里的位置。

我们使用 ChatGPT、Claude、Qwen、DeepSeek 等基础模型的工程成果，而不是和它们竞争。我们也使用 LangGraph、CrewAI 等通用 Agent 框架的工程探索，但 DeepexiOS 在做的不是 orchestration runtime 上的工程优化，而是 runtime 之上的企业本体耦合。

六 · 写在最后

到这里，产业观察三部曲就讲完了它的三件事 ——

第一篇《记忆，是智能体的「灵魂」》讨论的是 AI 在企业里「记什么」。本体范式记忆作为企业级 AI 的价值密度端 —— 每个 token 携带精确的企业语义，而不是公开互联网知识。

第二篇《本体大模型，企业级智能体落地的产品化探索》讨论的是 AI 在企业具体语境的完整长任务的 Plan。两层 Plan 架构作为企业级 AI 的 Plan 准确率端 —— 业务语义层 Plan 和通用执行层 Plan 在同一套模型权重里融合。

这一篇《协同，企业级智能体的另一道工程题》讨论的是多个 AI 员工在企业里「怎么一起做」。AgentOS 作为产业品类、DeepexiOS(Deepexi 企业大模型 + FastAGI 企业智能体平台）作为滴普的实现 —— 本体驱动的协同基础设施，让 AI 员工团队在企业里真正落地。

这三件事合起来，是企业级 AI 落地在 Token 经济上算得平的工程路径：

● 记忆解决「价值密度」—— 每个 token 都带企业精确语义

● 单体 Plan 解决「Plan 准确率」 —— 每次推理都基于企业本体规划

● 团队级协同解决「决策可靠性」—— 多个 AI 员工的协同不偏离业务本体

通用模型把成本端 token 单价压下来，DeepexiOS 把价值端 token 业务密度提上来 —— 三件事合起来，才是Token 经济在企业级场景里真正算得平的工程路径。

这一篇文章的副标是「本体如何驱动协同」。读到这里，这个副标的工程含义就清楚了 —— 协同的并行、协同的路由、协同的传递、协同的审计、协同的治理，每一件事都建立在企业本体之上。本体不是协同的辅助信息，是协同的语义基础。

三篇文章里所有的判断，都从滴普科技这 8 年间通过服务近 400 家头部企业落地 AI 的真实工作里来。Anthropic、OpenAI、Palantir、Glean 这些产业里值得尊敬的公司，都用各自的方式回答着「企业级 AI 如何真正可行」这个共同问题。我们用Deepexi 本体大模型 + FastAGI 企业智能体平台组合而成的 DeepexiOS，在 AgentOS 这个产业品类下，给出了我们的产业化答案。这些答案中长期会如何演进，由产业实证决定。

文章里所有的判断都是滴普视角的判断，我希望它能为这场仍在进行中的产业讨论，提供一个稍微不一样的角度 —— 一个从中国 AI to B 落地的真实战场里走出来的角度。

参考资料 · References

[1] 赵杰辉。《记忆，是智能体的「灵魂」 —— Token 经济时代下，企业级 AI 落地的一条主线》。2026.（本系列第一篇）

[2] 赵杰辉。《本体大模型，企业级智能体落地的产品化探索》。2026.（本系列第二篇）

[3] Anthropic. Claude Managed Agents announcement, Code with Claude 2026 Conference, May 2026.

[4] Anthropic Engineering. How we built our multi-agent research system. 2026.

[5] LangChain. LangGraph Documentation: State Machines for Multi-Agent Coordination. 2025—2026.

[6] CrewAI. Multi-Agent Framework Documentation. 2025—2026.

[7] 滴普科技。《设备故障诊断：DeepSense 在制造业的工程实践》。技术报告 v1。2026.

[8] 滴普科技股份有限公司。FY2025 年度业绩公告。香港联合交易所披露易。2026.