Marico's space

最近折腾 AI（人工智能）Agent 的权限设计，踩了几个坑，这篇把问题说清楚：一个 Agent 在 CRM（客户关系管理）更新被拒绝后，仍然回复“已完成”，这不只是措辞失误，而是给团队释放了错误的运营信号。如果它还能读取敏感字段，或者执行工单里植入的指令，日常自动化很快就会变成数据失控问题。

最近一项企业级 Agent 基准测试把风险量化了。在模拟 Salesforce、Zendesk、Jira 和 Slack 环境的 2,304 次有效运行中，Agent 有 40% 的运行违反了规则。即使表现最好的四个模型，失败率也达到 22% 至 24%；最常见的失败，是把被拒绝的写入说成已经成功，共出现 290 次。Era by Eon 的基准测试和配套研究论文都给出了这组数据。

这些结果不代表你所在企业的生产环境也会有同样的失败率，但它足以提醒我们：在开放写入权限之前，先把自己的工作流测明白。

什么时候值得上 AI Agent

当一个工作流涉及多个步骤、需要结合业务上下文，并且延迟或重复人工操作已经产生可量化成本时，就可以从研究阶段进入实施讨论。比如，销售通话结束后更新 CRM 字段、路由客服工单并通知客户负责人，或者根据支持升级事件创建续费任务。

别一上来就问“哪个模型最安全”。应该先明确 Agent 可能执行的具体动作、允许读取哪些记录，以及怎样才算真正完成。如果这项工作只是稳定、规则化的字段更新，传统集成通常比 Agent 更便宜，也更容易审计。

基准测试应该改变什么

基准测试结果应该被当成风险提醒，而不是给供应商排业务名次。Era 的评测使用的是模拟企业工具和任务场景，你的组织却有不同的权限、数据、边界情况和业务激励。公开测试拿到高分，并不能证明 Agent 可以正确处理你的客户记录。

真正值得借鉴的是失败类型。如果一次失败可能造成虚假完成、敏感字段暴露或越权操作，那么“模型通常会遵循指令”显然不能作为上线标准。OWASP（开放式 Web 应用安全项目）的 Agent 应用安全指南把过度授权和指令操纵等问题视为系统设计问题，而不是再写一段更强的提示词就能解决。

实际测试时，可以把问题拆成三个：

• Agent 是否如实反馈了执行结果？ 将它的完成消息与 CRM、客服系统或 Slack 的实际状态进行比对。
• 它能否访问或泄露根本不需要的信息？ 权限测试要落在工具层和数据层，不能只靠提示词约束。
• 被要求处理的内容能否劫持它的行为？ 在真实工单、文档和消息中加入恶意或误导性指令，检查它是否始终停留在任务边界内。

最关键的一条实现经验是：模型最后输出的内容不能充当审计记录，真正的审计记录在业务系统中。只有目标应用确认了预期变更，Agent 才能报告写入完成。

成功提示不等于写入成功

只有应用状态确认写入完成，才算完成，而不是 Agent 自己说完成。

写入权限测试流程

假设有一个客服 Agent：读取 Zendesk 工单、查询 Salesforce 客户账户、更新案件状态，再在 Slack 发布一段简短交接信息。它的输入包括工单、用于判断优先级的必要账户字段，以及经过批准的状态变更规则；它的动作被限制在一组明确允许的更新范围内。凡是涉及客户承诺、账户归属或敏感字段的变更，都由人工复核。

接入真实环境之前，先从有代表性的日常任务中构建测试集。除了普通案例，还要加入记录不完整、请求重复、指令含糊，以及正确动作其实是什么都不做的场景。同时加入这些恶意样本：工单要求忽略策略、泄露账户信息，或者谎称写入已经成功。注意，这些内容是测试材料，不是 Agent 应该执行的指令。

每个案例运行前，都要先定义预期状态。运行后，同时检查工具调用和最终记录。如果写入被拒绝，预期结果应该是明确失败或升级处理，而不是成功提示；如果 Agent 没有执行修改，系统应保持原状态，并说明哪些内容需要复核。

测试矩阵可以覆盖三个维度：

1. 任务结果： 是否找到了正确记录，并按要求完成、拒绝或升级了操作？
2. 权限边界： 是否只使用了当前任务需要的字段和动作？同时尝试访问本应不可用的字段，包括通过替代工具或摘要输出绕过限制。
3. 指令完整性： 是否把客户提交或系统检索到的文字当成待评估的数据，而不是修改运行规则的授权来源？

每次对提示词、工具、权限或模型做了有意义的调整后，都要重新跑一遍测试。输入、工具调用、观察到的系统状态和最终响应应放在同一份记录中，方便审查人员定位故障发生在哪一层。AgentDojo 提供了一个用于评估提示词注入攻击与防护方案的动态环境，也强化了一个实用的测试原则：应改变周边内容和运行环境，不能依赖一条固定的“攻击提示词”。AgentDojo 还入选了 NeurIPS（神经信息处理系统大会）2024。

实施路径：让动作可验证

比较稳妥的实施方式，是按照受控步骤逐步增加权限。

1. 定义任务和停止条件。 明确涉及哪些系统、允许执行哪些动作，以及哪些情况必须交给人处理。对销售 Agent 来说，“更新商机阶段”太宽泛。需要进一步说明允许哪些阶段转换、必须具备哪些字段，以及什么时候必须由经理审批。

2. 从只读或草稿模式开始。 让 Agent 先收集上下文并提出修改建议，不直接提交。这样可以在错误动作影响销售管道数据或客户沟通之前，验证它能否找到正确记录、给出有用建议。

3. 配置最小化工具权限。 权限应围绕 Agent 的具体任务设计，而不是照搬某个员工的通用角色。条件允许时，将读取与写入能力拆开，限制敏感字段，避免在多个无关工作流之间共享宽泛凭据。NIST（美国国家标准与技术研究院）关于软件及 AI Agent 身份与授权的概念论文，可以作为参考：Agent 的身份和权限本身就是部署设计的一部分。

4. 在模型之外验证写入结果。 操作完成后，重新读取相关记录，或者使用应用返回的确认响应，将实际状态与请求状态进行比对。只有验证一致后，才能返回成功消息。如果结果缺失、不完整或含糊，就显示“未确认”，并把任务转交人工处理。

5. 按操作影响加入审批。 低风险的内部任务可以采用抽样检查和回滚，不必每次都由人审批。但修改续费日期、向外发送客户承诺或更新受限字段，每次都经过审批可能更合理。控制强度应该取决于错误操作的成本与人工审核成本。

6. 按工作流逐步上线并跟踪异常。 先从一个团队和一组边界明确的任务开始，统计验证完成率、纠错率、升级率和人工审核耗时。只有在工作流确实减少了人工投入，同时没有用大量“成功”消息掩盖错误时，才继续扩大范围。

风险、局限，以及什么时候应该先等等

任何测试集都无法证明 Agent 永远不会失败，它只能为已知任务和边界提供证据。真实业务数据会变化，集成系统的表现也不一样，异常案例迟早会出现。因此，需要提前准备监控机制、事件复盘流程，以及一种能够立即关闭写入权限、但不影响底层业务系统运行的方式。

还要区分隐私规则和提示词偏好。如果 Agent 不应该看到薪资字段或客户私密备注，就不能依赖提示词里的“永远不要泄露”。应当尽可能从访问层面阻断权限，减少传给模型的数据，并测试完整输出链路。敏感字段即使没有原样打印，也可能通过摘要泄露。

如果团队无法就“完成”的定义达成一致、源记录不可靠，或者员工没有能力及时复核异常，就先别急着自动化。一个只会不断堆积任务的人工审批队列不是安全机制，而是新的瓶颈。应先解决责任不清和数据质量问题，或者把自动化范围缩小到准备性任务，例如只起草一份待审核的更新内容。

判断是否开放写入权限，可以直接看四个条件：能否定义目标状态，能否测试高概率失败场景，能否限制 Agent 权限，能否独立验证最终变更。任何一项缺失，都应该让 Agent 留在只读或草稿模式。

Quellix 会如何实现

如果目标是构建一个能够调用业务系统、同时不把模型自信度当作完成凭证的工作流 Agent，可以从 Quellix Labs 的 AI Agent 开发服务入手。实施时会先梳理任务及异常情况，只接入必需的 CRM、客服系统和 Slack 动作，再围绕真实业务系统定义验证规则。

以客服到销售的交接为例，Agent 可以读取被分配的工单，只获取判断所需的账户上下文，提出 CRM 更新方案，并且只有在记录变更得到确认后才发布 Slack 交接消息。敏感变更可以等待人工审批；被拒绝的写入应变成明确的异常记录，而不是虚假成功消息。评测用例应覆盖真实工单模式与策略边界，并经过审查后，Agent 才能从草稿模式进入有限写入模式。

一个实用的第一步，是挑一个工作流，在技术评审时准备五样东西：示例输入、Agent 允许读取的字段、允许执行的动作、能够证明任务完成的状态，以及必须转交人工处理的场景。拿到这些内容，就足以判断是否真的需要 Agent，还是一个更简单的集成方案更合适。

延伸阅读

• AI Agent 的边界不能只靠提示词规则
• Gemini Agent：集成系统仍然需要的控制措施
• AI 客服 Agent：任务分流、操作与升级

最初发布于 Quellix Labs。