在現代軟體開發中，演進式架構（Evolutionary Architecture）的核心理念在於將架構視為一個可持續演進的決策系統，而非一個固定不變的終點。為了確保在持續變更的過程中，系統的重要特性（如可擴展性、安全性、效能）不會在不知不覺中惡化，開發團隊引入了適應度函數（Fitness Functions）。這是一種將架構意圖轉化為可執行回饋的機制，讓治理從週期性的人工審查轉變為持續性的自動化監控。
然而，傳統的適應度函數大多屬於確定性規則（Deterministic Rules）。例如，透過依賴檢查工具防止循環依賴、利用合約測試確保 API 相容性，或設定延遲預算來監控效能。雖然這些工具在執行客觀 invariant（不變量）檢查時非常高效，但它們面臨一個共同的天花板：無法處理需要「判斷力」的架構問題。
許多架構的衰敗並非源於違反了某條明確的規則，而是發生在數次看似合理的微小變更之中。例如，一個新的 API 欄位可能在結構上完全相容，但卻將 UI 層的關注點洩漏到了領域模型中；或者一個新的服務呼叫雖然沒有違反依賴規則，但卻悄悄地將兩個獨立的業務邊界耦合在一起。這類問題無法用簡單的閾值或模式匹配來偵測，過去只能依賴資深架構師的人工審查，但這種方式在快速交付的 CI/CD 環境中完全無法規模化。
為了填補這個空白，InfoQ 的相關研究提出了代理適應度函數（Agentic Fitness Functions）的概念。這是一種由經過校準的 AI Agent（智能代理）擔任評估者的治理檢查機制。它並不旨在取代確定性規則，而是將 AI 作為一個「受控的判斷層」，處理那些有證據支持但無法機械化決定的複雜架構問題。
代理適應度函數的運作並非將 AI 當作全知的預言機，而是將其視為一個根據分析量表（Analytic Rubric）執行任務的審查員。一個完整的生產級代理適應度函數包含四個核心組成部分：首先是適應度意圖，定義要保護的具體架構關注點（如邊界忠實度）；其次是證據合約，限制 AI 僅能查看特定的工件（如 PR Diff、API 規範或架構決策紀錄 ADR），以避免資訊過載或幻覺；第三是代理判斷者，即應用量表的 AI 模型；最後是結構化裁決，輸出包含分數、信心水準、違規準則及建議行動的機器可讀結果。
在實務運作上，這套機制採取「確定性門檻先行，代理判斷隨後」的策略。系統先運行傳統的自動化檢查，若通過後，再由 AI Agent 針對較深層的意圖進行評估。例如，在邊界忠實度審查中，確定性規則能攔截非法導入，而 AI Agent 則能分析該變更是否導致業務能力的所有權被削弱。在語義合約評估中，結構驗證器確保 API 不會崩潰，而 AI Agent 則判斷該合約是否仍符合領域語言的定義。甚至可以建立 ADR 漂移監控器，定期比對當前的運行指標與當初做出架構決策時的假設是否仍然成立。
引入代理適應度函數最大的挑戰在於其非確定性。為了確保可靠性，必須建立嚴格的校準與控制流程。開發團隊應準備 20 到 50 個已知的歷史案例（包含可接受與不可接受的變更）作為校準集，不斷調整量表直到 AI 的精準度與召回率達到要求。同時，系統必須透明地揭露信心水準，當 AI 出現低信心、多個模型判斷不一致或變更影響範圍過大時，必須強制升級（Escalate）給人類架構師審核。
此外，必須防止 AI 產生偏見或被誘導。例如，為了避免「冗長偏見」（AI 傾向於認為描述詳細的 PR 是正確的），評估應基於實際證據而非文字長度；為了防止「提示詞注入」（Prompt Injection），AI 應被設定為忽略程式碼註解或 PR 描述中的指令，僅將其視為證據而非指令。
從長遠來看，代理適應度函數的價值不在於完全自動化架構審查，而是在於將原本隱晦的人類判斷過程「可觀察化」與「可審計化」。當某類 AI 偵測到的問題反覆出現且被人類確認為真實違規時，團隊可以將其從 AI 的量表中提取出來，轉化為新的確定性規則。這形成了一個正向循環：AI 發現模式 $\rightarrow$ 人類確認 $\rightarrow$ 轉化為確定性規則 $\rightarrow$ 降低 AI 負擔。
總結來說，代理適應度函數為演進式架構提供了一種務實的擴展。它將「判斷力」轉化為程式碼，但保留了對證據與問責制的敬畏。透過將硬性門檻留在確定性工具，將解釋性分析交給校準後的 AI，企業能夠在保持高速交付的同時，防止架構在無聲之中崩潰。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。