当 AI Agent 在业务里越跑越深大家心里其实都清楚一个隐患同一个 Agent昨天输出干净利落今天可能就会在关键结论上张冠李戴。你给它做了 benchmark它分数漂亮一进生产环境面对真实请求可靠性立刻变得难以捉摸。最近我在 Hacker News 上看到一个很有启发性的提问为什么我们不沿用圣训传述人评价的逻辑来给 AI Agent 评级初看会以为是一个历史考据爱好者在开脑洞但认真想一想这个类比恰好击中了 AI Agent 评估体系中的一个真实缺口——我们对模型有评测对 Agent 却缺少一套“长期可信度追踪”的方法论。这篇文章不打算停留在哲学类比层面。我会先拆解古典传述人评价体系的核心方法论再把它映射到现代 AI Agent 评估中最后用一套可运行的 Python 评估框架演示如何为一个 Agent 建立“信誉档案”输出类似“可靠 / 诚实 / 尚可 / 弱 / 弃用”的等级评价。无论你是做 AI 应用开发、大模型工程实践还是在团队里负责 Agent 的安全合规治理这套思路都能直接落地。1. 从传述人评价说起古代“事实核查”的方法论遗产1.1 传述链记录“谁把话说给了谁”在古典文献考据传统中验证一段文字是否可信首先要看它的传播路径。所谓传述链Isnad就是一条完整的信息传递路径A 听 B 说B 听 C 说C 听 D 说最终追溯到最初的那个权威来源。如果这条链断了、模糊了或者中间某个人身份不明整段文字的可信度就会大打折扣。传述链思想放到今天毫不陌生——学术论文要标注参考文献新闻要写明信息来源开源代码要有 commit 历史。它们都在做同一件事让信息的传播路径可追溯。现代 AI Agent 的 tool call 日志本质上就是一种“传述链”用户提出问题 → Agent 搜索网页 → 解析数据 → 调用计算函数 → 生成最终回答。这一整条链路如果不完整后面的回答再漂亮也无法取信于人。1.2 传述人个体评估链条重要但链条上的“人”更重要。传统考据学发展出一套专门研究传述人个体的方法论中文通常翻译为人物学Ilm al-Rijal核心研究三个问题这个人是否诚实记忆力是否可靠是否容易混淆相似内容研究者会收集传述人的生平、学术背景、同侪评价、言行记录形成一份“人物档案”。一个人如果曾经故意修改内容即使后来有所改正他的传述也会被降级。这套方法论对 Agent 评估非常对症。我们团队在落地 Agent 时经常会遇到类似情况某个 Agent 上一周表现很好这一周因为上游数据源变化错误率突然上升。如果只看“单次任务结果”你很难判断这是偶发问题还是系统性问题。可如果你像人物学家一样持续记录 Agent 的“行为档案”每次任务结束后都评估一次滚动更新分数很快就能发现趋势变化。1.3 双轨校验与分级除了考察传述人个体传统考据学还有一个非常重要的双轨校验机制传述链校验和文本校验。传述链校验回答“这条消息从哪来”文本校验回答“这条消息本身是否合理”。两条线交叉验证才构成完整的证据链。基于这些评估古人给出了精细的分级最可靠的称为“可靠Thiqah”稍次称为“诚实Saduq”再往下有“尚可”“弱Da‘if”和“被弃Matruk”。同一个传述人在不同文本、不同传述链上的表现会被持续追踪形成不断更新的信誉档案。这个“分级 滚动追踪”的体系正是当代 AI Agent 评估最缺少的部分。2. 当代 AI Agent 的可信度危机2.1 Agent 和单次模型调用有本质区别传统 LLM 评测非常简单给模型一个 prompt看输出。但 Agent 不是这样——Agent 有工具调用、多步推理、任务拆解、自我修正一个任务往往要运行很多步。因此Agent 的错误往往是“过程性”的它可能把昨天的数据当成了今天的可能在调用外部工具时没有校验返回格式可能在没有足够证据时直接下结论。这些错误很难用“准确率”来概括。它更像是“这个执行者值不值得信任”的问题。举个实际例子一个客服 Agent 在回答用户退换货政策时先搜索了公司公告但找到的是一个月前的旧政策于是给出了错误答复。从结果上看它“答错了”从过程上看它“找到了错误来源”。如果没有工具调用链审计你根本定位不到根因。2.2 现有评估方法解决了哪些问题留下了哪些缺口目前社区常用的评估方式无非几类评估方式优点局限性BLEU / ROUGE 等文本指标简单、可快速计算只看文本相似度对语义正确性几乎无感Benchmark 数据集覆盖面广可以横向对比长尾场景覆盖不足容易过拟合LLM-as-judge灵活、便宜、可扩展裁判模型本身有偏差和幻觉人工评估最接近真实质量成本极高无法规模化金标准数据库对照事实性校验准确需要维护高质量数据覆盖有限这些方法有一个共同缺陷它们只测“单次任务结果”不追踪“行为历史”。就像只看一个人某一句话说得对不对而不去查阅他过去是否经常撒谎。这恰好是传统传述人评价体系最重视的地方——长期信誉记录。单次评估是“考试”持续评估才是“档案”。3. 从传述人评价到 Agent 评价方法论映射3.1 四个核心维度的映射传统传述人评价的核心维度可以一一映射到 AI Agent 评估指标上。这不是生搬硬套而是因为两者面对的信息可信度问题在结构上高度相似。传述人评价维度原始含义AI Agent 对应指标诚实性是否如实传递信息、有无篡改动机事实一致性、幻觉率记忆力是否准确记住并再现内容长上下文一致性、知识回溯能力溯源性传述链是否完整、上源是否可靠工具调用链完整性、引用来源可追溯性行为合规传述人品行是否端正工具权限合规、隐私保护、请求策略交叉验证多条传述链互证多模型 / 多源验证、可复现性诚实性是最重要的一层。一个 Agent 可能因为上下文太长、数据源冲突、prompt 被注入等原因产生幻觉说出看似合理但实际错误的内容。传统考据学对“故意篡改”和“记忆偏差”会做不同处理Agent 评估也应该区分“故意绕过规则”和“模型能力不足导致的偏差”。前者需要安全治理介入后者主要靠模型迭代和 prompt 优化。记忆力对应的是 Agent 在多轮对话、长任务中的一致性。一个 Agent 如果在第一轮告诉用户“库存充足”第二轮却说“缺货”那它在“记忆力”维度上就应该被扣分。这种问题在复杂业务场景中非常常见尤其是 Agent 需要跨多个工具查询数据、再汇总结果时。溯源性则是 Agent 评估里最容易量化的部分。我们可以审计 Agent 的每一次工具调用它查了哪些数据源调用了哪些函数传参是否正确返回结果有没有被真实使用这些信息和传统考据学的“传述链”概念几乎一一对应。3.2 为什么不能只测结果结果指标只能告诉你 Agent“这次对不对”不能告诉你 Agent“下次对不对”。在真实生产环境中一个 Agent 需要持续运行几周、几个月接触各种各样的输入。这就要求评测体系从“一次考试”变成“档案追踪”——把每一次任务的表现记录在案滚动更新信任等级。这和传述人评价的思路完全一致不以一次传述定优劣而以长期记录分等级。从工程实践来看这意味着你需要为每个 Agent 建立一套可累计、可回溯的评估数据模型并在 Agent 每次完成一个任务后自动运行一次评估得到新证据更新旧档案。下面我们就用代码来实现这个框架。4. 实战实现一个“Agent 传述人评级”评估框架4.1 环境与项目结构本文示例使用 Python 3.9核心评估逻辑只用标准库不依赖任何特定大模型 SDK。如果你要接入真实 Agent可以在外围通过 OpenAI、Anthropic、Spring AI 等任意 SDK 获取输出和工具调用日志然后交给评估器处理。项目结构如下agent-reliability-eval/ ├── agent_eval/ │ ├── __init__.py │ ├── domain.py # 评级枚举、证据模型、报告模型 │ ├── evaluator.py # 核心评估器 │ └── tool_audit.py # 工具调用链审计 ├── demo.py # 模拟演示 └── README.md先创建虚拟环境并初始化项目目录mkdir agent-reliability-eval cd agent-reliability-eval python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate4.2 定义评价维度和等级第一个文件是领域模型层。这里我们把传统传述人评价的四个核心维度映射成 Python 数据结构。评级枚举直接对标古典分级体系。# 文件路径: agent_eval/domain.py 评价领域模型等级、证据、报告。 from dataclasses import dataclass, field from typing import List, Dict from enum import Enum class Grade(Enum): THIQAH 可靠 (Thiqah) SADUQ 诚实 (Saduq) SADUQ_HADITH 尚可 (Saduq Hadith) DAIF 弱 (Daif) MATRUK 弃用 (Matruk) DIMENSIONS { sidq: 事实一致性, dabt: 稳定性可复现性, isnad: 溯源完整性, adalah: 行为合规性, } dataclass class EvidenceItem: 一条评估证据 dimension: str # 所属维度如 sidq source: str # 证据来源如 fact_check / tool_audit passed: bool # 该证据是否通过 detail: str # 细节描述 confidence: float 1.0 # 证据置信度 dataclass class EvaluationReport: 评价报告 agent_name: str task_id: str evidence: List[EvidenceItem] field(default_factorylist) dimension_scores: Dict[str, float] field(default_factorydict) overall_score: float 0.0 grade: Grade Grade.MATRUK def to_markdown(self): lines [] lines.append(f## 评估报告{self.agent_name}) lines.append(f- 任务ID{self.task_id}) lines.append(f- 综合评分{self.overall_score:.1f} / 100) lines.append(f- 综合等级{self.grade.value}) lines.append() lines.append(| 维度 | 得分 | 判断 |) lines.append(| --- | --- | --- |) for dim, score in self.dimension_scores.items(): passed_label 通过 if score 60 else 不通过 lines.append(f| {DIMENSIONS.get(dim, dim)} | {score:.1f} | {passed_label} |) lines.append() lines.append(### 证据明细) for e in self.evidence: status PASS if e.passed else FAIL dim_name DIMENSIONS.get(e.dimension, e.dimension) lines.append(f- [{status}] ({dim_name}) {e.source}: {e.detail}) return \n.join(lines)这段代码里Grade枚举就是 Agent 的最终“评级”结果。EvidenceItem表示一条具体的评估证据比如“事实核验通过”“工具链缺失一步”。每个评价维度下可以收集多条证据最后通过加权汇总得到综合得分。EvaluationReport.to_markdown()则负责把报告渲染成 Markdown方便直接贴进内部文档或日志系统。4.3 核心评估器实现第二个文件是核心评估器。它接收多条证据按维度分组通过加权平均计算每个维度的得分再按权重汇总成总分最后映射到等级。# 文件路径: agent_eval/evaluator.py 核心评估器聚合证据计算维度得分输出等级。 from collections import defaultdict from typing import List from .domain import DIMENSIONS, EvidenceItem, EvaluationReport, Grade class ReliabilityEvaluator: # 权重设计可根据业务调整 WEIGHTS { sidq: 0.3, dabt: 0.2, isnad: 0.3, adalah: 0.2, } # 等级阈值 GRADE_THRESHOLDS [ (Grade.THIQAH, 90), (Grade.SADUQ, 75), (Grade.SADUQ_HADITH, 60), (Grade.DAIF, 40), (Grade.MATRUK, 0), ] def __init__(self, agent_name: str, task_id: str): self.agent_name agent_name self.task_id task_id self.evidence: List[EvidenceItem] [] def add_evidence(self, dimension: str, source: str, passed: bool, detail: str, confidence: float 1.0): 添加一条评估证据 item EvidenceItem( dimensiondimension, sourcesource, passedpassed, detaildetail, confidenceconfidence, ) self.evidence.append(item) def evaluate(self) - EvaluationReport: 聚合证据计算最终评级 dim_items defaultdict(list) for item in self.evidence: dim_items[item.dimension].append(item) dimension_scores {} for dim in DIMENSIONS: items dim_items.get(dim, []) if not items: dimension_scores[dim] 0.0 continue total_weight 0.0 total_score 0.0 for item in items: w item.confidence total_weight w total_score (100.0 if item.passed else 0.0) * w dimension_scores[dim] total_score / total_weight overall_score sum( dimension_scores.get(dim, 0.0) * weight for dim, weight in self.WEIGHTS.items() ) grade self._score_to_grade(overall_score) return EvaluationReport( agent_nameself.agent_name, task_idself.task_id, evidenceself.evidence, dimension_scoresdimension_scores, overall_scoreoverall_score, gradegrade, ) def _score_to_grade(self, score: float) - Grade: for grade, threshold in self.GRADE_THRESHOLDS: if score threshold: return grade return Grade.MATRUK这里有两个点值得展开。第一权重设计非常重要。在传统考据学里“诚实性”的权重要高于“记忆力”因为一个人如果能记住但故意撒谎比记性差的人更危险。在 Agent 评估中事实一致性和溯源完整性的权重也应该更高因为它们直接决定 Agent 输出是否可信。本文示例权重是事实一致性 0.3、溯源完整性 0.3、稳定性 0.2、合规性 0.2你可以按业务风险偏好调整。第二证据置信度的设计。不是所有证据来源都同样可靠直接通过数据库校验得到的事实证据置信度可以给 1.0而 LLM-as-judge 给出的判断置信度可能只有 0.7。用置信度作为权重能有效防止低质量证据主导评级结果。4.4 工具调用链审计第三个文件专门处理“溯源完整性”。在实际项目中Agent 框架通常会记录完整的工具调用日志我们可以从中提取出“实际调用链”再和“期望调用链”做比对。# 文件路径: agent_eval/tool_audit.py 工具调用链审计验证 Agent 是否按预期步骤完成工作。 from typing import List, Dict, Tuple def audit_tool_chain( tool_calls: List[Dict], expected_chain: List[str] ) - Tuple[bool, List[str]]: 校验实际工具调用链与预期链路是否一致。 参数: tool_calls: 工具调用记录例如 [{tool: search, input: 北京天气}, ...] expected_chain: 期望的工具顺序例如 [search, parse, compute] 返回: (是否一致, 实际链路) actual_chain [call.get(tool) for call in tool_calls] if actual_chain expected_chain: return True, actual_chain mismatches [] for i, (actual, expected) in enumerate(zip(actual_chain, expected_chain)): if actual ! expected: mismatches.append(f第{i 1}步应为 {expected}实际是 {actual}) if len(actual_chain) ! len(expected_chain): mismatches.append( f调用链长度不一致实际 {len(actual_chain)} 步期望 {len(expected_chain)} 步 ) return False, actual_chain这段代码虽然简单但解决的是一个核心问题Agent 有没有按照预期路径完成任务如果期望链路是[search, parse, compute]某个 Agent 却跳过了parse直接compute那么它虽然可能结果正确但过程是不透明的后续排查成本和风险都很高。在评估体系中这种过程缺陷会直接导致“溯源完整性”维度扣分。4.5 模拟案例天气查询 Agent现在我们把整个框架串起来。下面这个 demo 模拟一个天气查询 Agent 的完整评估流程Agent 先搜索天气再解析结果最后判断是否需要带伞。我们用评估器分别从事实一致性、溯源完整性、稳定性、合规性四个维度打分。# 文件路径: demo.py 演示使用评估器对一个模拟天气查询 Agent 进行评级。 from agent_eval.evaluator import ReliabilityEvaluator from agent_eval.tool_audit import audit_tool_chain def run_demo(agent_name: str weather-agent-v1): task_id task-20240614-001 # 模拟 Agent 的工具调用日志真实场景中由 Agent 框架给出 tool_calls [ {tool: search, input: 北京今日天气, return: 晴25℃}, {tool: parse, input: raw_page, return: 北京 晴 25℃}, {tool: compute, input: 要不要带伞, return: 不需要}, ] # Agent 最终回答 final_answer 北京今天晴天气温25℃不需要带伞。 # 外部事实源模拟人工或数据库校验结果 ground_truth 北京 晴25℃ # 1. 构建评估器 evaluator ReliabilityEvaluator(agent_nameagent_name, task_idtask_id) # 2. 事实一致性sidq fact_consistent ground_truth in final_answer evaluator.add_evidence( dimensionsidq, sourcefact_check, passedfact_consistent, detail最终回答与外部事实源是否一致, confidence0.9, ) # 3. 溯源完整性isnad chain_ok, actual_chain audit_tool_chain( tool_calls, expected_chain[search, parse, compute], ) evaluator.add_evidence( dimensionisnad, sourcetool_audit, passedchain_ok, detailf工具调用链{ - .join(actual_chain)}, confidence1.0, ) # 4. 稳定性dabt重复运行两次结果是否一致模拟 result_twice 北京今天晴天气温25℃不需要带伞。 stability_ok result_twice final_answer evaluator.add_evidence( dimensiondabt, sourcereproducibility, passedstability_ok, detail重复执行两次回答是否一致, confidence0.8, ) # 5. 行为合规性adalah compliant all( call.get(tool) in {search, parse, compute} for call in tool_calls ) evaluator.add_evidence( dimensionadalah, sourcepolicy_audit, passedcompliant, detail未调用越权工具未输出无关隐私信息, confidence1.0, ) # 6. 输出报告 report evaluator.evaluate() print(report.to_markdown()) return report if __name__ __main__: report run_demo() print(f\n综合等级: {report.grade.value})运行命令cd agent-reliability-eval python demo.py预期输出效果如下## 评估报告weather-agent-v1 - 任务IDtask-20240614-001 - 综合评分100.0 / 100 - 综合等级可靠 (Thiqah) | 维度 | 得分 | 判断 | | --- | --- | --- | | 事实一致性 | 100.0 | 通过 | | 稳定性可复现性 | 100.0 | 通过 | | 溯源完整性 | 100.0 | 通过 | | 行为合规性 | 100.0 | 通过 | ### 证据明细 - [PASS] (事实一致性) fact_check: 最终回答与外部事实源是否一致 - [PASS] (溯源完整性) tool_audit: 工具调用链search - parse - compute - [PASS] (稳定性可复现性) reproducibility: 重复执行两次回答是否一致 - [PASS] (行为合规性) policy_audit: 未调用越权工具未输出无关隐私信息 综合等级: 可靠 (Thiqah)你可以在 demo 里故意改坏一个环节比如让工具调用链变成[search, compute]或者让final_answer缺少数值评估器就会自动把对应维度分数拉低最终降级到“诚实”甚至“尚可”。这个机制正是“传述人评级”的核心——一次失误不会直接否定 Agent但会真实地反映在等级上。5. 让评级体系适配真实生产环境真实的 Agent 场景远比上面的天气查询复杂。要让这套评估体系真正落地还需要考虑几个工程化问题。5.1 证据来源的自动化在 demo 中证据是手工构造的。生产环境需要自动化采集证据。通常的做法是把评估器接入 Agent 框架的中间件在每次任务结束后自动触发。需要采集的证据包括工具调用日志从 Agent 框架的 Tracing 系统拉取解析出工具名、参数、返回值。事实核验结果如果 Agent 的业务涉及数据库或知识库查询可以将最终回答与查询结果做自动比对。用户反馈真实用户的点赞、点踩、投诉是一种天然的人工评估信号。LLM-as-judge 打分让大模型对 Agent 的回答质量做初步判断但是要注意置信度权重不能设太高因为它本身不一定可靠。这些证据会以EvidenceItem的形式写入评估器最终沉淀到EvaluationReport。5.2 滚动窗口与长期档案一次任务的评级没有太大意义只有长期积累才具备参考价值。工程上建议为每个 Agent 维护一张“信誉档案表”存储结构大致如下CREATE TABLE agent_reputation ( agent_name VARCHAR(64) PRIMARY KEY, total_tasks INT DEFAULT 0, pass_tasks INT DEFAULT 0, avg_overall_score DECIMAL(5,2) DEFAULT 0, current_grade VARCHAR(32), updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );每次评估完成后更新total_tasks、pass_tasks、avg_overall_score并根据最新 N 次任务的平均分重新计算current_grade。这里建议使用滑动窗口而不是全量累加比如只取最近 100 次任务更贴近“近期表现”避免很久以前的问题一直压着评分。5.3 基于评级的访问控制评级体系一旦建立就可以把它作为 Agent 权限控制的依据。这一点和传统考据学中的“采用规则”非常相似高等级传述人的传述可以被采信低等级的需要辅助证据。在实际业务中可以这样设计AGENT_GRADE_POLICY { weather-agent-v1: { grade: Grade.SADUQ, allowed_actions: [query_weather, query_express], need_manual_approval: True, risk_level: medium, }, search-agent-v1: { grade: Grade.THIQAH, allowed_actions: [search, summarize], need_manual_approval: False, risk_level: low, }, } def check_agent_permission(agent_name: str, action: str) - bool: 根据 Agent 的信誉等级和策略判断是否允许执行某个动作。 policy AGENT_GRADE_POLICY.get(agent_name) if AI Agent可靠性评估：基于传述人评级思想的信誉档案与分级体系
当 AI Agent 在业务里越跑越深大家心里其实都清楚一个隐患同一个 Agent昨天输出干净利落今天可能就会在关键结论上张冠李戴。你给它做了 benchmark它分数漂亮一进生产环境面对真实请求可靠性立刻变得难以捉摸。最近我在 Hacker News 上看到一个很有启发性的提问为什么我们不沿用圣训传述人评价的逻辑来给 AI Agent 评级初看会以为是一个历史考据爱好者在开脑洞但认真想一想这个类比恰好击中了 AI Agent 评估体系中的一个真实缺口——我们对模型有评测对 Agent 却缺少一套“长期可信度追踪”的方法论。这篇文章不打算停留在哲学类比层面。我会先拆解古典传述人评价体系的核心方法论再把它映射到现代 AI Agent 评估中最后用一套可运行的 Python 评估框架演示如何为一个 Agent 建立“信誉档案”输出类似“可靠 / 诚实 / 尚可 / 弱 / 弃用”的等级评价。无论你是做 AI 应用开发、大模型工程实践还是在团队里负责 Agent 的安全合规治理这套思路都能直接落地。1. 从传述人评价说起古代“事实核查”的方法论遗产1.1 传述链记录“谁把话说给了谁”在古典文献考据传统中验证一段文字是否可信首先要看它的传播路径。所谓传述链Isnad就是一条完整的信息传递路径A 听 B 说B 听 C 说C 听 D 说最终追溯到最初的那个权威来源。如果这条链断了、模糊了或者中间某个人身份不明整段文字的可信度就会大打折扣。传述链思想放到今天毫不陌生——学术论文要标注参考文献新闻要写明信息来源开源代码要有 commit 历史。它们都在做同一件事让信息的传播路径可追溯。现代 AI Agent 的 tool call 日志本质上就是一种“传述链”用户提出问题 → Agent 搜索网页 → 解析数据 → 调用计算函数 → 生成最终回答。这一整条链路如果不完整后面的回答再漂亮也无法取信于人。1.2 传述人个体评估链条重要但链条上的“人”更重要。传统考据学发展出一套专门研究传述人个体的方法论中文通常翻译为人物学Ilm al-Rijal核心研究三个问题这个人是否诚实记忆力是否可靠是否容易混淆相似内容研究者会收集传述人的生平、学术背景、同侪评价、言行记录形成一份“人物档案”。一个人如果曾经故意修改内容即使后来有所改正他的传述也会被降级。这套方法论对 Agent 评估非常对症。我们团队在落地 Agent 时经常会遇到类似情况某个 Agent 上一周表现很好这一周因为上游数据源变化错误率突然上升。如果只看“单次任务结果”你很难判断这是偶发问题还是系统性问题。可如果你像人物学家一样持续记录 Agent 的“行为档案”每次任务结束后都评估一次滚动更新分数很快就能发现趋势变化。1.3 双轨校验与分级除了考察传述人个体传统考据学还有一个非常重要的双轨校验机制传述链校验和文本校验。传述链校验回答“这条消息从哪来”文本校验回答“这条消息本身是否合理”。两条线交叉验证才构成完整的证据链。基于这些评估古人给出了精细的分级最可靠的称为“可靠Thiqah”稍次称为“诚实Saduq”再往下有“尚可”“弱Da‘if”和“被弃Matruk”。同一个传述人在不同文本、不同传述链上的表现会被持续追踪形成不断更新的信誉档案。这个“分级 滚动追踪”的体系正是当代 AI Agent 评估最缺少的部分。2. 当代 AI Agent 的可信度危机2.1 Agent 和单次模型调用有本质区别传统 LLM 评测非常简单给模型一个 prompt看输出。但 Agent 不是这样——Agent 有工具调用、多步推理、任务拆解、自我修正一个任务往往要运行很多步。因此Agent 的错误往往是“过程性”的它可能把昨天的数据当成了今天的可能在调用外部工具时没有校验返回格式可能在没有足够证据时直接下结论。这些错误很难用“准确率”来概括。它更像是“这个执行者值不值得信任”的问题。举个实际例子一个客服 Agent 在回答用户退换货政策时先搜索了公司公告但找到的是一个月前的旧政策于是给出了错误答复。从结果上看它“答错了”从过程上看它“找到了错误来源”。如果没有工具调用链审计你根本定位不到根因。2.2 现有评估方法解决了哪些问题留下了哪些缺口目前社区常用的评估方式无非几类评估方式优点局限性BLEU / ROUGE 等文本指标简单、可快速计算只看文本相似度对语义正确性几乎无感Benchmark 数据集覆盖面广可以横向对比长尾场景覆盖不足容易过拟合LLM-as-judge灵活、便宜、可扩展裁判模型本身有偏差和幻觉人工评估最接近真实质量成本极高无法规模化金标准数据库对照事实性校验准确需要维护高质量数据覆盖有限这些方法有一个共同缺陷它们只测“单次任务结果”不追踪“行为历史”。就像只看一个人某一句话说得对不对而不去查阅他过去是否经常撒谎。这恰好是传统传述人评价体系最重视的地方——长期信誉记录。单次评估是“考试”持续评估才是“档案”。3. 从传述人评价到 Agent 评价方法论映射3.1 四个核心维度的映射传统传述人评价的核心维度可以一一映射到 AI Agent 评估指标上。这不是生搬硬套而是因为两者面对的信息可信度问题在结构上高度相似。传述人评价维度原始含义AI Agent 对应指标诚实性是否如实传递信息、有无篡改动机事实一致性、幻觉率记忆力是否准确记住并再现内容长上下文一致性、知识回溯能力溯源性传述链是否完整、上源是否可靠工具调用链完整性、引用来源可追溯性行为合规传述人品行是否端正工具权限合规、隐私保护、请求策略交叉验证多条传述链互证多模型 / 多源验证、可复现性诚实性是最重要的一层。一个 Agent 可能因为上下文太长、数据源冲突、prompt 被注入等原因产生幻觉说出看似合理但实际错误的内容。传统考据学对“故意篡改”和“记忆偏差”会做不同处理Agent 评估也应该区分“故意绕过规则”和“模型能力不足导致的偏差”。前者需要安全治理介入后者主要靠模型迭代和 prompt 优化。记忆力对应的是 Agent 在多轮对话、长任务中的一致性。一个 Agent 如果在第一轮告诉用户“库存充足”第二轮却说“缺货”那它在“记忆力”维度上就应该被扣分。这种问题在复杂业务场景中非常常见尤其是 Agent 需要跨多个工具查询数据、再汇总结果时。溯源性则是 Agent 评估里最容易量化的部分。我们可以审计 Agent 的每一次工具调用它查了哪些数据源调用了哪些函数传参是否正确返回结果有没有被真实使用这些信息和传统考据学的“传述链”概念几乎一一对应。3.2 为什么不能只测结果结果指标只能告诉你 Agent“这次对不对”不能告诉你 Agent“下次对不对”。在真实生产环境中一个 Agent 需要持续运行几周、几个月接触各种各样的输入。这就要求评测体系从“一次考试”变成“档案追踪”——把每一次任务的表现记录在案滚动更新信任等级。这和传述人评价的思路完全一致不以一次传述定优劣而以长期记录分等级。从工程实践来看这意味着你需要为每个 Agent 建立一套可累计、可回溯的评估数据模型并在 Agent 每次完成一个任务后自动运行一次评估得到新证据更新旧档案。下面我们就用代码来实现这个框架。4. 实战实现一个“Agent 传述人评级”评估框架4.1 环境与项目结构本文示例使用 Python 3.9核心评估逻辑只用标准库不依赖任何特定大模型 SDK。如果你要接入真实 Agent可以在外围通过 OpenAI、Anthropic、Spring AI 等任意 SDK 获取输出和工具调用日志然后交给评估器处理。项目结构如下agent-reliability-eval/ ├── agent_eval/ │ ├── __init__.py │ ├── domain.py # 评级枚举、证据模型、报告模型 │ ├── evaluator.py # 核心评估器 │ └── tool_audit.py # 工具调用链审计 ├── demo.py # 模拟演示 └── README.md先创建虚拟环境并初始化项目目录mkdir agent-reliability-eval cd agent-reliability-eval python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate4.2 定义评价维度和等级第一个文件是领域模型层。这里我们把传统传述人评价的四个核心维度映射成 Python 数据结构。评级枚举直接对标古典分级体系。# 文件路径: agent_eval/domain.py 评价领域模型等级、证据、报告。 from dataclasses import dataclass, field from typing import List, Dict from enum import Enum class Grade(Enum): THIQAH 可靠 (Thiqah) SADUQ 诚实 (Saduq) SADUQ_HADITH 尚可 (Saduq Hadith) DAIF 弱 (Daif) MATRUK 弃用 (Matruk) DIMENSIONS { sidq: 事实一致性, dabt: 稳定性可复现性, isnad: 溯源完整性, adalah: 行为合规性, } dataclass class EvidenceItem: 一条评估证据 dimension: str # 所属维度如 sidq source: str # 证据来源如 fact_check / tool_audit passed: bool # 该证据是否通过 detail: str # 细节描述 confidence: float 1.0 # 证据置信度 dataclass class EvaluationReport: 评价报告 agent_name: str task_id: str evidence: List[EvidenceItem] field(default_factorylist) dimension_scores: Dict[str, float] field(default_factorydict) overall_score: float 0.0 grade: Grade Grade.MATRUK def to_markdown(self): lines [] lines.append(f## 评估报告{self.agent_name}) lines.append(f- 任务ID{self.task_id}) lines.append(f- 综合评分{self.overall_score:.1f} / 100) lines.append(f- 综合等级{self.grade.value}) lines.append() lines.append(| 维度 | 得分 | 判断 |) lines.append(| --- | --- | --- |) for dim, score in self.dimension_scores.items(): passed_label 通过 if score 60 else 不通过 lines.append(f| {DIMENSIONS.get(dim, dim)} | {score:.1f} | {passed_label} |) lines.append() lines.append(### 证据明细) for e in self.evidence: status PASS if e.passed else FAIL dim_name DIMENSIONS.get(e.dimension, e.dimension) lines.append(f- [{status}] ({dim_name}) {e.source}: {e.detail}) return \n.join(lines)这段代码里Grade枚举就是 Agent 的最终“评级”结果。EvidenceItem表示一条具体的评估证据比如“事实核验通过”“工具链缺失一步”。每个评价维度下可以收集多条证据最后通过加权汇总得到综合得分。EvaluationReport.to_markdown()则负责把报告渲染成 Markdown方便直接贴进内部文档或日志系统。4.3 核心评估器实现第二个文件是核心评估器。它接收多条证据按维度分组通过加权平均计算每个维度的得分再按权重汇总成总分最后映射到等级。# 文件路径: agent_eval/evaluator.py 核心评估器聚合证据计算维度得分输出等级。 from collections import defaultdict from typing import List from .domain import DIMENSIONS, EvidenceItem, EvaluationReport, Grade class ReliabilityEvaluator: # 权重设计可根据业务调整 WEIGHTS { sidq: 0.3, dabt: 0.2, isnad: 0.3, adalah: 0.2, } # 等级阈值 GRADE_THRESHOLDS [ (Grade.THIQAH, 90), (Grade.SADUQ, 75), (Grade.SADUQ_HADITH, 60), (Grade.DAIF, 40), (Grade.MATRUK, 0), ] def __init__(self, agent_name: str, task_id: str): self.agent_name agent_name self.task_id task_id self.evidence: List[EvidenceItem] [] def add_evidence(self, dimension: str, source: str, passed: bool, detail: str, confidence: float 1.0): 添加一条评估证据 item EvidenceItem( dimensiondimension, sourcesource, passedpassed, detaildetail, confidenceconfidence, ) self.evidence.append(item) def evaluate(self) - EvaluationReport: 聚合证据计算最终评级 dim_items defaultdict(list) for item in self.evidence: dim_items[item.dimension].append(item) dimension_scores {} for dim in DIMENSIONS: items dim_items.get(dim, []) if not items: dimension_scores[dim] 0.0 continue total_weight 0.0 total_score 0.0 for item in items: w item.confidence total_weight w total_score (100.0 if item.passed else 0.0) * w dimension_scores[dim] total_score / total_weight overall_score sum( dimension_scores.get(dim, 0.0) * weight for dim, weight in self.WEIGHTS.items() ) grade self._score_to_grade(overall_score) return EvaluationReport( agent_nameself.agent_name, task_idself.task_id, evidenceself.evidence, dimension_scoresdimension_scores, overall_scoreoverall_score, gradegrade, ) def _score_to_grade(self, score: float) - Grade: for grade, threshold in self.GRADE_THRESHOLDS: if score threshold: return grade return Grade.MATRUK这里有两个点值得展开。第一权重设计非常重要。在传统考据学里“诚实性”的权重要高于“记忆力”因为一个人如果能记住但故意撒谎比记性差的人更危险。在 Agent 评估中事实一致性和溯源完整性的权重也应该更高因为它们直接决定 Agent 输出是否可信。本文示例权重是事实一致性 0.3、溯源完整性 0.3、稳定性 0.2、合规性 0.2你可以按业务风险偏好调整。第二证据置信度的设计。不是所有证据来源都同样可靠直接通过数据库校验得到的事实证据置信度可以给 1.0而 LLM-as-judge 给出的判断置信度可能只有 0.7。用置信度作为权重能有效防止低质量证据主导评级结果。4.4 工具调用链审计第三个文件专门处理“溯源完整性”。在实际项目中Agent 框架通常会记录完整的工具调用日志我们可以从中提取出“实际调用链”再和“期望调用链”做比对。# 文件路径: agent_eval/tool_audit.py 工具调用链审计验证 Agent 是否按预期步骤完成工作。 from typing import List, Dict, Tuple def audit_tool_chain( tool_calls: List[Dict], expected_chain: List[str] ) - Tuple[bool, List[str]]: 校验实际工具调用链与预期链路是否一致。 参数: tool_calls: 工具调用记录例如 [{tool: search, input: 北京天气}, ...] expected_chain: 期望的工具顺序例如 [search, parse, compute] 返回: (是否一致, 实际链路) actual_chain [call.get(tool) for call in tool_calls] if actual_chain expected_chain: return True, actual_chain mismatches [] for i, (actual, expected) in enumerate(zip(actual_chain, expected_chain)): if actual ! expected: mismatches.append(f第{i 1}步应为 {expected}实际是 {actual}) if len(actual_chain) ! len(expected_chain): mismatches.append( f调用链长度不一致实际 {len(actual_chain)} 步期望 {len(expected_chain)} 步 ) return False, actual_chain这段代码虽然简单但解决的是一个核心问题Agent 有没有按照预期路径完成任务如果期望链路是[search, parse, compute]某个 Agent 却跳过了parse直接compute那么它虽然可能结果正确但过程是不透明的后续排查成本和风险都很高。在评估体系中这种过程缺陷会直接导致“溯源完整性”维度扣分。4.5 模拟案例天气查询 Agent现在我们把整个框架串起来。下面这个 demo 模拟一个天气查询 Agent 的完整评估流程Agent 先搜索天气再解析结果最后判断是否需要带伞。我们用评估器分别从事实一致性、溯源完整性、稳定性、合规性四个维度打分。# 文件路径: demo.py 演示使用评估器对一个模拟天气查询 Agent 进行评级。 from agent_eval.evaluator import ReliabilityEvaluator from agent_eval.tool_audit import audit_tool_chain def run_demo(agent_name: str weather-agent-v1): task_id task-20240614-001 # 模拟 Agent 的工具调用日志真实场景中由 Agent 框架给出 tool_calls [ {tool: search, input: 北京今日天气, return: 晴25℃}, {tool: parse, input: raw_page, return: 北京 晴 25℃}, {tool: compute, input: 要不要带伞, return: 不需要}, ] # Agent 最终回答 final_answer 北京今天晴天气温25℃不需要带伞。 # 外部事实源模拟人工或数据库校验结果 ground_truth 北京 晴25℃ # 1. 构建评估器 evaluator ReliabilityEvaluator(agent_nameagent_name, task_idtask_id) # 2. 事实一致性sidq fact_consistent ground_truth in final_answer evaluator.add_evidence( dimensionsidq, sourcefact_check, passedfact_consistent, detail最终回答与外部事实源是否一致, confidence0.9, ) # 3. 溯源完整性isnad chain_ok, actual_chain audit_tool_chain( tool_calls, expected_chain[search, parse, compute], ) evaluator.add_evidence( dimensionisnad, sourcetool_audit, passedchain_ok, detailf工具调用链{ - .join(actual_chain)}, confidence1.0, ) # 4. 稳定性dabt重复运行两次结果是否一致模拟 result_twice 北京今天晴天气温25℃不需要带伞。 stability_ok result_twice final_answer evaluator.add_evidence( dimensiondabt, sourcereproducibility, passedstability_ok, detail重复执行两次回答是否一致, confidence0.8, ) # 5. 行为合规性adalah compliant all( call.get(tool) in {search, parse, compute} for call in tool_calls ) evaluator.add_evidence( dimensionadalah, sourcepolicy_audit, passedcompliant, detail未调用越权工具未输出无关隐私信息, confidence1.0, ) # 6. 输出报告 report evaluator.evaluate() print(report.to_markdown()) return report if __name__ __main__: report run_demo() print(f\n综合等级: {report.grade.value})运行命令cd agent-reliability-eval python demo.py预期输出效果如下## 评估报告weather-agent-v1 - 任务IDtask-20240614-001 - 综合评分100.0 / 100 - 综合等级可靠 (Thiqah) | 维度 | 得分 | 判断 | | --- | --- | --- | | 事实一致性 | 100.0 | 通过 | | 稳定性可复现性 | 100.0 | 通过 | | 溯源完整性 | 100.0 | 通过 | | 行为合规性 | 100.0 | 通过 | ### 证据明细 - [PASS] (事实一致性) fact_check: 最终回答与外部事实源是否一致 - [PASS] (溯源完整性) tool_audit: 工具调用链search - parse - compute - [PASS] (稳定性可复现性) reproducibility: 重复执行两次回答是否一致 - [PASS] (行为合规性) policy_audit: 未调用越权工具未输出无关隐私信息 综合等级: 可靠 (Thiqah)你可以在 demo 里故意改坏一个环节比如让工具调用链变成[search, compute]或者让final_answer缺少数值评估器就会自动把对应维度分数拉低最终降级到“诚实”甚至“尚可”。这个机制正是“传述人评级”的核心——一次失误不会直接否定 Agent但会真实地反映在等级上。5. 让评级体系适配真实生产环境真实的 Agent 场景远比上面的天气查询复杂。要让这套评估体系真正落地还需要考虑几个工程化问题。5.1 证据来源的自动化在 demo 中证据是手工构造的。生产环境需要自动化采集证据。通常的做法是把评估器接入 Agent 框架的中间件在每次任务结束后自动触发。需要采集的证据包括工具调用日志从 Agent 框架的 Tracing 系统拉取解析出工具名、参数、返回值。事实核验结果如果 Agent 的业务涉及数据库或知识库查询可以将最终回答与查询结果做自动比对。用户反馈真实用户的点赞、点踩、投诉是一种天然的人工评估信号。LLM-as-judge 打分让大模型对 Agent 的回答质量做初步判断但是要注意置信度权重不能设太高因为它本身不一定可靠。这些证据会以EvidenceItem的形式写入评估器最终沉淀到EvaluationReport。5.2 滚动窗口与长期档案一次任务的评级没有太大意义只有长期积累才具备参考价值。工程上建议为每个 Agent 维护一张“信誉档案表”存储结构大致如下CREATE TABLE agent_reputation ( agent_name VARCHAR(64) PRIMARY KEY, total_tasks INT DEFAULT 0, pass_tasks INT DEFAULT 0, avg_overall_score DECIMAL(5,2) DEFAULT 0, current_grade VARCHAR(32), updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );每次评估完成后更新total_tasks、pass_tasks、avg_overall_score并根据最新 N 次任务的平均分重新计算current_grade。这里建议使用滑动窗口而不是全量累加比如只取最近 100 次任务更贴近“近期表现”避免很久以前的问题一直压着评分。5.3 基于评级的访问控制评级体系一旦建立就可以把它作为 Agent 权限控制的依据。这一点和传统考据学中的“采用规则”非常相似高等级传述人的传述可以被采信低等级的需要辅助证据。在实际业务中可以这样设计AGENT_GRADE_POLICY { weather-agent-v1: { grade: Grade.SADUQ, allowed_actions: [query_weather, query_express], need_manual_approval: True, risk_level: medium, }, search-agent-v1: { grade: Grade.THIQAH, allowed_actions: [search, summarize], need_manual_approval: False, risk_level: low, }, } def check_agent_permission(agent_name: str, action: str) - bool: 根据 Agent 的信誉等级和策略判断是否允许执行某个动作。 policy AGENT_GRADE_POLICY.get(agent_name) if