在生产环境中运行 AI Agent 需要具备什么？

在生产环境中运行 AI agent，需要限定访问权限和执行范围，确保写入安全、故障后可以持久恢复、生成的代码隔离运行，还要具备端到端追踪、可重复评估，以及经过验证的停止机制。一次有人监督的成功演示，几乎无法证明这些控制措施已经到位。

当 agent 开始处理开发者没有预先编写的输入，而且不再有人全程盯着每一步时，系统才真正进入生产阶段。发布门禁应该重点测试会失败、会重复执行或需要权限的路径。

先建立身份，再开放自主执行

为每个 agent、部署或会话提供能标识调用方的凭据，并限制其可访问的租户、资源和操作。由数据所属的服务强制执行这些限制。工具描述和系统提示词只能为模型提供上下文，不能替代后端授权。

OWASP 关于过度代理权的指南建议尽量减少工具功能、权限和自主程度。可以按以下顺序落实：移除工作流不需要的工具，收窄其余工具背后的凭据权限，再为高影响操作增加事前审批。

AI agent 安全指南进一步介绍了凭据范围、密钥处理和审计归属。

在代码中限制单次运行

在服务端强制限制单次运行的墙上时间、模型费用、工具调用次数、重复尝试次数、并发运行数和输出大小。对于会写入数据或产生费用的工具，限制应更加严格。授权或校验反复失败时应直接停止，而不是继续重试。

预算耗尽后，模型仍可能请求下一步操作，运行时必须拒绝。这也说明全局速率限制并不够：它也许能拖慢失控的工作流，却无法限制该工作流最终造成的全部损失。

让每项外部影响都可恢复

每个可重试的写入都需要一个逻辑操作 ID 或幂等键。服务端保存操作结果，并在相同操作再次发起时返回原结果。客户端超时后，应先查询操作记录，再决定是否重复执行。

每次确认外部操作成功后都要写入检查点。如果进程在发出邮件或创建部署后失败，恢复后的工作流应从该步骤之后继续，而不是重新执行。

Temporal 的持久执行文档解释了持久化工作流状态如何抵御进程故障。应用仍需要幂等活动，因为外部服务接受请求后，worker 依然可能发生故障。

隔离生成或不受信任的代码

Agent 生成的代码应在应用进程之外运行。沙箱需要明确规定：

• 哪些文件系统路径存在、哪些可以持久保留；
• 进程可以访问哪些主机和协议；
• 注入哪些密钥，以及保留多长时间；
• CPU、内存、进程数量和墙上时间限制；
• 运行结束后产物与日志的保留策略。

仅使用容器并不能回答这些问题。AI agent 沙箱指南将每项边界都转化为可执行的测试。

追踪决策直至其实际影响

用一条追踪记录串联用户请求、模型调用、检索到的上下文、工具选择、策略决策、工具执行和下游 API 工作。记录稳定的租户、agent、运行、工具调用和操作标识符，并排除凭据及敏感工具输出。

OpenTelemetry 的 GenAI 约定定义了模型、agent 和工具活动的字段。以此为基础，再加入产品自身的标识符，才能回答是谁修改了哪个资源。

每次变更发布前评估行为

固定一小组有代表性的任务，其中应包含预期工具选择、禁止执行的操作、审批节点、恢复场景和验收标准。模型、系统提示词、工具描述、权限、重试策略或记忆行为发生变化后，都要重新运行这组任务。

对于受模型随机性影响的用例，应重复运行。一次成功只能算一个样本，不能代表成功率。Agent 评估指南介绍了如何结合确定性断言和模型判定的输出。

定义人工中断流程

系统应能在高影响操作前暂停，并向审核者展示确切的资源、操作、范围和预期影响。即使 agent 状态混乱或无法响应，运维人员也必须有一条可用的处置路径：

1. 停止新的运行。
2. 中断当前运行。
3. 撤销受影响的凭据。
4. 找出本次运行触及的所有资源和操作。
5. 恢复、补偿或升级处理已经完成的影响。

请在隔离环境中演练这条路径。从未实际执行过的运行手册仍只是一个假设。

使用发布门禁，而不是就绪评分

综合评分可能掩盖某项缺失的控制措施。对当前要发布的工作流，应将每一行分别判定为通过或失败。

下方的提示词会为风险最高的工作流生成这份门禁清单，同时避免把生产环境带入测试。