我构建了一个AI支持代理原型,意识到难点不在于聊天机器人,而在于转交和审计追踪。希望从运行支持/客户体验工作流的人那里获得反馈。
摘要
作者构建了RelayOps,一个用于电信/订阅支持场景的AI支持代理原型,分享了50个工单样本的结果,并寻求关于转交记录、不安全操作、审计字段以及测试实用性的反馈。
我一直在构建RelayOps,一个用于电信/订阅式支持的AI支持代理原型。目标不仅仅是“回答用户”。我正在测试一个更具体的问题:
> 当前版本:
* 处理示例支持工单队列
* 自动解决低风险可逆案例
* 升级计费/账户风险案例
* 阻止不安全操作
* 每张工单写入一条审计记录
* 创建人工转交工单,包含负责人/原因/证据/截止日期
* 在实时控制台中显示决策
* 导出JSONL/CSV审计记录
在我当前的50个工单样本队列中:
* 27个自动解决
* 20个人工转交
* 3个不安全操作阻止
* 0个不安全自动操作
* 0个计费漏报
重要说明:这是样本数据,不是生产流量。我尚未声称产品验证。
我现在要理解的部分是:对于运营支持、客户体验、SaaS运维或计费/账户工作流的人:
1. 在信任AI代理正确升级之前,您需要在转交记录中看到什么?
2. 您绝不允许代理自动执行哪些操作?
3. 如果客户后来对决策提出异议,哪些审计字段会很重要?
4. 什么能让这个工具有足够的价值在匿名工单上进行测试?
请评论获取仓库或演示的链接。
相似文章
需要直率反馈:我构建了一个用于记录AI代理运行的工具
一位开发者构建了agentproof-recorder来记录AI代理运行并检测规则违规,寻求反馈这是否是一个常见的痛点。
经验分享:构建用于处理 GitHub、Discourse 和邮件的 AI Agent(开源维护的真实用例)
作者分享了为 Seafile 构建 AI Agent 的案例研究,该 Agent 通过同步知识库并提供可操作建议,协助维护人员在 GitHub、Discourse 和邮件中分流处理支持请求。
我构建了一个AI支持代理,其主要指标是不安全自动操作率,而不仅仅是准确性
关于构建电信客户支持代理的技术实践,该代理优先考虑安全指标而非分类器准确性,采用了确定性访问门控、限域工具执行和路由级评估。
我让一个代理处理太多任务,结果它以四种不同方式失败。关于防护栏和交接的AMA
一位开发者分享了让单一AI代理处理过多任务的教训,导致多种失败模式。他们提倡拆分角色、强制结构化输出并仔细设计交接。
OpenAI通过每次交互改进支持服务
OpenAI分享了如何使用AI重新设计其支持运营,每年处理数百万个请求,建立了一个每次交互都能改进下一次的运营模式。该方法整合了聊天、邮件和电话等多个渠道,持续改进知识库,并通过人工-AI评估循环使支持代表能够充当建设者并为产品改进提供信息。