Single-Agent 架构模式

4.1 何时选择 Single-Agent？

Single-Agent 不是”简单”或”不成熟”的选择，而是适合特定场景的架构决策：

适用场景	特征
任务类型单一	主要处理一类任务（如客服问答）
工具数量有限	< 10 个工具
上下文需求小	不需要维护复杂的多轮状态
延迟敏感	多 Agent 会增加通信开销
快速原型	需要快速验证概念

4.2 Single-Agent 的成熟形态

白皮书强调：Single-Agent ≠ 简单

┌─────────────────────────────────────────────────────────────┐
│  成熟的 Single-Agent 架构                                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  System Prompt (精简)                                │   │
│  │  - 角色定义                                          │   │
│  │  - 核心行为准则                                      │   │
│  │  - 输出格式要求                                      │   │
│  └─────────────────────────────────────────────────────┘   │
│                          ↓                                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Skills 库 (按需加载)                                │   │
│  │  - Skill 1: 数据查询                                │   │
│  │  - Skill 2: 报告生成                                │   │
│  │  - Skill 3: 异常处理                                │   │
│  │  - ...                                              │   │
│  └─────────────────────────────────────────────────────┘   │
│                          ↓                                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Tools (MCP / 本地)                                  │   │
│  │  - Database MCP                                     │   │
│  │  - API MCP                                          │   │
│  │  - File System                                      │   │
│  └─────────────────────────────────────────────────────┘   │
│                          ↓                                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  外部状态管理                                        │   │
│  │  - 会话状态 (数据库)                                 │   │
│  │  - 用户偏好 (KV Store)                              │   │
│  │  - 任务队列                                         │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

4.3 Single-Agent 的扩展模式

当 Single-Agent 开始触及极限时，有以下扩展策略：

模式 A: Tool Routing

不增加 Agent，而是通过更智能的工具路由：

User Query
    ↓
┌──────────────────┐
│  Single Agent    │
│  + Intent Router │  ← 在工具层面做路由决策
└──────────────────┘
    ↓
┌────────┬────────┬────────┐
│ Tool A │ Tool B │ Tool C  │
└────────┴────────┴────────┘

适用场景: 任务类型相近，只是执行路径不同

模式 B: Skill-based Expansion

利用 Skills 的渐进式加载，避免上下文膨胀：

Base Context (~500 tokens)
├── Skill A 描述 (~50 tokens) [始终加载]
├── Skill B 描述 (~50 tokens) [始终加载]
├── Skill C 描述 (~50 tokens) [始终加载]
...
└── 当前激活 Skill 正文 (~2000 tokens) [按需加载]

总活跃上下文 ≈ Base + 1 Skill
而非 Base + All Skills

适用场景: 功能多样化，但每次对话只用到一小部分

模式 C: Recursive Delegation

Agent 可以将子任务委托给… 自己（递归）：

主 Agent 收到复杂任务
    ↓
分解为子任务
    ↓
对每个子任务:
    创建新的上下文实例
    → 执行子任务
    → 返回结果
    → 清理子任务上下文
    ↓
合并所有子任务结果

关键: 不是创建新 Agent，而是隔离上下文

4.4 Single-Agent 的边界信号

当出现以下信号时，应该考虑多 Agent 架构：

信号	阈值	说明
工具数量	> 20	工具选择准确率下降
Skills 数量	> 30	路由准确率下降
平均上下文长度	> 50k tokens	成本和延迟问题
任务类型	> 5 种明显不同的领域	需要专业化
独立部署需求	不同模块需要独立更新	架构解耦需求

---