你构建了能研究、能思考、能编码的 Hermes Agent。困难的部分是将这些能力连接起来，让它能够判断什么重要、决定什么值得构建、并在没有人类介入的情况下完成构建。
这就是 Auto-think 和 Auto-build 的作用。
双循环架构
Auto-think 是想法摄入层。Research agent 向它提供证据。Dreamer agent 是将重复信号、压力、失败运行和研究含义转化为候选想法契约的模式识别器。
Auto-build 是验证构建循环。它将批准的工作通过 Main agent、Coder agent、QA agent、信任报告、保留审查和操作者视图推进。
关键分离在于：Auto-think 决定什么可能值得构建。Auto-build 决定什么可以构建、验证它，并留下收据。
角色分离：为什么工作不能模糊
实时架构有明确的角色分工：
| 角色 | 职责 |
|---|---|
| Research | 收集证据 |
| Dreamer | 识别信号，塑造候选想法 |
| Main | 审查想法，决定是否推进 |
| Coder | 仅实现已批准、有边界的工作 |
| QA | 独立验证 |
| Trust | 总结房间状态：干净/观察/调查 |
| Retention | 决定已完成产物保留/改进/搁置/修剪 |
| Operator | 查看控制室 |
当这些工作模糊时，系统就会变得鲁莽。这正是这套设置要防止的。
Buildroom：文件系统驱动的工作流
公共 buildroom 不是聊天转录。它是一个文件系统驱动的工作流房间。
目录结构：
hermes-buildroom/
docs/
architecture.md
lifecycle.md
operator-model.md
builder-guide.md
safety.md
retention.md
schemas/
research-input.schema.json
idea-contract.schema.json
intent-review.schema.json
main-review.schema.json
product-plan.schema.json
build-plan.schema.json
verification-report.schema.json
verification-delta.schema.json
trust-report.schema.json
retention-review.schema.json
operator-summary.schema.json
engine/
adapters/
dashboard/
evals/
export/
pipeline/
reviewers/
verification/
examples/
demo-room/
research/
ideas/
plans/
jobs/
verification/
trust/
retention/
operator/
tracks/
project-builder/
scripts/
validate_fixtures.py
run_demo_checks.py
start_demo_server.py
run_demo_verification.py
build_operator_summary.py
export_sanitized_bundle.py
buildroom 强制系统分离研究、想法、审查、计划、构建、验证、信任、保留和操作者报告。
契约链：从想法到产物的完整路径
1. 想法契约（Idea Contract）
从思考到构建的第一个持久交接。它捕获：
- 应该存在什么
- 谁受益
- 为什么是现在
- 什么证据支持它
- 什么超出范围
- 它可能存在于哪里
- 如何验证
这是"我有一个想法"和"系统可以审查这个"之间的区别。
2. 意图审查和 Main 审查
意图审查是早期过滤器。它检查想法是否准备好成为有契约支持的候选。Main 审查是批准关口。
示例 Main 审查产物：
{
"schema_version": 2,
"job_id": "20260421-0900-dreamer-demo-signal-bridge",
"reviewed_at": "2026-04-21T09:10:00Z",
"decision": "approved_for_coder",
"risk_band": "low",
"risk_score": 3,
"approved_by": "main",
"auto_approved": false,
"force_approved": false,
"block_reason": null
}
这个产物很重要。它证明构建没有直接从想法跳到执行。
3. 产品计划（Product Plan）
Main 批准后，Main 编写产品计划。这是 Coder 实际构建的依据。
产品计划包括：
- 允许的路径
- 计划文件
- 非目标
- 验证命令
- 验收检查
- 风险评估
- 受保护表面注释
Coder 不会收到"去改进系统"。Coder 收到的是有边界的工作。
4. 构建计划（Build Plan）
Coder 将产品计划转化为构建计划。构建计划是可执行包。
目标不是仪式。目标是让 Coder 有有界的包，让 QA 有具体可验证的东西。
5. QA 独立验证
QA 默认不信任 Coder 的摘要。它阅读计划、实现、变更文件和验证收据。然后它编写自己的收据。
验证增量有明确状态：
- confirmed：Coder 和 QA 证据一致
- drift：存在偏差
- regression：出现退化
- missing_evidence：证据不足
这是系统最强的部分之一。它不仅问"测试通过了吗？"它问 Coder 证据和 QA 证据是否一致。
6. 信任报告（Trust Reporting）
验证检查一次构建。信任报告检查整个房间。信任状态：
- clean：房间干净
- watch：需要观察
- investigate：需要调查
操作者不应该必须阅读每个原始收据才能知道该看哪里。信任报告压缩房间而不隐藏不确定性。
7. 保留审查（Retention）
构建完成并不意味着它应该永远存在。保留审查问产物应该：
- keep：保留
- improve：改进
- park：搁置
- prune：修剪
保留在公共提取中是仅建议的。它可以推荐应该发生什么，但不会静默删除或移动实时产物。
完整循环
- Research 收集证据
- Dreamer 将信号塑造成候选想法契约
- 意图审查过滤弱或不安全的想法
- Main 审查契约
- Main 编写有边界的产品计划
- Coder 准备构建计划
- Coder 在允许路径内实现
- Coder 记录验证
- QA 独立验证
- 增量比较 Coder 和 QA 证据
- 信任报告总结房间健康度
- 保留推荐什么存活
- 操作者看到控制室
护栏：为什么每个限制都很重要
- Dreamer 不允许批准自己的构建 — 防止自我欺骗
- Dreamer 不允许突变受保护的工作流表面 — 防止破坏系统
- Coder 不允许静默扩大范围 — 防止范围蔓延
- QA 不允许橡皮图章 Coder 输出 — 防止验证失效
- Retention 不允许自行删除实时状态 — 防止意外丢失
- 控制室不是隐藏不确定性的借口 — 保持透明
每个有意义的构建都应该留下收据。
真正的教训
大多数 Agent 系统的第一个版本是关于产生更多输出。更好的版本是关于复利判断。
这意味着系统能够区分：
- 有趣的信号 vs 构建候选
- 潜意识回归 vs 批准的计划
- 弱声明 vs 验证的证据
- Coder 收据 vs 独立验证
- 完成的产物 vs 值得保留的东西
这就是 Agent 开始感觉不那么像提示链，而更像操作系统的地方。
它们有边界、记忆、状态、审查、收据，以及一种从思考移动到构建的方式——而不假装每个想法都值得执行。
如何开始构建
不要从给 Agent 做所有事情的权限开始。从契约链开始。
- 创建一个本地 buildroom
- 添加 schemas
- 添加一个研究包
- 添加一个想法契约
- 让 Main 审查它
- 让 Main 编写产品计划
- 让 Coder 仅在允许路径内构建
- 让 QA 独立验证
- 比较收据
- 编写信任报告
- 编写保留审查
- 渲染操作者摘要
最小有用版本可以是本地和无聊的。它不需要实时 cron、私有配置文件、浏览器自动化或第一天的仪表板。它只需要按顺序产生文件并证明交接有效。
这就是整个模式。普通 Agent 回答面前的提示。更好的 Agent 记住发生了什么。在这种情况下，Research agent 构建证据库，Dreamer 注意到什么持续回归，Auto-think 和 Auto-build 将复利智能转化为有收据的验证工作。