共计 1101 个字符，预计需要花费 3 分钟才能阅读完成。
企业里沉淀的数据越来越多,AI 真正能“看到”的却始终有限 。云栖大会期间, 千问办公抛出一个值得玩味的问题: 当模型能力不再是瓶颈, 企业到底缺什么? 答案指向同一个词——上下文。
📌 数据很多,AI 能用的很少
阿里巴巴集团副总裁、千问办公 CEO 陈宇森给出了一组对比: 一家中大型企业内部的数据规模平均约为 150PB, 而当前最强模型的上下文窗口大多在 100 万 token 左右 。两者之间横着数个数量级的鸿沟。
更麻烦的是, 企业数据并非整齐排列的数据库记录 。客户需求、业务规则、员工经验散落在文档、会议、群聊和各类业务系统中, 有的彼此矛盾, 有的早已过时。模型即便接触到更多数据, 也未必知道完成眼前任务该调用哪一条。
🔍 三大症结: 不懂业务、组织没跟上、不敢用
- AI 不懂业务 : 通用任务交给任何足够好的 Chatbot 都能完成, 换成具体企业的问题就难以回答。
- 个人提效但组织未跟上 : 员工把八小时工作压缩到一小时, 经验既没有机制分享给同事, 也没有沉淀给组织。
- 想用但不敢用 : 企业要在降本的同时守住数据安全底线。
💡 把上下文做成基建, 而不是某个功能
具体做法上, 企业上下文采用类似文件系统的组织方式 , 让每一层级尽可能压缩下一层级的信息,Agent 需要时逐级展开, 即“渐进式暴露”。同时用图数据库连接实体关系——一个项目关联了哪些人、哪些群聊、哪些文档, 汇聚后 Agent 才能判断执行状态。
束骏亮举了一个成本账: 如果抽象一家企业的上下文要 10 天、花 100 万元, 对企业不可行 ; 如果能做到 5000 元、3 天, 就是好方案。处理海量非结构化数据时, 模型是否足够好用、适配场景、快且便宜, 直接决定抽象的质量与成本。
📊 从古茗案例看落地路径
奶茶品牌古茗有一万多家线下门店, 新品上市时总部运营标准需要及时下发 。通过企业上下文, 飞书文档、知识库、答疑群和培训日程里的内容被整理成门店运营知识空间, 帮助近万名一线员工快速掌握新品标准。
当店员通过 Agent 询问海报张贴规范时, 系统不会返回全部运营知识 , 而是提供当前任务所需的那部分。这背后依赖多模态理解能力足够强的模型, 比如 Qwen3.8-Omni-Flash, 来处理成千上万的视频段落。
🚀 开放与解耦: 上下文跟着主体走
束骏亮强调, 上下文跟着主体走 , 与最终使用的 Agent 解耦。企业上下文属于企业自己, 可以拿到任何一个 Agent 里使用。他把这套东西定义为新一代数据基建, 跟数据库一样, 只是尚未像数据库那样被标准化。
陈宇森也明确表态:“无论是千问办公还是企业上下文, 我们要做到: 开放 , 还是开放。”他透露, 千问办公服务了大量使用飞书和企业微信的客户, 这会是未来一个特别重要的核心方向。
