算法艺术创作
algorithmic-art
通过代码和可调参数创作生成艺术与交互式视觉效果。
choose-loop-wakeup-interval【设计与创意】Select a `delaySeconds` value when scheduling a loop wakeup via the `ScheduleWakeup` tool or the `/loop` slash command. Covers the three-tier cache-aware decision (cache-warm under 5 minutes, cache-miss 5 minutes to 1 hour, idle default 20 to 30 minutes), the 300-second anti-pattern, the [60, 3600] runtime clamp, the minute-boundary rounding quirk, a…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
delaySeconds value when scheduling a loop wakeup via the
ScheduleWakeup tool or the /loop slash command. Covers the three-tier
cache-aware decision (cache-warm under 5 minutes, cache-miss 5 minutes to
1 hour, idle default 20 to 30 minutes), the 300-second anti-pattern, the
[60, 3600] runtime clamp, the minute-boundary rounding quirk, and writing
a telemetry-worthy reason field. Use when designing an autonomous loop,
when a heartbeat cadence is being planned, when polling cadence is being
tuned, or when post-hoc review of loop costs reveals interval mis-sizing.
license: MIT
allowed-tools: ""
metadata:
author: Philipp Thoss
version: "1.0"
domain: general
complexity: intermediate
language: multi
tags: loop, wakeup, cache, scheduling, delay, general為 ScheduleWakeup 擇 delaySeconds 之值,須守提示快取五分鐘之壽、排程整分鐘之粒度、[60, 3600] 之運行夾限。此抉擇非直觀:常人直覺「約候五分鐘」,實落兩敗之域——既失快取,又未能攤還其失。
此推理本隨 ScheduleWakeup 之工具描述同行於呼叫之際,然彼時迴圈已排定。此技能將推理前移至規劃之時,歸其本位。
/loop 或 ScheduleWakeup 驅動之續行,擇每刻之延遲delaySeconds 之指南、手冊或示例定等待屬何層:
預期: 明確分類:主動觀察、失快取、或閒置。
失敗時: 若等待無法分類——若對「所待何事」無誠實答——迴圈本不該存。跳至步驟六,慮全然不排喚醒。
依分類擇 delaySeconds:
| 層級 | 範圍 | 快取行為 | 用時 |
|---|---|---|---|
| 快取溫存 | 60 – 270 s | 快取溫存(五分鐘壽內) | 主動觀察——下刻需快速廉價重入 |
| 失快取 | 1200 – 3600 s | 快取變冷;一失換得長候 | 真正閒置,或待發事件不能更早 |
| 閒置預設 | 1200 – 1800 s(20–30 分) | 快取變冷 | 無特定信號;用戶可中斷之週期檢查 |
莫取 300 s。 此乃兩敗之區:快取已失,候時不足以攤還。若手伸向「約五分鐘」,降至 270 s(保溫存)或許 1200 s+(攤還其失)。
預期: 具體 delaySeconds 值,取自三層之一,非習慣性整分鐘。
失敗時: 若抉擇屢落於 300 s,底層之問常為「此迴圈以此節律該存否」——回顧步驟一。
排程於整分鐘觸發。delaySeconds 為 N 則實際延遲 N 至 N + 60 秒,視呼叫時處分鐘之何秒。
示例:
於
HH:MM:40呼ScheduleWakeup({delaySeconds: 90})產生目標HH:(MM+2):00——實際候 140 s,非 90 s。
結果:次分鐘之意無義。視所傳值為下界,非精確排程。若一分鐘偏差關乎成敗,迴圈節律於此機制過緊。
預期: 已接受實際等待可較所請 delaySeconds 多至 60 s。對快取溫存之刻此事重要——270 s 可實成約 330 s,落入失快取之域。
失敗時: 若近天花板之值(如求快取溫存取 265 s)頻現,向下墊——取 240 s 而非 270 s,即便最壞之分鐘偏差亦保溫存之諾。
運行將 delaySeconds 夾至 [60, 3600]——範圍外之值靜然調整。遙測分別模型所求(chosen_delay_seconds)與實際排程(clamped_delay_seconds),凡不符置 was_clamped: true。
以夾後之值規劃,非所請之值:
預期: 所擇值落於 [60, 3600] 內,或已故意接受夾後行為。
失敗時: 若需確為多時(如「四時後喚我」),串接喚醒——排 3600 s 之刻,其自重排——或改用 cron 迴圈(CronCreate 帶 kind: "loop")。
reasonreason 欄乃遙測、用戶可見狀態、提示快取溫度推理之合一。截於 200 字元。須具體。
checking long bun build、polling for EC2 instance running-state、idle heartbeat — watching the feedwaiting、loop、next tick、continuing此欄之讀者乃欲解迴圈所作而無須預測節律之用戶。為彼而書。
預期: 具體一語之因,用戶瞥狀態欄即能解。
失敗時: 若無具體因可言,重審迴圈該存否(步驟一與步驟六)。
非凡「稍後再來」之念皆值排喚醒。勿排一刻當:
預期: 於排喚醒與不迴圈之間有自覺之擇。「因我能」非迴圈之由。
失敗時: 若排之喚醒屢於觸發前被用戶打斷,模式有誤——非間隔。
delaySeconds 落於三層範圍之一(60–270、1200–3600 或閒置之 1200–1800)[60, 3600] 內,或夾後行為已明確接受reason 具體且少於 200 字元reason 欄:"waiting" 告用戶無物,亦令遙測失用。書因如用戶將讀於狀態欄。bun build 已啟;代理欲速檢入令結果至時快取尚溫。
checking long bun build自主代理每時觀低流量饋送一次,覓可為之事。
idle heartbeat — watching the feed代理欲於遠端 API 重試時「候五分鐘」。請求為 300 s。
manage-token-budget — 長駐代理迴圈之成本上限;快取感知之定量乃一槓桿du-dum — 觀察/行動分離之模式;無 cron 時此技能定觀察之鐘間隔read-continue-here — 跨會話交接;此技能涵會話內喚醒write-continue-here — read-continue-here 之反