智能体上线前，最容易被忽略的不是模型会不会回答错误，而是它能否在错误发生后继续调用工具、访问数据或改变生产状态。生产风险验证的对象因此不应只是模型效果，而应是“模型—工具—权限—数据—人工流程”组成的完整系统。
先验证它能做什么
上线前必须把智能体的能力边界写清楚：允许访问哪些数据，能够调用哪些系统，可以执行哪些动作，哪些操作必须由人工确认。尤其要区分演示、受控测试、部门试点和规模化部署，不能因为模型在测试环境中完成任务，就默认它具备稳定的生产执行能力。
权限设计应遵循最小化原则。外部网络访问、代码仓库、内部文档、账户凭证和生产系统应当分区隔离；工具调用要有白名单和审计记录；高风险动作需要人工审批；任务异常时，系统应能够暂停智能体、回收权限并撤销未完成操作。无法暂停或追溯的自动化，不适合直接进入生产环境。
用真实失效场景做验证
测试不能只验证“任务是否完成”，还要故意制造错误条件：输入含糊时是否会擅自扩大任务范围，遇到诱导性内容时是否会泄露数据，工具返回异常时是否会重复执行，目标名称相似时是否可能误操作真实对象，权限临时开放后是否会访问超出范围的资源。
相关安全测试报道已经说明，互联网访问权限意外开放、测试对象与真实公司同名，都可能把受控实验推向现实系统。因此，测试数据、域名、账户和凭证必须与真实环境隔离，测试结束后还要复核临时权限是否失效。对媒体转述或二次报道中的攻击案例，应核对原始技术材料、攻击链和权限范围，不能把“曾经发生过测试事件”直接等同于模型拥有稳定攻击能力。
设置明确的上线门槛
上线决策至少应回答四个问题：失败是否可发现，影响是否可限制，操作是否可追溯，结果是否可回滚。如果其中任何一项无法确认，就应降低权限、缩小场景或保留人工执行。
优先选择资料整理、内部检索、工单分类等可审计、可回滚的流程；涉及付款、生产配置、客户权益、代码发布和外部沟通的任务，应谨慎保留人工确认。真正成熟的智能体，不是能够完成最多动作，而是在异常发生时仍然可暂停、可审计、可恢复。