失败一：当问答机器人做
只让它回答问题、不接任何工具，业务方很快发现和现有搜索没有差别。智能体的价值在动作闭环，若第一步就不敢碰系统写操作，应重新评估是否值得做定制，而不是继续加提示词，把预算消耗在一个没有出口的方向上。
失败二：工具泛滥
一次接入十几个工具，表面能力很强，实际编排路径复杂、失败率上升、排错成本极高。工具数量应受任务边界约束，通常两到四个核心工具即可覆盖主要场景，其余按需再开，每开一个都要补相应的评测用例与权限说明。
失败三：权限缺位
没有权限矩阵就上线，智能体可能直接触发退款、下单、改状态等写操作。一次误操作就需要人工回滚数据，且难以证明操作是系统还是人为发起，责任界定会非常困难，内部追责时往往只能各自承担，最后没人愿意再用。
失败四：只演示不评测
演示样本经过挑选，看起来一切正常，真实用户的第一句诱导性提问就可能突破边界。缺少越权与注入用例的评测，等于把边界验证交给运气，事故往往发生在上线首周，而团队连复现路径都拿不出来。
失败五：没有接力与熔断
异常时智能体继续硬撑，用户拿到错误结果，运营侧事后才知道。设定接管比例与熔断阈值，让系统在不确定时主动退回人工，比追求全自动更能保护用户体验与信任，也更容易通过风控评审，后续放量更顺。
适用与不适用
适合谁
- 正在评估智能体项目可行性的团队
- 已上线但使用率或准确率不及预期的项目
- 需要向风控说明边界的业务负责人
不适合谁
- 仅做知识问答、不涉及系统动作的场景
- 尚无可用接口、也不打算改造系统的环境
典型场景
某零售企业的智能体上线首月接到数起投诉：用户询问退货政策时被直接触发退款流程。追查发现该动作被归为建议档，但配置里实际是自动执行。团队随后补做权限矩阵与审批环节，并把退款类动作全部降级为需人工确认，投诉才停止，配置也改为每次改动都留痕、可追溯。
可执行步骤
- 核对智能体是否真正完成了动作闭环，而不只是回答问题，确认动作是否真的闭环
- 按任务边界裁剪工具数量，只保留核心的两到四个，避免编排失控，每增一个都要补评测
- 为每个写操作补权限档位、审批人与回滚方式，逐条核对，并写入权限矩阵
- 补做越权、注入、诱导承诺与拒答四类用例，逐条跑通，作为放量前提，并留下测试记录
常见坑
- 为了让演示好看而放宽权限，上线后再收紧会遭到业务方反对，整改久拖不决，风险一直悬在那里。
- 工具数量只增不减，编排图越来越复杂，新人无法接手维护，最终没人敢改配置，只能长期维持现状。
- 把边界验证交给交付方自测，缺少独立红队视角，问题在上线后才暴露，处理成本高出数倍；同类问题还会再来。
- 熔断阈值拍脑袋设定，过严导致频繁中断被业务弃用，过松则等于没有，异常时照常输出错误结果；事故概率随之上升。
自检与验收清单
- 智能体是否完成了真实的动作闭环，而不只是能回答问题
- 工具数量是否受任务边界约束，是否随迭代失控
- 写操作是否都有权限档位与审批人，是否有审批记录
- 接管比例与熔断阈值是否演练过，是否覆盖异常路径
常见问题
智能体一定要能执行动作吗？
不一定。若场景只需检索与汇总，问答形态足够，也更安全；但这类需求通常用检索增强即可满足，不必定制智能体。是否需要动作闭环，是判断要不要做定制的第一道分界，也是预算分配与权限设计的前提。
权限分级会不会影响体验？
会有一定影响，尤其是需要审批的执行动作。折中做法是把高频低风险动作设为自动执行并留痕，把低频高风险动作设为审批，按动作而不是按用户来区分，既控制风险也避免所有人被同一条规则拖慢。
出过一次事故要不要停用？
先判断是否属于设计缺陷。若同类动作普遍缺少审批与回滚，应暂停相关动作而不是整体停用；修补后用小范围灰度验证，再逐步恢复，既避免因一次事故放弃整个场景，也避免不加区分地继续运行。