我们要为多人、多个异步工作的本地 Agent 建一套共享上下文系统：业务原件在现有文件库中，Agent 需要按项目、角色、当前任务和权限只取少量相关内容。原文、结构化事实、AI 提炼、检索索引、个人工作记忆如何分层？多人修改同一事实时，如何处理版本、冲突、失效、回读，并避免每次把整库塞进上下文？请给出最小可行架构、先后建设顺序，以及最容易踩的坑。

立正团队交付的 Context Architecture 把 context 分三层记忆：工作记忆是当前任务直接需要的，项目记忆是这个项目积累的经验和决策，组织记忆是跨项目的长期知识；同时规定什么保留原始形态、什么提炼成精华、什么定期清理⁠1。这正好对应你问的分层：业务原件留在现有文件库，属于原始 context；结构化事实和 AI 提炼是从原件加工出的项目记忆与组织记忆；检索索引不是内容层，只记录“哪份原件、哪段提炼、属于哪个项目角色”，供 Agent 定位。

加载方式上，原文强调渐进式加载：不能一股脑塞进 context window，也不能什么都不给，核心是让 AI 执行任务时自动找到并加载需要的那部分，不多不少，这需要建索引、做分类、设计加载策略⁠1。所以“按项目、角色、任务、权限只取少量”不是靠一次大检索，而是先按项目与权限缩小范围，再按任务取工作记忆，必要时回查原件。个人工作记忆可以单独放一层，只对该 Agent 可见，不进入共享事实层。

立正提到用 Git 做 context 的版本管理和持久化存储，并把规范写成 AI 能理解的规则注入工作流⁠1。对多人异步改同一事实，这给出最小做法：结构化事实以文件形式进版本库，每次修改留下 diff 和提交人，冲突在合并时暴露，而不是靠口头同步。

权限边界上，立正在一次 Agent 未经同意就对外发布社区帖后，没有选择收紧权限，而是加 approval gate：所有对外内容都需要他批准，并让 AI 更新 AGENTS.md 写入这条规则⁠2。这是他对具体事件的判断，可迁移的是：有外部后果的写入要设审批门，内部读写可以放开。失效与回读则靠“提炼物标注来源原件和版本”，原件变了就标记提炼过期，Agent 回读时先看版本是否一致。

按原文的落地顺序，先画概念层：列出 context 散落在哪些地方、彼此什么关系、哪些日常调用、哪些长期沉淀、哪些定期提炼⁠1。这一步不写代码，但决定后面索引怎么建。

第二步搭技术层的最小版：一个文件库放原件，一个版本库放结构化事实和提炼物，一份索引记录项目、角色、权限和来源版本，一套加载规则按任务取工作记忆。第三步才是工具链：接文档系统和项目管理工具做自动采集，配置 AGENTS.md、MEMORY.md 让每个 AI 入口自动加载组织级 context⁠1。提炼可以晚做，先保证原件可追溯、索引可定位。

最容易踩的坑有两个。一是把整库塞进上下文，原文明确说会撑爆，且 subagent 应拿简明自洽的目标和必要上下文，而不是默认继承整个漫长历史⁠1,3。二是让 AI 在没有审批门的情况下直接改对外内容，立正那次事件里内容本身没问题，问题在流程⁠2。