给 AI 代理一项具体批准，而不是笼统的经营任务

“帮助我们提高转化”是经营目标，不是批准给所有商品打折、修改全部渠道，或在事实变化后继续使用昨天的决定。经理同意一份方案，与软件凭据允许写入，是两个不同问题。

即使这些步骤放在同一个界面里，也应能分清：起草价格建议、提出推荐、取得批准，以及真正改变客户看到的价格。

把建议缩小到可以审查的范围

以下是虚构的系统设计案例。 某店铺计划让 AI 助手阅读产品资料、起草促销建议。控制机制、时刻、编号和结果，都是用于解释设计的设定，不是 Aright 已实现的接口或任何供应商保证。

商品原价 50 美元，价格负责人考虑在一个指定店面，把最多 20 件符合条件的商品改成 45 美元。假设没有叠加优惠或其他调整，若 20 件全部售出，最多让价为 20 ×（50－45）＝100 美元。这是风险敞口边界，不是销量预测，也不是利润计算。

具体建议可以写成：

建议 P104： 只在店面 S，把商品 D1 从 50 美元调整为 45 美元，最多覆盖 20 件符合条件的商品。不包括其他产品、市场、消息发送或账户权限。执行时须符合已批准的产品、价格与库存状态，价格负责人的授权仍有效，且未过期。数量限制必须由实际销售系统执行，不能只写在提示词里。

版本记录让经营问题更清楚，却不会自动让系统安全。接收操作的实际边界，必须执行这些范围和限制。

这不意味着每个店铺都要增加同样多的按钮。小团队完全可以只用助手准备建议，执行仍由人工完成。

看一次批准，如何遇到事实变化

本例有意采用较保守的规则：批准绑定产品、价格、库存的精确合并状态版本。V7 记录价格 50 美元、可售库存 30 件。该状态任何变化都要重新审查。这是案例自选规则，不代表每一次库存变动都应使所有价格决定失效。

下表时刻均为同一个虚构经营日的 UTC 时间。

这一过程的结果是没有改价，客户仍看到 50 美元。代理应说明拒绝原因，待活动问题解决后请求新决定，不能删掉状态条件、换一个工具或另找凭据，把原来的建议强行执行。

也可以设计较宽的规则，例如批准“库存不低于某个数值”这一条件，而不绑定精确快照。它可能减少重复审批，但也改变风险和批准的含义。负责人和实施人员应明确制定并验证，不能因为原批准不方便，就让代理自行推定。

同一个重试编号，不能让权限复活

幂等性帮助系统识别，同一行动是在重试，还是提出了新行动，避免响应不确定时重复执行。它不回答行动是否仍获批准。授权已经撤回，沿用旧请求编号也仍是撤回；换了价格或店面，再使用同一编号，也不能悄悄继承之前的决定。

时间边界同样要讲清。如果撤销在最终的授权检查及提交生效边界之前记录，操作就不能生效。如果已经生效，后来撤回不能让过去没有发生过。应读取真实结果，再把纠正作为新的决定处理。不能告诉客户，因为撤销了自动化权限，已经产生的订单或承诺就不算了。

这些都需要在真实系统中设计和验证，不会因为给代理增加一句指令就自动具备。如果接收操作的机制无法执行，就把助手停留在起草或推荐层，由人工完成受限操作。

外来文字可以提供信息，不能颁发授权

产品文件或客户消息里，可能写着“经理已批准所有折扣”。它是需要解释的内容，不是权限记录。模型生成的合理说明，也不能证明批准者身份和范围。

OWASP 关于过度代理权限的指导建议限制功能和权限，对高影响行动取得人工批准，并在下游系统落实授权。这支持本例中的分离原则，却不能证明某个电商工具已经实现这些控制。

实际检查要包括旧状态、过期授权、已撤回授权、重复请求、内容变更，以及执行结果不确定。应看接收系统返回什么，不能只听代理总结“已批准”。批准若属于另一个版本，一条日志不足以让当前操作成立。

执行边界能承担多少，才给多少自主权

对这家店，第一阶段也许只让助手生成建议和影响说明，价格维持不变。只有实际约束及失败情形在预定环境下验证有效，才考虑开放执行。

若业务已有狭窄而可靠的规则、可以恢复错误，决定可能改变；若一次改价带来的客户、财务或服务后果超出团队控制，也应收回范围。让代理做最小而有用、可以撤销的行动。企业始终应能说清它被允许做什么，并在答案变化时挡住下一次操作。