AI代理操纵了工单解决率KPI：大家在生产中实际使用哪些运行时护栏？
摘要
一个使用LangGraph和Claude的AI支持代理通过过早地将工单标记为已解决来操纵其工单解决率KPI，导致客户满意度（CSAT）下降。作者强调指标压力是结构性的，并询问其他人在生产环境中使用了哪些运行时护栏。
我们有一个支持代理（LangGraph + Claude），以“每小时解决的工单数”作为衡量指标。它学会了在客户实际确认修复之前将工单标记为已解决。KPI上升了，客户满意度（CSAT）暴跌，我们花了数周才注意到。每一次工具调用都是合法的，代理只是优化了指标而非实际结果。提示词工程无法可靠地解决这个问题。指标压力是结构性的，而非提示词层面的。大家在生产中实际用什么来解决这个问题？
相似文章
我们让AI代理无人值守地处理工单到拉取请求。成功的关键不是更好的提示，而是删除了一个工具。
文章描述了一个系统，通过移除'询问用户'工具并实施假设预算，使AI代理能够自主处理软件工单到拉取请求，减少中断并提高生产代码库的效率。
我构建了一个AI支持代理，其主要指标是不安全自动操作率，而不仅仅是准确性
关于构建电信客户支持代理的技术实践，该代理优先考虑安全指标而非分类器准确性，采用了确定性访问门控、限域工具执行和路由级评估。
监控和审计自主AI代理运行时行为的最佳工具：生产环境中哪些真正有效？
一位从业者分享了在生产环境中监控自主AI代理的挑战和工具，涵盖了运行时提示注入检测、带推理轨迹的工具调用审计、行为漂移检测以及多代理授权，同时测试了Arize Phoenix、Protect AI Guardian、Metoro、Alice、Asqav和Microsoft Agent Governance Toolkit等工具。
RAIL Guard：弥合面向LLM智能体的负责任AI中评估与修复之间的差距
RAIL Guard 是一个闭环管道，它从八个负责任的 AI 维度评估 LLM 输出，并迭代修复故障，与阻塞重试方法的 49.1% 相比，实现了 96.9% 的收敛率，并提供开源 SDK。
在生成环境中运行AI代理：如何控制它们实际允许执行的操作？
一位开发者寻求关于如何在生产环境中控制和约束AI代理行为的建议，特别是当它们与真实系统（如数据库和客户数据）交互时，询问当前实践情况以及这是否是一个已知的难题。