---
title: "agent skills teams architecture evolution selection guide"
source_url: https://arxiv.org/abs/2512.08296
ingested: 2026-04-28
sha256: aa647f41babf2c4854da80373660582b900cccf6f10d327cbc898745a6cd964d
type: raw
created: 2026-05-10
updated: 2026-05-10
tags: [reinforcement-learning, skill-curation, self-evolving-agents, llm-agent, skill-repo, grpo, composite-rewards]
---
# Agent/Skills/Teams 架构演进过程及技术选型之道
**作者**：飞樰 | **来源**：阿里云开发者 | **时间**：2026年3月17日
---
> -> [[entities/agent-skills-teams-architecture-evolution-selection-guide|原文实体]]
## 背景
Agent 架构的演化路径：单点提示词调用 → 工作流编排 → 多智能体协同 → 自主规划 → Agent Skills 可复用能力 → Agent Teams 并行探索。
**核心论点**：Agent 架构的演化史，是对大模型底层能力缺失的补偿机制——本质是大家对"如何更好地注入领域知识"和"记忆管理"这两方面需求的不断探索。
---
## 一、为什么需要 Agent 架构
**训练路径的失效**：向内修改模型参数的"预训练-微调"范式在 LLM 时代暴露三大痛点：
1. 训练成本高昂且周期长
2. 效果评测与泛化难题——灾难性遗忘
3. 基座迭代速度远超训练周期——"刚毕业就失业"
**结论**：大模型在特定领域的知识内化和长周期记忆管理上存在显著挑战，必须在模型外围通过架构设计来补充——RAG、Multi-Agent、Workflow、Skills 等架构模式因此百花齐放。
---
## 二、Single Agent：知识注入与上下文窗口博弈
**架构**：System Prompt 驱动 + ReAct 自主调用工具，串行调用。
**优势**：
- 实现成本极低、开发效率极高
- 最原生的架构，运行效率极高
- 适合快速构建 Demo 或处理知识依赖较少的场景
**劣势**：
- 极度依赖上下文窗口的质量与长度
- "Lost in the Middle"——长上下文 ≠ 长记忆，模型无法精准定位领域知识
- 知识体量超过 2 万 Token 时稳定性大幅下降
**RAG 的局限**：先搜后答，但前置检索依赖 BM25 或小参数 Embedding 模型，存在关键信息漏召或误召的能力断层。
**适用条件**：
1. 场景复杂度较低，业务逻辑简单
2. 领域知识核心指令在 2 万 Token 以内可表述清楚
3. 知识库结构清晰，检索链路成熟
---
## 三、Multi-Agent：架构隔离与通信带宽的权衡
**四种模式**（Google 论文）：
- **Independent**：多 Agent 并行处理子任务不沟通，最后汇总
- **Decentralized**：点对点网状结构，Agent 直接沟通共享信息
- **Centralized**："中心辐射"模型，中央 Orchestrator 分配任务并综合输出
- **Hybrid**：层级监督 + 点对点协调，平衡控制与灵活执行
**核心逻辑**：
- **主 Agent（Orchestrator）**：意图识别 + 任务路由，不背负所有领域知识
- **Sub-Agent**：独立 Identity 空间，内化特定领域专业知识
**优势**：
- 降低单体复杂度，避免 Context Window 爆炸
- 独立调优——单个 Sub-Agent 可针对性优化而不影响其他模块
**引入的新挑战**：
1. **路由准确率压力**：Sub-Agent 数量达到几十上百时，主 Agent 面临巨大分类决策压力，一旦 Misrouting 全盘皆输
2. **局部最优导致的上下文割裂**：Sub-Agent 只关注局部最优路径，缺乏全局感知，导致重复执行（如"ECS 远程无法连接"被重复诊断）和结论冲突
3. **通信带宽限制**：传递经过 Summary 或 Rewrite 的有损上下文，关键细节丢失；若保证效果扩大带宽，则 Token 爆炸 + 耗时增长
**结论**：Multi-Agent 是一把双刃剑——解决了知识隔离问题，却将复杂度转移到 Agent 之间的通信带宽与协同上。
---
## 四、Agent Skills：可复用与渐进式的能力披露
**核心转变**：不再盲目堆叠 Multi-Agent，而是构建基于文件系统的可复用能力包。
**与动态修改 System Prompt 的关键差异**：
- 动态替换 System Prompt 易导致认知冲突（Cognitive Dissonance）——History 与 System Prompt 指令错位，模型困惑
- Agent Skills 的做法：System Prompt 恒定（人设身份不变），Skills 内容以 User Prompt 形式渐进式披露，模型感知为"用户在提供参考资料"
**三大核心机制**：
1. **能力封装复用**：领域知识封装成独立的 Skills 文件包（Guide Book），跨 Agent 复用
2. **按需调度**：主 Agent 不预加载所有知识，运行中按需动态读取
3. **渐进式披露（Progressive Disclosure）**：先通过目录概览定位技能，再逐步深入；执行中发现缺少知识可主动触发下一个 Skills 加载
**带来的收益**：
- 低成本知识注入——模型按需阅读，无需全量预加载，比 Multi-Agent 更轻量，比 RAG 更精准
- 全局上下文一致性——始终由同一主 Agent 执行，完整知晓已执行步骤和已读取 Skills
- 规避 Context 爆炸——"读一点、做一点、再读一点"的流式处理
**缺点**：Skills 切换过于频繁时，累积上下文仍可能变长，需配合上下文压缩或滑动窗口管理策略。
---
## 五、Agent Teams："协同共创"的探索式形态
**与 Multi-Agent 的核心区别**：
| 维度 | 传统 Multi-Agent | Agent Teams |
|------|----------------|-------------|
| Agent 角色 | 独立"员工"，提交最终结果 | 真正的"特种小队" |
| 运行方式 | 串行或零交流 | 并行探索 |
| 上下文 | 隔离或点对点通信 | **共享 Task List / Shared Context** |
| 目标感知 | 局部最优 | 共享同一终极目标 |
| 信息流动 | 单向汇报 | 实时写入进度、发现和思考 |
**解决的问题**：高度不确定性的决策难题——当面对没有标准答案的问题时：
- 单一路径风险：预设路径错误则全盘皆输
- 多维度试错：多个不同 Identity Agent 并发尝试不同解题思路
- 最优解涌现：对比多条路径的中间结果，汇聚或融合最优方案
**Agent Teams 的工程哲学**：在未知面前，并行的多样性优于串行的确定性。
**缺点**：
- 算力成本成倍增加
- 需要高效的共享 Task List 机制避免读写冲突
---
## 六、Google DeepMind 论文：5 条反直觉结论
论文《Towards a Science of Scaling Agent Systems》通过大量 Benchmark 得出：
### 1. 模型越强效果越好，但并非 Agent 越多效果就越好
更强大的模型带来的 Agent 效果提升基本呈正相关。但 Multi-Agent 有时显著提升效果，有时反而降低效果——不是"无脑堆 Agent 数量"就能提高效果。
### 2. 尽量降低沟通成本和通信带宽
在固定 Token 预算下，频繁的 Agent 间沟通会显著降低系统整体效果——沟通本身消耗宝贵的 Context Window，挤占推理和知识注入空间。
**启示**：能由单个 Agent 内部消化的逻辑，尽量不要拆分成多轮对话。
### 3. 单 Agent 的 45% 阈值法则
当单个 Agent 任务成功率达到 **45% 以上**时，单纯增加 Agent 数量带来的收益边际递减，甚至为负。
**警示**：如果单智能体基线已超过 45%，盲目增加 Multi-Agent 协同机制反而降低整体表现，应简化架构。
### 4. 错误放大效应
- 纯粹的 Independent 架构可将错误放大 **17.2 倍**
- 引入中心化机制后，错误放大控制在 **4.4 倍**
**解读**：没有监管的"群策群力"极易演变成"集体幻觉"，缺乏强有力的 Manager 进行校验和纠偏时，多个 Agent 同时犯错并相互印证的概率极高。
### 5. 场景决定架构：没有万能钥匙
| 任务类型 | 最佳架构 | 原因 |
|---------|---------|------|
| 规划类（PlanCraft） | Single Agent | 逻辑性强、工具依赖少，避免不必要的调度开销 |
| 工具使用类（WorkBench/BrowseComp-Plus）| 去中心化 Multi-Agent | 充分发挥效率优势 |
| 垂类场景（Finance Agent） | 中心化协作 | 对错误零容忍，严格把控每一步操作 |
---
## 七、Agent 架构选型之道
**奥卡姆剃刀原则**：如无必要，勿增实体。
| 优先级 | 选型 | 触发条件 |
|--------|------|---------|
| **P0** | Single Agent | 能用则绝不上复杂架构 |
| **P1** | Agent Skills | 遇到知识瓶颈，优先通过渐进式加载扩展能力边界 |
| **P2** | Multi-Agent | 上述方案失效，且对效果上限有极致追求时，谨慎启动并做好长期调优准备 |
| **P3** | Agent Teams | 针对高度不确定的探索性任务，灵活叠加并行协作能力 |
**Manus AI 的口号**："Less structure, More intelligence."——盲目追求 Multi-Agent 的"高大上"会陷入通信泥潭和错误放大陷阱；在应该并行时固守单点 Agent，又会失去效率红利。
---
## 参考链接
- Google DeepMind《Towards a Science of Scaling Agent Systems》：https://arxiv.org/abs/2512.08296
- Anthropic《The Complete Guide to Building Skills for Claude》：https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf
- Anthropic Agent Teams 文档：https://code.claude.com/docs/en/agent-teams