讓 Agent 自動建、測、修 Agent

030Benedikt Sanftl（Mutagent）34:492026-06-29

The Agentic AI Engineer - Benedikt Sanftl, Mutagent

Mutagent 兩位創辦人示範怎麼用 agent 接手建 agent、eval、診斷到優化的整套流程。

重點摘要

建 agent 也該走軟體開發的迴圈：像寫程式一樣分成 spec、build、eval、ship 幾個階段，上線後再進入 monitor、diagnose、optimize 的迴圈，周而復始。
人工迭代撐不住規模：一個個手動看 trace、判斷、修正，agent 一多就變成瓶頸，這正是 agentic AI engineer 想解決的問題。
spec 是後續一切的依據：把責任範圍、context 需求、要用的工具與邊界寫清楚，換框架、換 harness 都不必重新設計一次。
eval 要能告訴你怎麼修：比起模糊的評分制，binary 判準更容易指出哪裡壞了；用 LLM 當裁判時，還要處理評分不穩定的問題。
診斷靠抽樣不是逐條看：把驗證過的失敗模式變成可以直接比對的訊號，之後不必每次都重讀全部 trace。
Mutagent 把這套流程做成產品：evaluator agent 負責建資料集，diagnostics agent 負責找上線後的根因，兩者由一個跑在 coding 環境裡的 orchestrator 串起來。

時間軸16 段

00:00	開場	Bene 與 Burak 開場，說明這場要講 agentic AI engineer 怎麼運作。
00:35	兩個迴圈	建 agent 分成上線前的 offline loop（迭代、測試、evaluate）與上線後的 online loop（監控、診斷、回饋）。
01:08	手動迭代的瓶頸	目前多半靠人工跑這個迴圈，人力審核與建置時間跟不上規模，尤其是要一次推出上百個 agent 的時候。
03:08	迴圈七階段	spec、build、eval、ship 到 monitor、diagnose、optimize，整套流程都可以逐步交給 agent 執行。
05:50	兩種起點	從零開始建 agent，跟改既有已上線的 agent，該走的路不一樣。
07:03	spec 先定邊界	spec 要寫清楚 context 需求、要用的工具，以及 agent 該做與不該做的事，成為之後開發的依據。
08:44	build 交給 coding agent	把 spec 交給 coding agent 落地，目標平台可以自己選，框架保留彈性方便日後更換。
11:10	eval suite 怎麼長出來	eval 由 metrics、criteria 加資料集組成，很難一開始就寫齊，得靠正式上線後持續補齊邊界案例。
13:43	為何要 evaluator agent	光是一份 200 筆的資料集，沒有自動化的 eval，靠人眼一筆一筆看就要花很久，人力變成瓶頸。
15:19	好 eval 要看什麼	要看 agent 拿到的 context 完不完整，也要檢查過程中每一步工具輸出對不對，而不是只看最終結果。
17:15	二元判準比較好用	模糊的評分制不容易告訴你該怎麼修，binary 判準更直接；用 LLM 當裁判還要處理評分不穩定的問題。
18:47	上線後找根因	蒐集失敗案例並依根因分類，再把驗證過的失敗模式變成可以直接比對的訊號，省去每次重讀全部 trace 的成本。
22:04	自動優化與部署	依 eval 分數調整 agent 的內容，分數達標就自動上線，形成完整的自動迴圈。
24:55	Mutagent 的兩隻 agent	evaluator agent 負責建資料集，diagnostics agent 負責找上線後的問題，由一個跑在 coding 環境裡的 orchestrator 串起來。
27:05	現場示範	在 Claude Code 裡下診斷指令，產出的 HTML 報告列出失敗模式、根因鏈與修復建議，最後轉成給 coding agent 的任務清單。
34:15	結語	呼籲別再手動除錯，讓 agent 分攤重複瑣碎的工作。

值得記的話5 句

So this is why doing this agentically is the key to increasing the throughput because then you can fit many more cycles into the same time window.把這個流程交給 agent 跑，才是提高吞吐量的關鍵，因為同樣的時間內能塞進更多次迭代02:49
I mean, one issue is, again, imagine you have a data set item of 200 here without automated evals, running this and evaluating by human eyes takes quite a while.光是一份 200 筆的資料集，如果沒有自動化的 eval，光靠人眼一筆一筆看就要花很久時間13:43
In such cases, using binary type of evals or criteria is preferred because there you have a kind of a call to action.這種情況下，用二元判定的 eval 或準則比較好，因為它能直接告訴你該怎麼處理17:34
What that means is there are maybe specific pieces of content or there's a specific tool called sequence where you know that the agent will encounter an issue.意思是說，某些特定的內容片段，或是特定的工具呼叫順序，能讓你事先知道 agent 會在哪裡出問題21:06
Then for each tab, you will have a failure mode and kind of like an explanation of the problem.每個分頁都會列出一種失敗模式，並附上這個問題的說明31:56

名詞與人物9 個

Mutagent: 這場演講兩位講者所屬的新創公司，做的產品是把建 agent 的流程 agent 化的平台。
Bene: Mutagent 的 CEO 兼共同創辦人，這場開場與整體流程說明由他主講。
Burak: Mutagent 的 CTO，負責深入講解各階段細節，也負責現場示範。
offline loop: 上線前的開發迭代：建 agent、測試、evaluate、改善。
online loop: 上線後持續監控 trace、診斷問題，再把結果回饋進優化。
evaluator agent: Mutagent 目前研究預覽中的兩隻 agent 之一，協助建立 eval 資料集。
diagnostics agent: Mutagent 另一隻研究預覽中的 agent，協助分析上線後的 trace、找出根因。
orchestrator: 串接 evaluator agent 與 diagnostics agent 的角色，跑在使用者自己的 coding 環境裡。
trajectory: agent 從收到任務到產出結果的完整執行過程，是評測時要看的核心對象。

提到但沒有展開

提到修復結果可以自動變成 GitHub 上的 PR、直接調整 agent 的 MD 設定檔，或部署到代管服務，但沒有進一步說明每種輸出方式的細節。
提到可以用語音輸入（speech-to-text）在報告裡留一般性回饋，但只是順帶一提，沒有展開。
提到近來不斷有新的 agent runtime、harness 冒出來，但沒有點名細節。

Agent開發工具評估

在 YouTube 看原片 ↗