Loop-Engineering 循环护栏 — 研究与自主性系统适配
Codex 核验（2026-10-09）：本文件是工作流设计。成本记录和预算提示不会自动形成服务端花费硬上限，技能中的“三次”限制需循环代码检查才能强制；worktree/受限页面/提示规则也不等于进程或网络沙箱。
✅保留为原日期描述，不代表本次运行验证；$47,000 事故及人物引语缺少可追溯原始证据，暂不能当作已核实统计。参考Git worktree 的实际职责。
来源:
fltman/loop-engineer(⭐32) — Claude Code loop guardrail skill 原始发现: 小红书 “两周疯传！6个Claude新神Skill” (168👍 / 352📌)
核心发现
Loop-Engineering 解决的核心问题是 Agent 循环失控（“loopmaxxing”）：跑着跑着开始飘 → 自嗨 → 绕路 → 误判完成状态。
声称的通过率改善: 87% → 100%，来源于 5 点护栏清单强制落地。
5 点护栏清单（非协商条款）
任何循环在投运前必须满足这 5 条，否则就是 bug 而非循环：
| # | 护栏 | 说明 | 在 Hermes 自主性系统中的实现 |
|---|---|---|---|
| 1 | 可验证的退出条件 | binary pass/fail 检查，每轮先检查再执行 | 每条便签必须有 done_when 字段 ✅ 已实现 |
| 2 | 最大迭代次数硬上限 | 代码级的 for 循环上限，不在 prompt 里 | 执行上限 3 轮，超限标记 ✅ 已植入宪章 |
| 3 | 预算上限（代码级强制） | 累计成本，在下次 API 调用前停止 | 每次执行记录 token 消耗 ✅ 已实现 (budget log) |
| 4 | 沙箱 | 不在 main 上无人值守运行 | 自主操作限定在 brain 页面 / skill 文件 ✅ 已植入 |
| 5 | 人的检查点 | push/deploy/发送前必须停 | 高风险操作标记 ⏸️ 等待用户 ✅ 已植入 |
核心纪律: 没有 binary 退出条件 → 不要建循环。 “改善用户体验” 没有通过/不通过。该修复目标，而不是建循环。
5 种循环模式
| 模式 | 适用场景 | 在自主性系统中的映射 |
|---|---|---|
| Headless while-loop | 单一 Agent 朝向单一 binary check | 单条便签处理循环 |
| Evaluator-optimizer | 质量是判断型（有评审环节） | 生成内容后自动评审 |
| Meta / prompt-refinement | 改进 prompt 本身 | 长期优化便签处理 prompt |
| Orchestrator fan-out | 子任务不可预测 | 多 Agent 协调工作 |
| Scheduled / triggered | 定时或事件驱动 | 当前 cron 任务 |
已记录的真实事故
| 事故 | 原因 | 教训 |
|---|---|---|
| 4-Agent 循环跑了 11 天 → ~$47,000 | 无 per-Agent 预算上限 | 预算警告 ≠ 预算强制 |
| 工具被调用 400× 在 5 分钟内 | 循环 bug / 上下文膨胀 | 迭代上限必须在代码中 |
| 5,000 | 模型路由错误 | 每次调用前检查上限 |
应用到 Hermes 自主性系统 Phase 0
当前的便签检查 cron 任务是本系统的核心循环。按照 Loop-Engineering 方法论，需要以下强化：
立即实施（Phase 0）— 状态
| # | 事项 | 状态 | 说明 |
|---|---|---|---|
| 1 | 便签必须有退出条件 (done_when) | ✅ 已实现 | 每条便签必须标注完成判定条件 |
| 2 | 每个 cron 运行加迭代上限 | ✅ 已实现 | 执行上限 3 轮，超限标记「未完成·超限」 |
| 3 | 成本追踪 | ✅ 已实现 | 每次执行写入 sticky-notes-budget-log |
| 4 | 沙箱 | ✅ 已植入宪章 | 自主操作限定在 brain 页面/skill 文件 |
| 5 | Discord 确认检查点 | ✅ 已植入宪章 | 高风险操作标记 ⏸️ 等待用户 |
下一阶段（Phase 1）
- 情绪标签系统 — 在便签中加入”需要冷静/可以激进”标签
- 反馈闭环 — cron 记录做了什么、结果如何，更新记忆
- 优先级自主判断 — AI 判断哪些便签值得做
架构参考
┌─────────────────────────┐
│ 便签池 (sticky notes) │
│ gbrain 'concept' 类型 │
└────────┬────────────────┘
│ 每 X 分钟 cron 扫描
│ (当前: 每30min)
┌────────▼────────────────┐
│ 主动性决策循环 │
│ 1. 读便签池 │
│ 2. 检查退出条件 │
│ 3. 检查预算上限 ✅ │
│ 4. 执行便签 │
│ 5. 记录结果 │
│ 6. 检查人机检查点 │
└────────┬────────────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Eventide │ │ gbrain │ │ Discord │
│ 情绪/状态 │ │ 记忆/知识 │ │ 检查点界面 │
└────────────┘ └────────────┘ └────────────┘
关键引用
“I don’t prompt Claude anymore. I have loops running that prompt Claude… My job is to write loops.” — Boris Cherny, creator of Claude Code (Anthropic)
“No binary, verifiable exit condition → no loop.”
“Budget alerts are not budget enforcement.”
下一步 — 跟踪
- 调研 Loop-Engineering 核心机制
- 提取 5 点护栏清单
- 将护栏 checklist 写入 sticky-notes 系统 ✅ 2026-07-15
- 为每条便签新增
done_when字段 ✅ 2026-07-15 - 在 cron 中实现预算追踪 ✅ 2026-07-15 — 创建 sticky-notes-budget-log 日志页
Phase 1 待办
- 情绪标签系统
- 反馈闭环 — 每次执行自动记录到记忆
- 优先级自主判断 — AI 自动排序便签
- Eventide 状态接入
关联
- sticky-note-guardrails — 便签操作护栏（本研究成果的直接实现）
- sticky-notes-board — 便签板（护栏已植入操作宪章）
- sticky-notes-budget-log — 预算追踪日志