凌晨兩點半線上告警把我和枕頭拆散打開日志一瞧又是空指針而且就在同事上周重構完的支付模塊里。這種時候我腦子里反復滾著一句話能不能寫個Agent讓它自己把bug給修了。說干就干這就是AutoDebug Agent的由來——一個基于真實運行反饋、能自主定位缺陷并生成修復方案的Agent項目。這里說的缺陷是軟件世界里的bug不是工業(yè)視覺里那種軸承、試管的外觀缺陷檢測。AutoDebug Agent做的是把一段真實的失敗信息丟給Agent讓它自己去復現(xiàn)、診斷、寫補丁、跑測試然后再根據(jù)新的測試結果決定是收工還是繼續(xù)修。它解決的是開發(fā)過程中最磨人的那部分——大量重復的、低級的、但又必須有人蹲在電腦前盯著的bug修復工作適合日常開發(fā)被bug反復糾纏的程序員、維護一堆歷史工程的老兵、想往CI/CD流水線里塞自動修復能力的DevOps以及想把Agent產(chǎn)品化成內部工具的技術負責人。1. 這個Agent到底在修什么核心思路與場景拆解1.1 為什么寫AutoDebug Agent它和其他自動化工具差在哪很多AI自動修復的演示是在精心準備的代碼庫里跑通一個預埋好的缺陷反饋也是設計好的跑通了就錄個視頻發(fā)出來。真拿這種思路去修真實項目里的bug基本會撞得頭破血流——真實世界里哪有那么多讀一遍代碼就能看出來的缺陷。AutoDebug Agent的思路不是讀代碼找bug而是讓Agent進入一個觀察-診斷-修復-驗證的閉環(huán)把每次代碼真實執(zhí)行產(chǎn)生的信號當成下一輪判斷的依據(jù)。用最簡單的話說它不是靠猜而是靠試。你給它一個失敗的測試它先看為什么失敗改完再跑一遍看是不是真的解決了沒解決就帶著新的失敗信息重新診斷。這跟傳統(tǒng)自動化測試工具有本質區(qū)別。靜態(tài)掃描工具能告訴你這里可能越界但它不會替你寫補丁再跑一遍回歸驗證。CI系統(tǒng)能把失敗的構建甩到你臉上但它不會自己動手把問題修好再重新提交。AutoDebug Agent真正想接手的是定位-修改-驗證這一整條動作鏈而不僅僅是發(fā)現(xiàn)。1.2 真實反饋是什么以及它為什么是會修的關鍵真實反饋是AutoDebug Agent標題里最關鍵的定語。什么是真實反饋就是代碼真實執(zhí)行之后產(chǎn)生的信號不是人腦模擬出來的理想輸出也不是人工標注好的標準答案。最典型的一類反饋是測試失敗信息。拿Python項目舉例pytest跑完一個用例失敗輸出里通常包含斷言實際值和期望值、拋異常的行號、堆棧里經(jīng)過哪些函數(shù)。這套信息對Agent來說就是雷達信號模型看到期望值是True實際值是False、看到traceback定位到某個文件它才有條件把問題和代碼位置關聯(lián)起來。除了測試輸出還有幾類反饋同樣重要編譯和類型錯誤TS類型不匹配、Rust借用檢查失敗、Go空指針解引用警告運行時堆棧和日志線上服務異常日志帶request_id和調用鏈上下文靜態(tài)分析告警lint規(guī)則觸發(fā)、安全掃描報告、復雜度告警版本控制歷史git blame、最近的提交記錄能告訴Agent這個文件最近被誰動過、改了什么用戶行為信息復現(xiàn)步驟、異常截圖、一句話描述尤其是UI類缺陷這些反饋的共同特點是它們是一手信息直接來自代碼運行的結果。讓Agent基于這些信號去修而不是基于它對代碼的感覺這是AutoDebug Agent區(qū)別于其他demo級Agent的本質差異。反饋的顆粒度直接決定了修復能力的上限。給Agent的信息越接近一個真實工程師調試時看到的信息它就越能做出靠譜的判斷。如果你只丟給它一個測試失敗的結論再強的模型也只能是在黑暗中瞎摸。1.3 適用場景和不適用場景先把丑話說前面我得先潑一盆冷水AutoDebug Agent不是萬能的也不是拿來替代程序員的。實測下來最適合的是這幾類場景單元測試和集成測試覆蓋較高的模塊覆蓋率至少60%以上否則反饋太稀疏Agent根本沒法定位異常類型明確的bug比如空指針、越界、超時、版本兼容性問題能在幾個文件范圍內定位的中小型缺陷修完之后有回歸測試可以驗證的模塊不適合的場景也很明確設計層面的架構問題比如緩存一致性設計錯了這不是一次修復循環(huán)能解決的跨十幾個服務、幾十張數(shù)據(jù)表的鏈路故障反饋信息爆炸而且大量缺失依賴外部硬件、特殊設備或真實用戶流的環(huán)境Agent沒法在本地復現(xiàn)完全沒有測試覆蓋的遺留系統(tǒng)一個文件三千行Agent盲修的風險極高這個工具的價值不是替代工程師而是把修bug這個動作里最耗時的可復現(xiàn)、可定位、可驗證環(huán)節(jié)壓縮到分鐘級。我在設計AutoDebug Agent時的目標很樸素讓Agent像實習生一樣先把能查的查了能改的改了把真正需要人類判斷的部分留給我。2. 技術架構與關鍵設計Agent的骨架怎么搭2.1 感知層把缺陷信息變成模型看得懂的輸入Agent要干活第一步是拿到它能用的信息。感知層是所有反饋信號的入口也是我最先設計、后來改動最多的模塊。設計原則只有一條把原始信號做結構化處理、壓縮體積、按診斷優(yōu)先級排序再喂給模型。原始信號是各種格式混雜的pytest輸出是純文本GitHub Actions日志是一大坨時間戳加著色控制字符線上日志是JSON堆棧是帶文件路徑和行號的多行文本。如果直接把拷貝的原始輸出丟給模型效果會非常差——上下文被無關信息塞滿模型反而找不到重點。我的做法分三步第一步歸一化。寫一組解析器把不同測試框架的失敗輸出轉成統(tǒng)一結構包括測試名稱、失敗類型、斷言詳情、堆棧列表。這一步的作用是把機器輸出變成結構化事件。第二步壓縮。堆棧按規(guī)則排序后只保留應用內代碼的frame刪除框架內部和第三方庫的frame日志按級別過濾保留ERROR和WARN去掉INFO和DEBUG的噪音。壓縮的目標是把原始10KB的反饋壓到2KB以內同時保住關鍵信息。第三步排序。把信息按診斷價值排序先給核心異常類型和消息再給出現(xiàn)異常的文件和行號接著是相關堆棧然后才是測試上下文和額外日志。模型讀token是有位置偏置的開頭的內容權重最高所以一定要把最該讓模型看到的東西放前面。這一步看起來不起眼但直接決定了后面修復循環(huán)能不能跑通。我的經(jīng)驗是80%的Agent失敗不是模型不夠聰明而是喂給模型的信息不對或不夠。2.2 決策與行動層修復循環(huán)的設計AutoDebug Agent的核心是一個修復循環(huán)像人的調試流程一樣分階段推進。第一步是復現(xiàn)。Agent拿到反饋后先嘗試運行相關測試或命令確認缺陷能不能復現(xiàn)。這個階段如果復現(xiàn)不了Agent應該停下來問人而不是瞎猜。第二步是診斷。模型基于反饋信息和代碼上下文生成假設指出最可能的根因。這個階段的輸出不直接是代碼而是自然語言的診斷結論包括證據(jù)和懷疑點。第三步是修復。根據(jù)診斷結論生成一個最小化代碼變更。我要求Agent盡量只改相關行不要順手重構不相關的代碼。第四步是驗證。跑測試、跑lint、編譯收集新的反饋。如果測試通過進入回歸檢查如果失敗帶著新反饋回到第二步形成循環(huán)。這個循環(huán)的本質是一個假設-驗證-修正的迭代過程。每輪迭代模型都根據(jù)最新的測試結果修正自己對根因的判斷。我把核心骨架寫成偽代碼def autodebug_fix_loop(issue, feedback_store, model, tools): context build_context(issue, feedback_store) for attempt in range(MAX_ATTEMPTS): if attempt 0: diagnosis model.diagnose(context, feedback_store.last_failure()) if diagnosis.get(unreproducible): return {status: needs_human, reason: 無法復現(xiàn)} else: diagnosis model.refine_diagnosis(diagnosis, new_feedback) patch model.generate_patch(diagnosis, codebase_context) if not validate_patch(patch): continue # 補丁語法都不對直接重來 apply_patch(patch) result run_tests_and_checks() if result.failed: new_feedback feedback_store.record(result) continue if run_regression().failed: # 當前測試過了但回歸掛了 new_feedback feedback_store.record(run_regression()) continue return {status: fixed, patch: patch, attempts: attempt 1} return {status: timeout, last_feedback: feedback_store.latest()}關鍵點在于循環(huán)不是無限跑的。我給MAX_ATTEMPTS設定默認值5最多嘗試五輪。原因有兩層一是每輪都會消耗token和計算資源二是從實踐中看五輪還修不好繼續(xù)下去大概率是模型在同一個錯誤假設里打轉不如收集好上下文交給人類。另一個設計細節(jié)是validate_patch這一步。不要直接讓模型生成的補丁覆蓋文件——先用AST解析、語法檢查甚至先看diff的改動范圍。語法不對立刻丟棄這個環(huán)節(jié)能攔截掉一大部分模型幻覺式輸出。2.3 記憶層讓Agent跨會話學習Agent記憶確實是能力提升的隱藏杠桿。AutoDebug Agent的短期記憶就是當前修復會話的上下文這沒問題真正有價值的是長期記憶。我自己的長期記憶實現(xiàn)思路是這樣的用一個向量庫或者簡單的JSON文件記錄三類經(jīng)驗。第一類是修復過的缺陷特征包括錯誤類型、發(fā)生在什么模塊、根因是什么、最后怎么修的。第二類是有用的命令和查詢模板比如查這個服務全部日志用grep -r order_id logs/這樣的固定模式。第三類是項目特有的約定比如這個倉庫提交前必須跑make format。每次修復成功后把這次的診斷結論和補丁摘要寫進記憶庫。下次遇到類似錯誤Agent先檢索記憶庫把歷史相似案例作為上下文注入。這個設計在積累幾十個案例后效果明顯相當于Agent在自己給自己加經(jīng)驗。記憶庫要防止臟數(shù)據(jù)。我只記錄經(jīng)過驗證的成功案例不記錄失敗嘗試。失敗的嘗試往往帶有誤導性會讓Agent把錯誤的修復路徑當成可能方案。2.4 安全邊界Agent能做什么、不能做什么搞Agent的人最容易忽略的就是安全邊界。AutoDebug Agent能執(zhí)行命令、能改代碼、能跑測試這在本地開發(fā)環(huán)境還好一旦接入CI或者給了它一定的倉庫權限風險立即放大。我做的第一道防線是沙箱執(zhí)行。Agent通過一個受限的runtime執(zhí)行命令只允許白名單內的操作跑測試、讀文件、改倉庫內文件、執(zhí)行git diff和git log。禁止網(wǎng)絡請求、禁止訪問其他目錄、禁止安裝系統(tǒng)級依賴。第二道防線是文件修改策略。補丁應用到真實代碼前先在臨時分支上應用、跑驗證、通過后再合回當前分支。我習慣用git stash加臨時branch的流程這樣即使Agent闖禍一條checkout就能完全恢復。第三道防線是審批門檻。涉及刪除、push、合入主干這些高影響操作全部停下來等人點確認。Agent可以當好實習生但不能讓它掌握發(fā)布權限。還有一點容易被漏超時控制。每條命令必須有超時上限比如跑測試最多10分鐘。沒有超時的Agent就像沒有辭退機制的實習生能把整個CI卡死。我見過把Agent掛在一條等待輸入的命令上拖了半個小時的場景別問我怎么知道的。3. 實操記錄從零搭一個能修缺陷的Agent3.1 環(huán)境準備與框架選型實際操作前先說環(huán)境。我建議的起步配置是Python 3.11以上寫Agent骨架本身用Python最順手一個支持工具調用的強模型目標是修復的代碼倉庫帶測試套件再加Docker或venv做沙箱?？蚣苓@塊我經(jīng)歷過三個階段最早直接用function calling手寫后來用LangChain現(xiàn)在留在自研輕量框架加LangChain組件混搭。這里先給結論如果你的目標是給一個特定倉庫做自動修bug沒有必要上大型編排器一個函數(shù)調用循環(huán)足夠了。起步階段需要的東西不多核心三個文件一個工具定義文件、一個修復循環(huán)主文件、一個反饋解析器目錄。工具定義文件負責給模型描述你能調用什么修復循環(huán)主文件控制整個流程反饋解析器目錄放各個測試框架的解析邏輯。3.2 核心代碼實現(xiàn)修復循環(huán)逐行拆解我把最核心的實現(xiàn)拆開講。第一步是工具定義以跑測試為例用function calling風格定義TOOLS [ { type: function, function: { name: run_test, description: 運行指定測試用例并返回 pytest 輸出, parameters: { type: object, properties: { test_path: {type: string, description: 測試文件或測試用例路徑} }, required: [test_path] } } }, { type: function, function: { name: read_file, description: 讀取倉庫內指定文件的指定行范圍, parameters: { type: object, properties: { path: {type: string}, start_line: {type: integer}, end_line: {type: integer} }, required: [path] } } }, { type: function, function: { name: apply_patch, description: 以 unified diff 格式應用代碼修改, parameters: { type: object, properties: { diff: {type: string} }, required: [diff] } } } ]主循環(huán)是核心部分實際代碼里要注意每個函數(shù)調用的結果必須完整存進消息歷史模型才能基于真實結果繼續(xù)推理。很多人寫Agent時犯一個錯誤只把工具調用的結果字符串塞進日志但忘了告訴模型這個結果是來自哪次調用、對應哪個動作。我建議每個工具調用結果前加一個結構化標記比如命令: pytest tests/test_user.py exit_code: 1 輸出: ...這樣模型能準確理解反饋和動作的對應關系。補丁應用和驗證環(huán)節(jié)同樣關鍵。模型輸出的patch可能格式不對需要專門的解析器把unified diff解析成實際的文件修改。我踩過的坑是模型會在patch里寫假的行號標記但實際diff內容對不上文件行數(shù)。這時不應該強套apply而應該直接把patch原樣返回給模型讓它重新生成。理解和容忍模型輸出的這種不穩(wěn)定性是寫Agent的基本功。3.3 接入真實反饋日志、測試、堆棧的一手處理接入真實反饋是AutoDebug Agent的重頭戲。以最常見的pytest場景為例測試運行后用subprocess拿到的輸出是這樣的import subprocess, json, re def run_tests(test_path): proc subprocess.run( [pytest, test_path, -p, no:cacheprovider, --tbshort], capture_outputTrue, textTrue, timeout600 ) return parse_pytest_output(proc.stdout proc.stderr)parse_pytest_output函數(shù)要提取以下字段失敗用例列表、每個失敗用例的斷言消息、截取的堆棧、異常類型比如AssertionError、IndexError。這個結構化結果會直接作為新反饋進入修復循環(huán)。我強烈建議把原始輸出也留一份在日志里方便人工排查時對照。接入線上運行時錯誤的思路也類似把錯誤日志、堆棧、關聯(lián)的上下文信息一起打包。關鍵點是讓反饋帶上時間和空間上下文而不是丟一個孤零零的異常消息。比如2025-01-15T02:30:00Z 服務order-svc 請求req_88ab2f1 出現(xiàn)KeyError: status比KeyError: status給模型的信號多得多。反饋處理管線做成一個獨立模塊后還可以做一件事給每種反饋類型打標簽。比如按編譯錯誤單元測試失敗集成測試失敗運行時崩潰靜態(tài)分析告警分類。這個標簽會作為上下文的一部分傳給模型讓它在診斷時知道當前面對的是什么性質的缺陷。3.4 評價指標與參數(shù)調整AutoDebug Agent跑起來之后你得知道它干得好不好。我用的評價指標有五項修復成功率驗證通過并完成回歸的patch數(shù)除以嘗試修復的問題總數(shù)平均修復輪數(shù)每次成功修復平均跑了多少輪回歸率通過了目標測試、但讓其他測試掛掉的patch比例單次修復耗時從輸入issue到輸出patch的平均分鐘數(shù)單次修復成本token消耗量直接關系成本這幾個指標相互關聯(lián)。比如壓低了平均修復輪數(shù)token成本自然下降但也可能提高回歸率追求高修復成功率就要允許更多輪迭代。我的默認參數(shù)是MAX_ATTEMPTS5temperature0.3top_p0.9。temperature太低容易機械重復太高容易發(fā)散。還有一個我觀察到的細節(jié)模型的診斷質量比直接生成patch質量更重要。與其讓模型直接給修復代碼不如先強制它用自然語言描述根因、列出證據(jù)、寫出驗證計劃再進入代碼生成。這一步相當于給模型一個思考工作區(qū)診斷質量上去了后面的patch質量會明顯提升。這也是AutoDebug Agent里Agent部分的核心價值——它不是一個單次生成的prompt工具而是有完整推理鏈的執(zhí)行者。4. 常見問題與排查技巧實錄4.1 反饋信號太弱Agent反復瞎改這是我遇到最多的失敗模式。Agent第一輪修復失敗后第二輪給出的patch跟第一輪幾乎一樣說明它沒有得到足以修正判斷的新信息。根因是反饋太稀疏比如日志只寫了測試失敗沒有具體斷言。排查思路是先看給Agent的反饋里到底有沒有差異信息。如果Agent已經(jīng)定位到某個函數(shù)但不知道函數(shù)內部實際執(zhí)行到哪一步可以在反饋里加入traceback的中間層。另一個有效手段是讓Agent自己加調試輸出——比如讓它往代碼里插臨時的print跑一次測試后再刪掉。這個方法在實踐中非常有用相當于把調試這個動作也交給了Agent。但要注意臨時調試輸出必須在最終patch里清除干凈。我有一條規(guī)則最終diff里不允許出現(xiàn)print、debugger關鍵字否則自動拒絕。這條規(guī)則把不少看起來修好了但其實是靠打印撐著的垃圾補丁擋在了門外。4.2 上下文塞滿了日志模型開始失憶長日志、大堆棧、多輪工具調用結果都會把上下文塞滿。模型失憶的癥狀是明明前面已經(jīng)定位到文件了后面生成patch時卻引用了錯誤的行號或者開始重復前面已經(jīng)試過的失敗方案。應對策略有兩個方向。第一是壓縮日志超出閾值后讓模型先做一個日志摘要把幾KB的原始輸出壓縮成關鍵的幾百字再進入下一輪。這個先總結再推理的兩階段法效果很好。第二是重構上下文結構不要無限追加對話歷史而是維護三個獨立槽位——問題描述、當前診斷結論、最近一輪反饋。每輪只把這三個槽位刷新給模型而不是把所有歷史消息全部丟進去。這樣上下文長度可控也符合人調試時的認知方式。4.3 誤修復測試過了但坑更深了這是AutoDebug Agent最危險的問題——目標測試通過了但Agent的修改破壞了別的行為或者把一個表面的斷言修成了更隱蔽的錯誤。我遇到過一個典型案例一個函數(shù)原本應返回列表Agent改成返回None恰好有個測試斷言結果為空時返回None于是過了單測但整個模塊的調用方全炸了。這類問題的核心是驗證范圍不夠。我的強制方案是目標測試通過后必須再做兩步。第一步跑當前文件所在的整個測試文件不只是失敗的那一條第二步有條件的話跑一次完整測試套件。另外提交前會要求Agent給出patch的安全自述解釋為什么這個改動是安全的、改動影響哪些模塊。這個自述會作為人工審查的參考。效果好但會增加一兩分鐘成本值得。4.4 安全和連接問題Agent會話、超時那些坑實操中還會遇到一類跟Agent本身運行環(huán)境有關的問題。比如某些Agent運行時在建立會話時會返回空標識和無效服務名的錯誤常見原因是服務端版本與客戶端不匹配、會話過期或者網(wǎng)絡鏈路不穩(wěn)定。這類錯誤往往不是Agent邏輯的問題而是基礎設施。我建議做好兩件事一是所有工具調用都帶超時和重試二是注意會話的持久化和恢復。Agent在中間斷了上下文丟失就只能從頭再來。給修復循環(huán)加一個checkpoint機制每輪結束后把上下文快照存下來重連時從最近一個快照恢復能省大量時間。沙箱環(huán)境還有一個容易被忽視的安全點不要給Agent無限的文件系統(tǒng)權限。我發(fā)生過一次Agent好心修改了配置文件的事故。從那以后我在apply_patch工具里強制加了路徑白名單檢查凡目標路徑不在倉庫目錄內的一律拒絕。這是成本極低的微調但能擋住很多低級事故。5. 工具選型與前沿參考站在現(xiàn)有框架和產(chǎn)品上做5.1 主流Agent框架怎么選LangChain、Dify、CrewAI做AutoDebug Agent之前我先研究了一圈現(xiàn)有框架。個人選型觀如下LangChain生態(tài)最全適合有工程能力、想深度定制的團隊。它的工具調用、記憶模塊都比較成熟但抽象層偏厚調試起來麻煩。尤其當你需要精確控制每輪上下文的時候反而會被框架束縛。Dify適合快速原型和業(yè)務側落地可視化編排讓你不用寫太多代碼就能搭一個Agent工作流。但它的抽象不太適合精細控制代碼修復這種高交互、多循環(huán)的任務。CrewAI擅長老多Agent協(xié)作比如讓診斷Agent和修復Agent分工。我試驗過把診斷和修復拆成兩個角色效果有一點但開銷翻倍收益不大后來還是合并成一個完整循環(huán)。我的選擇是用原生function calling寫核心循環(huán)必要時用LangChain的消息模型來管理歷史但不是整個流程都套框架。這種半自研的好處是核心邏輯完全可控壞處是需要自己維護一些邊緣邏輯?？紤]到要寫的是生產(chǎn)可用的工具可控性比省事重要。5.2 向Codex CLI與Claude Skills學什么產(chǎn)品化的編碼Agent給AutoDebug Agent提供了很好的設計參考。Codex CLI這類工具給我的啟發(fā)是命令行優(yōu)先的交互形態(tài)。它把Agent做成了終端里的一條命令開發(fā)者在代碼目錄里就能啟動拿到上下文后直接開始診斷和修改。AutoDebug Agent也應該保持這種最小侵入——不要求把整個開發(fā)流程搬到某個IDE或平臺而是作為一條命令、一個API接入現(xiàn)有工作流。我在實現(xiàn)時也選擇了類似的形態(tài)在倉庫根目錄執(zhí)行一條命令Agent自行讀取git狀態(tài)、定位最近變更、跑測試、開始修復循環(huán)。Claude Skills的思路更值得研究把技能看作可復用的、經(jīng)過驗證的能力單元。放到AutoDebug Agent里就是我可以把收集pytest反饋、檢查git歷史、運行靜態(tài)分析封裝成獨立的技能模塊并給每個技能寫清楚適用條件和輸出格式。這樣Agent在遇到特定場景時能精準調用而不是每次都在原始信息里重新摸索。技能化的另一個好處是可組合、可分享團隊里積累的調試技能可以沉淀下來復用。5.3 輕量自研 vs 大型編排器我的建議如果要給一個明確的建議我的答案是一開始不要先買來一堆框架先用最原始的function calling把修復循環(huán)跑通再根據(jù)痛點決定要不要引入更重的抽象。原因很現(xiàn)實Agent的核心是基于反饋做推理而不是編排了多少個節(jié)點。你拖出10個節(jié)點但如果每個節(jié)點喂給模型的信息都是一坨沒處理的原始日志效果還不如一條精心設計的循環(huán)?？蚣苣軒湍愎芾磉吘壡闆r但替代不了對反饋信號的處理。我自己現(xiàn)在保留了一個約300行的核心循環(huán)加上一堆針對不同測試框架的反饋解析器。它比任何框架都穩(wěn)定因為在那個循環(huán)里我知道每一步在干什么模型看到的每一條反饋我都親手驗證過格式。如果后續(xù)要擴展到多倉庫、多Agent協(xié)作再考慮把循環(huán)包裝成服務接入更完善的編排層不遲。我個人在實際項目里最深刻的體會是AutoDebug Agent這個東西真正的瓶頸不是模型而是反饋信號的質量和循環(huán)設計的穩(wěn)健性。你給Agent喂什么它就修什么你讓它在什么邊界內活動它就在什么邊界內靠譜。我給團隊交付這個工具的時候特意把無法復現(xiàn)就停下來問人和通過測試后必須跑全量回歸寫成兩條不可繞過的規(guī)則。踩過幾次坑之后這兩條規(guī)則救過我太多次。如果你也想搞一個自己的AutoDebug Agent建議從最小的修復循環(huán)開始先把反饋管好技能化封裝跟上再慢慢把邊界往外擴。等到你的Agent能穩(wěn)穩(wěn)地修完一批又一批歷史issue并且在修完的同時沒有引入新的坑你會覺得這幾十個小時的折騰值了。