什么时候值得做 Agent

一句话理解：只有当任务同时满足“跨系统、多步骤、需要判断、最终要执行”时，Agent 才值得它带来的成本、延迟和风险；否则，更简单的方案通常更好。

“我们也做个 Agent 吧”是这两年最常见、也最容易浪费资源的需求。Agent 并不免费：它比单次模型调用更慢、更贵，结果更难预测，还需要额外的权限、验证与评估体系。一个本来用 Excel 公式、一条 SQL 或固定流程就能解决的问题，被做成 Agent 之后，往往变得既不稳定又难以维护。

这一课给你一套判断方法：先判断“该不该”，再决定“做多大”。

四个条件

条件	含义	判断问题	满足的例子
跨系统	需要从多个来源获取信息或在多个系统中操作	人做这件事要开几个系统？	查一个售后问题要看订单系统、支付系统、工单系统
多步骤	无法一次调用完成，需要多轮获取与处理	至少要几步才能完成？	销售归因要先看总量、再拆维度、再下钻
需要判断	下一步做什么取决于中间结果，难以穷举规则	能否画出一张覆盖所有情况的流程图？	SEO 流量下降可能是收录、排名、技术、季节性等多种原因
最终要执行	用户要的是被完成的结果，而不只是一个答案	交付物是一段文字，还是一个被改变的状态？	创建工单、提交代码、发出通知

四个条件像四道闸门，缺一不可：

四个条件都满足，Agent 通常是合适的选择。只满足其中一两个时，往往有更好的方案：

Anthropic 在工程博客中给过类似建议：先寻找最简单的可行方案，只在确实需要时才增加复杂度；Agent 更适合那些难以预测需要多少步骤的开放式问题。

常见反例

需求	为什么不适合做成 Agent	更好的方案
每天早上 9 点把昨日销售数据发到群里	步骤完全固定，无需判断	定时任务 + 报表模板
把用户上传的发票识别成结构化字段	单步转换，无需多轮行动	单次模型调用 + 结构化输出
回答“退货政策是什么”	只需要检索与回答	知识库问答（RAG）
根据订单金额计算返利	规则明确，要求 100% 准确	规则引擎或普通代码
批量把 1 万条商品标题翻译成英文	可并行、步骤固定	批处理脚本调用模型
自动给所有逾期客户发催款邮件	步骤固定且风险高	Workflow + 人工抽检

一个常见信号：如果你能画出一张覆盖 95% 情况的流程图，那就先做 Workflow，只把剩下 5% 的复杂情况交给 Agent 或人工。

值得做 Agent 的正面例子

订单售后诊断：问题原因多样（支付回调丢失、库存不足、优惠券规则冲突、地址信息有误……），需要跨多个系统查证，每一步查什么取决于前一步发现了什么，最终要创建工单、通知相关方。四个条件全部满足。

Coding Agent 修 Bug：需要搜索代码、阅读多个文件、修改、运行测试、根据失败信息再修改。路径无法预知，而且有测试这种天然的验证手段，是 Agent 最成熟的场景之一。

SEO 诊断：流量下降的原因分布广，需要调用 Search Console、爬虫、站点地图等多个数据源，根据发现逐步缩小范围。如果只是“生成一份固定格式的周报”，则不需要 Agent。

除了“能不能”，还要算“值不值”

满足四个条件，只说明 Agent 技术上合适，还要过一遍商业与风险的账：

维度	要回答的问题	危险信号
频率	这个任务每周发生多少次？	一个月一次，做 Agent 的投入难以回收
人工成本	人做一次要多久、什么级别的人？	5 分钟就能完成的简单任务
容错度	做错一次的代价是什么？可以挽回吗？	涉及资金、法律、不可逆删除且无法人工复核
可验证性	有没有办法检查 Agent 做得对不对？	结果对错只能靠资深专家主观判断
数据与工具可得性	需要的系统有 API 吗？权限拿得到吗？	关键系统只能人工登录、没有接口
成功率门槛	成功率要到多少用户才愿意用？	要求接近 100%，但任务本身高度模糊

一个实用的估算方式：

单任务价值 ≈ 人工耗时 × 人力成本 × 成功率 − 单任务 Agent 成本 − 失败处理成本

成本模型的细节见成本模型，完整的商业测算见商业化与 ROI。

从小处起步：自主性可以逐步放开

即使结论是“值得做”，也不必一开始就做全自动：

1. 只读诊断：Agent 查数据、给结论与证据，人来执行。
2. 草稿 + 确认：Agent 准备好工单或邮件草稿，人点确认。
3. 低风险自动：查询、分类、内部通知自动执行，高风险动作仍需确认。
4. 按数据放权：评测与线上数据证明可靠后，再逐步扩大自动执行范围。

这四步是一级一级的台阶：

这条路径对应后面的自主性等级 L0–L5。

常见误区

• “Agent 是更先进的方案，所以优先选 Agent。” 方案选择看任务特征，不看技术新旧。固定流程用 Workflow，是专业判断，不是落后。
• “先做出来再看效果。” 没有想清楚验证方式和评测标准就开工，最后只能靠“感觉不错”来决定上线，风险极高。
• “Agent 能替代整个岗位。” 更现实的切入点是替代岗位中某一类高频、耗时、可验证的任务。

产品经理检查清单

• 这个任务是否跨系统？列出涉及的系统。
• 需要几步？中间是否有依赖前一步结果的判断？
• 能不能画出覆盖 95% 情况的流程图？如果能，为什么不用 Workflow？
• 最终交付的是答案还是被执行的动作？
• 任务频率、单次人工耗时、错误代价分别是多少？
• 有没有程序化的方法验证结果？
• 需要的 API 和权限是否可得？
• 第一版能否从“只读 + 人工执行”开始？

练习

用 45–60 分钟，从你的工作中找 5 个“想用 AI 自动化”的任务，填写下表：

任务	跨系统	多步骤	需要判断	要执行	频率 / 耗时	结论与推荐方案
例：每周 SEO 流量异常诊断	✓	✓	✓	部分（创建修复任务）	每周 1 次 / 3 小时	Agent，第一版只读诊断
例：每日销售数据推送	✗	✗	✗	✓	每天 / 15 分钟	定时任务

最后挑出一个最值得做的，写一段 100 字左右的理由。

延伸阅读

• Anthropic：Building effective agents，文中讨论了何时使用、何时不使用 Agent，以及复杂度、成本与收益之间的取舍。

下一步

判断清楚“该不该做”之后，下一课「Agent 产品版图」带你看看市场上已经有哪些类型的 Agent，以及它们各自解决什么问题。