AI Agent评测新范式：基于轨迹证据链的A/B/C/D分级方法

Hacker News 上出现过一条很尖锐的提问：为什么我们不像圣训学者那样去给 AI Agent 评分？

第一次看到时可能觉得跳跃。但如果把“圣训学者”理解成“古典考据学者”，这个问题一下就变得很现代：在缺乏录音、视频和一手权威的年代，人们要判断一段话是否可靠，靠的是建立“证据链”。每一条信息都要回答三个问题：谁说的、通过谁传下来的、传述人本身可不可靠。最终不是一句“信”或“不信”，而是一套分级：可靠、可信、存疑、弃用。

我们做 AI Agent 评测时，需要的也正是这条链。

为什么？因为 Agent 跟单轮大模型问答最大的区别是：它会自己规划、调工具、读文档、试错、迭代。最终返回的答案，是多个决策节点的累积结果。如果一个 Agent 在工具调用环节换了来源，在检索环节漏掉了关键文档，在推理环节补了一个不存在的结论——这些问题往往不会直接暴露在最终答案里，却会以“看起来正确但经不起追溯”的方式留存下来。

这篇文章想给出的判断是：Agent 评测的重点不是给最终答案打分，而是给执行过程做“证据链还原”。只有把来源链、工具链、推理链全部记录下来，再套用一套分层评分机制，我们才能知道一个 Agent 到底可不可信、能信几分。

文章后半部分，我会用一个包含知识库检索、计算工具的最小 Python Agent 做演示：从轨迹记录、程序性检查、LLM-as-judge，到最终输出 A/B/C/D 四级可靠性标签。整套代码可以直接复制下来试用，也可以作为你团队 Agent 评测体系的起点。

1. 为什么单点评测无法应对 Agent 场景

先看一个对比。

传统的大模型评测，输入是 prompt，输出是文本。你只需要关心“这轮回答对不对”。评测指标也比较成熟：准确率、F1、BLEU、ROUGE、人工评分、LLM-as-judge，都能用。即使回答有幻觉，问题也能定位在“模型”这一层。

但 Agent 不一样。Agent 是一个复合系统：大模型负责推理决策，工具负责获取外部信息，知识库负责提供领域事实，代码逻辑负责把它们串起来。这意味着两个之前可以混在一起的问题，现在必须分开：

1. 模型本身的能力问题：它不会规划、不会反思、不遵循指令。
2. 系统链路的问题：工具返回错了、召回文档不相关、上下文被截断、来源冲突。

只看最终答案，你根本分不清是哪一个环节出错。我见过一个 Agent 面对“退货政策”提问时，回答得有理有据，结果后来查轨迹才发现：检索器召回的是“会员积分规则”，工具调用失败后 Agent 直接忽略错误，继续按照自己的记忆编了一段答案。这种案例在最终答案层面几乎不可能被发现。

所以 Agent 评测的第一个原则是：必须把执行轨迹纳入评估对象。轨迹（trajectory）指的是 Agent 从接收输入到生成输出的完整过程，包括每一步的决策、工具调用、检索结果、中间推理和最终组装。没有轨迹的 Agent 评测，等于在黑暗里验货。

2. 古典考据体系里值得借鉴的三层结构

回到 Hacker News 那个问题。如果把圣训学者的工作方法抽象出来，其实是一套非常完整的可信度验证框架，至少包含三个层次。

第一层是来源链。每一段话都不是凭空出现的，它必须说明“由谁传给谁，再传给谁”。这条链上的任何一环断裂，可信度都要打折。对应到 Agent，就是数据来源链：最终答案是基于哪几个文档、哪几次工具输出、哪一段代码逻辑拼接出来的。如果无法回答“这句话是从哪里来的”，这个输出就应该被标记为低置信度。

第二层是传述人评级。古典体系里会对每个传述人的记忆力、诚实度、与权威观点的一致性做评估。传述人分等级，有的被标记为“可信”，有的被标记为“缺陷明显”。对应到 Agent，这里的“传述人”不仅包括大模型，还包括工具、插件、外部 API、知识库文档。每个环节都要有可靠性档案：

• 这个工具历史上返回错误的频率有多高？
• 这个知识库文档是正式版本还是临时草稿？
• 这个模型在处理这类推理任务时，已知的失败模式是什么？

第三层是文本批评。即使来源链完整、传述人可靠，内容本身还要接受交叉验证：是否与其他可靠来源矛盾？是否符合常识和逻辑？对应到 Agent，就是对最终答案做一致性校验：多个独立文档是否指向同一结论？工具结果是否支持模型最后的推理？答案里有没有内部矛盾？

可以整理成一张表：

这个映射关系，是我认为这个问题真正有价值的地方：古人早就设计好了一套“多节点可信度评估”的成熟范式，而今天大多数 Agent 评测还停留在单点打分。

3. 可落地的 Agent 评测框架：五步法

把上面的思路转成工程师能直接执行的方法，我建议用五步法。这套方法不依赖特定框架，也不绑定某个评估平台，你可以在已有 Agent 代码上逐步加上去。

第一步：记录轨迹。改造 Agent，让每一步工具调用、检索、中间输出都进入 trace。这是整条证据链的地基。

第二步：拆解阶段。把 Agent 流程拆成路由、检索、工具执行、生成、反思等环节，每个环节单独评估，而不是只评最终答案。

第三步：程序性检查。用确定性规则做闸门检查，比如“最终答案是否包含来源”“工具是否调用成功”“是否存在占位符内容”。程序性检查不依赖大模型判断，速度快、稳定，适合做硬性过滤。

第四步：LLM-as-judge 评分。让一个独立的评测模型基于轨迹和答案，按评分标准输出结构化分数。这里要注意，评测模型最好与执行 Agent 不同，降低“自己给自己打分”的偏差。

第五步：分级汇总。把程序性检查和 LLM 评分汇总成最终等级，同时保留步骤级详细信息。分级不是为了让 Agent 失去资格，而是让使用方明确知道风险边界。

这个五步法并不复杂，但能覆盖 Agent 评测里最关键的三个部分：过程、结果、来源。接下来我们用代码把整条链路跑通。

4. 环境准备与项目结构

为了演示，我会用最小依赖实现一个带知识库检索和计算工具的客服问答 Agent，并给它配上评测脚本。环境如下：

• Python 3.10 或 3.11
• openai SDK（用于 LLM judge，如果只想跑通演示逻辑，也可以先用 fake judge）
• 不需要额外安装大模型推理依赖

如果你的环境没有 Python，可以先用 conda 或 pyenv 准备一个独立环境：

mkdir agent_evals_demo && cd agent_evals_demo python -m venv .venv source .venv/bin/activate pip install openai

项目文件规划：

agent_evals_demo/ ├── agent_demo.py # 最小 Agent 示例，包含轨迹记录 ├── grade_agent.py # 评测脚本，包含程序性检查和 LLM judge └── .env # 存放 OPENAI_API_KEY（可选）

本文代码重在演示“证据链式评测”的通用思路，生产环境可直接复用这个分层设计，但具体工具接口需要你按业务替换。

5. 代码实现：带轨迹记录的最小 Agent

先实现 Agent 部分。我不会引入 LangChain 这类重框架，而是直接写一个可以被评测的轻量 Agent，方便你看到每一条轨迹是怎么产生的。

文件路径：agent_demo.py

# agent_demo.py """ 一个最小可运行的 Agent 示例。 生产环境中，工具选择由 LLM 完成；这里用确定性规则便于复现评测流程。 """ from dataclasses import dataclass, field from typing import Any @dataclass class TraceEvent: step: int module: str action: str input: Any output: Any sources: list[str] = field(default_factory=list) @dataclass class AgentResult: final_answer: str trace: list[TraceEvent] used_sources: list[str] = field(default_factory=list) def tool_retrieve_kb(query: str): """模拟知识库检索。真实项目中可替换为向量检索或搜索引擎。""" kb = { "退货": ("用户可以在签收后 7 天内无理由退货", ["doc_policy_2024.pdf#p12"]), "保修": ("主要零部件保修期为 2 年", ["doc_warranty_v3.pdf#p5"]), "积分": ("会员积分有效期为 1 年", ["doc_member_2024.pdf#p8"]), } for key, (answer, src) in kb.items(): if key in query: return answer, src return "知识库无匹配结果", ["kb_missing"] def tool_calc(expr: str): """极简计算工具。生产环境请换用安全的表达式解析器。""" try: return str(eval(expr, {"__builtins__": {}}, {})), ["tool:calculator"] except Exception: return "表达式错误", ["tool:calculator:error"] def run_agent(query: str) -> AgentResult: trace = [] # 步骤 1：路由。实际项目里这一步可以由 LLM 决策。 if "退货" in query or "退款" in query or "退" in query: kb_ans, kb_src = tool_retrieve_kb(query) trace.append( TraceEvent(1, "router", "retrieve_kb", query, kb_ans, kb_src) ) # 步骤 2：组装答案 answer = f"根据知识库：{kb_ans}。" trace.append( TraceEvent(2, "responder", "compose", query, answer, kb_src) ) return AgentResult(final_answer=answer, trace=trace, used_sources=kb_src) if "保修" in query: kb_ans, kb_src = tool_retrieve_kb(query) trace.append( TraceEvent(1, "router", "retrieve_kb", query, kb_ans, kb_src) ) answer = f"根据知识库：{kb_ans}。" trace.append( TraceEvent(2, "responder", "compose", query, answer, kb_src) ) return AgentResult(final_answer=answer, trace=trace, used_sources=kb_src) if "计算" in query or "多少" in query: # 简化场景：从问题里提取第一个算术表达式 import re expr = re.findall(r"[\d+\-*/() ]+", query) expr_str = expr[0].strip() if expr else "" calc_ans, calc_src = tool_calc(expr_str) trace.append( TraceEvent(1, "router", "call_calc", expr_str, calc_ans, calc_src) ) answer = f"计算结果：{calc_ans}。" trace.append( TraceEvent(2, "responder", "compose", query, answer, calc_src) ) return AgentResult(final_answer=answer, trace=trace, used_sources=calc_src) # 默认：无法匹配时返回提示 answer = "抱歉，我暂时无法处理这个问题。" trace.append( TraceEvent(1, "responder", "fallback", query, answer, ["no_route"]) ) return AgentResult( final_answer=answer, trace=trace, used_sources=["no_route"], ) if __name__ == "__main__": test_query = "我 7 天前买的空调，现在还能退吗？" result = run_agent(test_query) print("最终回答：", result.final_answer) print("使用来源：", result.used_sources) print("轨迹数量：", len(result.trace)) for event in result.trace: print(event.step, event.module, event.action, event.input, event.output, event.sources)

这段代码的关键点有几个。

第一，所有工具都返回(content, sources)结构。content是供 Agent 使用的文本，sources是这一步的证据来源。这个设计是整个证据链的基础。如果你的工具没有返回来源信息，后面的评测会非常被动。

第二，每个 TraceEvent 都记录了模块、动作、输入和输出。这不仅仅是日志，它是评测模型判断“这一步是否合理”的依据。没有这些信息，LLM-as-judge 只能盲猜。

第三，AgentResult里的used_sources是最终答案实际依赖的来源。这个字段会和答案绑定，用于来源忠实度检查。

运行这个文件：

python agent_demo.py

预期输出大致如下：

最终回答： 根据知识库：用户可以在签收后 7 天内无理由退货。 使用来源： ['doc_policy_2024.pdf#p12'] 轨迹数量： 2 1 router retrieve_kb 我 7 天前买的空调，现在还能退吗？ ... 2 responder compose 我 7 天前买的空调，现在还能退吗？ ...

到这里，我们已经有了可以评测的执行轨迹。

6. 代码实现：轨迹评测与 A/B/C/D 分级

接下来写评测脚本。评测脚本分成四部分：程序性检查、LLM-as-judge 评分、分级函数、主流程。

文件路径：grade_agent.py

# grade_agent.py """ 基于轨迹的 Agent 评测演示。 把 Agent 执行轨迹当作证据链，先做程序性检查，再做 LLM 评分，最后分级。 """ import json import os from dataclasses import asdict from agent_demo import run_agent, AgentResult # ---------- 程序性检查 ---------- def check_final_answer_not_placeholder(result: AgentResult) -> bool: """最终答案不能是兜底话术。""" return "抱歉" not in result.final_answer def check_trace_not_empty(result: AgentResult) -> bool: """执行轨迹不能为空。""" return len(result.trace) > 0 def check_sources_matched(result: AgentResult) -> bool: """最终回答必须至少关联一个非 no_route 来源。""" bad_markers = {"no_route", "kb_missing", "tool:calculator:error"} return any(src not in bad_markers for src in result.used_sources) def check_tool_success(result: AgentResult) -> bool: """工具调用不能出现错误标记。""" for event in result.trace: for src in event.sources: if src.endswith("error") or src == "kb_missing": return False return True # ---------- LLM-as-judge ---------- from openai import OpenAI client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) EVAL_SYSTEM_PROMPT = """ 你是一位严格的 Agent 评测专家。你只会收到 Agent 的执行轨迹、输入问题和最终答案。 请基于以下维度评分，每个维度 0-5 分，只输出 JSON，不要输出任何解释。 维度说明： - factuality: 事实性，最终答案是否符合常识和真实世界知识。 - faithfulness: 来源忠实度，最终答案是否严格基于轨迹中的来源，没有编造。 - tool_use: 工具使用合理性，Agent 是否选择了合适的工具，工具结果是否正确使用。 - reasoning: 推理质量，Agent 的中间决策和推理是否清晰、无明显矛盾。 输出格式： {"factuality": 4, "faithfulness": 5, "tool_use": 4, "reasoning": 3} """ def llm_judge(result: AgentResult, input_query: str) -> dict: trace_text = json.dumps( [asdict(event) for event in result.trace], ensure_ascii=False, default=str, ) user_prompt = ( f"输入问题：{input_query}\n\n" f"执行轨迹：{trace_text}\n\n" f"最终答案：{result.final_answer}" ) resp = client.chat.completions.create( model=os.getenv("OPENAI_MODEL", "gpt-4o-mini"), messages=[ {"role": "system", "content": EVAL_SYSTEM_PROMPT}, {"role": "user", "content": user_prompt}, ], response_format={"type": "json_object"}, temperature=0, ) return json.loads(resp.choices[0].message.content) # ---------- 分级函数 ---------- def grade_to_label(scores: dict) -> tuple[str, str]: """ A(可靠)：平均分 >= 4.5，且没有任何维度低于 4 B(可信)：平均分 >= 3.5，且没有维度低于 3 C(存疑)：平均分 >= 2.5 D(拒绝)：其他情况 """ avg = sum(scores.values()) / len(scores) min_score = min(scores.values()) if avg >= 4.5 and min_score >= 4: return "A", "可靠" if avg >= 3.5 and min_score >= 3: return "B", "可信" if avg >= 2.5: return "C", "存疑" return "D", "拒绝" # ---------- 评测主流程 ---------- def evaluate_agent(query: str, use_llm: bool = True) -> dict: result = run_agent(query) # 程序性检查：硬性门槛 checks = { "final_answer_not_placeholder": check_final_answer_not_placeholder(result), "trace_not_empty": check_trace_not_empty(result), "sources_matched": check_sources_matched(result), "tool_success": check_tool_success(result), } if not all(checks.values()): label = "D" label_desc = "拒绝" return { "query": query, "final_answer": result.final_answer, "used_sources": result.used_sources, "checks": checks, "scores": None, "label": label, "label_desc": label_desc, "reason": "程序性检查未通过，存在明显异常", } # LLM 评分 if use_llm: scores = llm_judge(result, query) else: # 演示用 fallback，不调用外部模型 scores = {"factuality": 4, "faithfulness": 4, "tool_use": 4, "reasoning": 4} label, label_desc = grade_to_label(scores) return { "query": query, "final_answer": result.final_answer, "used_sources": result.used_sources, "checks": checks, "scores": scores, "label": label, "label_desc": label_desc, "reason": f"平均分 {sum(scores.values()) / len(scores):.2f}，最低分 {min(scores.values())}", } if __name__ == "__main__": demo_queries = [ "我 7 天前买的空调，现在还能退吗？", "空调保修期多久？", "请计算 12 * 8 + 3 等于多少？", "帮我写一首诗", ] for q in demo_queries: report = evaluate_agent(q, use_llm=False) print(json.dumps(report, ensure_ascii=False, indent=2)) print("-" * 60)

这段代码里，我最想强调的程序性检查的优先级。它负责挡住那些“一眼假”的情况：没有来源、工具报错、兜底话术。这些情况不需要大模型来判断，直接用规则拦截，能省下不少评测成本和误判风险。

LLM-as-judge 则负责更细微的质量判断，比如“答案是否忠实于来源”“推理过程是否存在矛盾”。这里我把评分维度定义成 0-5 分的 JSON 输出，方便后续聚合和可视化。注意一点：评测模型选择了temperature=0，目的是降低随机性，让同一轨迹重复评分时结果尽可能稳定。

分级函数把评分映射到四档。这个阈值不是固定的，你可以根据业务风险调整。如果是金融、医疗场景，建议把 A 级的门槛提高，例如要求所有维度都是满分 5 分；如果是内容推荐场景，B 级可能已经可用。

7. 运行结果与效果验证

运行评测脚本：

python grade_agent.py

由于默认没有配置OPENAI_API_KEY，脚本会走use_llm=False的演示分支。预期输出类似：

{ "query": "我 7 天前买的空调，现在还能退吗？", "final_answer": "根据知识库：用户可以在签收后 7 天内无理由退货。", "used_sources": ["doc_policy_2024.pdf#p12"], "checks": { "final_answer_not_placeholder": true, "trace_not_empty": true, "sources_matched": true, "tool_success": true }, "scores": { "factuality": 4, "faithfulness": 4, "tool_use": 4, "reasoning": 4 }, "label": "B", "label_desc": "可信", "reason": "平均分 4.00，最低分 4" }

这里演示分支给的分数是写死的，所以只能用来验证整个流程是否跑通。真正要评判 Agent 质量，必须让 LLM 根据轨迹输出真实评分。

验证成功的标准有三个：

1. 程序性检查所有项目返回true，并且结果里没有出现kb_missing、no_route、error这类异常标记。
2. 最终答案能追溯到明确的来源文件，来源不是空数组。
3. 分级结果符合直觉：正常检索问题得到 B 或 A，无来源问题得到 D。

如果你配置了 OpenAI Key，想跑真实评分，可以单独写一个入口：

export OPENAI_API_KEY=sk-xxx export OPENAI_MODEL=gpt-4o-mini python -c "from grade_agent import evaluate_agent; r = evaluate_agent('我 7 天前买的空调，现在还能退吗？', use_llm=True); print(r)"

如果失败，先检查网络是否能访问相应 API 服务，再确认账号是否有该模型的调用权限。这个步骤依赖具体的模型服务配置，不同环境差异较大。

8. 常见问题与排查方法

在实际落地这套评测体系时，我遇到过一些高频问题，整理成表格供你参考。

其中最容易忽视的是“工具失败后 Agent 继续生成”的情况。在 Demo 里，tool_calc返回错误标记，但路由逻辑没有强制中止。生产环境应该在检测到工具返回 error 标记时，让 Agent 明确给出“工具执行失败，无法计算”，而不是继续拼接一个看似合理的答案。这是评测暴露出的典型工程问题，也是证据链式评测的价值所在。

9. 最佳实践与工程建议

如果要把这套思路落到真实的团队项目里，下面几条建议可以直接参考。

第一，工具返回结构要统一。无论是函数调用、HTTP API、还是数据库查询，都建议统一封装成(content, sources, status)结构。content是给模型的文本，sources是证据来源，status是成功或失败状态。没有统一协议，评测脚本会变成一团乱麻。

第二，记录评测版本。每次跑评测时，要记录使用的模型版本、prompt 版本、知识库版本、工具版本。Agent 评测最怕的是“昨天得分高，今天得分低，但说不清哪个环节变了”。没有版本信息，这类问题几乎无法排查。

第三，程序性检查和 LLM judge 要分离。程序性检查是规则，速度快、确定性强，适合做 CI/CD 门槛；LLM judge 是质量判断，适合做灰度评估和线上采样分析。两者混在一起，会让问题定位变得模糊。

第四，评测模型与执行 Agent 尽量隔离。最好使用不同模型，或者至少使用不同 prompt 体系。如果 Agent 自己评判自己，会出现系统性偏差，因为同一个模型的偏好会在执行和评分之间互相强化。

第五，建立金牌测试集。挑选 30 到 50 条历史真实问题，人工标注预期答案和预期评级，作为回归基准。每次改动 Agent 逻辑后，先跑一遍金牌集，再决定是否发布。这是成本最低的质量底线。

第六，关注漂移。Agent 上线后，要持续采样线上轨迹做评测，观察评级分布是否随时间变化。如果 A 级比例突然上升，不一定是 Agent 变强了，也可能是评测模型变了或知识库漂移了。

第七，安全边界。工具执行涉及外部系统时，要做最小权限授权。评测脚本也不应该访问生产环境敏感数据，日志中的用户个人信息必须脱敏。对任何涉及账号、支付、删除类操作的 Agent，建议在真实执行前增加人工审批节点。

10. 总结与后续学习方向

这篇文章想说明的核心问题是：Agent 评测不是“给最终答案打分”，而是“给整个执行过程建立证据链”。古典考据体系已经给了我们一套成熟的思考模型——来源链、传述人评级、文本批评、分级判定。把这套模型迁移到 Agent 评测上，你会得到一个根本不同的视角：你不再问“这个回答正确吗”，而是问“这个回答凭什么可信，可信到什么程度”。

在工程层面，我们演示了从轨迹记录、程序性检查、LLM-as-judge 到 A/B/C/D 分级的完整链路。代码量不大，但已经覆盖了 Agent 评测的核心骨架。你可以直接把它接到自己现有的 Agent 项目里，先让工具返回来源，再逐步加上程序性检查和评分。

如果你继续深入，建议研究这几个方向：多轮 Agent 评测，因为真实任务往往不是一轮结束；多智能体协作评测，因为不同角色的 Agent 之间会有责任划分问题；以及评测结果的可解释性，也就是如何让用户看到“为什么这个 Agent 被标记为存疑”。

最后想留一个思考题：如果你的 Agent 输出没有来源、没有轨迹、没有版本信息，你还敢把它接到生产环境里吗？答案如果是否定的，那你应该已经从今天开始，为你的 Agent 建立它自己的传述人档案了。