A²E：面向智能体脚手架的端到端审计评测引擎 A^2E : An End-to-End Agent Auditing Engine
用统一任务协议与自动插桩追踪，对智能体脚手架做全生命周期多维评测
前置知识
Agent Harness（智能体脚手架）
包裹在 LLM 外围、真正决定智能体系统行为的工程层：系统提示词的构造方式、工具 schema 与调用路由、上下文管理与状态维护、控制循环与终止策略、错误处理等。同一个模型配不同脚手架，会表现出截然不同的执行行为、token 消耗与成功率。
本文的核心论点是'脚手架不是模型的轻量包装'，全文的评测对象正是 harness 而非模型本身，不理解这一分层就无法理解论文动机与实验设计。
OpenTelemetry Span（分布式追踪）
可观测性领域的标准模型：一个 span 代表一个有边界的操作，记录开始时间、结束时间、状态与上下文；相关 span 共享 trace 标识并通过父子关系构成一棵执行树，既能还原时序也能还原因果结构，可与 OTel 生态的追踪工具互通。
A²E 的 Monitor 层就是把每次智能体执行记录为一棵 span 树（agent span 内嵌推理链、模型调用、工具/技能调用），这是理解其轨迹采集机制的必备背景。
适配器模式与协议解耦
当两个维度（如基准和脚手架）各自异构时，若为每个组合写集成代码会有 m×n 份实现；适配器模式让两侧各自实现一个共享接口（协议），从而任意组合可自由配对，新条目只需一个适配器。
A²E 的 Agent Task Protocol（ATP）本质就是该模式在智能体评测中的实例化，实现了 23 基准 × 9 脚手架的免两两集成组合，这是本文方法主干。
LLM-as-Judge（大模型评审）
用另一个 LLM 按评分标准给定性维度打分的方法，如推理连贯性、指令遵循、安全性等规则难以表达的属性。评审模型读取轨迹或答案后输出分数与理由，成本低但存在评审偏差与版本漂移问题。
A²E 评估层一半指标（规划质量 plan_grade、failure_transparency、幻觉率等）依赖 LLM 评审，另一半是确定性规则指标，两者混合是其指标目录的关键设计。
Bradley–Terry / Elo 等级分
从成对比较结果中估计实力的统计模型：Elo 给每个参赛者一个等级分，胜负后按期望胜率更新分值，分差越大表示实力差距越稳定。论文中 GDPval 以人类专家为 1000 分锚点计算机器输出的 Elo。
GDPval 是论文四大前沿基准之一，Table 2 以'对人类 Elo'报告结果（如 LangGraph 1129.6），不了解该指标无法解读这一列数据。
研究动机
随着 LLM 能力趋同，智能体系统的整体表现越来越取决于'脚手架'（harness）——决定系统提示词、工具接口、上下文管理与执行策略的那一层，只评测底层模型无法反映真实部署能力。然而现有工具链各管一段：Inspect AI 提供基准编排、沙箱执行与打分，但接入外部脚手架需要为每个 harness 写专属适配器和模型 API 代理，接口一变就要持续维护，代理还可能篡改生成参数与调用路径，降低轨迹保真度；基于 OpenInference 的 Phoenix 提供原生执行的标准观测，但不是端到端基准运行器，缺少任务编排与结果校验，用户得自己拼装基准、脚手架和追踪设施。同时，主流评测几乎只看最终答案正确性：论文实测 9 个脚手架在 23 个基准上的 correctness 仅分布在 0.42–0.77 的窄区间，一个'6 次侦察后早停'的失败和一个'22 步只差最后测试'的失败都会得到同样的 0 分，聚合成功率几乎没有诊断价值。
本文的目标是本文的目标是构建一个轻量、低侵入、脚手架无关的端到端评测引擎 A²E（Agent Auditing Engine），把任务组合、轨迹监控与生命周期对齐评估统一到一套技术栈中。具体包括：通过统一协议让 23 个基准与 9 个脚手架自由组合成 m×n 配对而无需两两编写集成代码；以自动插桩捕获模型调用、工具调用、时延与 token 消耗等结构化轨迹，并与 OpenTelemetry 观测生态互通；把评估指标注册到'执行阶段 × 评估维度'的二维目录下，同时评估过程（规划、工具使用）、结果（答案正确性）与运行时质量（效率、安全）；轨迹、指标定义与评估结果统一存入数据库而非散落的 JSON 文件，支持增量评估与跨运行纵向追踪，最终能回答'脚手架在哪个执行阶段、哪个能力维度上拉开差距'这类诊断性问题。
与已有工作不同的是，本文的独特切入是'协议解耦 + 原生执行监控 + 数据库中心评估'三件套的组合。与 Inspect AI 的 harness 专属适配器加 API 代理方案不同，A²E 把共享接口下沉为 Agent Task Protocol（ATP），基准侧与脚手架侧各自实现 ATP 边界即可任意组合，且不介入生成路径，轨迹保真度更高；与只做观测的 Phoenix 不同，A²E 补齐了任务编排、沙箱执行与结果校验，形成从跑到评的闭环。第二个差异点是'生命周期对齐评估'：每个指标显式注册到 Reasoning/Action/Final Answer/Runtime Quality 四个阶段与细粒度维度之下，指标的位置与测法（LLM 评审、确定性规则、环境校验器、统计聚合）分离，新增指标零侵入。第三个差异是轨迹入库而非存文件，新指标可对已存轨迹离线重算，无需重跑昂贵的 API 调用。Table 1 的六维功能对比显示 A²E 在任务编排、原生执行、轨迹采集、生命周期评估、持久存储、harness 无关性上全部支持，而两个对照系统均有缺失。
核心方法
直觉上，评测智能体脚手架的两大障碍是'基准 × 模型 × 脚手架'组合爆炸与轨迹不可比。A²E 的解法是定义一个最小共享边界让两侧各自适配：基准侧只需把数据集条目转成统一的 TaskInput，脚手架侧只需实现统一的 AgentRunner，中间由 AgentBinding 提供工具 schema、工具执行与提示词构造，这就是 ATP 协议的四个核心对象（TaskInput、AgentBinding、AgentRunner、TaskTrace）。运行时 Monitor 层自动插桩，把每次执行记为一棵 OpenTelemetry span 树——模型调用、工具调用、技能调用各为一个带起止时间、状态与父子关系的 span，并完整保留推理-行动-观察循环 $R_1 \to A_1 \to O_1 \to R_2 \to \cdots$，轨迹流式写入中心服务器。评估层随后从数据库读取轨迹与结果，按生命周期阶段计算过程级（Reasoning/Action）、结果级（Answer Correctness/Task Completion）与生命周期级（Efficiency/Safety）指标并写回。整个流水线由 Task、Server、Evaluation、UI 四个松耦合组件构成，UI 刻意设计为只读，避免可视化逻辑与执行评估逻辑耦合。
核心创新有三点。其一，ATP 协议：由 TaskInput（指令、状态、期望动作/输出、元数据、可选沙箱规格）、AgentBinding（工具 schema、工具执行、提示词构造）、AgentRunner（绑定后运行输入并返回 TaskTrace）与 TaskTrace（运行状态、轮数、有序工具调用、最终答案、耗时、原始输出）构成的内部软件协议，把'基准适配'与'脚手架执行'彻底解耦——每个新基准只需一个 adapter、每个新框架只需一个 harness 集成，避免 m×n 两两实现；这与 Inspect AI 逐 harness 写适配器加代理的路线有本质区别。其二，原生执行监控：不做模型 API 代理，而是在框架自然的执行点插桩，内部又分三层——语义层定义 agent/chain/model call/tool/skill 五类行为词汇，span 层记录时序边界与父子结构，SDK 层把各框架特有的调用机制映射到统一表示，保证轨迹既忠实又可跨框架比较。其三，生命周期对齐评估：指标是'（阶段，维度，实现）'三元组，评估位置与测法分离，且轨迹入库后可增量评估——同一份轨迹能用不同评审模型或指标版本反复打分。
方法步骤详情
完整流程分四步。第一步任务准备：执行支持包打包沙箱定义、任务数据集、实验配置与运行时环境；基准树按时间（过去/当前/新）、类别（编码/研究/工具使用/生产力等）、难度三维索引，23 个基准归入编码、对话、研究、计算机使用四个任务区。第二步轨迹生成：输入'基准 key + 脚手架 key + 模型名'，注册表解析出数据加载器、binding、runner 与 SDK 映射；CLI 默认无放回采样 40 个任务（可自定义样本量与种子）；对每个任务构造 TaskInput 并调用 AgentRunner，沙箱任务通过 task state 传入活环境；runner 跑完控制循环返回 TaskTrace（运行状态、轮数、有序工具调用、最终答案、耗时），插桩同时记录 span 树并以 trace id 关联。第三步评估：规则评估器算 accuracy、任务/工具成功率、延迟、token 用量、成本、步数；LLM-as-judge 评结果质量、推理质量、工具使用质量、指令遵循与安全性；指标按四阶段（Reasoning/Action/Final Answer/Runtime Quality）及其维度注册。第四步存储与展示：分数写回为结构化记录，数据库分轨迹/结果/指标三类存储，大文件外置存指针，UI 只读查询与聚合对比。
技术新颖性
与 Inspect AI 相比，A²E 不经 API 代理介入生成路径，轨迹保真度更高，且避免随框架接口演化而来的持续适配维护成本；与 Phoenix 相比，补上了基准编排与结果校验，从可观测性工具升级为完整评测引擎；论文还强调其核心实现比这两个通用系统显著更小，因为只保留了三层所必需的抽象。评估组织方式上的新颖性在于'位置与测法分离'的指标目录：先行工作（如 progress-based 轨迹分析）只解决了诊断信号问题，A²E 则把诊断能力、零侵入可扩展性（新增指标不改 runner/harness）与规模可扩展性（数据库事务、失败重试、增量计算）统一进同一架构，并把评估套件明确定位为'持续演进的系统'而非固定分数集合。实验贡献上，论文用统一协议首次跑通 23 基准 × 9 脚手架 × 2 后端（gpt-5.6-sol 与 glm-5.3）的匹配条件评测矩阵，并提出效果-效率联合得分 $Q_h = 1 - \sqrt{\frac{\hat{T}_h^2 + (1-\hat{S}_h)^2}{2}}$（其中 $\hat{T}_h$、$\hat{S}_h$ 为归一化 token 用量与成功率）来定位每个基准的帕累托前沿，而非输出单一排行榜。
实验结果
发现一：不存在普适最优组合。官方矩阵（Table 2，gpt-5.6-sol 后端）显示 DeepSearchQA 上 9 个脚手架 F1 挤在 56.38–58.13（Google ADK 最高 58.13），GDPval Elo 1041.4–1129.6（LangGraph 最高）；而 τ 系列 harness 差异极大——τ-bench 上 Claude-SDK 84.72% 对 CrewAI 35.29%，相差近 50 个百分点；Terminal-Bench 2.1 上 Smolagents 76.5% 最高、Google ADK 仅 63.0%。换 glm-5.3 后差距急剧放大：DeepSearchQA F1 从 5.81 到 38.51 差近 6.6 倍，τ2-bench 上 59.65% 对 23.68%；模型效应同样显著（Terminal-Bench 2.1 平均成功率 68.3% vs 48.1%）。发现二：正确性分辨率有限。DeepSeek-V4-Pro 配 9 个脚手架的 Figure 1b 花瓣图显示 correctness 仅跨 0.42–0.765，而 task_comp 0.395–0.926、tool_inv 11.3–26.6 次、turns 1.8–16.6、walltime 74810–1078124、plan_grad 0.731–0.896、self_corr 0.739–0.937 等过程与运行时指标跨度大得多。发现三：效果-效率权衡随基准而变（Figure 6，按 $Q_h = 1-\sqrt{\frac{\hat{T}_h^2+(1-\hat{S}_h)^2}{2}}$ 排名）：DeepSearchQA 前三为 CrewAI、Google ADK、Claude-SDK（成功率集中但 token 差近一个数量级），τ-Bench 与 τ3-bench 前三同为 Claude-SDK、OpenAI Agents、AutoGen-AgentChat，若干脚手架烧更多 token 却无更高成功率。发现四：案例研究（Table 3）中同一 GPT-5.6-sol 在同一 pyknotid 任务上，Google-ADK（6 次 bash 全是侦察、plan_grade=0.2、tool_invocation=1.0）与 LangGraph（22 步、plan_grade=1.0、最后 bash 被截断致 tool_invocation=0.0）双双 correctness=0，但前者是早停的计划深度失败、后者是只差最后验证的晚停失败，凸显正确性单一指标的盲区。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| τ-bench（对话式工具使用，gpt-5.6-sol 后端） | pass@1（TRAJ-OK 轨迹） | 最佳脚手架 Claude-SDK 84.72% | 同模型最差脚手架 CrewAI 35.29% | 同一固定模型下脚手架间差距达 49.43 个百分点，说明 harness 影响远超 API 差异 |
| τ3-bench（对话式工具使用，gpt-5.6-sol 后端） | pass@1 | OpenAI Agents 84.00%、Google ADK 83.78% | CrewAI 38.61% | 差距 45.39 个百分点；τ 系列 harness 方差为全部基准中最大 |
| DeepSearchQA（深度网页研究，gpt-5.6-sol 后端） | Paper F1 | Google ADK 58.13% | AutoGen 56.38%（最低） | 差距仅 1.75 分，结果层指标几乎无法区分 harness，需过程指标补充 |
| GDPval（专业生产工作，gpt-5.6-sol 后端） | Bradley–Terry Elo（人类=1000） | LangGraph 1129.6 | OpenAI Agents 1041.4（最低） | 领先 88.2 Elo，且人类基线 1000 被所有 harness 超越 |
| DeepSearchQA（glm-5.3 弱后端） | Paper F1 | Smolagents 38.51% | Claude-SDK 5.81% | 相差近 6.6 倍：模型越弱，脚手架质量对性能的放大效应越显著 |
| Terminal-Bench 2.1（命令行计算机使用） | 解决任务成功率 | gpt-5.6-sol 下 Smolagents 76.5%，模型平均 68.3% | glm-5.3 模型平均 48.1% | 模型效应 20.2 个百分点；同模型下 harness 区间 63.0–76.5% |
局限与改进
作者承认的局限：指标目录'并非智能体质量的完整定义'，只是演示该架构如何组织、执行、存储与聚合异构指标；注册表支持某框架不等于该框架-基准对通过了端到端验证；AutoGen AgentChat 因依赖冲突需要隔离环境运行，暗示 harness 接入仍有工程摩擦。我自己的观察：其一，主报告只覆盖 2 个后端模型，'模型×脚手架交互'结论的统计功效有限，且 gpt-5.6-sol 上 DeepSearchQA 的 F1 差距（约 1.75 分）很可能小于评估噪声，论文未给置信区间；其二，LLM-as-judge 指标（plan_grade、failure_transparency 等）依赖特定评审模型，案例研究只有一局单个任务，没有跨种子方差；其三，默认 40 任务采样对小基准的置信度问题未讨论；其四，数据库中心设计带来 schema 演化与存储运维成本，论文未给性能基准；其五，Table 1 对 Inspect AI/Phoenix 的六维对比由作者自评，缺乏第三方复现；其六，UI 刻意只读，从评测结果回到 harness 改进的闭环仍完全依赖人工。
独立分析的弱点
弱点一：LLM-as-judge 指标的可靠性未量化——plan_grade、tool_invocation 等判分依赖特定评审模型，换 judge 或换提示词分数可能漂移，而论文既未报告 judge 与人工标注的一致性，也未做敏感性分析；改进方向是引入多人/多 judge 评审的一致性度量（如 Cohen's Kappa）、校准集与多数投票。弱点二：效果-效率得分 $Q_h$ 把归一化 token 与成功率等权合成，隐含'少花 token 总是好'的价值假设，对高难度任务或低延迟不敏感场景可能误导排名；可改为按任务难度、成本预算或风险偏好加权的帕累托前沿分析，并报告前沿的置信区间。弱点三：案例研究是单任务深描，虽然叙事说服力强，但'过程指标能区分失败模式'的普适性缺乏统计支撑；应扩展为失败模式自动聚类加大规模归因统计。弱点四：评估成本不透明——23×9×2 组合的 API 费用未披露，Figure 1b 显示单任务 walltime 跨 74810–1078124 毫秒，大规模复现门槛高；可发布成本估算器与分层降采样策略。弱点五：覆盖面偏文本与命令行，多模态 GUI 操作、长程跨会话记忆、多智能体协作等维度缺失。
未来方向
作者明确提出的方向：指标目录按新智能体能力、新基准与安全需求持续演化，把评估套件当作'不断演进的系统'而非固定分数集合；依托数据库做增量评估，使同一轨迹库可在不同指标版本、评审模型与聚合策略下重复打分；面向生产级 ML 基础设施补齐实验溯源、可审计与可复现能力。基于其成果可延伸的方向：一是规模化'离线指标回填'实验，研究评审模型迭代带来的指标漂移与校准方法；二是把诊断指标接入 harness 自动优化闭环，例如用 failure_transparency=0 的轨迹自动改进终止策略与状态报告；三是构建跨任务类型的 harness 推荐器——给定模型与任务画像预测最优脚手架；四是引入统计功效分析（样本量、置信区间、多重比较校正）让排行榜结论更严谨；五是扩展多模态与长程记忆评估维度，并将轨迹格式与 OpenTelemetry GenAI 语义约定对齐，推动行业标准化。
复现评估
开源情况良好：代码在 GitHub（github.com/datamllab/A2E）公开，论文详细给出 ATP 四个协议对象的语义、九个脚手架注册表与 23 个基准清单，附录 A 记录了匹配的解码设置、工具配置、步数限制、超时预算、官方评分规则与样本量。数据方面 23 个基准均为公开数据集（human-eval、swe-bench 系列、mmlu-pro、gpqa、τ 系列、terminal-bench-2.1 等），评测矩阵覆盖 9 脚手架 × 2 后端。算力门槛主要在 API 调用费用：默认每个组合无放回采样 40 个任务，Figure 1b 显示单任务 walltime 约在 7.5 万至 107.8 万毫秒之间，无训练需求，评估与存储可在普通硬件完成，但完整复现主表需要可观的 API 预算。综合评估：协议与架构描述清晰、工程复现难度中等，属可复现性较好的系统论文；不足是 LLM-as-judge 指标的评审模型版本与提示词披露不完整，judge 相关分数的精确对齐存在不确定性，且随机种子报告可更规范。
论文图表
