agency-agents-zh 評測：277 個專家角色的中文地頭蛇，還是提示詞的數量遊戲？
🎭 277 个即插即用的 AI 专家角色 — 支持 Claude Code/Cursor/Copilot 等 20 种工具，覆盖工程/设计/营销/金融等 20 个部门。含 64 个中国市场原创智能体（小红书/抖音/微信/飞书/钉钉/Qt 上位机/机械设计）。搭配编排器 agency-orchestrator，一句话即可让多位专家按 DAG 自动协作。
秒懂
- 它是什麼？
- agency-agents-zh 把上游 213 個 AI 專家角色翻成中文，再加 64 個鎖定小紅書、抖音、Qt 上位機的中國市場原創智能體。角色定義的深度與工具相容性是亮點，但 277 這個數字本身需要打折看。
- 適合誰用？
- agency-agents-zh 適合需要快速取得大量中文角色定義、且願意手動篩選品質的個人開發者或小團隊，尤其是要處理小紅書、抖音、微信生態或 Qt 工業上位機等冷門領域的人。不適合追求每個角色都能直接上生產線的企業，因為 README 沒有提供任何角色品質驗證機制，而且 277 個角色中有 213 個是翻譯，原創比例約 23%。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Shell（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決什麼問題：中文團隊的角色荒
多數 AI 程式工具的角色定義，例如 Claude Code 的 CLAUDE.md 或 Cursor 的 rules，都是以英文為中心。中文團隊要嘛自己從零寫 system prompt，要嘛拿英文範例硬改，結果常常出現語氣彆扭、忽略中國平台規則的狀況。agency-agents-zh 直接面對這個缺口。它把上游 msitarzewski/agency-agents 的 213 個角色完整翻譯，再新增 64 個原創角色，專門覆蓋小紅書、抖音、微信、B站、飛書、釘釘等平台的營運需求，甚至包含 Qt 工業上位機與機械設計這類冷門工程領域。這不是通用的「你是個行銷專家」提示詞，而是每個角色都帶獨立人設、專業流程與可交付成果。對於想快速建立多角色團隊、卻不想從空白文件開始的人，這是一個現成的起點。
角色目錄的實際結構：翻譯與原創的雙層設計
倉庫的規模數字需要拆開看。277 個智能體中，213 個是英文版的翻譯，64 個是中國市場原創。翻譯部分繼承上游的品質，原創部分則鎖定中國特有的平台與產業。README 特別強調「不是通用提示詞模板」，暗示每個角色檔案都有結構化的人設與流程。從釋出紀錄看，v1.2.4 做了「計數补齐 216 + 計數守卫」，v1.2.5 則是在 README 加上線上展示區。這些細節顯示維護者把角色數量當作品質指標在管，但這也帶來一個問題：數量守衛只保證檔案存在，不保證內容品質。你拿到的是 277 個目錄，其中有多少真正能在你的工具裡跑出預期效果，README 沒有給出任何驗證數據。
支援 20 種工具：格式相容性的關鍵
這個專案宣稱支援 Claude Code、Cursor、Copilot 等 20 種 AI 程式工具。機制上，角色定義必須能被這些工具各自讀取。Claude Code 吃的是 CLAUDE.md 或類似格式，Cursor 吃 .cursorrules，Copilot 則有另一套規則。agency-agents-zh 的角色檔案要嘛是通用 Markdown，要嘛是各工具的特定格式，但 README 沒有列出每個角色對應哪種工具格式。這是一個實際的採用障礙：你不能假設下載一個角色就能丟進任何工具。上游 agency-agents 的設計是讓使用者自行複製貼上到工具的規則檔，中文版繼承了這個模式。換句話說，它提供的是角色內容，不是安裝器。你得自己處理格式轉換，對於不熟悉各工具規則語法的人，這會是第一個卡關點。
安裝與使用：從 npm 到桌面客戶端
專案提供多種取得方式。npm 上可安裝 agency-agents-zh，README 有對應的 npm 徽章，但沒有給出明確的安裝指令。比較具體的是 agency-orchestrator 桌面客戶端，號稱原生 App、免裝 Node，支援 macOS、Windows、Linux，可以從 GitHub Releases 下載。另外還有線上體驗站 ao.aiolaola.com/experts。README 提到搭配 agency-orchestrator 可以「一句話讓多位專家按 DAG 自動協作」，這暗示角色定義與編排器之間有某種契約，但細節沒有展開。實際使用流程大概是：從倉庫挑角色，把內容貼進你的工具，或透過 orchestrator 載入。我沒有實際安裝，無法驗證 orchestrator 與角色檔的相容性，但從描述看，角色檔本身是靜態的，編排邏輯完全在 orchestrator 端。如果你只想要單一角色，直接複製貼上即可，不需要裝任何額外軟體。
真正的限制：數量不等於深度，原創角色缺乏驗證
最明顯的限制是品質不均。213 個翻譯角色繼承上游的成熟度，但 64 個原創角色是這個專案自己的產出，README 沒有提供任何品質保證機制。沒有範例輸出、沒有測試案例、沒有使用者回饋。以「畜禽養殖檔案核對」這類高度垂直的角色為例，它的 system prompt 是否真的能處理中國農業的檔案格式，完全沒有證據。另一個限制是角色之間的協作依賴外部編排器。角色定義檔只是靜態文字，不會自己跟其他角色溝通。若你想讓 CEO、CTO、CMO 三個角色一起工作，你得自己設計流程，或依賴 agency-orchestrator 的 DAG 功能。這表示這個專案不是開箱即用的多智能體系統，而是一個角色素材庫。對於只需要單一專家的人，277 這個數字會造成選擇困難，實際上有用的可能只有十幾個。
替代方案：上游原版與自製提示詞的比較
最直接的替代是上游 msitarzewski/agency-agents。它同樣提供角色定義，而且持續維護，但目前沒有中文翻譯，也沒有中國平台原創角色。如果你的團隊能接受英文角色，或者你只需要通用角色如工程師、設計師，上游可能更穩定，因為它的角色經過更多使用者驗證。另一個替代是自行撰寫提示詞。對於只需要 3 到 5 個角色的團隊，自己寫 system prompt 的成本可能低於篩選 277 個角色。差別在於：agency-agents-zh 提供的是廣度與在地化，自製提供的是精準度。以「小紅書營運專家」為例，原創角色可能包含平台演算法、違禁詞、筆記格式等細節，這些是通用提示詞沒有的。但若你的需求是「寫 Python 程式碼」，一個自己寫的 50 字角色可能比一個 500 字的翻譯角色更有效。
維護與授權：活躍但依賴贊助
授權是 MIT，這代表你可以自由使用、修改、商用，沒有 copyleft 限制。這對企業採用是加分項。維護方面，最後一次 push 是 2026 年 9 月，最新釋出 v1.2.6 在 2026 年 6 月，顯示專案仍然活躍。釋出紀錄中有「README 在线展示区 + 精简」這類變更，表示維護者持續調整文件與功能。但 README 大量篇幅被贊助商佔據，從 APINEBULA 到勝算雲，至少六家贊助商，這暗示專案的持續開發可能依賴商業支持。這不是壞事，但你要知道專案方向可能受贊助商影響。升級成本方面，因為角色是靜態檔案，升級通常是覆蓋或新增，不會破壞既有設定。但若你修改了角色內容，升級時可能被覆蓋，需要自己管理差異。整體而言，維護風險低，但依賴單一維護者與贊助生態是潛在隱憂。
編輯結論
agency-agents-zh 適合需要快速取得大量中文角色定義、且願意手動篩選品質的個人開發者或小團隊，尤其是要處理小紅書、抖音、微信生態或 Qt 工業上位機等冷門領域的人。不適合追求每個角色都能直接上生產線的企業，因為 README 沒有提供任何角色品質驗證機制，而且 277 個角色中有 213 個是翻譯，原創比例約 23%。採用前你該先做兩件事：第一，在目標工具（例如 Claude Code）裡實際載入 3 到 5 個你最重要的角色，確認其 system prompt 與工具格式相容，而不是只看數量；第二，檢查 agency-orchestrator 的 DAG 協作是否真的支援你的工作流程，因為角色定義檔本身不含任何編排邏輯。若你只需要單一領域的專家，直接從上游挑選或自行撰寫提示詞可能更省事。這個專案的價值在於中文在地化與垂直覆蓋，不在於 277 這個總數。
社群筆記