企业Agent能发邮件、改CRM，该给多大权限？六类动作的授权设计

一个销售 Agent 已经能检索知识库、生成客户跟进邮件，还能调用 CRM 接口。试点结束后，团队希望开放直接发送邮件和更新商机的权限。

技术评审不能只看演示是否顺畅。一次“允许这个 Agent 使用 CRM 和邮箱”，可能同时开放读取、写入、发送与批量执行；其中任何一项越界，都可能影响正式业务。

更合理的设计是：模型负责提出动作，系统负责判定这一次动作是否获得授权。 本文将授权拆成六类动作，并给出工具调用网关、审批绑定和反向验收的实现思路。

下文销售场景、字段和控制策略均为教学示例，不是某企业的实测结果，也不是可直接套用到所有业务的统一制度。

一、先区分“会调用工具”和“有权执行”

Agent 能构造出合法的 API 参数，只说明调用格式符合要求。它是否应该读取某个客户、修改某个字段或发送某封邮件，需要另一套判断。

至少应区分三个对象：

• 工具能力：接口支持查询、修改还是发送。
• 执行身份：实际调用使用哪个账号或受管身份。
• 本次授权：允许对哪些对象、执行什么动作、影响多少条记录。

如果把所有操作装进同一个管理员凭证，再依靠提示词要求模型“谨慎使用”，授权边界就难以单独撤销。只想停止发信时，可能只能断开整个工具；继续保留查询时，又可能顺带保留发送权限。

创建一个 Agent 的权限，也不应自动传递为审批业务动作的权限。开发者维护工具，业务审批者决定具体行为，两者可以由同一人承担，但职责需要明确。

二、六类动作应该分别评审

下表是一种面向实现的拆分方式。批量操作作为额外的影响范围维度，叠加在读取、修改或发送之上，而不是天然具有独立的低风险等级。

动作	销售场景示例	建议的初始边界	执行前必须检查
读取资料	检索产品文档、读取客户记录	限定资料集、字段、对象和用途	有效身份、资源权限、输出接收范围
生成草稿	起草客户跟进邮件	写入独立草稿区，不覆盖正式内容	事实来源、对象、敏感字段
修改业务记录	更新商机跟进阶段	从获批对象和明确字段开始	修改前后值、版本、恢复办法
对外发送或发布	向客户发送邮件	将起草与发送拆成不同动作	收件人、完整内容、附件和本次授权
高后果执行	合同承诺、关键权限变更	普通自建试点只生成申请或候选操作	适用审批流程、责任岗位和接管能力
批量操作	更新一批客户或群发邮件	单独批准对象集合与数量上限	全量影响范围、部分失败和停止条件

两点容易被忽略：只读仍可能把不应暴露的信息带入输出；有撤销按钮也不能保证业务后果可逆。已经被收件人阅读或转发的信息，不会随着系统里一次撤回操作自动消失。

因此，“这个接口是 GET 请求”和“这个字段可以改回去”，都不足以独立作为放行依据。

三、把授权检查放在模型和工具之间

可以为工具调用增加一个受控执行层：

用户任务
  → Agent 生成结构化动作计划
  → 授权检查：身份、资源、动作、数量、时效
  → 需要时提交审批
  → 执行前再次核对计划与授权
  → 调用下游接口
  → 记录结果、异常与接管状态

模型提供动作建议，但不应自行签发批准记录。下游系统仍应使用最小权限身份实施访问控制，避免执行网关失效后直接获得全量权限。

下面是一个待审批动作的字段示例，不代表某个现成协议：

{
  "action_id": "followup-001",
  "actor": "sales_agent",
  "operation": "crm.update",
  "targets": ["test_customer_001"],
  "changes": {
    "followup_stage": {
      "before": "pending",
      "after": "contacted"
    }
  },
  "policy_id": "sales_pilot_v1",
  "approval_status": "pending"
}

执行服务还需要校验这里的身份、对象和旧值是否真实有效；不能因为模型提交了一个结构化字段，就把它当作可信的授权证明。

四、授权要绑定到实际动作，不能只绑定任务名称

“已批准客户跟进”过于宽泛。审批者看到的可能是一封邮件，实际执行时却追加了附件或扩大了收件人范围。

一种实现方式是生成不可随意修改的动作快照，记录对象集合、正文版本、附件标识、执行身份与到期条件。审批记录关联这份快照，执行端校验当前动作与获批版本是否一致。

如内容、收件人或目标字段发生变化，应重新判断原批准是否仍覆盖当前动作。具体是否需要重新确认，由明确的授权范围决定，不能由模型自行扩大解释。

在实现审批摘要或哈希时，还要规范字段顺序、附件版本和编码方式。摘要只用于发现内容变化，并不能替代身份认证、签名校验或权限检查。

五、实施时优先做好这五个控制点

1. 分离读、写和发送能力

工具定义要足够细。与其暴露一个可以执行任意业务操作的接口，不如分别定义检索、生成草稿、修改指定字段、发送指定邮件等能力。

如果底层接口只能提供过宽权限，应通过受管代理限制操作，或者先维持较小的试点范围。不要把文档里写着“只读”当作系统已经禁止写入的证据。

2. 在目标系统执行资源级检查

不仅检查“能否访问 CRM”，还要检查具体客户、字段和操作。发起人可见的对象范围与服务账号的对象范围可能不同，需要明确定义映射规则。

第三方资料、邮件或网页中的指令属于输入内容，不能自动成为扩大工具权限的理由。资源权限由可信系统判定。

3. 将批量操作视为影响范围变化

一次获批的单条更新，不应被解释为可以循环处理整个客户库。限制对象集合、单次数量、速率和总量，并明确这些限制在重试时如何计算。

如果需要分批推进，应记录每一批的成功、失败和未执行对象。超过错误阈值时停止后续批次，而不是为追求完成率持续重试。

4. 处理超时、重复执行和并发修改

调用超时并不等于动作没有生效。应优先查询动作状态，使用接口支持的幂等机制；接口不支持时，需要设计可核验的结果检查方式。

修改 CRM 字段还要关注并发：审批之后，销售人员可能已手工更新记录。执行时比较版本或修改前值，避免将新信息覆盖为旧计划中的结果。

5. 让撤权和人工接管真正可用

撤权至少要覆盖后续调用、等待中的动作和已有执行凭证。是否能撤销正在进行的请求，取决于系统能力，应在测试中明确。

接管记录需要告诉负责人：哪些动作已完成，哪些结果未知，哪些尚未执行。只留一句“任务失败”，无法帮助人判断下一步是否会重复发信或重复改数据。

六、上线前跑一组反向验收

测试输入或变化	应观察的结果
请求读取不在获批范围内的客户	在读取环节拒绝，不把数据带入后续生成
已批准一封邮件，随后增加收件人	按授权策略重新判断，不默认为原批准覆盖
单条修改被改成全库循环	对象集合或总量限制生效
审批后 CRM 记录被人工更新	识别版本冲突，停止覆盖或请求重新评估
调用超时后触发重试	查询真实状态，避免重复产生业务动作
撤销执行身份后继续任务	后续执行被拒绝，并留下待处理状态

测试应在获批的测试环境和样本上执行。通过标准要来自目标系统的实际状态，而不是 Agent 自述“已经遵守规则”。

七、销售 Agent 可以怎样分阶段开放

第一阶段可限定为读取指定资料并生成邮件草稿，验证来源、对象和内容质量；第二阶段再对少量获批测试记录开放一个字段的更新，展示前后值并验证恢复；发送与更高影响的动作单独评审。

扩大范围的依据应是实际错误样本、结果质量和接管能力，而不是笼统的“已经试用了两周”。同时记录业务负责人、工具维护者、资料所有者和审批者，避免把全部责任压在创建 Agent 的员工身上。

来源与延伸阅读：Runwise 的员工自建 Agent 六类动作授权决策表提供了按动作评审权限的业务框架。本文将其重构为工具调用、审批绑定、批量边界和反向验收的工程实践。