热闻岛
返回全网热点

智能体设计模式:评估与监控 Evaluation & Monitoring

5小时前12 阅读
智能体设计模式:评估与监控 Evaluation & Monitoring配图
没有评估的 Agent,不能进生产 Agent 做得越复杂,越不能靠感觉上线。 普通聊天机器人,最多看最后回答好不好。Agent 不一样。它会路由、规划、调工具、查知识库、转人工、触发护栏。任何一步错了,最后答案都可能看起来“挺像那么回事”
智能体设计模式:评估与监控 Evaluation & Monitoring配图

没有评估的 Agent,不能进生产

Agent 做得越复杂,越不能靠感觉上线。

普通聊天机器人,最多看最后回答好不好。Agent 不一样。它会路由、规划、调工具、查知识库、转人工、触发护栏。任何一步错了,最后答案都可能看起来“挺像那么回事”,但实际已经跑偏。

所以,Agent 的评估与监控,要同时看两件事:结果对不对,过程有没有走对。

智能体设计模式:评估与监控 Evaluation & Monitoring配图

1. 为什么 Agent 不能只看最终答案?

因为 Agent 的错误常常藏在中间步骤里。

用户问“帮我查一下退款进度”。最终回复可能很自然:你的退款正在处理中。看起来没问题。但实际链路可能是错的:它没有校验身份,没查订单,只是凭上下文猜了一个答案。

这种系统如果上线,风险很高。客服场景会误导用户。金融场景会误判数据。生产运维场景可能执行错误操作。

评估与监控的核心,就是把 Agent 的黑盒过程拆开看。看它是否选对工具,是否传对参数,是否遵守权限,是否基于证据回答。

智能体设计模式:评估与监控 Evaluation & Monitoring配图

2. 评估什么?看五层

Agent 的评估不是一个指标能解决的。要分层看。

智能体设计模式:评估与监控 Evaluation & Monitoring配图

第一层:任务是否完成。用户的真实目标有没有达成。

第二层:最终答案是否正确。有没有胡说,格式是否可用。

第三层:工具轨迹是否正确。有没有选错工具、跳过步骤、参数传错。

第四层:RAG 是否可靠。检索内容是否相关,回答是否忠于上下文。

第五层:安全和成本是否可控。有没有越权,延迟和 Token 是否失控。

一句话:答案只是结果,轨迹才是证据。

3. 监控什么?看真实运行

离线评估解决“改完会不会变差”。线上监控解决“真实用户那里发生了什么”。

生产环境里,最重要的是 Trace。Trace 就是一次 Agent 运行的完整录像。里面应该能看到:用户输入、模型调用、工具调用、工具参数、工具结果、护栏命中、人工介入、最终回答、耗时和成本。

没有 Trace,出问题只能猜。有 Trace,问题可以定位到具体步骤。

智能体设计模式:评估与监控 Evaluation & Monitoring配图

4. 一个完整流程怎么跑?

先选样本。用真实用户问题、失败问题、边界问题,做成评估集。

再定义期望结果。不只写预期答案,还要写预期工具调用轨迹。

然后跑评估。每次改 Prompt、模型、工具或路由,都要重新跑。

接着设门禁。指标低于阈值,不允许上线。

上线后采样监控。抽取真实 Trace,持续看失败率、延迟、成本和安全命中。

最后回灌样本。线上失败案例进入评估集,下次发布必须通过。

这就是 Agent 的质量飞轮:线上发现问题,离线固化问题,下一次发布不再重复犯错。

5. 评估系统本质是一条数据链路

不用先纠结框架。先看运行逻辑。一个可上线的 Agent,至少要有三块能力。

Trace Collector:采集完整执行链路。每个 run_id 下记录模型、工具、参数、结果、耗时、Token。

Evaluator:对 Trace 和最终答案打分。既可以规则判断,也可以 LLM-as-a-judge。

Monitor:把指标做成看板和告警。任务成功率下降、工具失败率上升、成本异常,都要能发现。

智能体设计模式:评估与监控 Evaluation & Monitoring配图

6. 案例:退款客服 Agent 怎么评估

用户说:订单损坏了,帮我申请退款。

这个 Agent 不能直接退款。它必须按业务链路走:先校验身份,再查订单,再判断退款规则,最后才决定退款或拒绝。

智能体设计模式:评估与监控 Evaluation & Monitoring配图

这类场景的评估重点不是“回复好不好听”,而是:

有没有先做身份校验。

有没有调用 lookup_order 查询订单。

有没有把正确的 order_id 和 user_id 传给工具。

退款金额是否符合规则。

如果订单不满足条件,是否拒绝并给出清楚原因。

如果风险过高,是否转人工审批。

这个案例能说明 Agent 评估的重点:业务链路必须可验证。

7. 常用指标怎么选?

指标不要贪多。先抓住最关键的。

任务成功率:用户目标是否达成。

工具调用正确率:工具选得对不对。

参数正确率:工具参数有没有传错。

轨迹匹配率:是否按照预期步骤执行。

回答准确率:最终回复是否正确。

RAG 忠实度:回答是否被检索上下文支持。

安全命中率:是否触发越权、敏感信息、危险操作。

平均延迟:一次任务多久完成。

单次成本:模型和工具调用花了多少钱。

研发阶段更看轨迹。上线阶段更看趋势。出现异常后,再回放 Trace 定位具体步骤。

8. 容易踩的坑

只评最终答案,不评工具轨迹。结果看起来对,过程可能已经错。

只用人工感觉判断,没有稳定评估集。每次改动都像赌博。

评估集太干净,没有真实失败样本。上线后问题才暴露。

没有记录工具参数。工具调了,但不知道参数是否正确。

没有发布门禁。评估只是看看,不影响上线。

没有线上回灌。线上摔过的坑,下次还会再摔。

9. 上线前检查清单

智能体设计模式:评估与监控 Evaluation & Monitoring配图

总结

Agent 不是普通问答系统。它会决策,会调用工具,会改变外部状态。能力越强,越要可评估、可监控、可追踪。

离线评估负责上线前拦截问题。线上监控负责上线后发现问题。Trace 负责还原真相。评估集负责防止问题复发。

真正能进生产的 Agent,不是“看起来聪明”,而是“每一步都有证据,每一次变更都能验证”。

要点速读

没有评估的 Agent,不能进生产 Agent 做得越复杂,越不能靠感觉上线。 普通聊天机器人,最多看最后回答好不好。A

  • 没有评估的 Agent,不能进生产 Agent 做得越复杂,越不能靠感觉上线
  • 普通聊天机器人,最多看最后回答好不好
  • A