08 · 自动化边界 · AI 编程教程中文版

Hermes 能做自动化，但自动化不是把所有事情都交给 agent。真正可靠的自动化一定有边界、日志、失败处理、人工确认点、回滚路径——这五件没有的自动化，不是节省人力，是放大事故面。

官方资料：Cron、Delegation、Hooks、Persistent Goals、Messaging Gateway、Security、Checkpoints & Rollback。

先给结论：自动化的四个默认——默认只读、默认不发布、默认不删除、默认不外发敏感内容。所有写操作限定范围，所有高风险动作人工确认。基础失败时，先停自动化再看代码，不要让定时任务在错误状态里反复跑。

自动化能力层

Hermes 中和自动化相关的 6 类能力——任意一项启用都让风险面更大一层：

Gateway

后台进程，把消息平台和 cron scheduler 接进 Hermes——它是远程能力的入口。

Background session

把长任务放到独立 session，完成后回报结果——主聊天保持响应。

Cron

周期性或一次性运行任务，支持自然语言（例如：每天 9 点）和标准 cron 表达式。

Delegation

生成隔离上下文的子 agent（child agents），用于并行研究、审查或拆分任务。

Hooks

在生命周期事件（启动 / 命令前后 / session 结束）运行自定义代码、webhook 或 shell 脚本。

Persistent Goals

持久目标：设一个长期目标后，agent 跨多轮持续推进——Hermes 自创的 Ralph loop。

这些能力叠加后，Hermes 可以主动运行任务、调用工具、发消息、修改文件，甚至连接远端环境。风险也随之指数上升——任意两项组合（如 cron + hooks）的故障传导路径就比单一能力复杂数倍。

适合自动化

适合 Hermes 自动化：

每日摘要。
定时检查服务状态。
收集公开信息并生成报告。
跑只读诊断。
对固定目录做低风险整理。
自动提醒和待办汇总。
后台跑测试并回报结果。

这些任务有共同点：输入稳定、失败可接受、结果可检查、动作可重复。

不适合直接放权

不适合直接放权：

删除数据。
发布生产。
修改账单或权限。
操作真实客户数据。
自动提交或合并高风险代码。
在未隔离环境运行未知脚本。
发送无法撤回的外部消息。

这些任务可以让 Hermes 做计划、检查、草稿和预演，但执行前必须人工确认。

Cron 边界

Cron 可以创建一次性或周期任务，可以 pause、resume、edit、run、remove，可以绑定一个或多个 skills，也可以把结果投递到 origin chat、文件或平台目标。官方还提供 no-agent mode，让脚本按计划运行并把 stdout 原样投递。

设计 cron 前先回答：

失败后谁知道？
日志在哪里？
任务是否幂等？
是否会重复发送消息？
是否可能修改文件或外部系统？
凭据是否最小权限？
运行目录是否明确？
会不会递归创建更多 cron？

官方限制 cron-run sessions 递归创建 cron jobs，这是防 runaway scheduling loop 的必要护栏。你自己的任务也要有同类边界。

Workdir 与项目规则

Cron 默认不一定在你的项目目录里运行。设置 workdir 后，项目里的 AGENTS.md、CLAUDE.md、.cursorrules 才会按规则注入，terminal/file/code execution 也会以该目录作为工作目录。

这意味着：项目相关 cron 不要只写“每天检查项目”。要写清楚绝对路径、规则文件、输出位置和失败通知。

Delegation 边界

Delegation 会生成 child agents。官方强调子 agent 没有父对话历史，只知道 goal 和 context 字段。父 agent 必须把任务需要的信息完整传入。

适合：

多个独立资料收集。
多模块只读审查。
并行测试/调查，且写入范围互不冲突。
复杂任务的隔离分析。

不适合：

多个子任务写同一个文件。
修改同一模块。
需要强共享上下文的复杂决策。
生产发布。

默认并发和 depth 限制要谨慎调整。每多一层 delegation，成本、并发写入风险和排障复杂度都会增长。

Hooks 边界

Hermes 有 gateway hooks、plugin hooks 和 shell hooks。它们适合：

记录 slash command 使用。
长任务提醒。
session start/reset 通知。
webhook 投递。
自动格式化或阻断危险动作。

Hooks 是确定性自动化，不是 LLM 推理。它们应该短、小、可观测。不要在 hook 里塞大型业务逻辑，也不要让 hook 悄悄吞掉失败。

最小安全基线

默认只读
默认不发布
默认不删除
默认不外发敏感内容
所有写操作限定范围
所有高风险操作人工确认
所有定时任务有日志
所有外部 token 最小权限
所有消息平台有 allowlist
所有后台任务有停止方式
所有自动化有失败通知

没有边界的自动化，不是效率，是持续运行的事故源。

系列收束 · Hermes 自我改进的边界 = 这条递进顺序

读完这一篇，你应该能把 Hermes 的使用顺序串起来——这就是「self-improving agent runtime」的正确进化路径：

flowchart TB
    A1[1 理解 Hermes 是什么<br/>区分聊天 CLI / IDE 助理 / 消息 Bot / Agent Runtime]
    A2[2 跑通稳定闭环<br/>install + provider + chat + session]
    A3[3 配好 provider 和目录<br/>~/.hermes 文件分工 + Provider 策略]
    A4[4 收敛工具和执行环境<br/>toolset 和 backend 解耦]
    A5[5 治理记忆<br/>MEMORY.md / USER.md / 不当日志写]
    A6[6 沉淀 skills<br/>渐进加载 + Curator 治理]
    A7[7 接入消息平台<br/>Gateway + allowlist + 三类场景区分]
    A8[8 自动化<br/>cron / delegation / hooks / goals 守边界]
    A1 --> A2 --> A3 --> A4 --> A5 --> A6 --> A7 --> A8
    A8 -.->|"反过来检查"| A2

跳过任何一步都会在后面付双倍代价——基础不稳就开扩展，等于把每一层的不确定性传给下一层；而且新层暴露的故障并不会自己定位回根因，最后只能整体重启从头排查。

官方资料

Cron Jobs（自然语言 / cron 表达式 / no-agent mode）
Delegation（子 agent / 并发 / depth 限制）
Hooks（生命周期钩子 / webhook 投递）
Persistent Goals（Ralph loop 实现）
Security（命令审批 / 容器隔离 / 生产部署）
Checkpoints & Rollback（破坏性操作快照与回滚）

08 · 自动化边界