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

文 / 刘家乐 · AI 工具落地培训师开发者看千问办公开源的 MyContext别只看「又一个 AI 记忆项目」的热闹要看清它背后的工程判断办公 Agent 的瓶颈不在模型在上下文与记忆的组织方式。本文从架构视角拆解 MyContext 的设计并附可复用的技术要点。CSDN 封面 · 从 MyContext 看上下文基建一、定位local-first 的个人上下文层MyContextgithub.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 办公相关开发时上下文/记忆这块是怎么处理的本地向量库、还是别的方案评论区交流踩坑经验。尾图 · 能接住上下文才值钱