下属自己搭了个能发客户邮件的 Agent，你批不批？六类动作的授权决策表

一句话看懂：员工自建 Agent 申请正式权限时，管理者不应简单回答“批”或“不批”，而应先把任务拆成读取资料、生成草稿、修改记录、对外发送、高风险执行和批量操作六类动作，再分别判断数据是否有权读取、动作是否必要、错误能否撤回、谁承担批准与接管责任。核心原则是：创建权不等于执行权，只读不等于无风险，可撤销不等于后果可逆。更可执行的做法是，为每类动作设定默认边界、执行前控制和责任停止条件，并把权限写进系统而非仅写进说明文字。

一个周一早上，销售运营的部门经理发来一条消息：他自己搭了一个 Agent，能检索公司知识库、按模板写客户跟进邮件，还接上了客户管理系统里的商机记录。试用两周，团队反馈很好。现在他想申请正式权限，让这个 Agent 直接发邮件、直接更新商机状态。

问题落到你桌上，看起来只需要回答一个字：批，还是不批。

但这一次授权其实同时打开了好几扇门：它能读取哪些客户资料、能不能生成草稿、能不能改正式记录、能不能向客户发送信息、能不能继续连接其他系统。如果这些动作被装进同一个管理员账号，你之后很难只关掉其中危险的那一部分。

更可执行的做法，是先把任务拆成动作，再分别判断四件事：数据是否有权读取、动作是否必要、错误能否撤回、谁承担批准与接管责任。

先记住三条，后面所有判断都建立在它们上面：

创建权 ≠ 执行权；只读 ≠ 无风险；可撤销 ≠ 后果一定可逆。

一、这已经不是一道假设题

过去两年，“员工自己搭 Agent”的门槛正在快速下降。到 2026 年下半年，千问办公、豆包工作、WorkBuddy 等产品都在强化技能、连接器、Agent 创建或分享能力，员工把个人尝试扩展成团队可共享使用的工具，已经不再只是技术团队的事情。

阿里千问办公的官方介绍提到“组织级技能”，可以把一次成功的交互过程做成技能，供组织内共享使用。字节豆包工作支持按需扩展技能模块、连接器与第三方工具，并沿用飞书既有的角色访问控制模型。腾讯 WorkBuddy 支持技能的创建、安装和分享；其官方产品页当前显示 SkillHub 提供 100+ 领域专家、7 万+ Skills（WorkBuddy 官方产品页）。

这些公开能力说明，技能资产正在被更低门槛地创建和传播使用，但它们并不自动等于经过了企业权限评审。随着同一个技能被更多人安装、分享或重复使用，单个权限设计的问题也可能被同步放大。

所以摆在管理者面前的问题已经变了。不再是“要不要允许员工自建”——产品默认允许，员工已经在建。真正的问题是：这些自建出来的工具，怎样进入真实的业务责任链。

二、一次授权，其实是六件事

把开头那个销售 Agent 拆开看，它申请的是六类完全不同的动作，风险差着几个量级：

1. 读取客户知识库和历史成交资料
2. 生成一封邮件草稿
3. 更新商机记录里的“跟进阶段”字段
4. 直接把邮件发给客户
5. 修改合同金额或折扣审批
6. 批量对全部在库客户执行以上任一动作

第 1 项和第 4 项之间，隔着一整条对外责任链。第 4 项和第 6 项之间，隔着一次可能波及全部客户的事故。用一个“批”字回答这六件事，是这类申请最常见的处理方式，也是最常出事的地方。

有两个直觉需要先纠正。

只读不天然低风险。如果工具能读取全公司的薪酬或客户资料，即使它不修改任何记录，也可能造成越权和泄露。读取的风险由数据范围决定，不由动作类型决定。

“有撤销按钮”不代表后果可逆。撤回一封邮件，不能保证收件人忘记其中的内容；更不能保证对方没有截图、没有转发给他的同事。可逆性要按后果判断，不按界面上有没有那个按钮判断。

三、六类动作的默认边界

下表是供内部评审使用的建议，不是统一的法规标准，也不是任何一家企业已公开实施的完整制度。

这张表的粒度仍可以继续缩小。“修改客户信息”太宽，“只在指定的 5 个测试客户记录中更新一个内部标签”才是可评审的。

还有一条容易被漏掉：对一次可能波及全部客户的批量操作，即使每一条单独看都能回滚，也应该提高控制强度。一万条记录理论上可回滚，和一万条记录实际被逐条回滚，是两回事。

这类问题在国际标准里也有对应。OWASP 针对大模型应用列出的十大风险中，有一项叫“过度代理”——它把功能过多、权限过宽、自主性过高列为主要来源，建议限制工具能力、最小化权限，并对高影响动作设置人工批准OWASP：LLM06 Excessive Agency。

作为产品侧的一个参照：Shopify 的官方帮助文档说明，其内置助手在变更生效之前会先把改动呈现给用户审核。值得借鉴的是“审阅放在动作生效之前”这个次序，不能据此推定每一种第三方扩展或其他企业工具都有同样控制Shopify Sidekick 帮助中心。

四、权限要写进系统，不只写进说明文字

“不要越权”可以作为工作说明，但它不能替代技术限制。上面提到的那份 OWASP 指南明确建议：由下游系统实施授权检查，而不是只让模型自己判断某个动作是否被允许。

这一点在实践中的差别很大。写在提示词里的“你不得发送邮件”，在模型被诱导、被误解或版本更新之后可能失效；配置在邮件系统里的“该账号无发送权限”，不会因为对话内容改变。

因此，一份可执行的授权至少应回答六个具体问题：Agent 用谁的身份；允许访问哪些资源；允许执行什么动作；一次能影响多少对象；何时必须暂停并交给谁；平台怎样撤销访问。

下面是一个可审核的填写样本。这是一项建议配置，不代表任何企业的现行做法。

如果工具无法实施其中的必要限制，不要把表格上的签字当作限制已经存在。这是评审会上最容易自我欺骗的一步：制度写得很完整，系统里一个开关都没有。

遇到这种情况，合理的做法是先降级——由人工提供已批准的资料，Agent 只生成本地草稿，等平台的权限能力具备之后再开放连接。

五、“由人负责”要有对象、有证据，也有时间

“最终由人把关”这句话如果没有具体岗位和检查对象，很容易变成形式批准。

审批者至少需要看到四件事：这次将影响什么对象、具体改什么、依据是什么、出了问题怎样止损。看不到这四件事而点了同意，这个签字在事后追责时不构成任何保护。

组织规模较小时，一个人可以兼任其中几个角色，但不能省略任务本身。岗位分离、数据处理或专业审批另有要求时，按企业适用要求执行。这份通用表不构成对医疗、金融、工业安全等专业流程的合规认证。

六、能开放多少自主权，取决于接管能力

授权不是一次性决定。业务资料会变，工具会升级，创建者也可能调岗。

建议把复核与撤权附在工具记录上。以下任一情况发生时，重新确认这个 Agent 能否继续使用：负责人离开、数据范围扩大、模型或工具有重要变化、出现越权尝试、输出质量持续下降。

不要为了追求“自动化率”，让 Agent 对不确定的任务反复执行。可以允许它在已批准范围内完成常规工作，同时把高后果动作、无法判断的资料范围和异常结果交还给人。对复杂任务，先从最小可用流程开始，再根据真实质量、接管工作量和成本逐步扩大权限。Anthropic 的工程建议也指出，复杂程度应随实际需要增加，而不是默认拉满。

七、回到那个销售 Agent：你应该批什么

现在可以回答开头那个问题了。答案不是“批”或“不批”，而是一份分项清单：

可以立刻批的：读取已划定范围的客户知识库（限定字段、限定用途）、生成邮件草稿并写入个人草稿区。

可以小范围批的：在 5 到 10 个指定客户记录上更新“跟进阶段”这一个字段，显示修改前后值，验证过恢复办法之后再扩大。

暂不批的：直接向客户发送邮件。改为起草与发送分离，由销售本人在原系统确认发出。等运行两个月、有了实际的错误样本和接管记录之后再评估。

明确不批的：修改合同金额或折扣、对全部在库客户执行批量动作。

同时要写清的：这个 Agent 用谁的身份连接客户管理系统、部门经理调岗之后由谁接手、什么情况下平台可以直接停用它。

管理者最终要批准的，从来不是“这个 Agent 好不好用”，而是“哪个 Agent，为谁完成什么任务，在什么范围内行动”。先把这句话写清楚，再讨论全公司是否开放自建。

八、先把你手上那个 Agent 过一遍

本周可以做的最小动作：拿一个团队里已经在用的助手，按上面的六类动作列出它现在能读、能写、能发和必须暂停的清单。大多数人做完这张表会发现，实际开出去的权限，比当初批准的那一项要宽。

如果你手上正好有一个待批的申请，可以把下面这段复制到 Upskill Pro 的专业级AI顾问工具，让它先出一版评审草稿，再拿去和 IT、法务讨论：

我们有一个员工自建的 Agent 在申请正式权限，请帮我出一份可以进评审会的授权草案。

Agent 用途：[一句话说明它替谁完成什么任务]
现在能读取的资料：[列出资料类别，注明是否含客户个人信息、人员绩效、合同、财务数据]
申请开放的动作：[列出，例如生成草稿／修改某字段／对外发送／调起审批]
执行时使用的身份：[创建者个人账号／部门公共账号／受管的企业连接，或“不清楚”]
一次可能影响的对象数量：___
创建者：___；业务负责人：___；如果创建者调岗，接手人：___
所在行业是否有额外监管要求：[有／无／不确定]

请分四步输出：
一、把这个申请拆成具体动作，逐条判断可逆性、影响范围和错误后果，对每条给出“可批／限范围批／暂不批／明确不批”，并说明理由；
二、指出哪些限制必须配置在系统里、不能只写在工作说明中；
三、按业务负责人／创建者／资料所有者／审批者四个角色，写清各自该承担和不该承担的责任；
四、列出触发重新复核或直接停用的条件。

要求：只读也要评估数据范围风险，不要因为“不修改记录”就判定低风险；对我标注为“不清楚”或“不确定”的项，直接列为评审前必须查清的问题，不要替我假设。

最后那条同样是重点。一份把未知项都填成合理假设的评审草案，比没有草案更危险——它会让评审会以为问题已经想清楚了。

如果你正在规划跨部门共用的 AI 入口，可以继续读摩根大通的平台与风险边界案例，观察平台能力与业务责任如何分开管理。

想把这套打法用到你自己的业务上？

把本文的六类动作授权表套用到你团队里正在用的那个 Agent 上，看看实际开出去的权限是不是比当初批准的要宽。如果发现差距，可以用 AI 顾问先做一次授权诊断，把风险边界理清楚再上评审会。

💎 核心承诺：先诊断、再合作，思路不对不推进。

专属咨询热线：400 822 8832

扫码加顾问 Ben 评估