近日，千问办公正式开源了个人工作上下文基础设施MyContext，该项目上线短短一周多，便在GitHub上斩获超过1000颗星，成为千问办公首个开源项目，引发业界广泛关注。
MyContext并非传统意义上的知识库，而是聚焦于将飞书、钉钉等平台中的聊天、文档、会议记录等工作痕迹进行整合，形成一份个人工作档案。通过这份档案，Agent能够逐渐了解用户的身份、工作内容以及日常处理事务的方式。它类似于为Agent配备了一个本地个人知识库Obsidian，但二者存在明显差异。Obsidian的内容主要依赖用户手动撰写，而MyContext则致力于从日常工作记录中自动提炼关键信息。
从架构上看，MyContext构建了一个围绕“个人工作”的庞大循环系统。它持续抓取消息和工作信息，经过分类、抽象、存储和关联等一系列操作，最终沉淀为Agent可调用的上下文。在千问办公的产品布局中，MyContext扮演着补充Agent办公“上下文层”的重要角色。此前，千问办公已整合阿里旗下的QoderWork、悟空、MuleRun三款办公Agent产品，MyContext的开源为AI办公产品提供了实用的上下文工具支持。
MyContext的核心目标是为办公Agent补充上下文，让聊天记录转化为“个人档案”。在实际工作中，若将Agent比作新入职员工，其面临的最大难题并非不会工作，而是不清楚用户的工作内容和任务背景，每次处理新任务都需重新从提示词和资料中寻找线索。MIT发布的NANDA报告显示，约95%的企业级生成式AI试点未能取得收益，主要原因是缺乏数据基础设施，导致AI系统难以融入现有工作流。MyContext正是致力于解决这一问题，通过提炼日常工作记录，为Agent提供持续更新的“个人上下文”。同时，在数据安全方面，AI仅作为使用方，模型和Agent只能通过受控接口读取上下文，数据所有权和权限归用户所有。
MyContext在架构设计上并未直接让大语言模型（LLM）进行总结，而是通过多步流程将日常消息与工作记录转化为Agent可用的上下文。首先，通过channels插件打通钉钉和飞书，采集聊天、文档、会议纪要、待办审批、日历、通讯录等信息，采集范围由用户授权控制，保密群信息会被跳过，数据按“数据源 + 类型 + ID”进行增量去重。原始信息进入系统后，MyContext会将连续3小时无人发言的消息切成会话块，再经过向量化、实体和事实抽取，形成带时空信息的知识图谱。接下来是关键的蒸馏环节，MyContext从聊天记录中提炼用户的工作模式，形成五类结构化结论，包括用户的工作内容、他人通常找用户的事务、接到任务后的处理步骤、交付形式以及用户的规矩和红线。它还会从对话中识别多步流程，整理成playbook，为多个Agent协作提供支持。最终，这些工作档案交到Agent手中，数字分身基于档案理解新消息、召回相关背景，并生成符合用户习惯的回复草稿。
在MyContext的设计中，生成和发送功能被刻意拆分，管控模块是唯一决策点，生成模块不具备发送能力。这意味着MyContext沉淀的是一套关于用户工作方式的判断，当这些判断被Agent调用时，准确性和可信度成为关键问题。
由于MyContext生成的工作档案源自真实的聊天和工作记录，包含用户的工作习惯、协作关系和正在推进的事务等信息，因此安全边界至关重要。MyContext的数据默认存储在本机SQLite，图谱采用本地文件模式，不强制上云；数字分身的生成和发送能力分离，能否直接对外发送由用户策略决定，同时提供“yolo”模式允许跳过审核。为防止prompt注入问题，MyContext会对抓取的内容进行处理，如将换行改为空格、处理Markdown图片链接、替换反引号等，避免工作档案受到污染。
有使用者拉取源码实际运行MyContext后发现，项目存在一些真实工程中的“踩坑痕迹”。例如，playbook第一版按“消息最多”挑选样本，未能归纳出有效流程，后改为按流程密度挑选样本，效果显著改善。然而，目前MyContext仍处于开发者预览阶段，没有集成包，需拉取源码自行启动。在实际运行过程中，从安装、授权到数据处理都存在一定门槛，如知识图谱默认后端缺少本地C库，需手动补依赖或切换SQLite；目前主要支持钉钉，飞书不支持数字分身。数据处理方面，若主模型不支持embedding，向量化阶段会报错，后续图谱和蒸馏也无法进行。实际运行中，采集功能正常，但图谱生成失败，个人画像也无法提取。README明确提醒，项目仍可能出现破坏兼容性的改动，本地数据依赖版本化迁移，部分改动不可逆。由此可见，MyContext目前更像一套面向开发者的基础设施原型，距离成为拿来即用的AI办公产品还有一定距离。
