什么时候不该用 AI Agent：先和普通代码、Workflow 比一遍

现在很多需求评审一提到 AI，下一句就是“要不要做成 Agent”。这种顺序通常反了：先决定架构，再回头给它找场景，最后很容易把本来三条规则能解决的问题做成一套昂贵又难测的自主系统。

Agent 不是更高级的默认架构。它用延迟、成本和可预测性，换取在不确定环境里动态决策的能力。只有当这种灵活性真的值钱时，交换才成立。

先说结论

能用普通代码稳定解决的，不要为了“更智能”换成模型决策。
流程固定、只有局部需要理解文本时，优先用 Workflow 加少量 LLM 节点。
单 Agent 跑不稳时，先修目标、工具和评测，多 Agent 很少是第一剂药。
选型一定和最简单可行方案比较，不要只和“什么都不做”比较。

先问四个问题

输入是否高度非结构化？
中间步骤是否需要根据观察动态决定？
失败是否容易检测和恢复？
Agent 带来的收益是否覆盖模型、工具和治理成本？

如果前两个答案都是“否”，通常不需要 Agent。

四种实现形态

形态	控制者	适合	主要代价
普通代码	程序逻辑	规则清楚、输入结构化	灵活性低
确定性工作流	程序定义步骤	流程稳定、部分步骤可用模型	流程变化需要改代码
单 Agent	模型动态选择步骤和工具	路径难预先枚举	成本、延迟、不确定性
多 Agent	多个模型角色协作	上下文隔离或真正可并行的复杂任务	协调、冲突和评测成本

明确不该用 Agent 的场景

规则已经足够

例如：

税率计算；
字段映射；
权限判断；
固定格式转换；
定时同步；
数据库约束。

把它们交给模型只会引入随机性。

错误代价高且无法独立验证

例如直接批准贷款、自动签署合同、无审核执行生产 DDL。模型可以辅助整理信息和提出建议，但最终决策应由确定性规则或人完成。

用户只需要一次回答

没有工具、状态和多步执行的问答，不需要包装成 Agent。

延迟预算极低

多轮推理和工具调用可能需要数秒到数十秒。对几十毫秒级接口，应使用规则、缓存、小模型分类器或预计算。

没有可用工具或反馈

Agent 需要“行动—观察—修正”的闭环。如果它既不能操作环境，也拿不到行动结果，只是在反复生成文本。

团队还无法评测

没有任务集、trace、副作用检查和回滚能力时，不应该直接扩大自主权。

优先考虑“工作流中嵌入模型”

很多业务最适合：

flowchart LR
  A["确定性输入校验"] --> B["模型提取或分类"]
  B --> C["确定性业务规则"]
  C --> D["模型生成说明"]
  D --> E["人工或系统确认"]

模型只处理它擅长的非结构化环节，业务状态和权限仍由代码控制。

例如报销审核：

模型从发票和说明中提取字段；
程序校验金额、预算、重复报销和权限；
模型生成异常解释；
高风险案例交给人工。

这比让 Agent 自由决定所有步骤更稳定。

什么时候单 Agent 合理

单 Agent 适合：

工具集合有限；
目标明确但步骤取决于中间观察；
每一步都有反馈；
副作用可控；
可以设定步数、成本和时间预算；
失败后能交还用户。

优先从一个 Agent 开始。只有出现明确瓶颈，再引入角色分离。

多 Agent 的三个正当理由

上下文隔离

不同子任务需要完全不同的资料和工具。拆分可以避免一个超大上下文互相污染。

真正并行

多个互不依赖的调查可以同时进行，例如：

一个检查代码；
一个核对官方文档；
一个分析测试失败。

如果所有步骤存在顺序依赖，多 Agent 并不会更快。

独立验证

执行者和审查者使用不同上下文与标准，可以发现部分错误。但“再叫一个模型看看”不等于可靠审核，仍要有确定性测试。

不充分的多 Agent 理由

角色名字听起来专业；
一个 Agent 做不好就无限加 Agent；
希望通过投票得到事实；
把同一个 Prompt 发给多个模型；
用多 Agent 掩盖需求没有定义；
没有统一状态和最终负责人。

每增加一个 Agent，都会增加：

Prompt 和工具版本；
消息协议；
超时与重试；
权限边界；
轨迹数量；
成本；
失败组合。

一个决策流程

规则能完整表达吗？
  是 → 普通代码
  否
  ↓
步骤是否基本固定？
  是 → 确定性工作流，在局部使用模型
  否
  ↓
一个 Agent 的上下文和工具是否足够？
  是 → 单 Agent
  否
  ↓
是否存在上下文隔离、真实并行或独立验证需求？
  是 → 多 Agent
  否 → 重新缩小问题

上线前的收益计算

至少估算：

每任务价值
- 模型成本
- 工具和基础设施成本
- 人工接管成本
- 错误与补偿成本
- 评测和维护成本
= 实际收益

还要比较基线：

人工流程；
规则系统；
普通搜索；
单次模型调用；
有限状态工作流。

Agent 的效果应该和最简单可行方案比较，而不是和“什么都不做”比较。

最终原则

选择 Agent 的理由应该是：

任务确实需要模型根据不确定输入和中间反馈动态决定下一步，并且我们能够限制、观察和验证这个过程。

如果只是为了显得先进，Agent 通常是最昂贵的那条路。