1. 為什么要讓 Agent 自己跑完開發(fā)閉環(huán)先說個實際的場景。很多團隊現(xiàn)在已經(jīng)讓 AI 幫著寫代碼了但寫出來的代碼總是要有人接手去構(gòu)建、去跑測試、去修失敗。修完之后再跑一輪可能又掛了再修再跑。這么一個“構(gòu)建→測試→修復(fù)→循環(huán)”的過程如果全靠人肉盯著那 AI 寫代碼省下來的那點時間又全填回調(diào)試?yán)锪?。我自己最早接觸這個概念是在做一個內(nèi)部工具的時候團隊產(chǎn)出越來越快可 CI 上的紅燈越來越頻繁每天光看構(gòu)建失敗日志就占用大量精力。后來我干脆把整條鏈路交給一個 AI Agent 去跑——它負(fù)責(zé)構(gòu)建、它負(fù)責(zé)發(fā)現(xiàn)問題、它負(fù)責(zé)提修復(fù)甚至它負(fù)責(zé)確認(rèn)自己改對了沒有。效果比預(yù)期好很多不是說它能一次把所有問題都修完而是它能把人從重復(fù)性的“看日志→猜原因→改代碼→重新跑”里徹底解放出來。這篇文章想跟你聊的就是怎么把“構(gòu)建→測試→修復(fù)→循環(huán)”這八個字落成一個真實的、可運行的 AI Agent 工作流。內(nèi)容適合已經(jīng)在用 LLM 寫代碼的開發(fā)者也適合在做 CI/CD 流水線優(yōu)化的人。我會把我實際搭過的方案、踩過的坑、以及一些不太容易在文檔里找到的細節(jié)全部攤開講。這里使用的核心關(guān)鍵詞是 AI Agent、構(gòu)建、測試、修復(fù)、循環(huán)。先把這幾個詞串起來理解AI Agent 是大腦構(gòu)建是入口測試是裁判修復(fù)是動作循環(huán)是流程。2. Agent 驅(qū)動開發(fā)閉環(huán)的架構(gòu)設(shè)計2.1 這個閉環(huán)到底是什么很多人一聽到“AI Agent 自己跑開發(fā)閉環(huán)”第一反應(yīng)是是不是讓 AI 完全替代程序員不是的。這里說的閉環(huán)指的是讓 Agent 在一個受限的范圍里自動完成“寫代碼→驗證→修復(fù)→再驗證”的循環(huán)直到通過預(yù)定義的驗收標(biāo)準(zhǔn)或者達到某個退出條件。一個典型的閉環(huán)包含這幾個環(huán)節(jié)構(gòu)建Agent 在給定代碼庫上執(zhí)行構(gòu)建命令比如mvn compile、npm run build、python -m build。構(gòu)建失敗信息是 Agent 后續(xù)行動的輸入。測試構(gòu)建通過后Agent 接著運行測試集。測試可以是已有的測試套件也可以是 Agent 根據(jù)需求新生成的測試用例。修復(fù)Agent 分析失敗原因定位到相關(guān)文件生成修復(fù)補丁。循環(huán)修復(fù)后再次執(zhí)行構(gòu)建和測試如果還是失敗基于新的失敗信息繼續(xù)修復(fù)。這里的關(guān)鍵不是“Agent 能寫多少代碼”而是“Agent 能不能可靠地收斂”。如果它一直在同一個錯誤上打轉(zhuǎn)或者越改越亂那這個閉環(huán)就是失敗的。所以架構(gòu)設(shè)計的重心不是在“調(diào)用大模型的能力”上而是在如何為 Agent 構(gòu)建一個良好的“感知—決策—行動”循環(huán)。2.2 核心組件拆解我梳理了一下一個能真正跑起來的閉環(huán)至少需要五個組件。缺一個循環(huán)就有斷層。第一個是代碼倉庫工作區(qū)。Agent 需要一個隔離的、干凈的工作目錄。不能直接在主干分支上修代碼否則一次錯誤的修復(fù)可能污染整個倉庫。最好用臨時分支或者臨時目錄Agent 每次修改都生成 patch由外部系統(tǒng)決定要不要合入。第二個是執(zhí)行器。Agent 本身不直接執(zhí)行命令而是通過執(zhí)行器調(diào)用構(gòu)建工具和測試工具。執(zhí)行器需要捕獲命令的輸出、退出碼、耗時等元數(shù)據(jù)并把它們結(jié)構(gòu)化之后回傳給 Agent 的上下文。第三個是事件日志系統(tǒng)。這個組件是我強烈建議加的。記錄每一次嘗試的情況包括命令、輸出摘要、退出碼、Agent 的決策、生成的補丁內(nèi)容。不光是用來排查問題還能在 Agent 陷入循環(huán)時給人工介入提供判斷依據(jù)。第四個是 Agent 運行框架。這個框架負(fù)責(zé)編排整個流程。它會告訴 Agent 當(dāng)前處于哪個階段、下一步應(yīng)該做什么、有哪些約束。它的核心是一套狀態(tài)機狀態(tài)之間有明確的切換條件。第五個是大模型接口層。這是大家最熟的部分但也是導(dǎo)致很多 Agent 跑不起來的重災(zāi)區(qū)。API 的穩(wěn)定性、token 成本、上下文長度管理都要在這一層處理。把這五個組件事先捋清楚后面寫 Agent 邏輯的時候就會順很多。我見過不少項目一上來就寫 prompt結(jié)果跑兩步就卡住再回頭補結(jié)構(gòu)反而更浪費時間。2.3 為什么 LLM 不等于 Agent說到 AI Agent很多人會誤以為“接一個大模型的 API 就是 Agent”。這也是熱搜詞里“agent 和 llm 和 ai模型 有什么區(qū)別”這個問題出現(xiàn)頻率高的原因。LLM 是一個靜態(tài)的知識映射器。你給它一段輸入它給你一段輸出它本身不具備持續(xù)行動的能力。而 Agent 不一樣它有循環(huán)、有工具調(diào)用、有內(nèi)外狀態(tài)反饋、有目標(biāo)驅(qū)動的行為規(guī)劃。用一個不太嚴(yán)謹(jǐn)?shù)芎美斫獾念惐萀LM 像是一個很聰明的實習(xí)生你問他問題他答得頭頭是道但 Agent 更像是一條流水線——它把一個大的任務(wù)拆開每完成一步就檢查一次結(jié)果然后根據(jù)檢查結(jié)果決定下一步動作。所以在這個閉環(huán)里L(fēng)LM 承擔(dān)的是“生成修復(fù)建議”、“生成代碼 diff”、“解讀失敗日志”這些具體動作而 Agent 框架承擔(dān)的是狀態(tài)流轉(zhuǎn)、條件判斷、退出機制、工具調(diào)用等控制邏輯。兩者缺一不可。2.4 工具選型與執(zhí)行環(huán)境在實際落地時執(zhí)行環(huán)境怎么選直接影響閉環(huán)的穩(wěn)定性。我用的比較多的是 Docker 容器方案。為什么要用容器因為構(gòu)建環(huán)境、測試依賴、系統(tǒng)庫版本這些必須得鎖定。同一個項目本地跑得好好的一上 CI 就掛往往就是環(huán)境差異導(dǎo)致的。Docker 的執(zhí)行方式也很簡單Agent 通過 Docker SDK 啟動一個容器容器內(nèi)掛載代碼目錄執(zhí)行預(yù)設(shè)命令然后把日志和退出碼返回給 Agent。有一點要注意容器不要用特權(quán)模式尤其當(dāng)代碼倉庫是不可信來源時要給容器加上資源限制比如 CPU、內(nèi)存、磁盤配額。理由是防止 Agent 在循環(huán)中跑出一些失控的測試程序把宿主機資源打滿。另外對于測試環(huán)境我建議盡量用真實環(huán)境。少用 mocks。原因很直接Agent 修代碼依據(jù)的是測試的失敗信息如果測試用的 mock 和真實行為差太遠那修復(fù)出來的代碼很可能是錯的。比如一個接口返回數(shù)據(jù)格式變了mock 里面還是舊格式那測試永遠測不出這個 bugAgent 自然也就無從修起。在編程語言的選擇上我沒做太多限制。Python、Java、Node 項目都跑過。關(guān)鍵在于你的 Agent 框架要能適配不同語言的構(gòu)建工具。拿我自己寫的框架來說構(gòu)建命令不是硬編碼的而是通過項目文件自動識別的看到pom.xml就調(diào) Maven看到package.json就調(diào) npm看到pyproject.toml就調(diào) pip 加 pytest。這樣一套體系可以覆蓋大多數(shù)主流項目。3. 構(gòu)建環(huán)節(jié)的實現(xiàn)讓 Agent 看見失敗3.1 構(gòu)建信息的結(jié)構(gòu)化解構(gòu)構(gòu)建環(huán)節(jié)是整個閉環(huán)的入口也是最容易被低估的一環(huán)。很多 Agent 項目失敗不是修代碼的能力不行而是對構(gòu)建失敗信息的理解太淺。先說說通常的執(zhí)行結(jié)果長什么樣。一個構(gòu)建命令跑完無非三種結(jié)果成功、失敗、異常中斷。成功最好處理直接進入測試階段。異常中斷比如超時、內(nèi)存溢出、環(huán)境錯誤這種通常不是代碼問題Agent 就不該去改代碼。真正需要重點處理的是失敗——但失敗的信息非?！芭K”。你拿到的是一大坨終端輸出里面混著編譯錯誤、警告、日志、堆棧甚至還有一些無關(guān)的裝飾性字符。如果直接把這一大坨全部塞給 LLM有幾個問題。第一是 token 消耗巨大一次失敗日志幾百上千行幾次循環(huán)下來上下文就爆了。第二是噪音太大真正有用的錯誤信息被淹沒模型容易“跑偏”。所以我在這個環(huán)節(jié)做的事情是把原始輸出結(jié)構(gòu)化成幾條核心信息。這一條我會詳細展開因為直接影響后面修復(fù)階段的效果。三條核心信息分別是錯誤類型、錯誤位置、錯誤描述。錯誤類型用來區(qū)分是語法錯誤、類型錯誤、依賴錯誤、還是測試斷言失敗。這個分類決定了 Agent 后續(xù)的修復(fù)策略。比如依賴錯誤可能需要改配置而不是改代碼測試斷言失敗則要先看斷言邏輯再決定是修產(chǎn)品代碼還是修測試代碼。錯誤位置通常包括文件路徑和行列號。很多構(gòu)建工具已經(jīng)把這些信息打印出來了比如File.java:42: error: cannot find symbol。這些信息要單獨提取出來作為 Agent 定位代碼的錨點。錯誤描述就是真正說明原因的那句話。像 Java 里的cannot find symbol、Python 里的NameError: xxx is not defined、前端構(gòu)建里的Module not found: xxx這些一看就能大概猜到問題方向。結(jié)構(gòu)化工作做在前面后面 Agent 的決策質(zhì)量會高很多。實操中可以通過兩個思路來做要么寫正則提取要么直接調(diào)用構(gòu)建工具的 JSON 輸出模式。像 TypeScript 編譯器有--json參數(shù)ESLint 也有 JSON 格式輸出能拿到結(jié)構(gòu)化數(shù)據(jù)就盡量用。3.2 構(gòu)建失敗的分級響應(yīng)策略有了結(jié)構(gòu)化的信息還不夠你得給 Agent 定義“什么情況下該做什么事”的分級響應(yīng)策略。這是我反復(fù)調(diào)整后總結(jié)出來的經(jīng)驗。我把構(gòu)建失敗分成三個級別。初級單文件語法錯誤、缺失 import、拼寫錯誤。這類問題修復(fù)風(fēng)險低Agent 可以直接改不用請示。中級跨文件接口變更、依賴版本沖突、構(gòu)建腳本問題。這類問題建議讓 Agent 先出一份修復(fù)方案再動手改方案里有風(fēng)險說明。高級構(gòu)建環(huán)境異常、系統(tǒng)級依賴缺失、權(quán)限問題。這類問題 Agent 不應(yīng)該碰代碼直接中止并通知人來處理。這個分級機制看起來簡單但在實際效果上非常顯著。沒有分級之前Agent 碰到任何錯誤都會嘗試改代碼結(jié)果遇到系統(tǒng)級問題改了一通代碼根本不是問題根源浪費好幾輪循環(huán)。有了分級Agent 在“行動”之前先判斷“該不該行動”路徑清晰多了。3.3 依賴管理與本地倉庫準(zhǔn)備構(gòu)建失敗的另一個高頻原因是依賴問題。代碼在開發(fā)者本地能編譯但在 Agent 的工作區(qū)里報“包找不到”十有八九是依賴緩存沒有準(zhǔn)備好。我踩過一個大坑在構(gòu)建環(huán)節(jié)沒有做依賴預(yù)熱Agent 第一次構(gòu)建時下載依賴花了十幾分鐘然后超時了它就以為是代碼問題瘋狂改 codepointer結(jié)果越改越亂。正確的做法是分兩步。第一步提前構(gòu)建一個帶依賴緩存的鏡像或工作區(qū)。比如 Java 項目先跑一遍mvn dependency:go-offline把依賴?yán)玁ode 項目用npm ci安裝完后把node_modules做成快照Python 項目用pip cache加上預(yù)裝虛擬環(huán)境。這個工作在 Agent 循環(huán)開始之前做一次性投入。第二步給 Agent 的執(zhí)行環(huán)境加上網(wǎng)絡(luò)策略。如果項目依賴都是內(nèi)部倉庫確保容器能訪問內(nèi)部鏡像源如果項目依賴的是公網(wǎng)包那就讓容器有必要的默認(rèn)路由。但我個人建議盡量把依賴層面的事情放在前置準(zhǔn)備階段不要在 Agent 的循環(huán)過程中頻繁訪問網(wǎng)絡(luò)。4. 測試環(huán)節(jié)Agent 的質(zhì)檢員4.1 測試套件的接入與選擇構(gòu)建通過之后Agent 要面對的就是測試。測試在這里起到質(zhì)檢員的作用——它決定了 Agent 的修復(fù)到底算不算有效。測試套件的選擇不是越大越好而是要跟“修復(fù)驗證”這個目標(biāo)匹配。這個點是我在實際跑閉環(huán)后深刻體會到的。最開始我把整個項目能跑的測試全塞給 Agent單測、集成測試、端到端測試全跑。結(jié)果就是每次修復(fù)都要跑好久而且失敗信息五花八門有時候是集成測試掛了Agent 跑去修單測的邏輯改了半天單測過了集成還是掛反饋太慢收斂效率極低。后來我調(diào)整了策略把測試分成兩個層級。第一層級是快速驗證層。只跑跟改動文件有直接關(guān)聯(lián)的測試用例優(yōu)先用測試覆蓋率掃描出來的關(guān)聯(lián)關(guān)系。比如改了一個 Python 函數(shù)就只跑調(diào)用這個函數(shù)的那幾個測試文件里的用例。這一層講究的是快一兩分鐘內(nèi)要能給出來結(jié)果用于判斷基礎(chǔ)修復(fù)是否生效。第二層級是完整回歸層。全部測試跑一遍用于最后驗收。這一層慢但是必須跑防止 Agent 在修復(fù)一個 bug 的時候破壞了別的東西。這個分層的邏輯其實跟人開發(fā)時做“先跑局部測試再看全部回歸”是一樣的只不過 Agent 需要你用代碼把這種決策固化下來。4.2 測試失敗信息的二次加工測試失敗信息的處理比構(gòu)建失敗信息更講究。原因是測試失敗通常不是“編譯不過”這么直接而是跟斷言邏輯強相關(guān)。你經(jīng)常會看到一堆 assertEquals 失敗的信息拿給 Agent 看它可能自作聰明地覺得“既然測試期望的值是 A而實際是 B那我把測試改成 A 不就過了嗎”——這就是經(jīng)典的“作弊修復(fù)”。為了避免這個問題我對測試失敗信息做了一層“可信度標(biāo)注”的處理。分兩步第一步如果某個測試用例在本次修復(fù)之前就已經(jīng)失敗了歷史失敗那這個失敗信息對 Agent 來說是不可信的不參與當(dāng)前修復(fù)的反饋。因為可能是之前那個迭代引入的問題Agent 參考它會得到錯誤的方向。第二步如果某個測試用例是本次“因為 Agent 的修改”而失敗的也就是上次通過、這次掛了那這個失敗信息才是 Agent 需要重點關(guān)注的。為了拿到這個信息你需要記錄每一個測試用例在歷次循環(huán)中的執(zhí)行結(jié)果做一次差分。這個數(shù)據(jù)結(jié)構(gòu)類似{用例ID: [上一次結(jié)果, 這一次結(jié)果]}。如果出現(xiàn)[PASS, FAIL]就是“回歸失敗”Agent 必須處理如果是[FAIL, FAIL]就說明這個用例一直沒修復(fù)好Agent 需要繼續(xù)修但同時也說明 Agent 的修復(fù)方案可能沒到位。這個二次加工的邏輯很多人會忽略但它對 Agent 決策質(zhì)量的影響是決定性的。沒有這層差分Agent 就像一個沒有歷史記憶的測試工人每次都從零開始判斷完全無法利用“這個用例之前是過的”這條關(guān)鍵線索。4.3 測試提示詞的設(shè)計技巧如果你用的是 LLM 來生成測試用例——比如給 Agent 布置“為這個功能補充單元測試”的任務(wù)——那提示詞的設(shè)計就有講究了。我不推薦上來就寫“請為這個函數(shù)寫測試”這種太寬泛生成出來的測試往往是套模板的廢代碼。我一般會用三層提示結(jié)構(gòu)。第一層是任務(wù)目標(biāo)明確指定測試對象和方法。比如“針對order_service.py中的create_order函數(shù)用 pytest 編寫單元測試覆蓋正常下單、庫存不足、用戶不存在三個場景”。第二層是基線約束指定測試的預(yù)期行為。比如不能改變業(yè)務(wù)代碼來將就測試、不能 mock 被測函數(shù)本身、測試數(shù)據(jù)要使用獨立的臨時數(shù)據(jù)源等。這些約束可以在一定程度上抑制 Agent 的“作弊”傾向。第三層是成功標(biāo)準(zhǔn)。告訴 Agent 什么樣的測試算完成測試全部通過才算完成如果業(yè)務(wù)代碼有 bug 導(dǎo)致測試失敗不要修改業(yè)務(wù)代碼來掩蓋問題而是報告問題。這一節(jié)有一個經(jīng)驗可以直接抄在使用這條 prompt 之后我需要隨后運行一次覆蓋率工具看看 Agent 生成的測試有沒有真正覆蓋到關(guān)鍵分支。不要依賴 Agent 自己的描述。覆蓋率工具不會說謊。5. 修復(fù)環(huán)節(jié)讓 Agent 擁有“靠譜的動手能力”5.1 修復(fù)補丁的生成與落地修復(fù)環(huán)節(jié)是整個閉環(huán)里技術(shù)含量最高的部分。Agent 需要在理解失敗原因的基礎(chǔ)上生成一個可以落地的補丁。這個補丁必須滿足三個條件格式正確、改動最小、效果可驗證。格式正確這一點很多人會忽略。實際場景里L(fēng)LM 生成的修復(fù)代碼直接應(yīng)用到代碼庫上經(jīng)常出現(xiàn)縮進錯亂、語法殘缺、甚至文件編碼問題。所以我建議不要把 LLM 輸出的文本直接當(dāng)作補丁而是交給一個統(tǒng)一的補丁服務(wù)去處理。我的做法是讓 Agent 輸出標(biāo)準(zhǔn) diff 格式之后用git apply來應(yīng)用。在應(yīng)用之前先做一次 dry-run 檢查是否可以干凈合入。如果無法合入報錯反饋給 Agent讓 Agent 基于沖突信息重新生成。改動最小是第二個約束。很多 LLM 在修復(fù)的時候容易“發(fā)揮過度”比如修復(fù)一個函數(shù)順手把整個文件的格式調(diào)了一遍修復(fù)一個 bug順手重構(gòu)了相鄰模塊。這種超出范圍的改動在 CI 合入時會造成大量沖突也讓 review 變得困難。我加的約束是只允許修改與失敗原因直接相關(guān)的行其他改動一律不允許。第三個約束效果可驗證這個已經(jīng)在測試環(huán)節(jié)覆蓋了。Agent 修復(fù)完必須跑相關(guān)的測試來證明修復(fù)有效。不能讓 Agent 修完就交差沒有驗證的修復(fù)只是猜測。5.2 避免“越改越亂”的機制“越改越亂”是 AI Agent 自動化修復(fù)中最大的痛點。具體現(xiàn)象就是Agent 修好了 A 問題又把 B 弄壞了再修 B又把 A 弄壞了。典型振蕩。我做了兩個機制來壓低這個概率。第一個機制是“修改前快照”。每次 Agent 嘗試修復(fù)之前先把當(dāng)前工作區(qū)的狀態(tài)做一個快照。如果這一次修復(fù)導(dǎo)致的可通過測試數(shù)比上一次少了那就回滾到上一次的快照讓 Agent 在干凈的基礎(chǔ)上重新?lián)Q一個修復(fù)策略。第二個機制是“差異限制”。計算 Agent 本次修改的 diff 行數(shù)如果超過預(yù)設(shè)閾值比如 30 行就要求 Agent 解釋為什么需要這么大的改動并把解釋和 diff 放入人工評審隊列。它本身就是一個認(rèn)知偏誤的糾正機制——大改動往往是因為 Agent 沒有準(zhǔn)確定位問題。這兩個機制加在一起讓 Agent 的振蕩收斂速度明顯提升。你可以把整個循環(huán)失敗率降到可接受的范圍關(guān)鍵是不要讓一個失敗“滾雪球”。5.3 修復(fù)策略的上下文管理還有一個經(jīng)常被忽視的技術(shù)細節(jié)上下文管理。Agent 在修復(fù)的時候它的輸入包括失敗日志、文件內(nèi)容、測試報告、上次修復(fù)的記錄等。如果這些信息全部塞進 prompt很容易超長而且大量的舊信息會干擾模型對當(dāng)前問題的判斷。我做了兩層處理。第一層是“只保留最近兩輪”的信息。比如 round 3 的決策只看 round 2 的失敗信息和 round 3 自己改了什么更早的信息通過摘要帶入不要全量堆在 prompt 里。第二層是“定向提取文件片段”。因為 Agent 要修改的文件可能很大我不會把整個文件傳給模型而是根據(jù)失敗信息里的行列號和符號名用 AST 解析出相關(guān)函數(shù)或類的代碼片段只把這段代碼給 Agent 看。這兩層處理讓修復(fù)階段的輸入變得很精煉模型判斷也更聚焦。實測下來相同任務(wù)下token 消耗降低了約一半而且修復(fù)成功率反而更高——因為信息噪音少了。6. 循環(huán)控制如何優(yōu)雅地停在一個好結(jié)果上6.1 退出條件的設(shè)定循環(huán)不是無限轉(zhuǎn)的你得給 Agent 設(shè)定退出條件。這是我個人認(rèn)為整個閉環(huán)設(shè)計中最需要經(jīng)驗的地方。太寬松的退出條件比如“只要測試全綠就算完成”會放大假裝有效的風(fēng)險。太嚴(yán)格的退出條件比如“任何失敗都不允許”會讓循環(huán)無法收斂。我實際采用的是一組三元退出條件成功退出所有測試通過構(gòu)建正常Agent 在預(yù)設(shè)輪次內(nèi)完成。放棄退出達到了最大嘗試輪次比如 5 次仍然有失敗項。危險退出出現(xiàn)了不可控的異常比如 Agent 不斷修改同一個函數(shù)但結(jié)果越來越差、或者測試環(huán)境本身崩了。第三種退出條件很多時候會被遺漏但它恰恰是防止 Agent 把項目改壞的關(guān)鍵。我自己最開始搭的時候只設(shè)了前兩種結(jié)果有一次 Agent 在一個錯誤上來回橫跳了十個輪次把項目狀態(tài)搞得一團糟。加了危險退出檢測之后只要檢測到“上一輪失敗項數(shù)量 前一輪失敗項數(shù)量 1”且連續(xù)發(fā)生三次就立即熔斷標(biāo)記為高危失敗人工介入。6.2 循環(huán)過程中的成本控制成本控制也是不可回避的話題。調(diào)用大模型 API 是有費用的而 Agent 的自動循環(huán)會放大調(diào)用量。每輪循環(huán)Agent 可能要調(diào)用 3 到 5 次大模型——一次解釋失敗日志一次生成修復(fù)方案一次處理測試反饋有時候還要再調(diào)用一次處理補丁沖突。十輪下來調(diào)用量相當(dāng)可觀。我做了三件事來壓成本。第一啟用緩存機制。把相同或高度相似的請求做緩存比如相同的一份失敗日志就不要重復(fù)丟給模型解析直接復(fù)用上一次的結(jié)構(gòu)化結(jié)果。實際場景里構(gòu)建失敗在循環(huán)中重復(fù)出現(xiàn)的概率非常高。第二設(shè)置模型分級。便宜的普通模型做首次分析復(fù)雜的修復(fù)策略生成用強模型。不要一個模型打天下。這個策略的效果挺明顯大約能省 30% 到 40% 的開銷。第三限制單輪上下文長度。每輪循環(huán)盡量把輸入控制在模型輸入窗口的一半以內(nèi)避免因為超長要求額外擴容計費也減少模型在長上下文中的“健忘”問題。6.3 與 CI/CD 流水線的集成方案最后說一下這個閉環(huán)如何和現(xiàn)有的 CI/CD 流水線結(jié)合。我見過兩種主流方式。第一種是“后置觸發(fā)器”模式。流水線跑完后如果發(fā)現(xiàn)失敗就觸發(fā) Agent 閉環(huán)來處理。注意這里的實現(xiàn)要點流水線必須輸出可解析的失敗報告而不是只有一堆打印日志。Agent 需要的是結(jié)構(gòu)化信息比如失敗用例列表、對應(yīng)代碼位置、是編譯失敗還是測試失敗。這種方式適合從不穩(wěn)定的項目起步讓 Agent 處理最容易處理的失敗。第二種是“前置門禁”模式。在代碼合入之前Agent 先跑一輪完整的“構(gòu)建→測試→修復(fù)→驗證”確定沒有潛在問題后再合入。這種模式對 Agent 的質(zhì)量要求更高也不太適合剛從零開始的項目。我個人的建議是先從后置觸發(fā)器模式開始跑。讓 Agent 處理那些被 CI 抓到的基本錯誤比如低級語法問題、資源泄漏、缺失邊界判斷。這些修復(fù)是小而明確的Agent 的效果會很好。等 Agent 在閉環(huán)上穩(wěn)定了再逐步擴大它的職責(zé)范圍。7. 實操案例一個 Python 項目的完整閉環(huán)光講架構(gòu)不夠這一節(jié)用一個真實的 Python 項目作為示例展示從零構(gòu)建這個閉環(huán)的過程。7.1 項目背景與初始狀態(tài)這個項目是一個簡單的“用戶積分管理系統(tǒng)”代碼量不大只有一個模塊points_service.py。我用它來驗證閉環(huán)的可行性是因為它的邏輯足夠簡單問題卻不簡單有幾個明顯的 bug比如用戶積分可能變成負(fù)數(shù)、數(shù)據(jù)庫鎖競爭導(dǎo)致死鎖、以及一個接口參數(shù)沒有做類型校驗。初始狀態(tài)下我寫了一批測試用例大部分能過但有三個用例失敗。我的目標(biāo)是讓 Agent 自己跑完構(gòu)建、測試、修復(fù)、再驗證的過程把這三個失敗用例修到全綠。7.2 Agent 的啟動指令與首次循環(huán)我給 Agent 下達的指令簡化如下你的工作目錄是/workspace/project網(wǎng)關(guān)命令是python -m pytest tests/ -x構(gòu)建命令是python -m compileall .。你的任務(wù)讓所有測試通過。每次修復(fù)后重新執(zhí)行測試命令以確認(rèn)結(jié)果。第一輪循環(huán)中Agent 執(zhí)行了構(gòu)建命令編譯失敗并沒有出現(xiàn)——這個項目語法上是好的。接著執(zhí)行了 pytest拿到了第一個失敗用例的堆棧test_negative_balance報錯 “ValueError: Insufficient balance”。Agent 分析后認(rèn)為問題出在deduct_points()函數(shù)沒有做余額校驗。于是它修改了函數(shù)在扣減前加了一個if balance points: raise ValueError(...)的判斷。第二輪循環(huán)測試執(zhí)行結(jié)果test_negative_balance通過但另一個用例test_concurrent_deduction掛掉了。它是有意設(shè)計的一個復(fù)雜場景兩個線程同時扣減需要保證數(shù)量一致。這時候 Agent 面臨一個典型困難并發(fā)問題的修復(fù)光靠“發(fā)現(xiàn)在賦值前后加鎖”很容易忽略鎖粒度。第一版修復(fù)它只是在deduct_points函數(shù)內(nèi)部加了一個threading.Lock()但鎖是每次調(diào)用都新建的等于沒有鎖測試還是失敗。7.3 第二輪循環(huán)中的修復(fù)優(yōu)化第三輪循環(huán)Agent 拿到第二次失敗的堆棧測試期望最終積分為 0實際卻是負(fù)數(shù)。這說明兩個線程的讀取和寫入交錯執(zhí)行了。Agent 這次意識到了問題把鎖提升為模塊級單例并對整個“讀余額→扣減→寫回”操作包成臨界區(qū)。第四輪循環(huán)測試全部通過。第三個用例test_invalid_user_id實際上在第一輪就被 Agent 順手修復(fù)了——它看到函數(shù)入口缺少類型校驗自己加了一個if not isinstance(user_id, int)的判斷。這個案例的過程非常清晰地展示了 Agent 閉環(huán)的價值不是一次就能把代碼改對而是通過“失敗→分析→修復(fù)→再失敗→再分析→再修復(fù)”的循環(huán)逐步逼近正確解。7.4 案例復(fù)盤Agent 表現(xiàn)好與不好的瞬間復(fù)盤這個案例有幾個細節(jié)值得展開。好的方面Agent 在沒有人工干預(yù)的情況下識別了三個獨立問題的修復(fù)優(yōu)先級沒有出現(xiàn)來回橫跳。這是因為它能看到每個測試用例的獨立狀態(tài)而不是只看“測試總量”。不好的方面在并發(fā)修復(fù)的那一輪Agent 第一次的鎖方案是不對的但它沒有能力提前判斷。真正讓它收斂的是“循環(huán)中看到測試失敗→生成新的修復(fù)嘗試→再驗證”的過程。這也印證了我的觀點Agent 的修復(fù)質(zhì)量是循環(huán)淘汰出來的不是一次生成出來的。另外有一點很關(guān)鍵Agent 在這個項目里的角色被限制在了“修代碼讓測試通過”而不是讓它自己重新設(shè)計整個系統(tǒng)的架構(gòu)。這個限制是必要的。如果讓 Agent 自由發(fā)揮它很可能把整個模塊重新寫一遍引入大量不相關(guān)的變更反而讓驗證失效。8. 遇到的問題與排查技巧8.1 構(gòu)建環(huán)境不一致導(dǎo)致的假失敗這是我跑第一個 Agent 閉環(huán)時遇到的高頻問題。本地構(gòu)建通過Agent 環(huán)境里構(gòu)建失敗。排查之后發(fā)現(xiàn)原因是 Agent 容器的 Python 版本比項目目標(biāo)版本低語法解析失敗了。解決的思路有兩個。第一個思路是把“構(gòu)建環(huán)境鎖定”前置化。在啟動 Agent 之前用項目自帶的環(huán)境配置文件比如requirements.txt、pyproject.toml、.nvmrc生成一個標(biāo)準(zhǔn)的鏡像和環(huán)境再做快照。第二個思路是給 Agent 的構(gòu)建命令前面加一個環(huán)境自檢步驟。自檢內(nèi)容包括系統(tǒng)版本、解釋器版本、依賴包版本。如果自檢失敗Agent 停止一切修復(fù)行為直接上報環(huán)境問題。為什么這個環(huán)節(jié)要單獨設(shè)置一個“不得修改代碼”的規(guī)則因為環(huán)境問題不屬于業(yè)務(wù)代碼 bugAgent 修改代碼無法解決而且很可能引入新問題。按照我之前講的分級響應(yīng)策略這就是典型的高級問題。8.2 測試用例不穩(wěn)定Flaky Test的干擾Flaky Test也就是測試本身不穩(wěn)定時好時壞是 Agent 閉環(huán)里最讓人頭疼的問題之一。原因很簡單Agent 基于測試結(jié)果做決策如果結(jié)果本身不穩(wěn)定Agent 的決策就失去了依據(jù)。它可能這次修好了下次跑又是失敗于是又修一遍修完又多出一堆無意義的改動。我應(yīng)對這個問題的方式是在“結(jié)果差分”模塊里增加一個標(biāo)記機制。同一個用例在連續(xù)兩輪中出現(xiàn)了 PASS/FAIL/PASS 這種模式就自動標(biāo)記為“不穩(wěn)定用例”從 Agent 的決策依據(jù)中降權(quán)。同時把它單獨放到一次“干擾排除”任務(wù)里去跑不再讓 Agent 基于它的結(jié)果繼續(xù)修復(fù)。這類問題的另一個處理思路是給測試用例加穩(wěn)定化改造。比如消除隨機數(shù)、固定時間種子、避免真實網(wǎng)絡(luò)調(diào)用、設(shè)置超時。這些都是測試工程里老生常談的方法但在 Agent 閉環(huán)里它的意義更多了一層——你不想讓 Agent 在無用信息上浪費輪次。8.3 模型幻覺導(dǎo)致的錯誤修復(fù)LLM 修復(fù)代碼時偶爾會“一本正經(jīng)地胡說八道”。最典型的是Agent 聲稱某個文件需要加一個不存在的模塊然后在代碼里寫了一個完全不存在的 API 調(diào)用。測試當(dāng)然繼續(xù)失敗Agent 看到失敗后再編一個理由再改陷入死循環(huán)。針對這類問題我做了兩件事。第一在 Agent 的修復(fù)指令中加入一條硬性約束不得使用項目中不存在的依賴、API、類或方法。如果引用了新的依賴必須先更新依賴配置文件否則視為非法修改。第二加強驗證環(huán)節(jié)的反饋。當(dāng) Agent 的修復(fù)包含不存在的符號時運行完測試后把報錯信息“Cannot find module”或者“ImportError”完整反饋給 Agent。讓它在下一輪中基于真實的報錯去修正而不是靠記憶去猜。這兩件事都是為了讓 Agent 的“決策依據(jù)”盡量來自真實環(huán)境反饋而不是來自模型的內(nèi)部先驗知識。說到底Agent 修復(fù)代碼的本質(zhì)是“試探—驗證”的循環(huán)模型幻覺只能讓試探變慢但只要你讓驗證的反饋足夠清晰和結(jié)構(gòu)化Agent 最終還是會走到正確方向上的。8.4 長時間運行的上下文失控一個復(fù)雜的修復(fù)任務(wù)Agent 可能需要跑十幾輪循環(huán)。每輪循環(huán)都會產(chǎn)生大量的中間信息包括失敗日志、測試輸出、生成的補丁、分析結(jié)論。如果不做上下文管理token 會很快超限而 Agent 會進入“記憶錯亂”狀態(tài)——它開始引用之前幾輪的錯誤信息而不是當(dāng)前這輪的真實信息。我前面講過的“只保留最近兩輪信息”是一個基礎(chǔ)手段。這里再補充一個更細的技巧在進入每一輪修復(fù)之前強制 Agent 生成一份“當(dāng)前狀態(tài)摘要”包含三塊內(nèi)容已經(jīng)修改了哪些文件、當(dāng)前剩余的失敗用例清單、基于最近一次失敗信息得出的下一步計劃。摘要生成后前幾輪的完整歷史就可以被清理掉只保留這份摘要作為新上下文的起點。這樣處理之后上下文長度始終是可控的而且模型的“決策狀態(tài)”也被壓縮得更干凈。這個操作在 Agent 框架里叫“狀態(tài)壓縮”或者“記憶摘要”它對于跑長鏈任務(wù)的 Agent 幾乎是一種必須的手段。8.5 補丁沖突與修改回滾Agent 在連續(xù)多輪修改后可能會在同一個文件的多個位置留下修改痕跡。此時如果再生成一個新的補丁補丁和當(dāng)前文件狀態(tài)可能沖突。受限于大模型的上下文限制它也未必能記住每個位置現(xiàn)在是什么狀態(tài)。我的應(yīng)對策略是放棄“讓 Agent 記住所有狀態(tài)”的思路轉(zhuǎn)而“在補丁應(yīng)用之前強制刷新狀態(tài)”。具體來說每一輪修復(fù)開始之前Agent 都會基于當(dāng)前磁盤上的文件實際內(nèi)容重新生成補丁而不是基于上一輪輪結(jié)束時它記憶中的文件快照。這樣可以降低補丁應(yīng)用失敗的概率。如果沖突還是發(fā)生我不會讓 Agent 直接重試修改而是讓它重新解析當(dāng)前文件內(nèi)容再重新生成補丁。沖突發(fā)生時干燥運行一次確認(rèn)沒有沖突再正式應(yīng)用。這套機制非常簡單但極其有效。8.6 常見問題速查表現(xiàn)象可能原因處理方式構(gòu)建失敗但本地通過Agent 環(huán)境與開發(fā)環(huán)境不一致前置環(huán)境自檢、鎖定鏡像版本同一測試忽好忽壞Flaky Test標(biāo)記不穩(wěn)定用例從決策依據(jù)中降權(quán)Agent 引用不存在的 API模型幻覺硬性約束不存在的依賴必須先改配置上下文越跑越亂循環(huán)過多信息堆疊每隔幾輪做一次狀態(tài)摘要清理歷史補丁應(yīng)用報沖突基于舊記憶生成補丁每輪強制刷新磁盤狀態(tài)再生成補丁循環(huán)中出現(xiàn)大量無意義修復(fù)目標(biāo)不明確檢查退出條件和本輪目標(biāo)定義測試全綠但功能實際上還是壞的測試覆蓋不足檢查覆蓋率補充關(guān)鍵分支測試9. 經(jīng)驗總結(jié)與擴展方向9.1 不要一上來就追求全自動我記得效果最好的跑法不是“扔給 Agent 一個項目讓它自己從頭到尾做完”而是先把閉環(huán)鏈路拆成幾個可控的環(huán)節(jié)每個環(huán)節(jié)單獨驗證。先驗證“構(gòu)建失敗信息能不能結(jié)構(gòu)化成 Agent 看得懂的輸入”再驗證“Agent 生成的補丁能不能干凈合入”最后再逐步放開循環(huán)輪次。這個階段很像訓(xùn)練一個新來的同事先給固定的、簡單的小任務(wù)等它對環(huán)境熟悉了再把更大的事情交出去。盲目追求一步到位到最后只會讓排查問題時無從下手。9.2 構(gòu)建失敗信息是 Agent 最好的老師如果把整個閉環(huán)的運轉(zhuǎn)比作一場手術(shù)那構(gòu)建失敗信息就是手術(shù)臺上的監(jiān)測儀。信號越清晰手術(shù)就越安全。所以在這套體系里真正要花時間打磨的不是讓大模型的 prompt 更花哨而是把構(gòu)建和測試的輸出整理成 Agent 能快速理解的決策依據(jù)。9.3 讓 Agent 自己記錄自己的每一步我給 Agent 加過一個指令每一輪修改之后必須用一句話說明自己改了什么、為什么改、期望解決什么問題。這些記錄會自動寫入到運行日志里同時也是后續(xù)人工介入時的參考依據(jù)。實際效果是Agent 每做一件事之前都會先想清楚邏輯日志的可用性大大提升。9.4 這個閉環(huán)還能怎么擴展如果你已經(jīng)跑通了這個閉環(huán)下一步可以考慮幾個擴展方向。第一個方向是多語言支持。把構(gòu)建、測試、補丁校驗這些能力抽象成與語言無關(guān)的接口讓同一個 Agent 框架能對接 Python、Java、Go 等不同生態(tài)。第二個方向是多 Agent 協(xié)作。不是讓一個 Agent 從構(gòu)建盯到修復(fù)而是拆分成“構(gòu)建檢測 Agent”和“修復(fù) Agent”——前者專職分析失敗原因后者專職生成補丁再有一個“驗證 Agent”收尾。這個模式在處理大型項目時會更有優(yōu)勢因為每個 Agent 的上下文負(fù)載都更小。第三個方向是沉淀修復(fù)知識庫。把 Agent 每次成功修復(fù)的問題類型、修復(fù)策略、涉及的模式存下來在后續(xù)類似問題上直接做相似度匹配大幅減少試錯輪次。這個方向我覺得很有意思本質(zhì)上是在給 Agent 積累“項目經(jīng)驗”。我自己的體會是AI Agent 跑開發(fā)閉環(huán)這條路越走越像在帶實習(xí)生你對反饋質(zhì)量和邊界定義得越清楚它就越靠得住你越是偷懶、越是讓它自由發(fā)揮后面收拾爛攤子的成本就越高。構(gòu)建→測試→修復(fù)→循環(huán)這套閉環(huán)的價值不是讓 Agent 替你聰明而是讓 Agent 在一次一次反饋中變得可靠。把它當(dāng)成一條工程流來建設(shè)才是它真正能落地的關(guān)鍵。