接手一个仓库、或者刚 clone 下来的项目，你做的第一件事往往是在终端里打出那一串“标准动作”：装依赖、构建、跑测试、起服务、看端口通不通。每个项目都来一遍，命令还各不相同——有的用 npm，有的用 pip，有的 cargo build，有的 docker compose up。

Hermes Agent 在 2026 年 8 月初合入 main 的 hermes verify 就是为这个场景设计的：一条命令，回答“这个项目现在到底能不能跑起来？” 它自动识别项目的运行配方（run recipe），按 bootstrap → build → test → start → readiness 的顺序做一次完整的冒烟验证，最后给出结构化结论。

$ hermes verify
detected: node (npm, vite)
bootstrap ✓  build ✓  test ✓
start on :5173 → ready in 2.1s
VERIFY PASS · evidence recorded

---

1. 它做什么

hermes verify 的核心工作流是：

1. 识别项目类型（detect）——扫描当前目录（或指定路径），根据特征文件判断项目属于哪种框架，生成一份 recipe；
2. bootstrap——安装/准备依赖（如 make install 或检测到的安装目标）；
3. build——构建（如 npm run build、go build ./...、cargo build、mvn package）；
4. test——跑测试（如 npm test、pytest、go test ./...、mvn test）；
5. start——后台启动应用，轮询就绪状态（默认 60 秒就绪超时，可配端口）；
6. teardown——清理，输出证据摘要与结构化 pass/fail 结论。

识别不了的项目会明确告诉你，并提示如何手动定义 recipe。

它和 Hermes 已有验证栈的关系

Hermes 此前已有三层验证能力（自我验证、完成契约、canonical test 命令），hermes verify 补上的是运行时冒烟验证这个缺口：项目真的能构建、能启动、端口真能通。通过运行的记录会写入 verification evidence ledger（agent/verification_evidence），与 verify-on-stop 守卫共用同一证据库——一次通过的 hermes verify 和一次通过的 canonical test 命令地位相同。

关键设计：它是个纯 CLI 命令，零 model-tool footprint——不新增任何模型可见的工具，不影响 agent 的工具面。

2. 支持哪些项目类型

源码 agent/verify/recipes.py 里实打实的检测器（每条都附证据说明）：

项目	特征	默认 build / test / start
Node.js	package.json + 包管理器（npm/pnpm/yarn）	npm run build / npm test / npm run dev（vite 等项目）
Python (Django)	manage.py 或 django 依赖	— / python manage.py test / python manage.py runserver 0.0.0.0:8000
Python (FastAPI 等)	pyproject/requirements	— / pytest（或 unittest）/ 按检测
Go	go.mod	go build ./... / go test ./... / go run .
Rust	Cargo.toml	cargo build / cargo test / cargo run
Java (Maven)	pom.xml	mvn package / mvn test
Java (Gradle)	build.gradle(.kts)	./gradlew build / ./gradlew test
Makefile 项目	Makefile	按目标自动挑选 install/build/test/run
docker-compose	compose.yml 等	docker compose build / docker compose up

3. 完整参数

hermes verify [path] [options]

  path               要验证的项目根目录（默认当前目录）

  --detect-only      只识别并打印 recipe（JSON），什么都不跑
  --save             把 recipe 保存为项目下的 .hermes/environment.json
  --skip-start       跑命令阶段，但跳过启动应用与就绪轮询
  --phase <name>     只跑指定阶段（bootstrap|build|test|start，可重复）
  --port <n>         覆盖就绪轮询使用的端口
  --timeout <sec>    每阶段超时（默认 600 秒）
  --ready-timeout <sec>  就绪轮询超时（默认 60 秒）
  --json             输出机器可读的 JSON 结果

4. 典型用法

日常冒烟验证

cd ~/projects/acme-web
hermes verify

只识别，先看看它认不认识你的项目

hermes verify --detect-only
# {"source": "detected", "recipe": {"kind": "node", ...}}

把 recipe 固定下来

识别结果可能随目录内容变化。用 --save 把 recipe 固化到 .hermes/environment.json，之后 hermes verify 优先加载这个 manifest，结果可复现：

hermes verify --save
# Saved manifest: /Users/me/projects/acme-web/.hermes/environment.json

CI 里用 JSON 结果做门禁

hermes verify --json
# {"ok": true, "recipe": {...}, "phases": {...}}

只跑测试阶段

hermes verify --phase test

5. 手动定义 recipe

--detect-only 识别失败时，提示语会告诉你：在项目下创建 .hermes/environment.json 来手动定义 recipe。manifest 是项目级的，.hermes/ 目录放进 .gitignore 与否由你决定——但注意它优先于自动检测，所以一旦保存，后续验证都按你定义的来。

6. 设计取舍（为什么值得注意）

• 零模型 footprint：verify 是 CLI 命令而非 agent 工具——它服务的是“人在终端里快速确认项目健康”，不占用 agent 的工具预算；
• 证据入账：通过结果写入 verification evidence ledger，与 verify-on-stop 守卫共享，形成闭环；
• fail 得快：每阶段默认 600 秒超时、就绪轮询 60 秒超时，卡死的项目不会被无限挂起。

小结

hermes verify 把“clone 下来先跑通”这个所有开发者的日常动作自动化了：识别框架、装依赖、构建、测试、起服务、探活，一条命令拿到结构化结论。对经常要评估陌生仓库、或想在 CI 里加一道冒烟门禁的开发者尤其有用。

配合我们站上的其他指南：Hermes Agent 定时任务完全指南 可以让你每天自动跑一遍 verify；错误处理与恢复机制解析 讲了 Hermes 失败后如何自愈；安装指南 帮你五分钟后拥有自己的 Hermes。