什么场景值得用 Agent：从普通 AI 调用到真正的 Agent 应用
Agent 很热，但不是每个 AI 功能都该做成 Agent。我做企业系统和内容相关产品时，更常问自己：
这个问题，到底需不需要「动态决定下一步」？
这篇不写行业场景大全，只整理一个我会反复用的判断框架，并落到 MES、企业业务系统和 AI 漫剧这几类我熟悉或正在做的方向。技术定义仍看 技术 → Agent。这里只谈选型。
先给结论：Agent 是一种更贵、更强、也更不确定的执行方式。用它，是因为任务结构需要它，不是因为技术栈清单上缺它。
1. 先判断：是不是 AI 问题
有些事根本不需要模型：
计算 · CRUD · 固定流程 · 明确规则 · 强一致事务库存加减、状态机流转、权限校验、金额计算——这些交给普通程序更稳、更便宜、更好测。
如果硬塞 Agent，等于把确定性工作重新变成不确定性工作。那不是升级，是降级。企业系统里，大量「能不能上 AI」的讨论，其实第一步就该被挡在门外：这根本不是 AI 问题。把不该 AI 化的环节 AI 化，后面所有「不听话」都是自找的。
2. 普通 AI 什么时候够了
一次模型调用就能闭环的，通常够了：
文本生成 · 总结 · 分类 · 改写 · 信息抽取 · 简单问答例如：根据工单描述生成摘要；把制度段落改成白话；从一段文本里抽出字段；给一段日志做一个可读解释（依据仍是你提供的原文）。
这时上 Agent，多半是为了「看起来高级」。多出来的编排、Tool、多轮循环，带来的是成本和故障面，不是业务价值。
原则：
一次调用能解决，就不要为了高级而上 Agent。
我会把「普通 AI」当成默认选项。只有当一次调用明显不够——需要查系统、需要分支、需要多轮验证——才进入下一层讨论。简历上写「我们做了 Agent」，不如写清楚「为什么普通 AI 不够」。
3. Workflow 什么时候更合适
流程固定时：
A → B → C → DWorkflow（或普通编排）往往比 Agent 更可靠。
例如：工单进入 → 模型分类 → 按规则分派 → 通知责任人。中间「分类」用 AI，前后步骤用程序。路径是定的，不需要模型现场决定「下一步调哪个接口」。
再比如内容生产里固定的：大纲确认 → 分集 → 分镜 → 生成 → 人工审核。步骤顺序不变，变的是每步内容。这时用 Workflow 挂局部 AI，通常比让 Agent 自由编排整条流水线更稳。
固定多步骤 + 局部 AI，优先 Workflow。Agent 的动态决策优势用不上，稳定性却更差。能用状态机和任务队列解决的，我不会先上 Agent。
4. Agent 真正适合什么
我会用四个条件打分：
1. 任务不是完全固定流程
2. 下一步需要根据中间结果动态决定
3. 需要调用多个工具 / 多个数据源
4. 允许一定程度的不确定性（可解释、可复核）满足得越多，越值得考虑 Agent。
典型画像：用户给一个目标，而不是给一条固定流水线；系统要查几处数据、根据结果决定还查不查、最后组织结论或建议。
四个条件都弱，就回到普通 AI 或 Workflow。四个条件都强、且风险高，就上 Agent，但必须加 Workflow 边界和人工确认——不是「更自由的 Agent」，而是「被关进笼子的 Agent」。
这四个条件我面试或评审方案时也会用：对方说要做 Agent，我先问这四条满足几条。答不清楚，多半还没到该上 Agent 的时候。
5. MES 场景
如果让我设计一个 MES 相关的 Agent，我会先从低风险分析开始，而不是自动控制。
用户可能说：
「帮我分析一下今天 3 号设备为什么异常停机。」
一条合理的执行路径是：
查询设备状态
↓
查询报警记录
↓
查询维修记录
↓
查询相关生产订单
↓
分析异常
↓
形成结论与建议路径不一定每次一样：有时报警已足够，有时还要看质检或班次。这种「根据结果决定下一步查什么」，才是 Agent 的用武之地。
但边界必须清楚：
查询 / 分析 → Agent 可以做
修改设备参数 /
执行生产操作 → 必须严格权限 + 人工确认我不会声称已经上过一套「AI MES」。这是设计判断：工业现场出错成本高，Agent 先做人的辅助分析，再谈更深的自动化。点检辅助、报警解释、工单知识问答，都比「自动调参」更适合作为第一刀。和 MES 里的 AI 切口 是同一条思路，只是这里从「要不要 Agent」的角度再收一遍。
6. 企业业务系统场景
结合 Java / ERP / CRM / OA / MES 一类系统经验，Agent 比较适合：
- 跨模块查询与汇总（人要点很多次菜单才能拼齐的信息）
- 异常单据解释（状态为什么停在这、缺什么材料）
- 辅助决策草稿（给人看的建议，不直接过审）
- 把自然语言当成复杂查询的入口
不适合直接接管的：
- 审批最终决策
- 库存与金额变更
- 任何不可逆的对外动作（无确认）
核心数据操作仍由确定性业务代码控制：写库、审批、库存、财务，不交给模型自由发挥。
一句话：
Agent 负责「找齐信息 + 组织判断」；业务系统负责「改世界」。
两者边界清楚，才接得进现有权限与审计体系。这也是为什么有企业系统背景的人做 Agent，往往比「只会调 API 的 Demo」更容易谈落地——不是更会写 Prompt，是更知道哪些动作绝对不能松绑。十年业务系统经验在这里的用处，不是背框架名，而是知道坑在哪。
7. AI 漫剧场景
我在做 AI 漫剧相关平台时，更能体会 Agent 和「一次生成」的差别。
一次 Prompt「写一篇剧本」往往不够：人物设定、大纲、当前集剧本之间容易冲突，生成完还要改、再查、再生成。创作者真正痛苦的，常常不是「不会写」，而是「写出来前后对不上」。
更适合 Agent（或强编排）的链路是：
检查人物设定
↓
检查剧情大纲
↓
检查当前剧本
↓
发现冲突
↓
给出修改建议
↓
按建议再生成
↓
再次检查这里有状态、多步骤、工具（或模块）调用、上下文、检查、修改、再验证——正好踩中前面四个条件。
这比单纯「让 AI 写剧本」更能体现 Agent 价值，也更容易做结果验证：冲突列表是否清空、关键字段是否一致。我按这个方向做产品时，会优先把「检查—修改—再验证」做成闭环，而不是堆更多一次性生成。生成很炫，闭环才像应用。这条我当成正在做的实践方向来写，和上面 MES 的「如果让我设计」是不同可信度的表述。
8. 哪些场景我不会使用 Agent
必须写清楚不会用的地方，否则选型框架是假的：
- 简单 CRUD：表单提交、列表查询
- 固定审批流：节点和规则已定，用工作流引擎
- 精确计算：金额、库存、排产公式
- 强一致性事务：下单、扣款、库存锁定
- 高风险自动执行：改生产参数、对外正式发文且无人确认
- 单次文本生成：摘要、改写、翻译
- 只是想「系统里有个对话框」：那是入口问题，不是 Agent 问题
核心原则：
Agent 不是技术升级，而是一种成本更高、能力更强、但不确定性也更高的执行方式。
用它，是因为任务结构需要它，不是因为简历或 Demo 需要它。能明确说「这里我不用 Agent」，本身就是选型能力。
9. 我的 Agent 选型判断
| 场景 | 推荐 |
|---|---|
| 固定规则 | 普通程序 |
| AI 生成 / 总结 / 抽取 | 普通 AI |
| 固定多步骤（局部可用 AI） | Workflow |
| 动态多步骤任务 | Agent |
| 高风险动态任务 | Agent + Workflow + 人工确认 |
表可以再细，但日常够用。讨论方案时，我会先把需求丢进这一行，再谈模型和框架。如果一句话需求同时跨两行，就拆任务：能固定的固定，必须动态的才交给 Agent。
这张表也是我跟业务方对齐预期的工具：不是「我们要不要上 Agent」，而是「你的问题落在哪一行」。落错行，后面预算和风险预期都会偏。
10. 最终结论
我不会先问：
「这个系统能不能加 Agent？」
而会先问：
「这个问题是不是需要动态决策？一次 AI 够不够？流程固定吗？出错能否承受？」
答完这些，选型几乎就出来了。
Agent 适合嵌在真实业务里的那一小段：信息分散、路径不固定、需要工具、且结果可以被验证或被人接住。其余大部分，老老实实用程序、Workflow 和普通 AI，往往更像工程，也更像能上线的东西。
选型做对了，后面的开发才有意义；选型做错了，架构图画得再好看，也只是把不确定性放大到了系统里。对我来说，Agent 应用的第一课不是怎么写 Prompt，而是什么时候坚决不用它。