当我们说 Agent 时，很多人脑子里只有一种模糊图像。 仿佛它要么是一个无所不能的总控智能体，要么就是一群互相聊天的小人。
但真正进入工程视角以后，你会发现 Agent 从来不是单一形态，而是一组不同的系统组织方式。
这一章最重要的结论，不是列名词，而是建立一个判断：
Agent 的不同形态不是等级关系，
而是任务复杂度、控制权分配和协作成本共同决定的系统形状。本书先采用四种最基本、也最实用的形态分类：
- 单 Agent
- 工具型 Agent
- 工作流型 Agent
- 多 Agent
这四类不是互斥的纯血物种，现实里经常混合存在。 但把它们先拆开，能帮助我们看清系统设计到底在增加什么，又在交换什么。
先看第一类：单 Agent。
单 Agent 的核心特征，不是“只有一个模型”，而是任务主要由一个统一控制器持续推进。 它自己理解目标、维护状态、调用工具、处理反馈，并决定下一步。
这种形态的最大优点是简单。
- 状态集中
- 责任集中
- 调试路径短
- tracing 更容易看
- 评测更容易建立
OpenAI 的很多单体 agent 示例、本质上都属于这一类。 它们不一定弱，恰恰相反，在模型足够强、工具足够清楚、任务边界足够明确时，单 Agent 往往是最有性价比的起点。
这也是为什么近两年越来越多研究开始提醒：
强单 Agent 应该始终是多 Agent 之前的基线。这不是保守，而是方法论。 如果一个任务连强单 Agent 都做不稳，直接拆成多个 Agent，通常只会把问题分散，而不是解决。
第二类，是工具型 Agent。
工具型 Agent 的重点不在角色分工，而在动作空间设计。 它仍然可能只有一个主要控制器，但它的能力边界被一组外部工具显著扩展了。
这类系统最关键的问题通常不是“要不要多 Agent”，而是：
- 工具定义是否清楚
- 工具边界是否合理
- 工具选择是否稳定
- 参数构造是否可靠
- 结果回流是否足够支撑下一步决策
很多今天被称为 Agent 的产品，实质上首先是工具型 Agent。 它们的价值主要来自：
- 能查信息
- 能改状态
- 能执行外部动作
- 能把外部环境重新带回决策过程
从工程角度看，工具型 Agent 其实是单 Agent 的第一个自然扩展。 它标志着系统从“只会说”变成“能做事”，但还没有进入大规模协作和复杂编排。
第三类，是工作流型 Agent。
它介于纯 workflow 和纯自由 Agent 之间。 整体路径并不是完全开放的，而是由程序、图结构或业务流程提供一个明确外壳； 但在某些步骤里，系统被允许进行局部自治决策。
这是工业界特别常见的一种形态。 因为很多业务既不能完全放给 Agent，也无法完全写死成流程图。
于是系统会变成这样：
- 外层流程负责责任链、审批、权限、日志、回滚
- 某些节点由 Agent 动态做判断、总结、路由、补查或生成
Anthropic 在公开实践里给出的 prompt chaining、routing、parallelization、orchestrator-workers，本质上都可以视作这种光谱上的不同位置。 Microsoft Agent Framework 把 workflow 和 agent 明确并置，也是在承认这种混合形态不是过渡方案，而是工业常态。
工作流型 Agent 的优势很明确：
- 比纯 Agent 更可控
- 比纯 workflow 更灵活
- 更容易挂接治理要求
- 更容易做阶段性评测
但代价也很明确：
- 控制流会变得两层化
- 一部分复杂度在图里，一部分复杂度在模型里
- 很容易出现“外层以为内层做了，内层以为外层兜底”的责任空洞
第四类，是多 Agent。
多 Agent 的核心不是数量，而是显式分工。 也就是说，系统开始把不同职责交给不同控制单元，而不是让一个总控器完成所有事情。
常见角色包括：
- 路由 Agent
- 规划 Agent
- 执行 Agent
- 审核 Agent
- 记忆或检索 Agent
- 汇总 Agent
- 领域专长 Agent
OpenAI 在 orchestration 文档里给出的 agents as tools 和 handoffs，其实对应了两种非常不同的多 Agent 语义。
第一种，是中心控制型。 主 Agent 把其他 Agent 当作能力模块来调用。 这更像“agent 作为工具”。
第二种，是接力控制型。 当前 Agent 把任务或会话控制权交给另一个 Agent。 这更像 handoff。
LangGraph 的多 Agent 架构里，又把这种差异进一步具体化成 network、supervisor、hierarchical 等模式。 这说明多 Agent 不是一个单一词，而是一组协作拓扑。
Google ADK 和 Microsoft Foundry 则把这种谱系进一步产品化了。
Google 直接区分 LLM Agents、Workflow Agents、Custom Agents。
Microsoft 则区分 Prompt agents、Workflow agents、Hosted agents，并允许把 workflow 反过来包装成一个 Workflow Agent。
这些平台化分类都在说明同一件事：
Agent 的形态首先是系统组织方式，其次才是模型使用方式。理解这一点很关键。
因为很多团队说自己在做多 Agent，实际上做的是完全不同的东西：
- 有的是一个主控器加若干专用子节点
- 有的是多个平级角色相互通信
- 有的是树状层级控制
- 有的是外层 workflow 套一个局部多 Agent 子系统
这些系统的调试方式、评测方式、故障模式和治理要求都不一样。
所以，本章真正要讲的不是“四选一”，而是“随着复杂度上升，系统会往哪些方向长”。
如果用一条最简单的谱系来表示，大概是：
单 Agent -> 工具型 Agent -> 工作流型 Agent -> 多 Agent但这条谱系绝不是“越往右越高级”。 它真正表达的是：
- 越往右，控制结构越复杂
- 越往右，通信成本越高
- 越往右，调试与评测成本越高
- 越往右，只有当任务分工收益足够大时才值得
这也是为什么研究界对多 Agent 的态度，正在从早期兴奋走向更冷静的判断。
AutoGen 代表了多 Agent 对话驱动协作的一条主线。
CAMEL 强调 role-playing 和角色一致性。
MetaGPT 更进一步，直接把多 Agent 映射成软件组织结构，把产品经理、架构师、工程师、测试等角色做成明确分工。
这些工作很重要，因为它们证明了多 Agent 不只是“多开几个聊天窗口”，而是真可以对应到分工系统。
但近年的研究同时也在提出非常重要的反证。 无论是 2025 年关于 single-agent 与 multi-agent 混合范式的实证比较，还是 2026 年关于强单体基线的研究，都在说明同一件事：
如果多个 Agent 只是同一个底座模型换几个角色 prompt，
那么多 Agent 的收益往往会被通信与协作开销吃掉。这意味着，多 Agent 的成立条件不是“任务很复杂”，而是更严格的三条：
- 角色之间确实存在不同信息边界或能力边界
- 分工之后真的能减少局部决策难度
- 协作收益大于额外通信成本和失真成本
如果做不到这三条，多 Agent 很可能只是把一个问题拆成更多消息传递。
用组织类比会很直观。
单 Agent 像一个能力较强的通才。 工具型 Agent 像一个会使用很多外部工具的通才。 工作流型 Agent 像一个在制度与流程约束中工作的团队。 多 Agent 则像一个真正分工协作的组织。
组织越复杂，并不天然更高效。 只有当任务确实需要专业分工、并行推进、角色对抗或层级审查时，复杂组织才值得建立。
举几个典型场景。
第一种，简单知识助手。 如果任务只是检索、总结、回答，一个强单 Agent 往往就够了。 强行拆成多个 Agent，通常只会增加重复思考和消息传递。
第二种，工具密集型执行任务。 如果任务核心在于稳定调用浏览器、数据库、代码执行器、企业 API，那么工具型 Agent 往往是更合适的主形态。 这里最重要的不是多角色，而是动作接口和状态回流。
第三种，强治理业务流程。 如果任务要经过鉴权、审批、记录、回滚、人工确认，工作流型 Agent 往往最合理。 外层必须可控，内层才可能局部放权。
第四种，复杂研发或长链路问题解决。 如果任务需要问题路由、任务拆解、并行执行、结果审查、最终汇总，多 Agent 才会开始体现真实价值。 但即便如此，也应优先验证“强单 Agent + 少量子能力”是否已经足够。
所以，一个成熟团队在设计形态时，通常不会先问“我要不要多 Agent”，而会先问：
第一，这个任务有没有一个强单体就能稳定解决的可能。
第二，任务复杂度主要来自工具动作、流程治理，还是角色分工。
第三，如果引入更多 Agent，新增复杂度到底换来了什么确定收益。
把这三个问题问清楚，形态选择通常就不会跑偏。
本章最后给出一个非常实用的原则：
先做强单体，再加工具；
先把闭环做稳，再加流程；
先把流程做清，再谈分工。这不是教条，而是大多数公开框架、研究系统和真实落地项目共同收敛出的次序。
因为 Agent 系统真正昂贵的，不是“多了几个角色”，而是每多一层形态，系统就多一层控制、状态、通信、评测和治理成本。
下一章开始进入第二编。 到那里我们要切换一个更现实、也更容易决定成败的视角：
业务到底是如何塑造 Agent 的。