滴普科技赵杰辉：协同，企业级智能体的另一道工程题

在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 棒（并行），初判与隔离员快速输