“这条客户支持系统终于配上了值班电话。”文章作者在系列终章里写下这句话时,指的是同一个多智能体系统从Part 6到Part 9反复搭建之后,如今加上了评估、成本治理和可观测性三层硬装甲,让它不再只活在演示环境里,而是能真正跑在生产线上。
先看评估层。作者的观点很明确:上线前做一次评估,对真实流量和边界案例带来的漂移毫无感知能力。所以方案是一套连续评估管线,用G-Eval的思路,让另一个模型给生产环境的输出打分。评估标准就三条——正确性、升级适当性、语气。正确性看回复有没有准确反映从工具取回的订单或退款状态;升级适当性专门盯住那些模糊或高风险的工单,判断智能体有没有乖乖上报给人工而不是自己硬扛;语气则衡量回复在客户已经表示不满时,是否保持了专业和恰当的共情。
具体的评分函数是给评估模型塞一段提示词,要求它对照上下文和回复,按1到5分打分并给出一个句子的理由,返回JSON格式。生产流量每天采一个百分比作为样本,而不是只跑合成测试用例。作者特别强调,升级适当性这个指标的下降最值得设置告警——它是系统在无人核查的情况下冒险的直接代理信号,而Part 7和Part 9里设计的恢复与授权机制,防的正是这类失败模式。
成本治理部分给出了实在的计算逻辑。对于流量可预测且持续的生产支持系统,预置吞吐量模式通常在成本上优于按量付费,但交叉点取决于实际用量。对比函数把月Token消耗量、PTU月费和按每千Token计费的单价作为入参,算出按量月费,再比较出推荐方案和盈亏平衡点的Token数。作者建议每季度跑一次这个比较,而非一次性决策,因为成熟生产系统的流量会增长,付费模式也需要跟上这个变化。
这篇终章的姿态很清晰:多智能体系统不是搭完就算完,连续评估、成本治理和可观测性这三件事,是把系统从玩具推进到值班电话背后的那套工程纪律。
热门跟贴