生态工具篇难度 3⏱ 13 分钟概念
01评估框架（Evaluation Framework）
用于系统化测量 LLM/Agent 系统输出质量与行为可靠性的指标体系和方法论
评估框架LLM-as-Judge自动评估RAGASDeepEval
更新于 2026-03-26evaluation-framework
通过多维量化指标对 Agent 的工具调用、推理、任务完成和安全性进行系统化评估
内容摘要
Agent 行为评估是一套系统化的测量体系，用来给 Agent 做"全身体检"——不只看最终结果对不对，而是把 Agent 从理解任务、选择工具、调用参数、链式推理到输出答案的每一步都拆开检查，用量化指标定位具体哪个环节出了问题。
Agent 行为评估是一套系统化的测量体系，用来给 Agent 做"全身体检"——不只看最终结果对不对，而是把 Agent 从理解任务、选择工具、调用参数、链式推理到输出答案的每一步都拆开检查，用量化指标定位具体哪个环节出了问题。
传统的 LLM 评估只关心"输出正确率"，这对 Agent 远远不够。Agent 的行为是多层次的：它需要选对工具、传对参数、基于工具返回值做推理、多轮迭代后生成最终结果。一个简单的"对/错"判断无法告诉你"是工具选错了，还是参数传错了，还是推理链断了"。Agent 行为评估的核心思路就是把黑盒行为拆解成多个可观测维度，逐层诊断，精确定位瓶颈。
这在生产环境中尤其关键。企业级 Agent 涉及数据安全、合规约束、成本控制等非功能性需求，光看"答案像不像对的"无法保障系统质量。2025 年以来，行业已从单一的任务完成率指标，演进到涵盖工具正确性、推理一致性、行为稳定性、安全性和成本效率的多维评估体系。
Agent 行为评估由四个核心维度组成，每个维度独立测量但相互关联：
| 维度 | 评估对象 | 核心指标 |
|---|---|---|
| 工具调用准确率 | Agent 选工具、传参数的行为 | 精准率、召回率、F1、参数匹配度 |
| 任务完成率 | 最终输出是否满足用户需求 | 成功率（SR）、Pass@k、输出质量评分 |
| 多步骤推理正确性 | 链式推理的逻辑一致性 | 中间步骤对齐度、错误恢复率、规划得分 |
| 安全性评估 | 是否符合安全策略和合规约束 | 违规次数、敏感信息泄露率、策略合规分 |
评估 Agent 在"选哪个工具"和"怎么调用"两个层面的表现。拆成三个子指标：
从终端用户的视角评估 Agent 是否"把事办成了"。常用指标：
Agent 的推理链条越长，中间出错的概率越高。评估内容包括：
面向生产环境的关键维度，检查 Agent 是否"干了不该干的事"：
Agent 行为评估的核心机制是轨迹记录 + 多维度指标计算 + 分析报告三段式流程：
关键判断发生在第 2 步的指标计算环节——这里需要区分两种评估方法：
两种方法通常混合使用：自动化处理基础案例，LLM 评分处理复杂案例，人工抽检校准 LLM 评分的准确性。
四个阶段形成闭环：准备阶段定义"测什么"和"用什么测"；执行阶段运行 Agent 并采集完整轨迹；评估阶段对轨迹做量化打分；分析阶段诊断问题并生成优化方向，然后回到准备阶段调整测试集或评估标准。
两条评估路径（C1 确定性指标 / C2 模糊性指标）是读图时的关键分叉点——不同类型的指标计算方法完全不同，这决定了评估系统的设计方式。
以下示例展示评估器的核心逻辑——如何对 Agent 的执行轨迹做多维度打分：
# 最小示例：Agent 行为评估器核心逻辑
# 不依赖外部库，仅展示评估的计算机制
from dataclasses import dataclass
@dataclass
class ToolCall:
"""单次工具调用记录"""
tool_name: str # 调用了哪个工具
parameters: dict # 传了什么参数
result: str # 工具返回了什么
@dataclass
class AgentTrajectory:
"""Agent 完整执行轨迹"""
question: str # 用户问题
tool_calls: list[ToolCall] # 工具调用序列
final_answer: str # 最终输出
def evaluate_trajectory(trajectory: AgentTrajectory, ground_truth: dict) -> dict:
"""
对单条轨迹做多维度评分。
ground_truth 结构：
- expected_tools: 应该调用的工具列表
- expected_keywords: 答案应包含的关键词
- forbidden_tools: 禁止调用的工具列表
"""
called = [tc.tool_name for tc in trajectory.tool_calls]
expected = ground_truth.get("expected_tools", [])
forbidden = ground_truth.get("forbidden_tools", [])
keywords = ground_truth.get("expected_keywords", [])
# --- 维度 1：工具调用 F1 ---
correct = len(set(called) & set(expected))
precision = correct / len(called) if called else 0.0
recall = correct / len(expected) if expected else 1.0
f1 = 2 * precision * recall / (precision + recall) if (precision + recall) > 0 else 0.0
# --- 维度 2：任务完成率（关键词覆盖度） ---
answer_lower = trajectory.final_answer.lower()
hit = sum(1 for kw in keywords if kw.lower() in answer_lower)
completion = hit / len(keywords) if keywords else 1.0
# --- 维度 3：安全性（禁用工具检查） ---
violations = [t for t in called if t in forbidden]
is_safe = len(violations) == 0
return {
"tool_f1": round(f1, 3),
"completion_rate": round(completion, 3),
"is_safe": is_safe,
"safety_violations": violations,
"overall_pass": f1 > 0.5 and completion > 0.5 and is_safe,
}
# --- 使用示例 ---
trajectory = AgentTrajectory(
question="公司目前有多少员工？",
tool_calls=[
ToolCall("database_query", {"sql": "SELECT COUNT(*) FROM employees"}, "150"),
],
final_answer="公司目前共有 150 名员工。",
)
ground_truth = {
"expected_tools": ["database_query"],
"expected_keywords": ["150", "员工"],
"forbidden_tools": ["delete_record", "send_email"],
}
result = evaluate_trajectory(trajectory, ground_truth)
# 输出：{'tool_f1': 1.0, 'completion_rate': 1.0, 'is_safe': True,
# 'safety_violations': [], 'overall_pass': True}
代码对应评估器的核心计算逻辑：接收一条 Agent 执行轨迹和标准答案，分别计算工具调用 F1、任务完成率和安全性三个维度的得分。overall_pass 是三个维度的联合判定——任何一个维度不达标，整体就不通过。实际生产中还需加入 LLM-as-Judge 对推理质量的评分，此处省略。
| 概念 | 与 Agent 行为评估的区别 | 更适合关注的重点 |
|---|---|---|
| LLM 评估（LLM Evaluation） | 只评估模型的文本生成能力，不涉及工具调用和多步决策 | 模型选型、基础能力对比 |
| Benchmark 基准测试 | 是评估体系中"测试数据集"的标准化形式，是评估的输入而非评估本身 | 框架选型、跨系统对标 |
| 可观测性（Observability） | 侧重运行时的数据采集和监控，是评估的数据来源而非评估方法 | 生产环境实时监控和告警 |
| A/B 测试 | 侧重比较两个版本的整体效果差异，不做逐维度深入诊断 | 上线决策、版本选择 |
核心区别：
| 常见误区 | 正确理解 |
|---|---|
| 用一个总分就能代表 Agent 质量 | Agent 是多维系统，总分相同但维度分布不同的两个 Agent，优化策略完全不同。必须看各维度拆分指标 |
| 测试集数量越多评估越准 | 关键是测试集的多样性和代表性，100 个覆盖各种边界情况的用例比 1000 个重复用例更有诊断价值 |
| 评估一次就够了 | Agent 是动态系统，每次改动（提示词、工具集、模型版本）都可能影响表现。必须建立持续评估机制，嵌入 CI/CD 流程 |
| Pass@1 高就说明 Agent 可靠 | Pass@1 只说明"偶尔能做对"，生产环境需要的是"每次都做对"。应该用 Pass@k 的全部成功率来衡量行为一致性 |
| LLM-as-Judge 可以完全替代人工 | LLM 评分有幻觉和偏差风险，对安全关键场景和模糊判断仍需人工抽检。正确做法是自动化 + LLM + 人工三层结合 |
参考答案：
四个核心维度：工具调用准确率、任务完成率、多步骤推理正确性、安全性评估。
不能只看任务完成率的原因：任务虽然"完成"了，但可能工具选错了（只是碰巧得到正确结果）、推理过程有逻辑漏洞（下次类似问题就会失败）、或者违反了安全约束（在生产环境中不可接受）。单一维度无法定位具体哪个环节出了问题，也无法指导优化方向。
参考答案：
工具选对了但任务完不成，说明问题出在工具调用之后的环节。可能的原因：
诊断方法：回放失败案例的完整轨迹（Thought → Action → Observation → Output），逐步检查工具返回值是否被正确解读、推理链条在哪一步断裂。
参考答案：
评估维度设计：
处理模糊指标的方法：采用三层评估策略——
Anthropic. "Demystifying evals for AI agents." Engineering Blog. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
Amazon Web Services. "Evaluating AI agents: Real-world lessons from building agentic systems at Amazon." Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/evaluating-ai-agents-real-world-lessons-from-building-agentic-systems-at-amazon/
Confident AI. "LLM Agent Evaluation: Assessing Tool Use, Task Completion, and Reasoning." https://www.confident-ai.com/blog/llm-agent-evaluation-complete-guide
Liu et al. "AgentBench: Evaluating LLMs as Agents." ICLR 2024. https://arxiv.org/abs/2308.03688
Jimenez et al. "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" ICLR 2024. https://arxiv.org/abs/2310.06770
o-mega. "Best AI Agent Evaluation Benchmarks: 2025 Complete Guide." https://o-mega.ai/articles/the-best-ai-agent-evals-and-benchmarks-full-2025-guide
Evidently AI. "10 AI agent benchmarks." https://www.evidentlyai.com/blog/ai-agent-benchmarks
优先展示同分类且标签更接近的内容，方便继续串联学习。
用于系统化测量 LLM/Agent 系统输出质量与行为可靠性的指标体系和方法论
Agent 和 RAG 系统的核心评估工具，涵盖 RAGAS、DeepEval、TruLens、Promptfoo 等主流框架
系统化评估 RAG 系统的检索质量与生成质量，定位瓶颈并指导优化。