让智能体有可操作的结构化表面

TL;DR：这一期我关注的不是“再给智能体更多上下文”或“每一步都换成更强模型”，而是智能体工作时需要什么样的结构化操作表面。入选的四篇分别讨论：用共享工作板做大规模 web-to-table 数据抽取、用事件检测决定电脑使用智能体何时升级到大模型、用 trace 分析多智能体系统中的信息污染，以及把 reward model 的机理分析目标从词表投影换成 reward head 方向。

本期我在看什么

前几期已经反复讲过可验证状态、硬证据和科研智能体接口。这一期我想收窄一点：当一个智能体要连续工作很多步时，它用什么界面工作，本身就会影响系统能力。

数据智能体的界面可能是一块共享表格工作板。GUI 智能体的界面可能是一组事件检测器，判断什么时候该从便宜小模型升级到强模型。多智能体工作流的界面可能是可比较的执行 trace，帮助定位被污染的信息在哪一步改变了路由和工具调用。RLHF 里的 reward model 也一样：如果最终目标不是 token，而是一个标量 reward，那机理工具就应该沿着 reward head 的方向看。

这也是本期写作的约束。每篇都先补问题背景，再讲方法。每张图都必须解释它支撑了什么 claim，而不是只贴在正文里当装饰。

论文细读笔记

Web2BigTable: A Bi-Level Multi-Agent LLM System for Internet-Scale Information Search and Extraction

作者：Yuxuan Huang, Yihang Chen, Zhiyuan He, Yuxiang Chen, Ka Yiu Lee, Huichi Zhou, Weilin Luo, Meng Fang, Jun Wang。
机构：University of Liverpool；Huawei Noah’s Ark Lab；University College London。
日期/出处：2026 年 4 月 29 日，arXiv 预印本。
链接：arXiv | HTML | code

这张界面图是进入论文的最好入口。Web2BigTable 不是让一个 agent 在浏览器里一路搜索到底，而是把查询拆成子任务，把约束、schema、worker 结果槽都放在共享工作板里。它支撑的核心 claim 是：宽表抽取需要围绕部分结构化状态协作。需要谨慎的是，这种设计默认任务可以比较自然地拆成多个相对独立的子问题。

架构图把长期技能和短期工作状态分开了。orchestrator 读取分解技能，worker 读取执行技能，工作板通过 tag 分区和文件锁来协调并发写入。红色路径表示训练阶段的 run-verify-reflect：系统根据 gold table 更新外部技能记忆，但不更新底层 LLM 参数。也就是说，这篇更像是 agent memory 和协作协议论文，而不是新模型训练论文。

一句话核心 idea：Web2BigTable 把开放网页搜索改写成结构化 web-to-table 任务，再用双层多智能体系统学习“怎么拆任务”和“怎么执行子任务”。

为什么重要：很多 data agent demo 其实是 deep search demo。它们擅长找一个答案、解释它、给几个引用。但真实数据工作经常要的是一张表：很多实体、同一组字段、多个来源、还要尽量避免漏行。单个 agent 很容易在一个长轨迹里丢掉覆盖度，因为它同时要记住实体列表、字段约束、来源证据和已经填过的行。

方法拆解：

1. 论文先定义 web-to-table search：从开放网页证据中构建 schema 对齐的大表，覆盖宽搜索和深搜索两类任务。
2. 系统分成上层 orchestrator 和下层 worker。orchestrator 负责把查询拆成子任务，worker 负责搜索、核验和把结构化结果写进共享 Markdown 工作板。
3. 训练阶段，每个 episode 会和 gold table 对比，反思结果更新两个外部技能库：分解技能库和执行技能库。底层 LLM 保持冻结。
4. 推理阶段，技能库冻结，多个 worker 并行运行，最后从工作板聚合出表格结果。

关键证据：在 WideSearch 上，论文报告 Avg@4 Success Rate 38.50、Row F1 63.53、Item F1 80.12。作者还专门做了对照，说明收益不是单纯来自更强底座：GPT-5 mini 和 Gemini 3 Flash 单独作为 agent 时 Item F1 只有 33.28 和 31.61，而完整框架达到 80.12。XBench-DeepSearch 上，Gemini 3 Flash 版本达到 73.0 accuracy。案例也很直观：Taylor Swift 演唱会表格任务有 534 个 ground-truth rows，Web2BigTable 最终提交 556 个去重行，Row F1 达到 93.8%，明显高于单 agent 和无技能版本。

我的判断：我喜欢这篇，是因为它把“记忆”当成可编辑的过程知识，而不是 embedding 仓库。最强的部分是分解、工作板和技能库这组三件套。弱点也很明显：可分解假设很重。如果某些表格字段依赖跨实体联合推理，只有 worker slot 和文件锁可能还不够，下一步需要更明确的冲突消解和跨 worker 证据合并。

对应主题：data agents、agent memory、开放网页抽取、结构化工作流状态。

Step-level Optimization for Efficient Computer-use Agents

作者：Jinbiao Wei, Kangqi Ni, Yilun Zhao, Guo Gan, Arman Cohan。
机构：Yale NLP Lab；University of North Carolina at Chapel Hill。
日期/出处：2026 年 4 月 29 日，arXiv 预印本。
链接：arXiv | HTML

这张 pipeline 图先把问题讲清楚了：小模型默认执行，两个轻量 monitor 观察轨迹中是否出现 stuck event 或 milestone event；风险上升时才切到强模型，之后再把控制权还给小模型。它支撑的 claim 是，电脑使用智能体应该在 step 级别分配算力，而不是每一步都调用 frontier model。

这张表把准确率、延迟、成本和升级比例放在一起，是论文最有产品感的证据。OSWorld 上，EvoCUA-8B + Kimi K2.5 达到 58.2% success，每个任务成本为 0.051 美元，接近单独 Kimi K2.5 的 60.1%，同时比一直调用 Claude Sonnet 4.5 便宜很多。但表里也能看到另一面：OSWorld cascade 中，大模型仍处理大约 40% 到 63% 的执行步骤。这不是“小模型替代大模型”，而是“小模型减少一部分不必要的大模型调用”。

ablation 图说明这个路由策略不只是单一启发式。stuck detector 处理局部循环和停滞，milestone detector 处理看起来还合理、但可能已经偏离目标的语义检查点。两个 detector 一起用，在图中 OSWorld 和 WebArena 设置下效果最好。需要注意的是，event 的定义和标注会变成系统契约；如果真实产品里的“卡住”和“里程碑”长得不一样，cascade 可能过度升级或漏掉失败。

一句话核心 idea：这篇把电脑使用 agent 的推理改成事件驱动的 cascade：便宜模型默认执行，轻量检测器发现高风险步骤时再调用强模型。

为什么重要：GUI/电脑使用 agent 贵，不只是因为模型贵，还因为系统把每一步都看成同等困难。真实轨迹里，大量动作是例行操作，少数节点决定任务是否循环、漂移或恢复。均匀分配算力浪费成本，也掩盖了失败原因：一个任务失败可能只是因为早期一步偏了，而不是每一步都需要 frontier reasoning。

方法拆解：

1. 在 OSWorld 和 WebArena 风格的交互任务中，小模型作为默认执行 policy。
2. stuck monitor 根据最近的 reasoning/action history 检测重复动作、进展停滞和局部失败。
3. milestone monitor 找到有语义意义的检查点，让强模型做稀疏验证，捕捉 silent drift。
4. controller 只在事件触发时升级到强模型，完成恢复或核验后回到小模型。

关键证据：OSWorld 上，Qwen3-VL-8B + Kimi K2.5 达到 59.3% success，接近单独 Kimi K2.5 的 60.1%，成本更低；EvoCUA-8B + Kimi K2.5 达到 58.2%，每任务 0.051 美元。WebArena 上，AgentTrek-32B + GPT-5.2 达到 58.8%，接近单独 GPT-5.2 的 60.1%，成本从 0.335 美元降到 0.208 美元。detector 结果也有信息量：learned stuck detector 达到 93.9% accuracy 和 91.5% F1；milestone detector accuracy 为 94.1%，但 F1 为 62.0%，这和 milestone 稀疏且模糊的性质一致。

我的判断：这是一篇很贴近产品部署的 agent 论文。它没有假装小模型能做所有事，而是问了更好的问题：什么时候需要昂贵判断？我会继续看它的 detector 能不能迁移到真实企业 UI，尤其是那些服务很慢、状态反馈不稳定、业务里程碑高度领域化的界面。

对应主题：agentic training、GUI agents、计算预算分配、中间状态核验。

Trace-Level Analysis of Information Contamination in Multi-Agent Systems

作者：Anna Mazhar, Huzaifa Suri, Sainyam Galhotra。
机构：Cornell University；University of Illinois Urbana-Champaign。
日期/出处：2026 年 4 月 30 日，arXiv 预印本；ACM CAIS 2026。
链接：arXiv | HTML

这张图用一个收入分析 workflow 引入问题：表格解析错误不会只改一个数值，它会改变后续路由、重试和解释策略。它支撑的核心 claim 是，多智能体系统里的不确定性不是单纯的输入质量问题。一旦 agent 根据被污染的 artifact 调用工具、写中间状态、选择下游 agent，它就变成了轨迹问题。

结构编辑距离图展示不同扰动如何改变 workflow trace。OCR noise 会带来比较稳定的结构变化，image blur 的方差更大。这个图的价值在于提醒我们：两个扰动即便最终答案影响类似，也可能有完全不同的运行时签名。不过 edit distance 抽掉了词面内容，所以它适合诊断控制流，不等于语义正确性。

first divergence point 图补了时间维度。有些扰动在解析阶段就触发路由变化，有些会先通过早期处理，直到推理或综合阶段才暴露。它给出的工程启发很直接：验证不应该只有最后一道 guardrail。不同污染模式需要在抽取、计算或综合阶段布置不同检查。

一句话核心 idea：这篇把 artifact-derived representation 做受控扰动，然后比较 clean 和 perturbed 多智能体执行 trace，定位信息污染何时、如何改变系统行为。

为什么重要：多智能体系统越来越常处理 PDF、表格、幻灯片、图片和工具输出。一个坏 OCR span、坏表格解析或坏中间数值，可能跨过多个 agent 边界后才影响答案。最终准确率无法告诉我们系统是忽略了扰动、静默吸收了扰动、绕路恢复了，还是花了大量 token 之后失败。

方法拆解：

1. 作者在带文件附件的 GAIA 任务上固定一个多智能体 workflow，包括抽取、分析、代码生成、验证和协调角色。
2. 扰动作用在 agent 实际消费的 artifact-derived representation 上，而不是原始文件上，比如已解析文本、表格、图像或音频表示。
3. 每次运行都记录路由决策、工具调用、memory 操作、agent 输出和最终结果，形成结构化 execution trace。
4. clean 和 perturbed run 通过 structural signature 和 normalized edit distance 比较，并用 first divergence point 定位 cascade 起点。

关键证据：实验覆盖 32 个 GAIA 任务、614 对 clean/perturbed runs、3 个 LLM backend。最重要的结果是 trace 行为和最终结果解耦。论文报告 15.3% 是 silent semantic corruption：trace 结构相似但最终结果改变；40.3% 是 behavioral detours with recovery：执行路径变了但最终结果一致；39.9% 是结构和结果都被破坏。divergent runs 中，80.6% 出现 rerouting，37.4% 出现 extended execution，25.3% early termination。成本也不是可靠信号：overhead 超过 2x 的高成本 run 里只有 16.3% 成功，而 overhead 低于 1.2x 的低成本 run 中 76.2% 是错的。

我的判断：这是本周更有用的 agent evaluation 论文之一，因为它把失败讲得可定位，同时没有把所有 divergence 都当成坏事。绕路可能是健康恢复；trace 稳定也可能是静默错误。下一步我更想看它和自动 mitigation 连接起来，比如按污染类别触发重新抽取、按模态调用 validator、按 trace 信号分配验证预算。

对应主题：多智能体可靠性、文档智能、trace-native evaluation、可审计工作流。

reward-lens: A Mechanistic Interpretability Library for Reward Models

作者：Mohammed Suhail B. Nadaf。
机构：未注明。
日期/出处：2026 年 4 月 28 日，arXiv 预印本。
链接：arXiv | HTML

这张 dashboard 图展示了论文的基本对象：不是把中间状态投影到词表 logits，而是投影到 reward head 方向。这样就能看到 reward model 的 preference formation 如何随层数形成。它支撑的是观察性 claim，而不是因果 claim；真正的因果判断还要和 intervention 结果对比。

这张图是论文最重要的警告。在线性 attribution 中，late MLP 组件占主导；但在 Skywork helpfulness 的 activation patching 例子里，early-layer components 对 causal patching effect 更关键。换句话说，reward score 被线性归因到哪里，并不等于模型真正因果依赖哪里。对 alignment 来说，这个区别不是细节。

轨迹叠加图比较了 Skywork 和 ArmoRM 的 preference formation。不同 reward 架构可能在深度轨迹上有相似趋势，但承载它们的组件集合不同。这个图把机理分析和训练实践接在一起，不过作者也很谨慎：这些只是早期 empirical slices，不是 reward model 的普遍规律。

一句话核心 idea：reward-lens 把 reward model 的机理解释目标从 vocabulary unembedding 换成 reward head 向量 (w_r)，从而移植 lens、attribution、patching 和 concept analysis。

为什么重要：RLHF 系统依赖 reward model，但主流机理工具大多围绕生成式 LLM 设计。logit lens 关心中间状态通过 (W_U) 投影到哪些 token；reward model 结尾不是 (W_U)，而是一个标量 head。如果只检查 policy model，而不检查 reward model，我们就漏掉了塑造优化压力的那一部分。

方法拆解：

1. 论文从 reward head 方程开始：(r(x,y)=w_r^\top h_{\mathrm{final}}(x,y)+b_r)。向量 (w_r) 成为 lens、attribution、SAE feature alignment 和 concept analysis 的共同轴。
2. Reward Lens 把中间 residual stream 投影到 (w_r)，得到逐层 preference trajectory。
3. Component attribution 把 attention 和 MLP contribution 沿同一方向分解。
4. Activation patching 在 preferred 和 dispreferred completion 之间替换组件，再测 reward 的因果变化，而不是只相信观察性 attribution。

关键证据：论文在 Skywork-Reward-Llama-3.1-8B-v0.2 和 ArmoRM-Llama3-8B-v0.1 上评估，每个模型约 695 个 RewardBench preference pairs。Skywork 的 preference crystallization 比较晚且稳定，helpfulness、safety、correctness、verbosity 都在约 0.90 fractional depth；ArmoRM 更早且方差更大，比如 correctness 为 0.64 ± 0.34。最核心的结果是一个负结果：linear attribution 不能预测 causal patching effect。Skywork 的 mean Spearman correlation 是 -0.256，ArmoRM 是 -0.027。在 Skywork helpfulness 例子里，top attribution 是 late MLP，而 strongest patching effect 来自早期 MLP 和 attention components。

我的判断：这篇入选，是因为它符合“理论/机理论文也要展示公式和细节”的要求。公式很简单，但它改变了检查对象。论文最有价值的地方是明确区分 attribution 和 patching：前者适合探索，后者才支撑因果 claim。较弱的地方是 hacking/cascade probe 样本偏小，作者也承认那些结果更像方向性 triage。我会把 reward-lens 看成一个工具论文，它的真正价值取决于后续能否在更多 reward model 和更大 probe set 上复现。

对应主题：大模型机理、agentic training、reward model 审计、可解释性工具。

阅读优先级和下期问题

如果关心 data agent，我会先读 Web2BigTable；如果关心部署审计，我会先读 Trace-Level Contamination；如果关心 GUI agent 成本，我会先读 Step-level Optimization；如果关心训练信号本身，我会先读 reward-lens。

下期我想继续追的问题：

1. 共享 workboard 能不能处理跨 worker 证据冲突，而不只是并行填行？
2. GUI agent 的事件检测器能不能跨产品、跨慢服务、跨真实企业 UI 迁移？
3. trace divergence 能不能在最终答案检查前触发有针对性的验证策略？
4. reward model interpretability 能不能进入 RLHF 训练循环，成为实时报警，而不是事后 notebook？