Workflow vs Agent：如何为生产任务选择正确架构

用任务形态做决定

架构不是能力排行榜。Workflow、Agent 和多 Agent 是不同控制方式，各自适合不同不确定性。判断时先看任务，而不是先看想使用的技术。

决策树

先问三个问题：

1. 任务步骤能否在执行前大部分写出？
2. 错误是否必须被严格审计和回滚？
3. 是否存在单个上下文无法同时承担的专业职责？

如果前两个答案是“是”，优先 Workflow。如果第一项为“否”，但目标、工具和停止条件可明确，可以使用 Agent。只有第三项为“是”，并且并行或隔离收益足够大，才考虑多 Agent。

混合架构通常更实用

很多生产系统并不是二选一。可以让 Workflow 管理阶段、审批和重试，让 Agent 只负责某个开放节点，例如检索候选方案或分析错误原因。

确定性输入校验
  → Agent 生成候选
  → 确定性规则过滤
  → 人类批准高风险动作
  → Workflow 执行
  → 独立验证

这种结构把不确定性限制在局部，保留可测试的外壳。

反模式

Agent 包办一切

同一个 Agent 同时规划、执行、验证和批准，会产生自我确认偏差。至少把关键验收做成独立规则或独立评审角色。

为了“智能”拆成很多角色

角色越多，交接、上下文同步和冲突处理越复杂。没有明确职责差异的角色应该合并。

没有停止条件

开放循环如果没有最大轮次、预算或完成判定，会持续消耗资源并放大错误。

架构决策记录

为每个方案记录：

任务:
选择: workflow | agent | hybrid | multi-agent
关键不确定性:
允许工具:
预算:
停止条件:
失败恢复:
人工批准点:
验证方法:

可执行检查清单

• 不确定性只放在确实需要判断的节点。
• 每个 Agent 有工具白名单和预算。
• 多 Agent 角色职责不重叠。
• 交接状态结构化且可版本化。
• 高风险动作有明确人工批准点。
• 最终结果由独立检查验证。