3個月燒掉200萬，他們終于搞懂AI編程代理不是加長版ChatG

2024年Q3，某北美SaaS團隊花了87天、燒掉23萬美元，最后把項目回滾到Cursor自動補全。復盤會上CTO的原話是：「我們以為在造鋼鐵俠，結果焊了輛會說話的輪椅。」

這不是孤例。Sebastian Buzdugan——前Stripe工程師、現AI infra創業者——在Medium發文稱，他訪談了17個嘗試自研編碼代理的團隊，14個卡在同一個認知陷阱：把代理當成「上下文更長的ChatGPT」。

真正的工程級編碼代理，架構上更像一個「感知-決策-執行-驗證」的閉環系統。Buzdugan拆解了這個loop的五個必選項，以及兩個大多數團隊漏掉的隱藏關卡。

第一關：任務接口不是聊天框，是「工單系統」

初級團隊常犯的錯誤，是把用戶輸入直接塞進大模型。Buzdugan的建議是：先做一個結構化的任務接收層（Task Interface），把模糊需求翻譯成機器可執行的規格。

他舉了個具體例子。用戶說「修復登錄頁面的bug」，代理需要自動追問：復現步驟？影響版本？優先級？關聯工單號？這些元數據決定了后續整個執行鏈的資源分配。

更隱蔽的陷阱是輸出格式。Buzdugan強調，代理返回的結果必須包含「可驗證的完成標準」——不是一段代碼，而是一個測試用例列表、一個部署預覽鏈接、或者一個需要人工確認的驗收清單。

「沒有驗收標準的交付，等于沒有交付。」他在文中寫道。

第二關：代碼記憶不是向量檢索，是「分層緩存」

大多數團隊把「記憶」理解為RAG（檢索增強生成，Retrieval-Augmented Generation）——把代碼庫切成chunk塞進向量數據庫。Buzdugan認為這遠遠不夠。

他提出的分層模型包括三層：文件級快照（當前編輯狀態）、模塊級依賴圖（調用關系）、項目級語義索引（業務概念映射）。代理在不同決策階段，需要動態切換讀取的粒度。

舉個例子。當代理接到「把用戶積分系統遷移到新數據庫」的任務時，第一層告訴它哪些文件被鎖定編輯；第二層告訴它積分計算函數被哪些服務調用；第三層告訴它「積分」在業務語境里等同于「忠誠度積分」而非「數學積分」。

Buzdugan沒有給出具體實現代碼，但他提到一個驗證指標：代理能否在零人工干預的情況下，識別出「這個修改會影響賬單系統的折扣計算」——這需要跨模塊的語義關聯，而非簡單的文本相似度匹配。

第三關：執行引擎不是單次調用，是「可回滾的事務」

這是Buzdugan認為最被低估的組件。編碼代理的每一次「行動」——讀文件、寫代碼、跑測試、調API——都必須被封裝成原子操作，支持撤銷和重試。

他對比了兩種失敗場景。場景A：代理改了5個文件后測試失敗，手動回滾花了40分鐘。場景B：代理在第3個文件就檢測到lint錯誤，自動撤銷并換策略，總耗時90秒。差距不在模型能力，在執行層的容錯設計。

關鍵機制包括：文件系統快照（pre-action checkpoint）、依賴變更的級聯追蹤、以及失敗時的「降級策略庫」——比如從「批量重構」降級為「最小侵入式補丁」。

Buzdugan特別提到，Git的staging area是現成的參考模型。「你的代理應該能像git add -p那樣，對變更進行選擇性提交和回滾。」

第四關：驗證層不是跑測試，是「多維度守門」

測試通過≠任務完成。Buzdugan列了一個四維驗證矩陣：語法正確性（lint/type check）、行為正確性（測試覆蓋）、安全合規性（依賴漏洞掃描）、以及業務一致性（與需求文檔的diff比對）。

最有趣的是第四維。他建議接入產品需求管理工具（如Jira/Linear），用LLM做「需求-實現」的語義對齊檢查。代理需要回答：這段代碼是否覆蓋了工單里所有的驗收條件？是否有額外的、未經批準的變更？

一個細節：Buzdugan反對讓代理自己判斷「是否完成」。他設計了一個「置信度閾值」機制——當代理的自我評估置信度低于0.85時，強制轉人工審核。這個數字來自他團隊的A/B測試：閾值從0.9降到0.85，誤報率下降34%，而人工介入量只增加12%。

第五關：決策核心不是模型選擇，是「狀態機設計」

Buzdugan把代理的決策層比作「自動駕駛的規控模塊」。大模型只是其中一個傳感器，真正的復雜度在于狀態流轉邏輯。

他畫了一個簡化狀態圖：Idle → Planning → Executing → Validating → 分支到Done/Retry/Escalate。每個狀態的進入條件、超時處理、異常恢復，都需要顯式編碼。

「別讓模型決定『我現在該干嘛』，」他警告，「模型只負責『給定當前狀態，下一步最優動作是什么』。狀態管理的權力必須留在工程可控的代碼里。」

這個區分直接影響系統的可解釋性。當代理陷入循環時，你能打開日志看到「在Validating狀態超時，觸發Escalate」——而不是面對一段黑箱的模型輸出。

隱藏關卡一：人類介入的「黃金時刻」

Buzdugan花了相當篇幅討論「何時該打斷用戶」。他的結論是：不是出錯了才找人，而是在「信息缺口」出現時提前預警。

具體觸發條件包括：需求存在歧義（多個合理解讀路徑）、變更影響范圍超出預設閾值、或者檢測到與歷史代碼風格顯著偏離。代理需要生成結構化的澄清請求，附帶推薦的決策選項——而不是開放式的「我該怎么做？」

他分享了一個反直覺的數據：在代理-人類協作中，「過早求助」比「過晚求助」的端到端效率高出23%。因為人類的上下文切換成本，遠低于事后返工的成本。

隱藏關卡二：評估即產品

文章最后，Buzdugan拋出一個讓多數團隊不適的觀點：在你能穩定評估代理表現之前，所有功能迭代都是盲目的。

他建議建立「代理性能基準」——不是跑幾個LeetCode題，而是收集真實任務的歷史軌跡，人工標注「理想執行路徑」，然后計算代理的偏離度。指標包括：步驟冗余度（是否繞遠路）、工具調用效率（是否濫用文件檢索）、以及人類介入率的趨勢。

「我們花了6周才搭建出可信的評估流水線，」他承認，「但這6周讓后續18個月的迭代速度提升了4倍。」

Buzdugan在文末沒有給出「下一步」的號召，只留了一個觀察：目前開源社區最成熟的編碼代理實現（如OpenHands、Devin的開源替代品），架構上都趨同于他描述的這套loop——但工程打磨程度差異巨大。

「同樣的藍圖，有人蓋出茅草屋，有人蓋出摩天樓。」他寫道。

你的團隊現在卡在哪個環節——是以為買了API就萬事俱備，還是發現評估體系比代理本身更難建？