说起来，

AI Agent 上生产要不要开写权限？我把执行链拆成 道闸门

AI Agent 从“能回答”走到“能执行”。最大的架构变化不是多接一个模型，而是程序开始允许模型触发真实副作用。

读数据、生成建议通常可控；改订单、建工单、发消息和删除记录则完全不同。我的实践原则是：不要把生产写权限设计成一个布尔开关，而要把它拆成可验证的执行链。

. 四级权限比“能写/不能写”更实用

我通常从四层开始：

1. 只读观察读取授权范围内的数据，不修改状态；
2. 生成建议模型只产生结构化提案；
3. 短时审批对这一次目标和参数签发单次、短时凭证；按理说，
4. 执行回读完成写入后重新查询业务对象。

这背后是零信任思路：每次请求都显式验证。只授予完成当前任务所需的最小权限，并假设错误已经可能发生，所以必须限制影响范围。

. 模型输出不是业务命令

不要让模型直接拼 ORM 或 SQL。让它先生成一个受约束的提案：

from dataclasses import dataclass
from typing import Literal
@dataclass
class TicketProposal:
ticket_id: int
从action来看。Literal
reason的观点是，str
expected_version: int

确定性业务代码再检查对象权限、动作白名单、乐观锁版本和审批状态。模型负责语义理解，领域层负责真正的授权与落库。老实说，

这样做的价值是：模型即使产生幻觉。也只能得到一份校验失败的建议，不能绕过业务规则。

. 审批要绑定精确内容

审批不能只是 approved=true. 它至少要绑定操作者、目标、动作、参数哈希、过期时间和单次使用状态：

@dataclass
class Approval:
actor_id: str
至于target。str
从action来看，str
payload_sha256: str
expires_at: str
nonce的观点是，str

目标或参数在审批后变化，旧批准立即失效。否则程序会出现“批准 A，执行 B”的隐蔽越权。

. 幂等性决定能不能重试

写动作遇到超时最危险的操作是立刻重试。第一次可能已经成功，第二次会制造重复对象。

安全流程应该是：先记录意图。绑定幂等键，只执行一次超时后查询真实结果。

def execute_once:
if existing := repository.find_by_key:
return existing
repository.record_intent
result = command.execute
repository.record_result
return result

外部程序既不支持幂等、又无法查询结果时自动化应该暂停转人工。

. 验收业务事实而不是接口状态

• HTTP 、点击成功和页面跳转，只能证明请求被接受。真正的完成条件应该是：
• - 目标对象存在；
• - 关键字段精确匹配；
• - 同一幂等键只有一个结果；
• - 审批已经消费；
• - 审计链能关联操作者、动作和结果。

. 一份上线前清单

• Agent 使用独立身份，不借用管理员凭据；工具是业务级动作，不暴露任意 SQL 或脚本；写动作有白名单和对象级授权；老实说，批准绑定内容哈希、过期时间和单次使用；副作用动作都有幂等键，超时后先查询状态；完成后回读业务事实，状态不明时暂停并交给人。说起来，

使用者痛点集锦：

• 担心 AI 在生产环境中误操作导致数据损坏或丢失。
• 合规监管要求必须有完整审计追踪，但传统“一把钥匙”模式难以满足。
• 团队在配置细粒度权限时耗费大量时间与资源。
• 运维人员面临频繁手工介入的问题，降低了自动化收益。
• 程序对重复请求处理不当导致订单或工单被多次创建，引发成本浪费。