ARTICLE · 996428
66%的企业喂不饱AI:聊天、文档、会议里的散落数据,才是Agent的口粮
66%的企业喂不饱AI:聊天、文档、会议里的散落数据,才是Agent的口粮把上周讨论的客户方案更新一下，再按公司最新口径整理成汇报材料。这句话放到任何一个办公室里，人都能秒懂：上周讨论的是哪份方案、最新口径是什么、汇报材料给谁看。可把它原样交给一个AI Agent，它大概率会愣住——上周的讨论散落在聊天记录里，口径散落在通知和文档里，这些信息全在它看不到的地方。 模型能力一路狂奔的这几年，这个问题反而越来越扎眼。Confluent在2026年做的一项调查显示，66%的企业认为，数据基础设施和数据质量正在拖慢AI Agent的落地；与此同时，80%的企业已经把用好自家数据，列成了AI落地的头号优先事项。 翻译成人话就是：多数公司卡住的环节，已经不是模型不够聪明，而是AI根本够不到自家那些散落的数据。 真实工作从来不是一条孤立的指令。任何一个任务背后，都挂着散落在不同平台里的工作讨论、已经形成的决策、不断变化的状态、组织内部的规则，还有同事之间默认都知道的背景。这些东西合起来，才构成一个任务真正的业务现场。 去年开始，各种Agent框架、协议、执行引擎层出不穷，写报告、查资料、改表格、连续执行一串复杂任务，AI都越来越像那么回事了。可一旦把它真正塞进工作流，问题立刻冒出来：Agent既不知道你在负责什么，也不了解你们公司内部的规范，更读不到项目最近发生了什么、哪些讨论已经形成了结论。 结果就是，每一次让AI干活，都得把背景从头交代一遍；换一个Agent，甚至要重新自我介绍一遍。那些在聊天里聊过的、文档里沉淀过的、会议上拍板过的信息，对AI来说统统是黑盒。模型能答对全世界的题，却答不对你们公司内部那道最简单的题——因为那道题的答案，从来没有进入过它的视野。 一句话总结这个断层：模型越来越强，不代表它越来越懂你。懂你这件事，靠的不是参数，是数据。 这也是为什么各家Agent框架做得再热闹，问题依旧：框架解决的是任务怎么拆、工具怎么调、状态怎么管，属于执行层面的功夫；上下文解决的是AI知不知道你在干什么、为什么要这么干，属于理解层面的功夫。执行可以靠代码补，理解只能靠数据补。过去这两层常被当成同一件事，模型一升级，就顺带期望AI更懂业务，可模型变聪明解决的是通用问题，你们公司内部那道题，从来不是通用问题。 这个断层，正在成为AI进入生产级场景的普遍瓶颈，也成了主流厂商新的角力点。 海外已经走出三条不同的路。Palantir用一套本体模型，把企业里的对象、关系和业务逻辑统一起来，给Agent一个可执行的语义层；Glean强调企业知识图谱，把人和项目、文档、业务实体之间的关联织成网；微软则靠Microsoft Graph和Copilot连接器，把企业数据、权限和协作关系整体接入Copilot。路径不同，方向一致：Agent想进入企业核心流程，必须先建立对组织数据、关系和规则的理解。 国内的落点更直接。8月18日，阿里千问办公正式接入企业微信，至此完成了对钉钉、飞书、企业微信三大协同平台的全面打通，海外也已接入Slack。在此之前，千问办公8月3日开启公测，把桌面端Agent、云端Agent、企业协同Agent三种形态装进了同一个产品。办公人员进入千问办公连接器，完成授权和配置，就能用对话直接读取智能表格、新建和读写文档、发送通知、查询日程、预约会议、创建待办。 比入口打通更值得注意的，是阿里在数据层埋的一步棋：千问办公开源了一个叫MyContext的上下文基础设施。项目上线大约一周，在GitHub上已经拿到超过1k的星标。 这个项目的定位，是把散落在各处、格式各异的个人工作数据，加工成Agent能直接消费的专属档案。在IM里跟同事聊过什么、文档里沉淀过哪些决策、会议上定了什么事、企业有哪些标准规范，都可以经本人授权后被持续收拢、整理，沉淀成一份动态更新的工作档案。而且它不是把上下文做成一个黑箱：每一条结论都保留了可追溯的证据链，可以一路点回原始的聊天、文档或会议记录，确认是谁、在哪天、具体说了什么。 顺着这条线看阿里的布局，是一套完整的闭环：最底层，钉钉覆盖超过2000万企业组织、近8亿人，是国内最大的企业数据入口，聊天、文档、会议天然沉淀在那里；中间层，MyContext这类治理工具负责把钉钉、飞书、Salesforce、SAP以及本地存储里各说各话的数据，重新组织成AI能读懂的上下文；最上层，千问办公拿着这些高质量上下文去执行任务，让AI从能完成，走向更准确、更符合组织规则。 数据汇聚、上下文加工、Agent消费，三层一闭合，企业过去分散在不同系统里的数据才算真正被盘活：那些藏在聊天记录、会议纪要和业务系统里的信息，不再随着项目结束、人员流动而流失，而是逐渐沉淀成一套可信、可追溯、能随组织运转持续演化的上下文。 
大方向谁都能说，难的是细节。真实办公数据有多乱，干过的人才知道：上周的消息可能今天才同步过来，同一段工作沟通里上午聊上线、下午聊预算，其实是两个话题；销售说客户已经确认，项目经理说流程还没走完；上午定了A方案，下午又补充了新条件。MyContext的处理方式，是把这堆乱麻拆成四道工序，每一道都值得单独看。 
第一道，先解决迟到和串台。如果机械地按时间先后喂数据，晚到的信息会被漏掉；按固定长度硬切，又会把两个话题搅进同一段上下文。MyContext的做法是给每条原始信息绑定一个稳定的来源标识，把要不要处理，建立在来源标识之上——哪怕时间戳已经很旧，只要系统此前没消费过这条数据，它照样会进入处理链路。同时用对话的空闲间隔来切分话题边界：聊到一半停了，再开口可能就是另一件事，上下文跟着真实交互的节奏走，而不是跟着时钟走。这一道工序要回答的问题很朴素：AI看到的，是不是一段完整、不串味的信息。 第二道，让反复出现变成可信度。企业里一个说法靠不靠谱，往往看它被多少人、在多少场合重复过。MyContext用滑动时间窗持续聚合证据：同一个事实如果在不同时间、不同讨论里反复出现，重复本身就转化成一条置信度信号。于是Agent看到的不是一堆按时间排列的记录，而是一套能识别新旧、保留话题边界、还能随时间不断校准可信度的动态上下文。这一道工序要回答的问题，是AI到底该信什么。 第三道，把冲突当成业务信号，而不是抹掉。企业里的事实很少整整齐齐排成一条线。很多系统的习惯做法是保留最新版本或置信度最高的一条，得到一个唯一答案，代价是决策过程中的分歧和变化被顺手抹掉了。MyContext用的是三态合并：信息一致，就增强置信度；信息互补，就并入既有结论；出现真正的冲突，就同时保留多条事实、下调置信度，把分歧显式摆到人面前。已经由人工确认过的结论，还会被打上更高优先级，不允许模型后续自动覆盖。这一道工序要回答的，是AI会不会把没定的事说成定了的——对任何需要留痕的组织来说，这点都值钱。 第四道，算得过账，才用得起。企业数据是持续更新的，如果每来一批新消息，就让模型把历史从头算一遍，Embedding、实体判断、去重归并全部重来，成本很快失控。MyContext把重心压在增量计算上：能靠本地规则判断的先直接处理，只有关系模糊、拿不准的信息才交给模型；已经算过的结果尽量复用，多次更新攒成批次集中处理，再配上版本缓存和分级降级策略，把昂贵的模型能力只留给真正新增、真正需要推理的信息。这一道工序要回答的，是这事能不能长期跑下去。 四道工序之外，还有两条底线贯穿始终：一是权限，AI能看见和调用的信息，始终受个人与组织的权限约束，不是收进来就能随便看；二是可追溯，每条结论都链回原始出处，谁说的、哪天说的、原始记录在哪，一查便知。 这套底层功夫，决定了Agent能不能从偶尔调用几个工具完成任务，变成长期稳定地泡在真实业务流程里干活。前端的模型可以随时换，这套把组织数据持续加工成上下文的功夫，才是短期内很难被替代的积累。 聊完技术，回到最实际的问题：这套东西和银行办公有什么关系？ 先盘一盘银行办公系统里到底攒了多少人都知道、AI不知道的信息。制度库是第一个富矿：一家银行少说有几百项内部制度，从公文处理、印章管理到数据安全，分散在OA和档案系统里，平时靠人来记、靠人来查。公文流转是第二个：一份文件从拟稿到处室会签、办公室核稿、领导签发，再到分发归档，每个环节都有过程版本和背景讨论，最终只沉淀下一个红头文件。会议纪要和督办台账是第三个：会上议定了什么、谁负责、什么时候要结果，散落在纪要正文和跟进记录里。再加上日常IM里那些过程性沟通——这些都是典型的高价值、非结构化、持续更新的数据。 过去这些数据躺在系统里，价值是可查询：人想找的时候，能检索到。而Agent时代，数据要回答的问题是可执行：AI能不能直接读懂一份制度，然后照着它起草一份合规的通知？能不能把上季度的会议议定事项和督办台账串起来，自动生成进展报告？能不能在拟公文时，自动带上相关制度条款和历史同类文件的处理口径？ 答案取决于同一件事：这些数据有没有被加工成AI可消费的上下文。而这恰恰是银行的长板所在。银行办公对可信的要求，和这类上下文基础设施的设计原则几乎是逐条对应的——证据链可追溯，对应审计留痕和事后追责；冲突显式保留、人工确认优先，对应决策过程的透明和谁使用谁负责的责任边界；权限受控，对应数据安全和保密分级。别家要额外补的合规功课，在银行是天然需求。 把四道工序对着银行的数据形态过一遍，每一道都有具体的落点。公文办理跨处室流转，同一件事在不同环节的说法可能前后不一致，冲突保留机制正好接得住；制度库历经多次修订，新旧版本并存，来源标识与版本处理能避免AI引到过期的条款；会议决议要跟踪执行，反复确认的事项自动累积置信度，督办就有了依据；最敏感的是涉密与内部信息，权限控制从第一天就不能缺席。换句话说，这套机制不是银行为AI额外做的功课，而是把银行本来就该做好的数据管理，换了一种产出方式。 当然，落地不可能一步到位，方向上大概有四步。第一步是盘点：把散落在OA、档案、IM、会议系统里的数据摸一遍，分清哪些是高价值、可授权给AI的结构化资产，哪些是敏感、需要隔离的。第二步是分级授权：按数据敏感程度定规则，明确什么数据能进Agent的上下文、谁能授权、越权怎么拦——这步做不好，后面全是合规风险。第三步是选场景试点：不用贪多，制度问答、会议决议跟踪、督办事项进展这类边界清楚、见效快的场景先跑起来，让数据加工链路在真实业务里接受检验。第四步是沉淀：把试点中验证过的数据治理规则、权限模型、加工流程固化成需求，写进下一轮系统建设和升级的规划里。 
对正在规划AI办公的银行来说，还有一个更前置的判断：选协同平台和办公系统的时候，数据能不能被AI顺畅消费，正在变成和功能、价格一样硬的指标。入口、模型都可以后补，数据在谁手里、以什么形态存在、权限边界清不清楚，决定了未来三年AI能在办公场景里走多远。 落到系统建设上，有一个动作现在就能做：把数据可消费性写进需求清单。协同平台选型或升级时，除了问功能全不全、性能稳不稳，还值得追问三句——系统里的聊天、文档、流程数据，能不能以结构化方式对外提供？权限边界能不能细化到数据条目级别？历史数据能不能按来源、时间、话题完整追溯？这三个问题现在答不上来的供应商，未来三年大概率也补不齐，而AI对数据的渴求只会越来越深。 数据资产的叙事，正在发生一次微妙的升级：从可被查询的资产，走向可被执行的资产。过去衡量一个办公系统值多少钱，看它存了多少数据、检索快不快；接下来要看的，是这些数据能不能被AI读懂、能不能直接参与干活。 对普通员工来说，变化是直观的：不用再对每个AI重复一遍自己的工作和背景。对组织来说，变化是根本的：那些只存在于人脑和聊天记录里的隐性知识，第一次有了被系统化留存、持续演化的可能。谁先把自家数据加工成AI的口粮，谁就拿到了下一轮办公效率竞赛的入场券。 你们单位的办公数据现在处于哪个阶段？是躺在系统里只能查，还是已经开始喂给AI干活了？评论区聊聊。觉得有启发，转发给负责办公系统和数据管理的同事。 如果是你来做这件事，第一步会怎么走： A. 先盘点数据资产，摸清家底 B. 直接挑一个场景试点，边干边理 C. 等大厂方案成熟了再动，避免返工 评论区留下你的选择和理由，我根据大家的反馈，下一篇拆一拆银行数据分级授权具体怎么落地。
模型再强，也读不懂你的业务现场
大厂开始动手：给Agent补上数据加工层
把散乱数据变成可信上下文，有四道工序
对银行办公来说，这层能力意味着什么