為什麼 awesome lists 不是挑選 AI agent 工具的正確方式

Curated AI agent lists 適合拿來找工具，但不適合拿來決定要押注哪個 AI agent stack。

這類清單很有用，所以才危險。當一個 repo 同時塞進 445+ 資源、25 個分類，還標上 fresh、stale、experimental、audited 這些狀態時，它很容易把「資訊完整」偽裝成「判斷完整」。創辦人或 PM 掃過一頁，看到 MCP、A2A、coding agents、browser agents、sandboxing、enterprise platforms 全部排在一起，會下意識以為市場已經有秩序了。其實沒有。AI agent 工具市場的核心問題不是缺名單，而是缺可比較的決策框架。

第一個論點

awesome list 的第一個價值是 discovery，不是 selection。它像地圖，不像導航。以這份清單為例，它把 protocols、frameworks、evaluation tools、甚至 anti-picks 都放進來，對於第一次摸市場的人很有幫助。但當 23+ frameworks、18+ enterprise platforms、17 個 observability tools 被並排呈現時，清單就變成目錄，而不是答案。你能知道有什麼，不代表你能知道該選什麼。

這個差別不是文字遊戲，而是會直接影響成敗。Agent 專案真正死掉的原因，通常是整合成本、可靠性、權限與維運，而不是「我沒看過那個框架」。README 裡特別補了 scenario guides、stack recipes、compare tables，這其實已經說明一切：一旦你需要額外的 tradeoff 指引，原始列表本身就不夠用了。它能告訴你 LangGraph、AutoGen、CrewAI、OpenAI tools 都存在，但不能替你回答哪個能過安全審查、哪個撐得住 latency budget、哪個不會把團隊拖進長期維護地獄。

第二個論點

多數 agent framework 根本不是可互換零件，而是不同的操作模型。寫在 developer workflow 裡的 coding agent，和要去點 legacy portal 的 browser agent，需求差很多；再往上看，客服 agent 還要面對 policy、稽核、權限與可追溯性。這份清單把 coding、computer use、browser、voice、personal、mobile、enterprise 分成不同區塊，反而證明了這件事：問題本來就不一樣。把它們當成同一個市場，最後常見的結果就是團隊重複造三次 orchestration layer。

更有價值的訊號，其實不是條目數量，而是 status tags 和 anti-picks。這些標籤承認了成熟度差異很大，這才是 2026 年 agent tooling 的真相。experimental sandbox 不等於 audited security layer；星數暴衝的熱門專案，也不等於穩定 runtime。若你的選型流程沒有把這些差異拉開，你其實不是在評估工具，而是在收集 logo。這也是為什麼看起來「全面」的清單，常常反而會誤導決策。

反方可能怎麼說

支持 awesome list 的人有一點說得對：這個領域變化太快，單靠舊文章或廠商頁面根本跟不上。能維護到 445+ 資源、還有更新時間與分類篩選的 repo，確實是在替社群節省大量搜尋成本。對新手來說，它降低進場門檻；對老手來說，它能補到平常不會主動看的周邊工具。放在一個碎片化市場裡，curation 本身就是價值。

他們也對於另一件事：如果清單有 status labels、compare tables、anti-picks，那它就不是中立索引，而是帶有判斷的導覽。這種導覽能幫團隊更快排除死路。對正在探索階段的團隊來說，一份維護良好的廣譜清單，常常比零散的部落格和 vendor landing page 更實用。

但這個辯護只能走到 discovery 為止。只要團隊把清單當成採購捷徑，它就開始變成負資產。curation 可以降低搜尋成本，卻不能取代 benchmark、threat modeling、或在你自己的 stack 裡做 proof-of-concept。原因很簡單：agent 工具的失敗發生在 context 裡，而 context 不會躺在 README 裡。這份 repo 最好的用途，是當候選名單的索引，不是當決策引擎。

你能做什麼

如果你是工程師，先用清單縮到 3 個候選，再用同一套 harness 跑完真實工作流、安全測試、延遲測試與 rollback 計畫；如果你是 PM，別再問哪個 framework 最好，改問哪種 failure mode 你能接受；如果你是創辦人，把 protocols、evals、sandboxing 當成長期層，把 framework 當成可替換實作。這樣你才是在用 awesome list 找方向，而不是拿它替你做決策。