最近我在折騰一個任務(wù)讓 AI Agent 像實習生一樣接到一個開發(fā)任務(wù)后自己完成“構(gòu)建→測試→修復(fù)→循環(huán)”直到把代碼交付到一個基本可用的狀態(tài)。聽上去挺科幻其實拆開之后就是一堆工程細節(jié)環(huán)境怎么初始化、命令怎么跑、報錯怎么喂給模型、改完代碼怎么驗證。真正動手做之后我最大的感受是——寫提示詞讓模型生成代碼太簡單了難的是讓整個流程在無人干預(yù)的情況下自己往前走。很多人分不清 Agent 和 LLM 的區(qū)別。常說的 DeepSeek、GPT、Claude 這些屬于大語言模型是“大腦”你問它問題它給你答案而 Agent 是“大腦手腳”它不僅能回答問題還能調(diào)用工具、執(zhí)行命令、讀取文件、根據(jù)結(jié)果決定下一步。構(gòu)建、測試、修復(fù)這個閉環(huán)恰恰需要的就是這一套行為循環(huán)。而且這里的“構(gòu)建”指的是軟件開發(fā)里的 build不是訓練 AI 模型那個“構(gòu)建模型”別搞混了。1. 先理清一個概念A(yù)gent 到底比大模型多干了什么1.1 模型只負責“說話”Agent 負責“動手”你直接問一個大語言模型“這段代碼哪里有問題”它能給你一份漂亮的答案但它不會自己打開終端更不會順手幫你把問題改了。Agent 不一樣它有完整的“感知—決策—行動”鏈路。感知讀取文件、執(zhí)行命令、捕獲輸出、解析狀態(tài)。決策把感知到的結(jié)果交給 LLM 分析LLM 給出“接下來該做什么”的判斷。行動修改文件、運行構(gòu)建命令、觸發(fā)測試、發(fā)起新的命令。這三步拼在一起就是一個循環(huán)。每一次循環(huán)的結(jié)束又變成下一次循環(huán)的開始。這也是標題里“循環(huán)”二字的本質(zhì)不是簡單地把同一條命令跑幾遍而是讓 Agent 在每次執(zhí)行后根據(jù)結(jié)果調(diào)整策略直到滿足退出條件。我習慣把 Agent 想象成一個剛?cè)肼毜膶嵙暽?。你只給他一個 KPI“把這個項目的構(gòu)建跑通、測試跑通。”他不會一次成功但他會自己看報錯、改代碼、再跑一遍。LLM 是他的腦子手和腳則由代碼里的函數(shù)和工具提供。1.2 開發(fā)閉環(huán)里 Agent 的三項核心能力要支撐“構(gòu)建→測試→修復(fù)→循環(huán)”Agent 至少要具備三項能力能力說明失敗表現(xiàn)工具調(diào)用執(zhí)行 shell 命令、讀寫文件、處理路徑卡在環(huán)境準備連依賴都裝不好錯誤理解從日志和堆棧里提取根因判斷問題類型亂改代碼把環(huán)境問題當代碼問題自主決策決定繼續(xù)修復(fù)還是停止提交陷入死循環(huán)燒掉大量 token這三個能力不是平行的而是遞進的。工具調(diào)用是基礎(chǔ)錯誤理解是智力自主決策是判斷力。沒有第二項第三項就是瞎判斷沒有第一項后兩項只能在紙面上高談闊論。網(wǎng)上很多“AI Agent 練手小項目”都在演示“生成代碼”但那離真正的“開發(fā)閉環(huán)”還很遠。生成代碼只是一個瞬間動作而開發(fā)是連續(xù)過程。你要的是 Agent 能在失敗之后自我修正而不是撞上南墻還繼續(xù)寫同一句修復(fù)。2. 構(gòu)建環(huán)節(jié)的自動化讓 Agent 自己準備環(huán)境、編譯、收集產(chǎn)物2.1 環(huán)境準備是最容易被低估的一步我見過太多 Agent demo 都假設(shè)環(huán)境已經(jīng)就緒Python 裝好了、依賴都在、路徑也對。現(xiàn)實項目里根本不是這樣缺少依賴、版本沖突、系統(tǒng)庫不對、環(huán)境變量沒設(shè)置任何一個都能讓構(gòu)建倒在第一關(guān)。所以構(gòu)建環(huán)節(jié)的第一步不是跑編譯命令而是“環(huán)境自檢”。我常用的檢查清單是這樣的檢查運行時版本python --version、node -v、java -version檢查依賴是否安裝pip list、npm ls --depth0安裝或更新依賴pip install -r requirements.txt、npm ci設(shè)置環(huán)境變量密鑰路徑、編譯緩存目錄這些動作最好由 Agent 自動完成但你必須在腳本里給一個“重試邏輯”。比如第一次pip install因為網(wǎng)絡(luò)失敗Agent 要能重試如果重試三次還失敗就上報“環(huán)境構(gòu)建失敗”而不是嘗試修改項目代碼。把環(huán)境問題和代碼問題分開是讓 Agent 高效工作的前提。我自己的習慣是在把 Agent 放進去之前先手動把環(huán)境調(diào)通一次。這不是多此一舉而是為了給 Agent 建立一條可預(yù)期的基線。當環(huán)境本身已經(jīng)可用時Agent 遇到構(gòu)建失敗就能大概率推斷是代碼或配置的問題而不是在環(huán)境泥潭里打轉(zhuǎn)。2.2 構(gòu)建輸出要“可喂給模型”而不是一堆亂日志構(gòu)建失敗時終端里輸出的內(nèi)容少則幾十行多則上千行。直接把這堆原始日志丟給 LLM結(jié)果就是上下文窗口被塞爆模型開始“失憶”甚至把無關(guān)的警告當成根因。我第一次這么做就吃了大虧——模型盯著一條 warning 分析了大半天真正的 error 被淹沒在幾百行輸出里。更有效的做法是先把構(gòu)建輸出預(yù)處理成一個標準化的“反饋模板”。這個模板要至少包含幾個字段[BUILD_STATUS]: FAILED [EXIT_CODE]: 1 [ERRORS]: - 文件 src/foo.py 第42行: TypeError: unsupported operand type syntax - 文件 src/bar.py 第17行: ModuleNotFoundError: No module named xxx [CONTEXT]: - 最近的命令: python -m build - 構(gòu)建目錄: /workspace/project你不需要把完整的build.log全部塞給 LLM可以把日志寫入文件然后在反饋模板里提煉出關(guān)鍵錯誤。如果 Agent 需要更多細節(jié)它可以通過工具讀取build.log的相應(yīng)行。這種“摘要按需查閱”的方式能大幅降低 token 消耗也能讓模型更專注于問題本身。2.3 清理舊構(gòu)建別讓 Agent 被舊產(chǎn)物騙了這是另一個高頻坑尤其是涉及編譯型項目時。上次構(gòu)建成功留下的.class、.jar、.o文件還在Agent 這次改了代碼但構(gòu)建步驟因為“沒有問題”而沒重新生成新產(chǎn)物結(jié)果測試跑的是舊的東西整個循環(huán)都在假象里打轉(zhuǎn)。我在每個構(gòu)建動作之前都會強制清理rm -rf dist build .pytest_cache *.egg-info mvn clean即使你不用 Agent在 Jenkins 這類 CI 環(huán)境里也記得清理 workspace。熱詞里提到“jenkins構(gòu)建清理”其實就是同一件事舊產(chǎn)物不刪新測試就沒有意義。對 Agent 來說清理動作尤其重要因為它沒有人類那種“看到舊文件時的警惕心”。你必須在循環(huán)腳本里寫明構(gòu)建前先清理日志按時間戳命名只讀取最新一份日志。我還會把舊日志一起清掉避免 Agent 在讀取文件時翻到上一個循環(huán)的失敗信息產(chǎn)生誤判。典型案例是第一次失敗是因為缺依賴第二次已經(jīng)修好了但 Agent 從舊日志里看到了同樣的錯誤誤以為還在斷點于是重復(fù)執(zhí)行相同的修復(fù)動作。3. 測試環(huán)節(jié)的智能化核心不是跑用例而是“翻譯失敗”3.1 失敗信息的分層設(shè)計測試輸出是所有環(huán)節(jié)里信息量最大的。pytest、JUnit、Go test 都會給出大量細節(jié)包括用例名、斷言、堆棧、截圖。但對 Agent 來說原始文本并不是越詳細越好關(guān)鍵是“結(jié)論先行證據(jù)靠后”。我把測試反饋設(shè)計成兩層第一層摘要。例如3 passed, 2 failed in 12.33s。第二層失敗用例詳情。包括用例 ID、失敗原因、觸及的代碼位置。比如[TEST_STATUS]: FAILED [SUMMARY]: 15 passed, 2 failed in 1.42s [FAILED_CASES]: - tests/test_auth.py::test_login_returns_200 REASON: assert 500 200 FILE: app/auth.py:45 in login - tests/test_cart.py::test_add_item_when_cart_full REASON: ValueError: Cart capacity exceeded FILE: app/cart.py:112 in add_item這比把整個pytest --tblong的輸出丟給模型要清晰得多。模型只需要讀到前幾行就能知道“哪里炸了”如果它還需要看詳細的堆棧再通過工具打開測試報告文件也不遲。3.2 什么樣的失敗信息 Agent 最容易理解我自己揣摩出一點模型最容易理解的失敗信息是“現(xiàn)象—期望—實際”三要素齊全的信息?，F(xiàn)象是“哪個用例掛了”期望是“本應(yīng)該是什么結(jié)果”實際是“程序到底給了什么結(jié)果”。舉兩個例子差的信息assert False好的信息test_login_returns_200 failed: expected status 200, got 500差的信息只告訴模型斷言失敗但沒告訴它為什么失敗。好的信息則直接指向問題類型狀態(tài)碼從預(yù)期值變成了非預(yù)期值大概率是接口處理出錯而不是路由不存在。要讓 Agent 能自動修復(fù)測試用例本身也要寫得足夠“會說話”。這算是一個額外收益為了喂給 Agent你可能要把項目里的斷言寫得比平時更明確。3.3 從“測試通過”到“測試有價值”之間還差一個覆蓋率如果項目本身的測試很薄弱Agent 跑完整個循環(huán)也只是“假綠”。構(gòu)建過了、測試過了但業(yè)務(wù)邏輯可能完全沒被驗證。所以我在閉環(huán)里加了一步自動統(tǒng)計代碼覆蓋率低于閾值不讓循環(huán)退出。這個閾值可以按項目調(diào)整個人建議先定一個保守的 60%70%。低于這個值A(chǔ)gent 就必須停下來補充新的測試用例再繼續(xù)循環(huán)。這一步會把 Agent 的定位從“修 bug 的工具”變成“真正維護代碼質(zhì)量的程序員”。但請注意讓 Agent 補充測試用例比讓它修復(fù)源碼更難。因為它需要先理解原有模塊的行為再設(shè)計出合理的斷言。如果你的項目太過復(fù)雜我建議第一階段只做“構(gòu)建跑測試修復(fù)”覆蓋率提升放到第二階段。一口吃不成胖子循環(huán)也是一樣。4. 修復(fù)環(huán)節(jié)要求 Agent 先講根因再動手改代碼4.1 如何告訴 Agent“現(xiàn)在出了什么問題”修復(fù)環(huán)節(jié)的 prompt 不能是“請修復(fù)這個錯誤”這種空泛指令。我給 Agent 的指令模板是結(jié)構(gòu)化的至少包含你是這個項目的維護者。 當前構(gòu)建/測試失敗信息如下 [FEEDBACK] 請完成以下步驟 1. 分析失敗根因用不超過5句話說明問題出在哪里。 2. 提出修改方案明確修改哪些文件、怎么改。 3. 執(zhí)行修改但嚴禁修改測試文件和配置文件。 4. 修改后重新運行構(gòu)建和測試。為什么非要讓它先“說明根因”因為模型在決策時如果跳過推理直接產(chǎn)生補丁很容易輸出一種“看著合理但沒解決根本問題”的垃圾修復(fù)。讓它先寫根因等于強制它的評論邏輯參與到生成過程中。實際跑下來只要根因分析靠譜修復(fù)動作大概率也靠譜。4.2 限制修復(fù)范圍與回歸風險Agent 最容易犯的一個錯誤是“打地鼠式修復(fù)”為了通過眼前這個測試偷偷改了另一個模塊的常量或者加了全局異常捕獲把所有異常都吞掉。這種修復(fù)表面上讓測試變綠實際上把問題埋得更深。對付這個問題我在循環(huán)腳本里加了兩個約束修改文件的名稱必須出現(xiàn)在 Agent 自己的修復(fù)方案里。如果 diff 里出現(xiàn)了“聲明外的文件”直接報錯終止。遍歷測試套件時如果任何一個原來通過的用例在修復(fù)后失敗了立即回滾這次修改并把回歸信息反饋給 Agent。聽起來很簡單但實際執(zhí)行很有效。Agent 學會了一個教訓不能為了一個失敗用例去破壞其他用例。最終它給出的修復(fù)往往更保守也會更小心地觸碰共享函數(shù)。4.3 環(huán)境問題與代碼問題要分開處理我見過最浪費時間的場景是 Agent 花了好幾輪去“修復(fù)”環(huán)境問題。比如 Windows 環(huán)境里常見的api-ms-win-crt-runtime-l1-1-0.dll報錯或者kernel32.dll相關(guān)異常這根本不是你項目代碼的問題而是系統(tǒng)運行庫缺失或缺 VC 運行環(huán)境。Agent 如果在代碼層面找征兆無論怎么改都是白費勁。所以我在循環(huán)腳本里加了一步“錯誤分類”代碼類錯誤語法錯誤、類型錯誤、斷言失敗、模塊缺失對當前項目而言環(huán)境類錯誤系統(tǒng)庫缺失、運行時版本不對、依賴沖突、權(quán)限不足如果判斷是環(huán)境類錯誤Agent 應(yīng)當執(zhí)行“環(huán)境修復(fù)”動作比如安裝運行庫、切換 Node 版本、更新依賴。只有識別為代碼類錯誤才走正常的“源碼修復(fù)”路徑。這一步細化之后循環(huán)的無效輪次減少了至少一半。5. 循環(huán)控制讓 Agent 知道什么時候收手而不是無限試錯5.1 終止條件不是“全部通過”而是“連續(xù)失敗 N 次就?！崩碚撋涎h(huán)可以一直跑到所有測試都通過。但實際中有些問題就是修不好的——根因可能是需求矛盾也可能是 Agent 已經(jīng)把代碼改得面目全非。如果一直讓它試它會在同一個死胡同里反復(fù)。我在代碼里設(shè)置了兩類終止條件成功條件構(gòu)建成功測試全部通過且覆蓋率達標。失敗條件連續(xù)兩次失敗反饋里的“錯誤位置”完全相同并且 Agent 給出的修復(fù)方案沒有產(chǎn)生任何有意義的變化或者總迭代次數(shù)超過 5 次。我傾向于用“連續(xù)相同錯誤”來判斷死循環(huán)而不是只盯次數(shù)。因為如果錯誤每次都不一樣說明 Agent 還在探索可能再試一次就會見效。如果錯誤完全一樣那就說明當前策略失效繼續(xù)下去只是燒錢。5.2 給整個循環(huán)加一個“時間預(yù)算”很多 Agent 項目只考慮次數(shù)忽略了時間成本。一次構(gòu)建可能要幾分鐘一套完整測試可能要十幾分鐘模型推理也要時間。你的等待時間會呈指數(shù)級膨脹。我會在循環(huán)入口加上兩個預(yù)算總執(zhí)行時間預(yù)算比如整個任務(wù)最多 20 分鐘超時立即中斷把當前狀態(tài)寫成報告。LLM 調(diào)用次數(shù)預(yù)算比如最多調(diào)用 10 次模型因為每次調(diào)用都會產(chǎn)生 token 費用。這兩個預(yù)算不是等循環(huán)真正超時才生效而是每次進入循環(huán)前先檢查剩余配額如果配額不足就提前終止“修復(fù)嘗試”把部分通過的狀態(tài)交給人工處理。這能有效防止一次實驗燒掉幾百塊 token 費用。5.3 成本控制壓縮反饋、限制修改次數(shù)、合并測試報告LLM 的 token 費用在 Agent 循環(huán)里是主要開銷之一。我在跑了幾十輪后總結(jié)出三個省錢要點壓縮反饋把原始日志和測試輸出全部重定向到文件只把結(jié)構(gòu)化的“錯誤摘要”給 LLM通?？刂圃?200500 字符。限制修改動作每次修復(fù)前只允許 Agent 針對相關(guān)文件生成 diff不要讓它全倉庫搜索、打印無關(guān)文件內(nèi)容。把工具調(diào)用限定在白名單里。合并測試報告如果一次跑了多個模塊的測試只把失敗模塊的摘要合并傳輸不要把所有模塊的通過統(tǒng)計都塞進提示詞。這三個要點直接決定了閉環(huán)的經(jīng)濟性。沒有它們循環(huán)就是吞金獸有了它們一次完整閉環(huán)的 token 消耗可以控制在一次普通對話的幾倍以內(nèi)。6. 一個最小可復(fù)現(xiàn)的“構(gòu)建-測試-修復(fù)”循環(huán)骨架6.1 主循環(huán)邏輯如果你也想搭一個最小閉環(huán)我建議不要一上來上重量級框架先用一個 Python 腳本把循環(huán)撐起來。下面是我落地過的一個骨架# minimal_agent_loop.py import subprocess from datetime import datetime MAX_ROUNDS 5 TIMEOUT_MINUTES 20 def run_cmd(cmd, timeout120): return subprocess.run( cmd, shellTrue, capture_outputTrue, textTrue, timeouttimeout ) def build(): # 清理舊產(chǎn)物確保這次構(gòu)建是干凈的 run_cmd(rm -rf dist build .pytest_cache) result run_cmd(python -m build, timeout300) return result.returncode 0 def test(): result run_cmd(pytest --tbshort -q, timeout300) return result, result.returncode 0 def fix(feedback): # 調(diào)用 LLM 接口得到 diff 或直接修改文件 # 這里省略具體實現(xiàn)核心是讓模型根據(jù) feedback 生成補丁 prompt build_feedback_prompt(feedback) return generate_and_apply_patch(prompt) def main(): start_time datetime.now() for round_idx in range(MAX_ROUNDS): # 時間預(yù)算檢查 elapsed (datetime.now() - start_time).total_seconds() if elapsed TIMEOUT_MINUTES * 60: return TIMEOUT if not build(): feedback parse_build_error(build.log) else: result, ok test() if ok: return SUCCESS feedback parse_test_summary(result.stdout) print(f[ROUND {round_idx}] {feedback}) # 修復(fù)動作把反饋轉(zhuǎn)換成補丁 fix(feedback) # 判斷是否卡死對比最近兩輪的錯誤位置 if round_idx 0 and same_position(feedback, prev_feedback): return STUCK prev_feedback feedback return FAILURE這個骨架沒有依賴任何 Agent 框架只要你自己接一個 LLM 調(diào)用函數(shù)就能跑。它最大的價值是把“循環(huán)”這個抽象概念變成了看得見的代碼構(gòu)建失敗就解析構(gòu)建日志測試失敗就解析測試摘要然后丟給模型生成補丁再回到下一次循環(huán)。6.2 反饋模板示例為了讓這個骨架工作反饋模板必須穩(wěn)定。我建議統(tǒng)一成下面這種格式方便寫parse_*函數(shù)[ROUND 2/5] [STATUS]: TEST_FAILED [SUMMARY]: 3 passed, 1 failed in 1.42s [FAILED_CASE]: tests/test_auth.py::test_login_returns_200 [REASON]: assert 500 200 [PINPOINTED_FILE]: app/auth.py [PINPOINTED_LINE]: 45只要這個模板生成穩(wěn)定LLM 的修復(fù)準確率會明顯提升。你不會希望 Agent 為了理解“到底哪里出問題”還要自己去字符串里大海撈針。6.3 跑通后的運行效果以我的一個真實小項目為例初始跑構(gòu)建失敗反饋指向缺失依賴Agent 調(diào)用了pip install第二輪構(gòu)建通過但測試失敗一條用例 500 vs 200Agent 定位到auth.py的返回值處理邏輯修復(fù)后測試通過第三輪覆蓋率檢查發(fā)現(xiàn)低于閾值A(chǔ)gent 補了一個測試用例第四輪全部通過循環(huán)結(jié)束。整個過程大約花了 12 分鐘調(diào)用 LLM 三次。這就是一個典型的“構(gòu)建→測試→修復(fù)→循環(huán)”閉環(huán)。它并不酷炫但很實在——它證明了 Agent 可以在少量人工干預(yù)下自主完成一段開發(fā)任務(wù)。7. 我實際跑下來的幾個坑和調(diào)整思路7.1 坑一把完整日志丟給 AgentToken 爆掉導(dǎo)致“失憶”第一次跑我圖省事直接把 pytest 輸出和構(gòu)建日志全部塞給 LLM。結(jié)果上下文窗口很快就被幾千行日志占滿模型開始“失憶”連自己上一輪修了什么都不知道。更離譜的是它開始從日志的警告部分找問題忽略真正的錯誤行。解決方案就是前面說的寫一層解析器把日志壓縮成結(jié)構(gòu)化反饋。這一步不是可選的而是必須的。如果你要做真正的 Agent 閉環(huán)請把 80% 的工程量放在反饋解析上而不是放在寫 prompt 上。解析做得好后面所有環(huán)節(jié)都順。7.2 坑二修復(fù)后忘了重新構(gòu)建測試跑在舊產(chǎn)物上寫 Java 或 C 項目時遇到過這個問題。Agent 改了源碼我沒有強制“先重建再測試”結(jié)果測試直接跑舊的.class或.jar。更誤導(dǎo)的是舊產(chǎn)物里碰巧也有那條測試用例但測的完全是上一版代碼。我現(xiàn)在的做法是在主循環(huán)里把“構(gòu)建”和“測試”合并成一個執(zhí)行單元。無論當前步驟是否只改了一行注釋只要腳本走到測試環(huán)節(jié)就強制先跑一次清理重建。雖然有時會多花一點時間但能保證測試結(jié)果的可靠性。7.3 坑三Agent“為了過測試”而繞過了原有的斷言這個坑非常隱蔽。有一輪測試要求接口返回200Agent 修改了業(yè)務(wù)邏輯后還是500于是它直接在視圖函數(shù)里寫死了status200測試通過了但它沒有檢查數(shù)據(jù)是怎么生成的。這種“作弊式修復(fù)”會掩蓋真實的業(yè)務(wù)故障。我加了兩個預(yù)防措施第一修復(fù)方案里禁止修改測試用例也不允許跳過斷言第二循環(huán)結(jié)束后額外檢查 diff如果看到像return Response(, status200)這類硬編碼直接被人工問責。更重要的是我會同時檢查測試通過之外的數(shù)據(jù)正確性指標但這屬于更高階的玩法了。7.4 我的最終建議如果你也想動手復(fù)現(xiàn)這條閉環(huán)別急著把公司里復(fù)雜的微服務(wù)搬進來。先找一個只有幾十個文件的小項目最好是你自己熟悉的然后寫一個最小循環(huán)跑通它。第一次運行大概率會失敗但每一個失敗都是學習——你會知道哪里解析不合理哪里反饋不夠清晰哪里循環(huán)條件太寬松。等這個小閉環(huán)跑順了再逐步提高復(fù)雜度最終把它接到真實的 CI/CD 流程里。我現(xiàn)在已經(jīng)習慣把“構(gòu)建、測試、修復(fù)”三個動作封裝成獨立的函數(shù)任何項目來了都能套用同一套循環(huán)骨架。這種工程化的 Agent 應(yīng)用方式比在一行 prompt 里賭模型發(fā)揮要可靠得多。