做了几个 Agent 项目之后，我最大的收获不是"Agent 能做什么"，而是**"Agent 不应该做什么"**。
这篇文章不讲技术，讲判断——一个框架，帮你决定一个问题值不值得用 Agent 解决。
最常见的误判
先看几个真实例子：
案例 1：账单自动分类
用户需求：根据交易描述自动分类"餐饮"、"交通"、"购物"
方案：用 LLM Agent 做分类
实际：一个关键词规则引擎（if contains "美团" → 餐饮）就搞定了
成本：规则引擎 2 小时开发，Agent 方案 2 天开发 + 持续调优
结论：Agent 过度设计
案例 2：客户投诉归类
用户需求：把客服收到的投诉归类到 50 个类别中
方案：规则引擎
实际：类别太多，规则写不完了——规则之间互相冲突
改为：LLM Agent
结论：Agent 适合做
同样是"分类"，为什么一个适合用规则、一个适合用 Agent？
核心区别：分类的确定性和可预期性。
账单分类 → 规则确定、类别少、关键词稳定 → 规则引擎
投诉分类 → 类别多、表达多变、边界模糊 → LLM Agent
决策框架：二维坐标
我设计了一个简单的框架，用来判断一个问题是否适合用 Agent 解决。
规则确定性
高 ←─────────────────→ 低
│ │
可预期性 │ │
(知道所有情况) │ 规则引擎 │ Agent + RAG
│ (SQL/if-else) │ (复杂分类/推理)
高 │ │
│─────────────────────│
│ │
低 │ 传统代码 │ 谨慎使用 Agent
(不知道会有啥) │ (防呆设计) │ (必须有人兜底)
│ │
└─────────────────────┘
第一象限（高确定性 + 高可预期性）→ 规则引擎
你知道所有输入的可能性，而且规则明确的。
例子：
- 根据用户等级计算折扣（已知等级 A/B/C，折扣率固定）
- 根据订单金额判断是否包邮（明确的门槛值）
- 数据格式转换（JSON → CSV，字段映射固定）
做法：写 if-else 或配置表。
第二象限（低确定性 + 高可预期性）→ Agent + RAG
规则不明确，但你知道可能出现什么情况。
例子：
- 客服投诉分类（类别固定但表达多变）
- 文档摘要（知道要摘要但不知道内容范围）
- 意图识别（知道 10 种意图但用户表达方式不确定）
做法：Agent + 少样本示例 + RAG。
第三象限（高确定性 + 低可预期性）→ 传统代码防呆
规则明确，但你不能预测用户会怎么用。
例子：
- 表单输入校验（规则明确但用户可能填任意内容）
- 支付回调处理（逻辑确定但可能收到异常的请求）
- 文件上传处理（格式已知但文件内容可能异常）
做法：传统程序 + 全面的异常处理。
第四象限（低确定性 + 低可预期性）→ 谨慎使用 Agent
规则不明确，而且不知道会遇到什么情况。
例子：
- 交易风控决策（新的欺诈手段层出不穷）
- 医疗诊断（不典型的病例）
- 法律判决（没有先例的新情况）
做法：Agent 可以辅助分析，但决策必须有人。
什么场景不需要 Agent
结合上述框架，我总结了几种 AI Agent 的"伪需求"场景：
1. 有确定的规则映射
输入 → 确定的规则 → 输出
比如：
"如果订单金额 > 200 且用户等级为 VIP，则免运费"
→ 一条 if 语句就解决了
→ 不需要 Agent
识别标志：你能不能在一张纸上写清楚所有输入到输出的映射关系？如果能，用规则引擎。
2. 高频且对延迟敏感
场景：实时广告推荐
用户打开页面 → 需要在 50ms 内返回推荐结果
Agent 做不到（LLM 推理至少要几百毫秒）
→ 用传统的协同过滤或 Embedding 检索
一种可行的混合方式：Agent 用于离线优化推荐策略，在线还是传统算法。
3. 容错率为零
场景：财务对账、交易清算
如果 Agent 算错了一笔账，可能导致数百万的损失
→ 用精确的算法和确定性程序
Agent 本身是不确定的，同一个输入两次可能产生不同的输出。容错率为零的操作不适合交给 Agent。
4. 简单的 CRUD
场景：通过聊天界面创建一条数据库记录
用户说："帮我新增一个客户，叫张三，电话 138xxxx"
→ Agent 调用 create_customer API
但用户直接在表单上填只需要 10 秒，Agent 还要多轮确认
→ 除非用户确实不方便操作 UI（如开车），否则 Agent 的价值不大
不是不能做，而是不值得——Agent 增加了复杂度但没有显著提升体验。
5. Agent 的核心问题比问题本身更难
用户："帮我改一下 HTML 里的颜色"
→ 最简单的方案：sed 's/red/blue/g'
→ Agent 方案：读文件 → 分析 → 找到颜色值 → 修改 → 验证 → 回复
当解决方案（写一行 sed）比 Agent 的流程简单时，不要用 Agent
什么场景应该用 Agent
1. 需要综合多种信息做判断
"这个客户的信用额度应该提高吗？"
需要查：历史交易、还款记录、行业数据、当前政策
→ Agent 可以整合多个数据源后给出综合判断
→ 传统方式需要人手工查 4 个系统
2. 输入表达不固定
"帮我查一下上周那个客户的单子"
→ 时间表达不精确（"上周"）、客户未指名（"那个客户"）
→ Agent 能理解这种模糊表达，通过反问或推断来补全信息
3. 多步骤、条件分支复杂
流程：
如果 A 条件 → 走分支 A1 或 A2（取决于子条件）
如果 B 条件 → 走 B1 → B2 → B3（每个步骤有不同参数）
如果 C 条件 → 需要调用外部系统确认
→ 传统代码会变成层层嵌套的 if-else，难以维护
→ Agent 能理解流程逻辑并灵活执行
4. 需要"理解"语义
"帮我把这篇文章改得更正式一些，适合在年终总结会上用"
→ "更正式"是什么？需要理解文章内容和"正式"的风格要求
→ Agent 可以只做这种需要语义理解的任务
实际决策清单
当你考虑要不要用 Agent 时，问自己这几个问题：
□ 这个问题有确定的规则吗？
是 → 用规则引擎或传统代码
否 → 继续
□ 容错率多高？
零容忍 → 不能用 Agent 做决策（可以做辅助）
有一定容错空间 → 继续
□ 延迟要求多高？
< 100ms → 用传统算法
< 1s → 混合架构（传统 + Agent）
> 1s → Agent 可行
□ 输入是结构化的还是自然语言？
结构化数据 → 传统程序更容易处理
自然语言 → Agent 适合
□ 逻辑复杂度多高？
简单的 if-else → 写规则
多分支、动态条件 → Agent
□ 场景变化频率？
半年不变 → 写死规则
每周都有新情况 → Agent 更灵活
如果多数答案指向"Agent"，那值得做。如果多数答案指向"传统方式"，那就不要为了用 AI 而用 AI。
总结
用不用 Agent，不是技术能力的判断，而是值不值得的判断。
值得用 Agent 的：多信息源推理、模糊输入、复杂多分支、语义理解
不值得用 Agent 的：确定规则映射、低延迟要求、零容错、简单 CRUD、单步非语义操作
很多人踩的坑是"手里有锤子看什么都是钉子"——学会了 Agent 就想啥都用 Agent 做。但好的工程师不仅知道怎么用 Agent，更知道什么时候不用。
AI Agent 是一个强大的工具，但不是唯一的工具。把它放在合适的位置上，它很强；把它放在不合适的位置上，它只会增加复杂度。
评论