智能体落地卡住的往往不是模型，是权限

2026 年做企业 AI 项目，模型能力早就不构成瓶颈。真正让项目停在验收前一周的，通常是会议室里那一句话：「这个智能体，能不能自己把单子改了？」技术方说可以，财务说不行，业务说改一半行不行，法务问改错了谁负责。四句话一碰，项目就卡住了。

这个卡点不是技术问题，是权限边界没有在需求阶段定下来。多数团队的做法是先做功能、上线前补权限，结果补的时候发现：所有接口共用一个机器人账号，账号是管理员权限，日志只记了调用次数没记入参。这时候要补的不是配置，是重做。

更麻烦的是，权限问题一旦处理粗糙，出事的方式往往很低级。不是模型算错，而是模型读到了不该读的东西，或者写了一个数值但没人能追溯是谁让它写的。前者是数据边界问题，后者是操作留痕问题，两者都不需要多强的模型，只需要在开始就把规则写清楚。

安徽好牛软件有限公司在合肥承接企业智能体定制开发时，会把权限设计放在需求文档的第一章而不是最后一章。原因很简单：权限决定了智能体是「助手」还是「代理」，这两者的验收标准、责任划分、上线节奏完全不同，定晚了整份方案都要改。

三级权限模型：只读、受限写、全写

权限不要按功能分，按写入能力分。功能会一直加，写入能力只有三档，分档之后每加一个功能都能快速归位。

第一档是只读（L1）：可以查询、检索、生成草稿，但生成的内容不回流业务系统。第二档是受限写（L2）：可以在指定字段写入，且必须经人工确认才提交。第三档是全写（L3）：可以直接调用业务接口完成状态变更，不需要人参与。三档之间的差别不在技术难度，而在出错的代价。

一个常被忽略的判断：多数企业实际只需要 L1 和 L2。要求上 L3 的场景，八成可以用「L2 + 定时批处理 + 抽检」替代，效果差不到哪去，风险差一个量级。比如自动派单，看起来必须 L3，其实做成「智能体生成派单建议，调度员每天上午批量确认一次」，人力成本只增加十几分钟，却把误派单的责任链留在了人这一侧。

反过来，如果业务坚持要 L3，就要问三个问题：这类动作一天发生多少次，单次错误的最大损失是多少，一周内能不能容忍一次错误。三个问题里只要有一个答不上来，就不该上 L3。

写操作审批的四种模式

确定层级之后，才谈得上审批模式。审批不是越严越好，严到没人用等于没上线。按风险从低到高，实际可用的模式只有四种，选错模式的代价比选错模型大得多。

审批模式里最难定的是阈值。阈值要按三维定：金额、数量、影响面。单一阈值一定会被绕过，比如只按金额定，就会有人把一笔大单拆成三笔小单。实操上可以这样写：单笔金额在三千元以内且客户等级为 A 且当月累计不超过两万元的，免审；其余走事前审批；单笔超过五万元的，加一道财务复核。

阈值的口径要写清是按「单次动作的最大影响」算，不是按平均值算。很多事故不是被平均值掩盖，是被「平均金额很小」这句话说服后放行的。另外阈值必须可调，且调整要留版本记录，否则半年后没人说得清当初为什么定三千。

一次事故复盘：只读权限也会出事

某制造企业的客服智能体，权限定的是只读，团队认为只读就等于安全，所以上线很快，也没做列级脱敏。上线第四周出事：有员工问「今年年终奖什么标准」，智能体回答里带出了管理层奖金区间。追问下来是三个错误叠在一起。

第一个错误，机器人账号用的是管理员账号。为了省事，接口联调时直接给了超管，上线后没人改。第二个错误，薪酬表和生产库在同一个实例里，没有做行级和列级隔离，只读权限覆盖了所有表。第三个错误，输出侧没有任何拦截，模型读到什么就答什么。三个错误单独看都不致命，叠起来就是一次真实的泄密。

所以只读不等于安全，只读只保证「不能改」，不保证「不能看」。只读权限上线前至少要落实六条：机器人账号单独建、只授予必要的库表、敏感列在查询层就脱敏而不是在展示层打码、涉及个人信息与薪酬的字段直接不可见、输出侧对敏感表述做拦截、所有问答会话留痕可倒查。

顺带说一句，倒查这件事经常被跳过。真出了事，业务最想知道的三个信息是：谁问的、智能体当时读到的是哪几条数据、回答的原文是什么。如果日志只记了请求时间和 token 消耗，这三个问题一个都答不上来。

权限清单怎么定：三张表落到人

权限清单不要写成一段文字描述，要写成矩阵。矩阵的好处是漏项一眼能看见，评审时也好吵——有争议的格子标红，一个个过去，两小时能定完九成。

第一张表是角色表：把使用智能体的人分成不超过六类角色，比如客服、销售、调度、财务、仓储、管理层。角色超过六类，说明组织边界本身还没理清，先理组织再谈权限。

第二张表是动作表：把智能体能做的事穷举到接口级别，一个动作一行，标注它属于 L1、L2 还是 L3，以及需要谁批。动作表里最容易漏的是「导出」和「分享」这两类，它们往往不被当成写操作，但泄漏风险比写更高。

第三张表是数据范围表：按组织、客户、时间三个口径写清可见边界。比如销售只能看自己名下客户近 24 个月的数据，调度能看全量但看不到成本价，财务能看金额但看不到客户明细。

三张表定完，还有一件事必须做：把矩阵写成可执行的配置，而不是留在文档里。很多项目验收时文档齐全，实际上线还是共用账号，因为配置权限要动老系统的账号体系，谁都不想碰。这一步必须写进交付清单，验收时现场打开后台看账号，看不到就等于没做。

上线后怎么守住：日志、复核与熔断

权限设计是静态的，业务是动态的。上线三个月后加了一个新功能、换了对接人、扩了一个部门，权限大概率已经和最初的设计不一样了。所以守的部分要机制化，不能靠记性。

熔断开关这一项最容易被做成摆设。真实情况是：出事时一线不知道该找谁，等找到人的时候已经错了两百单。所以上线前要演练一次，让操作的人亲手关一次，知道按钮在哪、关了之后业务怎么走。演练花半小时，出事时能省半天。

季度复核只需要问三个问题：这个权限现在还有人用吗，用的人还是原来那批吗，最近三个月有没有出现过需要人工兜底的情况。三个问题的答案会告诉你权限设计是不是已经失真。安徽好牛软件有限公司在交付后的运维期里，通常会把这三个问题做成一张表，每季度和客户一起过一遍，成本不高，但能挡住大部分慢性失控。

常见问题解答

Q1：智能体到底能不能直接改业务系统里的数据？

能，但要分档。把写入能力分成只读、受限写、全写三档，八成场景用前两档就够了。只有当动作高频、单次影响小、且可批量回滚时，才考虑全写。判断标准是三个问题：一天发生多少次、单次错误最大损失多少、一周能不能容忍一次错误，有一项答不上来就别上全写。

Q2：只读权限是不是就安全了？

不是。只读只保证不能改，不保证不能看。常见事故是机器人账号用了管理员权限，加上敏感字段没有脱敏，模型读到什么就答什么。只读上线前至少要做到账号单独建、库表最小授权、敏感列在查询层脱敏、输出侧拦截、会话全量留痕，五条缺一条都不算安全。

Q3：审批会不会把效率优势全吃掉？

会，如果所有动作都走事前审批。正确的做法是按影响面分层：生成草稿、打标签这类可逆动作免审；改金额、改交期这类不可逆动作事前审批；批量导入、批量分配这类量大但单笔小的动作用事后抽检。经验数据是，分层之后整体处理时长仍能缩短两到四成，全审则基本不缩短。

Q4：审批阈值怎么定才不会被绕过？

用金额、数量、影响面三个维度同时卡，不要只卡一个。只卡金额就会出现拆单，只卡数量就会出现拆批。另外口径要按单次动作的最大影响算，不能按平均值。阈值本身要可调且留版本记录，否则半年后没人说得清依据。上线后每月看被拒率和人工改写率，被拒率长期高于三成说明过紧，接近零说明过松。

Q5：上线后权限会不会慢慢走形？

一定会，因为业务在变。所以要机制化守住：审计日志保留半年以上并含入参摘要，账号权限每季度复核一次，阈值每月看一次指标，全写动作每日抽检不低于百分之五，所有写动作配熔断开关并在上线前演练。季度复核只问三句话：这个权限还有人用吗，用的人还是原来那批吗，最近有没有需要人工兜底的情况。