過去三個月，企業 AI 圈有一條暗線：大家嘴上還在比模型參數，手上卻在悄悄做一件更笨的事——把自家的業務規則、歷史單據、客戶定義、審批流，一點一點餵回給系統。
這件事不性感，但越來越要命。
SAP 在 10 月底的 TechEd 上把 Knowledge Graph 升級成帶 Ontology Manager 的平台能力；網易智企在烏鎮給「帝王蟹」加了知識引擎「萬典」和一塊能採集現場數據的智能工牌；Glean 拉著實施服務商 Emergys，要把散落在 ERP、CRM、工單裡的知識連成圖譜，專治 agent 卡在試點。三條路線，一個結論：當通用模型人人可用，企業 AI 的差異，來自對自身業務、知識、流程的理解深度。
這不是新口號。去年 IBM 就說過「客戶有 19 種定義、產品有 29 種定義」，語義不一致讓 AI 推進慢 30%。但那時候它還是一份報告裡的洞察。到了 2026 年第四季度，它變成了三家廠商真金白銀發布的產品。從「道理」到「工具」，這中間隔著的，正是大部分企業現在卡住的地方。
一、SAP 把知識圖譜做成平台底座，而不是一個功能
SAP TechEd 2026 最值得記的一筆，不是又多了幾個 agent，而是它把「讓 agent 理解業務」這件事工程化了。
Joule Studio 現在支援 no-code 和 pro-code 兩種搭建方式，能選 70 多種 AI 模型，早期試用客戶還能直接在裡面跑 n8n 工作流。但真正關鍵的是 Knowledge Graph 推出 Ontology Manager：企業可以把 SAP 和第三方資料之間的關係，定義成一套「本體」。說人話就是，系統終於知道「一張銷售訂單」和「一次發貨」「一筆應收」之間，在你的公司裡到底是什麼關係，而不是各自為政的欄位。
這步棋的意義在於，它把過去顧問公司靠人手梳理的「業務流程藍圖」，變成了可以配置、可以重複使用的資產。agent 基於這套本體推理，就不會把「客戶 A 的退貨」誤判成「客戶 B 的新單」。
SAP 還順手放了一個 AI Governance Assistant，幫客戶滿足 EU AI Act。注意這個組合：知識圖譜負責「讓 agent 懂業務」，治理助手負責「讓 agent 守規矩」。前者決定 agent 能不能用，後者決定 agent 敢不敢放。
二、網易用一塊工牌，把「現場」塞進了上下文
網易智企這次最反常識的動作，是發了塊硬體——智能工牌。
工牌本身不稀奇，稀奇的是它把客戶拜訪、現場服務這些長期以來沉在紙面、微信和記憶裡的線下資訊，直接接進 AI 系統。再配上知識引擎「萬典」：它連接文件、郵件、工單、CRM 和現場溝通，還結合資訊的邏輯和時間關係，給 agent 的判斷提供依據。Agent Team 則是多個專業 agent 分工、討論、校驗，去推跨角色的複雜任務。
網易智企段毓錚說了一句很實在的話：模型能力普及之後，企業 AI 的差異，更多來自對企業自身業務、知識、流程和做事方式的理解，這些長期沉澱的內容共同構成「企業上下文」。
這話翻譯過來就是：你公司裡那個做了十年銷售、知道哪個客戶週三心情好、哪筆單子要找誰簽字的老師傅，他的腦子，才是你最該數位化的資產。工牌只是把這部分資產從「老師傅的腦」搬到「系統的上下文」裡。
三、Glean 的圖譜加實施服務，專治「試點死」
Glean 和 Emergys 的合作，指向的是同一個痛點：企業買了核心平台，但關鍵知識碎片化，agent 永遠停在 demo 階段，上不了生產。
Glean 的三根支柱是企業平台、知識上下文圖譜、智能架構，能把散落在 ERP、ESM、CRM 裡的知識連成一張網；Emergys 負責把這些能力落實到業務關鍵系統裡。它宣稱能降低 token 用量，但目前沒有量化基準，這一點要打個問號。
但方向沒錯。太多企業的 agent 專案死在「知識沒接好」：問它一個本公司才有的退貨政策，它給你背通用條款；讓它從工單裡找根因，它只看得到工單標題看不到背後的客戶歷史。圖譜不連，agent 就是個嘴快的實習生。
四、對 Odoo 使用者，這意味著什麼
作為 Odoo 實施方，我更願意從「能落地」的角度說這件事。
Odoo 的架構對做「上下文層」其實是友善的：REST API、MCP 原生連接、模組化的資料模型，意味著你不用推倒重來，就能把訂單、庫存、客戶、專案這些物件之間的關係，逐步沉澱成一套可查詢的知識底座。Odoo 20 還開放了把外部 AI agent 經 MCP 伺服器讀寫資料庫的能力——前提是你的資料本身就乾淨、有結構。
但這裡有個殘酷的真相：開源和平台只給你「裝上下文的容器」，裝什麼、怎麼裝，得自己來。語意層不會自動長出來。我見過太多專案，系統上線了，欄位填了一堆，但「客戶類型」三個部門三種填法，「交付狀態」全靠人肉備註。這種資料餵給再強的 agent，也只是讓它「聰明地犯錯」。
所以給 Odoo 用戶三條建議，按順序來：
第一，先沉知識，再上 agent。 別一上來就喊「上智能體」。先把主數據治理、審批流梳理、欄位口徑統一做紮實。上下文品質是 agent 能力的上限，這個上限你定。
第二，知識主權必須在自己手裡。 無論是 SAP 的本體、網易的萬典還是 Glean 的圖譜，核心都是「企業自己的上下文」。選型時把「資料是否 100% 自有、可否匯出、能否移轉」寫進合約。模型可以換，你的業務知識換不了，也不該被鎖死。
第三，把上下文品質當成持續的營運動作，而不是上線前的專案。 業務在變，定義也要跟著變。最好指定一個角色（不一定是 CIO，可以是業務負責人）定期維護這套「企業詞典」。
模型會越來越便宜、越來越像。真正拉開差距的，是你願不願意花笨功夫，把公司幾十年的業務直覺，變成系統讀得懂、agent 用得上的上下文。這件事沒有捷徑，但一旦做出來，就是別人抄不走的護城河。
