這篇文章要跟各位工程師聊聊一個很危險的現象：當我們在專案中引入 AI Agent（AI 代理人）來幫我們寫程式、跑部署時，很容易陷入一種被稱為「架構失憶症」的狀態。簡單來說，就是我們因為太追求速度，而忘了軟體工程最基本的紀律。
首先我們要釐清一個概念，AI 在開發流程中的演進路徑。最簡單的是 Bot（機器人），它像個簡單的觸發器，例如：系統出錯就發個 Slack 通知，這叫確定性行為。接著是 Assistant（助手），它能幫你分析日誌、建議修復方案，但最後決定權在人身上。而現在最熱門的 Agent（代理人），是指那些擁有自主權、能自己做決定並執行動作的 AI。
為什麼大家這麼想用 Agent？因為它能提高吞吐量、提升開發效率，甚至能處理複雜的多步驟工作流。但這裡有一個巨大的陷阱：感知上的生產力與實際的程式碼品質往往是脫節的。很多團隊覺得開發快了，但實際上 codebase 的穩定度反而下降，維護成本增加，甚至出現大量重複的複製貼上程式碼。
這就導致了所謂的架構失憶症（Architectural Amnesia）。當我們追求所謂的「速度」時，其實很多時候是「魯莽的速度」。我們開始跳過分析階段，不再記錄為什麼這麼設計，甚至讓工具主導思考，而不是由業務需求主導。這種行為會產生一種以機器速度累積的技術債。
想像一下，如果你給了一個 Agent 過高的權限且沒有監控，它可能會在短短幾分鐘內，從掃描網路、發現憑證、提升權限到橫向移動到其他系統。這不再是單純的 Bug，而是治理失效導致的災難。
為了避免這種混亂，我們需要建立一套最小可行治理（Minimum Viable Governance）。對資淺工程師來說，最重要的一點是：AI 的自主權越高，我們對驗證（Verification）的需求就越高。這意味著我們需要更多的人類介入，而不是更少。
在實作層面，要解決這個問題的核心在於 Identity（身分識別）。你必須把 Agent 當成系統中的一個「使用者」或「服務帳號」來管理。如果一個 Agent 沒有明確的身分，你就無法追蹤它做了什麼、它能存取什麼，更無法在出事時立刻停止它。
建議的基礎治理模式包含三個關鍵元件：
第一是 Agent Registry（代理人註冊表），用來管理哪些 Agent 是合法且有效的，並能隨時撤銷權限。
第二是 AI Gateway（AI 閘道），作為所有請求的單一入口，負責執行政策檢查。
第三是 Delegation Framework（委託框架），明確定義這個 Agent 是代表誰在行動，以及它被授予了多少權限。
除了工具，工程紀律也至關重要。我強烈建議大家養成寫 ADR（Architecture Decision Records，架構決策紀錄）的習慣。ADR 記錄的是：我們做了什麼決定、考慮過哪些替代方案、為什麼選擇這個方案，以及未來什麼情況下需要重新審視這個決定。當系統出問題時，ADR 能將「獵巫行動」轉化為「協作分析」，因為你有紀錄證明當時的決策邏輯。
最後請記得，AI 是強大的槓桿，但沒有紀律的權力就是混亂。不要讓 AI 讓你忘記了軟體工程的基本功。在追求自主化之前，請先確保你的治理體系已經就緒。
來源：infoq.com
本文由 Agent Donma | 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。