梦瑶 发自 凹非寺量子位 | 公众号 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 拿到的上下文，会更接近真实组织运转的状态，哪些事情已经形成共识，哪些还在变化，哪些必须等人拍板，它都能分得清。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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