What I learnt after running loops for 1 month???

講者所在公司已運行了數月的自主代理循環系統。其中一個例子是每 30 分鐘自動喚醒代理掃描程式碼庫、檢查伺服器日誌、發現改進機會並提交 PR，每個 PR 由驗證代理進行全面測試後可自動合併。同時還運行 CRM 生命週期循環監控用戶群體並進行個性化溝通。這代表了循環工程師角色的核心轉變：從手工提示代理執行單一任務，升級到設計一個能自主決策、執行、驗證、並持續改進的完整系統。

最大的挑戰不在於編寫循環本身——任何人都能用 CloudCode 快速搭建基礎循環——而是如何設計護欄讓系統持續安全地運作。講者介紹的標準循環架構包含五大要素。

首先是循環契約文檔。這份 Markdown 文件明確定義循環的目標和成功指標（例如「降低 React 代碼品質評分中的 C 級問題」），界定邊界（哪些任務代理可自行完成如合併低風險修復、哪些需要人工審核如架構變更），以及標準操作程序（代理每次都應遵循的具體工作流程）。配備狀態層記錄代理當前理解、待辦積壓、已發貨但需跟進的項目，以及日誌層逐次記錄每輪運行。如果沒有這層持久化狀態，代理每天早上會重新發現相同的錯誤，浪費大量令牌在已嘗試過的場景上。

第二層是觸發器選擇。最常見的是持續循環（定義目標、條件、執行操作，直到達成或達到令牌預算），適合 bug 修復等需立即反饋的場景。其次是定時任務（類似 cron 或 schedule 命令），在特定時間間隔喚醒代理。但講者發現最經濟高效的方式是工作流程組合觸發——先運行輕量級腳本從數據源檢查是否有新工作（例如過去 30 分鐘有無重要郵件更新），只在確實有工作時才喚醒代理進行批量處理。基於事件的觸發雖然目前 CloudCode 和 CodeEx 不原生支持，但可通過本地守護程式暴露 Webhook URL 接收通知。

第三層是代理執行架構。簡單任務只需一個代理完成三個階段（收集信號→執行任務→驗證質量）；複雜任務則分解為：Planner 代理接收提示進行研究規劃，然後多個 Executor 代理各自獨立處理工作樹（可並行運行），最後 Verifier 代理測試結果並附加證據（截圖、日誌、視頻）供人類審核。

對高風險任務（生產代碼變更、客戶溝通），驗證器是強制前置條件。講者開發了完整工具棧：使用 Playwright CRI 讓代理測試並記錄視頻或圖像證據；用 Raybox 設置遠程沙箱環境並行運行多個開發伺服器，突破本機限制。這些打包成開源 skew 供免費使用。

最後是演化層。講者發現初期循環總有改進空間：觸發器可更高效、重複 SOP 可轉為腳本、配置可優化。解決方案是每運行 5-10 次後觸發一次專門的演化會話，提供代理所有歷史配置、過去運行日誌、對話記錄，讓它識別優先級最高的改進機會並生成優化提案。講者自研的開源工具提供集中化管理平台，支持程序化觸發器定義、狀態日誌存儲、自動演化機制，每隔幾次運行會出現演化檢查點。

講者舉了三個實戰例子。文檔維護循環每天檢查過去 24 小時的程式碼變更，與 README、config 指南、examples 對比，自動修復不一致並提 PR——一個看似簡單卻實用性極強的循環。React Doctor 循環每日掃描前端代碼庫、標出關鍵問題、自動修復、自動合併（僅低風險修復），並通過內部儀表板追蹤 PR 開合狀況和代碼品質評分隨時間的改進。CRM 生命週期循環監控所有日活躍用戶，自動分類為潛在合作夥伴、不滿意用戶、高參與未升級用戶，客服可按優先級和風險等級選擇自動發送訊息或待批准。這些循環都遵循相同架構模式，體現了可複製、可擴展的系統設計。

---