Intelligent Routing

智能 Agent 路由

目标：自动分析用户请求，并在无需用户显式提及 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：

3. 自动路由协议

TIER 0 - 自动分析（ALWAYS ACTIVE）

在响应任何请求之前：

// 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 时，需简洁告知用户：

 **正在应用 `@security-auditor` + `@backend-specialist` 的知识...**

[继续提供专业化回复]

收益：

• [OK] 用户能看到当前应用的专业能力
• [OK] 决策过程透明
• [OK] 仍然是自动化流程（不需要 /commands）

领域识别规则

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

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

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

示例："创建一个带深色模式 UI 的安全登录系统"
-> 检测到：Security + Frontend
-> 自动调用：orchestrator
-> orchestrator 将协调：security-auditor、frontend-specialist、test-engineer

复杂度评估

SIMPLE（直接调用 Agent）

• 单文件修改
• 任务清晰且具体
• 仅单一领域
• 示例："修复登录按钮样式"

动作：自动调用对应 Agent

MODERATE（2-3 个 Agent）

• 影响 2-3 个文件
• 需求清晰
• 最多 2 个领域
• 示例："为用户资料添加 API 端点"

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

COMPLEX（需要 Orchestrator）

• 涉及多文件/多领域
• 需要架构级决策
• 需求不清晰
• 示例："构建一个社交媒体应用"

动作：自动调用 orchestrator -> 将先提出苏格拉底式问题

实施规则

规则 1：静默分析

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

• [OK] 静默完成分析
• [OK] 告知正在应用哪个 Agent
• [FAIL] 避免冗长的元叙事

规则 2：告知 Agent 选择

必须告知正在应用的专家能力：

 **正在应用 `@frontend-specialist` 的知识...**

我将按以下特征创建该组件：
[继续提供专业化回复]

规则 3：无缝体验

用户体验应与“直接和正确专家对话”一致。

规则 4：覆盖能力

用户仍可显式点名 Agent：

用户："使用 @backend-specialist 来审查这段代码"
-> 覆盖自动选择
-> 使用用户显式指定的 Agent

边界场景

场景 1：通用问题

用户："React 是如何工作的？"
-> 类型：QUESTION
-> 不需要调用 Agent
-> 直接给出解释

场景 2：极度模糊的请求

用户："把它做得更好"
-> 复杂度：UNCLEAR
-> 动作：先提澄清问题
-> 然后路由到合适 Agent

场景 3：模式冲突

用户："给 Web 应用加上移动端支持"
-> 冲突：mobile vs web
-> 动作：先问“你要的是响应式 Web，还是原生移动 App？”
-> 再按结论路由

与现有工作流集成

与 /orchestrate 命令

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

区别：用户不需要知道这个命令存在。

与苏格拉底门控

• 自动路由不会绕过苏格拉底门控
• 如果任务不清晰，仍先提问
• 然后再路由到合适 Agent

与 GEMINI.md 规则

• 优先级：GEMINI.md 规则 > intelligent-routing
• 如果 GEMINI.md 指定了显式路由，按其规则执行
• 当没有显式规则时，智能路由作为默认机制

系统测试

测试用例

测试 1：简单前端任务

用户："创建一个深色模式切换按钮"
期望：自动调用 frontend-specialist
验证：回复中显示“正在应用 @frontend-specialist”

测试 2：安全任务

用户："审查认证流程中的漏洞"
期望：自动调用 security-auditor
验证：输出以安全分析为主

测试 3：复杂多领域任务

用户："构建一个带实时通知的聊天应用"
期望：自动调用 orchestrator
验证：协调多个 Agent（backend、frontend、test）

测试 4：缺陷修复

用户："登录不可用，返回 401 错误"
期望：自动调用 debugger
验证：输出体现系统化调试路径

性能注意事项

Token 使用

• 分析阶段每次请求增加约 50-100 tokens
• 权衡：更高准确率 vs 轻微开销
• 整体会减少往返沟通，反而节省 tokens

响应时间

• 分析是即时的（模式匹配）
• 不需要额外 API 调用
• Agent 选择在首次回复前完成

用户教育

可选：首次说明

如果是项目中的首次交互，可使用：

TIP:  **提示**：我已配置自动专家 Agent 选择机制。
我会始终为你的任务选择最合适的专家。如果你更偏好手动指定，
也可以使用 `@agent-name` 显式点名。

调试 Agent 选择

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

可在 GEMINI.md 中临时加入：

## DEBUG: Intelligent Routing

显示选择理由：

- 检测到的领域：[list]
- 选中的 agent：[name]
- 理由：[why]

总结

intelligent-routing 技能可实现：

[OK] 零命令操作（无需 /orchestrate）
[OK] 基于请求分析自动选择专家
[OK] 透明告知当前应用的专家能力
[OK] 与现有工作流无缝集成
[OK] 支持用户显式点名覆盖
[OK] 复杂任务自动回退到 orchestrator

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

下一步：将此技能集成到 GEMINI.md 的 TIER 0 规则。