阿里千问开源MyContext：让Agent读懂真实工作流上下文

今年以来，Agent Harness已经成为AI领域的热门关键词。一方面，大模型的推理、代码调用和工具使用能力在持续升级；另一方面，各类Agent插件、协议和执行框架也在不断补齐任务编排、环境调用、多步执行和状态管理的能力。

如今，AI Agent处理个人办公任务已经越来越成熟：写报告、查资料、修改表格、运行代码，甚至连续执行多步复杂任务，都已经进入了可用好用的阶段。

但一旦将Agent真正嵌入真实的工作流程，一个扎心的问题就会立刻浮现：这个Agent根本不懂真实的业务场景。

举个职场人都熟悉的场景：你让Agent帮忙更新上周讨论过的客户方案，并按照公司最新的口径整理成汇报材料。

这句话对人类来说信息完整且清晰，但对Agent而言，这些业务信息天然分散在邮件、即时通讯工具、协作文档和各类业务数据库中，还伴随着实时更新、版本冲突、权限边界和信息过期等一系列问题。

最终Agent只能依赖通用模型知识和当前的Prompt指令完成任务，完全无法贴合真实的工作场景，自然无法给出符合业务需求的结果。

这也暴露出AI Agent走向生产级场景的核心上下文问题：模型能力的提升并不会同步补齐Agent对真实工作场景的理解。

真实的工作从来不是孤立的单条指令，每一个任务背后都关联着分散在不同平台的工作讨论、已形成的决策、不断变化的项目状态、组织内部的规则，以及人与人之间默认共享的上下文背景。

这些持续积累、不断变化的信息，共同构成了任务真正的「业务现场」。如果这些业务信息无法被Agent获取并理解，Agent就只能依赖通用知识和当前指令，无法真正嵌入具体的工作流程。

更严峻的是，这个问题已经逐渐成为Agent进入生产级场景的普遍基础设施瓶颈。根据2026年Confluent的调查，66%的企业认为数据基础设施和数据质量正在拖慢Agentic AI的落地；与此同时，80%的企业已经将「用好自家数据驱动AI」列为业务优先事项。

这意味着，企业AI落地的真正瓶颈，已经不再是前端是否有更强的模型，而是后端是否有一套能够持续治理、加工并将分散业务数据转化为可用上下文的基础设施。

好在，已经有主流厂商开始从基础设施层解决这个问题。针对Agent无法获取真实业务上下文的痛点，国内团队推出的MyContext给出了直接的解决方案：将原本散落在Agent访问范围外的工作数据，加工成Agent可以直接消费的标准化上下文。

值得注意的是，这个项目仅开源一周，就在GitHub上获得了超过1000个Star。

这款项目就是国内主流AI办公团队推出的「MyContext」，它的核心逻辑相当直接：将分散在各处、格式各异的个人工作数据加工成Agent可以理解的专属档案，让Agent真正读懂用户和真实业务工作流，并最终在决策和执行等环节实现人机协同。

MyContext从上线之初就瞄准了企业上下文领域的几个核心难点：迟到且反复变化的时序数据、彼此矛盾的业务事实，以及海量历史数据持续更新带来的计算成本。

其实针对企业级上下文的问题，海外厂商已经展开了不同路径的探索：比如企业级数据与AI平台公司Palantir通过Ontology统一企业对象、关系与业务逻辑，为Agent提供可执行的语义层；企业级AI搜索与知识平台公司Glean则更强调Enterprise Graph，将人、项目、文档和业务实体之间的关系连接起来；微软则依托Microsoft Graph与Copilot Connector，将企业数据、权限和协作关系接入Copilot。

尽管路线不同，但这些探索的核心方向一致：Agent要进入企业核心流程，必须先建立对组织数据、关系和规则的上下文理解。

不过，从早期就瞄准企业场景的MyContext团队，进一步将关注点推向了更底层的工程问题：如何将异构、强时序、持续变化甚至彼此冲突的原始业务数据，稳定加工成Agent可以直接消费的Context。

在团队看来，上下文真正接入业务场景后，难点远不止简单的数据接入，背后需要一整套围绕数据处理、状态管理和上下文推理的工程解决方案。

首先要解决的是时序数据处理的问题。真实办公数据中的时间远比单纯的时间戳复杂：上周的消息可能今天才同步，同一个群上午聊上线、下午聊预算，已经是两个完全不同的话题。如果仅按时间先后筛选，迟到的信息容易被遗漏；如果机械按固定Token切分，又可能将不同话题混进同一段上下文。

MyContext并没有简单按时间新旧处理数据，而是为每条原始信息绑定了稳定的来源标识，将幂等性建立在数据源的稳定标识之上：即使数据的时间戳已经较旧，只要系统此前未处理过，依然会进入处理链路。同时，团队以对话空闲间隔作为Session边界，让上下文切分符合真实的交互节奏。在知识提炼环节，还采用滑动时间窗持续聚合证据，当某个事实在不同时间、不同讨论中反复出现时，其重复出现会转化为新的置信度信号。

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

第二个更棘手的问题是事实冲突处理。企业中的工作事实往往并非整齐划一：销售说客户已经确认需求，项目经理却表示流程还未走完；上午会议确定了A方案，下午负责人又补充了新的条件。工业系统中常见的处理方式是保留最新版本或置信度最高的一条，虽然得到了唯一答案，却抹掉了决策过程中的分歧和变化。

MyContext则通过「三态合并机制」将冲突视为需要保留的业务信号：一致的信息用于增强置信度，补充的信息并入既有结论，当出现真实冲突时，则同时保留多条事实并下调置信度，将冲突明确暴露给用户。对于已经由用户人工确认的结论，还会设置更高优先级，禁止后续模型自动覆盖。

这意味着Agent获取的上下文会更接近真实的组织运转状态：哪些事情已经形成共识，哪些还在变化，哪些需要等待决策，Agent都能清晰区分。

最后一个容易被忽略的问题是上下文工程的成本控制。企业数据是持续更新的，如果每收到一批新消息就让模型重新计算整个历史上下文，反复进行Embedding、实体判断、去重和归并，计算成本和延迟会迅速失控，带来极高的资源消耗。

针对这个问题，MyContext采用了增量计算的思路：可以通过本地规则处理的信息先直接完成处理，只有遇到关系模糊、规则无法判断的信息时，才交给模型处理；已经计算过的结果会尽量复用，多次更新的数据则攒成批次集中处理。同时配合版本缓存、批量触发和分级降级策略，尽量减少重复计算，将昂贵的模型能力留给真正新增、需要推理的信息。

通过这些底层的工程设计，MyContext实现了一套能够持续处理异构数据、时序状态、事实冲突、置信度演化、增量计算和成本约束的完整系统。这些看不见的底层能力，决定了AI Agent能否从偶尔调用工具完成任务，进一步进入持续变化的真实业务流程，实现长期稳定的协作。

企业每天最鲜活的上下文，本就产生在一线的协作现场。从诞生之初就瞄准企业工作场景的MyContext，并没有将能力边界局限在个人用户层面。

这款项目的更大目标，是将上下文能力从个人工作流延伸到整个组织内部，与协作工具和AI办公平台形成「数据汇聚—上下文加工—Agent消费」的三位一体闭环，真正进入企业级工作场景。

在即时通讯层面，依托国内最大规模的企业协作平台，企业可以快速获取高价值的原始知识库；在上下文治理层面，团队的异构数据处理和上下文工程积累，可以帮助企业将来自不同平台的知识、工作流重新组织起来；在Agent层面，高质量的上下文可以推动任务执行从「能完成」升级为「更准确、更符合组织规则」。

当这三层能力结合起来，企业分散在不同系统中的数据将完成价值跃迁：那些藏在聊天记录、会议纪要、业务系统和个人判断中的信息，不会随着项目结束、人员流动和时间推移而流失，而是会沉淀为一套可信、可追溯、且能随组织运行持续演化的工作上下文。

当这层能力真正建立起来，AI Agent将不再是被动接收Prompt的工具，而是能够理解组织、延续任务、参与协作的长期生产力单元。真实业务场景中的数据，也将从「可被查询的资产」进一步升级为「可参与执行的资产」。

目前，MyContext已经正式开源，感兴趣的开发者和企业可以直接上手体验。