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

梦瑶 发自 凹非寺

量子位 | 公众号 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切分，又可能把不同话题混进同一段上下文。

针对这个问题，MyContext并没有简单按「时间新旧」处理数据，而是给每条原始信息绑定一个稳定的来源标识——

将幂等性建立在数据源的稳定标识之上，即使时间戳已经很旧，只要系统此前没有消费过，数据依然会进入处理链路；同时以对话空闲间隔作为Session边界，让上下文切分服从真实交互节奏。

在更高一层的知识提炼环节，它还采用滑动时间窗持续聚合证据，某个事实如果在不同时间、不同讨论中反复出现，其重复本身就会转化为新的置信度信号。

这样一来，Agent看到的就不再是一堆按时间排列的聊天记录，而是一套能识别新旧、保留话题边界、处理历史更新，还能随着时间不断校准可信度的动态上下文～

另一个更棘手的问题，是「事实冲突」。

企业里的工作事实很多时候并不会整整齐齐地排成一条线，销售说客户已经确认，项目经理却说流程还没走完；上午会议里定了A方案，下午负责人又补充了新的条件。

工业系统里常见的处理方法，是保留最新版本，或者保留置信度最高的一条，看起来得到了唯一答案，实际也顺手抹掉了决策过程里的分歧和变化。

在这点上，MyContext则通过「三态合并机制」把冲突当成一种需要保留的业务信号——

一致信息用于增强置信度；补充信息并入既有结论；出现真实冲突时，则同时保留多条事实并下调置信度，将冲突显式暴露给用户。

对于已经由用户人工确认的结论，则进一步设置更高优先级，禁止后续模型自动覆盖。

这就意味着，Agent拿到的上下文，会更接近真实组织运转的状态，哪些事情已经形成共识，哪些还在变化，哪些必须等人拍板，它都能分得清。

△AI生成

最后一个很容易被忽略的问题，是上下文工程本身也得算得起《账》。

大家都知道，企业数据是持续更新的，如果每来一批新消息，就让模型把历史上下文从头算一遍。

如果每来一批新消息，都重新做Embedding、实体判断、去重和归并，计算成本和延迟很快就会失控，真·烧钱啊！！！

于是乎，MyContext灵机一动，选择把重点放在增量计算上——

能靠本地规则判断的先直接处理，只有碰到关系模糊、规则拿不准的信息，才交给模型；已经算过的结果尽量复用，多次更新则攒成批次集中处理。

再配合版本缓存、批量触发和分级降级策略，尽量减少重复计算，把昂贵的模型能力留给真正新增、真正需要推理的信息。

于是，一套能够持续处理异构数据、时序状态、事实冲突、置信度演化、增量计算与成本约束的系统工程，就这么集达成到了MyContext身上。

而这些看不见的底层功夫，也决定了Agent能否从偶尔调用几个工具完成任务，进一步走进持续变化的真实业务流程，长期、稳定地干活。

从组织数据到Agent协作，补齐企业上下文最后一环

企业每天最鲜活的上下文，本来就产生在一线协作现场。

自诞生起便瞄准企业工作场景的千问办公，显然很早就意识到了这一点。

而作为面向真实业务场景搭起的上下文基础设施，MyContext事实上也没有把能力边界停留在个人用户身上。

再往前一步，它所瞄准的更大命题，是把这套上下文能力从个人工作流继续向组织内部延伸——

与钉钉、千问办公形成一套「数据汇聚—上下文加工—Agent消费」的三位一体闭环，真正进入企业级工作场景。

在IM层面，钉钉拥有国内最大规模企业客户，覆盖超2000万企业组织、近8亿用户，是天然的数据入口，企业可快速从中获取高价值原始知识库。

到了Context治理层，千问办公团队在异构数据处理和上下文工程上的积累，则可以帮助企业把钉钉、飞书、Salesforce、SAP，以及企业本地存储里那些原本各说各话的知识、工作流等重新组织起来。

在Agent层，千问办公承接高质量上下文，推动任务执行从「能完成」走向「更准确、更符合组织规则」。

这三层连起来之后，企业过去分散在不同系统里的数据，才真正完成了一次价值跃迁——

那些藏在聊天记录、会议纪要、业务系统和个人判断里的信息，不再随着项目结束、人员流动和时间推移一点点下沉，而是逐渐沉淀为一套可信、可追溯、还能随着组织运行持续演化的工作上下文。

当这层能力真正建立起来，Agent才有机会从一次次被动接收Prompt的工具，进一步演化为能够理解组织、延续任务、参与协作的长期生产力单元。

这也意味着，真实业务场景里的数据也将从「可被查询的资产」进一步走向「可参与执行的资产」。

对了，目前MyContext已经开源，感兴趣的朋友可以直接上手试试～

参考链接：

[1]https://github.com/openTrinity/mycontext#mycontext