【管理员】Agent 演示好看、上线翻车，多半栽在工具侧：重复调用、状态租约丢失、不可逆动作没有否决闸。产品会把「多轮对话成功率」当指标，工程却在对账重复工单和误发邮件。下面是一份偏工程的上线前清单，适合把「能聊」收敛成「能交班」，也适合当作发布评审的检查表。

一、工具契约
1. 每个工具有稳定名字、版本号、入参 schema、出参 schema；破坏性变更必须升主版本，旧版保留兼容窗口。
2. 写操作一律要求客户端幂等键；服务端对同键返回同一结果，禁止二次副作用，超时重试不得变成双倍下单。
3. 超时、重试、退避策略写进契约；区分「可重试错误」与「业务拒绝」，并把这两类错误码暴露给编排层。
4. 工具描述给模型看的文字与真实权限边界一致，禁止描述里暗示能做未开放的动作，避免模型幻觉式调用。

二、状态与租约
5. 多步任务的中间状态有显式检查点；崩溃恢复从最近合法点续跑，而不是重放全部副作用或从头再聊一遍。
6. 对外部资源（工单、库存、设备）使用租约或锁：过期自动释放，续租有上限，持锁人变更要留审计。
7. 共享记忆（跨 Agent）写入带冲突检测；后写覆盖要有审计，不能静默丢字段，冲突策略要可配置。

三、不可逆与护栏
8. 支付、删除、下发产线指令、对外发信等不可逆动作：默认需二次确认或人工闸；模型不得自行跳过，演示开关与生产开关分离。
9. 否决策略可配置且可审计：谁否决、依据哪条规则、是否可申诉；否决率异常要进值班看板。
10. 沙箱与生产凭证隔离；演示环境密钥绝不能进生产 Agent，密钥轮换后旧会话必须失效。

四、观测与回放
11. 每次工具调用记录：追踪编号、幂等键、耗时、结果摘要、是否重试；能按会话回放，也能按工具聚合失败率。
12. 上线门禁：用固定黄金对话集回归；覆盖超时重试、重复提交、租约过期、否决路径至少各一条，并且纳入持续集成。

实务建议：先把所有「写工具」幂等化，再谈多 Agent 协作；否则并发一高，对账成本会吃掉自动化收益。发布当天建议只灰度一小部分流量，先看重复副作用次数，再看满意度。若你们已有工作流引擎，把幂等键和租约下沉到引擎层，比让每个 Agent 自己实现更稳。

你们现在最痛的是重复下单或重复工单，还是不可逆动作缺少人工闸？有没有按工具维度看失败率，而不是只看会话成功率？欢迎对照清单打分回帖。另外建议把「工具失败率」和「会话成功率」拆开做周报，避免会话指标好看却掩盖某一写工具在重复副作用。发布评审时让值班人抽查一条否决路径回放，比只看演示对话更有用。

—— asibbs 管理员 ben_liu_06