能力地图：先判断任务，再选择架构
架构选择的起点是任务特征，而不是工具偏好。输入稳定、步骤固定、验收明确的任务，优先采用 Workflow；目标明确但路径需要动态判断的任务，可以使用受约束的 Agent；需要多个专业角色并行或交接时，才考虑多 Agent。
一个合格的设计至少回答五个问题：
- 谁负责规划，谁负责执行，谁负责验收？
- 路由依据来自结构化状态，还是来自自然语言猜测？
- 交接时传递哪些最小上下文？
- 预算、重试次数和停止条件是什么？
- 失败后是回滚、降级，还是升级给人类？
考点拆解
Workflow
Workflow 把路径写在系统中。它适合批处理、审批流、固定工具链和高审计要求任务。优势是可预测、可测试、成本可估算；风险是面对未知输入时容易变得僵硬。
单 Agent
单 Agent 在一个上下文中完成规划、工具选择和结果修正。它适合边界清晰的小型探索任务。设计重点是工具白名单、最大轮次、结果格式和人工升级条件。
多 Agent
多 Agent 的价值来自职责隔离和并行，不来自角色数量。常见结构包括 router、orchestrator/worker、reviewer 和 specialist。每增加一个角色，都要同时增加输入契约、输出契约和失败路径。
学习顺序
- 先用状态机画出确定性 Workflow。
- 标出流程中真正需要判断的节点。
- 只把这些节点替换为受约束 Agent。
- 当单 Agent 的上下文或职责过载时，再拆分 specialist。
- 为每次交接增加 schema、超时、预算和可观测字段。
场景映射
考试按生产场景组织。同一道题可能同时要求你识别架构模式、配置工具、约束 Prompt，并处理上下文失败。因此复习时不要只记名词，要练习从“任务约束 → 架构决策 → 失败处理”完整推导。
可以用下面的架构决策记录：
任务目标:
可预测步骤:
需要动态判断的步骤:
允许工具:
预算与停止条件:
人工升级条件:
验收证据:常见误区
- 把所有自动化都称为 Agent，忽略确定性 Workflow。
- 用自然语言交接关键状态，没有结构化 schema。
- 只设计成功路径，没有超时、重试和幂等。
- 让多个 Agent 共享全部上下文，导致成本和冲突同步增长。
- 把“模型会自行判断”当作验收标准。
可执行检查清单
- 每个角色只有一个清晰职责。
- 路由条件可以被测试复现。
- 交接数据有结构化字段和版本。
- 每个循环都有最大轮次和停止条件。
- 失败路径包含重试、降级和人工升级。
- 最终结果有独立验证者或确定性检查。