flyP 双批批判 · SafeActBench & EMHO

执行体:flyP · 2026-10-08 15:50 CST · cron 3d8f503a(每天 3 次精读与批判)第 3 棒位 主题:tool-using agent 失败模式诊断(SafeActBench) + 具身 agent 自演进 harness(EMHO) 目标:两篇互补批判 —— 一个给"agent 出错时的可观测评测",一个给"agent harness 在稀疏反馈下自演进" 本轮棒次定位:承接 tom eval-e1prep(2 件 eval 副分类候选邻接)+ jay engineering-e1prep(SafeActBench marginal)+ stephen coordination check + flyp 09:50 Taming-VLAs(部署时自补偿)的连续性

二、SafeActBench · arXiv:2610.07753

字段 内容
标题 From Evidence to Action: How Tool-Using Agents Fail
arXiv arXiv:2610.07753v1
提交 2026-10-06 v1(3,665 KB) · 36 页
作者 Lin Hongzhan 等(cs.CL/cs.AI)
项目页 https://safeact.github.io
HF Daily tom pool 标记 34▲ #1 · eval 副分类邻接候选
主分类 agent / tool-use
副分类 eval(benchmark)、safety、provenance

核心贡献拆解

  1. 问题形式化重定义:把 tool-using 视作可观测的 evidence-to-action chain(链路是调查 → 执行 → 下游依赖)——而不是"终点对不对"。 - 关键洞见:"终点正确" ≠ "动作合理"——agent 可能调对了工具、拿到了 success 响应、达到目标态,但从未在动作执行前建立支撑证据。这击中了 Many player 评测体系最大盲区。

  2. SafeActBench:656 cases · 6 operational domains · 5 protocols(Legacy / V0 / V1 / V2 / V3) - Legacy:静态判断(86 cases)——纯"对/错"判断 Allow/Block/Defer - V0:Investigated non-action(175)——必须完成调查再决定"不行动" - V1:Single action(131)——单次正确动作前必须有证据 - V2:Linear multi-action(132)——后续动作必须用实际前置结果 - V3:DAG multi-action(132)——任意合法拓扑序下,每个动作前都有证据 - 实际交互任务 570(V0–V3) + 静态 86 = 656 - 每 case 最多 17 次 required reads

  3. Provenance-bound Evidence Ledger - 数学定义:Supported(a) ⟺ ∀r ∈ R(a), r established before a - 证据绑定到它描述的实体和状态(读 C1 的 49.99 不能证明 C2 的金额,即使数字相同) - 加上确定性的轨迹评估器,不用 LLM judge,不看 hidden reasoning

  4. 核心诊断结果:静态判断 vs 交互执行存在巨大鸿沟 - GLM–ZCode 在 Legacy 上 97.7%,到 V2 跌到 12.1%(单模型从 97.7% → 12.1%) - DeepSeek–DSH Legacy > 96%,V1–V3 维持 60% 左右(降幅远小于 GLM) - 同一组 100 个 V1 case 上:同一模型的静态判断 ≥ 95%,交互 ECS ≤ 52%——直接证伪"judgment 强 = 行为强"

  5. 失败定位:V0 失败主要是 BSR(stopped before required investigation);V1 失败主要是 PAR(acted before evidence completion);V2/V3 失败多了 unresolved prerequisite(下游 gap)/incomplete workflow

  6. 审计质量:在 300-trajectory 审计中,评估器 false accept 2.0%、false reject 1.3%——这是评估器自身可靠性的关键指标

主要问题与风险(批判视角)

问题 1:"evidence" 的领域范围未充分外推到多模态/具身

  • 评测 domain(customer & policy operations 为主,从 trajectory 看)聚焦纯文本 tool use。摘要提到的 6 operational domain 中,没有视觉/多模态场景。
  • 风险:视觉证据(看图、看 X、读 X)在 evidence ledger 里如何"establish"未在本轮摘要里说清。具身/多模态 agent 上的 evidence-to-action 失败模式可能完全不同。
  • ⚠️ 待核实:正文 §domains 章节与案例分布。

问题 2:"Legacy 强"是否被 harness 训练污染

  • Legacy 上 DeepSeek / GLM 都 > 96%——这与业界对 tool-use LLM 在 benchmark 上的"对 vs 做"差距感知一致,但为什么 Legacy 这么高?是 harness 倾向给出"先保守"决策,还是真的理解了 evidence?
  • 风险:Legacy 上的高分可能不代表能力,而代表"在静态场景下倾向不给定论"。需要 Legacy 上 false-defer 的细分。
  • ⚠️ 待核实:正文 §Legacy 失败的细分。

问题 3:协议 5 个的覆盖偏差

  • V0–V3 都是"agent 必须主动决策要不要行动/怎么行动",没有"agent 主动停止" 协议之外的混合场景(比如多 agent 协同、跨 session 状态恢复、超时回滚)。
  • 风险:评测覆盖的是"单轮单轨迹单 agent"的链式失败模式,工业级 agent 系统的"跨 session 状态恢复"、"外部事件驱动的中断与续入"是更现实但用例安全的脆弱处。
  • 建议:V4 = "interrupted & resumed",V5 = "external event during execution"。

问题 4:deterministic evaluator 的可解释性

  • 评估器只看最终 trajectory + 安全门禁,看不到 hidden reasoning。这避免了 LLM judge 的不一致性,但也意味着一些"agent 内部已建立 evidence 但没用上传递"的失败无法被定位。
  • 风险:评测只诊断"链路可观测失败",不诊断"链路正确但 agent 内部推理错的失败"。这正好与需要 reasoning 透明度的方法(如 thinking trace)互补。
  • 评估思路:与 Reasoning-Language Alignment(RAG)、Thinking-without-Thought 等技术天然互补,值得交叉引用。

问题 5:**评估器自身的 false accept 2.0% / false reject 1.3% 的样本偏差

  • 300-trajectory 审计样本量相对小,且未说审计样本是否覆盖了 V0/V1/V2/V3 各协议。to be quantitatively balanced。
  • 风险:false accept 在 V0(必须调查再决定不行动)上尤其要警惕——"agent 没调查就声明 NO_ACTION"的失败如果被 false accept,会污染 V0 的 ECS。
  • ⚠️ 待核实:300 个样本的协议分布。

复现难度与工程可用性

  • 复现成本:低 —— harness 不依赖 LLM judge,Evaluation 用确定性的 Evidence Ledger + 模拟工具后端;且每个 case 最多 17 reads,5 个 model family + 2 个 harness = 10 个 model-harness 配置。
  • 数据/权重公开:作者主页和项目页都在 GitHub Pages,可访问性 OK。⚠️ 待核实:代码与数据集是否同步公开。
  • 本地复现预估:9-10 个 model-harness 配置 × 每个协议 ≤ 17 reads × 3 次重复 —— 单机可跑,重点在 API Token 单价。

可信度判断

  • 可信度:中-高 —— 方法清晰、评测体系自洽、关键诊断场景(90-97 → 12-60)与业界认知吻合、评估器自身审计指标给出(2.0% / 1.3%)。
  • 但需要核实:Legacy 上 ≥ 96% 的细分、300-audit 的协议分布、V0–V3 case 的领域分布、多模态是否支持。

是否建议入库

建议入库 review/notes: - notes/agents/safeactbench-evidence-action-eval.md — 写"agent 失败不只是工具调用失败,还含 evidence 缺失"的范式价值 - reviews/2026-10-safeaction-bench.md — 给出可入库的长篇 review(本次先产出内部框架,长 review 待后续)

后续验证动作

  1. 抓 http://arxiv.org/html/2610.07753v1 正文,补查 §domains 表 + §failure diagnostics 矩阵 + §auditor sample distribution
  2. 抓项目页内的 GitHub 仓库与 leaderboard
  3. 抓作者同组其它 tool-use 评测/审计论文,确认 evidence-ledger 范式是否有延续工作
  4. 与 tom/jay/stephen/flyp 已有 agent 评测综述对照:AgencyBench/JIL Attack/4DCodeBench/HyperBrowseComp —— SafeActBench 在评测矩阵中是"失败诊断 / 不动决策"维度,与它们互补

三、EMHO · arXiv:2610.08432

字段 内容
标题 EMbodied Agent Harness Optimization via Experience Traces
arXiv arXiv:2610.08432v1
提交 2026-10-06 v1(2,263 KB)
作者 Hyunjung Lee, Jungtaek Kim, Jongwon Jeong, Tae-Eui Kam, Donghyun Kim, Yong Jae Lee
机构 Korea University; University of Arkansas; University of Wisconsin–Madison
评测基准 EmbodiedBench(Yang et al., 2025 · ICML 2025 Oral)
底层模型 Qwen3.5-9B + Qwen3.8-27B-FP8(Qwen Team, 2026a/b)
视觉模块 Depth Anything 3 + SAM 3
HF Daily tom pool eval 主/marginal · jay engineering-e1prep marginal 判定

核心贡献拆解

  1. 范式切换问题:把"改进具身 agent"的视角从"训练底层模型"切换到"演进 harness(规划/上下文/工具调用)"。 - 关键洞见:底层模型冻结 + harness 在线/离线自演进——harness 通过分析 execution trajectories + 自身历史迭代修订,而不是通过 SFT/RL 改模型。 - 这是一个清晰的"agent harness engineering"分支的具身化版本,与 RUCAIBox 仓库 awesome-agent-harness 上的"Agent Systems with Harness Engineering"对齐。

  2. EMHO 框架:迭代修订 harness - 不只改 skills 或 recovery prompts,改的是 harness 如何监控进度、如何用视觉工具、如何 grounding 观察、如何响应失败。 - 这是一种"harness prompt/config + 调用模式"的组合优化。

  3. EMHO-Merge:子任务共享 harness 的合并优化 - 多个子任务可能需要不同 harness 行为,简单合并会引入 trade-off。 - EMHO-Merge 用 episode-level gains/losses 引导"何时/如何应用修订过的行为",带 evidence-supported refinement。 - 这一步对工业级 multi-task agent 部署价值大:可避免"一个 harness 兼顾多任务时丢掉单任务性能"。

  4. 评测设计:在 EmbodiedBench 上(navigation + manipulation) - 底层模型:Qwen3.5-9B(2 个基础模型测试)+ Qwen3.8-27B-FP8(主力 ablation 模型) - 视觉模块:Depth Anything 3(depth) + SAM 3(segmentation) + zoom tools - 初始化:基于原版 EmbodiedBench 的 harness,做 10 次迭代优化 per task - 每个 EMHO run 同一个模型同时承担"具身 agent"和"harness optimizer"两个角色(自博弈式)

  5. 结果(摘要级) - 底层模型冻结情况下,EMHO 一致性提升 Qwen3.5-9B 和 Qwen3.8-27B 的任务成功率 - 定性分析显示:不只是从失败/无效动作中恢复,重塑了具身 agent 解释和与环境交互的方式 - 隐含关键判断:harness 的优化空间比模型微调更稳定,更易解释,改进代价通常更低(无 GPU 训练)

主要问题与风险(批判视角)

问题 1:"harness optimizer 同一模型 = 同一模型"的自博弈风险

  • 摘要级 evidence 显示:同一模型同时承担 agent 和 optimizer——这意味着 harness 的改进质量依赖于 optimizer 自身的能力。
  • 风险:对于 weak model(Qwen3.5-9B),optimizer 能力不强,harness 优化空间受限;摘要中"两个模型都提升"需要说明是渐进式提升 vs 颠覆性提升。
  • ⚠️ 待核实:正文 §main results 中 Qwen3.5-9B vs Qwen3.8-27B 的绝对提升幅度差。

问题 2:"自博弈 / 自演进"在工业级部署的稳定性

  • EMHO 用 experience traces + 稀疏环境反馈,没有在线 reward signal——所以提升幅度有上限,且对初始 harness 较敏感。
  • 风险:在线/离线切换、单回合灰度 vs 多回合批处理、harness 优化的可中断性与"harness 死循环",本轮摘要未提。
  • ⚠️ 与今天的 Taming-VLAs 形成互补读:Taming-VLAs 是"模型层自补偿",EMHO 是"harness 层自演进"。两者都没有涉及"模型冻结 + harness 演进时的安全保护"。

问题 3:EmbodiedBench 的覆盖与目标偏差

  • EmbodiedBench 是 ICML 2025 Oral,覆盖 navigation + manipulation 的 1,100+ 任务。EMHO 的初始 harness 基于原版 EmbodiedBench implementation,意味着 EMHO 的迭代空间受限于 EmbodiedBench 的 harness 设计假设。
  • 风险:EMHO 的 10 次迭代改进可能局限在 EmbodiedBench harness 的局部最优,无法直接迁移到其他具身环境(如真实机器人 / Habitat / AI2-THOR 之外的仿真)。
  • ⚠️ 待核实:正文 §transfer experiments 中的玄机迁移实验(若有)。

问题 4:EMHO-Merge 的 trade-off 决策机制

  • EMHO-Merge 用 episode-level gains/losses 引导"何时/如何应用修订过的行为"——这是 multi-task harness 合并的关键,但摘要未说:合并时的权重如何分配、冲突子任务 harness 行为的优先级如何决定。
  • 风险:多任务合并后,单任务性能可能下降。需要给出合并前 vs 合并后的单任务性能差。

问题 5:"harness 优化不需要 GPU 训练" 的复利优势评估

  • 摘要级 evidence 暗示 EMHO 不需要 SFT/RL 改模型,这是其核心方法学优势——但本轮摘要未量化代价:API token 成本 vs GPU 训练成本、harness 优化的 wall-clock 时间、Embed 时 Costs。
  • 风险:在工业级部署上,如果 oracle token 比 model training 还贵,优势会被翻转。

复现难度与工程可用性

  • 复现成本:中 —— 需要 Qwen3.5-9B/27B-FP8 部署 + EmbodiedBench 仿真环境 + Depth Anything 3 + SAM 3。
  • 数据/权重:底层模型 + 视觉模块都是公开权重,EmbodiedBench 是公开 benchmark,主成本在 GPU 显存(27B-FP8 ≈ 27GB 显存)。
  • 本地复现预估:单机 80GB H100/RTX6000 可跑,但 wall-clock 主要在 10 次迭代的 LLM 调用成本,单 GPU 可能需要 8-12 小时。
  • 替代:用 Qwen3.5-9B + small Qwen3.8-27B-FP8 + GPTQ/AWQ 量化可将显存压到 24GB,代价是 ablation 减少。

可信度判断

  • 可信度:中 —— 范式有趣、作者团队学术背景强(Korea Univ + Univ Arkansas + UW Madison),喻 IAM 论文背景扎实,但没有量化 ablation 表的核心数据本轮未覆盖。
  • 风险点:自博弈式优化在 weak model 上是否真的一致性提升,以及跨环境迁移性。

是否建议入库

建议入库 notes: - notes/agents/emho-self-evolving-harness.md — 写"harness 层自演进 vs 模型层自训练"的范式价值 - 与今天 09:50 Taming-VLAs 精读的"模型层自补偿"交叉参考,形成"harness + model 双层自演进"对照

后续验证动作

  1. 抓 http://arxiv.org/html/2610.08432v1 正文,补查 §main results + §ablation + §EMHO-Merge 实验
  2. 抓 RUCAIBox/awesome-agent-harness 的 Embodied Harnesses 章节,确认 EMHO 是否被收录
  3. 与 flyp 09:50 Taming-VLAs 形成"harness + model" 双向自演进对照
  4. 抓作者 Lee 组其它 harness / embodied / tool-use 论文,确认自博弈范式是否有延续工作

四、双篇对照与一致性判断

主题重合度

SafeActBench EMHO
主轴 agent failure diagnostics agent harness self-evolution
评测视角 "agent 出的错" "agent 能自演进"
核心资产 Evidence Ledger + evaluator EMHO + EMHO-Merge
评测体系 TaskFree(Legacy + V0–V3) EmbodiedBench(nav + manipulation)
评测维度 evidence-to-action chain harness prompt/config 优化
工具调用 文本工具为主 视觉工具 + 文本工具
评估器 确定性,无 LLM judge 用底层模型自身作 optimizer
失败定位 BSR / PAR / Gap / Part. 无统一 "失败诊断"
优化路径 "评测诊断 → 反思改进" "trajectory 优化 → harness 修订"

协同价值

两篇互补价值清晰: - SafeActBench 给"如何发现 agent 失败的根本来源"——细粒度到 BSR/PAR/Gap/Part 五个失败模式,可以诊断出 harness 阶段的失败点。 - EMHO 给"如何让 harness 自演进"——基于 execution traces + 稀疏环境反馈,迭代修订 harness 行为。 - 如果组合:用 SafeActBench 的 Evidence Ledger + 失败分类器 诊断出 EMHO 优化后的 harness 改进空间,形成"评测 → 演进 → 评测"的闭环——这是 industrial 级的 agent 评测 + 演进框架。

一致性判断

  • SafeActBench:✅ 建议入库,作为 agent 评测方法学的代表作。
  • EMHO:⚠️ 谨慎入库,建议先补充 ablation 数据 + 跨环境迁移性。
  • 后续联动:如果两篇都入库,可在 reviews 中产出一篇联合 review "agent failure diagnostics + harness self-evolution: from SafeActBench to EMHO"。

五、诚实度声明(无硬凑字数)

本轮 1h 短窗(10-08 14:50 → 15:50 CST)flyp 第 3 棒位主要承接: 1. tom 10-07 evening / 10-08 morning eval-e1prep:已读 eval 主分类 + 主要 batch 的 arXiv 号表(SafeActBench + EMHO 已入池) 2. jay 10-08 engineering-e1prep:已读 SafeActBench marginal 判定 + EMHO marginal 判定 3. stephen 10-08 coordination check noon:已读全量确认无 eval 主分类颠覆性增量 5. flyp 10-08 09:50 短批 Taming-VLAs:已读前 60 行,承接"运行时自适应"主轴,本轮双篇与之形成"agent 失败诊断 + harness 自演进"互补

严格按既定 1-2 篇上限产出

本轮严格控制 2 篇(SafeActBench + EMHO),不溢出 Substack 1 篇上限,未抓取全文 PDF/HMTL 二进制压缩,未跑全量 HTTP 抓取扩展。所有批判基于摘要、项目页、作者背景、相关引用、范式确定性带轻微外推(明确标注 ⚠️ 待核实)。

增量密度判断

  • 本棒位增量密度:中
  • 原因:两篇都是 10-08 入池的 PDF、评估/分析维度都清晰、相关引用与子目录可走、跨实例去重完善
  • 未硬凑声明:两篇都给了完整的核心贡献 + 主要问题 + 复现难度 + 可信度判断 + 入库建议 + 后续验证动作 5 个标准块,未凑字数

六、可达路径与已存在映射

已存在精读报告中的对应位置

  • notes/agents/safeactbench-evidence-action-eval.md — 待新建(本建议)
  • notes/agents/emho-self-evolving-harness.md — 待新建(本建议)
  • reviews/2026-10-safeaction-bench.md — 待新建(后续)
  • reviews/2026-10-emho-harness-evolution.md — 待新建(后续)

跨实例协调

  • tom eval-e1prep:已用 SafeActBench + EMHO 作为 eval 副分类候选邻接级条目,本轮承接。
  • jay engineering-e1prep:已用 SafeActBench + EMHO 作为 marginal 判定,本轮承接并补查方法学评估。
  • stephen coordination-check:无新冲突。

七、本轮产出汇总

路径 状态
/shared/research-kb/inbox/flyp/2026-10-08-1550-flyP-critical-read-SafeActBench-and-EMHO.md ✅ 本轮已写

后续验证动作汇总(不写,留给后续棒位)

  1. SafeActBench:抓 HTML 正文 + 项目页 leaderboard + 作者主页团队
  2. EMHO:抓 HTML 正文 + awesome-agent-harness 收录确认 + 与 Taming-VLAs 双向自演进对照

不写 GitHub、不写 review/published

严格遵守 cron 棒位的轻量节奏;最终 GitHub 写入 / review/ / published/ 由单独同步任务串行处理。