千问发布办公领域首个开源项目通过蒸馏飞书钉钉数据实现数字化身

本文介绍千问办公首个开源项目MyContext，它从飞书、钉钉工作记录中自动提炼个人工作档案，帮助AI办公与Agent开发者理解上下文层、数据安全和实际落地限制。

当Agent开始进入真实工作流，光会执行任务还不够，它还需要知道你是谁、常处理哪些事、习惯如何。千问办公开源的MyContext，就是想把飞书和钉钉里的日常痕迹整理成一份可持续更新的个人工作档案。

一、个人上下文基础设施

近期，千问办公正式开源了其首个项目 MyContext。上线仅一周多时间，该项目在 GitHub 上已收获超 1k 星，迅速在开发者社区引起关注。MyContext 的核心定位并非传统意义上用于检索文档的知识库，而是构建一套个人工作上下文基础设施。它试图解决 Agent 在办公场景中缺乏“背景知识”的痛点，让 AI 不再仅凭当前指令行动，而是基于对用户的长期理解来协助工作。

该项目通过自动整合用户在飞书、钉钉中的聊天消息、文档内容及会议记录，提炼并生成一份可持续更新的个人工作档案。这份档案记录了用户的身份特征、任务处理流程及交付习惯，构成了 Agent 理解用户偏好的基础数据层。在千问办公的产品矩阵中，MyContext 扮演着关键的衔接角色，它与 QoderWork、悟空以及 MuleRun 等工具形成互补，共同补全了 Agent 在真实办公流中的上下文缺失。对于希望深入理解数据流转机制的开发者而言，后续章节将详细剖析这一工作模式的具体实现。

二、工作记录采集与处理

上一节阐述了 MyContext 构建个人工作上下文的基础定位，这一层基础设施要真正落地，关键在于如何从复杂的办公环境中高效、安全地提取数据。MyContext 通过 channels 插件机制打通了钉钉与飞书的数据入口，能够全面采集用户的聊天消息、文档内容、会议记录、待办事项及日历安排。在采集过程中，系统严格遵循用户授权控制原则，注意：对于标记为保密性质的群组或文档，插件会自动执行跳过机制，确保敏感信息不被泄露。

面对海量且动态变化的工作数据，重复读取不仅浪费资源，还可能导致数据冗余。MyContext 采用“数据源+类型+ID”的组合策略进行增量去重，仅处理新增或变更的内容。为了更精准地捕捉对话语义，系统引入了会话块切分逻辑：若连续 3 小时无消息交互，则将之前的消息聚合为一个独立的会话块。这些结构化的会话块随后进入处理管线，经过向量化转换以及实体、事实抽取，最终构建出一张时空知识图谱。这张图谱为后续章节中提到的个人工作模式蒸馏提供了高质量的结构化数据基础。

三、蒸馏个人工作模式

结构化数据构建完成后，MyContext 的核心价值体现在对隐性工作模式的显性化提炼。系统不再仅停留在记录“发生了什么”，而是深入挖掘“为什么发生”以及“通常如何处理”。通过自然语言处理技术，它从海量交互中归纳出用户的五类关键结论：岗位职能、高频任务类型、标准处理步骤、常见交付形式以及业务红线。这种画像式的总结，使得 AI 能够理解用户的专业边界和操作习惯。

在此基础上，MyContext 具备将散落在多轮对话中的碎片化操作重组为标准化流程的能力。当系统识别到用户反复执行类似的多步操作时，会自动将其整理为可复用的 Playbook（操作手册）。这为多 Agent 协作提供了明确的执行依据，确保不同智能体在处理同类任务时遵循一致逻辑。在实际交互中，数字分身利用这份档案理解新消息意图，快速召回相关背景信息，并生成符合用户语气的回复草稿。

注意：为了保障最终输出的可控性，系统严格执行“生成与发送分离”策略。AI 仅负责生成建议内容，而真正的发送动作由独立的管控模块统一决策。这一设计确保了在自动化办公场景中，关键信息外发始终处于人类监督或严格规则约束之下，防止因模型幻觉导致的不当信息泄露或误操作。

四、档案可信与安全机制

档案的可信度与安全性是数字化身落地的底线。MyContext 采用严格的证据链机制，确保每一条提取的结论都必须挂载具体的 message_id，无实证支撑的推测不会被写入数据库。当新数据与既有认知发生冲突时，系统采取差异化处理：若是补充信息，则直接追加细节；若为确认信号，则提升该结论的置信度；若出现矛盾，则保留双方观点并降低整体置信度，最终交由用户裁决，避免模型盲目覆盖。

在权限控制上，数据所有权完全归属于用户。一旦用户确认了某条结论，模型便无权单方面修改或覆盖，确保工作档案反映的是真实且经过审核的业务事实。存储层面，默认采用本地 SQLite 数据库，数据不出内网，从根本上规避云端泄露风险。针对自动化场景，系统提供 yolo 模式以跳过部分人工审核，但核心防护逻辑不变，包括对 Prompt 注入攻击的实时拦截以及消息发送前的内容拆分检查，确保即使在高效率自动化流程中，安全边界依然稳固。

五、实际运行与工程限制

虽然架构设计清晰，但当前 MyContext 仍处于开发者预览阶段，尚未提供标准的集成包。这意味着想尝鲜的开发者必须直接拉取源码进行部署，且由于底层逻辑尚在快速迭代中，任何对源码的细微改动都可能破坏系统兼容性，调试成本不可小觑。

在本地运行环境中，知识图谱模块默认依赖某些特定的 C 库，若系统缺失这些依赖项，初始化会直接报错。解决思路通常是手动补充相应的系统依赖，或者在配置层面将存储后端切换为 SQLite 以规避编译问题。此外，主模型的选择至关重要，如果所选模型不支持 embedding 接口，向量化阶段将会直接失败，导致流程中断。

从生态打通来看，目前系统主要支持钉钉的数据接入，飞书方面尚不支持数字分身功能。在一次实测中，尽管成功采集了 34 条飞书消息和 6 个会话数据，但后续构建知识图谱的步骤依然以失败告终。这一结果直观地反映了项目在工程化落地上的局限性与成熟度瓶颈，提醒用户在生产环境中需做好充分的容错准备。

相关标签：

相关标签