你们在生产环境中如何处理代理的不可逆操作?我放弃了提示词,构建了一个外部风险门控。
摘要
作者描述了一个为生产环境AI代理构建的外部动作前风险门控,用于防止发送错误消息或删除数据等不可逆操作,并分享了一个真实案例,其中该门控阻止了一次不合规的短信活动。
这是针对在生产环境中运行代理的人的真诚提问,同时分享一下我最终采用的方法。最让我担心的失败模式不是幻觉——而是不可逆性。一个代理发送错误的汇款、删除错误的表,或者发出不合规的消息。这些都无法回滚。而在系统提示中写“小心”也无济于事:模型在正确时和即将搞垮生产时一样自信。我得到的结论是:检查必须存在于代理之外——一个代理无法说服自己的评分器,位于“决策”和“执行”之间。于是我构建了一个小的动作前门控。在任何不可逆操作之前,它对提议的动作及上下文进行评分,在亚秒级返回一个0–100的风险评分、GO/CAUTION/STOP判定以及具名的危险标志。我在自己的编排器中将这些映射到升级层级:GO=继续,CAUTION=人工审批,STOP=暂停并告警。它在我的多智能体栈中运行。上周的真实案例:我的外联代理即将向一个抓取的列表发送包含4,200名收件人的短信活动。门控返回STOP/92——标记了TCPA违规和意图不匹配(我配置为仅限已选择加入的联系人,但输入来源是抓取)。它在任何消息发送前自动停止。我真正好奇的两点:1. 你们目前如何处理动作前安全——硬编码白名单、人工介入、评估门控,还是只能指望运气?2. 像这样的外部评分器在您的用例中会在哪些方面失效?延迟开销、误报阻止了合法操作、代理绕过它——哪个会最先出问题?如有需要,我很乐意分享我构建的内容(将按照规则3在评论区提供链接)。
相似文章
AI代理在生产中执行的最可怕的“失控行为”是什么?
讨论AI代理在生产中执行的最可怕的失控行为,强调例如因API超时导致双重退款等风险,以及需要稳健的测试流程。
如何阻止编码代理接触生产数据?
讨论防止AI编码代理意外修改生产数据库的策略,主张使用只读访问、沙盒环境和审批关口,而不是仅仅依赖提示。
在生产环境中让智能体采取真实操作,你最担心的是什么?
一位开发者分享了在部署能够执行真实操作(如API调用和数据操作)的AI智能体时的担忧,并向社区询问他们的恐惧以及诸如护栏和人工审批等缓解策略。
人类总会打破规则,AI亦然:论“硬性门禁”的必要性
本文分析了 PocketOS 一起由 AI 代理误删生产数据库的事件,主张采用验证器独立性和可逆性检查等“硬性门禁”,而非单纯依赖提示词工程。
你是如何让非工程师团队成员在生产环境中编辑提示词的?
作者讨论了在受监管领域中允许领域专家对AI代理的生产提示进行编辑所面临的挑战,并分享了一种使用带有GitHub后端的提示编辑器进行版本控制的解决方案。