intelligent-routing

智能 Agent 路由

目的：自动分析用户请求，并将其路由至最合适的一个或多个专家 Agent，无需用户明确提及。

核心原则

AI 应扮演智能项目经理，分析每项请求，并自动选择最适合完成任务的专家。

工作原理

1. 请求分析

在回应任何用户请求之前，先进行自动分析：

graph TD
    A[User Request: Add login] --> B[ANALYZE]
    B --> C[Keywords]
    B --> D[Domains]
    B --> E[Complexity]
    C --> F[SELECT AGENT]
    D --> F
    E --> F
    F --> G[security-auditor + backend-specialist]
    G --> H[AUTO-INVOKE with context]

2. Agent 选择矩阵

使用此矩阵自动选择 Agent：

用户意图	关键词	所选 Agent(s)	自动调用？
身份验证	"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	✅ 是
错误修复	"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 → 多 Agent	⚠️ 先询问
复杂任务	检测到多个领域	orchestrator → 多 Agent	⚠️ 先询问

3. 自动路由协议

第 0 级 - 自动分析（始终启用）

在回应任何请求之前：

// Pseudo-code for decision tree
function analyzeRequest(userMessage) {
    // 1. Classify request type
    const requestType = classifyRequest(userMessage);

    // 2. Detect domains
    const domains = detectDomains(userMessage);

    // 3. Determine complexity
    const complexity = assessComplexity(domains);

    // 4. Select agent(s)
    if (complexity === "SIMPLE" && domains.length === 1) {
        return selectSingleAgent(domains[0]);
    } else if (complexity === "MODERATE" && domains.length <= 2) {
        return selectMultipleAgents(domains);
    } else {
        return "orchestrator"; // Complex task
    }
}

4. 响应格式

自动选择 Agent 时，请简洁地告知用户：

🤖 **Applying knowledge of `@security-auditor` + `@backend-specialist`...**

[Proceed with specialized response]

优点：

• ✅ 用户可以看到正在应用哪方面的专业能力
• ✅ 决策过程透明
• ✅ 仍然是自动的（无需使用 /commands）

领域检测规则

单领域任务（自动调用单个 Agent）

领域	模式	Agent
安全	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

多领域任务（自动调用 Orchestrator）

如果请求匹配不同类别中的 2 个或更多领域，自动使用 orchestrator：

Example: "Create a secure login system with dark mode UI"
→ Detected: Security + Frontend
→ Auto-invoke: orchestrator
→ Orchestrator will handle: security-auditor, frontend-specialist, test-engineer

复杂度评估

简单（直接调用 Agent）

• 修改单个文件
• 任务清晰、具体
• 仅涉及一个领域
• 示例：“修复登录按钮样式”

操作：自动调用相应的 Agent

中等（2-3 个 Agent）

• 涉及 2-3 个文件
• 需求明确
• 最多涉及 2 个领域
• 示例：“为用户资料添加 API 端点”

操作：按顺序自动调用相关 Agent

复杂（需要 Orchestrator）

• 涉及多个文件/领域
• 需要做出架构决策
• 需求不明确
• 示例：“构建一个社交媒体应用”

操作：自动调用 orchestrator → 将提出苏格拉底式问题

实施规则

规则 1：静默分析

不要宣布“我正在分析你的请求……”

• ✅ 静默分析
• ✅ 告知正在应用哪个 Agent
• ❌ 避免冗长的元评论

规则 2：告知 Agent 选择

务必告知正在应用哪种专业能力：

🤖 **Applying knowledge of `@frontend-specialist`...**

I will create the component with the following characteristics:
[Continue with specialized response]

规则 3：无缝体验

用户不应察觉到与直接向合适的专家求助有什么不同。

规则 4：覆盖能力

用户仍可明确提及 Agent：

User: "Use @backend-specialist to review this"
→ Override auto-selection
→ Use explicitly mentioned agent

边缘情况

情况 1：一般性问题

User: "How does React work?"
→ Type: QUESTION
→ No agent needed
→ Respond directly with explanation

情况 2：极其模糊的请求

User: "Make it better"
→ Complexity: UNCLEAR
→ Action: Ask clarifying questions first
→ Then route to appropriate agent

情况 3：模式相互矛盾

User: "Add mobile support to the web app"
→ Conflict: mobile vs web
→ Action: Ask: "Do you want responsive web or native mobile app?"
→ Then route accordingly

与现有工作流集成

与 /orchestrate 命令配合

• 用户输入 /orchestrate：显式编排模式
• AI 检测到复杂任务：自动调用 orchestrator（结果相同）

区别：用户无需知道该命令的存在。

与苏格拉底式门控配合

• 自动路由不会绕过苏格拉底式门控
• 如果任务不明确，仍应先提问
• 然后再路由到相应的 Agent

与工作区规则配合

• 优先级：工作区规则（.agents/rules/）> 智能路由
• 如果工作区规则指定了明确的路由方式，则遵循该规则
• 若不存在明确规则，智能路由为默认方式

测试系统

测试用例

测试 1：简单的前端任务

User: "Create a dark mode toggle button"
Expected: Auto-invoke frontend-specialist
Verify: Response shows "Using @frontend-specialist"

测试 2：安全任务

User: "Review the authentication flow for vulnerabilities"
Expected: Auto-invoke security-auditor
Verify: Security-focused analysis

测试 3：复杂的多领域任务

User: "Build a chat application with real-time notifications"
Expected: Auto-invoke orchestrator
Verify: Multiple agents coordinated (backend, frontend, test)

测试 4：修复 Bug

User: "Login is not working, getting 401 error"
Expected: Auto-invoke debugger
Verify: Systematic debugging approach

性能考量

Token 用量

• 分析会为每个请求增加约 50-100 个 token
• 权衡：提高准确性，略微增加开销
• 总体而言，通过减少来回沟通来节省 token

响应时间

• 分析即时完成（模式匹配）
• 无需额外的 API 调用
• 在首次响应前完成 Agent 选择

用户引导

可选：首次说明

如果这是项目中的首次交互：

💡 **Tip**: I am configured with automatic specialist agent selection.
I will always choose the most suitable specialist for your task. You can
still mention agents explicitly with `@agent-name` if you prefer.

调试 Agent 选择

启用调试模式（用于开发）

临时添加到工作区规则文件（.agents/rules/）中：

## DEBUG: Intelligent Routing

Show selection reasoning:

- Detected domains: [list]
- Selected agent: [name]
- Reasoning: [why]

总结

intelligent-routing skill 可实现：

✅ 零命令操作（无需使用 /orchestrate）
✅ 根据请求分析自动选择专家
✅ 透明告知正在应用的专业知识
✅ 与现有工作流无缝集成
✅ 支持覆盖默认选择，显式指定 Agent 时优先采用
✅ 复杂任务回退到协调器

结果：用户无需了解系统架构，也能获得专家级响应。

---

后续步骤：将此 skill 集成到工作区规则（.agents/rules/request-routing.md）中。