统一 AI 入口，怎样控制参数、状态、重试、撤销和限流？

一句话查库存、建工单、发通知，体验确实很爽。

真正危险的时刻通常藏在后台：模型把收件人理解错了，系统提交后没有及时返回，AI 以为失败又重试一次。等人发现时，同一动作已经执行了两遍。

统一 AI 入口要把“AI 提出动作”和“系统真正执行”拆开。所有关键操作都要经过参数、权限、状态、重复、风险和预算六道闸。

入口越简单，后台越不能靠模型临场发挥。

一句话之后，要过六道闸

假设员工输入：“把这批客户的退款申请建好。”系统至少要完成六次判断。

第一道是参数：具体哪些客户、哪些订单、金额多少、原因是什么。缺少关键字段时，AI 只能继续询问，不能自己补猜。

第二道是权限：当前员工有没有读取订单、创建退款草稿和正式提交的权限。身份必须来自企业系统，用户在对话里说自己是主管不能改变权限。

第三道是状态：订单是否已经退款、正在处理，还是仍可申请。业务系统里的真实状态拥有最终解释权。

第四道是重复检查，也就是技术团队常说的“幂等”。同一个请求即使重复发送，系统也只能产生一次有效动作。

第五道是风险：金额、客户范围或动作类型达到阈值时，进入人工确认。批准人应该看到对象、金额、依据和不可逆后果。

第六道是预算与速度：一次最多处理多少对象、调用多少工具、花费多少资源。人工队列已经积压时，系统要限速或暂停。

超时以后，先查状态，再决定重试

网络超时只说明“没有及时收到结果”，无法证明动作没有发生。

正确顺序是：用唯一任务编号查询业务系统；已经成功就返回结果；明确失败才重试；状态仍然未知，就暂停并交给人。直接让 AI“再试一次”，可能造成重复扣款、重复发货或重复通知。

重试也要有上限。连续失败却没有新信息时，第四次尝试通常只是把成本和风险继续放大。

技术回滚和业务撤销要分开

数据库里的草稿可以删除，已经发出的邮件很难真正收回，已完成的付款更需要新的补偿流程。

因此，每个工具上线前都要写清：动作能否撤销；无法撤销时怎样补救；谁通知受影响的人；谁承担后续处理。

“系统可以回滚”如果只指代码版本，对业务几乎没有帮助。

用状态机代替一段长对话

任务至少要区分：待补参数、待确认、待执行、执行中、成功、明确失败、结果未知、已撤销。

AI 负责理解需求、整理证据和提出下一步。状态变化由可信系统记录。这样即使对话中断、模型更换或人工接手，团队仍然知道任务停在哪里、哪些动作已经发生。

上线前故意把它弄坏一次

少做一遍正常演示，多测试几种坏情况：参数缺失、权限不足、接口超时、重复提交、人工拒绝、预算超限。每一种情况都要看到系统停在正确状态，并且有人能够接手。

统一 AI 入口真正统一的，应该是任务状态和责任边界。一个聊天框只是最外面那层壳。

本问行动：留给负责系统的人一个现场测试：让接口连续超时三次，看看系统究竟会重复执行、安静卡死，还是把完整状态交给人。