高风险变更应保留人工确认

当 AI Agent 能够读取系统、修改配置，甚至向外部发送信息时，“自动化成功”不等于“风险可控”。尤其是删除、批量更新、权限变更和外部发送这类高风险动作，最好保留人工确认。人工确认并不是对自动化的不信任，而是在不可逆或影响范围较大的环节，增加一道能够解释、追责和及时阻断的控制。

真正需要讨论的，不是“所有操作都要不要人工审批”，而是哪些动作值得暂停一下。查询工单状态、读取与当前任务相关的监控数据，通常可以交给 Agent 自动完成；但当它准备改变生产配置、处理敏感数据，或一次操作可能影响多个业务对象时，就不能只看 Agent 是否拥有调用权限，还要确认发起请求的用户是否有权要求它执行，以及这次操作是否符合明确的业务目的。

一个稳妥的流程可以分成两段：Agent 负责收集信息、分析原因、生成修复建议和待执行参数；真正的高风险变更则关联任务或工单，由指定人员确认后，才临时授予针对目标资源的执行权限。执行结束后及时回收授权，避免一次审批变成长期有效的通行证。

人工确认也不能只是弹出一个“是否继续”的按钮。确认者至少应看见目标系统、具体操作、影响范围、授权依据和是否可回退。若界面只展示“Agent 建议执行修复”，人很容易在不了解后果的情况下顺手点击通过。确认机制的价值，取决于它是否让风险变得可理解，而不是是否增加了一个流程节点。

日志同样重要。系统应记录谁发起任务、哪个 Agent 实例参与、调用了什么工具、访问了什么资源、依据哪条授权规则、由谁确认，以及最终执行结果。多 Agent 协作时，还要保留从用户到 Agent、再到工具的委任关系，否则出了问题只能看到一个技术账号，无法还原责任链。

当然，人工确认也有代价：它可能拖慢处理速度，甚至让审批疲劳变成新的风险。因此，边界应按影响范围、敏感程度、可逆性和操作类型划分，而不是一刀切。低风险读取可以充分自动化，高风险变更则保留清晰的人工确认和回退路径。你更愿意把“最后一次点击”交给谁，或许正是衡量一个 Agent 系统是否成熟的简单问题。