仓库中心智能体栈

以下来自 @yoheinakajima 提出的一种模块化智能体工作架构，核心主张只有一句：

传统交互模式是这样的：

复制human → prompt → agent → output → human

大部分工作上下文都保留在会话内部，人类在不同工具、模型和对话之间承担着连续性衔接的角色——你是人肉搬运工。

而作者的架构更接近：

复制human ↔ Chief of Staff ↔ project managers ↔ workers / reviewers ↔ shared project state

核心的分离在于持久化的项目状态与可替换的执行组件：模型、智能体、工具、界面和会话都可以变更，而仓库保留项目的状态、规则、证据、决策、历史记录以及验证机制。

在此设置中，GitHub 的功能远不止代码托管——仓库成为共享操作环境，人类与多个智能体通过它协作处理同一项目。仓库里可能包含：源代码、规范说明、架构图、议题、研究主张、源指针、实验运行记录、决策记录、验收标准、队列、测试用例、审批状态、工具策略、机器可读的元数据。

关键问题不在于是否保留了所有上下文信息，而在于：一个具备能力的新智能体，能否重建项目的运行状态？作者列了 10 项检查清单：

1. 项目的目标与当前阶段；
2. 已接受的状态及其证据基础；
3. 源层级与规范记录；
4. 此前的尝试与重大失败；
5. 决策及其未解决的影响；
6. 开放问题、阻塞与依赖；
7. 不变量、权限与审批边界；
8. 可用角色与工具；
9. 下一个有界的工作单元；
10. 评估拟议变更的机制。

作者明确说：不试图保留每个模型生成的每一个词元——大多数对话内容只是脚手架。持久化的信息集中在状态转换中，有 4 种标准记录格式：

复制decision → evidence → resulting state → unresolved implications
hypothesis → experiment → observation → result → confidence
task → implementation → verification → artifact
failure → diagnosis → newly discovered constraint

这些记录是结构化的线索：压缩了工作的物质轨迹，而无需未来的智能体重放整个对话。优化目标不是穷尽记忆，而是低成本、可靠的延续。

仓库区分底层记录及其生成的视图：

投影可能会过时或不完整，其价值在于能追溯到更持久的基底，从而得以再生、比较或质疑。

这是作者从 ActiveGraph 借来的架构模式：

复制event history → projection logic → current state

把底层历史视为首要数据，可提供重放、溯源、谱系、分支、轨迹对比，以及重构"特定状态为什么存在"的原因。这也使得当前解读与产生该解读的证据和事件得以分离。

较小的项目不用真的跑 ActiveGraph——Git、结构化文件、确定性脚本、测试和规范的提交历史就能实现相同的状态模型。在更丰富的项目中，仓库本身可以成为显式关系的 ActiveGraph：

复制people → agents → tasks → events →
claims → experiments → artifacts →
decisions → sources → results → open questions

一旦这些关系明确，系统就能回答实用的操作性问题：哪些结论依赖一个有争议的假设？哪些实验支持某个主张？哪个决策改变了发展轨迹？哪些结果已被独立复现？

智能体行为由多个不同的指令层构成，而非编码在一个大型提示中。有效的指令堆栈大致为：

复制global operating rules + role skill + project contract + current task

根指令文件保持精简，只做索引：

复制work type X → load contract A
state class Y → load policy B
generated artifact Z → apply validation procedure C

Codex、Claude、Cursor、ChatGPT 等工具的指令文件只放适配器信息和路由逻辑，而不是项目规则的独立副本——规范策略只在一处，避免语义漂移。重要规则的变更本身也是项目变更：可追溯、可评审、进历史，而不是通过更新提示词悄悄引入。

模型经由薄适配器进入

作者用 ChatGPT、Codex、Claude、Replit、本地 agent、GitHub 原生自动化等不同接口，但不把每个接口当独立的机构记忆。每个模型经由薄适配器（thin adapter）进入同一项目，适配器确立：智能体身份与角色、可用工具与凭证、读写权限、规范指令入口、相关项目/任务上下文、记录结果的机制。

持久状态提供连续性，但不产生推进力。执行层用有界心跳（heartbeats）：短控制循环，智能体醒来 → 对账状态 → 认领一个有界工作单元 → 执行/委派 → 验证并记录状态转换 → 退出。

一次典型心跳的结构：

复制identify role and authority
→ inspect assignments, approvals, and changed state
→ reconcile current state against project objectives
→ select or claim one bounded unit of work
→ execute or delegate
→ verify and record the resulting state transition
→ exit

有界的执行窗口减少对长寿上下文的依赖，也限制未记录假设的堆积——项目状态在心跳之间承载连续性。

不同角色在不同分辨率上运行，形成层级：

复制Chief of Staff heartbeat
→ determine which projects require attention

Project Manager heartbeat
→ determine the next useful project-level action

Worker / Researcher heartbeat
→ execute bounded work

Reviewer / Verifier
→ evaluate the resulting artifact or claim

Repository
→ record the accepted state transition

心跳可以定时、事件触发或手动调用，共同点是在有界的执行范围内反复做状态对账。

Chief of Staff 只做注意力路由：它看的是组合层面的小投影（活跃项目与目标、当前阶段与负责人、最新实质状态变更、阻塞与过期工作、待审批、未决决策、建议的下一步、健康度指标），不把每个项目的内部上下文吸进一个中央提示词——避免把顶层协调者变成第二套记录系统。

多智能体执行在什么时候变得不可靠？当每个智能体不经独立检查就继承上一个智能体的结论时。

在这个架构里，验证是状态转换机制的一部分：

复制agent proposes change → verifier evaluates contract → accepted state changes

生成与接受是分离的操作。这一点在智能体能修改自己的工作流、指令、评估器或编排逻辑时尤其重要：自修改不因为"修改者报告成功"就被接受，结果状态要对照修改范围之外的不变量、或由独立授权的验证者来评估。

验证也适用于研究与推理产物。一个 claim 不是一句话，而是一个带溯源链的状态对象：

复制claim
← evidence
← source or experiment
← method and version
← run or artifact
← assumptions
← producing agent or action
← confidence and epistemic status

显性认知状态

仓库不把智能体产出的所有材料坍缩成单一的"已知"，而是区分知识类别。记录可以携带以下状态：

复制proposed / observed / reproduced / accepted / disputed /
superseded / unresolved / inferred / source-backed / speculative

置信度、权限、敏感度、证据基础也可以保持显式。这很重要：进来的智能体需要区分已验证的不变量、临时解释、未解决的冲突、不受支持的假设，也防止 polished 的综合悄悄替换掉它所基于的较弱证据。

系统里的角色（builder、researcher、reviewer、verifier、auditor、PM、Chief of Staff）首先不是人设，而是可执行的操作合同。一份角色合同规定：

1. 读哪个状态；
2. 负责回答哪些问题；
3. 能做哪些决策；
4. 能调哪些工具；
5. 能改哪些状态；
6. 必须产出哪些制品；
7. 必须记录哪些证据；
8. 何时必须升级；
9. 什么算完成。

例如：builder 可以实现有界变更，但无权改验收标准；reviewer 可以检查和挑战制品，但不能修改它；verifier 对照确定性合同评估拟议的状态转换。

每次会话产出"状态增量"

一次完成的智能体会话产出的不只是直接要的制品，还有可读的状态增量（state delta）：实现、测试、实验证据、更新的主张、决策记录、新发现的约束、失败的尝试、源指针、未解决问题、置信度变化、有界的下一步。

复利循环：

复制execute → record clues → update state → verify → continue from the new state

这改变了重复使用智能体的经济学：上下文加载越来越便宜，因为此前的工作以环境的形式存在，而不是每次靠人工简报重建。

整个架构一句话总结（来自原文）：

复制project substrate
=
canonical state
+ derived projections
+ layered instructions
+ role contracts
+ model adapters
+ bounded heartbeats
+ verification
+ provenance
+ human governance

模型提供可变的推理与执行能力；仓库提供连续性；技能与合同提供操作行为；心跳提供推进力；验证与溯源提供信任；PM 本地协调；Chief of Staff 跨项目分配注意力；人的判断改变其余部分运作的目标与约束。