阿里杀进Agent上下文战场：钉钉聊天、企业文档、工作数据终于要被Agent吃进去了

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400"> 阿里杀进Agent上下文战场：钉钉聊天、企业文档、工作数据终于要被Agent吃进去了 梦瑶 2026-08-18 12:40:03 来源： 量子位 梦瑶 发自 凹非寺 量子位 | 公众号 QbitAI 痛心啊！这产品那插件用了大一圈，我这Agent咋还是不懂我日常每天的工作流啊…… 哪怕到了各种Harness各种AI产品满天飞的今天，个人、企业用户依然苦 工作场景「上下文」 久矣。 对于真实工作里最重要的信息，Agent经常两眼一抹黑！！ 在钉钉里跟同事聊过啥、文档里沉淀过哪些决策、企业各种标准规范，这些数据信息往往全散落在Agent之外。 那如果我说，现在有这么个东西，能直接给每个人建一层专属的工作上下文呢—— 聊天、文档、会议里散落的历史信息，全给你收拢整理成Agent能直接消费的上下文。 甚至我再打眼一看，这个项目开源短短一周，就已经在GitHub斩获超 1k Star 了！？ 不卖关子，就是这两天阿里千问办公开源的上下文基础设施 「MyContext」。 这玩意儿干的事情，可以说是相当《直给》—— 直接 把分散在各处、格式各异的个人工作数据加工成Agent能理解的专属档案 ，让Agent真正读懂用户和真实业务工作流，并最终在决策和执行等环节实现人机协同。 而且MyContext一上来挑的，还是企业上下文里几块出了名难啃的骨头。 迟到、反复变化的时序数据，彼此矛盾的事实，以及海量历史数据持续更新带来的计算成本，基本一起梭哈了。 当聊天、文档、会议和业务规则都能被持续加工成Agent可消费的上下文，Agent才真正有机会从一个会执行指令的工具，走进真实工作流。 这回，真的有人帮我们把真实业务场景里的数据信息，狠狠加工利用起来了！！ 从分散数据到可用上下文，MyContext补上Agent的数据加工层 Agent Harness，几乎成了今年AI圈绕不开的关键词。 这边模型的推理、代码和工具调用能力不断next level。 那边各种插件、协议和执行框架不断补齐Agent的任务编排、环境调用、多步执行和状态管理能力。 于是到了今天，Agent处理个人办公任务，已经越来越像那么回事了： 写报告、查资料、改表格、跑代码，甚至连续执行一串复杂任务，都已经逐渐进入能用好用的阶段。 But，一旦把它真正塞进工作流，一个扎心的问题还是会迅速冒出来—— 这Agent，是真不懂真实业务场景啊我说！！！ 举个大家日常工作里应该都很有体感的例子。 我们让Agent帮我把上周讨论的客户方案更新一下，再按公司最新口径整理成汇报资料。 这句话对人来说信息很完整，但对Agent来说，这些真实业务中的内容可能天然分散在邮件、IM、文档和各种数据库中，甚至可能还伴随着实时更新、版本冲突、权限边界与信息过期的问题。 结果就是Agent既不懂咱的工作流，也不了解企业内部规范，只能靠模型通用知识和当前Prompt完成当前任务，真·傻眼了。 而这，也恰恰暴露出Agent走向生产级场景时一个越来越核心的上下文问题。 模型能力一路提升，并不会同步补齐Agent对真实工作场景的理解。 真实工作从来都不是一条孤立指令，每一个任务背后都挂着散落在不同平台中的工作讨论、已经形成的决策、不断变化的状态、组织内部的规则，以及人与人之间默认已经知道的上下文背景。 这些持续积累、不断变化的信息，共同构成了一个任务真正的「业务现场」。 这些业务信息一旦无法进入上下文，Agent就只能更多依赖通用知识和当前指令，无法真正嵌入具体工作流。 更扎心的是，这个问题甚至已经逐渐成为Agent进入生产级场景的普遍基础设施瓶颈—— Confluent 2026年调查显示， 66% 的企业认为数据基础设施和数据质量正在拖慢Agentic AI落地；与此同时， 80% 的企业已经把「用好自家数据驱动AI」列为业务优先事项。 换句话说，企业AI落地真正卡住的，已经不再是前端有没有更强的模型的问题，而是 后端有没有一套能把分散业务数据持续治理、加工并转化为可用上下文的「基础设施」。 好在，这个问题已经开始有主流厂商从基础设施层动手了。 针对Agent吃不到真实业务上下文这个bug，阿里千问办公最近开源的项目 「MyContext」 给出的解法相当直给—— 直接把那些原本散落在Agent视野之外的工作数据资料，加工成Agent真正能消费的上下文。 IM里的沟通、文档、会议、业务协作记录，以及本地和其他工作数据源里的信息，都可以经过用户授权，被持续收拢、整理，再逐步沉淀成一份动态更新的工作档案。 过去那些每次都得反复交代给Agent的工作流信息背景—— 你在负责什么、经常和谁协作、项目最近发生了什么、哪些讨论已经形成结论，这回可以被系统性保留下来，并直接进入后续任务执行链路。 不仅如此，MyContext没有把上下文做成一团「黑箱记忆」。 每条结论都保留了可追溯的证据链，可以继续点回原始聊天、文档或会议记录，确认是谁、在哪天、具体说了什么；同时，Agent能够看到和调用的信息，也始终受用户与组织权限约束。 这样一来，个人用户最直观的变化，就是不用每换一个Agent都重新自我介绍一遍。 对企业来说，也可以将群聊、文档、会议里那些「人都知道，AI不知道」的隐性业务背景，集成到Agent的工作链路。 一言以蔽之，真实工作里的经验、工作流，都能被系统性加工成AI可理解、可检索、还能直接用于执行的Context了～ 把动态、冲突、异构数据，处理成Agent可消费的可信上下文 针对企业级上下文的问题，海外厂商其实已经展开了不同路径的探索。 比如，企业级数据与AI平台公司 Palantir ，通过Ontology来统一企业对象、关系与业务逻辑，给Agent提供可执行的语义层。 企业级AI搜索与知识平台公司 Glean 则更强调Enterprise Graph，把人、项目、文档和业务实体之间的关系连起来。 微软 则依托Microsoft Graph与Copilot Connector，把企业数据、权限和协作关系接入Copilot。 几条路线虽然不同，但方向是一致的，那就是Agent要进入企业核心流程，必须先建立对组织数据、关系和规则的上下文理解。 但在企业上下文这条技术路线上，从早期就瞄准企业场景的千问办公团队，又进一步把关注点推向了更底层的问题—— 如何把异构、强时序、持续变化，甚至彼此冲突的原始业务数据，稳定加工成Agent可以直接消费的Context。 △AI生成 在千问办公团队看来，上下文真正接入业务场景之后，难点远不止把数据接进来这么简单，其背后真正需要解决的，其实是一整套围绕数据处理、状态管理与上下文推理的工程问题。 一个很典型的问题，就是「时间」。 真实办公数据里的时间，远比一个时间戳复杂，上周的消息可能今天才同步进来，同一个群上午聊上线、下午聊预算，也已经是两个不同话题。 如果只按时间先后筛选，迟到信息容易被漏掉；机械按固定Token切分，又可能