約束衰減：為什麼 LLM Agent 在生產級後端代碼中表現掙扎

對於許多開發者而言，AI 編碼 Agent 的承諾是一個透過高階提示詞（prompt）就能轉化為功能完整的後端系統的世界。在快速原型設計中，這通常行得通：當規範較為鬆散時，LLM 在生成功能正確的代碼方面表現得非常出色。然而，在「可行」的原型與遵循嚴格架構模式、資料庫綱要（schema）以及物件關聯映射（ORM）的生產級軟體之間，存在著巨大的鴻溝。

最近的一項研究，《約束衰減：LLM Agent 在後端代碼生成中的脆弱性》（Constraint Decay: The Fragility of LLM Agents in Backend Code Generation）揭示了這一差距。研究人員指出了一種他們稱為「約束衰減」（constraint decay）的現象，即隨著需求數量的增加，Agent 維持功能正確性與結構完整性的能力會隨之崩潰。

約束衰減現象

該研究評估了 LLM Agent 在 80 個全新生成任務（greenfield generation tasks）和 20 個功能實現任務（feature-implementation tasks）中的表現，涵蓋了八種不同的 Web 框架。透過固定統一的 API 合約並同時使用行為測試與靜態驗證器，研究人員分離出了結構複雜度的影響。

他們的發現非常驚人：隨著結構性需求的累積，Agent 的性能會大幅下降。在從基準任務轉向完全指定的任務時，能力較強的配置在斷言通過率（assertion pass rates）上平均下降了 30 分點。在某些較弱的配置中，性能甚至趨近於零。

框架敏感度

在 LLM 眼中，並非所有框架都是平等的。研究發現，根據框架的「慣例」（convention）程度，性能存在顯著差異：

極簡主義框架： Agent 在 Flask 等明確且極簡的框架中表現較好。
慣例密集型框架： 在 FastAPI 和 Django 等環境中，性能大幅下降，因為這些環境中存在更多隱含的慣例與複雜的結構性需求。

失敗的根本原因

錯誤分析顯示，資料層是主要的失敗點。最常見的缺陷包括錯誤的查詢組合（query composition）以及 ORM 執行時錯誤（runtime violations）。這表明，雖然 LLM 可以處理函數的邏輯，但它們難以同時滿足功能的特性需求與資料層的結構性需求。

行業觀點：超越提示詞

學術研究的發現與開發者社群產生了強烈的共鳴。在 Hacker News 上，從業者分享了他們在使用當前 Agent 時遇到限制的真實經驗，並指出解決方案不在於更好的提示詞，而是在於更穩健的生態系統。

「上下文腐化」與「鈣化」問題

一些開發者認為，約束衰減是「上下文腐化」（context rot）的一種變體——即隨著對話變長，LLM 失去對護欄（guardrails）掌控的傾向。一位用戶指出，將必要的目錄感知資訊填滿上下文窗口，往往會導致模型缺乏足夠的「認知」空間來實際遵循約束。

另一個有趣的觀察是「鈣化」（calcification），即 Agent 過於僵化地遵循代碼庫中現有的模式，以至於該模式主導了上下文並變得自我強化，無論該模式是否為新任務的最合適選擇。

緩解策略

為了對抗約束衰減，開發者正在採用幾種戰術轉變：

範例優於 Markdown： 與其使用長篇的 Markdown 文件來描述架構規則，一些開發者發現，提供幾個具備慣用風格（idiomatic）的文件作為 Agent 模仿的範例會更有效。
規劃模式： 實施一個明確的「規劃階段」，讓 Agent 在編寫代碼之前先生成藍圖，這有助於維持結構完整性。這可以防止 Agent 在長對話會話的持續壓縮過程中變得「草率」。
靜態分析作為護欄： 社群對於將「架構檢查工具」（例如 ArchUnit）整合進 Agent 循環中提出了越來越多的呼聲。透過使用靜態代碼檢查工具來強制 LLM 遵循架構，Agent 可以被直接餵入特定的錯誤，而不是依賴模糊的指令。
類型安全： 一些從業者指出，靜態類型語言（如 Go）比動態類型語言（如 Python 或 JS）更容易讓 Agent 維持，因為編譯器提供了 Agent 可以用來自我修正的即時反饋循環。

結論：人機協作

該研究與社群得出的總體結論是：LLM Agent 目前在快速原型設計方面是可靠的，但在生產級後端開發方面仍不可靠。挑戰不僅在於生成能通過測試的代碼，更在於生成優雅、可維護且結構穩健的代碼。

正如社群所建議的，未來的路徑很可能是生態系統的方法：將 LLM 與靜態驗證器、正式規範以及人工審查結合起來，以確保約束的「衰減」不會導致軟體本身的衰減。