習(xí)筆記-AI工程化系列】Loop Engineering，從手動提示到目標(biāo)驅(qū)動自動化-13/16)
前面我們講了 Agent Loop。它是 Agent 能多步執(zhí)行的最小內(nèi)核。但真實工作里問題很快會變成另一種形態(tài)。不是幫我執(zhí)行這一次。而是以后只要 PR 有新評論就幫我檢查。 每天早上把重要信息匯總給我。 每晚跑一次文檔漂移檢查。 CI 失敗時先自動定位原因。 發(fā)現(xiàn)依賴風(fēng)險時生成修復(fù)草稿。這已經(jīng)不是一次對話里的 Agent Loop這是目標(biāo)驅(qū)動自動化。本系列把這類工程實踐稱為Loop Engineering。先把口徑說清楚Loop Engineering 不是一個已經(jīng)完全標(biāo)準(zhǔn)化的官方學(xué)科名。它更像是開發(fā)者社區(qū)對一組正在成熟的工程實踐的命名。這些實踐包括agent loop scheduled routines event-driven automation long-running agents verification loops human approval loops recovery loops它們的共同點是圍繞一個目標(biāo)讓 Agent 在觸發(fā)器、狀態(tài)、工具、驗證和恢復(fù)機制之間持續(xù)運行。一、從 prompt 到 routine手動提示的工作方式是人發(fā)現(xiàn)問題 人打開工具 人描述任務(wù) Agent 執(zhí)行 人檢查結(jié)果這種方式適合臨時任務(wù)但它有明顯上限。人必須記得觸發(fā)。人必須重復(fù)描述背景。人必須每次判斷下一步。人必須發(fā)現(xiàn)失敗。Routine 的工作方式不同它把一組配置保存下來目標(biāo) 上下文 倉庫或數(shù)據(jù)源 連接器 觸發(fā)器 權(quán)限 驗證方式 匯報方式然后在合適的時機自動運行。比如 Claude Code Routines 這類能力把 prompt、repo、connectors 和 triggers 組合成可復(fù)用任務(wù)。CLI 里的 schedule、GitHub 事件、API webhook本質(zhì)上都是讓 Agent 從“等人提問”變成“按條件觸發(fā)”。這就是 Loop Engineering 的第一層變化從交互式調(diào)用變成持續(xù)任務(wù)。二、六個組件一個可用的 Loop Engineering 系統(tǒng)至少要有六個組件。2.1 Goal目標(biāo)必須穩(wěn)定。不能寫成幫我看看項目有沒有問題。這太寬。更好的目標(biāo)是每天檢查 docs/ 中是否存在與代碼行為不一致的說明并生成修復(fù)建議。或者當(dāng) PR 出現(xiàn) review comments 時分類為可自動處理、需要作者決策、需要人工確認(rèn)三類。好的 Goal 應(yīng)該包含對象 范圍 成功標(biāo)準(zhǔn) 風(fēng)險邊界 輸出形式2.2 TriggerTrigger 決定 loop 什么時候啟動。常見觸發(fā)器有四類。時間觸發(fā)每天 9 點、每周一、每晚 事件觸發(fā)PR、issue、CI、webhook 人工觸發(fā)/loop、/schedule、按鈕、命令 狀態(tài)觸發(fā)指標(biāo)異常、任務(wù)積壓、文檔過期Trigger 不是簡單的定時器它要帶上觸發(fā)上下文。比如哪個 PR 哪條評論 哪個 job 失敗 哪些文件變化 上次運行結(jié)果是什么沒有觸發(fā)上下文Agent 每次都要重新探索。成本高也容易誤判。2.3 StateState 是持續(xù)運行的核心。沒有 StateAgent 每次啟動都像失憶。State 至少包括上次運行時間 已處理對象 當(dāng)前進度 重要決策 失敗記錄 待人工確認(rèn)事項 預(yù)算消耗State 可以存在 session 里可以存在數(shù)據(jù)庫里也可以存在倉庫文件里。關(guān)鍵不是形式。關(guān)鍵是下一次運行能恢復(fù)任務(wù)。2.4 ActionAction 是 Agent 能做什么它來自工具和權(quán)限。比如讀 PR 評論 拉取代碼 運行測試 修改文件 提交 commit 寫草稿 發(fā) Slack 創(chuàng)建 issueAction 必須分級只讀動作可以自動化可回滾動作可以在驗證后自動化。外部副作用動作要審批。不可回滾動作要非常謹(jǐn)慎。2.5 VerificationLoop Engineering 的核心不是讓 Agent 多跑而是讓它每一輪知道自己是否接近目標(biāo)。驗證可以是測試通過 lint 通過 schema valid 引用來源完整 diff 符合范圍 人工審批通過 LLM reviewer 通過沒有 Verificationloop 會變成自動化幻覺。它會一直做事但你不知道它是否在變好。2.6 Recovery長期運行一定會失敗工具會報錯權(quán)限會過期網(wǎng)絡(luò)會失敗模型會走偏。上下文會污染預(yù)算會耗盡。所以 Recovery 不是兜底裝飾它是核心組件。至少要設(shè)計retry rollback checkpoint pause escalate to human resume from state一個沒有 Recovery 的 loop不應(yīng)該接高價值任務(wù)。三、/loop、Routines、cron 和 headless agent這些東西經(jīng)常被混在一起。但它們不是同一個層級。/loop更像交互式命令。讓當(dāng)前 Agent 在一個目標(biāo)上持續(xù)執(zhí)行直到滿足條件或被停止。Routines更像保存好的 Agent 任務(wù)配置。它把 prompt、repo、connectors、觸發(fā)器、權(quán)限和運行環(huán)境組合起來。cron headless agent更像開發(fā)者自己搭的自動化。定時觸發(fā)一個無界面 Agent讓它在 CI、服務(wù)器或工作流平臺里運行。workflow engine更像確定性編排系統(tǒng)。Agent 只參與其中一部分步驟。所以選擇時不要問哪個更高級要問誰負(fù)責(zé)觸發(fā) 誰負(fù)責(zé)狀態(tài) 誰負(fù)責(zé)權(quán)限 誰負(fù)責(zé)驗證 誰負(fù)責(zé)恢復(fù) 誰負(fù)責(zé)審計如果這些問題沒有答案換什么名字都不算工程化。四、什么時候適合用 LoopLoop 適合這類任務(wù)。第一重復(fù)發(fā)生。比如 PR 評論、issue triage、日報、周報、依賴檢查。第二目標(biāo)可驗證。比如測試是否通過、草稿是否生成、鏈接是否有效、評論是否處理。第三路徑有一定不確定性。如果路徑完全固定用普通 workflow 就夠了。第四失敗能恢復(fù)。失敗后能重試、暫停、回滾或升級人工。第五風(fēng)險可分級。低風(fēng)險動作自動執(zhí)行高風(fēng)險動作進入審批。典型場景包括PR babysitting daily digest issue triage nightly documentation drift check build failure auto-fix dependency update draft knowledge base freshness check這些任務(wù)不一定需要 Agent 全天候運行。它們需要的是在正確時機啟動 拿到正確上下文 執(zhí)行有限動作 完成驗證 留下狀態(tài) 必要時叫人五、什么時候不要用 LoopLoop 不適合所有任務(wù)。下面幾類要謹(jǐn)慎。5.1 目標(biāo)含糊比如讓產(chǎn)品更好。 幫我優(yōu)化增長。 自動維護整個項目質(zhì)量。這類目標(biāo)太寬。Agent 會在錯誤方向上很努力。5.2 高風(fēng)險且不可回滾比如自動轉(zhuǎn)賬 自動刪生產(chǎn)數(shù)據(jù) 自動發(fā)送大規(guī)模營銷消息 自動改權(quán)限不是絕對不能自動化但不能只靠 loop。需要強審批、沙箱、審計和補償機制。5.3 難以驗證如果沒有成功標(biāo)準(zhǔn)Agent 只能自說自話這比不自動化更危險。5.4 人類其實想要判斷而不是執(zhí)行有些任務(wù)看似重復(fù)其實核心價值在判斷。比如定戰(zhàn)略、定價格、定組織調(diào)整。這種場景可以讓 Agent 準(zhǔn)備材料。不要讓它閉環(huán)決策。六、實戰(zhàn) Checklist把一個手動提示改成 Loop 前先檢查這十二項。1. Goal 是否寫成可驗證目標(biāo) 2. Trigger 是否清楚 3. Trigger 是否攜帶上下文 4. State 存在哪里 5. State 是否能恢復(fù)下一次運行 6. Action 是否分級 7. 哪些動作自動允許 8. 哪些動作必須審批 9. Verification 是否可執(zhí)行 10. 失敗后如何 retry / rollback / pause 11. 預(yù)算上限是什么 12. 如何向人類匯報結(jié)果和風(fēng)險如果這些答案都清楚Loop 才有資格進入長期自動化。七、最后Loop Engineering 不是把 prompt 重復(fù)運行也不是讓 Agent 一直跑。它的核心是圍繞目標(biāo)設(shè)計可持續(xù)執(zhí)行系統(tǒng)。Prompt 讓任務(wù)說清楚。Context 讓每一步看對信息。Harness 讓 Agent 有工具、權(quán)限、驗證和觀測。Loop 把這些能力變成持續(xù)運行的自動化。下一篇我們進入最容易翻車的部分長運行 Agent。因為 loop 一旦拉長三個問題會被放大上下文會斷。 目標(biāo)會漂。 成本會爆。參考資料Claude Code Docs: Routines and scheduled routinesOpenAI Agents SDK: Runner, sessions, handoffs and human-in-the-loopAnthropic: Effective Harnesses for Long-Running AgentsAnthropic: Long-running Claude for Scientific ComputingAnthropic: Building Effective AI Agents參考文獻第十三篇Loop Engineering從手動提示到目標(biāo)驅(qū)動自動化 【學(xué)習(xí)筆記-AI工程化系列】Loop Engineering，從手動提示到目標(biāo)驅(qū)動自動化-13/16
前面我們講了 Agent Loop。它是 Agent 能多步執(zhí)行的最小內(nèi)核。但真實工作里問題很快會變成另一種形態(tài)。不是幫我執(zhí)行這一次。而是以后只要 PR 有新評論就幫我檢查。 每天早上把重要信息匯總給我。 每晚跑一次文檔漂移檢查。 CI 失敗時先自動定位原因。 發(fā)現(xiàn)依賴風(fēng)險時生成修復(fù)草稿。這已經(jīng)不是一次對話里的 Agent Loop這是目標(biāo)驅(qū)動自動化。本系列把這類工程實踐稱為Loop Engineering。先把口徑說清楚Loop Engineering 不是一個已經(jīng)完全標(biāo)準(zhǔn)化的官方學(xué)科名。它更像是開發(fā)者社區(qū)對一組正在成熟的工程實踐的命名。這些實踐包括agent loop scheduled routines event-driven automation long-running agents verification loops human approval loops recovery loops它們的共同點是圍繞一個目標(biāo)讓 Agent 在觸發(fā)器、狀態(tài)、工具、驗證和恢復(fù)機制之間持續(xù)運行。一、從 prompt 到 routine手動提示的工作方式是人發(fā)現(xiàn)問題 人打開工具 人描述任務(wù) Agent 執(zhí)行 人檢查結(jié)果這種方式適合臨時任務(wù)但它有明顯上限。人必須記得觸發(fā)。人必須重復(fù)描述背景。人必須每次判斷下一步。人必須發(fā)現(xiàn)失敗。Routine 的工作方式不同它把一組配置保存下來目標(biāo) 上下文 倉庫或數(shù)據(jù)源 連接器 觸發(fā)器 權(quán)限 驗證方式 匯報方式然后在合適的時機自動運行。比如 Claude Code Routines 這類能力把 prompt、repo、connectors 和 triggers 組合成可復(fù)用任務(wù)。CLI 里的 schedule、GitHub 事件、API webhook本質(zhì)上都是讓 Agent 從“等人提問”變成“按條件觸發(fā)”。這就是 Loop Engineering 的第一層變化從交互式調(diào)用變成持續(xù)任務(wù)。二、六個組件一個可用的 Loop Engineering 系統(tǒng)至少要有六個組件。2.1 Goal目標(biāo)必須穩(wěn)定。不能寫成幫我看看項目有沒有問題。這太寬。更好的目標(biāo)是每天檢查 docs/ 中是否存在與代碼行為不一致的說明并生成修復(fù)建議。或者當(dāng) PR 出現(xiàn) review comments 時分類為可自動處理、需要作者決策、需要人工確認(rèn)三類。好的 Goal 應(yīng)該包含對象 范圍 成功標(biāo)準(zhǔn) 風(fēng)險邊界 輸出形式2.2 TriggerTrigger 決定 loop 什么時候啟動。常見觸發(fā)器有四類。時間觸發(fā)每天 9 點、每周一、每晚 事件觸發(fā)PR、issue、CI、webhook 人工觸發(fā)/loop、/schedule、按鈕、命令 狀態(tài)觸發(fā)指標(biāo)異常、任務(wù)積壓、文檔過期Trigger 不是簡單的定時器它要帶上觸發(fā)上下文。比如哪個 PR 哪條評論 哪個 job 失敗 哪些文件變化 上次運行結(jié)果是什么沒有觸發(fā)上下文Agent 每次都要重新探索。成本高也容易誤判。2.3 StateState 是持續(xù)運行的核心。沒有 StateAgent 每次啟動都像失憶。State 至少包括上次運行時間 已處理對象 當(dāng)前進度 重要決策 失敗記錄 待人工確認(rèn)事項 預(yù)算消耗State 可以存在 session 里可以存在數(shù)據(jù)庫里也可以存在倉庫文件里。關(guān)鍵不是形式。關(guān)鍵是下一次運行能恢復(fù)任務(wù)。2.4 ActionAction 是 Agent 能做什么它來自工具和權(quán)限。比如讀 PR 評論 拉取代碼 運行測試 修改文件 提交 commit 寫草稿 發(fā) Slack 創(chuàng)建 issueAction 必須分級只讀動作可以自動化可回滾動作可以在驗證后自動化。外部副作用動作要審批。不可回滾動作要非常謹(jǐn)慎。2.5 VerificationLoop Engineering 的核心不是讓 Agent 多跑而是讓它每一輪知道自己是否接近目標(biāo)。驗證可以是測試通過 lint 通過 schema valid 引用來源完整 diff 符合范圍 人工審批通過 LLM reviewer 通過沒有 Verificationloop 會變成自動化幻覺。它會一直做事但你不知道它是否在變好。2.6 Recovery長期運行一定會失敗工具會報錯權(quán)限會過期網(wǎng)絡(luò)會失敗模型會走偏。上下文會污染預(yù)算會耗盡。所以 Recovery 不是兜底裝飾它是核心組件。至少要設(shè)計retry rollback checkpoint pause escalate to human resume from state一個沒有 Recovery 的 loop不應(yīng)該接高價值任務(wù)。三、/loop、Routines、cron 和 headless agent這些東西經(jīng)常被混在一起。但它們不是同一個層級。/loop更像交互式命令。讓當(dāng)前 Agent 在一個目標(biāo)上持續(xù)執(zhí)行直到滿足條件或被停止。Routines更像保存好的 Agent 任務(wù)配置。它把 prompt、repo、connectors、觸發(fā)器、權(quán)限和運行環(huán)境組合起來。cron headless agent更像開發(fā)者自己搭的自動化。定時觸發(fā)一個無界面 Agent讓它在 CI、服務(wù)器或工作流平臺里運行。workflow engine更像確定性編排系統(tǒng)。Agent 只參與其中一部分步驟。所以選擇時不要問哪個更高級要問誰負(fù)責(zé)觸發(fā) 誰負(fù)責(zé)狀態(tài) 誰負(fù)責(zé)權(quán)限 誰負(fù)責(zé)驗證 誰負(fù)責(zé)恢復(fù) 誰負(fù)責(zé)審計如果這些問題沒有答案換什么名字都不算工程化。四、什么時候適合用 LoopLoop 適合這類任務(wù)。第一重復(fù)發(fā)生。比如 PR 評論、issue triage、日報、周報、依賴檢查。第二目標(biāo)可驗證。比如測試是否通過、草稿是否生成、鏈接是否有效、評論是否處理。第三路徑有一定不確定性。如果路徑完全固定用普通 workflow 就夠了。第四失敗能恢復(fù)。失敗后能重試、暫停、回滾或升級人工。第五風(fēng)險可分級。低風(fēng)險動作自動執(zhí)行高風(fēng)險動作進入審批。典型場景包括PR babysitting daily digest issue triage nightly documentation drift check build failure auto-fix dependency update draft knowledge base freshness check這些任務(wù)不一定需要 Agent 全天候運行。它們需要的是在正確時機啟動 拿到正確上下文 執(zhí)行有限動作 完成驗證 留下狀態(tài) 必要時叫人五、什么時候不要用 LoopLoop 不適合所有任務(wù)。下面幾類要謹(jǐn)慎。5.1 目標(biāo)含糊比如讓產(chǎn)品更好。 幫我優(yōu)化增長。 自動維護整個項目質(zhì)量。這類目標(biāo)太寬。Agent 會在錯誤方向上很努力。5.2 高風(fēng)險且不可回滾比如自動轉(zhuǎn)賬 自動刪生產(chǎn)數(shù)據(jù) 自動發(fā)送大規(guī)模營銷消息 自動改權(quán)限不是絕對不能自動化但不能只靠 loop。需要強審批、沙箱、審計和補償機制。5.3 難以驗證如果沒有成功標(biāo)準(zhǔn)Agent 只能自說自話這比不自動化更危險。5.4 人類其實想要判斷而不是執(zhí)行有些任務(wù)看似重復(fù)其實核心價值在判斷。比如定戰(zhàn)略、定價格、定組織調(diào)整。這種場景可以讓 Agent 準(zhǔn)備材料。不要讓它閉環(huán)決策。六、實戰(zhàn) Checklist把一個手動提示改成 Loop 前先檢查這十二項。1. Goal 是否寫成可驗證目標(biāo) 2. Trigger 是否清楚 3. Trigger 是否攜帶上下文 4. State 存在哪里 5. State 是否能恢復(fù)下一次運行 6. Action 是否分級 7. 哪些動作自動允許 8. 哪些動作必須審批 9. Verification 是否可執(zhí)行 10. 失敗后如何 retry / rollback / pause 11. 預(yù)算上限是什么 12. 如何向人類匯報結(jié)果和風(fēng)險如果這些答案都清楚Loop 才有資格進入長期自動化。七、最后Loop Engineering 不是把 prompt 重復(fù)運行也不是讓 Agent 一直跑。它的核心是圍繞目標(biāo)設(shè)計可持續(xù)執(zhí)行系統(tǒng)。Prompt 讓任務(wù)說清楚。Context 讓每一步看對信息。Harness 讓 Agent 有工具、權(quán)限、驗證和觀測。Loop 把這些能力變成持續(xù)運行的自動化。下一篇我們進入最容易翻車的部分長運行 Agent。因為 loop 一旦拉長三個問題會被放大上下文會斷。 目標(biāo)會漂。 成本會爆。參考資料Claude Code Docs: Routines and scheduled routinesOpenAI Agents SDK: Runner, sessions, handoffs and human-in-the-loopAnthropic: Effective Harnesses for Long-Running AgentsAnthropic: Long-running Claude for Scientific ComputingAnthropic: Building Effective AI Agents參考文獻第十三篇Loop Engineering從手動提示到目標(biāo)驅(qū)動自動化