过去一段时间，Agent 成了 AI 产品里最容易被滥用的词。只要一个功能里出现了模型调用、工具调用和一点“自主决策”，很多团队就会下意识地把它包装成 Agent。
但真正落到工程里，你很快会发现：不是所有问题都值得交给 Agent 处理。有些场景用规则、工作流、搜索或普通的 LLM 调用就够了；硬上 Agent，只会让系统更贵、更慢、更难调试。
这篇文章不讨论“Agent 是什么”，而是集中回答一个更重要的问题：什么时候根本不该用 Agent？
先说结论：判断 Agent 是否值得上的 4 个问题
在进入具体场景之前，可以先用四个问题做一次快速判断：
- 任务路径是否稳定：如果步骤固定、分支有限，工作流通常比 Agent 更可靠。
- 错误成本是否可接受：如果一次误操作就会影响订单、资金、用户数据，Agent 的自主性要极度克制。
- 是否真的需要动态决策：如果只是在固定模板里填空，没必要引入 Planner、Memory 或多轮反思。
- 系统是否可观测：如果你无法解释 Agent 为什么这么做，也无法回放其决策链路，就很难上线到关键路径。
很多“想做 Agent”的需求，问完这四个问题后，最后都会收敛成更简单的方案。
场景一：任务步骤已经固定，只是你不想手写流程
这是最常见的一类误判。团队看到一个多步骤任务，比如“读取表单 -> 校验字段 -> 调用 API -> 生成结果 -> 发通知”，就会觉得很像 Agent。
但如果步骤本身是稳定的，真正需要的通常不是 Agent，而是 workflow。
比如：
- 用户提交一份简历，系统提取字段后生成结构化候选人档案
- 销售上传客户列表，系统清洗数据后同步进 CRM
- 内容团队提交选题，系统按固定模版生成标题、摘要和社媒文案
这类任务的共同点是：输入在变，流程没变。既然流程没变，就没有必要把“下一步做什么”交给模型决定。你完全可以把流程显式写出来，把模型限制在单点能力上：
- 文本分类
- 信息提取
- 文案改写
- 结构化输出
这样做的优势很直接：
- 每一步都能单独测试
- 失败位置容易定位
- 成本更稳定
- 回归验证更简单
很多时候，所谓的“Agent 化”，本质上只是团队不想显式维护状态机和分支逻辑。但这部分复杂度不会消失，只会转移到 Prompt、日志和线上事故里。
场景二：任务要求强确定性，错一次就很麻烦
如果任务涉及资金、权限、库存、合同、数据删除等高风险动作，默认就不该让 Agent 自主完成闭环。
原因不复杂：Agent 的问题不只是“回答错”，而是“做错事”。
一个能调用工具的 Agent，错误可能出现在很多地方：
- 选错工具
- 用对工具但参数错了
- 顺序错了
- 理解错用户意图却继续执行
- 在上下文污染后做出错误动作
这类系统一旦进入执行层，风险会比普通聊天机器人高很多。因为聊天机器人回答错，用户还能自己判断；执行型 Agent 做错，代价往往已经发生了。
更合适的方案通常是：
- Agent 只负责生成建议，不直接执行
- 高风险操作进入审批流
- 参数由结构化表单确认，不完全依赖自然语言
- 关键工具调用加白名单和权限隔离
换句话说，在强确定性场景下，Agent 最多做“副驾驶”，不要做“自动驾驶”。
场景三：你真正需要的是搜索、检索或规则系统
不少产品把“用户问一个问题，系统返回一个答案”都归到 Agent 范畴里，其实很多问题更接近：
- 站内搜索
- RAG 检索
- FAQ 路由
- 规则匹配
比如客服、帮助中心、知识库问答、文档导航，这些需求的核心往往不是“规划下一步行动”，而是“尽快找到对的信息”。
如果你把这种系统做成 Agent，常见后果是：
- 先做一轮冗长推理
- 再决定要不要搜
- 找到资料后又进行一轮自由发挥
- 最终答案变长了，但不一定更准
这不仅拖慢响应速度，也会放大幻觉空间。
更务实的做法通常是：
- 先用检索或规则把候选范围缩小
- 再用模型做总结、重写或结构化整理
- 明确区分“查得到”和“查不到”
当问题的本质是“找信息”，而不是“做决策”时，Agent 通常不是第一选择。
场景四：你还没有评估体系，却已经想做自主系统
很多 Agent Demo 看起来都不错，因为它们演示的是“最顺的一次”。真正的问题出现在上线之后：它什么时候会失败，为什么失败，失败后怎么修？
如果你还没有下面这些基础设施，就不适合急着上 Agent：
- 一组可重复运行的任务样本
- 成功/失败的判定标准
- 工具调用日志与 trace
- 成本、时延、成功率的监控
- 回放错误案例的能力
Agent 不是写完 Prompt 就结束的系统，而是一个需要持续校准的系统。没有评估体系时，你很容易陷入一种假象：线上偶尔能跑通，就以为方向没问题。
但只要输入一复杂、上下文一变、工具一超时，系统行为就会迅速失控。
如果团队还在产品探索早期，我会更建议先把任务拆小：
- 先验证单步能力是否成立
- 再验证两三步串联是否稳定
- 最后才考虑把决策权逐步交给系统
不要在“还没法测”的时候，就把系统设计成“高度自主”。
场景五：Multi-Agent 只是为了看起来更高级
现在很多方案一上来就是：
- planner agent
- researcher agent
- executor agent
- reviewer agent
看起来很完整，但多数时候只是把一个本可以在单上下文里完成的任务，拆成了多个角色互相传话。
这样做的问题很实际：
- token 成本更高
- 时延更长
- 调试更困难
- 责任边界更模糊
- 上下文在多轮转述中更容易漂移
如果一个任务本质上只是：
- 读取输入
- 调一次或几次工具
- 输出结果
那么单 Agent + 明确工具约束，通常就足够了。
Multi-Agent 只有在下面这些情况下才更有意义：
- 子任务天然并行
- 上下文窗口明显不够
- 不同角色拥有明确隔离的数据与权限
- 你能证明拆分后比单 Agent 更稳定，而不是更复杂
大多数团队的问题不是 Agent 不够多，而是系统边界不够清楚。
那什么时候才适合上 Agent？
如果一个任务同时满足下面几个条件，Agent 才更值得考虑：
- 目标明确，但路径不固定
- 需要根据中间结果动态选择工具
- 允许一定试错和回退
- 有 trace、评估和人工兜底
- 任务价值足够高，能覆盖复杂度成本
一个比较典型的例子是“研究型任务”：
- 用户给出一个开放问题
- 系统需要先搜集信息
- 再判断哪些资料可信
- 然后继续追问、补充检索、汇总结论
这里的关键不是“模型会说话”，而是任务本身确实存在动态路径。只有这时，Agent 的决策能力才真正有意义。
我的建议：先把 Agent 当成能力，不要先当成架构
很多团队在一开始就问：“我们要不要做一个 Agent 架构？”
这个问题本身就容易把方向带偏。更好的问法应该是：
- 我们当前任务里，哪一部分真的需要模型动态决策？
- 哪一部分应该继续由代码、规则和工作流控制？
- 哪一部分只能建议，不能直接执行？
先回答这些问题，再决定是否要引入 Agent，会务实得多。
Agent 不是产品升级的自动答案。大多数时候，真正拉开差距的不是“用了 Agent”，而是你是否知道 什么时候不该用它。
小结
- 步骤固定的任务，优先考虑 workflow，而不是 Agent
- 高风险执行任务，优先考虑审批、约束和人工确认
- 检索型问题，优先考虑 search / RAG / rules
- 没有评估体系时，不要急着做高自主系统
- Multi-Agent 不是默认答案，很多时候只是复杂度放大器
如果把 Agent 用在真正需要动态决策的地方，它会非常有价值；但如果只是为了追热点，它大概率会成为系统里最难维护的一层。
下一篇我会继续写：一个可上线的 Agent，难点为什么根本不在 Prompt。