當 Claude Code 持續運行數小時
去年流行過的 Ralph Loop（一種讓 AI Coding Agent 自動重複執行的技巧）當時我並不太信任這種做法是否足夠安全，以及能有足夠的穩定性。
前幾個月 Claude Code 的更新加入了 /loop 技能，本質上是利用 Claude Code 內建的 Cron 工具，以固定間隔重複特定的提示詞（Prompt）來做到類似的效果，至少更安全、可控。
然而，事情通常不會這麼單純。
不可靠
最初是想在三月份的額度加倍中，盡可能善用這些額度，因此開始用 /loop 來做一些嘗試。過程中很快就注意到，結果似乎不如預期。
以 SDD（Spec-Driven Development）的情境，這是一個相當不錯的使用方案，因為我們可以把規格寫好後，由 Claude Code 接手完成實作，而且還不需要花力氣一直去關注 Claude Code 畢竟最後總是會完成。
為了能安全的運行，我還特地準備了 Proxmox Base Image 讓我隨時產生乾淨的 Virtual Machine 來運行，結果很意外的我大概不到一小時就看到 Claude Code 停止運作，而且確實有一個能運行的 Golang 專案，但只有「可以運行」的部分，並沒有把規格完成。
至少現在可以確定，下方這樣的指示並不可行
/loop 5m 根據 SPEC.md 實作完整功能約束工程
仔細深入問題後，我發現這跟最初的提示詞工程（Prompt Engineering）有相同的性質，當提示太過簡單時，語言模型往往無法很好的運作。
因此我想起來在網路上熱烈討論 Ralph Loop 差不多的時間點，Anthropic 的研究已經默默的在思考約束工程（Harness Engineering）的問題，也才有 Effective harnesses for long-running agents 這篇文章的出現，以及近期的 Harness design for long-running application development 和 OpenAI 的運用工程技術：在智慧體優先的世界中善用 Codex 都讓大家開始討論這個概念。
Harness Engineering 目前還沒有看到比較公認的翻譯，也有人用「駕馭」來翻譯，我認為最接近概念的應該是「約束」因此這篇文章用「約束」來描述
實務上，約束工程在很早之前就已經存在，包括我們使用的代理人（Agent）框架（如：LangChain）或者使用的開發代理人（Coding Agent）都必須做到相當程度約束工程，才能被順利使用。
即使如此，就算軟體層面設計的再好。決定行為本身的提示詞沒有與之相應的設計，很大程度用起仍然不太理想，這也是 /loop 給了簡單的提示卻不能很好運作的原因。
雖然看過很多人都稱讚 OpenCode 好用，然而我自己的使用體驗跟 Claude Code 相比仍覺得差很多，包括之前被 Anthropic 移除從 Claude Code 挖出來的系統提示（System Prompt）讓我更確定運行的框架跟系統提示必須搭配良好才能夠很好的被使用，這點仍是開發 Agent 很大的挑戰
客製化技能
最後，我處理 /loop 可靠性的方式，大概是用 200 ~ 500 字的提示詞來做行為的約束，才把整體能力提高到可用的程度。即使如此，也讓我開始獲得更多時間在思考上，因為 Claude Code 開始能夠以無人模式（Unattended）的狀態運作。
當我確認這個機制穩定後，就著手設計 powerloop 這個技能，專門用來補足 /loop 原本缺乏的約束，具體的實作方式可以參考專案的 README。
做法並不困難，按照 Anthropic 在去年的約束工程實驗，我們只需要讓 Claude Code 寫一份計劃去執行，並且經常的「檢查問題」就可以達到穩定且可用的水準。當然，出錯跟缺漏還是會發生，但比原本的「能動」已經好上不少。
我在 /powerloop 技能的做法也很簡單，跟 /loop 不同的地方是先確認「目標」以及執行任務所需的技能，確認完畢後讓 Claude Code 撰寫一份 .powerloop/[date]-[name].note.md 的任務計劃跟交接紀錄。
接著產生一份專用的系統提示給 Cron 工具使用，這份專用的系統提示基本上就是說明每個階段（執行、檢查）所用的技能、任務計劃的位置和更新方式。
光是這樣，就能夠讓 Claude Code 持續運作 3 ~ 5 小時左右，相比年初還需要專注的在電腦前，已經到可以安心吃頓午餐，或者打一兩場遊戲的程度。
即使目前許多人的注意力都放到約束工程這樣的「熱門名詞」但這些進階技巧的基礎，仍舊是提示詞工程對應更複雜狀況演變而來。一個好的提示跟運作指引，有時候仍是更重要的。