AI Agent 五要素测试：判断什么业务该做成 Agent

我应该把什么业务/工作流做成 AI Agent？

@gregisenberg 分享的「AI Agent 五要素测试」判断框架，咱们一起看看。

五个要素测试

1. 重复的触发器 同类任务会反复出现。这是经济可行性的前提：一次性任务不值得为它构建 Agent，只有高频重复的场景才能摊薄构建和维护成本。

2. 稳定的输入 信息以可预测的结构进来。比如表单、固定格式的邮件、标准化的工单。输入越结构化，Agent 解析和处理的可靠性越高；输入越杂乱，错误率越高。

3. 明确的工具集 Agent 能调用的动作是有限且定义清晰的——查数据库、发邮件、调 API、创建文档。工具边界清晰，意味着行为可控、结果可验证，不会"什么都想做、什么都做不好"。

4. 可衡量的终点 能判断"做完了没有、做得好不好"。没有验收标准的任务，Agent 无法闭环，也无法迭代优化。这一条实际上是在要求任务具备可验证性。

5. 中间需要判断力 每次运行都有差异，需要在当下做真实的决策。这是全文的核心。

关键洞察：第 5 条是分水岭

Isenberg 框架的结构： 前 4 条问的是"这件事能不能被自动化"；第 5 条问的是"它应该是一个 Agent，还是一个普通自动化"。

这是一个非常重要的区分： · Automation：规则驱动，if-then 逻辑，每次执行完全相同的路径。适合前 4 条满足、但没有判断需求的场景。 · Agent：在流程中段存在决策点——需要理解上下文、权衡选项、处理例外情况。这正是大语言模型相对传统脚本的本质增量。

以"处理客户退款申请"为例

重复触发？每天都有退款请求 输入稳定？统一的退款表单 工具明确？查订单、核对政策、执行退款、发通知 终点可衡量？退款是否合规、客户是否满意 中间有判断？边缘案例：超期但理由合理？高价值客户是否破例？

前 4 条让它"可以自动化"，第 5 条让它"必须是 Agent"——因为纯粹的规则引擎处理不了灰色地带，而这正是 LLM 的价值所在。