The Agentic AI Engineer - Benedikt Sanftl, Mutagent

在 AI 代理開發的早期階段，團隊採用手工循環來構建和改進代理。流程是：當發現問題時，工程師實施變更，通過編碼代理生成樣本測試新功能，手動查看結果和日誌，決定是否發布，進行 A/B 測試，再基於反饋進行下一輪迭代。這個過程非常緩慢，人工審查和人工構建成為無法逾越的瓶頸——當組織計畫部署數百個 AI 代理時，這種模式完全無法擴展。

Agentic AI Engineer 是對這一模式的根本改造。它定義了一套完整的七階段循環，從規格定義開始。規格文檔是關鍵工件，需要明確定義代理的職責範圍、它將處理的任務、所需的工具和集成、上下文需求以及邊界條件。這份規格變成後續開發的藍圖，並且因為它是與實現細節分離的，所以當團隊需要在一年後從舊框架（如 Hermes）遷移到新框架時，只需調整實現層，規格本身保持不變。這種設計確保了長期的靈活性。

構建階段之後是評估驅動開發——相當於代理版本的測試驅動開發。完整的評估套件由兩部分組成：評估指標與評判標準，以及包含要測試的案例的數據集。大多數團隊犯的錯誤是試圖預先完整猜測所有評估標準，但現實是評估套件是一個持續發現的過程。它從生產故障、用戶反饋和邊界案例中逐步積累，代表了代理在真實環境中需要處理的具體挑戰。

當手工評估時，假設你有 200 個數據集項目，人工逐個審閱日誌和觀測平台會非常耗時，形成新的瓶頸。自動評估代理可以並行處理這些工作。評估的品質關鍵在於給出可操作的反饋——二元標準比評分更有價值，因為它們提供明確的「做什麼」指導。此外，如果使用 LLM 作為評判者，必須進行校準以減少評判方差，因為大語言模型在多次運行中可能給出不同評判。

代理部署到生產後，在線循環開始。診斷代理自動收集故障案例並執行結構化根因分析。關鍵洞察是，不應該人工讀遍所有日誌——一個擁有數百萬條代理追蹤的系統中，讀取成本超過執行成本本身。相反，診斷代理使用多層級過濾和智慧採樣策略，選擇代表性樣本，進行初步掃描以識別明顯問題，然後聚焦於特定故障模式。診斷結果以遞迴式根因分析呈現，展示「為什麼為什麼為什麼」的完整鏈條，並提供多個修復建議。過程中的假設會被明確標註，允許人工驗證。隨著時間推移，這些學到的故障模式積累成可檢查的代碼指標——比如特定的日誌內容或工具調用序列——這樣未來診斷就無需讀取完整日誌。

最終，一旦評估通過且改進方案確認，系統自動生成 Markdown 格式的任務定義供編碼代理使用，自動應用修復。這形成了一個完整的閉環：離線循環（Spec → Build → Eval → Ship）用於初期開發，在線循環（Monitor → Diagnose → Optimize）持續改進生產中的代理。每個生產故障轉化為新的評估標準，每個新的邊界案例豐富評估套件，讓代理越來越聰慧。

Mutagen 平台在研究預覽階段提供兩個核心代理：Evaluate Agent 幫助構建高質量的評估數據集，Diagnose Agent 自動分析生產追蹤。這些代理通過 Orchestrator（運行於編碼環境如 Claude Code）協調，連接到各種日誌源（LangSmith、本地文件、JSON-L 格式等）和目標平台（GitHub 自動提交、代理框架部署、託管服務）。用戶只需在編碼環境中輸入簡單命令（如 `/diagnose`）即可觸發整個工作流。

---