从 MyContext 看 AI 办公 Agent 的上下文基建（local-first / 知识图谱 / 冲突处理）

文 / 刘家乐 · AI 工具落地培训师

开发者看千问办公开源的 MyContext，别只看「又一个 AI 记忆项目」的热闹，要看清它背后的工程判断：办公 Agent 的瓶颈不在模型，在上下文与记忆的组织方式。本文从架构视角拆解 MyContext 的设计，并附可复用的技术要点。

CSDN 封面 · 从 MyContext 看上下文基建

一、定位：local-first 的个人上下文层

MyContext（github.com/openTrinity/mycontext）是一个本地优先（local-first）的桌面应用，定位为「个人工作上下文层」。核心思路一句话：把散落在 IM、文档、会议、日历、审批、本地活动里的信号，持续整理成一份私有的、不断演进的「你」的画像——你懂什么、你和谁协作、你在忙什么。

数据默认落在本地磁盘的SQLite vault里，带版本化迁移（versioned migrations），不上云。

# 数据平面（示意） sources = [IM, Docs, Meetings, Calendar, Approvals, LocalActivity] # 多源采集 → 会话分块 → 向量化/实体抽取 → 知识图谱 # → 蒸馏为五类结构化结论 → 生成 Agent 可调用的 playbook

二、处理链路：从碎片到「可检索、可推理」的资产

MyContext 不是简单的「全文堆砌」，而是多步流水线：数据采集 → 会话分块 → 向量化 + 实体抽取 → 构建知识图谱 → 蒸馏为结构化结论 → 生成 playbook（执行手册）。

档案最终沉淀四类信息：职责范围、协作关系、行为习惯、工作讨论结论。每一条都可回溯到原始出处，标注来源、时间、内容——这一步是直接针对「AI 幻觉」的工程解。

三、冲突处理：比「取最新」更聪明

IM 里前后矛盾的信息，传统方案是「取最新」或「取置信度最高」，两者在 Agent 场景下都会丢信息。MyContext 的做法是：

# 冲突处理策略（示意） def resolve(conflict): if semantic_mergeable(conflict): # 语义分析可合并 return merge(conflict) if semantic_overridable(conflict): # 语义分析可覆盖 return override(conflict) return ask_user(conflict) # 拿不准 → 用户最终确认 # 用户确认过的结论，模型永远不能覆盖（锁定）

这套「合并 / 覆盖 / 人工确权」三段式，保证了长期数据不会越用越片面。

要点卡 · 开发者三条

四、安全设计：生成与发送分离

针对企业最关心的数据安全，MyContext 把「知识生成」和「信息发送」两个环节分离，数据默认存本机 SQLite、不强制上传云端；内置提示词注入防护，例如把输入中的换行替换为空格、清除 Markdown 图片链接，降低恶意指令污染知识库的风险。

五、给开发者的三点启示

①上下文是下一个工程方向：模型能力趋同后，谁能把「记忆」组织好，谁就拥有 Agent 的护城河。

②local-first 是隐私场景的刚需：涉密、财务、医疗类工作流，本地化 + 可溯源比云端大模型更吃香。

③冲突处理要有人工兜底：纯算法解决不了所有矛盾数据，「合并 / 覆盖 / 确权」的分级策略 + 用户最终确认，是长期记忆可靠的关键。

数据口径：MyContext 架构细节引自 8/17–8/18 公开报道与开源仓库说明（开发者预览阶段，接口可能破坏性变更）；MIT NANDA 报告、杰富瑞评测均为公开转引，选型请以官方文档为准。

你在做 AI 办公相关开发时，上下文/记忆这块是怎么处理的？本地向量库、还是别的方案？评论区交流踩坑经验。

尾图 · 能接住上下文才值钱