AI Agent生产环境失败？四步构建评估体系

为什么很多AI Agent在演示时表现惊艳，一到生产环境就问题频出？Google工程师Dani在AI Agent Clinic节目中，与开源开发者Matt一起，用一场60分钟的实战演示给出了答案：缺少系统化的评估体系。他们以文档生成Agent（Docs Agent）为例，展示了如何用四个步骤从零搭建评估流程，并让一个基于LangGraph的Agent在部署前暴露出真实的质量问题。

评估缺失：Agent上线的隐形陷阱

Matt是开源文档工具Docs Agent的开发者，这个基于LangGraph构建的Agent能自动分析GitHub仓库、发现文档漏洞并生成修复PR。Dani在演示中坦言："如果让我来评估你的Agent，那就会有点困难。" 当开发者只凭感觉判断Agent是否正常，修改代码后只能靠肉眼观察输出是否"看起来对"，质量退化就难以察觉。

这一痛点具有普遍性。视频指出，没人告诉你该用什么数据测试，也没人告诉你具体如何使用评估工具。结果是，许多团队要么跳过评估直接上线，要么堆砌大量无法实际测量的指标——Dani的建议恰恰相反：先托管几个核心指标，比如工具使用质量和轨迹质量。

四步构建Agent评估体系

第一步：让Coding Agent理解源代码与追踪

Dani强调的第一步是"将Anti-Gravity指向智能体源代码，让它理解其内部运作机制"。在演示中，他们直接对Coding Agent下指令：分析本次运行的追踪数据，理解Agent如何工作，并生成更多测试场景。

Anti-Gravity不仅能读代码，还能渲染Mermaid架构图，把Agent的数据库、调用链路直观呈现出来。Matt推荐了OpenCode、T3code、PI Agent等项目作为额外测试场景，让Agent以可重复的方式在这些仓库上运行Docs Agent，从而积累评估所需的数据。

LangGraph与Agent执行追踪：LangGraph是LangChain团队推出的有状态Agent编排框架，用图（节点与边）描述工作流，并支持检查点（checkpoint）、中断恢复和持久化记忆。它的追踪通常以“一次运行（run）”为单位，记录每个节点的输入输出、状态变迁与工具调用，这正好对应文章中反复提到的“轨迹质量”。相比只看最终输出，轨迹级数据能揭示Agent是否走了弯路、是否重复调用工具、是否在某个节点反复循环——这些正是Demo阶段肉眼难以发现、却最容易在生产环境放大的问题。理解这一点，才能明白为什么第一步要先让Coding Agent读懂追踪数据，而不是直接看输出结果。

第二步：用OpenInference统一追踪格式

评估的前提是数据可用。不同框架（LangGraph、ADK等）产生的追踪数据格式各异，OpenTelemetry虽然提供了外观标准，但跨框架的跨度与参数仍不统一。OpenInference则充当转换器，把各类Agent的追踪汇总到一处。

据Dani和Matt在视频中的解释，让Agent符合OpenInference标准后，无论内部逻辑如何改动，评估数据本身保持兼容。演示中，工具自动完成了追踪转换，并将数据映射到Vertex AI评估服务可接受的格式。这一步将部署时间从数周缩短到约一小时。

OpenTelemetry与OpenInference的关系：OpenTelemetry（OTel）是云原生计算基金会（CNCF）孵化的开源可观测性框架，定义了追踪（trace）、指标（metric）、日志（log）三类遥测数据的统一采集与导出标准，已被主流云厂商和APM工具广泛支持。在LLM应用场景中，OTel提供了通用的Span（跨度）模型，但并未规定“一个LLM调用”“一次检索”“一个工具调用”应如何表示，导致不同Agent框架产出的追踪在语义层无法直接对比。

OpenInference是由Arize等厂商发起的OTel语义约定扩展，专门为LLM/Agent场景定义了一套标准属性（如llm.model_name、tool.name、retrieval.documents），并针对LangChain、LangGraph、LlamaIndex、CrewAI等框架提供instrumentor。它的价值在于：让不同框架产生的追踪遵循同一套“词汇表”，从而可以被同一套评估工具消费。这与文章强调的“无论内部逻辑如何改动，评估数据本身保持兼容”是同一件事——标准化发生在语义层，而不仅是传输层。

第三步：把主观质量转化为可运行指标

这是整场演示最具启发性的部分。Matt提出一种可复现模式：利用AI在遵循人类专家指导的前提下，快速创建评估指标。Agent基于Docs Agent的代码、LangGraph代码以及内部运行机制，预选了一批托管指标，同时生成了自定义判断标准——结构化格式、可操作性、技术精准度、代码块完整性等。

Dani特别赞赏"代码块"这一指标，因为很多文档在需要时并未生成代码块。他同时给出建议：不要一上来就用2000个指标，先从工具使用质量、轨迹质量等基础项开始，再和开发者及用户坐下来，聊聊对他们而言质量到底意味着什么。

LLM-as-judge的适用边界与常见陷阱：LLM-as-judge指的是用一个LLM按评分标准（rubric）对其他LLM的输出打分，替代人工评审。它在语义类指标（如可操作性、技术精准度、语气一致性）上成本低、扩展性好，因此成为Agent评估的主流手段。但它有几个已知偏差需要防范：

• 位置偏差：在成对比较中倾向于偏好第一个或第二个选项；
• 长度偏差：倾向于给更长的回答更高分；
• 自我偏好：同源模型互评时分数偏高；
• 标准漂移：rubric写得含糊时，评分结果在不同批次间方差很大。

实践中的缓解手段包括：固定judge模型版本、在rubric中给出正反例、使用确定性指标（如代码块是否存在、格式是否合法）作为交叉校验、对judge本身的输出做定期人工抽检。这也解释了文章为何同时保留确定性指标和LLM评分——两类指标互相兜底，才能让“量化反馈”真正可信。

第四步：运行评估并量化改进方向

最后一步是实际运行评估并获得量化反馈。演示中，Agent生成了EvalSet JSON数据集、EvalConfig YAML配置文件，并产出一份带Google配色的可视化报告。报告既包含确定性指标（如延迟、Token使用量、缓存Token），也包含LLM-as-judge的质量评分。

结果出人意料：Docs Agent的文档质量评分偏低，还暴露出一个渲染提示词错误。Matt坦言这让他"有点想回去修改Agent"，但更重要的是，他现在有了数据依据——可以判断是代码需要改进，还是评估方式本身需要调整。

评估是面向所有人的吗？

Dani在结尾抛出一个开放问题。Matt的回答相当务实：如果你正试图将产品投入生产或在企业中使用，评估非常重要；但对独立开发者而言，只有当Agent真的需要在生产环境中表现良好时，评估才值得投入。他还提到，如果模型明天变强了、测试框架变了，评估体系也需要随之迭代。

这场演示的核心价值不在于某个工具，而在于一种思路：把开发者脑海中对质量的理解，转化为可运行、可复现、可共享的实际数据。正如Matt所说，无论是自己修改内容还是别人提交PR，你都能衡量出改进甚至退化——这才是Agent从Demo走向生产的关键一步。