误区一：工作流当 Agent
把固定步骤的自动化包装成 Agent，演示好看，遇到分支就卡住。怎么识别：问对方遇到未定义情况时怎么处理，若回答只能人工介入或整段重跑，说明本质仍是工作流，按 Agent 采购会高估能力，验收时也难界定。
误区二三：无审批与只看演示
没有审批节点就上生产，等于把不可逆操作交给模型；只看成功演示，则看不到失败轨迹。怎么改：要求演示一次失败案例并说明接管方式，同时在合同里约定审批节点与回滚流程，两项缺一不可，否则风险全在客户侧。
误区四：权限过大
为了省事把工具权限开到最大，Agent 能改单、退款、发消息，风险无法收窄。怎么控制：按角色最小授权、敏感操作强制二次确认，并保留操作日志；权限设计要在试点前完成，事后收窄往往牵动流程重写，成本更高。
误区五：忽略轨迹漂移
平台升级后模型或工具接口变化，原本跑通的轨迹可能失效。怎么防：锁定版本、保留历史轨迹、升级前用固定任务集回归；把轨迹回放当成上线门槛，而不是出问题后的排查手段，才能把中断挡在业务之外。
适用与不适用
适合谁
- 正在评估 Agent 平台、收到多家演示的企业
- 已有一个流程准备自动化、需要控制风险的团队
- 对审批节点与操作留痕有明确要求的组织
不适合谁
- 只需要固定步骤自动化、不涉及判断的场景
- 希望全自动无人值守、不设审批的项目
典型场景
某电商企业原以为买的是 Agent，上线后发现只能按固定步骤执行，遇到地址异常就停住。复盘后团队重新梳理流程，把判断与生成交给模型、把改单与退款设为审批节点，并要求平台提供轨迹回放与权限收窄能力，先跑一个仓做试点。
可执行步骤
- 先问清平台在遇到未定义情况时怎么处理、由谁接管，再听演示，再安排现场演示
- 要求对方演示一次失败轨迹，并说明定位步骤与恢复的具体方式，以及预计需要多久
- 按角色设计最小权限，敏感操作一律加二次确认，并保留操作记录，便于事后审计
- 用固定的任务集做升级回归，同时保留历史轨迹与版本号备查，形成一份回归记录
常见坑
- 把固定流程当 Agent 采购，遇到分支就停住，业务方认为系统不好用，项目被搁置。
- 没有审批节点就让 Agent 改单，一次误操作造成实际损失，追责时才发现无人签字。
- 工具权限开到最大，Agent 能直接调用退款接口，风险无法收敛，审计时也说不清。
- 升级后没有回归任务集，轨迹悄悄失效，一周后才发现成功率下降，用户已经流失。追查也没有依据。
自检与验收清单
- 是否确认平台对未定义情况的处理方式与接管人
- 失败轨迹是否可定位、可恢复、可复盘，并留有记录
- 敏感操作是否有审批与二次确认机制，并留痕
- 工具权限是否按角色做到了最小化，并留有台账
- 升级前是否有固定的回归任务集与比对脚本准备
常见问题
怎么判断是不是真 Agent？
看它能不能根据中间结果改变下一步，并在不确定时停下来求助。只按固定顺序执行、分支全靠预设的，属于工作流；两者都能创造价值，但采购预期与验收标准不同，先分清再谈价格。
审批节点会不会拖慢效率？
会，但只在敏感操作上。把审批放在改单、退款、对外发送这类不可逆动作前，其余步骤自动执行；这样既保留效率，也避免一次误操作造成难以挽回的损失，审批阈值也可以按操作类型分开设置。
轨迹回放有什么用？
用来定位与回归。出问题时能看清每一步的输入、工具返回与判断依据；升级前用同一批任务回放，能提前发现行为变化。没有轨迹，排查只能靠重跑与猜测，成本高且难以复现。