明白什么时候不该用 Agent

前言：Agent 不是万能药

现在 AI 圈有个怪现象：啥都往 Agent 上靠。

做一个客服机器人？上 Agent！做一个定时任务？也上 Agent！批量处理数据？还是 Agent！

这跟当年微服务泛滥是一个病——手里拿着锤子，看啥都是钉子。

Agent 确实强大，但它带来灵活性的同时，也带来了不确定性、高成本和调试难度。很多时候，Workflow 甚至普通脚本就能搞定的事，非要用 Agent，纯属自找麻烦。

今天就说清楚：什么时候不该用 Agent，以及什么场景真的需要 Agent。

一、场景一：任务可预测 → 不需要 Agent

1.1 什么是「任务可预测」？

输入确定、输出确定、过程确定——你闭着眼都能说出每一步该做什么，这就叫可预测。

1.2 典型例子

场景	流程	为什么不需要 Agent
每日生成报表	读数据 → 统计 → 生成图表 → 发邮件	流程固定，不需要 AI 判断
RAG 知识库问答	用户提问 → 检索文档 → 组装 Prompt → 生成回答	检索和生成步骤固定
文档翻译	读取原文 → 分段 → 翻译 → 合并	翻译逻辑明确，不需要决策
SEO 文章生成	输入关键词 → 生成标题 → 写正文 → 优化	模板化流程，步骤不变

1.3 用 Agent 会怎样？

❌ Agent 版报表生成：
Thought: 用户要生成报表，我需要先连接数据库...（想了一堆废话）
Action: 连接数据库
Obs: 连接成功
Thought: 数据库连上了，接下来要查询数据...（又想了一堆）
Action: 执行 SQL
Obs: 返回 1000 条数据
Thought: 数据查到了...（继续想）
...
总计：5 次循环，3000 Token，耗时 15 秒

✅ Workflow 版报表生成：
Step 1: 连接数据库 → 执行 SQL（1 秒）
Step 2: 统计数据 → 生成图表（2 秒）
Step 3: 发送邮件（1 秒）
总计：0 次推理，50 Token，耗时 4 秒

Agent 在可预测任务上的问题：多了一层「思考」，每步都要推理，成本高、速度慢、结果还不一定对。

二、场景二：流程稳定 → 不需要 Agent

2.1 什么是「流程稳定」？

不管输入什么，执行路径基本不变，最多是在某一步做个简单判断（if-else 就能搞定）。

2.2 典型例子

客服工单处理：

Workflow 版（清晰稳定）：
  用户输入 → 意图识别 → 
    if 退款 → 走退款流程
    if 咨询 → 走知识库查询
    if 投诉 → 转人工
  → 生成回复

Agent 版（画蛇添足）：
  用户输入 → Agent 思考 → 
    "用户似乎想退款？让我查一下退款政策" → 调用工具
    "查到了退款政策，让我再想想怎么回复" → 又一轮思考
    "好的，我来回复用户" → 生成回复
    ...3 次循环才完成 Workflow 1 步搞定的事

2.3 稳定流程用 Agent 的风险

风险	说明
不确定性	同样的问题，Agent 可能走不同的路径，回答不一致
幻觉	Agent 可能「自作主张」编造信息，而不是走标准流程
效率低	简单判断 Agent 要推理好几轮，Workflow 一行 if-else
难以审计	Workflow 的每一步都清晰可追踪，Agent 的决策过程像黑盒

三、场景三：普通脚本能解决 → 不需要 Agent

3.1 什么是「普通脚本能解决」？

不需要 AI 参与的任务。纯逻辑、纯计算、纯 IO 操作，Python/Shell 脚本就能搞定，强行加 AI 只是增加了故障点。

3.2 典型例子

场景	脚本方案	Agent 方案（多此一举）
批量重命名文件	`for f in *.txt; do mv "$f" "prefix_$f"; done`	Agent 思考每个文件该不该改、改成什么名
服务器健康检查	`curl -s health_endpoint`	Agent 先思考要不要检查，再决定怎么检查
数据库备份	`mysqldump > backup.sql`	Agent 思考备份策略、选择工具…
日志分析	`grep "ERROR" app.log`	Agent 逐行读日志、分析、再搜索

3.3 一个真实案例

我见过有人用 Agent 做文件格式转换：上传图片 → Agent 判断格式 → 选择工具 → 执行转换。

一行命令的事：ffmpeg -i input.png output.webp

Agent 版本：3 次 API 调用，500 Token，耗时 8 秒。脚本版本：0.1 秒。

四、Agent 反而增加不确定性的三个原因

4.1 LLM 本身就有随机性

同样的输入，LLM 可能给出不同的输出。Temperature > 0 就有随机性，Temperature = 0 也不是完全确定。

第一次运行：
  Thought: 我需要查询数据库
  Action: query_db(sql="SELECT * FROM users")

第二次运行（相同输入）：
  Thought: 让我先看看有没有缓存
  Action: check_cache(key="users")

同个任务，不同路径。Workflow 永远不会这样。

4.2 错误会放大

Agent 的循环特性意味着：一次错误判断，后续所有步骤都会跟着偏。

Step 1: Agent 误判了用户意图（把"退款"理解成"换货"）
Step 2: 基于错误意图走了换货流程
Step 3: 返回了换货信息给用户
结果：用户要退款，你给了换货指引

Workflow 不会出现这种问题，因为意图识别和流程路由是分开的，每一步都是确定性逻辑。

4.3 调试是噩梦

Workflow 出了问题，看日志就知道哪一步卡住了。Agent 出了问题，你可能要翻几十轮 Thought-Action-Observation 的日志，才能找到它是在哪一步走偏了。

五、那什么场景真的需要 Agent？

说了这么多不该用的场景，那什么时候该用 Agent？

5.1 核心判断标准

如果任务的下一步取决于上一步的结果，而且你无法提前预测所有可能的路径，就需要 Agent。

简单来说：路径不确定 = 需要 Agent。

5.2 需要 Agent 的真实场景

场景 A：自动化调试

用户：这个 Python 脚本报错了，帮我修

Agent 思考：
  1. 看报错信息 → ImportError: No module named 'pandas'
  2. 分析：缺少 pandas 库
  3. 行动：pip install pandas
  4. 观察：安装成功
  5. 再运行 → 又报错：SyntaxError: invalid syntax on line 42
  6. 分析：语法错误，需要看代码
  7. 行动：读取 line 42 附近的代码
  8. 分析：少了冒号
  9. 行动：修复代码
  10. 再运行 → 成功！

为什么 Workflow 不行？ 因为错误类型不可预测，修复策略取决于具体报错，你没法预设所有可能的修复路径。

场景 B：研究分析

用户：帮我调研一下当前主流的向量数据库，做一个对比分析

Agent 思考：
  1. 搜索向量数据库 → 发现 Pinecone、Milvus、Weaviate、Qdrant
  2. 逐个查询特性 → 需要根据每个产品的文档调整查询策略
  3. 发现信息不够 → 搜索性能基准测试
  4. 对比价格 → 需要访问不同定价页面
  5. 综合分析 → 生成报告

为什么 Workflow 不行？ 调研方向随发现而变，可能搜到 A 后发现需要深入调查 B，这种动态调整 Workflow 做不到。

场景 C：多步代码生成

用户：帮我写一个 REST API，包含用户注册、登录、权限管理

Agent 思考：
  1. 设计 API 结构 → 生成路由定义
  2. 写数据库模型 → 需要看路由定义来决定字段
  3. 实现业务逻辑 → 需要看模型来写逻辑
  4. 写测试 → 需要看实现来写测试用例
  5. 运行测试 → 发现问题，自动修复

为什么 Workflow 不行？ 每一步的输出是下一步的输入，而且中间可能出现错误需要自动修复，这个反馈循环是 Workflow 无法处理的。

5.3 需要不需要 Agent 的判断表

判断维度	不需要 Agent	需要 Agent
路径	可预测，固定	不可预测，取决于中间结果
决策	if-else 能搞定	需要 AI 推理判断
工具	固定调用 1-2 个	需要根据情况选择不同工具
错误处理	不需要或很简单的重试	需要智能调整策略
迭代	一次性完成	需要多轮反馈循环

六、我的场景为什么需要 Agent？

说完了通用原则，说说我自己为什么选择 Agent 而不是 Workflow。

6.1 我的场景

我需要构建一个技术调研助手：给一个技术主题，自动搜索资料、阅读文档、对比分析、生成调研报告。

6.2 为什么 Workflow 不够用

1. 搜索策略需要动态调整

有时候搜一次就找到了核心资料，有时候需要换关键词、换搜索引擎、甚至去 GitHub 找源码。搜索策略取决于每次搜索的结果，Workflow 做不到「搜到 A 后发现需要深入查 B」。

2. 信息量不确定

有些主题资料很少，需要深度挖掘每一条；有些主题资料泛滥，需要筛选过滤。这需要 AI 根据实际情况判断「信息够不够」，而不是机械地执行 N 步。

3. 需要跨工具协作

搜索用 Web API，读代码用 GitHub API，查文档用向量检索，生成报告用 LLM。哪些工具组合、什么顺序调用，都取决于调研过程中发现的内容。

4. 需要反思和补充

初版报告生成后，可能发现某个维度的信息不够，需要回去补充调研。这种「生成→审查→补充→再生成」的循环，只有 Agent 能做。

6.3 如果我硬用 Workflow

Step 1: 搜索技术主题（关键词固定？不行，不同主题关键词不同）
Step 2: 阅读搜索结果（读几条？5 条？10 条？信息量不确定）
Step 3: 对比分析（维度固定？不行，不同主题对比维度不同）
Step 4: 生成报告（模板固定？不行，报告结构随主题变化）

每一步都充满了「不确定」，Workflow 的固定流程根本兜不住。强行用 Workflow，要么只能覆盖有限场景，要么需要几十个分支判断——那跟写代码有啥区别？

6.4 最终方案

我选择了 Agent + 受限工具集 的方案：

Agent 自主决策搜索策略和工具调用顺序
但工具集受限（只有搜索、文档检索、代码阅读、报告生成四个工具）
设置 max_iterations=15 防止死循环
关键节点加人审核（生成最终报告前确认）

这不是纯 Agent，也不是纯 Workflow，而是在可控范围内给 Agent 足够的自主性。

参考链接

LangChain - Agents Concepts — LangChain 官方 Agent 概念文档，详解何时使用 Agent
OpenAI - Agents Guide — OpenAI 官方 Agent 实践指南
Lilian Weng - LLM Powered Autonomous Agents — Agent 架构权威综述
Andrew Ng - AI Agentic Design Patterns — 吴恩达 Agent 设计模式
Dify - Workflow vs Agent — Dify 官方工作流和 Agent 平台

未经作者禁止转载！

本文链接： https://hyuzz-nuc.github.io/posts/when-not-to-use-agent/