企业管理系统要不要给 AI Agent 写权限？一套分级授权方案

把 AI Agent 接进 CRM、进销存、项目管理或客服系统以后，最容易出现两个极端：一种是完全不给写权限，Agent 只能回答问题，无法真正减少重复操作；另一种是直接给数据库或全量接口，短期演示很惊艳，生产风险却被一起放大。

我的结论是：企业管理系统可以给 Agent 写能力，但不能给“无限写权限”。正确的设计单位不是“这个 Agent 能不能写”，而是“谁发起、写什么对象、影响多大、能否预览、谁来批准、如何回读与回滚”。

对中小企业、个人和创业团队来说，这不是额外的形式主义。团队越小，一次误发客户通知、误改库存或误删订单越难靠专门运维人员补救，所以权限边界反而要更清楚。

一、先把“写权限”拆成四级

L0 只读：Agent 可以查订单、客户、库存和项目状态，但不能改变任何业务数据。适合经营问答、日报汇总和异常提示。

L1 生成草稿：Agent 可以生成跟进记录、报价说明、工单回复或营销文案，但只写入草稿区，必须由业务人员确认后进入正式数据。这个层级通常能覆盖大量“复制、整理、起草”工作。

L2 审批后写入：Agent 可以提出一个结构化变更，系统展示对象、旧值、新值、影响范围和依据；获得一次性批准后，才通过受限接口执行。适合更新客户标签、分配负责人、调整普通任务状态等可恢复操作。

L3 人工执行：付款、退款、批量删除、跨租户变更、权限提升、正式对外通知等高风险动作，Agent 只负责收集材料和生成操作建议，最终动作由有权限的人在原系统中执行。

这里的重点不是层级名称，而是默认最小权限。OWASP 对 Agent “过度自主操作”的风险建议同样强调：只给完成任务所需的最小工具、最小权限，并对高影响动作设置人工批准。

二、权限策略必须在提示词之外

如果只在系统提示词里写“不要删除数据”，这不是权限控制。提示词会受上下文、外部内容和模型行为影响，真正的业务边界必须由确定性的策略引擎执行。

下面是一个简化示例：

from dataclasses import dataclass
from enum import IntEnum


class RiskLevel(IntEnum):
    READ = 0
    DRAFT = 1
    APPROVED_WRITE = 2
    HUMAN_ONLY = 3


@dataclass(frozen=True)
class ChangeRequest:
    actor_id: str
    tenant_id: str
    action: str
    resource_id: str
    before: dict
    after: dict


HUMAN_ONLY = {"refund", "delete_order", "grant_admin", "send_bulk_message"}
APPROVAL_REQUIRED = {"update_customer_owner", "change_inventory", "close_ticket"}


def classify(request: ChangeRequest) -> RiskLevel:
    if request.action in HUMAN_ONLY:
        return RiskLevel.HUMAN_ONLY
    if request.action in APPROVAL_REQUIRED:
        return RiskLevel.APPROVED_WRITE
    if request.action.startswith("draft_"):
        return RiskLevel.DRAFT
    return RiskLevel.READ

生产实现还需要校验当前用户、租户、资源范围、字段白名单、批量数量、时间窗口和速率限制。Agent 不能提交任意 SQL、任意 URL 或任意工具名；它只能调用业务系统公开给它的窄接口。

RuyiBookCourse 关于企业 Agent 架构的内容也提出相同方向：工具集合应尽可能小，策略决策应从提示词中外置到规则层。这样业务人员调整审批门槛时，不需要重新训练模型，也不会因为换一个模型就丢失安全边界。

三、安全写入要形成可验证闭环

一条可靠的写入链路至少包括六步。

请求：记录发起人、租户、会话、业务目标和原始输入。
策略：根据动作、对象、数量和影响范围判级，拒绝越权和跨租户请求。
预览：展示将要修改的对象、旧值、新值、原因和不可逆影响。
批准：审批必须绑定这次变更内容、审批人和有效期；内容改变后旧批准立即失效。
执行：通过业务 API 执行，数据库账号本身仍只拥有必要表和必要操作。
回读或回滚：执行后重新读取正式状态，确认实际结果；失败或偏离预期时使用补偿操作或版本快照恢复。

审批不是一个通用的“同意”按钮。例如某次批准把客户 A 分配给销售 B，就不应顺便授权 Agent 修改其他客户。一次性批准令牌应绑定请求摘要，并在使用后作废。

审计日志至少记录：谁发起、模型和版本、调用了什么工具、输入摘要、策略判级、审批人、执行结果、回读结果、关联业务对象和回滚状态。日志要避免直接保存密钥与不必要的个人敏感信息。

四、四类常见业务怎样落级

场景	建议等级	原因
查询本周销售漏斗	L0	只读聚合，不改业务状态
生成客户跟进纪要	L1	内容先进入草稿，由负责人确认
把工单分配给值班人员	L2	可恢复，但需确认对象与当前班次
调整库存数量	L2	会影响采购与销售，必须预览差异并审批
批量给客户发送通知	L3	对外影响大，名单与文案都需人工复核
退款、删除订单、授予管理员	L3	涉及资金、数据完整性或权限提升

小程序和 App 中的 Agent 也应遵循同一策略。前端入口不同，后端权限模型不能各写一套。企业官网里的智能客服通常以 L0/L1 为主；管理系统可以开放受控的 L2；涉及资金、权限和正式外发的 L3 仍由人完成。

五、实践验收：不要只测“成功路径”

上线前至少完成下面十项验证：

1. 无权限用户请求写入时被拒绝，并返回可理解原因；
2. Agent 不能跨租户读取或修改资源；
3. 提示词要求调用未注册工具时，系统拒绝执行；
4. L2 变更必须显示旧值、新值和影响对象；
5. 审批后修改请求内容，原批准失效；
6. 同一批准令牌不能重复使用；
7. 批量数量超过阈值时自动升级为人工执行；
8. 接口超时或部分失败时不会留下未知状态；
9. 执行后回读结果与目标不一致时触发告警或补偿；
10. 审计记录能根据一次业务变更还原完整链路。

还可以先对少量内部用户、少量租户和低风险动作开放，观察拒绝率、审批率、回滚率和人工纠正率，再逐步扩大范围。这比一次把所有工具交给 Agent 更容易发现策略漏洞。

六、常见误区与风险边界

误区一：把数据库只读账号换成可写账号就算接入。 数据库权限通常过宽，也缺少业务级预览和审批语义。

误区二：只记录最终结果，不记录决策过程。 出错后无法判断是输入、模型、策略、审批还是执行器的问题。

误区三：认为“可回滚”就可以少审批。 对外通知、资金变动和数据泄露无法靠数据库回滚完全恢复。

误区四：所有动作都人工批准。 这会让系统沦为更慢的表单。应该把只读和草稿自动化，把审批集中在真正有业务影响的写入。

七、来源、延伸阅读与服务定位

本文的最小权限、人工批准和审计建议参考了 OWASP LLM06:2025 Excessive Agency 与 OWASP AI Agent Security Cheat Sheet。OpenAI 对 Codex 的说明也展示了类似边界：Agent 默认在受限环境中工作，扩大权限时需要显式批准，代码变更以补丁形式交给人复核，可参考 Codex Security。

关于如何把智能体任务拆成可审计、可验证的工程流程，可以继续阅读《大鹏 Codex 智能体软件工程》。本文三张配图是 AI 生成的概念图，来源与哈希已经记录；更多技术视觉素材可在如意图库查看。

白泽软件面向中小企业、个人和创业团队，提供企业官网、小程序、App、管理系统和小游戏开发。我们在管理系统中加入 AI 时，会先把权限、审批、审计、回读和回滚作为正式需求，而不是等出错后再补。

最后结论

企业管理系统不是不能给 AI Agent 写权限，而是不能把“能调用工具”误当成“可以随意操作生产数据”。

最实用的落地顺序是：先开放只读，再开放草稿；把可恢复的有限写入放进一次性审批；把资金、删除、权限提升、跨租户和正式外发保留给人工；所有执行都要回读，所有高风险变更都要能追溯。这样 Agent 才是在减少重复劳动，而不是把一次模型判断变成整套业务系统的单点风险。