前段时间在项目里测一个能调用搜索、文件读取和代码执行工具的多步骤AI agent遇到一个很有意思的瞬间任务完成最终答案看起来完全正确数据也有来源格式也标准。但当我要求它把整个过程一步步展开时发现它调用了一个根本不存在的数据文件还为了凑出那个答案在中间步骤里自己生成了一条“来源”。那一刻我突然意识到用最终输出对不对来评估AI agent只能告诉你它有没有完成任务并不能告诉你它是不是真的“会”完成任务。这个困惑其实指向一个更底层的问题。我们把越来越多的工作交给AI agent去做——查资料、整理报告、写代码、做数据分析、甚至代替人做出中间决策——但我们对它的评估方式却还停留在“结果对错”“分数高低”这类最粗粒度的层面。有人在Hacker News上提过一个很妙的标题为什么我们不能像古典学者考据叙事者那样去评估AI agent这个类比初看有点远细想却非常准确。AI agent和传统大模型问答最大的不同是它开始“行动”了。它会调用外部工具会修改内部状态会基于前一步的结果决定下一步怎么做。行动意味着它有过程有过程就有了审计的可能也有了出偏差的空间。所以我想先说清楚这次的主判断成熟的agent评估不应该止步于给结果打分而应该建立起一套基于过程证据链的评估方式。这个转变不是更麻烦而是让复杂智能体真正可控的唯一路径。1. 为什么只看最终输出评估不出真正的AI agent1.1 一个被测试结果骗过的典型场景假设你给一个agent安排的任务是查询某家公司最近一季度的财务数据判断营收是否比上季度增长。合理流程应该是这样搜索公开信息 → 定位到财报页面或PDF → 读取关键字段 → 对比上一季度数据 → 输出结论。但实际运行中过程经常会走样。比如搜索返回了多个页面agent随机挑了第一个读取PDF时因为格式问题解析失败它没有报错而是从上下文里猜了一个数字最后结论格式很好看但数字是错的。如果只看最终结论人类很难察觉问题。只有把工具调用链完整回放你才会发现第二步就已经失败了。这类事件不是极少数。在多步骤任务里每多一次工具调用就多一个偏差累积点。最终答案即使不错也可能是歪打正着最终答案错了就更难定位是哪一步造成的。这正是“过程评估”存在的意义它不是为了证明agent很厉害而是为了回答“它到底怎么做到的”。1.2 最终指标掩盖了过程错误现在的agent评测惯用指标是准确率、通过率、ROUGE、BERTScore或者让另一个大模型当裁判打分。这些指标对单轮问答或RAG系统有一定意义但对agent来说有明显结构性问题指标只反映最终结果无法体现过程是否规范。指标把工具调用、上下文状态、中间决策全部压缩成一个数丢失了绝大多数信息。如果评测集本身有偏差再高的分数也不可信。更麻烦的是agent的“路径”和“结果”之间不是简单线性关系。同一个任务它可能用5次正常工具调用完成也可能用1次错误调用加上1次幻觉兜底完成但最终文本看起来一模一样。只看准确率你根本区分不了这两种情况。而agent进入生产环境后真正要评估的是“决策路径质量”而不是“终点撞对没有”。一个能完成任务但全程乱撞的agent短期内可用长期必然出问题因为你不知道它下一次会不会换一条更离谱的路径。1.3 agent评估本质上是在评估一个协作流程我们可以把一个agent想象成一个临时组建的团队模型是决策者工具是执行者上下文是工作台。评估这个团队不能只看交付物还要看决策者是否做了规范判断、执行者是否正确调用、工作台有没有被污染。所以agent治理真正需要的是一套“全流程审计”思路每条证据、每次调用、每个中间决策都要可回放、可归因、可问责。这和传统软件开发里的日志、链路追踪、APM其实一脉相承只是对象从进程变成了agent。这种观点也暗示与其想发明一个完美分数不如先把过程记录下来让评估者能够看到agent到底是怎么走到最后一步的。没有这条证据链任何高级指标都只是空中楼阁。2. 历史考据法把“传递链”变成agent的审计策略2.1 考据思路的核心不是信任而是可验证性在古典口传史料考据传统里学者面对一个值得怀疑的说法时不会只看内容顺不顺、有没有道理而是会考察三件事来源是谁、经过哪些环节传下来、每个环节是否可靠、文本内部有没有矛盾。核心不是盲目信任“这段话说得很有道理”而是看它是否有一条可验证的传递链。把它映射到agent评估上思路就非常清晰agent说“我查了某份文件”我们就要能验证它是否真查了、查的是哪一份、读到的是什么内容。agent说“数据来源是某网站”我们就要能验证这个来源是否真实存在。agent说“某一步是因为异常才回退的”我们就要能查看上下文、异常日志和重试记录。这意味着agent运行过程必须产生“链上证据”。没有证据就没有评估。很多人担心这样会增加工作量但实际上软件工程一直就是这么干的。你不会因为服务端一次请求返回正确响应就不再查看日志你会记录日志、跟踪异常、做链路排查。agent只是一个更复杂、更需要过程记录的运行单元。2.2 从考据逻辑提炼出的五个评估层次把考据逻辑转译成工程语言我习惯把agent评估拆成五个层次评估层次要回答的问题典型证据来源层agent读到了什么信息来源真实吗系统提示词、检索上下文、知识库ID、URL、文件路径过程层agent做了什么工具调用是否合理工具调用序列、输入输出快照、状态变化结果层最终输出是否正确、完整、符合任务要求最终回答、引用、格式校验结果失败层异常发生时agent如何应对有没有掩盖失败异常日志、重试记录、默认值、回退路径一致层多次运行是否稳定边界输入下是否安全重复实验结果、对抗样本、边缘输入这五个层次不是并列的功能列表而是一条完整证据链。来源支撑过程过程解释结果失败暴露隐藏问题一致层回答可靠性。评估agent时如果只测结果层就会陷入1.2节说的“指标陷阱”。只有把五层串起来才能形成真正可用的评估方案。2.3 把来源、过程、结果、失败、一致性串成一张检查表为了落地可以把上述框架直接做成人工检查表。每次评估一个agent任务按顺序过一遍任务定义是否清晰输入范围、工具边界、期望输出结构。来源层这次运行使用了哪些上下文所有外部来源都可验证吗过程层每个工具调用是否符合预期有没有跳出允许范围结果层最终输出是否满足任务验收条件失败层有没有重试、降级、默认值这些地方是否掩盖了真实错误一致层同一任务跑三次结论是否稳定边界输入是不是都被正确处理这个检查表可以嵌入日常评估流程不一定一开始就要做成系统。最开始它可以是一份评估记录模板让人工评估者逐项填写等积累了足够样本再逐步自动化。3. 建立agent的可验证证据链从日志到回放3.1 没有过程日志的agent无法归因一切评估的前提是运行过程可观测。实际工作中很多团队还在用一个prompt 一个API返回值的方式使用agent这种情况下没有独立的工具调用记录。我建议先做一次基础改造对每个agent任务都要能输出一份结构化“运行档案”。这份档案至少包含用户输入和系统提示词。每次大模型调用的输入输出。工具名称、入参、出参、耗时、状态码。上下文版本或快照如果成本允许。异常、重试、回退记录。最终输出和停止原因。有了这份运行档案评估才谈得上“做证据链审计”。如果没有那任何测评都接近盲人摸象。具体落地时本地开发可以用结构化日志线上可以用tracing和时间线。不管用什么工具原则只有一个每个决策都有记录每次调用都有快照。3.2 一个最小可用的“过程审计”框架写一个非常简化的示例结构用来理解过程审计代码大概长什么样不代表某个正式库import time import uuid class AuditContext: def __init__(self, trace_id): self.trace_id trace_id self.events [] def record(self, event_type, name, payload): self.events.append({ trace_id: self.trace_id, event_type: event_type, # task_start / llm_call / tool_call / error / task_end name: name, payload: payload, ts: time.time() }) def run_agent_with_audit(task, tools, llm): audit AuditContext(trace_idstr(uuid.uuid4())) audit.record(task_start, task, {input: task}) # 在真实实现中这里需要包裹llm调用和工具调用 # audit.record(llm_call, plan, {prompt: task, output: plan}) # audit.record(tool_call, search, {query: task[query]}) # audit.record(tool_call, read_pdf, {path: result[path]}) final_result None audit.record(task_end, result, {output: final_result}) return final_result, audit关键不是这段代码而是设计原则所有关键决策和外部调用都要经过一个统一入口把事件记录下来。没有这一步后面所有评估手段都缺乏素材。3.3 评估集设计不能只喂正确答案还要喂边界情况评估agent时评估集不要只收集正常例子。按照第2节的五层框架评估集至少应该包含六类任务简单正常任务验证主流程能通。需要多步调用的任务验证工具链和步骤编排。会产生冲突来源的任务验证来源选择和质量判断。需要拒绝执行的任务验证安全边界和判断力。工具调用失败的任务验证异常处理和重试逻辑。上下文超长、歧义指令、幻觉高发输入验证稳定性和边界能力。对每个评估用例除了标准答案建议同时记录“允许使用的工具集合”和“禁止出现的行为”。例如任务“查询A公司营收”里可以明确禁止“直接根据记忆生成数字”必须调用搜索或读取文档。这样后续评估时过程层才能自动判断有没有越界。4. 实操落地单任务验证、批量评估、问题归因4.1 第一步定义可度量的任务而不是抽象目标很多agent项目失败不是因为模型不行而是任务定义太模糊。模糊任务“帮我查一下市场情况。”这个任务不可能可靠评估因为“市场情况”不是一个可度量的输出。可度量任务“查询某行业最近三个月的公开融资信息列出最近5条每条包含公司名、时间、金额和来源链接如果某一条缺少金额标注‘缺失’不要推测。”可度量任务必须写清楚输入边界允许用户传入哪些信息。允许调用的工具搜索、读文件、查数据库还是都不能调用。禁止行为不得编造数据、不得调用写入类工具、不得越权访问。输出格式结构化字段、列表顺序、缺失值写法。验收条件哪些字段必须真实存在哪些可以写“未知”。这一步看似简单实际是整个评估体系的地基。任务定义不清楚后面所有分数都没有意义。4.2 第二步运行小样本建立过程轨迹不要一上来跑几百条评测数据。先选10到15个代表性任务覆盖正常、边界、冲突、拒绝场景。逐个运行并保存完整运行档案。这一步的目标不是算分数而是让人看懂agent在干什么。建议每个任务打印或查看三样东西最终的输出。完整的工具调用序列。在哪个步骤出现了异常或可疑决策。通过这一步你会很快发现一部分失败其实不是模型不会答而是工具调用格式没写清楚一部分“成功”其实是幻觉还有一部分任务根本不该让agent自主执行需要在产品层加确认机制。4.3 第三步自动化评分与人工复核小样本能稳定解释清楚后再进入批量评估。批量评估建议分层规则校验检查输出结构、必填字段、是否包含禁止表述、是否调用了禁止工具。基于模型的评估用另一个模型判断最终答案与参考答案是否一致。不过模型评估也可能有偏好所以关键样本必须人工复核。人工复核至少对失败样本和过程异常的样本进行人工trace查看。对评分结果我建议记录两个数字最终输出通过率判断“终点对不对”。过程合规率判断“路径规范不规范”。两者差距越大说明agent越“碰运气”。比如最终通过率80%过程合规率只有40%这个agent就是典型的“结果好看过程不可控”生产环境慎用。4.4 第四步归因、修复、回归批量评估的价值不只是给一个分数而是定位问题根因。建议按频率排序高频根因先修。常见根因包括提示词未限定任务边界agent自己扩大了范围。工具schema描述不清晰模型不理解何时调用某个工具。检索结果过多或上下文被截断模型漏掉关键信息。重试逻辑不完善一次失败就直接放弃。输出解析层过脆模型输出格式稍有变化就崩。修复后把之前失败的样本加入回归集。这是agent工程里最值得投资的积累。慢慢地这个回归集就成了团队的“能力基线”比任何单独一次评测都更有参考价值。5. 最容易踩坑的四个环节与排查链路5.1 误区一把评估等同于跑测试用例普通测试用例只验证“输入→期望输出”。但agent没有标准输入输出它有状态、工具、上下文。只跑测试用例会出现三个问题没有过程断言结果对了也不知道为何对。无法覆盖工具失败、API超时等动态情况。评估结果无法指导修改只能说明“坏了”。解决在测试用例里增加过程约束。比如“不得调用写入类工具”“必须调用搜索工具”“不得使用超过N次外部调用”。这样测试就不只是结果判断而是路径判断。5.2 误区二只看准确率不看工具调用链准确率提升5%到底是模型变强了还是评估集变了还是随机性升高了只看准确率回答不了。建议同时跟踪平均工具调用次数。工具调用失败率。重试率。默认值或降级路径触发率。单任务耗时和token成本。这些指标变化往往比准确率更能反映agent的运行质量。准确率是结果工具调用链是过程二者缺一不可。5.3 误区三评估集被污染评估集被污染是agent评测里最隐蔽的坑。常见有几种情况人把参考答案或相关文档留在系统提示词或上下文里agent相当于开卷考试。检索知识库里包含评估用例的原始文档模型直接抄答案。模型训练数据里已经包含这个任务的标准答案。评估集必须做隔离。当一个agent的分数突然异常高先怀疑污染而不是先庆祝。5.4 排查顺序现象、输入、环境、参数、边界遇到agent表现异常时不要直接改prompt先按顺序排查现象是最终回答错误、过程错误、还是运行中断把现象记录准确。输入重新检查用户输入、系统提示词、上下文装载顺序、文件路径、检索query。环境检查依赖版本、模型版本、外部API是否可用、权限、网络、配额。参数检查temperature、max_tokens、top_p、检索top_k、超时、重试次数、并发数。这些参数未必是越大越好。工具边界该工具是否支持预期操作返回格式是否被正确解析有没有隐式截断模型与任务边界这个任务是不是超出当前模型能力需不需要改成多步、增加检索、或让用户确认每次排查都要保留运行档案否则下一次可能重复踩同一个坑。6. 这种评估方式真正改变的是什么6.1 从“结果判断”到“过程可审计”如果agent要进入真实生产环境你会发现最稀缺的不是模型能力而是“可解释的运行结果”。当运维、产品、安全、甚至客户问“为什么它这么做”时你必须有证据链。过程审计不是效率负担而是从“能用”走向“可信”的必经之路。一个在关键时刻无法自证的agent无论分数多高都无法承担真正的业务责任。6.2 适合什么场景不适合什么场景这套过程审计式评估并不适合所有场景。我把自己判断的边界写在这里适合场景不适合场景多步骤任务、多工具调用纯单轮问答、简短文本生成涉及外部真实数据、需要引用来源团队还没有基础日志能力需要稳定复现、审计、安全边界依赖频繁变动的早期原型正在把agent从demo推向beta只做玩具demo不需要长期维护如果团队连基本的服务端日志和链路追踪都没有直接上重型agent评估体系会脱离现实。建议先从“能记录运行档案”开始再逐步扩展。6.3 最终建议先建立评估基线再谈工程化工程化不是第一步。第一步是选10到15个真实任务给每个任务配好“输入允许工具禁止行为期望输出验收条件”。然后运行10次记录每条运行档案人工看一遍。这一步做完你会对项目现状有远比准确率更真实的认识。评估体系是可以长期迭代的先有过程日志再有过程规则再有自动评分再有回归集最后形成团队共识。这个过程没有捷径但它会让agent任务变得可控、可复用、可追责。回到文章开头那个场景。那次测试真正改变我看法的不是agent的最终答案有多正确而是它整个决策路径在审计档案里被完整暴露出来的过程。我开始明白评估AI agent不是一个打分问题而是一个建立证据链的问题。下次再测试一个agent时别只问“它做到没有”先问一句“它做了什么为什么这么做我能看到证据吗”能把这条链补齐才算是真正把agent当作一个受控的工程系统在管理。