本文基于Building Conversation Kernels for AI Agents中的核心示意图与文字内容，总结当前主流 Agent 架构的演进路径，并结合图示拆解其设计动机、优缺点与适用场景。
一、背景：为什么需要新的 Agent 架构？
随着 AI Agent 从单轮问答演进到复杂、多轮、工具驱动任务，传统的Single Agent System（SAS）暴露出明显问题：
- 上下文无限膨胀（Context Pollution）
- 工具与指令耦合严重
- 长对话下性能与稳定性下降
- 复杂任务难以扩展
为了解决这些问题，Agent 架构逐步从单体 → 分工 → 编排 → 群体演进。
二、On-Demand Tooling SAS：按需加载技能的单体 Agent
1. 核心思想
在传统 SAS 的基础上，引入Skill（技能）概念：
- 技能以独立
SKILL.md形式存在 - 描述：功能、输入输出、可用工具
- Agent 在运行时按需学习并注入技能
skill参考地址
2. Agent 调用关系（泳道图）
关键点：Skill 一旦加载即进入长期上下文，形成不可逆增长
3. 优点
- 比静态工具集更灵活
- 技能模块化、可复用
- 降低初始上下文负担
4. 致命问题
上下文不可逆增长（Irreversible Context Growth）
- 技能一旦注入，为保持一致性就难以移除
- 长会话后仍会走向 Context Pollution
- 本质仍是“增强版单体 Agent”
📌结论：这是过渡方案，而非终局。
三、Context Engineer / Executor SAS：双模型串行架构
1. 架构拆分
| 角色 | 模型 | 职责 |
|---|---|---|
| Context Engineer | 小模型（Fast / SFT） | 上下文工程、Query Rewrite、RAG、工具筛选 |
| Executor | 大模型（Reasoning） | 在“干净上下文”中执行 ReAct |
2. Agent 调用关系（泳道图）
关键点：Context Engineer 决定“给什么”，Executor 决定“怎么做”
3. 优点
- 高效率：小模型做“脏活累活”
- 上下文干净：Executor 不被污染
- 成本可控
4. 局限
- 工具依赖 SFT，扩展成本高
- Context Engineer 判断错误会被放大
- 系统运维复杂（双模型）
📌结论：工程效率很高，但灵活性不足。
四、Multi-Agent System（MAS）：多 Agent 分工协作
MAS 是当前主流与未来趋势，核心思想只有一句话：
让不同 Agent 各司其职，而不是让一个 Agent 无所不能
1、Basic Centralized MAS：Dialog / Planner 双 Agent
1.1 角色划分
Dialog Agent：
- 与用户交互
- 维护长期、干净记忆
Planner Agent：
- 接收 Task Specification
- 规划步骤、调用工具
1.2 Agent 调用关系（泳道图）
关键点：Dialog 不碰工具，Planner 不直接对话
1. 3 记忆策略
| Agent | 记忆特征 |
|---|---|
| Dialog | 长期、精简（只保留最终结果） |
| Planner | 短期、深度（完整执行链路） |
1.4 优点
- 指令竞争问题消失
- 支持长期对话
- 性能更稳定
1.5 缺点
单轮任务延迟略高
信息传递存在损耗
Planner 成为瓶颈
单轮任务延迟略高
信息传递存在损耗
Planner 成为瓶颈
2、Hierarchical Centralized MAS：层级化 Agent 组织
2.1 类似“公司组织结构”
- Dialog Agent（前台）
- Primary Planner（老板）
- Team Leader（部门负责人）
- Worker Agent（执行者）
2.2 Agent 调用关系（泳道图）
关键点：任务逐层拆解，结果逐层回传
2.3 适用场景
- 超复杂任务（写书、市场调研）
- 长时间异步执行
2.4 核心问题
延迟高
调试极难（电话游戏效应）
只适合高价值任务
延迟高
调试极难（电话游戏效应）
只适合高价值任务
3、Orchestrator MAS：编排者中心架构（强烈推荐）
3.1 核心角色
Orchestrator Agent：
- 全局状态机
- 路由、调度、聚合结果
Specialized Planner：
- 只做规划（Coding / Writing / Math）
Executor Agent：
- 具备重试、容错能力的“智能工具”
3.2 Agent 调用关系（泳道图）
关键点：Orchestrator 统一决策，Planner 与 Executor 完全解耦
3.3 优点
- Planner 可独立优化（CoT-SC / Critic）
- 扩展安全，不影响全局
- Executor 更稳定
3.4 核心挑战
- 规划与执行可能脱节
- Orchestrator 本身要“足够聪明”
📌结论：这是当前工程实践中最平衡的 MAS 架构。
4️⃣ 一个重要对比总结
| 架构 | 决策权 | 执行权 | 上下文控制 |
|---|---|---|---|
| SAS | 单 Agent | 单 Agent | 差 |
| Context/Executor | Context Engineer | Executor | 好 |
| Basic MAS | Planner | Planner | 很好 |
| Orchestrator MAS | Orchestrator | Executor Agent | ⭐⭐⭐⭐⭐ |
五、总结：架构选型建议
| 场景 | 推荐架构 |
|---|---|
| 简单问答 | 基础 SAS |
| 工具密集 | Context Engineer + Executor |
| 长对话 | Basic MAS |
| 超复杂任务 | Hierarchical MAS |
| 通用 AI Agent 平台 | Orchestrator MAS⭐⭐⭐⭐⭐ |
Agent 架构的本质，不是模型有多强，而是“谁在什么时候，知道什么，能做什么”。
)
