关于 Agent 具体的量化指标工具

Agent 项目最容易露馅的地方，不是会不会调模型，而是"你怎么知道它做得好"。

从一次被问住的经历说起

前段时间面试，面试官问我的 Agent 企业平台项目："具体是怎么量化评估的？"我答得磕磕绊绊，对方反馈很直接：项目有点 demo 级。

回来后我把评估模块从头到尾重新拆了一遍，越拆越确信一件事：评估是 demo 与工程之间的分水岭。功能跑通谁都会，但说得清指标、拿得出数据、形成得了闭环的，没几个。这篇把我复盘的结论整理出来：先认识两个业内现成的量化评估工具，再讲我是怎么在 Java 技术栈里自研出同一套能力的。

两个现成工具：LangSmith 与 Langfuse

LangSmith 是 LangChain 公司的官方平台，相当于给 LLM 应用配的全套质检流水线：

• Tracing：把每次调用的模型、工具、检索链路完整记录下来；
• Datasets：把测试问题管理成数据集；
• Experiments：批量跑分，版本间横向对比；
• Evaluation：规则断言或 LLM-as-judge 打分；
• 外加 prompt 版本管理和线上监控。

它以商用 SaaS 为主，SDK 优先支持 Python 和 JavaScript。

Langfuse 是它的开源对标物，核心代码 MIT 许可。最大的差异在接入方式：走 OpenTelemetry（OTLP）上报，语言无关，Java 应用同样能接；支持 Docker 自托管，可以私有化部署。

两者的核心差异，一张表说清：

我为什么选择自研

我的项目是 Java 技术栈、面向企业私有化交付，这两条约束直接排除了 LangSmith：SaaS 进不了客户内网，Python SDK 也接不进 Spring 服务。Langfuse 理论上可行，但我的 judge prompt 要按业务定制，评估数据还要和权限、审计体系打通，权衡之后我在应用层自研了评估模块。

这不是重复造轮子，而是私有化交付场景下的主动选择。面试里被问"为什么不用现成工具"，标准答法就是三段式：先讲约束，再讲权衡，最后讲你的方案补齐了什么。

评估到底评什么：三层拆解

第一层：成本与性能

token 用量必须取模型返回的真实 usage，不能靠估算；延迟记录到 P95。这些指标通过事件订阅旁路采集，不侵入 Agent 执行主链路。我实测一轮真实对话，token 用量 612/108（输入/输出），耗时和成本都留在了审计日志里。

第二层：质量双轨断言

固定测试集批量跑分，每个用例要过两道关：

• 规则断言：contains 判答没答、not_contains 判答偏没、数值断言判答对没；
• LLM-as-judge：用另一个 Agent 当裁判，固定 judge 模型与 prompt，它不生成答案，只输出分数、是否幻觉、一句话评语，保证结果相对可对比。

双轨的必要性有实锤：有个用例规则断言全过，judge 却识别出回答里"编造了不存在的差旅标准"，打了 4 分。只靠规则断言，这种答得流畅但事实编造的情况就漏网了。

第三层：坏例回归闭环

fail 的用例自动落盘进坏例集，带幻觉标记。之后每次改 prompt、换模型，都重跑测试集加坏例集，防止同样的错再犯。我专门设计了一个对抗用例：故意问知识库里没有的食堂菜单，Agent 编造了"周一到周五的菜单"，被 not_contains 断言命中、judge 标记幻觉，自动沉淀进坏例集——回归集从此多了一条防线。

一组实测数字

• 评估通过率：初版 5 个用例只过 2 个，修断言稳健性后 5/5；
• LLM-as-judge：抓出 1 个规则断言漏掉的编造案例；
• token 真实采集：tok=612/108，来自模型返回的 usage 字段；
• 延迟：评估批次内 P95 约 3 秒；
• 坏例沉淀：1 条对抗用例自动落盘，幻觉标记为真。

写在最后

量化评估不是加分项，是 Agent 工程的及格线。判断一个 Agent 项目是不是 demo 级，就看三点：有没有固定测试集、有没有可对比的指标、有没有回归闭环。工具可以选 LangSmith、Langfuse，也可以像我一样自研，但思路必须先立住：先有测试集，再有双轨断言，最后让坏例回流。被问住一次不可怕，可怕的是复盘之后还是答不出来。