用 Agent 打造生產級 AI 系統:經驗、陷阱與極限

TL;DR

• Demo 與 production 是兩件事:生產環境在意 maintainability、controllability、completeness,這些要求會直接改變你能怎麼用 agent。實測數字最誠實——bug-fixing agent 產出的 313 個修補,只有 73 個被人類接受並合進主線,超過 100 個因為「不夠完整、太 reward hacking、太表面」被打回。
• 把責任切細、把 reviewer 提前:多 agent 流程拆成 plan(plan generator + plan reviewer)與 implementation(coder + reviewer + QA),每個 sub-agent 專注、context 用得更省;光是多加一個 plan reviewer,就能在同樣品質下把迭代從 175 次降到 35 次,token 成本大幅下降。
• 不要蓋重型 harness:訓練端一開始做 deep-agent 式的重流程,後來改成「通用 coding agent + 極輕量 harness」,因為通用 coding agent 的進化會吃掉你自己造的輪子;輕量才能跟著基礎模型一起升級。

重點整理

三個推論端案例:bug fixing、model bring-up、效能最佳化(約 00:03–00:10)

實驗場域是 NVIDIA 的大模型推論框架(逐字稿聽為 "the 10M",判斷為 TensorRT-LLM,見待確認),已被大量客戶採用,也用來做 MLPerf、SemiAnalysis 等關鍵 benchmark 提交——是不折不扣的產品級軟體,對 agent 而言難度更高。

案例一:bug-fixing autobot(約 00:03–00:06) 流程是「agent 階段 → 人類階段」兩段式:bug 分析 → 重現 → 確認可重現後由 agent 修 → agent review → agent 驗證 → 標記 agent 階段完成;接著人類仔細 review,確認這個修補不是 reward hacking、不是 hacky、夠完整,必要時給回饋讓 agent 繼續迭代到收斂。

Dashboard 的真實數字(約 00:05:46):約 800 個 bug 中,313 個已有 agent 產出的修補;但其中只有 73 個被接受並合進 main branch,超過 100 個被人類直接拒絕。Jun Yang 把這個數字當成「production 要求與 agent 現況之間落差」的具體證據,也是團隊持續要拉高的比率。

案例二:新模型 bring-up(約 00:06–00:09) 新模型幾乎每月、有時每週就出現一個,團隊做了 agent-based model bring-up 工具:使用者用 CLI 把模型定義與驗收標準寫進 task YAML,餵進 agent 流程;過程中人類可以中斷、給回饋、再觸發,把 agent 導回想要的方向。

Agent 流程是典型的多 agent 分工:plan 階段有 plan generator 與 plan reviewer,implementation 階段有 coder、reviewer、QA。刻意把職責切開,是為了讓每個 sub-agent 夠專注、context 用得有效率,並透過共用檔案交換共同資訊,像一個團隊一起工作。

以 Google 的 Gemma 模型為例(約 00:07:52):x 軸是迭代次數 0–175,y 軸是品質分數(越高越好)。planner 觸發執行後,coder 與 reviewer 多輪往返,review 通過就交給 QA 評測,QA 把結果送回 coder 再改,四方密集互動後才收斂。加上 plan reviewer 之後(約 00:08:47),同樣品質只要 35 次迭代——這是他們發現對 token efficiency 最有效的一招。

案例三:效能最佳化(約 00:09–00:10) Bring-up 完成後再用 agent 做效能優化。從低效能 baseline 出發,第二、三輪各完成一批優化,第四輪收斂即停止。關鍵設計是 cookbook:團隊過去累積的優化經驗被整理成結構化文件供 agent 查詢——第二輪查了 host performance 相關 cookbook,第三輪查了 CUDA graph 相關 cookbook 再套用。也有不少優化做完但因為效益太邊際而被工作流自己否決。

訓練端:從 deep agent 走向「通用 coding agent + 輕量 harness」(約 00:10–00:11)

訓練與推論有共通處但特性不同,所以用不同工作流。一開始建的是 deep-agent 式流程,後來主動退回到「在通用 coding agent 之上做極輕量 harness」——原因是通用 coding agent 自己的進化,已經接管了他們先前手工打造的東西;流程輕、可適應,才能吃到通用 agent 與基礎模型的紅利。

訓練 agent 額外加了兩塊:kernel arena(重用歷史 kernel,讓生成 kernel 更容易)與學習回饋迴路(agent 對過去執行做根因分析 + 人類 review,回灌流程迭代)。也建了 evaluation toolkit,讓新增 skill 或 sub-agent 時能相對確定不會引入太多回歸——但他坦言「這還不理想,我們仍在摸索怎麼防守 agent 系統的演化」。

案例是 FLUX 這個 vision transformer 模型(約 00:11:20),原本已有人類調校出的良好 baseline。Agent 嘗試了 120 次以上實驗,有些 OOM、有些跑得起來但被否決,最後留下的優化在強 baseline 上帶來約 20% 效能提升。

結論:四個教訓(約 00:11:59–00:13:20)

1. Agent 的智能本質與人類不同,本質上是機率性的過程;設計任何東西時都要把這件事算進去,才能吃到優點、避開缺點。
2. 不要建重型 harness,客製化工作流越輕越好,才能持續 leverage 通用 coding agent 與基礎模型的未來進化。
3. 全自動 agent vs. 人 + agent 的取捨:一方面想盡量自動化,另一方面「人 + agent」在 token 效率與迭代速度上常常明顯更好。相關的是「集中化 vs. 在地化」:生產環境通常想把邏輯集中以便共用,但因為 agent 演進太快,人 + 在地客製 agent 有時比集中式 agent 更有效率——沒有 single silver bullet。
4. 在 coding agent 與輕量 harness 之間取得平衡,才能快速跟上基礎模型與通用 coding agent 的新進展。

金句

"Among the 313 back fix from agent, only 73 of them have been accepted and landed to our main branch."(約 00:05:56)

生產級軟體裡,agent 的「完成」和人類的「可接受」之間差了四倍多。

"Rather we should try to make sure the customization workflow should be as lightweight as possible so we can be able to leverage the future evolution of the general coding agent and foundation model."(約 00:12:20)

你造的 harness 越重,越可能在下一代通用 agent 出來時被整段作廢。

"Human plus local custom agent can sometimes work more efficiently than the centralized agent."(約 00:13:03)

集中化是軟體工程的直覺,但在 agent 演進速度下,這個直覺不一定成立。