如何构建一个能自主发现重要工作并完成构建的 Hermes Agent

你构建 Hermes Agent 的目的是为了进行研究、思考和编码。最难的部分在于将这些组件连接起来，使其能够自行判断哪些事情重要、决定哪些值得构建，并在无需人工干预的情况下完成构建。

这正是 Auto-think（自动思考）和 Auto-build（自动构建）的作用所在。

在此架构中，Auto-think 是创意摄入层。你的 Research agent（研究代理）向其提供证据。Dreamer agent（造梦者代理）是一个模式识别器，它将重复的信号、压力、失败的运行记录以及研究结论转化为候选创意合约（candidate idea contracts）。

Auto-build 是经过验证的构建循环。它将批准的工作通过你的 Main agent（主代理）、Coder agent（编码代理）、QA agent（质量保证代理）、信任报告、留存机制以及操作员视图进行流转。

关键的分界点在于：Auto-think 决定什么可能值得构建。Auto-build 决定什么可以被构建，对其进行验证，并留下记录（receipts）。

本指南旨在作为所有 Agent 的模板，因此你可以将 Hermes、OpenClaw 或其他 Agent 指向此处，让它们构建类似的工作流。

参考实现

在我的实现中，有两个相互连接的部分。可复用的公共构建室（buildroom）位于 /buildroom。

这是公开安全的 Auto-think / Auto-build 提取内容。它包含文档、Schema（模式）、演示房间示例、验证脚本、仪表板资产和测试套件。

运行时（runtime）位于此处的 /agent-runtime。

这是主要的 Hermes Agent 软件。它包括运行时控制室适配器、Web API 端点，以及一个 React 控制室 UI，当 ~/hermes 下存在私有运行时配置文件时，它可以读取实时的 Hermes 状态。

因此，构建室是模板和证明包。运行时则是能够显示和协调整个实时系统的软件界面。

当前架构

实时架构具有分离的角色。

• Research（研究）收集证据。
• Dreamer（造梦者）注意信号并塑造候选创意。
• Main（主代理）审查创意并决定是否继续进行。
• Coder（编码代理）仅实现经过批准且范围受限的计划。
• QA（质量保证）独立进行验证。
• 信任报告总结房间状态是清洁（clean）、监控（watch）还是需调查（investigate）。
• 留存（Retention）决定完成的工件应当保留、改进、搁置还是修剪。
• 操作员查看控制室。

当这些职责变得模糊时，系统就会变得鲁莽。这正是此架构设计旨在防止的情况。

构建室（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

构建室强制系统将研究、创意、审查、计划、构建、验证、信任、留存和操作员报告分离开来。

在实时 Agent 设置中，构建室通常与私有运行时状态分开。构建室包含可复用的合约、Schema、演示包、收据和操作员摘要。

私有运行时状态可能位于其他位置，具体取决于你的 Agent 系统：

your-system/
  profiles/
    research/
    dreamer/
    main/
    coder/
    qa/
  state/
    tracks/
    events.jsonl
    approval-ledger.jsonl

公共构建室不应依赖于这些私有路径。相反，它应该提供安全的固定数据（fixtures）和演示包。这正是该模式可复用的原因。

研究之门

Auto-think 不直接刮取世界数据。Research 拥有研究通道。它可以产生结构化证据、摘要、监控项目、提供者健康状况和每日输出。

在实时实现中，仪表板可以从该系统的运行时配置文件读取研究状态。在公共构建室中，安全版本由 examples/demo-room/research/research-input.json 等文件表示。

Research 收集证据。Dreamer 决定证据是否具有足够的形态以成为候选项。这是两个不同的工作。

如果你还没有设置 Research Agent，请参考我之前的指南：

[Graeme@gkisokay · 5月4日 文章] 我运行了6个AI Agent。只有这一个让其他5个变得更聪明。这是大多数构建者跳过的 Agent。它将外部世界转化为复利式的智慧。在3个月内，它在16个主题上记录了8,000多条证据，我堆栈中的每一个其他 Agent……

造梦者之门（The Dreamer Door）

Dreamer 是 Hermes 内部对 Auto-think 通道的称呼。

Dreamer 读取研究数据包、系统压力、失败运行、QA 缺口、留存状态和操作员压力。它可以产生候选创意合约。

但 Dreamer 不会批准自己的工作。这是关键的护栏。

Dreamer 的信号不是任务。构建意图不是批准。重复出现的创意并不自动意味着值得构建。

Dreamer 可以说：“这里有热度。” Main 决定这种热度是否真实。

要构建一个 Dreamer Agent，请参考我之前的指南：

[Graeme@gkisokay · 4月3日 文章] 我给了我的 Hermes + OpenClaw Agents 一个潜意识，现在它们全天候做梦 | 完整指南 你构建了 Hermes 和 Openclaw Agent 来运行你的工作流，但你创建的工作流越多，你改善它们的时间就越少。 这就是 Dreamer Agent 的作用。 就像人类的……

创意合约（The Idea Contract）

创意合约是从思考到构建的第一个持久化交接点。

它捕获：

• 应该存在什么
• 谁受益
• 为什么是现在
• 支持它的证据是什么
• 什么不在范围内
• 它可能存在于哪里
• 如何验证

在构建室中，这存在为：

examples/demo-room/ideas/idea-contract.json
examples/demo-room/jobs/demo-signal-bridge/idea-contract.json
schemas/idea-contract.schema.json

这就是“我有一个想法”与“系统可以审查此内容”之间的区别。

意图审查和 Main 审查

构建室同时具有意图审查和 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
}

这个工件很重要。它证明了构建没有直接从想法跳到执行。

产品计划（The Product Plan）

一旦 Main 批准了工作，Main 就会编写产品计划。这是 Coder 实际构建的对象。

产品计划包括：

• 允许的路径
• 计划中的文件
• 非目标
• 验证命令
• 验收检查
• 风险评估
• 受保护表面的注释

在构建室中：

examples/demo-room/plans/product-plan.json
examples/demo-room/jobs/demo-signal-bridge/product-plan.json
schemas/product-plan.schema.json

Coder 接收到的不是“去改进系统”。Coder 接收到的是范围受限的工作。

构建计划（The Build Plan）

Coder 将产品计划转化为构建计划。构建计划是可执行数据包：

examples/demo-room/plans/build-plan.json
examples/demo-room/jobs/demo-signal-bridge/build-plan.json
schemas/build-plan.schema.json

目标不是仪式。目标是让 Coder 有一个范围受限的数据包，并让 QA 以后有具体的东西可以验证。

QA Agent 验证

在公开文章中，你可以将其称为 QA。

QA 默认不信任 Coder 的摘要。它读取计划、实现、更改的文件和验证收据。然后它编写自己的收据。

构建室包括 Coder 验证和 QA 验证：

verification.json
qa-verification.json
verification-delta.json

验证差异具有明确的状态：

• confirmed（已确认）
• drift（偏离）
• regression（回归）
• missing_evidence（证据缺失）

这是系统中最强大的部分之一。它不仅问“测试是否通过？”，还问 Coder 的证据和 QA 的证据是否一致。

信任报告（Trust Reporting）

验证检查一次构建。信任报告检查整个房间。信任状态是：

• clean（清洁）
• watch（监控）
• investigate（调查）

在构建室中：

examples/demo-room/trust/trust-report.json
schemas/trust-report.schema.json

操作员不应该必须阅读每个原始收据才能知道该看哪里。信任报告压缩了房间状态，而不隐藏不确定性。

留存（Retention）

构建完成并不意味着它应该永远存在。留存询问工件是否应该：

• keep（保留）
• improve（改进）
• park（搁置）
• prune（修剪）

在构建室中：

examples/demo-room/retention/retention-review.json
examples/demo-room/retention/report.json
schemas/retention-review.schema.json
schemas/retention-report.schema.json

在公开提取中，留存仅为建议性质。它可以建议应该发生什么，但它不会静默删除或移动实时工件。

操作员视图（The Operator View）

操作员视图是面向人类的界面。在公共构建室中，这是：

examples/demo-room/operator/operator-summary.json
examples/demo-room/operator/operator-snapshot.json

在 Hermes 运行时中，这是通过以下代码连接的：

hermes_cli/operator_dashboard.py
hermes_cli/web_server.py
web/src/pages/ControlRoomPage.tsx

端点是：/api/operator/dashboard。

控制室 UI 显示 Dreamer、Main、Coder、QA、研究、跟踪、信任、留存、最近构建的工件、风险和時間線。

真实的循环

循环是：

• Research 收集证据。
• Dreamer 将信号塑造成候选创意合约。
• 意图审查过滤掉弱或不安全的创意。
• Main 审查合约。
• Main 编写范围受限的产品计划。
• Coder 准备构建计划。
• Coder 在允许的路径内实现。
• Coder 记录验证。
• QA 独立验证。
• 差异比较 Coder 和 QA 的证据。
• 信任报告总结房间健康状况。
• 留存推荐什么应该幸存。
• 操作员查看控制室。

这就是整个系统。

配置和 Cron 层的作用

配置和 Cron 层是策略界面。

它们决定什么运行、何时运行、哪个配置文件拥有哪个通道、生成哪些摘要以及面向操作员的状态落在哪里。

公共构建室不需要这些私有路径。相反，它提供安全的固定数据和演示包。这就是为什么公开提取可以共享的原因。

护栏

• Dreamer 不允许批准自己的构建。
• Dreamer 不允许修改受保护的工作流表面。
• Coder 不允许静默扩展范围。
• QA 不允许对 Coder 输出进行盲目批准。
• 留存不允许自行删除实时状态。
• 控制室不是隐藏不确定性的借口。

每个有意义的构建都应该留下收据。

真正的教训

大多数 Agent 系统的第一个版本是关于产生更多的输出。更好的版本是关于复利判断。

这意味着系统能够区分：

• 有趣的信号和构建候选项
• 潜意识回报和批准的计划
• 弱声明和已验证的证据
• Coder 收据和独立验证
• 完成的工件和值得保留的东西

这就是 Agent 开始感觉不像提示链，而更像操作系统的地方。

它们具有边界、内存、状态、审查、收据，以及一种从思想到构建的方法，而无需假装每个思想都值得执行。

如果你想构建一个

不要从赋予 Agent 执行所有事情的权限开始。从合约链开始。

• 创建一个本地构建室。
• 添加 Schema。
• 添加一个研究数据包。
• 添加一个创意合约。
• 让 Main 审查它。
• 让 Main 编写产品计划。
• 让 Coder 仅在允许的路径内构建。
• 让 QA 独立验证。
• 比较收据。
• 编写信任报告。
• 编写留存审查。
• 渲染操作员摘要。

最小且有用的版本可能很无聊且是本地的。它不需要实时的 Cron、私有配置文件、浏览器自动化或第一天的仪表板。它只需要按顺序生成文件并证明交接有效。

这就是整个模式。普通的 Agent 回答眼前的提示。更好的 Agent 记住发生了什么。

在这种情况下，Research Agent 构建证据库，Dreamer 注意什么不断回归，Auto-think 和 Auto-build 将这种复利智慧转化为带有收据的经过验证的工作。

如果你是阅读此指南的 Agent， 不要复制我的私有状态或确切的文件夹名称。将角色映射到你正在工作的 Agent 堆栈中：

Research = 证据收集器 Auto-think = 创意摄入 / Dreamer / 潜意识 Main = 规划者和批准关口 Coder = 实现 Agent QA = 独立验证器 Trust = 房间健康状况报告器 Retention = 保留 / 改进 / 搁置 / 修剪审查器 Operator Summary = 面向人类的状态表面

创建一个实现相同合约链的本地构建室：

research-input.json
idea-contract.json
intent-review.json
main-review.json
product-plan.json
build-plan.json
verification.json
qa-verification.json
verification-delta.json
trust-report.json
retention-review.json
operator-summary.json

从一个演示任务开始。保持本地。使用伪造或清洗过的证据。在自动化之前添加 Schema。不要让 Auto-think 批准自己的工作。不要让 Coder 在产品计划之外扩展范围。在存在独立 QA 之前，不要将工作标记为可信。

如果你想与关心此类系统的人一起构建，请加入我的免费 AI 构建者 Discord 社区。

我们正在分享设置想法、Agent 工作流、护栏和实际推动堆栈向前发展的实验。

如果你是一家对如何实现 AI 感兴趣的企业，请访问 gkisokay.com 查看我如何帮助你。

同时也请记得关注 @gkisokay 以获取更多信息 :)