过去三个月，企业 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 用得上的上下文。这件事没有捷径，但一旦做出来，就是别人抄不走的护城河。
