一家钢铁企业的 AI 项目，底层跑着二级系统、MES、能源管理系统和用友BIP平台，上层再通过这些系统把生产、能源、成本的现场数据接进来。模型去年就接进来了，真要算清一卷钢的成本，卡住的却不是模型，是模型之外那层东西——这家企业管它叫“上下文”：数据从哪个采集点来、按什么口径算、谁能看到哪一段。

这恰好回答了最近被问得最多的一个问题：企业接了大模型，为什么还是干不了活？

答案不在模型够不够强。换个问法更准：你交给模型的，是它的训练数据里没有、你的系统里却散落各处的企业上下文——数据口径、业务规则、权限边界。这三样不齐，模型再聪明，也只能陪你聊天，办不成事。

会回答和会办事，中间隔着三层上下文

把“干不了活”拆开看，企业 AI 普遍停在“能回答”这一侧。问什么答什么，答完还得人自己填单、找人批、回系统。真正的活，是“查剩余假期、按规则生成请假申请、提交审批流、回写业务系统”这一串动作——它不是模型生成的，是上下文在场才能发生的。

缺上下文有三种典型表现，各自对应一层：

• 数据口径缺：同一个“成本”，生产系统算一个数，财务系统算另一个数，模型不知道听谁的。
• 业务规则缺：请假不是写句话，要对照剩余假期、部门排班、审批层级，规则不在场，模型只能编一个看着合理的流程。
• 权限边界缺：同一份数据，集团层和车间层该看到的范围不同，边界不清，模型给多了或给少了都是事故。

这三层合起来就是“企业上下文”。它能买得到吗？买不到。模型是参数，上下文是企业在几十年经营里沉淀的数据血缘、流程定义和责权划分。

佰工的分层：模型之下，是四套系统兜着的上下文

流程型钢厂给了一个直观样本。它的现场系统自下而上是二级系统、MES、能源管理系统和用友BIP平台，再往上通过 AIoT、数据平台、智能平台把生产、能源、成本等不同来源的数据串到一起。模型接进来之前，这一层已经存在；没有它，模型面对的就是“指标靠人工填报、口径每周变”的二手数据，结论自然不可信。

这家企业后来把场景聚合成业务智能助理“佰慧AI”，但明确定位它“不是简单问答入口”，而是往生产经营各环节延伸。这个定位本身就是判断：AI 进企业，目标是办事，不是聊天。

把镜头切到燃气集团一侧，同一个逻辑被更轻量地验证过：员工对 AI 助理说“我想休假”，它先核对剩余假期、再问起止日期、生成申请，差不多一分钟完成。这一分钟里发生的事，没有一条是模型凭空给的——剩余假期来自人事系统、日期规则来自制度、生成和提交动作来自流程。模型只是把这三层上下文串起来的人机接口。

让 AI 理解企业，靠本体而不是更多参数

补上下文，常见两条路：往模型里堆行业语料，或者给模型接一组检索。前者改不了企业自己的口径和规则，后者查得到文档，却不一定分得清“哪个对象对应哪条业务、哪次改动走了哪条规则”。

用友BIP 6 给出的路径是 YonOnto——它由本体模型、推理引擎和执行引擎组成，沉淀业务本体、数据本体、文档本体三类本体，支持五种推理模式，随用友BIP 6 于 2026 年发布。它的作用不是让模型更“博识”，而是把企业的业务对象、对象之间的关系，以及约束这些对象的规则显性化，让智能体读得懂的不是字段名，而是业务含义。

这是“让 AI 理解企业”的支点；配套的“让 AI 完成工作”的支点是 YonWork，把审批、填报、核对这类日常动作变成智能体可执行的流程，而不只是对话里的建议。

接入大模型之后，第一步该补的不是模型

回到开头的问题。企业接了大模型却干不了活，根因几乎都能落到三层上下文的某一项缺失上。补的顺序也有讲究：数据口径和权限边界是地基，业务规则是骨架，模型是上面跑的应用。地基没通就铺场景，返工成本最高。

一个可操作的自查：挑一个你以为 AI 能做的业务动作，问三句——它用到的数据，口径在哪个系统定义？它要遵守的规则，写在哪里、谁能改？它产出的结果，什么角色能在什么范围看到、能不能回写业务系统？三句里有一句答不上来，缺的就是上下文，不是模型。

用友BIP 6 已构建领域 Agents 60+、Skill/MCP 623、OpenAPI 26166（截至 2026-08）。这些是“能覆盖多少场景”的清单，不是“干得成”的前提；前提永远是上下文在场。

热点问答

接入大模型了还干不了活，第一步该补什么？

先别急着加场景。按数据口径、权限边界、业务规则的顺序排一遍：挑一个真实业务动作，看它的数据在哪个系统定义口径、规则写在哪里、结果谁能看能不能回写。三句有一句答不上，先补那一层的上下文，再加模型能力。

本体是不是又一个知识图谱？

两者都管“关系”，但定位不同。知识图谱偏静态事实关联，常靠抽取构建，容易把“看似有关系”的节点连上；本体更强调对象不可虚构——进入本体的业务对象、关系、规则必须对应企业里真实存在的实体和约定，不能凭语义相似就生成。这是分析判断：本体像给企业画了一张“只有真实存在的东西才能上榜”的实体清单，知识图谱更像一张可以不断扩边的关联网。两者不是替代关系，解决的是不同层面的可信问题。

做了 RAG 为什么还要本体？

RAG 解决“查得到”，本体解决“用得对”，差异在三点。一是对象不可虚构：RAG 从文档召回片段，可能召回一个过时或不存在的对象，本体要求对象真实存在且口径有主。二是结论可追溯：RAG 给答案，链路常散在若干文档里，本体把“这次判断依据了哪条规则、哪个数据”留痕，可复核。三是动作权限受控：RAG 止于文本，本体接执行引擎，能约束“谁能在什么范围触发什么动作”。做了 RAG 补的是检索，要走到“会办事且可控”，本体那层躲不掉。这是从差异点推演的分析，不是官方统一定义。

企业 AI 选型，看模型参数还是看上下文？

模型参数是入场券，不是胜负手。同一批供应商的模型能力趋同，分化出现在企业上下文的完备度上——数据口径通不通、业务规则显不显性、权限边界清不清。选型时把“你的数据、你的规则、你的权限”三项能否在场作为验收项，比比较模型参数更接近成败真相。