先给结论
选择自动化层级的核心判据是任务确定性与上下文复杂度。若任务执行分支可枚举、控制流固定，应直接选择 Workflow，以获取最高的确定性与最低的成本。当任务路径无法提前写死，需要模型根据中间结果动态决定调用哪些有限工具时，选择单 Agent。只有当任务包含差异较大的子任务，且上下文互相干扰或存在并行处理空间时，才拆分为 Multi-Agent 进行分工协作。整体升级顺序是能用 Workflow 就不上 Agent，单体够用坚决不上多体，以此控制不确定性惩罚与倍增的消耗。
逐项对比
| 对比维度 | Workflow | Agent | Multi-Agent |
|---|---|---|---|
| 定位 | 控制流写死在代码里 | 执行路径由模型动态决定 | 多 Agent 分工协作 |
| 强项 | 确定性与可测性最高 | 灵活应对无法穷举的路径 | 隔离上下文、支持并行 |
| 弱项 | 需求变化要改代码 | 不确定性高 | 错误级联、结果合并复杂 |
| 典型场景 | 内容审核流水线、固定报表 | 开放问答带工具、编码助手 | 深度研究、多模块代码工程 |
| 成本 | 最低 | 随步数增加而上涨 | token 成本成倍增加 |
Workflow 的本质是控制流硬编码，开发者将业务逻辑与分支条件完全固化在代码中。这种方式隔离了模型幻觉对执行流的影响，在内容审核流水线或固定报表生成等流程稳定的高频任务中表现最为稳定。一旦业务需求发生变化，开发者必须手动修改代码来适应新流程，灵活性较差。
单 Agent 将控制权交给了模型，由模型根据当前状态和有限工具集自行规划执行路径。这种方式解决了开放问答或编码助手等场景下无法穷举执行分支的问题。但这种灵活性带来了不确定性，且执行成本会随着模型思考和调用工具的步数不断上涨，测试难度也随之增加。
Multi-Agent 进一步切分了任务边界。在深度研究或多模块代码工程中，不同子任务需要的背景知识差异巨大，单 Agent 容易出现注意力分散。多 Agent 协作通过职责单一的设计实现了上下文隔离，并允许不同模块并行运行。但这会引入错误级联风险，且最终的结果合并逻辑复杂，token 消耗呈现成倍增长的趋势。
面试怎么答
面试遇到这类选择题，第一步要先询问面试官任务流程是否固定、分支能否枚举。第二步直接抛出能不用就不用的降级选择框架，明确表达 Workflow 优先，单 Agent 其次，最后才是 Multi-Agent 的递进关系。这个顺序本身就是高频考点。
常见的错误答法是盲目推崇复杂架构，认为多体一定优于单体。面试官考察的核心其实是候选人对成本与不确定性惩罚的评估能力。答题时必须点明，只有在子任务上下文互扰且具备并行条件时，拆分多体才有实际收益，否则只会徒增 token 消耗与错误级联的风险，增加维护成本。