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

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

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

1. 四级权限比"能写/不能写"更实用

我通常从四层开始：

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

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

2. 模型输出不是业务命令

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

python 复制代码

from dataclasses import dataclass
from typing import Literal


@dataclass(frozen=True)
class TicketProposal:
    ticket_id: int
    action: Literal["raise_priority", "assign_team"]
    reason: str
    expected_version: int

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

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

3. 审批要绑定精确内容

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

python 复制代码

@dataclass(frozen=True)
class Approval:
    actor_id: str
    target: str
    action: str
    payload_sha256: str
    expires_at: str
    nonce: str

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

4. 幂等性决定能不能重试

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

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

python 复制代码

def execute_once(command, key, repository):
    if existing := repository.find_by_key(key):
        return existing

    repository.record_intent(key, command)
    result = command.execute()
    repository.record_result(key, result.id)
    return result

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

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

HTTP 200、点击成功和页面跳转，只能证明请求被接受。真正的完成条件应该是：

目标对象存在；
关键字段精确匹配；
同一幂等键只有一个结果；
审批已经消费；
审计链能关联操作者、动作和结果。

6. 一份上线前清单

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

总结

AI Agent 可以拥有生产写能力，但不该拿到一把永久、宽泛、不可审计的钥匙。

把执行链拆成只读、建议、审批和回读，再用幂等键约束重复副作用，系统才能清楚回答：谁批准了什么、执行了几次、真实结果是什么。

这时，写权限才不再是一场冒险，而是一种可治理的工程能力。