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