判断一项任务要不要用 AI Agent，可以先看四件事：步骤是否固定、输入是否稳定、执行中是否需要结合上下文做选择、出错后会不会产生真实损失。规则清楚的任务交给工作流，变化多且需要连续判断的任务再考虑 Agent。
很多团队一开始就问“这个场景能不能做 Agent”，结果把简单自动化做得又贵又难维护。换个问法更有效：任务里到底有多少环节无法提前写成规则？
先找固定部分
下面几类工作通常适合普通工作流：每天从同一张表读取数据；按固定公式计算指标；达到阈值后通知指定人员；把审核通过的文件移动到固定目录；根据表单字段创建工单。输入、步骤和结果都比较稳定，异常也能提前列出来。
工作流的优势很直接。执行路径可见，成本容易估算，出了问题能快速定位到具体节点。业务规则改变时，修改条件或节点就能继续使用。
有些流程会调用大模型，例如摘要、分类、字段提取。只要模型承担的是一个明确节点，前后路径仍然固定，这项任务依旧可以按普通工作流设计。调用了大模型，并不会自动变成 Agent。
再看任务里有没有连续选择
Agent 更适合执行中需要多次观察和调整的工作。用户只给出一个目标，系统要自己判断下一步查什么资料、调用哪个工具、是否补充信息、何时停止，这类任务很难在开始前画出完整路径。
例如，整理一份陌生行业的研究提纲。资料来源可能互相矛盾，缺少关键数字时还要继续搜索，发现题目过大后需要收缩范围。每一步都会改变下一步动作，Agent 才有发挥空间。
另一个例子是复杂故障初查。系统需要先读取报错，再结合服务状态选择日志，发现线索后继续查询相关依赖。路径跟着现场信息变化，固定流程只能覆盖其中较稳定的检查项。
用四个问题做一次筛选
第一，规则能否完整写下来？如果新同事照着一页说明就能完成，工作流通常已经够用。说明里频繁出现“视情况判断”“结合上下文选择”，再继续评估 Agent。
第二，输入变化有多大？固定表单、固定字段、固定文件格式适合流程。自然语言需求、跨来源资料、格式经常变化，会增加 Agent 的价值，同时也会增加测试难度。
第三，允许多大的误差？内部资料初步整理可以保留人工复核；付款、删库、对外发送和权限变更，任何自由决策都应受到严格限制。高风险动作可以让 Agent 提建议，再由规则或人工执行。
第四，任务是否值得承担额外成本？Agent 会带来模型调用、状态保存、工具权限、评估和监控工作。每次只节省几十秒、执行量又很小，简单脚本或工作流往往更划算。
任务特征
优先选择
路径固定、规则明确、输入稳定
普通工作流
流程固定，仅某一步需要理解文本
工作流加模型节点
目标明确，路径需要根据现场变化
AI Agent
涉及高风险写操作
规则控制、人工确认
既有固定环节又有开放判断
工作流承接主干，Agent 处理局部
混合方式更常见
真实业务里，纯工作流和完全开放的 Agent 都不算多。更常见的做法是把稳定部分固定下来，把变化最大的一个环节留给 Agent。
以客户反馈处理为例，接收消息、去重、保存、分配负责人可以走固定流程；理解问题、补充上下文、起草回复可以交给 Agent；正式发送继续经过人工确认。这样既保留灵活性，也能控制外部影响。
设计时还可以给 Agent 设一个活动范围：允许读取哪些资料，最多调用几次工具，哪些动作只能生成草稿，遇到哪些条件必须停下。边界写得越具体，后续评估越容易。
先用一周真实样本验证
拿最近一周的任务记录，选二十到五十条真实输入。先尝试写出固定规则，再标出规则覆盖不了的地方。若大部分任务都能落进稳定路径，工作流足够；若分支随着上下文不断增加，Agent 才值得进入方案。
验证时记录四项数据：完成率、人工修改量、单次成本和错误后果。只看演示效果，很容易被一两次漂亮回答带偏。真实样本会告诉你，灵活判断究竟创造了价值，还是给简单任务增加了不确定性。
选择工作流或 Agent，不用跟着产品名称走。把任务拆开，看清固定规则、开放判断和风险动作分别在哪里，技术方案通常会自己浮现出来。
