![]()
協同,企業級智能體的另一道工程題。
本文為IPO早知道原創
作者|Stone Jin
微信公眾號|ipozaozhidao
日前,滴普科技(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落地的真實戰場里走出來的角度。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.