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 是一个复合系统大模型负责推理决策工具负责获取外部信息知识库负责提供领域事实代码逻辑负责把它们串起来。这意味着两个之前可以混在一起的问题现在必须分开模型本身的能力问题它不会规划、不会反思、不遵循指令。系统链路的问题工具返回错了、召回文档不相关、上下文被截断、来源冲突。只看最终答案你根本分不清是哪一个环节出错。我见过一个 Agent 面对“退货政策”提问时回答得有理有据结果后来查轨迹才发现检索器召回的是“会员积分规则”工具调用失败后 Agent 直接忽略错误继续按照自己的记忆编了一段答案。这种案例在最终答案层面几乎不可能被发现。所以 Agent 评测的第一个原则是必须把执行轨迹纳入评估对象。轨迹trajectory指的是 Agent 从接收输入到生成输出的完整过程包括每一步的决策、工具调用、检索结果、中间推理和最终组装。没有轨迹的 Agent 评测等于在黑暗里验货。2. 古典考据体系里值得借鉴的三层结构回到 Hacker News 那个问题。如果把圣训学者的工作方法抽象出来其实是一套非常完整的可信度验证框架至少包含三个层次。第一层是来源链。每一段话都不是凭空出现的它必须说明“由谁传给谁再传给谁”。这条链上的任何一环断裂可信度都要打折。对应到 Agent就是数据来源链最终答案是基于哪几个文档、哪几次工具输出、哪一段代码逻辑拼接出来的。如果无法回答“这句话是从哪里来的”这个输出就应该被标记为低置信度。第二层是传述人评级。古典体系里会对每个传述人的记忆力、诚实度、与权威观点的一致性做评估。传述人分等级有的被标记为“可信”有的被标记为“缺陷明显”。对应到 Agent这里的“传述人”不仅包括大模型还包括工具、插件、外部 API、知识库文档。每个环节都要有可靠性档案这个工具历史上返回错误的频率有多高这个知识库文档是正式版本还是临时草稿这个模型在处理这类推理任务时已知的失败模式是什么第三层是文本批评。即使来源链完整、传述人可靠内容本身还要接受交叉验证是否与其他可靠来源矛盾是否符合常识和逻辑对应到 Agent就是对最终答案做一致性校验多个独立文档是否指向同一结论工具结果是否支持模型最后的推理答案里有没有内部矛盾可以整理成一张表古典考据层次对应 Agent 评测要素关键问题来源链数据来源与工具调用链最终答案由哪些来源构成链路是否完整传述人评级模型能力档案 / 工具可靠性档案 / 文档质量档案每个环节是否可靠历史失败率如何文本批评交叉验证 / 一致性校验答案与来源是否矛盾多来源是否互相支持分级判定可靠性等级标签综合后应归入 A/B/C/D 哪一级这个映射关系是我认为这个问题真正有价值的地方古人早就设计好了一套“多节点可信度评估”的成熟范式而今天大多数 Agent 评测还停留在单点打分。3. 可落地的 Agent 评测框架五步法把上面的思路转成工程师能直接执行的方法我建议用五步法。这套方法不依赖特定框架也不绑定某个评估平台你可以在已有 Agent 代码上逐步加上去。第一步记录轨迹。改造 Agent让每一步工具调用、检索、中间输出都进入 trace。这是整条证据链的地基。第二步拆解阶段。把 Agent 流程拆成路由、检索、工具执行、生成、反思等环节每个环节单独评估而不是只评最终答案。第三步程序性检查。用确定性规则做闸门检查比如“最终答案是否包含来源”“工具是否调用成功”“是否存在占位符内容”。程序性检查不依赖大模型判断速度快、稳定适合做硬性过滤。第四步LLM-as-judge 评分。让一个独立的评测模型基于轨迹和答案按评分标准输出结构化分数。这里要注意评测模型最好与执行 Agent 不同降低“自己给自己打分”的偏差。第五步分级汇总。把程序性检查和 LLM 评分汇总成最终等级同时保留步骤级详细信息。分级不是为了让 Agent 失去资格而是让使用方明确知道风险边界。这个五步法并不复杂但能覆盖 Agent 评测里最关键的三个部分过程、结果、来源。接下来我们用代码把整条链路跑通。4. 环境准备与项目结构为了演示我会用最小依赖实现一个带知识库检索和计算工具的客服问答 Agent并给它配上评测脚本。环境如下Python 3.10 或 3.11openai 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_factorylist) dataclass class AgentResult: final_answer: str trace: list[TraceEvent] used_sources: list[str] field(default_factorylist) 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_answeranswer, tracetrace, used_sourceskb_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_answeranswer, tracetrace, used_sourceskb_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_answeranswer, tracetrace, used_sourcescalc_src) # 默认无法匹配时返回提示 answer 抱歉我暂时无法处理这个问题。 trace.append( TraceEvent(1, responder, fallback, query, answer, [no_route]) ) return AgentResult( final_answeranswer, tracetrace, 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_keyos.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_asciiFalse, defaultstr, ) user_prompt ( f输入问题{input_query}\n\n f执行轨迹{trace_text}\n\n f最终答案{result.final_answer} ) resp client.chat.completions.create( modelos.getenv(OPENAI_MODEL, gpt-4o-mini), messages[ {role: system, content: EVAL_SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], response_format{type: json_object}, temperature0, ) 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_llmFalse) print(json.dumps(report, ensure_asciiFalse, indent2)) print(- * 60)这段代码里我最想强调的程序性检查的优先级。它负责挡住那些“一眼假”的情况没有来源、工具报错、兜底话术。这些情况不需要大模型来判断直接用规则拦截能省下不少评测成本和误判风险。LLM-as-judge 则负责更细微的质量判断比如“答案是否忠实于来源”“推理过程是否存在矛盾”。这里我把评分维度定义成 0-5 分的 JSON 输出方便后续聚合和可视化。注意一点评测模型选择了temperature0目的是降低随机性让同一轨迹重复评分时结果尽可能稳定。分级函数把评分映射到四档。这个阈值不是固定的你可以根据业务风险调整。如果是金融、医疗场景建议把 A 级的门槛提高例如要求所有维度都是满分 5 分如果是内容推荐场景B 级可能已经可用。7. 运行结果与效果验证运行评测脚本python grade_agent.py由于默认没有配置OPENAI_API_KEY脚本会走use_llmFalse的演示分支。预期输出类似{ 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 根据轨迹输出真实评分。验证成功的标准有三个程序性检查所有项目返回true并且结果里没有出现kb_missing、no_route、error这类异常标记。最终答案能追溯到明确的来源文件来源不是空数组。分级结果符合直觉正常检索问题得到 B 或 A无来源问题得到 D。如果你配置了 OpenAI Key想跑真实评分可以单独写一个入口export OPENAI_API_KEYsk-xxx export OPENAI_MODELgpt-4o-mini python -c from grade_agent import evaluate_agent; r evaluate_agent(我 7 天前买的空调现在还能退吗, use_llmTrue); print(r)如果失败先检查网络是否能访问相应 API 服务再确认账号是否有该模型的调用权限。这个步骤依赖具体的模型服务配置不同环境差异较大。8. 常见问题与排查方法在实际落地这套评测体系时我遇到过一些高频问题整理成表格供你参考。问题现象可能原因排查方式解决方案轨迹里没有来源信息工具封装没有返回 sources 字段检查工具函数返回值结构所有工具统一返回(content, sources)结构Agent 回答错误但评级却是 ALLM judge 被最终答案迷惑查看 judge prompt 是否要求基于轨迹评分在评分维度里强制加入 faithfulness并要求给出依据同一输入重复评测结果波动大模型温度设置过高 / 轨迹中随机采样对比多次输出和评分评测时设置 temperature0多次运行取平均工具调用失败但 Agent 继续编答案Agent 缺少错误处理逻辑查看工具输出是否被忽略在 Agent 层检测工具失败标记强制停止或明确告知用户评级过于宽松所有结果都是 A分级阈值太低检查评分分布和阈值提高 A 级门槛并对评分维度设置最低分限制日志里出现敏感信息轨迹记录了用户原始输入和工具入参检查日志字段在落盘前做脱敏处理删除手机、邮箱、身份证等字段程序性检查和 LLM 评分冲突两者评价维度不完全一致对比具体冲突样本把程序性检查作为硬性闸门LLM 评分只负责质量维度其中最容易忽视的是“工具失败后 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 建立它自己的传述人档案了。
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 是一个复合系统大模型负责推理决策工具负责获取外部信息知识库负责提供领域事实代码逻辑负责把它们串起来。这意味着两个之前可以混在一起的问题现在必须分开模型本身的能力问题它不会规划、不会反思、不遵循指令。系统链路的问题工具返回错了、召回文档不相关、上下文被截断、来源冲突。只看最终答案你根本分不清是哪一个环节出错。我见过一个 Agent 面对“退货政策”提问时回答得有理有据结果后来查轨迹才发现检索器召回的是“会员积分规则”工具调用失败后 Agent 直接忽略错误继续按照自己的记忆编了一段答案。这种案例在最终答案层面几乎不可能被发现。所以 Agent 评测的第一个原则是必须把执行轨迹纳入评估对象。轨迹trajectory指的是 Agent 从接收输入到生成输出的完整过程包括每一步的决策、工具调用、检索结果、中间推理和最终组装。没有轨迹的 Agent 评测等于在黑暗里验货。2. 古典考据体系里值得借鉴的三层结构回到 Hacker News 那个问题。如果把圣训学者的工作方法抽象出来其实是一套非常完整的可信度验证框架至少包含三个层次。第一层是来源链。每一段话都不是凭空出现的它必须说明“由谁传给谁再传给谁”。这条链上的任何一环断裂可信度都要打折。对应到 Agent就是数据来源链最终答案是基于哪几个文档、哪几次工具输出、哪一段代码逻辑拼接出来的。如果无法回答“这句话是从哪里来的”这个输出就应该被标记为低置信度。第二层是传述人评级。古典体系里会对每个传述人的记忆力、诚实度、与权威观点的一致性做评估。传述人分等级有的被标记为“可信”有的被标记为“缺陷明显”。对应到 Agent这里的“传述人”不仅包括大模型还包括工具、插件、外部 API、知识库文档。每个环节都要有可靠性档案这个工具历史上返回错误的频率有多高这个知识库文档是正式版本还是临时草稿这个模型在处理这类推理任务时已知的失败模式是什么第三层是文本批评。即使来源链完整、传述人可靠内容本身还要接受交叉验证是否与其他可靠来源矛盾是否符合常识和逻辑对应到 Agent就是对最终答案做一致性校验多个独立文档是否指向同一结论工具结果是否支持模型最后的推理答案里有没有内部矛盾可以整理成一张表古典考据层次对应 Agent 评测要素关键问题来源链数据来源与工具调用链最终答案由哪些来源构成链路是否完整传述人评级模型能力档案 / 工具可靠性档案 / 文档质量档案每个环节是否可靠历史失败率如何文本批评交叉验证 / 一致性校验答案与来源是否矛盾多来源是否互相支持分级判定可靠性等级标签综合后应归入 A/B/C/D 哪一级这个映射关系是我认为这个问题真正有价值的地方古人早就设计好了一套“多节点可信度评估”的成熟范式而今天大多数 Agent 评测还停留在单点打分。3. 可落地的 Agent 评测框架五步法把上面的思路转成工程师能直接执行的方法我建议用五步法。这套方法不依赖特定框架也不绑定某个评估平台你可以在已有 Agent 代码上逐步加上去。第一步记录轨迹。改造 Agent让每一步工具调用、检索、中间输出都进入 trace。这是整条证据链的地基。第二步拆解阶段。把 Agent 流程拆成路由、检索、工具执行、生成、反思等环节每个环节单独评估而不是只评最终答案。第三步程序性检查。用确定性规则做闸门检查比如“最终答案是否包含来源”“工具是否调用成功”“是否存在占位符内容”。程序性检查不依赖大模型判断速度快、稳定适合做硬性过滤。第四步LLM-as-judge 评分。让一个独立的评测模型基于轨迹和答案按评分标准输出结构化分数。这里要注意评测模型最好与执行 Agent 不同降低“自己给自己打分”的偏差。第五步分级汇总。把程序性检查和 LLM 评分汇总成最终等级同时保留步骤级详细信息。分级不是为了让 Agent 失去资格而是让使用方明确知道风险边界。这个五步法并不复杂但能覆盖 Agent 评测里最关键的三个部分过程、结果、来源。接下来我们用代码把整条链路跑通。4. 环境准备与项目结构为了演示我会用最小依赖实现一个带知识库检索和计算工具的客服问答 Agent并给它配上评测脚本。环境如下Python 3.10 或 3.11openai 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_factorylist) dataclass class AgentResult: final_answer: str trace: list[TraceEvent] used_sources: list[str] field(default_factorylist) 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_answeranswer, tracetrace, used_sourceskb_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_answeranswer, tracetrace, used_sourceskb_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_answeranswer, tracetrace, used_sourcescalc_src) # 默认无法匹配时返回提示 answer 抱歉我暂时无法处理这个问题。 trace.append( TraceEvent(1, responder, fallback, query, answer, [no_route]) ) return AgentResult( final_answeranswer, tracetrace, 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_keyos.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_asciiFalse, defaultstr, ) user_prompt ( f输入问题{input_query}\n\n f执行轨迹{trace_text}\n\n f最终答案{result.final_answer} ) resp client.chat.completions.create( modelos.getenv(OPENAI_MODEL, gpt-4o-mini), messages[ {role: system, content: EVAL_SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], response_format{type: json_object}, temperature0, ) 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_llmFalse) print(json.dumps(report, ensure_asciiFalse, indent2)) print(- * 60)这段代码里我最想强调的程序性检查的优先级。它负责挡住那些“一眼假”的情况没有来源、工具报错、兜底话术。这些情况不需要大模型来判断直接用规则拦截能省下不少评测成本和误判风险。LLM-as-judge 则负责更细微的质量判断比如“答案是否忠实于来源”“推理过程是否存在矛盾”。这里我把评分维度定义成 0-5 分的 JSON 输出方便后续聚合和可视化。注意一点评测模型选择了temperature0目的是降低随机性让同一轨迹重复评分时结果尽可能稳定。分级函数把评分映射到四档。这个阈值不是固定的你可以根据业务风险调整。如果是金融、医疗场景建议把 A 级的门槛提高例如要求所有维度都是满分 5 分如果是内容推荐场景B 级可能已经可用。7. 运行结果与效果验证运行评测脚本python grade_agent.py由于默认没有配置OPENAI_API_KEY脚本会走use_llmFalse的演示分支。预期输出类似{ 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 根据轨迹输出真实评分。验证成功的标准有三个程序性检查所有项目返回true并且结果里没有出现kb_missing、no_route、error这类异常标记。最终答案能追溯到明确的来源文件来源不是空数组。分级结果符合直觉正常检索问题得到 B 或 A无来源问题得到 D。如果你配置了 OpenAI Key想跑真实评分可以单独写一个入口export OPENAI_API_KEYsk-xxx export OPENAI_MODELgpt-4o-mini python -c from grade_agent import evaluate_agent; r evaluate_agent(我 7 天前买的空调现在还能退吗, use_llmTrue); print(r)如果失败先检查网络是否能访问相应 API 服务再确认账号是否有该模型的调用权限。这个步骤依赖具体的模型服务配置不同环境差异较大。8. 常见问题与排查方法在实际落地这套评测体系时我遇到过一些高频问题整理成表格供你参考。问题现象可能原因排查方式解决方案轨迹里没有来源信息工具封装没有返回 sources 字段检查工具函数返回值结构所有工具统一返回(content, sources)结构Agent 回答错误但评级却是 ALLM judge 被最终答案迷惑查看 judge prompt 是否要求基于轨迹评分在评分维度里强制加入 faithfulness并要求给出依据同一输入重复评测结果波动大模型温度设置过高 / 轨迹中随机采样对比多次输出和评分评测时设置 temperature0多次运行取平均工具调用失败但 Agent 继续编答案Agent 缺少错误处理逻辑查看工具输出是否被忽略在 Agent 层检测工具失败标记强制停止或明确告知用户评级过于宽松所有结果都是 A分级阈值太低检查评分分布和阈值提高 A 级门槛并对评分维度设置最低分限制日志里出现敏感信息轨迹记录了用户原始输入和工具入参检查日志字段在落盘前做脱敏处理删除手机、邮箱、身份证等字段程序性检查和 LLM 评分冲突两者评价维度不完全一致对比具体冲突样本把程序性检查作为硬性闸门LLM 评分只负责质量维度其中最容易忽视的是“工具失败后 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 建立它自己的传述人档案了。