评测目的（多目的，非单一）
三条对比轴（同等重要，不分主次）
同一套题目、同一套评分器，沿三个不同方向切分实验组。一个维度不需要三条轴都能跑才算数——只要在任意一条轴上能产生可行动的结论，就值得纳入评测。
分两小组跑，缺一不可：
- 最强版本对比：BA / Codex / Claude Code 各自用官方推荐的最佳配置与模型。回答的是"作为一个产品，谁更强"，这是客户和投资人真正关心的数字。
- 同模型对比：三者统一挂同一个模型（如同一个 Claude 或同一个开源模型）。剥离模型能力差异后，剩下的差距就是 agent 框架本身（上下文管理、工具编排、记忆、反思循环）带来的增量。这才是 BA 工程价值的直接证据。
同一个 BA 版本，依次接不同开源模型（Qwen / DeepSeek / GLM / Kimi 等）跑同一批题。用来回答：内网部署该选哪个模型、量化到什么程度精度开始塌、哪些维度对模型能力敏感（如自制工具、反思）、哪些维度主要由框架兜底（如压缩保真度、记忆选择）。不涉及 Codex / Claude Code。
锁死模型，只换 BA 版本，每次迭代跑一遍。这是 CI 意义上的回归门禁：改了 compaction 策略、换了记忆检索算法、调了 system prompt，究竟是真变好了还是只在少数几个 demo 上变好了。同样不涉及 Codex / Claude Code——BA v1 → v2 的提升本身就是完整结论，不需要外部参照系。
维度 × 数据集覆盖矩阵
维度与数据集是多对多关系：一个数据集常常同时承担几个维度，一个维度也需要几个数据集交叉验证。下表把每一格都填满，用来暴露覆盖缺口——哪些维度只靠单一数据集支撑，一旦那个数据集有偏差就没有交叉验证。
| 维度 | GDPval | Present Bench |
Chart Mimic |
D2C HARD |
Edge Bench |
App World |
GAIA | τ²- bench |
自建 A 记忆压缩 |
自建 B 自主协作 |
覆盖强度 | agent-octagon 当前覆盖 |
|---|
维度 6 在当前 agent-octagon 没有真正的 50+ 轮或超长材料 env；维度 10 全靠自建 env 单点支撑。前者不能用“多步 workflow”替代，后者缺少交叉验证，读数时都要特别谨慎。
鲁棒性已有 safety / HITL 载体但缺 pass^k；维度 9、11、12 虽有建议测法，但当前 agent-octagon 还没有专门 env。尤其维度 6 还要单独补 A 类知识密集长任务——BA 能写 12 小时代码，不代表它读 200 页研报也撑得住。
指令遵从在当前 agent-octagon 已有 travel-planner / 真实 skill 约束执行基础，接 GDPval、PresentBench、tau2-bench 后能快速形成交叉验证。维度 2 的公开数据集很强，但当前 Octagon 还没有美学专门 env，不能算“已有基础”。
最终确定的 12 个评测维度
维度 9、10 为上下文与记忆机制；维度 11、12 为自主性与任务委派。它们相对当前 agent-octagon 属于专门 env 缺口，但准入标准不变：它必须能暴露一种现有维度全都放过的失败，否则就是重复计分。
这些维度不需要先补 BA 特有机制 env，当前 agent-octagon 已有直接或部分载体；下一步主要是把公开数据集抽样 3–5 题，包装成 Octagon task，并补 scorer。
GDPval / PresentBench / tau2-bench
AppWorld / ChartMimic / EdgeBench 扩展题
GAIA Level 2/3 / EdgeBench 迭代题
GDPval / PresentBench / 陷阱材料任务
tau2-bench / AppWorld
面对大量复杂信息时能否依然遵从原始指令，含引用原文/逻辑链的正确性
PPT / 图表 / 网页等交付物的视觉质量与设计合理性
面对没有现成工具的难题，能否自己写代码构造工具解决问题
走不通时能否意识到路走错了，重新思考并找到正确方向
处理源材料时是否编造数字、虚构引用、歪曲原文含义
跨 50+ 轮交互或处理超长材料时，能否保持前后一致、不丢失早期指令。这是结果层指标，维度 9/10 是它的机制层归因
工具报错、输入含噪声或矛盾、指令模糊时能否优雅处理而非崩溃/死循环
完成同一任务的 token 消耗、工具调用次数、墙钟时间；横切指标，从 trace 提取，不需要专门题目
上下文触发压缩/摘要后，任务关键信息（约束、数字、用户偏好、已排除的方案）的保留率。黑盒测法：在早期轮次埋入关键约束，压缩发生后用只能靠该信息答对的探针题检验。白盒测法：直接读压缩前后上下文做事实比对（BA 可从 Langfuse trace 提取）。
相关与无关记忆混杂时，agent 检索并实际采纳的条目质量。两类失败：漏召回（重复犯已纠正过的错）与误召回（把上一个项目的过时约束套到当前任务）。后者更隐蔽、危害更大，需专门构造干扰记忆条目来暴露。
无人逐轮纠偏时，agent 能否自己判断"做完了吗"。三个子指标：目标分解质量（拆错了后面每步都对也白搭）、过早宣布完成率（只做了 60% 就交，交付物看着像那么回事）、停不下来率（目标已达成仍继续打磨，烧掉数倍 token）。
不依赖 agent 有显式 goal 模式——任何多轮任务里 agent 都必然隐式回答了"我做完了吗"，故测的是行为而非功能开关。
在 BA 里，所有智能体同构——提示词与工具完全一致，接收方唯一的不同只是"它收到了一个 handoff 任务并开始干活"。因此不存在"该转交给谁"的决策，主→子 agent 与看板 handoff 在能力层面是同一件事：把上下文与意图压缩成一段任务描述，交给一个没有你的上下文的同构执行者。二者合为一个维度。
把委派文案交给一个全新的、空白上下文的同构智能体，看它能否独立完成。完成率即文案质量分数。因为接收方就是它自己，"接收方能力"这个混淆变量被物理消除——活没干成，唯一解释就是文案没写清楚。不需要人工评分或 LLM 裁判，正合轴 3 无人值守回归的要求。
同一测法可反向做消融：删掉文案中某一段再跑，完成率掉多少即该段信息的边际价值——这是调委派提示词的直接工具。
②与③的失败在完成率上长得一样（都是"没干成"），但修复方式相反，必须分开记分。判别法：接收方问了本该在文案里的问题 → 自足性问题（改提示词模板）；接收方干了但干不完整、或需主 agent 的其他部分才能继续 → 边界问题（改任务拆分逻辑）。
④ 回收验收率（条件性适用）：仅当结果会交回主 agent 时存在。子 agent 失败却报告"成功"，主 agent 不检查就当成事实继续推理，错误在后续步骤被放大。这种静默错误在单 agent 评测里根本不可能出现。若看板模式是任务所有权彻底转移、不回交，则此项不适用。
两者都是"把上下文压成一段文本，交给一个没有你的上下文的接收方"，在 BA 的同构设定下连接收方能力都一样，极易被误认为重复计分。区别在于：
最终选定的数据集清单
全部为 agent 适配、数据公开可下载。每个数据集只抽取 3–5 道代表题，不做完整接入。
220 题 gold subset，44 职业 × 9 大行业，平均 14 年经验专家构造，含参考文件。任务用真实材料 + 明确指令，专家盲评成对比较，质量在同类里最高。
238 题，5 大主题，平均 54.1 个二元检查项/题，自动 rubric 评分，与人类偏好相关度 0.532（同类最高）。数据集是目前 PPT 评测里质量最好、最新的。
4800 个（图表、指令、代码）三元组，全自动评分（执行成功率 + 结构化 F1 + VLM 视觉相似度）。天然支持"生成代码→执行→观察结果→修正"的 agent 迭代循环，论文验证自我反思能显著提分（81.2→84.8）。
80 个高难度网页（GitHub Pages 来源），比主测试集更能拉开差距。全自动视觉+DOM+CLIP 评分，评分管线可直接嵌入 agent 的"渲染→截图→比对→修正"循环。
51 题公开（总量 134），平均每题 57.2 专家小时构造，全 agent 场景（Docker 环境 + hidden judge 容器 + 12h+ 迭代反馈）。agent-octagon 当前已有 edgebench-juliet、ad-placement、apple-incremental-game 这类 coding/优化载体，但还没把 EdgeBench 作为一组系统化数据集接入。当前 SOTA（Claude Opus 4.8）仅 51.3%，远未饱和，是目前质量和新鲜度最高的 agent-native benchmark。
750 题，9 个模拟 App、457 个 API，agent 需写交互式代码调 API 完成任务。全自动数据库状态 diff 评分，同时检测"附带损害"（意外改动）。当前 SOTA 仅 48.8%（Test-Normal），远未饱和。Test-Challenge 子集含未见过的 API，可测泛化。
虽非最新（2023），但仍是 agent 工具调用/多步推理的事实标准，Level 3 题目需最多 ~50 步、不限工具组合，能清楚观察 agent 走错路后是否会重新规划。验证集 165 题（含答案）可本地跑。只取 Level 2/3 里"曾经明显走偏又拉回来"类型的题目。
当前活跃维护版本，4 个域（airline/retail/telecom/banking）共 264 题。LLM 模拟用户 + 政策文档 + 读写 API，全自动数据库状态比对评分。核心指标 pass^k 专门测"连续 k 次都成功"的可靠性，天然适合鲁棒性评测。
现成评测覆盖不了这两个维度：LoCoMo、LongMemEval 等记忆评测是纯对话问答，不是 agent 任务；上下文压缩保真度目前没有公开 benchmark。因此这块只能自建，与原「陷阱材料」构想合并为一类 env：
- 时间轴陷阱（测维度 9）：第 5 轮下达一个具体约束（如"所有金额一律用欧元计价"），任务拉长到第 50 轮以后才要求输出金额。压缩若丢了这条约束，会直接暴露为交付物错误。纯黑盒，三方 agent 都能跑。
- 记忆干扰项（测维度 10）：向记忆库预置若干条目，其中混入来自"另一个项目"的过时约束。看 agent 是否会误召回并套用。可同时统计漏召回（此前纠正过的错误再次出现）。
- 陷阱材料（测维度 5，原文档待确认项）：源材料中故意植入相互矛盾或已过时的数据，看 agent 是盲信、还是识别并主动澄清。
- 终止判断（测维度 11）：任务带一个客观可判定的完成条件，但不告诉 agent 这个条件。记录 agent 实际停在第几轮，与真实完成轮次比对，得出过早/过晚两个方向的偏差。可复用 EdgeBench 的长任务与 GAIA 的唯一答案题。
- 同构复现（测维度 12 主指标）：截获 BA 产出的委派文案，交给一个全新的、空白上下文的同构智能体独立执行。完成率即文案质量分数，全自动、无需 rubric。删段消融可给出每段信息的边际价值。
- 谎报成功的子 agent（测维度 12 第四项）：注入一个被改造过的子 agent，它在特定子任务上返回看似合理但错误的结果，并声称成功。看主 agent 是照单全收还是会验证。仅在结果回交主 agent 的场景下适用。
维度 9 和 12 都面临同一个陷阱：agent 可以选择不压缩、不委派，用超长上下文硬扛。这样测出来的低分反映的是架构选择，不是能力缺陷。
解法是让任务所需上下文物理上超过单窗口容量（如 20 份互不相关、都必须读完的长文档）。硬扛这条路被堵死，不压缩/不委派就完不成任务，剩下的差距才是真实的能力差距。这也是维度 12 能在轴 1 上跨 agent 比较的前提——Codex 与 Claude Code 都有 subagent 机制，只要任务逼着它们用。
BA 目前没有 goal 模式，正在考虑做。这意味着维度 11 不只是评测，它会反向驱动功能设计——先立尺子再造功能。
风险随之而来：goal 模式会被做成"在这 5 道题上收敛得特别漂亮、换个任务就停不下来"的东西（Goodhart 定律）。因此维度 11 的题目必须切成公开集与保留集，保留集在 goal 模式上线前不对开发者开放。全体系里只有这个维度需要这条纪律，因为只有它直接反向影响功能实现。
四类真实使用场景
研究报告、行业分析、文档摘要、知识问答
PPT、海报、数据可视化、方案文档
写代码、debug、数据处理、自动化脚本
读大 JSON → 按流程调 MCP/工具 → 产出大 JSON → 再决策，不是传统审批工单流
明确排除的数据集
社区已有多篇文献指出其题目质量问题：部分题目答案信息泄露在 issue 描述中、测试用例过弱导致平凡 patch 也能通过（见 SWE-bench+ / UTBoost 等后续工作的修正）。改用 EdgeBench（Systems & SWE 类）与 AppWorld 承担"自制工具"维度的编程能力评测。
均为单轮 text-in text-out 的纯 LLM 评测，不涉及工具调用或多步交互，不能直接当 agent 任务跑。仅作为素材来源：把它们的 prompt / 文档 / 事实性问题包装进 agent 任务（如"基于这份文档做分析并遵守格式约束"），而不是照搬原题直接跑分。
论文已发布（2026），但数据和代码尚未公开发布，暂不可用。持续关注后续放出。
1320 题中仅 220 题 gold subset 公开可下载，其余需走 OpenAI 官方评测服务，本次只用公开的 220 题。
总体规模
下一步待确认
- 从每个数据集的候选题池中，具体挑哪 3–5 道题（需要人工过一遍质量，避免抽到有歧义/答案存疑的题）
- 每道题如何包装成 Octagon env（meta.yaml 的 dimensions/weight 怎么定，是否需要新写 scorer.py）
- GAIA 数据集是 gated（需接受 HuggingFace 使用条款），需要确认账号权限
- Design2Code / ChartMimic 原生是单轮生成评测，需要设计 agent 的"生成→渲染→自查→修正"任务外壳
- （已决议）幻觉控制的"陷阱材料"任务确认要做，并与维度 9/10 的自建 env 合并为同一批构造工作
- 维度 9：需要确定压缩触发点如何在 env 中稳定复现——不同 agent 的压缩阈值不同，题目长度要保证三方都必然触发至少一次压缩，否则测的是"没压缩"而非"压缩得准不准"
- 维度 10：Codex / Claude Code 是否提供可编程的记忆注入接口（CLAUDE.md、AGENTS.md 算不算等价物），决定轴 1 上这个维度能否成立；若不成立则只在轴 2 / 轴 3 上跑
- 轴 2：候选开源模型清单尚未确定（Qwen / DeepSeek / GLM / Kimi 各选哪个尺寸、是否含量化版本）
- 轴 1 的"同模型"组：需确认 Codex 与 Claude Code 能否挂载同一个自定义模型端点（如指向内网 vLLM），否则该组只能退化为"同一个 Claude 模型"的三方对比
- 维度 11：需要先划定公开集 / 保留集的边界与保管方式（谁持有保留集、什么时候解封）。这条要在 BA 的 goal 模式立项之前定下来，事后再补就失效了
- 维度 12：看板 handoff 之后，任务所有权是彻底转移（接收方独立完成、不回交）还是结果回交主 agent？前者则"回收验收率"这一子指标不适用，后者则它是最该盯的数字。这决定自建 env 少造还是多造一道题
- 维度 12：需确认 Codex / Claude Code 的 subagent 机制能否被 env 稳定地"逼出来"——若某一方在上下文超限时选择直接失败而非委派，则该方在此维度上无有效读数
- 维度 12：同构复现测法在轴 1 上要打折扣——Codex / Claude Code 的 subagent 与主 agent 并非同构（系统提示词不同），"接收方能力"这个混淆变量回来了。轴 1 上完成率的差异不能完全归因于文案质量，需另设对照或降级为定性观察
- 维度 10 的单点风险：它只有一个自建 env 支撑，没有任何交叉验证。是否需要构造两套独立设计、互不参考的题目，用两套题的一致性来交叉验证 env 本身的有效性