| name | intelligent-routing |
| description | 自動代理選擇與智慧任務路由。分析使用者請求並自動選擇最佳專家代理,無需使用者明確提及。 |
| version | 1.0.0 |
智慧代理路由
目的:自動分析使用者請求,並將其路由到最適當的專家代理,無需使用者明確提及。
核心原則
AI 應該擔任智慧專案經理,分析每個請求並自動選擇最佳專家。
運作方式
1. 請求分析
在回應任何使用者請求前,執行自動分析:
graph TD
A[使用者請求:新增登入] --> B[分析]
B --> C[關鍵字]
B --> D[領域]
B --> E[複雜度]
C --> F[選擇代理]
D --> F
E --> F
F --> G[security-auditor + backend-specialist]
G --> H[自動調用並附帶情境]
2. 代理選擇矩陣
使用此矩陣自動選擇代理:
| 使用者意圖 | 關鍵字 | 選擇的代理 | 自動調用? |
|---|
| 驗證 | 「login」、「auth」、「signup」、「password」 | security-auditor + backend-specialist | ✅ 是 |
| UI 元件 | 「button」、「card」、「layout」、「style」 | frontend-specialist | ✅ 是 |
| 行動 UI | 「screen」、「navigation」、「touch」、「gesture」 | mobile-developer | ✅ 是 |
| API 端點 | 「endpoint」、「route」、「API」、「POST」、「GET」 | backend-specialist | ✅ 是 |
| 資料庫 | 「schema」、「migration」、「query」、「table」 | database-architect + backend-specialist | ✅ 是 |
| Bug 修復 | 「error」、「bug」、「not working」、「broken」 | debugger | ✅ 是 |
| 測試 | 「test」、「coverage」、「unit」、「e2e」 | test-engineer | ✅ 是 |
| 部署 | 「deploy」、「production」、「CI/CD」、「docker」 | devops-engineer | ✅ 是 |
| 安全審查 | 「security」、「vulnerability」、「exploit」 | security-auditor + penetration-tester | ✅ 是 |
| 效能 | 「slow」、「optimize」、「performance」、「speed」 | performance-optimizer | ✅ 是 |
| 產品定義 | 「requirements」、「user story」、「backlog」、「MVP」 | product-owner | ✅ 是 |
| 新功能 | 「build」、「create」、「implement」、「new app」 | orchestrator → 多代理 | ⚠️ 先詢問 |
| 複雜任務 | 偵測到多個領域 | orchestrator → 多代理 | ⚠️ 先詢問 |
3. 自動路由協議
第 0 層 — 自動分析(始終啟用)
在回應任何請求前:
function analyzeRequest(userMessage) {
const requestType = classifyRequest(userMessage);
const domains = detectDomains(userMessage);
const complexity = assessComplexity(domains);
if (complexity === "SIMPLE" && domains.length === 1) {
return selectSingleAgent(domains[0]);
} else if (complexity === "MODERATE" && domains.length <= 2) {
return selectMultipleAgents(domains);
} else {
return "orchestrator";
}
}
4. 回應格式
自動選擇代理時,簡潔地告知使用者:
🤖 **應用 `@security-auditor` + `@backend-specialist` 的知識...**
[繼續專業回應]
好處:
- ✅ 使用者看到正在應用哪種專長
- ✅ 透明的決策過程
- ✅ 仍然是自動的(不需要 /commands)
領域偵測規則
單一領域任務(自動調用單一代理)
| 領域 | 模式 | 代理 |
|---|
| 安全 | auth、login、jwt、password、hash、token | security-auditor |
| 前端 | component、react、vue、css、html、tailwind | frontend-specialist |
| 後端 | api、server、express、fastapi、node | backend-specialist |
| 行動 | react native、flutter、ios、android、expo | mobile-developer |
| 資料庫 | prisma、sql、mongodb、schema、migration | database-architect |
| 測試 | test、jest、vitest、playwright、cypress | test-engineer |
| DevOps | docker、kubernetes、ci/cd、pm2、nginx | devops-engineer |
| 除錯 | error、bug、crash、not working、issue | debugger |
| 效能 | slow、lag、optimize、cache、performance | performance-optimizer |
| SEO | seo、meta、analytics、sitemap、robots | seo-specialist |
| 遊戲 | unity、godot、phaser、game、multiplayer | game-developer |
多領域任務(自動調用協調器)
如果請求匹配來自不同類別的 2+ 個領域,自動使用 orchestrator:
範例:「建立一個帶暗色模式 UI 的安全登入系統」
→ 偵測到:安全 + 前端
→ 自動調用:orchestrator
→ 協調器將處理:security-auditor、frontend-specialist、test-engineer
複雜度評估
簡單(直接代理調用)
- 單一檔案編輯
- 清晰、具體的任務
- 僅一個領域
- 範例:「修復登入按鈕樣式」
動作:自動調用對應代理
中等(2-3 個代理)
- 影響 2-3 個檔案
- 清晰的需求
- 最多 2 個領域
- 範例:「新增使用者個人資料的 API 端點」
動作:依序自動調用相關代理
複雜(需要協調器)
- 多個檔案/領域
- 需要架構決策
- 不明確的需求
- 範例:「建構一個社群媒體應用」
動作:自動調用 orchestrator → 將提出蘇格拉底式問題
實作規則
規則 1:靜默分析
不要宣布「我正在分析你的請求......」
- ✅ 靜默分析
- ✅ 告知正在應用哪個代理
- ❌ 避免冗長的後設評論
規則 2:告知代理選擇
要告知正在應用哪種專長:
🤖 **應用 `@frontend-specialist` 的知識...**
我將以以下特徵建立元件:
[繼續專業回應]
規則 3:無縫體驗
使用者不應該注意到與直接與正確專家對話的區別。
規則 4:覆蓋能力
使用者仍可明確提及代理:
使用者:「使用 @backend-specialist 來審查這個」
→ 覆蓋自動選擇
→ 使用明確提到的代理
邊界情況
情況 1:通用問題
使用者:「React 如何運作?」
→ 類型:問題
→ 不需要代理
→ 直接回應說明
情況 2:極度模糊的請求
使用者:「讓它更好」
→ 複雜度:不明確
→ 動作:先詢問澄清問題
→ 然後路由到適當代理
情況 3:矛盾模式
使用者:「為 Web 應用新增行動支援」
→ 衝突:行動 vs web
→ 動作:詢問:「你想要響應式 Web 還是原生行動應用?」
→ 然後相應路由
與現有工作流的整合
與 /orchestrate 指令
- 使用者輸入
/orchestrate:明確的協調模式
- AI 偵測到複雜任務:自動調用協調器(相同結果)
差異:使用者不需要知道該指令存在。
與蘇格拉底閘門
- 自動路由不會繞過蘇格拉底閘門
- 如果任務不明確,仍然先提問
- 然後路由到適當代理
與 GEMINI.md 規則
- 優先順序:GEMINI.md 規則 > intelligent-routing
- 如果 GEMINI.md 指定了明確路由,遵循它
- 智慧路由是沒有明確規則時的預設
測試系統
測試案例
測試 1:簡單前端任務
使用者:「建立一個暗色模式切換按鈕」
預期:自動調用 frontend-specialist
驗證:回應顯示「使用 @frontend-specialist」
測試 2:安全任務
使用者:「審查驗證流程的弱點」
預期:自動調用 security-auditor
驗證:以安全性為重點的分析
測試 3:複雜的跨領域任務
使用者:「打造一個帶即時通知的聊天應用」
預期:自動調用 orchestrator
驗證:多代理協調(後端、前端、測試)
測試 4:Bug 修復
使用者:「登入無法運作,出現 401 錯誤」
預期:自動調用 debugger
驗證:系統化的除錯流程
效能考量
Token 用量
- 分析每個請求多耗約 50–100 tokens
- 取捨:較高的準確度換來些微額外成本
- 整體上節省 tokens,因為減少了來回往返
回應時間
- 分析是即時的(樣式比對)
- 不需要額外的 API 呼叫
- 代理選擇在首次回應前就完成
使用者教育
選用:首次解釋
若這是專案中的第一次互動:
💡 **小提示**:本系統已設定為自動選擇專家代理。我會為你的任務挑選最適合的專家。如果你偏好,仍可以用 `@agent-name` 明確指定代理。
除錯代理選擇
啟用除錯模式(開發用)
暫時加到 GEMINI.md:
## DEBUG: Intelligent Routing
顯示選擇的推論:
- 偵測到的領域:[列表]
- 選擇的代理:[名稱]
- 理由:[原因]
摘要
intelligent-routing 技能啟用:
✅ 零指令操作(不需要 /orchestrate)
✅ 基於請求分析的自動專家選擇
✅ 透明地溝通正在應用哪種專長
✅ 與現有工作流無縫整合
✅ 明確代理提及的覆蓋能力
✅ 複雜任務退回到協調器
結果:使用者無需了解系統架構即可獲得專家級回應。
下一步:將此技能整合進 GEMINI.md 的 TIER 0 規則。