多智能体协作里，项目仓库如何成为可替换执行组件的持久底座

多数人构建智能体系统时，默认把一次对话、一个IDE会话或者某个模型当成工作的中心。上下文、决策、证据和未完成的任务，全堆在临时窗口里。人成了唯一的记忆搬运工，模型一换、会话一关，整条线索就断。我起初也觉得只要把prompt写得足够长、把历史摘要做得足够精，就能撑住复杂项目。后来在实际跑多仓库、多角色的长期任务时发现，真正能让不同模型、不同工具、不同人随时接手的，不是更长的上下文，而是一个能被任何新进入者快速读懂的持久项目状态。

这个状态的载体，是被当作治理仓库的Git仓库本身。它不只是放代码的地方，而是人类和多个智能体共同进入的共享操作环境。里面可以同时放源码、规格、schema、issue、研究主张、实验记录、决策对象、验收标准、队列、测试、生成投影、审批状态、工具策略和机器可读元数据。关键标准只有一条：一个能力合格的新智能体，能不能在几乎没有先验知识的情况下，进入仓库、判断当前状态、承担有限角色、完成一段工作、验证结果，然后留下清晰的状态转移，供下一个人或智能体接手。

传统交互模型把大部分工作上下文留在会话里，人负责在工具、模型和对话之间传递连续性。新的架构反过来：持久项目状态与可替换的执行组件彻底分离。模型、智能体、工具、界面、会话都可以换，仓库则保留项目的状态、规则、证据、决策、历史和验证机制。输出不再只是对话文本，而是结构化事件、产物、决策、主张、实验、测试结果或带谱系的状态转移。这样未来的智能体不必重放整段对话，只需读取压缩后的线索，就能低成本可靠地继续。

仓库内部明确区分规范层与投影层。规范层是Git历史、追加式事件、已接受记录、决策对象、源引用、不可变运行产物、实验输出、已验证主张等耐久状态转移。投影层是从规范层生成的方便视图：README摘要、当前状态页、仪表盘、队列、索引、任务列表、报告、简报、为智能体准备的上下文包。投影可以过时或不完整，但它的价值在于始终可追溯到更耐久的基底，随时能被重新生成、对比或质疑。这种“底层记录优先、当前视图只是投影”的思路，正是ActiveGraph当初的核心模式。即使小项目不跑完整的ActiveGraph运行时，也可以用Git、结构化文件、确定性脚本、测试和纪律化的提交历史实现同样的状态模型。一旦关系显式化，系统就能回答更有用的操作问题：哪些结论依赖有争议的假设，哪些实验支撑某条主张，哪次决策改变了轨迹，哪些开放问题阻塞了最多下游工作。

智能体行为不再塞进一个巨大prompt，而是由几层独立指令叠加而成。全局操作层是跨项目相对稳定的不变量：保留谱系、区分证据与推断、把密钥留在prompt和仓库之外、显式表示不确定性、对有后果的动作要求适当授权、优先使用耐久项目状态而不是隐藏的对话记忆。角色层是可复用的操作规程：评审者有评审协议，研究者有源处理、实验设计、主张形成和不确定性处理的方法，项目经理有状态协调与委派循环，验证者有定义好的证伪或接受程序。项目契约是仓库特有的信息：使命、本体、源层级、规范状态边界、不变量、schema、角色定义、工具权限、变更边界、审批策略、验收标准、升级规则、完成定义。任务上下文则是最窄、最临时的一层：当前目标、相关文件、近期变更、依赖、约束、请求输出、截止或审批状态。这种分离让同一个评审者或研究者技能可以跨多个仓库运行，而不强迫仓库共享同一套schema。项目特有的真相留在本地，通用操作方法可以复用。

当项目变得持久后，初始引导阶段会建立最小可行操作环境：项目简报、规范源边界、主要不变量、验收标准、权限、阶段结构、路由指令。根智能体指令文件保持相对紧凑，它只是指向更具体契约的索引。不同工具的适配器文件只放路由逻辑，不复制项目规则，避免语义漂移。重要规则的变更本身也作为项目变更被记录、可审查、可追溯，而不是通过更新prompt悄悄引入。

模型通过薄适配器进入同一项目。适配器只负责建立连接：有文件系统权限就直接读仓库，只有远程权限就走GitHub或其他结构化连接器。它不维护自己的项目真相版本，只是把模型接到已有状态和契约上。这样模型替换几乎不破坏连续性——Claude会话不必保留Codex看不到的知识，某个Codex对话也不会成为架构决策的唯一持有者。耐久知识被外化到项目环境里。

角色本身是可执行的操作契约，而不是人格。契约定义权限边界、输入输出格式、验证义务、允许的变更范围。构建者可以实现有限变更，但无权改验收标准；评审者可以检查和质疑产物，但不能直接修改；验证者可以对照确定性契约评估提议的状态转移；项目经理可以创建和排序任务并委派实现；审计者可以检查谱系、策略合规和真相源完整性，却不参与日常执行。可互换性来自把项目记忆和角色行为都外化——模型提供推理与执行能力，仓库和角色契约提供制度上下文、权威与程序。

持久状态提供连续性，但不会自动产生运动。执行层使用有界心跳：智能体醒来、协调状态、完成有限工作、记录结果、然后退出。典型心跳结构是状态协调 → 有限执行 → 结果记录 → 退出。有界窗口降低对长寿上下文的依赖，也限制未记录假设的积累。项目状态在心跳之间承载连续性。不同角色在不同分辨率上运作：窄智能体可以在具体实现或研究任务里做更深的工作，宽智能体用更浅的循环，因为它们的责任是协调而非直接执行。

每个耐久仓库可以有一个项目经理角色，负责解释本地状态、排序工作、识别阻塞、委派给专用智能体、协调已完成输出。项目经理对本地上下文的访问比首席幕僚更深，它的操作知识通过项目契约、状态记录、决策、issue和任务图留在仓库内。首席幕僚则通过更小的组合投影跨项目运作，它不把每个项目的内部上下文吞进一个中心prompt，只负责路由注意力。当某个项目需要更深分析时，它委托给该仓库的项目经理，由后者对着本地状态和契约工作。这样顶层协调者不会变成第二个真相系统，也不会变成越来越脆弱的全局上下文窗口。

多智能体执行最容易出问题的地方，是每个智能体无条件继承前一个智能体的结论。验证因此被做成状态转移机制的一部分。根据项目需要，验证可以通过schema、类型系统、测试、CI、确定性校验器、允许路径规则、状态转移约束、校验和、预注册实验谓词、独立复现或结构化评审来实现。生成与接受在错误状态转移成本足够高时被分开。当智能体可以修改自己的工作流、指令、评估器或编排逻辑时，自修改不能仅仅因为修改者报告成功就被接受。结果状态必须对照修改范围之外的不变量，或由独立授权的验证者评估。

仓库还会显式区分不同认知状态的知识，而不是把所有智能体生成的材料都压成“已知”。记录可以带有已验证不变量、临时解释、未解决冲突、无支撑假设等状态，置信度、权威、敏感性和证据基础也可以保持显式。这样新进入的智能体就能立刻区分什么是可靠的、什么是临时的、什么是有争议的，避免一篇漂亮的综合悄悄取代它背后更弱的证据。

人类的角色从手动搬运上下文，转向系统里最难形式化的部分：目标、优先级、品味、约束、歧义消解、有后果的审批、方向变更。首席幕僚和项目经理把这些输入点暴露出来。当人类决策的影响超出当前会话时，它变成耐久项目记录，随后影响未来任务、审批、验收标准和智能体行为，而不需要在每个会话里重新陈述。人仍然是控制架构的一部分，但不再是项目记忆的传输层。

一次完成的智能体会话产出的，不只是即时请求的产物，还有可读的状态增量。增量可能包括实现、测试、实验证据、更新主张、决策记录、新发现的约束、失败路径、源指针、未解决问题、置信度变化或有界下一步行动。复利循环因此变成：加载项目状态 → 有界执行 → 写入状态增量 → 下一轮更便宜的上下文加载。先前的工作被表示在环境里，而不是反复通过人工简报重建。

可以把整套架构压缩成一句话：模型提供可变的推理与执行容量，仓库提供连续性，技能与契约提供操作行为，心跳提供运动，验证与谱系提供信任，项目经理做本地协调，首席幕僚跨项目分配注意力，人类判断改变目标和约束。下面这张表把传统会话中心做法和这种仓库中心做法直接对照。

仓库像一座城市的永久档案室，而不是每天开会的临时白板。心跳则像工厂的班次交接：每一班只负责有限窗口内的工作，却把完整状态留给下一班。角色契约像岗位说明书，规定权限边界和验证义务，而不是给智能体贴性格标签。

如果你已经在跑多智能体系统，最值得立刻检查的，是当前项目的“规范层”是否真的存在、是否足够让一个全新智能体在五分钟内读懂状态并安全动手。或者你正在用的某个长对话，有多少关键决策其实只活在聊天记录里、一旦关闭就永久丢失？欢迎直接说你现在的卡点，我们可以对照实际架构一起拆。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。