为管理生产环境 AI 智能体的工程师而写
摘要
一篇工程领域的讨论，探讨如何在 AI 智能体已经部署到生产环境后修改它的权限和授权范围，对比了配置部署、IAM/RBAC、Cedar 和 OPA 等策略引擎，以及网关/代理层等不同方案。
能否在不修改智能体本身的情况下，改变 AI 智能体被允许执行的操作？
更具体地说，当一个智能体已经在生产环境中运行后，如何修改它的授权范围？
我看到的一些方案：
- 修改代码/配置 → 部署/重启 → 获得新行为
- IAM / RBAC / 权限管理
- Cedar / OPA / 其他策略引擎
- 在智能体与其工具之间引入网关 / 代理层
- 还有其他方案吗？
举个例子：该智能体可以执行退款操作。目前任何超过 500 美元的退款都需要审批。明天这个阈值需要调整为 300 美元。该如何处理？
更重要的是：非工程师能否完成这项修改，并使其立即生效？
相似文章
你们当中那些在生产环境中运行AI代理的人——实际上是如何管理它们的权限的？
本文探讨了工程师如何管理生产环境中AI代理的权限，强调了普遍存在的权限过大和缺乏审计追踪的问题。
是否应允许AI智能体直接部署或更改生产资源？
关于是否应允许AI智能体直接部署或更改生产资源，或者是否总是需要人工批准（尤其是对于小团队）的讨论。
如何防止AI代理在生产环境中采取意外或有害行动
一位开发者探讨了在不造成意外损害的情况下将AI代理部署到生产环境的挑战，并寻求关于最小权限、影子模式、速率限制和审批工作流程等控制机制的建议。
在生成环境中运行AI代理：如何控制它们实际允许执行的操作？
一位开发者寻求关于如何在生产环境中控制和约束AI代理行为的建议，特别是当它们与真实系统（如数据库和客户数据）交互时，询问当前实践情况以及这是否是一个已知的难题。
你们在生产环境中如何处理AI代理工具调用的授权？
本文讨论了在生产环境中处理AI代理工具调用授权所面临的挑战，包括上下文漂移和多轮不一致等问题，并请求社区对有效的架构模式提供反馈。