跳到主要内容

AI Agent 常见反模式

学 AI Agent 的时候，很多人最开始关注的都是：

  • 怎么让系统跑起来
  • 怎么接工具
  • 怎么让它多步执行

但做着做着就会发现，真正让系统难以变稳的，往往不是“不会搭”，而是：

用了很多看起来合理、实际上会把系统拖向不可控状态的错误模式。

这些错误模式，也就是 Anti-Patterns。

这篇文档的目标，是把做 Agent 时最常见的一批反模式拆清楚，帮助你更早建立判断力。

1. 什么是 Anti-Pattern​

Anti-Pattern 可以理解为：

表面上像解决方案，实际上会持续制造问题的一类做法。

它和普通 bug 不一样。

bug 往往是单点错误；anti-pattern 则是一种系统性习惯：

  • 一开始看起来能跑
  • 短期内甚至挺省事
  • 但随着复杂度上升，会不断放大成本和混乱

所以学 Agent 时，知道“什么是好的模式”很重要，知道“哪些看似方便的路不要走”同样重要。

2. 为什么 Agent 特别容易出现反模式​

因为 Agent 系统天然具备几个特点：

  • 行为不确定性更强
  • 多变量同时变化
  • 中间步骤比最终结果更重要
  • 很多问题不是立即爆炸，而是慢慢积累

这会导致团队很容易采用一些“先跑通再说”的做法。

这些做法在原型期没问题，但如果不及时识别，后面会越来越难收拾。

3. 反模式一：把所有复杂任务都默认做成 Agent​

这是最常见的一种。

表面思路是：

  • 任务复杂
  • 所以用 Agent

但真实情况往往是：

  • 很多任务其实只需要固定 Workflow
  • 上 Agent 只会增加不确定性和调试成本

怎么识别：

  • 路径其实 80% 能提前写出来
  • 中间决策很少
  • 主要问题是流程而不是推理

更好的做法：

  • 先用 Workflow
  • 只把真正需要运行时决策的节点 Agent 化

4. 反模式二：把多步执行误当成 Agent​

系统做了：

  1. 检索
  2. 调工具
  3. 输出答案

很多人就会说“这是个 Agent”。

但它可能只是一个多步 Workflow。

问题在于，如果定义都没分清，后面很多设计判断都会错位：

  • 会过度设计 state
  • 过度设计 memory
  • 过度引入 planning

更好的做法：

  • 先区分 Workflow 和 Agent
  • 明确“下一步是谁决定的”

5. 反模式三：一上来就多 Agent​

很多人会天然觉得：

  • 一个 Agent 已经不错了
  • 多个 Agent 分工协作应该更强

但现实通常是：

  • 协调复杂度先上来了
  • 状态同步更难了
  • 责任边界更模糊了
  • 问题更难排查了

更好的做法：

  • 先把单 Agent 做稳
  • 明确单 Agent 的瓶颈在哪
  • 只有当分工收益真的明显时，再考虑多 Agent

6. 反模式四：没有状态管理，只靠历史消息硬撑​

很多初版系统会把“多轮对话历史”直接当成状态管理。

短期看起来没问题，长期就会出现：

  • 失忆
  • 重复动作
  • 状态污染
  • 重点信息淹没

更好的做法：

  • 显式维护 State
  • 区分历史消息、当前状态、长期记忆

7. 反模式五：什么都记成 Memory​

一旦开始学 Memory，很多系统就会进入“尽量多记”的倾向。

但结果往往是：

  • 临时偏好变长期规则
  • 错误信息被写成事实
  • 历史信息不断污染当前任务

更好的做法：

  • 先把 State 管清楚
  • 只有稳定、可复用的信息才进入 Memory
  • 给 memory 写入设置明确规则

8. 反模式六：所有问题都靠改 Prompt​

这是 Agent 项目里非常高频的误判。

一看到系统表现不好，就立即：

  • 改 prompt
  • 加规则
  • 再塞更多说明

但很多问题根本不是 prompt 问题，而是：

  • 工具 schema 差
  • 状态设计不清
  • 编排逻辑有问题
  • 停止条件不明确

更好的做法：

先分层判断问题属于哪一层：

  • Prompt
  • Tool
  • State
  • Orchestration
  • Evaluation

9. 反模式七：不做评估，只凭感觉优化​

很多系统迭代方式是：

  • 改一版
  • 问几个问题
  • 觉得还不错
  • 就继续往前走

这会直接导致：

  • 不知道哪次优化真的有效
  • 看不到局部提升以外的退化
  • 无法积累回归能力

更好的做法：

  • 建立最小任务集
  • 保留失败案例
  • 做版本对比

10. 反模式八：只看最终答案，不看轨迹​

对普通问答来说，很多时候看结果就够了。

但对 Agent 来说，很多核心问题都藏在过程里：

  • 为什么选了这个工具
  • 为什么多跑了 4 步
  • 为什么明明拿到证据却没用上

更好的做法：

  • 记录 step trace
  • 记录工具调用
  • 记录状态变化
  • 记录停止原因

11. 反模式九：没有明确停止条件​

如果系统没有：

  • 最大步数
  • 重试上限
  • 完成条件

那它就很容易：

  • 无意义循环
  • 多次重复同类操作
  • 成本飙升

更好的做法：

  • 设置最大步数
  • 设置重试限制
  • 定义任务完成标准

12. 反模式十：高风险动作默认自动执行​

当 Agent 开始具备行动能力时，这个问题会非常危险。

比如：

  • 写库
  • 发消息
  • 删除数据
  • 调高风险 API

如果默认全自动，会把风险快速放大。

更好的做法：

  • 做风险分层
  • 引入 guardrails
  • 对高风险动作加入 human-in-the-loop

13. 反模式十一：过早上重框架​

很多人刚学 Agent 就想：

  • 先选一个最强框架
  • 再往里面塞需求

这很容易带来：

  • 抽象太厚
  • 很多行为看不懂
  • 调试难度上升

更好的做法：

  • 先搞清系统本质
  • 先用最小实现把主链跑通
  • 真遇到复杂度瓶颈时，再加框架

14. 反模式十二：没有 Demo 和生产的边界意识​

有些系统在 demo 阶段能跑得很好，但团队会不知不觉把 demo 逻辑直接带进生产。

这时就会缺很多关键东西：

  • evals
  • harness
  • observability
  • guardrails
  • fallback

更好的做法：

  • 明确区分原型、实验、生产阶段
  • 每进入下一阶段就补齐对应工程能力

15. 一个很实用的自检清单​

如果想快速判断系统有没有掉进反模式，可以问：

  1. 我们是不是把 Workflow 误做成了 Agent
  2. 我们是不是在用 prompt 掩盖结构问题
  3. 我们是不是没有显式状态
  4. 我们是不是没有任务集和回归验证
  5. 我们是不是只看最终答案
  6. 我们是不是对高风险动作缺少边界

如果这里面好几项都答不上来，通常说明系统已经在反模式边缘了。

16. 一句话总结​

很多 Agent 失败，不是因为模型不够强，而是因为系统一步步滑进了反模式：

  • 该简单时做复杂
  • 该分层时全混在一起
  • 该记录时没记录
  • 该评估时凭感觉
  • 该设边界时放任自动化

所以真正成熟的 Agent 工程能力，除了知道怎么搭系统，也包括：

尽早识别哪些做法虽然一时省事，但会让系统越来越难稳。