如何开始搭建一个 agent 评测系统？
这是藏书里唯一一篇从「数据管道本身会不会失真」讲起的评测文章。a25（Tracing 专篇）默认"接进来的数据就是对的"，讲的是接什么标准、怎么采样、怎么下钻；这篇补的是它前置的那一层：作者实测一天 90MB 的 trace 文件去重后只有 11MB，放大 8 倍多，而这类问题不报错、不崩溃，只是让你后面所有评分悄悄失真。另外两条也是藏书空白：把多条轨迹叠成胶囊图看常态（而不只是逐条翻日志），以及专治"该触发没触发"的触发分析。文章还附了一次完整的真实复盘——代码安全审计场景下结果面 90.0 分、轨迹面只有 63.1 分，顺着轨迹定位到 Skill 缺陷再修复，同条件复跑升到 76.9、换文件换漏洞类型的独立回归拿到 95.9，四步方法论每一步都能在这个案例里对上号。想搭第一套评测系统、正准备先设计评分标准的团队，先读这篇再动手。
核心内容速览
- 顺序不能反：先让数据可靠落地，再谈评分。执行数据要经过采集、上报、落盘、聚合四个环节，跳过这步直接设计评分标准，评出来的分看着好看，回头一查可能是"有一部分数据根本没采全，或者同一条数据被重复计算了好几遍"。
- 8 倍膨胀坑（藏书空白 · 机制级）：服务端一天 trace 文件约 90MB，去重后有效数据仅约 11MB。两个原因叠加——① 每次上报把完整对话历史存了两份到不同字段；② 上报端每完成一步就把当前会话全部已完成步骤重新打包上报，服务端只追加写不按会话+步骤去重，早期步骤被反复写入。不报错、不崩溃，只会让存储和统计悄悄失真——结论从源头就是错的。
- 采集维度按三层定清楚（省后面返工）：引自 UC Berkeley 的 AgentTrace 论文——操作面（谁调了谁、耗时多少）、推理面（当时推理链是什么、置信度多少）、上下文面（对外的 HTTP / SQL / 向量库调用），推理 Span 嵌套在操作 Span 里。好处：凌晨报警说 Agent 做了一次不该做的写入，展开到推理层直接看到它当时的想法。
- 跨轨迹聚合：胶囊图（藏书空白 · 工件级）：单条 trace 只能告诉你"这一次发生了什么"。AgentTrails 的做法是把每步动作打包成"胶囊"（用了什么工具、输入输出、上游血缘），跨轨迹聚类出同一逻辑步骤的不同实例再重新连边——节点大小 = 这步被多少条轨迹共享，边的粗细 = 这条依赖有多稳。高频路径是共同工作流，稀疏分支往往就是异常行为或该修的 Prompt。
- 触发分析：专治沉默失败（藏书空白 · 失败类型）：该触发某个能力时没触发，Agent 全程表现"正常"，只是压根没意识到该用某个工具或某段知识。它不报错、也不体现成"失败"（可能被别的路径绕过去了），代价是能力被浪费。做法是针对该触发的场景自动生成正反两类用例去验证召回，而不是等它主动出错。
- 一次完整复盘：结果面 90.0，轨迹面只有 63.1（最有说服力的一段）：Agent 跑代码安全审计，结果面 90.0 分"安全结论基本正确"，看着合格；轨迹面只有 63.1——展开才看到它判断出了风险，却没提供能独立复核的运行时复现证据，这一项只拿 80 分标"部分覆盖"。两套诊断一起上：一套查"这次执行怎么走的"，一套查"Skill 的哪些指令导致了稳定缺陷"（归档解压检查缺漏洞模式、缺参考实现、没有"没运行证据不能说已验证"的门槛）。优化候选还要人工审——第一版把 Python 版本和预期布尔值写死、压根没真调用标准库，被打回重做。同条件复跑：综合 76.6 → 85.8、轨迹 63.1 → 76.9；换文件、换一组漏洞类型的独立回归拿到 95.9——这一步是关键，它证明学到的是"怎么找证据"这套方法，而不是背下了一道题的答案。
- 别忘了回头验"打分"本身：上面那些分数，前提是裁判模型靠得住——它有系统性偏差（顺序偏差、偏爱更长回答、跟自己风格接近的输出打分更高）。解法是拆成独立原子裁判、让它定向核实，而不是一次输出就当真。否则分数只会给你一种虚假的安全感。
适合谁 · 怎么用
先修：a25（可观测性与 Tracing——本篇是它的前置补丁，两篇应连读）、a05（Agent Eval 概念）。正在从 0 搭第一套 Agent 评测系统的团队优先读第一步与第一步半：先把落盘队列做扎实（保证进程重启、网络抖动时数据不丢、不重复计数），再考虑评分体系。已有一套评测在跑的，重点读 8 倍膨胀坑做自查，以及胶囊图（轨迹攒到一定量之后再上，不是必需品）。评测维度设计请回 a41/a42，裁判校准回 a04/a12。
闯关自测
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
Q1 为什么 trace 文件会膨胀 8 倍？这类问题最危险的地方是什么？
两个原因叠加：一是每次上报把完整对话历史存了两份到不同字段（不同环节各自要用）；二是上报端每完成一步就把当前会话所有已完成步骤重新打包上报一次，服务端只追加写入、不按会话和步骤去重，导致早期步骤被反复写入很多遍。最危险的是它不报错、不崩溃，只会让存储和后续统计悄悄失真——评测系统直接在这种数据上跑分析，得出的结论从源头上就是错的，而没人会发现。
Q2 跨轨迹聚合的「胶囊图」里，节点大小和边的粗细分别代表什么？用它看什么？
节点大小 = 这一步操作被多少条轨迹共享；边的粗细 = 这条依赖有多稳定。看的是这个 Agent 的常态，而不是某一次发生了什么：高频路径是共同工作流，稀疏的分支往往就是异常行为或者该修的 Prompt。前提是先把每步动作打包成"胶囊"（用了什么工具、输入输出、上游血缘），再跨轨迹聚类出同一逻辑步骤的不同实例并重新连边。
Q3 什么是「触发分析」？它抓的是哪类别的评测抓不到的失败？
抓的是沉默失败：该触发某个能力的时候没触发，Agent 全程表现"正常"，只是压根没意识到该用某个工具或某段知识。它不会报错，也不会在结果评测里体现成"失败"——因为可能被别的路径绕过去了——代价是能力被浪费。主流评测大多聚焦"做得好不好"，这类"该做却压根没想起做"的失败是盲区。做法是针对该触发的场景自动生成正反两类用例去验证召回是否符合预期，而不是等它主动出错。
Q4 案例里复跑后轨迹分从 63.1 涨到 76.9，为什么还要再换一个文件、换一组漏洞类型做独立回归？95.9 这个分数证明了什么？
因为同条件复跑只能证明"这一道题改对了"，不能证明"方法学会了"——分涨了，也可能是 Agent 记住了这个文件的具体答案。换一个文件、换一组漏洞类型做独立回归，等于换一套全新的题考同一个能力：拿到 95.9，才说明它学到的是"怎么找运行时证据"这套方法，而不是背下了一道题的答案。这一条对你自己的评测体系同样成立：没有独立回归集的评测，提升可能只是过拟合。另外注意案例里优化候选还经过了一道人工审查——第一版把 Python 版本和预期布尔值写死、压根没真调用标准库，属于"看起来跑通了其实没验证"，被打回重做，改成真实调用 ZipFile.extractall / tarfile.extractall 才算数。
以下为原文全文
上方为本站原创导读，下方为原回答完整收录。作者 Leon，openEuler 社区孵化的开源 AgentOps 平台 Agent Insight 成员。原文为知乎回答，无小标题层级，本站仅按原文段落顺序整理排版，未作改写。
首先，两个关键点：安全要作为单独的否决门槛，不能被平均分掩盖；Trace 比总分更重要——总分只能排序，Trace 才能告诉你该改哪。
另外，在你能谈"怎么评"之前，先得把"怎么可靠地把执行数据收集上来"这件事做对，这一步比想象中容易踩坑，而且坑踩了你自己往往发现不了。
分享我做 Agent Insight 的一些踩坑经验（openEuler 社区孵化的开源 AgentOps 平台，观测→评测→诊断→优化，已适配 OpenCode、CC、DSH、jiuwen 等 12 个主流 Agent Harness 运行时）。
先想清楚顺序：没有可靠的观测，评测系统建立在流沙上
评测系统需要的原始数据，是 Agent 每一步做了什么、调了什么工具、模型返回了什么。这些数据要经过采集、上报、落盘、聚合几个环节才能变成评测能用的东西。很多团队直接跳过这一步去设计评分标准，结果评出来的分数看着挺好看，回头一查，发现有一部分执行数据根本没采全，或者同一条数据被重复计算了好几遍，评出来的分是不准的，只是没人发现。
我们自己的数据管道就踩过一个具体的坑：一次排查里，服务端一天的 trace 文件有约 90MB，但去重后实际有效数据只有约 11MB，放大了 8 倍多。查下来是两个原因叠加：一是每次上报都把完整的对话历史存了两份到不同字段里，因为不同环节各自要用；二是上报端每完成一步，就把当前会话所有已完成的步骤重新打包上报一次，而服务端只是把数据追加写入文件，没有按会话和步骤去重，导致早期步骤被反复写入很多遍。这种问题不会报错、不会崩溃，只会让你的存储和后续统计悄悄失真——评测系统如果直接在这种数据上跑分析，得出的结论从源头上就是错的。
从 0 到 1，按这个顺序搭，别反过来
第一步，先保证数据能可靠落地，哪怕粗糙。用一个简单的落盘队列把执行数据先稳定存下来，重点不是设计多精巧的评分体系，是保证进程重启、网络抖动这些意外情况下数据不丢、不重复计数。这一步做扎实，后面的评分才有意义。落地的时候顺手把该采的维度定清楚，能省后面很多返工：UC Berkeley 那篇 AgentTrace 论文的思路我很认同——把日志拆成操作面（谁调了谁、耗时多少）、推理面（当时推理链是什么、置信度多少）、上下文面（对外的 HTTP / SQL / 向量库调用）三层，推理 Span 嵌套在操作 Span 里。好处很直接：凌晨报警说 Agent 做了一次不该做的写入，点开 Trace 一路展开到推理层，直接看到当时的推理是"用户说'整理一下'，我认为应该归档到主库"——不用对着一堆 print() 日志干猜。
第一步半，Trace 攒多了之后，别满足于"能查单条"。单条 Trace 只能告诉你这一次发生了什么，看不出这是不是这个 Agent 的常态。AgentTrails 那类工作的做法是把多条轨迹的执行图叠在一起：把每一步动作打包成"胶囊"（用了什么工具、输入输出、上游血缘），跨轨迹聚类出同一个逻辑步骤的不同实例，再重新连边——节点大小代表这步操作被多少条轨迹共享，边的粗细代表这条依赖有多稳定。高频路径是共同工作流，稀疏的分支往往就是异常行为或者该修的 Prompt。这一步不是必需品，但轨迹攒到一定量之后，比逐条人工翻日志高效得多。
第二步，评测要拆成"结果"和"轨迹"两条线，缺一不可。结果面看任务有没有完成；轨迹面看做的过程对不对——该调用的工具有没有调、参数有没有错、推理链有没有自相矛盾。只看结果的评测，会把"蒙对了"和"真的做对了"混为一谈。
第三步，容易被漏掉的一层：触发分析。前面提到的评测大多聚焦"做得好不好"，但还有一类失败更隐蔽——该触发某个能力的时候没触发，Agent 全程表现得"正常"，只是压根没意识到该用某个工具或某段知识。这种沉默失败不会报错，也不会在结果评测里体现成"失败"，因为它可能被别的路径绕过去了，但代价是能力被浪费了。做法是针对该触发的场景，自动生成正反两类用例去验证召回是否符合预期，而不只是等它主动出错。
第四步，让评测变成持续的回归，而不是一次性的报告。一份评测报告如果只在上线前跑一次，价值有限，因为 Prompt、Skill、模型随时会变。真正有用的做法是把评测跑成 CI 式的例行任务，每次改动之后自动重新跑一遍基线对比，退化能在合入之前被拦下来，而不是等用户投诉才发现。
这套系统实际跑起来，长什么样
光讲步骤比较空，拿一次真实的评测过程举例。我们最近让一个 Agent（跑在 DeepSeek Harness 上）做一次代码安全审计，全程用上面这套系统记录和验证：
结果面评测给了 90.0 分，安全结论基本正确；轨迹面评测只有 63.1 分——展开到具体评分点，才看到 Agent 判断出了风险，却没提供能独立复核的运行时复现证据，这一项只拿 80 分、标记"部分覆盖"。综合分 76.6。这就是"结果"和"轨迹"两条线分开打分的价值：只看结果，这次审计是合格的；拆开看轨迹，才知道它是蒙对的还是真查清楚的。
定位问题也是两套诊断一起上：一套负责回答"这次执行是怎么走的、受什么环境限制"，另一套负责回答"Skill 的哪些指令导致了稳定缺陷"——归档解压检查这个 Skill 缺明确的漏洞模式、缺参考实现、也没有强制"没有运行证据不能说已验证"的门槛。据此生成的优化候选先经过人工审查——第一版候选写死了 Python 版本和预期布尔值，压根没真调用标准库，被打回去重做，改成真实调用 ZipFile.extractall / tarfile.extractall，独立目录里跑通了才算数。
同条件复跑验证：综合分 76.6 → 85.8，轨迹分 63.1 → 76.9，关键证据点补成完整覆盖；换一个文件、换一组漏洞类型的独立回归拿到 95.9，说明学到的是"怎么找证据"这套方法，不是记住了一道题的答案。四步顺序走下来，每个环节都能在这个案例里对上号。
一个容易被忽视的提醒
上面"结果面 90.0 分、轨迹面才 63.1 分"这件事，本身还依赖另一个前提：给结果和轨迹打分的裁判模型，它的判断靠不靠谱。裁判模型有系统性偏差——顺序偏差、偏爱更长回答、跟自己风格接近的输出打分更高，这个我在另一篇回答里展开过，核心是拆成独立原子裁判、让它去定向核实而不是一次输出就当真。这里先提一句：评测系统搭起来之后，别忘了回头验证"打分"这件事本身可不可信，不然分数会给你一种虚假的安全感。
延伸阅读
- 《Agent Insight：让生产级智能体可观测、可度量、可进化》
- 《同一个模型，换 Holistic Agent 评估框架，错误定位能力涨了 12 倍》
- 《AgentTrace：给 LLM 智能体装上"行车记录仪"》
- 《别再人肉翻 Agent 日志了，这张依赖图告诉你每条轨迹真正发生了什么》
原文链接：https://www.zhihu.com/question/1985714937893512991
