阿里千问办公开源了上下文基础设施项目 MyContext。它要解决的问题，是所有办公智能体都会撞上的那堵墙：模型再聪明，如果不知道”这个项目为什么延期、上次会议谁拍板、那份表格在哪”，就只能给出正确但无用的回答。MyContext 的定位是把散落在 IM 沟通、文档、会议里的多源工作数据，本地化地自动沉淀成一份 Agent 可理解的工作档案，并保证信息可溯源。
结论先行：它补的是智能体栈里最不性感却最要命的一层
当前 Agent 产品的竞争集中在推理、工具调用与上屏形态，真正决定可用性的却是上下文供给。没有稳定上下文，Agent 每次都像第一天入职——要复述背景、反复确认口径、把同一个需求解释三遍。MyContext 把这件事从”每次提问时临时检索”改成了”持续沉淀成结构化档案”，这是一个工程范式的差别。
值得注意的是它的运行方式：本地化。办公上下文包含大量敏感内容，路径选择本身就在回答隐私问题——档案留在本机，而不是先同步到云端索引。
它到底沉淀什么：三类来源，一种产出
| 数据来源 | 具体内容 | 沉淀价值 | 处理难点 |
|---|---|---|---|
| IM 沟通 | 钉钉、飞书等群聊与私聊记录 | 决策过程、责任人、口头约定 | 口语化、指代模糊、噪声高 |
| 文档 | 在线文档、本地文件、表格 | 正式结论、版本演进、数据口径 | 多版本并存，时效难判 |
| 会议 | 会议记录、日程、参会信息 | 议题边界、待办事项、时间点 | 记录不完整，与执行脱节 |
产出物是”专属工作档案”：一份按人、按项目、按时序组织的结构化上下文，附带来源指针——每条结论都能回溯到产生它的那条消息或那个文档段落。这是”可溯源”三个字的实际含义，也是它区别于简单 RAG 索引的地方。没有溯源，Agent 的错误就无法被追责；有了溯源，用户才有信心采用它的输出。
为什么”可溯源”是设计核心而非附加功能
办公场景的信息和 Wikipedia 不同：它有版本、有立场、有时间点。”预算是多少”这个问题在不同月份有不同答案，且都可能正确。若 Agent 只能给一个数字而说不清取自哪次会议纪要，用户只能自己去翻——AI 省下的时间又还了回去。
因此 MyContext 把关联性写进了数据结构：每条沉淀的信息都带着出处。这带来两个直接收益：一是答案可核验，二是可以反向做清理——当某个源头文档作废时，依赖它的结论能被标记待更新。
冲突怎么处理：不能靠模型自由心证
多源数据的必然结果是互相打架：群里说周三上线，文档写明周五；旧版方案标价 30 万，新版改成 45 万。这类冲突若交给模型自行取舍，等于把可靠性押在概率上。
按公开介绍口径，MyContext 的处理采用两条路线：语义分析自动判断，或交由用户确认。前者适合能从时间戳、来源权威性推断出答案的情形；后者用于歧义真实存在、语义分析没有把握的场景。把”何时该问人”写进系统规则，比事后提高模型准确率更可靠。
典型落地场景
自动回复工作信息
官方举例的场景是基于档案构建专属 Agent 助手，用于自动草拟工作回复。这类应用对上下文的依赖最重——回复语气、历史承诺、当前进度，缺一项就可能答错事情本身（而非答得不好看）。有档案托底，草稿才有可用性。
项目状态梳理
把散落在多个群里的讨论收敛成”现在进展到哪、卡点在哪、谁负责”的结构化摘要，是许多团队每周要做的重复劳动，也最适合交给持续更新的档案。
新人上手与交接
上下文档案天然是新人的入职材料。相比让人逐个群翻记录，一份带出处的项目脉络能大幅压缩上手时间。
与常见方案的取向对比
| 方案 | 上下文来源 | 数据位置 | 可溯源 | 适用 |
|---|---|---|---|---|
| 长上下文硬塞 | 每次会话临时拼材料 | 随请求上行 | 弱 | 一次性任务 |
| 云端知识库 RAG | 上传文档后建索引 | 云端 | 中（可有引用） | 文档型问答 |
| MyContext 类本地档案 | IM/文档/会议持续沉淀 | 本地 | 强 | 日常办公与流程性工作 |
三种方案并非替代关系。真正成熟的组合通常是：本地档案负责高频、持续的个人上下文；临时材料交给长上下文；公开资料走云端检索。
使用这类上下文基础设施要留意什么
数据范围要主动划定
接入 IM 意味着潜在可见范围极大。建议先限定到与工作直接相关的项目群与文档目录，宁可少接，也不要先全量再补救。
沉淀结果要定期复核
自动沉淀会累积错误解读，且错误会随着被引用而放大。保留”标记有误”的入口，并定期清理过期档案，是长期可用的前提。
明确自动回复的边界
草稿可以由 Agent 生成，发送最好留给人。尤其涉及对外承诺、金额、时间节点的回复，务必人工过一遍。
常见问题
Q1：MyContext 和普通的检索增强生成（RAG）有什么区别？
RAG 多在提问时临时检索相关片段，索引往往在云端、覆盖的多是文档。MyContext 的定位是持续性的上下文基础设施：它在本地持续运行，把 IM 沟通、文档、会议等多源数据沉淀成长期工作档案，并保留来源指针以便溯源。前者解决”这次问什么查什么”，后者解决”长期记住工作是怎么推进的”。
Q2：为什么强调本地化运行？
因为办公上下文天然敏感。群聊里讨论的是未公开的排期、报价、人事变动，文档里有客户资料与财务数据。本地化运行意味着这些内容的沉淀过程发生在本机，不必先上传建立云端索引，从架构层面缩小了数据暴露面。
Q3：信息互相冲突时会怎样处理？
按公开介绍口径，系统会通过语义分析做自动判断，或在无法确证时交由用户确认。这种设计把”不确定就别猜”写进流程，避免模型在多个版本之间自行取舍后给出一个看起来确定、实则随机的答案。
写在最后
上下文基础设施这类项目的共同特点是：发布时不会带来惊艳演示，却是决定上层 Agent 能否长期留存的关键。MyContext 把”记住工作”这件事从模型能力里剥离出来，变成了可管理、可溯源、可清理的本地资产——这大概是办公智能体走向实用所必经的一步。对企业与个人而言，值得关注的指标也很朴素：它沉淀的档案，你在翻看时能信几分。