AI Agent 风险已经从“回答什么”延伸到“能做什么”：产品研发应重画控制边界

本文采用的是基于所列项目与资料的工作性理解，不是行业统一定义：当生成式 AI 仅负责生成内容时，团队主要审视输入与输出；当它被嵌入能规划并执行任务的软件系统，并获得记忆、工具调用、身份凭证和外部 API 连接时，风险对象就延伸为一条完整的行动链路。

这不意味着所有 Agent 都已具备高自主风险。提交给 NIST 的一份评论认为，当前 Agent 在代理型任务上的表现仍显著低于人类水平，因而当下自主能力带来的风险较低；但该评论同时指出，能够在无人参与下创建并执行计划的软件嵌入场景，可能直接造成伤害。[1] 对产品团队而言，更实用的判断不是给 Agent 贴上“安全”或“危险”的标签，而是逐项确认：它能读取什么、决定什么、调用什么，以及其动作能否被限制、复核和追溯。

判断一：风险评估单位应从单次回答，改为一次可追溯的任务执行

一个面向客服、运营或内部协作的网站 Agent，表面上可能只是在对话框中回答问题；但一旦它能检索客户资料、写入工单、调用营销接口或更新业务状态，真正需要评估的是从用户请求到最终动作的全程。

本文建议将一次 Agent 任务拆为六个节点：

1. 请求进入：用户、系统事件或定时任务如何触发；
2. 上下文组装：检索了哪些知识、记忆和业务数据；
3. 推理与决策：模型提出了哪些计划和参数；
4. 工具调用：实际选择了什么 API、插件或 MCP 服务；
5. 外部副作用：是否产生写入、发送、删除、支付、发布或权限变更；
6. 结果回传与留痕：谁收到了结果，能否还原执行过程。

AWS 对 Agentic AI 威胁的梳理将风险点覆盖到输入处理、记忆读写、工具调用和输出生成等环节；其文章特别提到记忆投毒、工具滥用和权限泄露，并指出这些单 Agent 层面的风险可能在多 Agent 的信任关系、依赖关系和级联故障中扩大。[2]

因此，产品需求文档不应只写“接入大模型”和“调用某工具”，还应为每个工具动作标注：读取或写入、影响范围、是否可逆、是否需要用户确认、失败后的补偿方式。这会把抽象的安全讨论变成可测试的产品边界。

判断二：权限不是 Agent 的静态属性，而应绑定到任务、用户和动作

对话产品通常只需要内容生成权限；执行型 Agent 则可能触及邮件、数据库、终端或内部业务系统。提交给 NIST 的评论将“自主性”视为生成式 AI 的新兴风险之一，并以模型自主发现和利用漏洞的能力作为需要关注的自治攻击能力示例。[1]

我们的建议是，不要为一个 Agent 配置笼统的“业务管理员”身份，而是实施三层权限收缩：

这里的关键是：模型生成的调用意图不等于已获授权的业务指令。工具网关或业务后端应独立校验身份、资源归属和参数边界，不能仅因模型输出了格式正确的函数调用，就直接执行。

对于具有明显外部副作用的操作，可以考虑设置“计划—确认—执行”三段式交互：Agent 先展示将要调用的系统、对象和影响；用户或指定审批人确认后，再由后端发起实际调用。对于低风险、可逆的内部动作，则可以保留自动化空间，但仍需保留撤销与异常处理入口。

判断三：记忆、工具和第三方连接，应被当作三个独立攻击面管理

Agent 的能力并不只来自模型。它还来自长期记忆、知识库、外部 API、插件、代码依赖和工具服务器。R Street Institute 的研究指出，Agent 对第三方数据分析服务的依赖会增加风险：受损数据集、不安全的 API 依赖或不足的监控，可能让攻击者在不易被发现的情况下篡改 Agent 操作；第三方软件供应链任何一环受损，也会损害 Agent 的性能与可信度，并增加修复和恢复难度。[3]

针对网站、小程序和企业工作台，本文给出以下工作性区分：

• 记忆不是可信指令库。 用户偏好、历史摘要和检索内容应与系统策略分离。写入长期记忆前，可增加来源、归属用户、有效期和人工确认等字段。
• 工具描述不是安全策略。 即使工具说明中写明“仅用于查询”，后端仍应禁止越权参数、跨租户对象和未授权写操作。
• 外部连接不是普通配置项。 每新增一个 MCP 服务、插件或第三方 API，实质上都新增了代码、数据与身份依赖。

AWS 的文章将 MCP 生态描述为高风险、高速度、零信任的软件供应链：客户端可能连接到匿名开发者创建和托管的 MCP 服务器，而这些服务的代码质量、安全实践和维护状态并不一致，且通常缺少官方认证、审计或信任背书。[2] 这一描述并不代表所有 MCP 服务都不可信，但足以提示研发团队：连接器上架与依赖引入应走与第三方软件包相近的审查流程。

可以考虑建立一份“工具准入清单”，至少记录服务提供方、代码或接口版本、数据去向、所需权限、维护责任人、日志能力、下线方式和替代方案。未被批准的工具不应出现在生产环境 Agent 的可调用列表中。

判断四：把“是否成功回答”升级为“是否安全完成任务”的测试目标

传统大模型评测常关注准确率、相关性和幻觉；执行型 Agent 还需要验证它在异常输入、错误上下文和工具失败时是否会越过边界。

我们的建议是在上线前为每个高风险工具准备一组任务级测试，而不只是问答测试：

flowchart LR
A[用户请求或系统事件] --> B[上下文与记忆筛选]
B --> C[Agent 生成计划]
C --> D{策略与权限校验}
D -- 拒绝或需确认 --> E[说明原因/进入审批]
D -- 通过 --> F[受控工具调用]
F --> G[业务后端二次校验]
G --> H[执行、审计与告警]

测试可覆盖以下场景：

• 用户输入中含有与原任务无关的指令，Agent 是否改变工具目标；
• 检索文档中包含诱导性内容，Agent 是否把它当作更高优先级的操作命令；
• 工具返回异常、超时或只返回部分数据时，Agent 是否编造“已完成”；
• 请求试图访问其他用户、其他门店或其他租户的数据时，后端是否拒绝；
• Agent 连续重试时，是否造成重复发送、重复创建或重复扣减等副作用；
• 多 Agent 交接任务时，后续 Agent 是否继承了超出必要范围的上下文和权限。

测试结果应当进入发布门禁，而非只留在研发演示中。特别是对写入、发送、删除和跨系统同步等动作，建议将“策略拒绝是否有效”“审批是否绕过”“审计是否完整”设为与功能成功率同等重要的验收项。

判断五：治理界面应成为 Agent 产品的一部分，而不是上线后的补丁

如果运营人员无法看到 Agent 用了什么数据、调了什么工具、代表谁操作，团队就很难定位异常，也难以决定是否该扩大自动化范围。AWS 的文章提到，集中式网关可用于 Agent 与外部工具、API 和服务的集成治理，并将会话级身份隔离与访问控制作为相关能力之一。[2]

不必一开始就建设复杂平台，但生产级 Agent 至少应提供四类可见性：

1. 任务记录：触发者、任务目标、执行时间、最终状态；
2. 工具记录：调用的工具、参数摘要、响应状态和重试次数；
3. 授权记录：使用的用户或服务身份、权限范围、审批结果；
4. 异常记录：策略拒绝、越权尝试、工具失败、人工接管与撤销结果。

对于多租户 SaaS、小程序后台或企业门户，建议将这些记录按租户和会话隔离，并避免在日志中无差别保留敏感原文。日志的目的不是收集越多越好，而是支持事后还原一次任务为何发生、影响了谁、能否撤回。

结语：先收窄行动半径，再扩大自动化深度

AI Agent 的价值通常来自连接真实系统，而风险也恰恰在连接之后出现。基于本文的工作性理解，产品团队不必等待“完美治理框架”才开始试验；更可行的路径是先把 Agent 限定在低权限、低副作用、可撤销且可审计的任务中，再根据测试和运行记录逐步开放更复杂的工具与流程。

一个值得写进产品路线图的优先级是：先完成身份隔离、工具白名单、参数校验、人工确认和审计留痕，再讨论跨系统自动执行与多 Agent 协作。这样，Agent 才不只是会调用工具的界面能力，而是能够被产品、研发和运营共同管理的数字执行单元。