Appearance
并非所有 Agent 都长一样。从"简单反射"到"多智能体协作",Agent 按复杂度分多个层级,每个层级构建在前一层之上。本笔记梳理微软官方分类的 7 种类型,以及"何时该用、何时不该用"。
七种 Agent 类型
以"旅行预订智能体"为贯穿示例:
| 类型 | 做什么 | 旅行示例 |
|---|---|---|
| Simple Reflex(简单反射) | 遵循硬编码规则,无记忆、无规划 | 看到投诉邮件 → 直接转客服 |
| Model-Based Reflex(基于模型反射) | 维护内部世界模型并随变化更新 | 追踪历史机票价,标记突然涨价的航线 |
| Goal-Based(基于目标) | 有目标并逐步规划达成 | 从当前位置出发,一次订完机票+租车+酒店 |
| Utility-Based(基于效用) | 不只要"一个解",要"最优解",权衡取舍 | 平衡价格 vs 便利,选最符合偏好的行程 |
| Learning(学习型) | 从反馈中持续改进 | 根据行程后评分调整未来推荐 |
| Hierarchical(分层型) | 高层 Agent 拆解任务并委派给下层 | "取消行程"拆为:取消机票/酒店/租车,各交子 Agent |
| Multi-Agent Systems(多智能体) | 多个独立 Agent 协作或竞争 | 协作:酒店/机票/娱乐各一个 Agent;竞争:多个 Agent 抢最优房价 |
何时该用 AI Agent
Agent 在以下场景最能发挥价值:
- 开放式问题:解决步骤无法预先写死,需要 LLM 动态摸索路径
- 多步骤流程:任务需跨多轮调用工具,而非一次性查/生成
- 随时间改进:希望系统根据用户反馈或环境信号越变越聪明
何时不该用
"能造 Agent 不代表应该造 Agent。"
- 单步、确定性任务(直接查一次数据库就有答案)→ 普通 API 即可
- 高度受监管、容错率极低的场景 → 需严格人工把关
- 简单的规则分支 → 传统代码更可靠、更快、更省钱
判断原则:Agent 的价值在于"动态决策"。如果流程是固定不变的,用工作流/代码;只有流程需要模型现场判断时,才值得引入 Agent。
关键取舍
| 维度 | 简单 Agent | 复杂多 Agent |
|---|---|---|
| 复杂度 | 低,单个循环 | 高,需编排与通信 |
| 可解释性 | 较易跟踪 | 较难(多 Agent 决策链长) |
| 成本 | 低 | 高(多次 LLM 调用) |
| 适用 | 单任务、明确步骤 | 复杂协作、并行子任务 |
一句话总结
Agent 七类从简单反射层层递进到多智能体;判断铁律是"流程固定用工作流、需要现场动态决策才上 Agent",能造不等于应该造。
关联概念
- 相关:[AI-Agent-概述与核心组成](/学习笔记/AI技术/AI Agent/AI-Agent-概述与核心组成)、[AI-Agent-主流框架对比](/学习笔记/AI技术/AI Agent/AI-Agent-主流框架对比)
- 延伸:多 Agent 系统与 [AI-Agent-学习路径与资源](/学习笔记/AI技术/AI Agent/AI-Agent-学习路径与资源) 中的"多 Agent 协作"章节