Agent评估不能只靠搭框架：Langfuse与两层评估架构实战

很多团队在Agent项目里把精力全花在编排和工具调用上，上线后才发现真正棘手的问题：怎么知道它答得对不对？本文基于一个财务分析Agent的实战项目，梳理Agent评估的三个核心认知，并结合Langfuse平台与四大评估框架，拆解一套可落地的两层评估架构。

三个认知：Agent评估不是传统软件测试

做Agent评估之前，有必要先厘清三个容易被混淆的前提。

第一，Agent评估的目标不是100%准确。 因为Agent的底层是大模型，而无论DeepSeek^广告、OpenAI还是Anthropic的模型，本质上都是概率模型——基于上一个token推算下一个token。注意力机制能让模型理解语义和逻辑，但概率本质决定了它很难做到绝对准确。评估的真正目标是让Agent的结论和操作结果趋近于100%，就像4K金能做到99.99%已经是极高纯度，工程上追求的是那个"趋近"的过程，而非幻觉式的完美。

第二，Agent评估不等于大模型评估。 大模型评估通常是给一个问题、看生成的答案，相对直接。但Agent涉及多步推理、工具调用、状态流转，评估对象从"单次输出"变成了"整条执行轨迹"，复杂度完全不同。

第三，Agent评估不等于软件测试。 这是最普遍的误区。传统软件测试验证的是功能是否正常运行、流程是否走通；而Agent评估要回答的是"回答是否可信""推理是否合理""工具选择是否正确"。前者是确定性判断，后者是概率性判断。

这三个认知决定了后续架构设计的走向：你需要的不只是pass/fail，而是可追踪、可量化、可迭代的评估体系。

项目背景：9300条财报数据上的财务分析Agent

讨论评估方法需要一个具体场景。这里使用的是基于哈利架构与Langfuse搭建的财务分析Agent，定位为企业级评估平台。

数据层面，项目采集了9300多条全球上市公司公开财务报告，存储在轻量级SQLite数据库的financial report表中。每条数据包含公司名称、年份、PDF文件以及从财报中提取的文本内容和表格。这些数据来自公开渠道，并非模型生成。

Agent的任务是：基于这些公开财报，回答金融、基金、股票相关的分析问题。比如"某公司某年度的营收变化趋势如何"，或者"某公司现金流状况是否健康"。

这个项目的重点不在Agent功能本身，而在于：Agent回答完问题之后，如何判断回答是否准确。这正是评估体系要解决的问题。

Langfuse：Agent可观测性的基础设施

Agent评估的第一步是"看得见"。Langfuse在这个项目里承担的是可观测性层——追踪每一次Agent调用的完整链路。

具体来说，Langfuse记录的内容包括：每次请求的输入输出、每一步推理的中间状态、工具调用的参数与返回结果、以及整体的延迟和token消耗。这些trace数据是后续评估的原材料。

没有可观测性，评估就无从下手。你无法对一个你看不见执行过程的Agent做出有意义的判断。Langfuse的价值在于把Agent的"黑盒"变成"灰盒"——你不需要理解每一层神经网络的激活值，但你需要知道它走了哪几步、调了哪些工具、在哪一步出现了偏差。

Trace、Span与Generation 是理解 Langfuse 数据模型的关键。一次完整的 Agent 调用对应一个 trace，代表从用户提问到最终答复的整个请求生命周期。trace 内部由若干 span 组成，每个 span 对应链路中的一个执行步骤，比如一次检索、一次工具调用或一轮推理。而当某一步涉及大模型生成时，会单独记录为 generation，附带 prompt、completion、token 数和耗时。这种层级结构让评估者既能自上而下看整体耗时与成功与否，也能下钻到某个 span 检查工具参数是否正确、检索片段是否相关。正是这套分层记录机制，使组件级评估和端到端评估可以共用同一份 trace 数据，而不需要重复埋点。

两层评估架构与四大评估框架

在Langfuse的trace数据之上，项目搭建了两层评估架构。

第一层：组件级评估。 针对Agent执行链路中的单个环节做评估，比如检索到的财报片段是否相关、工具调用参数是否正确、单步推理是否逻辑自洽。这一层的好处是定位精准——当最终答案出错时，能快速定位是检索环节、推理环节还是生成环节的问题。

第二层：端到端评估。 针对Agent的最终输出做整体评估，判断回答是否准确、是否完整、是否与源数据一致。这一层更接近用户视角，但问题定位能力弱于组件级评估。

两层架构配合使用，既保证了对最终效果的把控，又提供了足够的诊断粒度。

在评估框架层面，项目结合了四类评估方法：基于规则的确定性检查（如数值是否匹配源数据）、基于LLM的裁判评估（用大模型判断回答质量）、基于人工标注的抽样评估、以及基于用户反馈的在线评估。四者从不同维度覆盖评估需求，规则检查负责硬性事实，LLM裁判负责语义质量，人工标注提供基准校准，用户反馈反映真实场景表现。

LLM-as-a-Judge 是近两年被广泛采用的一种评估范式，指用一个能力较强的大模型充当裁判，对另一个模型的输出打分或给出判断。它的优势在于能处理规则难以描述的语义质量，比如回答是否切题、推理是否连贯、是否存在事实性幻觉。常见做法是提供参考答案或评分 rubric，让裁判模型按维度打分。但它也存在已知偏差：倾向偏好更长的回答、对自身系列模型的输出更宽容、对位置敏感（先出现的选项更容易被选中）。因此在工程实践中，LLM 裁判通常与规则检查配合使用，并在关键场景用人工标注做校准，避免单一裁判的偏见被放大成系统性误差。

组件级评估 与 端到端评估 的分工，本质上对应了可观测性中的不同粒度。组件级评估针对 trace 中的单个 span 或 generation，回答的是局部正确性问题，例如检索到的财报片段与问题语义是否匹配、工具调用传入的年份和公司名是否与用户意图一致。它的信号更密集，因为一次 Agent 执行往往产生多个步骤，每一步都能产出评估结果，便于在数据量有限时更快发现回归。端到端评估则只看最终输出，信号稀疏但更贴近业务价值。工程上常见的做法是：用端到端评估做上线门禁，用组件级评估做问题归因和迭代指引，两者形成互补而非替代关系。

实践建议

如果你的团队正在做Agent项目，以下几点值得参考：

• 先建可观测性，再谈评估。 没有trace数据，评估就是空中楼阁。Langfuse这类工具应该在上线前就接入。
• 接受概率本质，设定合理预期。 不要用100%准确作为验收标准，而是设定可量化的趋近目标，比如关键事实准确率达到某个阈值。
• 两层架构并行。 只做端到端评估，出了问题不知道改哪里；只做组件级评估，又容易忽略整体效果。两者缺一不可。
• 多框架交叉验证。 单一评估方法都有盲区，规则检查覆盖不了语义质量，LLM裁判可能存在偏见，人工标注成本高但不可替代。

Agent评估不是一次性的验收动作，而是贯穿项目生命周期的持续过程。把评估体系当作产品的一部分来建设，而不是上线前的最后一道关卡。