架构演进：单体到分布式多 Agent

6.1 单体 Agent 的天花板

Single Agent Monolith 的三大瓶颈：

问题	描述	影响
Scaling Friction	无法单独优化”数据库逻辑”而不混淆”UI 逻辑”	搜索空间过大 → 幻觉参数、错误工具
Contextual Overload	巨大系统提示 + 复杂工具 schema + 对话历史	模型工作内存溢出
Single Point of Failure	一个工具 bug → 整个 Agent 崩溃	无隔离机制

6.2 Internal Specialization（内部专业化）

逻辑划分 sub-agent，但共享运行时：

┌─────────────────────────────────────────────────────────────┐
│  内部专业化优势：                                            │
│  ─────────────────                                          │
│  ① 减少搜索空间：限制 sub-agent 工具集                      │
│     → DB agent 只用查询工具 → 降低工具调用错误              │
│                                                              │
│  ② 缓解注意力稀释：专注单一域提示                           │
│     → 更尖锐的推理                                          │
│                                                              │
│  ③ 优化上下文负载：Orchestrator 路由任务                    │
│     → sub-agent 保持高信噪比上下文                          │
├─────────────────────────────────────────────────────────────┤
│  限制：                                                      │
│  ─────                                                       │
│  仍在同一进程内                                              │
│  不跨网络边界                                                │
│  无法利用官方维护的 Agent                                    │
└─────────────────────────────────────────────────────────────┘

6.3 Distributed Multi-Agent（分布式多 Agent）

关键转变：利用第三方平台提供的官方 Agent。

维度	自建 Agent	使用官方 Agent
维护责任	开发者全责 → 需跟踪上游 API 变化	平台负责 → 自动更新
域专业知识	开发者需学习每个域	平台专家团队深耕
可靠性和性能	开发者需持续测试	平台保障
开发者焦点	分散在维护 + 创新	专注核心价值

示例：

Google Agent → Python/Go/Java (ADK)
Salesforce Agent → LangChain
Workday Agent → Bespoke framework

无 A2A：自定义集成 → 维护税吞噬项目
有 A2A：标准通信 → Orchestrator 专注高层编排

6.4 架构决策树

问：是否需要多 Agent？
├─ 任务复杂度 > 单 Agent 能力？
│  ├─ 是 → 考虑专业化
│  │  ├─ 是否跨网络边界？
│  │  │  ├─ 是 → A2A（分布式）
│  │  │  ├─ 否 → Internal Specialization
│  │  ├─ 是否可用官方 Agent？
│  │  │  ├─ 是 → 优先使用（避免维护税）
│  │  │  ├─ 否 → 自建（记录维护成本）
│  ├─ 否 → 单 Agent + MCP Tools

---