你们如何处理AI代理做出的承诺?我经常遇到这个问题
摘要
作者描述了一个问题:AI代理做出承诺但未跟踪履约情况,提出了一个使用状态机的问责层,并向他人征求生产环境的解决方案建议。
我从事AI代理的开发大约一年了,一直遇到同一个问题:代理做出承诺,但没有任何机制跟踪这些承诺是否实现。例如:“我将在周五前发送报告。”“我明天会跟进客户。”“我会检查并回复你。”虽然代理的输出会被记录,但这并不能真正告诉你承诺是否最终履行。等到出问题时,你通常需要翻阅旧的跟踪记录来重建事件。而且代理本身显然不是这方面可靠的真相来源。我一直在试验一个问责层,它从代理输出中提取承诺,并通过状态机跟踪它们:open → due → overdue → fulfilled/failed。当承诺逾期或失败时,它还可以触发Webhooks。我仍不确定的部分是提取/路由的阈值。目前,任何置信度低于0.92的都会进入pending_review状态,而不是自动跟踪。我在想这是否是正确的做法,或者置信度阈值是否是处理这个问题的最佳方式。对于那些运行生产环境代理的人:你们现在是如何处理这个问题的?只是记录输出并手动审查吗?在应用数据库中跟踪承诺?使用其他可观测性系统?或者专门为这个问题构建了什么?我真的很想知道这是否是其他人遇到的问题,还是我在过度工程化一些无关紧要的东西。如果有人想深入了解,我很乐意分享数据模型/文档。
相似文章
谁已经在部署能做出真实承诺的智能体?
讨论团队如何处理AI智能体在未经人类批准的情况下做出真实承诺,寻求例外情况及关于责任和法律摩擦的见解。
我们的大部分“智能体”问题实际上是工作流/状态问题
一位开发者讲述,构建AI智能体时的许多挑战实际上源于工作流和状态管理问题,而非模型智能,强调了稳健的状态处理和可观测性的必要性。
在生成环境中运行AI代理:如何控制它们实际允许执行的操作?
一位开发者寻求关于如何在生产环境中控制和约束AI代理行为的建议,特别是当它们与真实系统(如数据库和客户数据)交互时,询问当前实践情况以及这是否是一个已知的难题。
AI代理即将制造一个无人愿意承担的责任问题
随着AI代理从提供答案转向在实际工作流程中采取行动——例如处理付款、客户数据和审批——其错误缺乏明确问责制成为了一个关键问题。
坦白说:在实际生产中,你们是如何处理AI代理可审计性问题的?
一位从业者探讨了在生产环境中为AI代理实施审计跟踪的挑战,提及了一项供应商解决方案,并征求社区关于实际部署情况的意见。