Honey Loop 用于约束重复 /loop 运行的成本。核心观点：循环中成本=每轮成本×轮数，浪费会累积；单次执行的省钱手段仍适用于每一轮，但循环还多出两个漏洞——每次唤醒重付上下文费用、重做未变化的工作。
五个手段：
- 按缓存节奏执行，避开死区。提示缓存 TTL 为 5 分钟。<270s 上下文保持热，适合主动轮询外部状态；≥1200s 可把一次缓存未命中摊销到长空闲等待，是空闲轮默认值（建议 1200–1800s）；约 300s 最差——付了缓存未命中又未摊销。不要取整为“5 分钟”，要么降到 270s，要么承诺 1200s 以上。
- 事件驱动优于轮询。受 harness 跟踪的工作（后台 Bash、Agent、Workflow）完成时会自动重新调用；不要为轮询它而安排短轮，那会白白重读完整上下文。设置长兜底心跳（1200s+），让完成通知驱动。只对 harness 看不到的外部状态（CI、部署、远程队列）轮询，节奏匹配其真实变化速度。
- 无变化短路。重新生成输出占每轮开销的大头，先廉价检查（哈希、时间戳、git rev-parse、状态字段）。若无变化：输出一行并重新调度，不重做任务、不重读世界、不写报告。
- 携带紧凑状态句柄，不要重新推导。把循环已做的事存进小文件（.honey-loop/state.json 或通过 eso stash 的 <honey:HASH> 暂存），每轮读取它，而非从头重新发现完整历史。
- 定义完成条件，然后停止。无界循环即无界成本。事先声明退出条件（达到目标、N 次空轮、截止时间），满足时结束循环并省略唤醒重新调度。“永远循环”是 bug，不是特性。
每轮输出默认 ultra：循环 tick 是 agent 给自身或日志的消息，不是交付物，默认只输出状态行，如 tick 4/∞ · no change · next 1800s；仅当确实需要用户介入（状态变化、决策、错误）时才升级为完整报告。
不要削减的部分：停止/退出检查、错误上报、手段 3 的廉价预检查。
资料未提供该技能的安装方式、平台要求、收费与价格等信息。