我当前受 @activegraphai 启发，对模块化、以仓库为中心的智能体操作系统的尝试 https://t.co/dRba7xv6ZE

构建以仓库为中心的模块化智能体技术栈

我一直在探索一种用于智能体工作的模块化架构，其中持久化的单元是项目，而不是模型、对话、IDE 会话或单个智能体。

项目以受治理的仓库形式表示，其中包含足够的操作状态，使人类或智能体能够在最少的先前上下文下进入，确定当前状态，承担限定角色，执行工作，验证结果，并为下一个进入者留下清晰的状态转换。

传统交互模型大致为：

人类 → 提示 → 智能体 → 输出 → 人类

大部分工作上下文保留在会话内部。人类在工具、模型和对话之间延续连续性。

我当前的架构更接近：

人类 ↔ 幕僚长 ↔ 项目经理 ↔ 执行者/审查者 ↔ 共享项目状态

核心分离在于持久的项目状态和可替换的执行组件。模型、智能体、工具、接口和会话都可以更换。仓库保留项目的状态、规则、证据、决策、历史和验证机制。

该架构在特定意义上是受 ActiveGraph 启发的：底层记录是首要的，而当前视图是该记录上的投影。应用到智能体工作中，这意味着有用的输出不仅停留在对话文本中，而是变成结构化的事件、工件、决策、声明、实验、测试结果或状态转换，并带有足够的溯源信息以供日后检查。

仓库作为项目基座

在这种设置中，GitHub 不仅仅是一个代码托管平台。仓库是共享的操作环境，人类和多个智能体通过它与同一个项目进行交互。

根据项目的不同，仓库可能包含源代码、规范、模式、问题、研究声明、来源指针、实验运行、决策记录、验收标准、队列、测试、生成的投影、审批状态、工具策略和机器可读的元数据。

关键问题不在于每一段上下文是否都被保留，而在于一个有能力的新智能体是否能够重建项目的操作状态：

‣ 项目的目标和当前阶段； ‣ 已接受的状态及其证据基础； ‣ 来源层级和权威记录； ‣ 先前的尝试和重大失败； ‣ 决策和未解决的后续影响； ‣ 未决问题、阻塞项和依赖； ‣ 不变量、权限和审批边界； ‣ 可用的角色和工具； ‣ 下一个有界的有用工作领域； ‣ 评估提议变更的机制。

聊天作为临时工作记忆仍然有用，但它不是权威的项目记录。

我并不试图持久化每个模型生成的每一个 token。大多数对话内容都是脚手架。持久的信息集中在状态转换中，例如：

决策 → 证据 → 结果状态 → 未解决的后续影响 假设 → 实验 → 观察 → 结果 → 置信度