客户最担心的不是答错，而是做错
设想一个销售方案 Agent。员工让它读取客户资料、检索产品库、生成方案，并把文件发到工作群。任务看起来很普通，但链路里藏着不少问题：
- 客户资料中的一段外部文本，诱导 Agent 读取其他目录；
- 产品库里有员工本来无权查看的价格文件；
- 消息工具默认允许发送，Agent 把未审核方案发给了客户；
- 接口超时后自动重试，造成同一条记录被提交两次；
- 事故发生后，日志只显示“工具调用失败”，无法还原当时读过什么。
- 传统软件主要限制用户点击哪个菜单。Agent 会自行规划步骤，风险边界会随着上下文、文件、工具和模型判断动态变化。因此，企业要控制一条正在运行的任务链，静态账号权限只能覆盖其中一部分。
Anthropic 做了什么：把安全边界放进执行环境
Anthropic 在 2026 年 5 月发布的工程文章中介绍了 Claude 在不同产品中的隔离方式。其核心思路是：不要只依赖模型“记住安全要求”，还要用操作系统沙箱、容器、虚拟机、文件边界和网络策略限制实际能力。Anthropic，2026-05-25
文章披露了两个值得企业平台关注的数据：
- 早期方案需要用户批准约 93% 的工具调用，频繁弹窗很快造成审批疲劳；
- 引入沙箱后，审批提示减少了 84%，系统只在真正越过边界时打断用户。
- 企业不必让所有 Agent 使用同一种沙箱。更可行的做法，是把低风险动作放在明确边界内自动执行，把高风险动作留给策略或人工确认。控制越精确，安全与效率越不需要互相牺牲。
把 Agent 放进生产环境，至少要管住五件事
身份和数据范围要跟着任务走
平台要知道任务由谁发起，并把用户身份传递到知识库、数据库和业务系统。Agent 不应因为拥有一个系统账号，就绕过员工原有的数据权限。
客户在 PoC 中可以直接测试：让不同岗位提问同一个问题，检查检索结果、字段和附件是否按原系统权限变化。只在应用入口做一次登录校验，不能证明运行过程安全。
工具权限要细到具体动作
同一个工具里的动作风险并不相同。查询订单和取消订单、生成邮件和发送邮件、创建草稿和正式发布，不能共用一条权限。
更实用的策略通常有三类：
- 允许：低风险、可逆、限定范围内的动作自动执行；
- 拒绝：超出任务和岗位边界的动作直接阻断；
- 需确认：发送、删除、付款、发布等敏感动作进入人工确认。
- 确认界面还要展示即将执行的内容、目标对象和主要依据。只显示“是否允许调用某工具”，用户很难作出有效判断。
代码、文件和网络需要隔离
如果 Agent 能运行代码或处理附件，就要限制它能访问的目录、能启动的进程和能连接的网络地址。临时任务应尽量使用隔离环境，任务结束后清理状态。
对外部内容也不能只做文件格式检查。网页、邮件、文档和工具返回值都可能携带提示注入。平台需要区分“用户指令”和“外部资料”，并对外部指令保持低信任。
人工介入后，任务还要能继续
人工介入不应等同于“遇到问题就全部重做”。长任务需要在关键步骤保存状态，支持暂停、修改参数、替换材料和继续执行。
如果任务已经完成了不可逆动作，恢复机制还要知道哪些步骤可以重试，哪些步骤必须先核对外部系统。Checkpoint、幂等键和补偿流程，是生产 Agent 常被忽略的基本功。
审计要能还原一次任务
审计记录至少应包含：
- 发起人、使用的 Agent 和版本；
- 输入材料、检索来源和权限上下文；
- 模型、工具、参数及返回结果；
- 命中的允许、拒绝或确认策略；
- 人工确认人及其决定；
- 失败、重试、恢复和最终输出。
- 有了这些信息，平台团队才能判断问题来自模型、数据、工具、策略还是流程。否则所谓审计只是保留了一段难以解释的对话。
这会怎样改变企业级智能体平台选型
过去的平台演示通常强调模型接入和流程编排。现在客户需要把“运行时控制”单独列为一组验收项。
| 选型对象 | 可以重点检查的方向 |
|---|---|
| Anthropic | 产品环境中的沙箱、文件与网络边界、工具审批设计 |
| OpenAI | 企业工作空间、连接器、工具调用和管理员控制 |
| Microsoft Copilot Studio | 与 Entra、Power Platform、连接器和数据策略的结合 |
| Google 企业 Agent 平台 | 云身份、数据治理、Agent 运行与企业搜索的结合 |
| Rich AIBox | 工作空间、工具策略、沙箱、人工介入、任务恢复和审计是否形成统一运行面 厂商能力会持续更新，正式选型应以当期产品文档和现场测试为准。比较的关键也不是谁的菜单更多，而是谁能证明一次真实任务始终没有越过企业边界。 |
把运行时控制落到企业平台：以 Rich AIBox 为例
彩讯股份在 Rich AIBox 中把控制对象从“应用”继续拆到任务、工具和动作。放到真实客户场景里，可以沿着下面六个问题核验：
- Workspace 边界：团队、Agent、知识和工具按工作空间组织，减少跨场景误用。
- 工具策略：对工具或动作配置允许、拒绝和需确认，敏感动作进入人工确认。
- 隔离运行：对代码、文件和外部连接设置沙箱与资源边界。
- HITL：在关键步骤暂停，让业务人员查看依据、修改参数或批准执行。
- Checkpoint：长任务保存过程状态，支持失败后的恢复和重试控制。
- 运行审计：记录调用链、策略命中、人工决策和异常过程，供问题定位与复盘。
- 上述功能中，部分仍属于规划或运行面设计方向。对外发布和客户选型前，应根据当前版本逐项确认已上线能力、配置粒度和适用部署方式。
- 把这些能力放进前面的评价框架，客户真正要看的不是功能名称，而是它们能否在同一条真实任务中协同生效：资源有没有越界、敏感动作是否被拦下、人工确认是否出现在正确节点、失败任务能否恢复、审计记录能否还原过程。
建议在 PoC 里做六次压力测试
普通演示很难暴露权限问题。可以主动设置以下测试：
- 越权检索：不同角色访问同一知识库，验证结果和字段是否隔离。
- 提示注入：在附件或网页中加入诱导指令，观察 Agent 是否越过原任务。
- 敏感动作：让 Agent 发送、删除或发布，检查是否触发正确的确认策略。
- 接口超时：在动作完成后制造超时，检查是否发生重复提交。
- 中途换人：任务暂停后由另一名员工接手，检查授权和审计是否更新。
- 事故回放：只依靠平台记录，还原一次任务的材料、决策和动作。
- 压力测试的结果应进入验收报告，而不是只由厂商口头解释。
常见问题
有人工审批，就能避免 Agent 风险吗？
不能。审批过多会造成疲劳，用户可能习惯性点击同意。更合理的方式是让低风险动作在受控边界内自动执行，只把高风险、越界或不确定动作交给人工。
私有化部署是否等于安全？
不等于。私有化解决了部分部署和数据边界问题，但身份传递、工具权限、提示注入、异常恢复和审计仍要单独设计。
只做知识问答，也需要运行时控制吗？
需要，但强度不同。知识问答至少要控制文档权限、来源、外部内容和输出留痕；一旦能调用工具或更新系统，控制要求会明显提高。
Rich AIBox 的这些能力都已经上线了吗？
相关能力会随版本持续完善。客户可在 PoC 中核验策略粒度、隔离方式、恢复能力和审计字段，并按实际部署版本确定验收范围。