Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP21。

實作一段時間後，我們回頭盤點 agents/ 目錄，發現一個尷尬的現象。

有幾個「角色」設定，拆開來看其實只是包了一顆 skill，本身沒有提供任何額外的協調價值——它就只是換了個名字的 skill，卻要多一層註冊、多一份載入成本。

於是我們定下一條判斷標準：

agent 的存在理由，必須是「協調多顆 skill 或承擔某種角色責任」；如果拆開只剩一顆 skill，那它就不該是 agent，應該直接是 skill。

這類「薄代理層」看起來人畜無害，但累積多了，會帶來兩個實際的成本：

1. 命名與註冊成本：每多一個 agent，就要多維護一份設定、多一個要記住的名字。
2. 載入成本：AI 在判斷「這個任務該用哪個能力」時，多一層無意義的間接，反而讓路由邏輯變複雜。

所以我們的做法是：可執行的能力，一律收斂到 skill；只有真的需要「協調好幾種能力」或「承擔明確角色責任」的情境，才保留 agent。

這是在減少複雜度，而不是單純為了減少檔案數量而合併——如果合併之後反而讓一顆 skill 要處理的職責變得混亂，那還不如維持分開。

這加起來其實就一句話：可執行能力一律收斂到 skill；只有真的需要協調多種能力或承擔角色責任，才保留 agent。

整理完角色與技能的邊界，我們也順手處理了另一種常見的重複：幾顆功能很像的 skill，該合併還是該維持獨立？

下一篇來聊這個判斷。