我们要为多人、多个异步工作的本地 Agent 建一套共享上下文系统：业务原件在现有文件库中，Agent 需要按项目、角色、当前任务和权限只取少量相关内容。原文、结构化事实、AI 提炼、检索索引、个人工作记忆如何分层？多人修改同一事实时，如何处理版本、冲突、失效、回读，并避免每次把整库塞进上下文？请给出最小可行架构、先后建设顺序，以及最容易踩的坑。
提问
把共享上下文分成工作记忆、项目记忆、组织记忆三层，原件留在文件库，索引只做定位，Agent 按任务渐进加载；多人改同一事实时用版本化文件加审批门，而不是每次塞整库。
三层记忆加原件库，索引只负责找路
立正团队交付的 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 回读时先看版本是否一致。
最小可行架构与建设顺序
AI推演按原文的落地顺序，先画概念层：列出 context 散落在哪些地方、彼此什么关系、哪些日常调用、哪些长期沉淀、哪些定期提炼1。这一步不写代码，但决定后面索引怎么建。
第二步搭技术层的最小版：一个文件库放原件，一个版本库放结构化事实和提炼物，一份索引记录项目、角色、权限和来源版本，一套加载规则按任务取工作记忆。第三步才是工具链：接文档系统和项目管理工具做自动采集，配置 AGENTS.md、MEMORY.md 让每个 AI 入口自动加载组织级 context1。提炼可以晚做，先保证原件可追溯、索引可定位。
最容易踩的坑有两个。一是把整库塞进上下文，原文明确说会撑爆，且 subagent 应拿简明自洽的目标和必要上下文，而不是默认继承整个漫长历史1,3。二是让 AI 在没有审批门的情况下直接改对外内容，立正那次事件里内容本身没问题，问题在流程2。
提供的片段只给出分层原则、Git 版本管理和审批门的做法，没有具体的数据模型、冲突合并规则或索引实现细节；这些需要结合你们现有文件库的权限模型另行设计。
回到3份原文
给出三层记忆、渐进式加载、持续提炼和 Git 版本管理的完整框架，是架构主依据。
具体说明 Agent 越权发布后加 approval gate 并写入 AGENTS.md 的处理方式。
说明 subagent 应拿简明上下文而非继承全部历史，支持避免整库塞入。