本文为IPO早知道原创

作者｜Stone Jin

日前，滴普科技(1384.HK)创始人、执行董事、董事会主席兼CEO赵杰辉发表了题为《协同，企业级智能体的另一道工程题》的思考。

以下是全文精选：

三个判断

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

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

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

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

其一、 本体作为语义层，承载业务语义层 Plan 能力

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

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

同时，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 级企业操作系统」 的工程内涵。

DeepexiOS 的三个工程创新点

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

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

创新点一：本体大模型作为语义记忆与 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、AI 员工、AI 员工团队三层结构，全部长在企业本体上。

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

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

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

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

在 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

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 之上的企业本体耦合。

写在最后

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

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