Workflow、Agent 与多 Agent 怎么选：一张工程决策表
优先选择能解决问题的最简单架构：步骤稳定、分支可枚举时用 Workflow；需要根据中间结果动态决定下一步时用单 Agent；只有角色确实拥有不同上下文、工具或并行目标，且协作收益大于协调成本时，才使用多 Agent。不要把“更自主”误当成“更先进”。
先说结论
先问三个问题：
- **路径能否预先写出来？**能，就从 Workflow 开始。
- **下一步是否必须根据开放式结果临场决定？**是，考虑单 Agent。
- **一个 Agent 的上下文、权限或职责是否已经无法保持清晰？**是，再评估多 Agent。
本文解决的是架构选择，不展开 Agent 内部每轮如何执行；运行时细节见Agent 运行机制总览。Tool Calling 与 MCP 只是能力接入方式，也不直接决定采用哪种架构。
适合谁，不适合谁
本文适合：
- 在立项或重构阶段选择 AI 应用编排方式的开发者；
- 遇到流程不稳定、Agent 成本过高或多 Agent 相互“聊天”却不产出结果的团队；
- 需要向面试官解释技术选型依据，而不是只复述框架概念的人。
无论你原来做前端、后端、测试、客户端还是运维，都可以把熟悉的确定流程先建模为 Workflow；只有中间结果确实无法预先枚举时，才把决策权逐步交给 Agent。
本文不适合：
- 想了解 Agent 感知—决策—执行循环的人；
- 想配置 MCP Client、MCP Server 或工具 Schema 的人；
- 已有明确固定流程，只需要某个编排框架代码示例的人。
三种架构的边界
Workflow：控制流由程序决定
Workflow 把步骤、分支、重试和终止条件写在代码或流程图中。模型可以参与分类、抽取、生成，但不能任意改变主流程。
典型例子：上传合同后依次做格式校验、字段抽取、规则比对、人工复核和归档。即使某一步使用大模型，整体路径仍然可预测。
单 Agent：控制流由运行时与模型共同决定
单 Agent 获得一个目标和一组受限工具，根据观察结果反复选择下一步。程序仍控制权限、预算和停止条件，模型只在允许范围内做动态决策。
典型例子：排查线上告警。不同告警可能需要查询日志、指标、发布记录或配置，固定枚举全部路径成本很高，但所有动作可以由一个“故障诊断”角色完成。
多 Agent：多个受限角色通过协议协作
多 Agent 将任务拆给拥有不同目标、上下文、工具或权限的角色，再由确定的协调机制合并结果。它不是让多个相同模型自由讨论。
典型例子：安全变更评审中，代码分析角色只读代码，合规角色只读制度，执行角色必须在两者均通过后才能操作。这里的权限隔离和独立证据可能值得额外协调成本。
核心决策表
| 判断维度 | Workflow | 单 Agent | 多 Agent |
|---|---|---|---|
| 任务路径 | 稳定、可枚举 | 随观察动态变化 | 可拆成多个相对独立目标 |
| 成功标准 | 每步均可确定校验 | 最终结果可校验，中间路径开放 | 各角色与最终结果都可校验 |
| 工具范围 | 少且调用顺序明确 | 同一角色需要动态选工具 | 工具或权限天然分属不同角色 |
| 上下文 | 结构化、规模可控 | 一个上下文可承载 | 不同领域上下文相互干扰 |
| 并行价值 | 普通并发任务即可解决 | 单条动态决策链 | 子任务真能独立并行且可合并 |
| 风险 | 最容易审计与回放 | 需要动作级策略和预算 | 还需处理委派、冲突和责任归属 |
| 延迟与成本 | 最低、最可预测 | 随循环轮次增加 | 通常最高，且有协调开销 |
| 首选场景 | 标准业务流程 | 开放式诊断与执行 | 明确的专家分工或权限隔离 |
一条可执行的选择规则
if 步骤和分支可枚举:
选择 Workflow
else if 一个角色能在单一权限边界内完成任务:
选择单 Agent
else if 子目标独立、接口明确、收益高于协调成本:
选择多 Agent
else:
缩小任务或增加人工决策点，不要强行自治这不是永久决定。正确做法通常是先用 Workflow 建立可靠基线，再把其中无法枚举的局部替换为 Agent 节点；只有单 Agent 出现可证明的上下文或职责瓶颈时，才拆成多 Agent。
用四类案例做判断
案例一：客服工单分类与派发
需求是读取工单、分类、提取优先级，再按固定规则进入队列。类别和队列都已定义，使用 Workflow。模型只负责分类，程序校验类别并派发。
反例：因为分类使用了大模型，就把整个流程包装成 Agent。这样只会增加不可预测分支，不能提高分类质量。
案例二：跨数据源研究并形成摘要
如果数据源固定、查询模板明确，仍然可以用 Workflow 并行查询再汇总。如果用户问题差异很大，需要根据首轮证据继续选择数据源、追问或修正搜索词，可以用单 Agent，但必须限制来源、轮次和引用要求。
案例三：代码修改与安全审批
“读取需求—修改代码—运行测试—输出 diff”可以先做成单 Agent。若组织要求安全评审者与修改者权限分离，可以拆为多个角色，但审批结果必须通过结构化协议返回，最终写入权限仍由执行系统控制。
反例：创建“产品 Agent、开发 Agent、测试 Agent、经理 Agent”，让它们共享同一工具和上下文自由对话。角色名称不同并不构成有效边界。
案例四：批量生成商品描述
每个商品独立生成并校验，适合 Workflow 的并发任务，而不是多 Agent。并行不等于多 Agent：普通任务队列更便宜、更容易重试，也更容易统计失败项。
从 Workflow 渐进升级
第一步：确定性骨架
先固定输入校验、数据读取、模型调用、结果校验、人工确认和写入。记录每一步耗时、失败率和人工干预原因。
第二步：只开放一个决策点
找到最难枚举的节点，例如“根据诊断结果选择下一个只读查询工具”，将其改为单 Agent 循环。其他步骤保持确定性，避免一次性失去全部控制。
第三步：用数据证明是否要拆角色
只有出现以下证据时才考虑多 Agent：
- 单上下文经常超过预算，且可按领域稳定切分；
- 不同子任务需要互斥权限或独立审计；
- 子任务并行后能显著缩短关键路径；
- 单角色在目标之间反复冲突，拆分后存在明确交付接口。
拆分后，每个角色都应有输入、输出 Schema、可用工具、预算、成功条件和失败归属。
常见误区与失败边界
误区一：复杂需求就用多 Agent
业务复杂不等于需要多个自主角色。复杂但稳定的财务流程通常更适合 Workflow。判断依据是控制流的不确定性和角色边界，而不是需求文档长度。
误区二：模型更强后可以删除流程约束
模型能力提高可能减少错误，但不会替代鉴权、事务、幂等、审计和合规要求。越接近真实副作用，确定性外壳越重要。
误区三：多 Agent 会自动提升答案质量
如果多个角色共享相同信息、提示和模型，它们的错误可能高度相关。没有独立证据和明确仲裁规则，“互相评审”只会增加 Token 和延迟。
失败边界
以下任一条件成立时，不应升级到 Agent 或多 Agent：
- 无法定义可验证的成功标准；
- 工具调用产生不可逆副作用，却没有确认与回滚；
- 任务错误率、成本和延迟没有基线，无法判断升级收益；
- 角色之间没有结构化交付接口；
- 只是为了展示技术，而不是解决已观察到的流程问题。
可执行检查清单
选 Workflow 前
- [ ] 主步骤和异常分支可以列举
- [ ] 模型输出可被 Schema 或规则校验
- [ ] 重试、补偿和人工节点有固定位置
- [ ] 并行需求可以由普通任务队列解决
选单 Agent 前
- [ ] 下一步确实依赖开放式观察结果
- [ ] 一个角色拥有完成任务所需的清晰权限边界
- [ ] 工具、轮次、时间和费用预算已限制
- [ ] 成功与停止条件能由运行时验证
- [ ] 已有 Workflow 基线可用于比较收益
选多 Agent 前
- [ ] 每个角色有独立目标，而不只是不同人设
- [ ] 每个角色的输入、输出和工具权限明确
- [ ] 委派、超时、冲突、合并和失败责任有规则
- [ ] 并行或隔离收益能覆盖额外延迟与成本
- [ ] 减少一个角色后系统会丢失必要能力或边界
下一步
回到 Agent 专题 Hub 查看完整学习路径。确定架构后，下一步阅读Tool Calling、MCP 与 Agent 的关系，再为所选架构设计能力接入层，而不是从框架名称反推架构。