vibe-loop：有界 coding-agent 循环监督器
vibe-loop：有界 coding-agent 循环监督器
核心判断
vibe-loop 值得深度入库，因为它把“让 coding agent 自己一直做下去”从一句愿望拆成了可审计的运行时结构：任务源、锁、隔离 worktree、agent 启动、gate/review、run records、worker pool 与 autopilot。它与 Loop-Engineering、Harness-Engineering 和 Agentic-Coding 的关系很直接：Loop 负责持续调度，Harness 负责约束每个 slice，coding agent 只负责在边界内完成一个可验证任务。
机制 / 一阶原理
vibe-loop 的关键机制是把长程开发拆成有限 runnable slices：先从 Markdown task table、Spec Kit、Kiro、OpenSpec 或自定义任务源中选择可运行任务，再加锁、开隔离 worktree、运行 worker 命令，最后执行配置化 gate、review 与证据记录。这样做不是为了让模型“更聪明”，而是降低每次执行的状态不确定性：任务边界、依赖、接受标准、证据和恢复点都变成运行时对象，而不是留在聊天上下文里。
它还区分 runtime-owned orchestration 与 worker-owned orchestration。前者意味着 loop supervisor 拥有任务选择、生命周期、证据、恢复和 worker pool；模型 worker 只做局部实现。这个边界对无人 cron / 自动 coding loop 很关键：如果 worker 既定义范围又验证自己，就容易产生 scope creep、claim inflation 或失败重试失控。
对 Hermes / llm-wiki 的启发
对 Hermes 来说，vibe-loop 提供了一个轻量可借鉴的“有界单元”合同：每次自动任务应有明确 task source、lock/去重、隔离执行面、预算与最大重试、runner-observed gate、run summary。每日 AI 雷达也可以被视为一个 bounded loop：发现候选 → 深度门槛 → raw/source/concept/index/log/reindex → 报告 receipts。缺少任一环节时，应标记为 PARTIAL/HOLD，而不是用自然语言补齐。
对 llm-wiki 来说，它提示不要把“每日发现”做成无界追热点。更稳的做法是维护候选队列和晋升状态：raw-only、source-note、concept-update、comparison-needed、rejected-with-reason。这样既能防止页面膨胀，也能让未入库材料在未来重新评估。
失败模式与边界
vibe-loop README 明确标注早期开发、尚未广泛测试，并提醒关闭 permission prompts 的 Codex/Claude session 必须运行在只暴露必要 repo/tools/network/credentials 的容器或 VM 中。这是重要边界：loop supervisor 增加了吞吐，也放大了错误 agent 行为的影响半径。若没有隔离、预算、kill/recovery、独立 gate 和审计日志，所谓 autopilot 会把一次失败变成连续失败。
相关页面
写入记录
- 2026-07-31 09:01 CST：新增对 vibe-loop 有界任务循环、runtime-owned orchestration、worker pool 和 Hermes radar bounded-loop 合同的分析。