本栏目为每期一版的 AIGC 学术界 / 工业界前沿摘要。选题以人工筛选为主，每篇的分析要点由自动化流程生成，可能存在偏差或不准确之处，仅供参考。

本栏目聚焦 AI / LLM / Agent / Harness，不收录纯图像、纯视频生成方向；世界模型与具身作为「智能体在物理世界的延伸」保留。本期时间窗为 7 月 22 日至 25 日，只有三天，故收得偏精：产品线落在窗内的一手前沿发布是 Anthropic 于 7 月 24 日推出的 Claude Opus 5；论文这批 UTC 提交时间集中在 7 月 22 晚至 23 日，折算到北京时间恰好落在上一期（收到 7 月 21 日提交）之后的空档。如果说前两期的主题是「把智能体运行时的每一环分别抠效率」，本期的共同点更靠上一层：把 agent / harness 本身当成一等构造物——去训练它（OpenForgeRL 在真实 harness 里端到端跑 RL）、去编程它（NOOA 把 agent 写成一个 Python 对象）、去自改进它（AREX 递归审计自己的答案）、去评测它（WorkBuddy、ICAE-Bench 直接考「agent 在真实 harness 上搭项目」）。Opus 5 官方主打的也正是长程自主 agent 与编码——工业界和学术界这一周都把重心压在「智能体作为工程对象」上。

模型 & 产品

Claude Opus 5（Anthropic Opus 档跨代旗舰）

Anthropic 于 7 月 24 日发布 Claude Opus 5，全平台即时上线，API 模型名 claude-opus-5。官方定位是「深思熟虑且主动」（thoughtful and proactive），核心卖点不是重新登顶，而是用一半的价格逼近上代最强 Fable 5 的智能——它成为 Claude Max 的默认模型、Claude Pro 上的最强选项。

  • 定位与能力：主打日常使用、agentic 编码、知识工作、科学研究，以及法律 / 金融 / 基因组学等专业工作流，官方反复强调它「会核验自己的产出、谨慎迭代」。
  • 性能（官方口径）：Frontier-Bench v0.1 上超过所有模型，称「以更低的单任务成本把 Opus 4.8 的表现翻了一倍多」；CursorBench 3.2 在 max effort 下逼近 Fable 5 峰值 0.5% 以内、成本减半；ARC-AGI 3 得分为次优模型的三倍；Zapier AutomationBench 在同等成本下通过率约为次优的 1.5 倍；OSWorld 2.0 以约三分之一的成本超过 Fable 5 最好成绩。生命科学上，有机化学 +10.2 分、蛋白质任务 +7.7 分（对比 Opus 4.8）。对齐上称整体错位行为得 2.3 分，为近期模型最低。
  • 接入与定价：$5/MTok 输入、$25/MTok 输出，与 Opus 4.8 持平；Fast 模式约 2.5× 默认速度、两倍基础价。同时放出两项 beta：对话中途切换工具、API 自动回退（被标记的请求默认回退到 Opus 4.8）。
  • 局限：官方自陈在网络安全任务与生物学研究上仍落后于 Mythos 5；在 OSS-Fuzz 上「发现漏洞」与 Mythos 5 相当，但「开发利用（exploit）明显更弱」；在长程、自主的生物学研究任务上仍有「重要局限」。把它理解成「Opus 档在成本/智能比上做了一次跨代跳，而非全维登顶」更准确。

论文精选

每篇附 arxiv / 项目链接，并给出「实用性 / 创新性」评分（满分 5）。本批预印本 UTC 提交时间集中在 7 月 22 晚至 23 日，部分定量结论以摘要口径为准，细节以全文为准。

LLM / Agent

AREX — 会「审自己」的递归自改进深度研究 agent

核心动机：深度研究要同时满足多条约束，作者点出一个「发现-验证不对称」（discovery–verification asymmetry）——找到答案很贵，但检查一个候选答案却可以拆成一条条按单个约束做的简单核对。既然验证比发现便宜，那与其一味搜得更久，不如让 agent 反复审自己的答案、哪条约束没满足就补做定向研究。

横向对比：AREX 是一族递归自改进（RSI）agent，在两个循环间交替——内层「研究循环」收集证据、搭出临时答案；外层「自改进循环」逐条约束地审计这份答案，标出未解决的主张，再发起针对性的补充研究。为支撑长程运行，它自己学了一个「自主上下文更新工具」，把交互历史压成一个保留「已验证证据 + 未决约束」的紧凑状态，且不依赖外部模型。训练走「agentic 中训练 + 长程 RL」，特别强化「拿到决定性证据 / 纠正错误研究方向」这些关键步。给出两个规格：稠密 4B 与 122B-A10B 的 MoE。在 BrowseComp、WideSearch、DeepSearchQA、HLE 等基准上评测，定性结论是「显著超过同规模基线，并与激活参数量大得多的模型保持竞争力」。

优点：把「验证比发现便宜」这条不对称性显式做成 agent 架构，比「搜索更久 / 加采样」更有结构；外层逐约束审计天然产出可解释的「哪条没满足」，而非黑箱重跑；自带上下文自更新工具、不挂外部压缩模型，是长程 agent 的干净解法；同一方法给出 4B 与 122B-A10B 两档，覆盖面宽。 缺点：摘要只给「substantially outperform / remains competitive」这类定性说法，无具体分数，增益幅度难独立核验；「自己审自己」存在自我确认偏差——审计器与研究器同源，系统性盲区不会被自己发现；递归自改进的轮数、成本与收敛性未在摘要交代；深度研究的正确性最终仍受检索证据质量制约。

Experience Distillation — 从 agent 经验里样本高效地学，而非重跑环境

核心动机：agent 在真实世界里学习很贵——跑一次长实验、收一轮人类反馈都是成本。上下文学习（ICL）样本效率高，但一旦交互历史滑出上下文窗口，好处就没了；而上下文蒸馏能把上下文信息压进权重，可「怎么把它和 agent 的历史轨迹结合、还保住样本效率」一直没人系统研究。

横向对比：作者把这个问题定义为「经验蒸馏」（Experience Distillation），给出一个「不需要在已收集经验之外再和环境交互」的实现。数字很硬：在 749 个精选软件工程任务与 6 个文字冒险游戏上，它在两个领域都保住了至少 64.8% 的 ICL 增益，而在同一批经验上直接做 SFT 只能追回 3.8%；对比经典 RL 基线，它用「trial-and-error 经验的 ICL + 经验蒸馏」在少至少 9.6× 的环境样本下追平表现。

优点：直接对上「环境交互太贵」这一 agent 落地的硬约束，且「不再额外交互」是极强的工程前提；64.8% vs SFT 3.8% 的对照非常干净地说明「不是数据的问题，是蒸馏方式的问题」；9.6× 样本效率对真实、昂贵的 agent 任务（跑实验、收人反馈）价值直接；同时覆盖 SWE 与文字游戏两域，泛化面较宽。 缺点：749 个 SWE 任务 + 6 个游戏仍是有限设定，向更开放的长程 agent 外推待验；「保住 64.8% ICL 增益」意味着仍丢掉三分之一，天花板受 ICL 本身能力限制；经验的质量决定蒸馏上限，坏经验会被固化进权重；与更强的 off-policy RL / 离线 RL 基线的完整对比在摘要里未展开。

Harness / 工程实践

NOOA — 把一个 agent 就写成一个 Python 对象

  • https://arxiv.org/abs/2607.20709 ｜ 实用性 4 ／ 创新性 3
  • NVIDIA-labs，15 位作者；含 Paul Furgale、Leon Derczynski、Gal Kaplun 等，cs.AI / cs.CL。

核心动机：常规的 agent 搭建被摊在 prompt 模板、工具 schema、回调代码、工作流图好几处，彼此割裂、难测难改。作者主张把这些统一起来：一个 agent 就是一个 Python 对象。

横向对比：NOOA（NVIDIA Object-Oriented Agents）是个模型无关的 Python 框架——对象的方法即可用动作、字段即状态、docstring 即 prompt、类型标注即契约；方法体写成 ... 的由运行时 LLM 循环补全，正常写了代码的方法保持确定性。这样 agent 行为就能像普通软件一样被测试、追踪、重构、改进。作者列出六个「模型可见」的设计首次被组合到同一个界面上：带类型的输入/输出、对活对象的引用传递、代码即动作、可编程的循环工程、显式对象状态、以及模型可调用的 harness API（拿上下文与事件）。在 SWE-bench Verified、Terminal-Bench 2.0、ARC-AGI-3 上做了评测（摘要未给分数），并演示当前模型能有效使用这套界面。

优点：用开发者最熟的抽象（类、方法、类型、docstring）承载 agent，学习与维护成本低，天然可单测、可版本控制；确定性方法与 LLM 补全方法混编，把「哪部分该稳、哪部分该由模型发挥」显式化，工程上很务实；把「模型可调用的 harness API」列为一等设计，正好呼应本期「harness 作为对象」的主题；作者也承认社区已在零散趋同于这些想法，定位诚实。 缺点：摘要在三个 benchmark 上都没给分数，「模型能有效使用」缺定量支撑；「docstring 即 prompt / 类型即契约」把提示工程绑死在代码注释里，复杂 prompt 的可维护性存疑；... 方法体在运行时被 LLM 填充，调试与可复现性可能变难；六个设计点更多是「整合已有实践」，创新性偏工程收敛而非新机理。

OpenForgeRL — 在真实 harness 里端到端训 agent

核心动机：现代 agent 依赖复杂的推理 harness（如 Claude Code、Codex）来做多轮推理与工具调用，但这让它们很难被端到端训练——现有开源 SFT/RL 栈「天生表达不了有状态、多进程的 harness 推理」。于是训练时用的往往是被简化过的环境，和部署时真正跑的 harness 对不上。

横向对比：OpenForgeRL 是个开源框架，用一个轻量代理（proxy）去承接 harness 发出的模型调用、同时把这些调用记录成训练数据，喂给标准 RL 代码库（如 veRL）；再用 Kubernetes 编排器把每条 rollout 跑在各自的远程容器里。训练与推理这么一解耦，研究者就能「直接在它部署时用的真实 harness 和环境里」训练。数字：只用几百到几千个任务，OpenForgeClaw 在 ClawEval 上拿到 31.7 pass^3、55.9 pass@3，QwenClawBench 33.7；OpenForgeGUI 在 OSWorld-Verified 37.7、Online-Mind2Web 63.0、WebVoyager 72.3。两者都在近乎所有基准上超过同规模开源基线，GUI 设定下还能追平甚至超过大几倍的模型。作者也分析了 harness 选择与 RL 的影响：有些 harness 更难学，RL 能提升可靠性（自我核验、工具覆盖、多步规划），但「错误恢复仍然薄弱」。

优点：直击「训练环境 ≠ 部署 harness」这个 agent RL 的结构性错位，让训练发生在真实 harness 上，迁移损耗小；proxy 记录调用 + 标准 RL 栈 + K8s 每 rollout 独立容器，是干净可复用的工程抽象；给出 ClawEval / OSWorld / WebVoyager 一整套实测，且只用几百到几千任务就见效，样本门槛低；对「哪种 harness 更难学、RL 到底改善了什么」的分析（错误恢复仍弱）诚实且有价值。 缺点：pass^3 / pass@3 这类指标绝对值仍不高（31.7 / 55.9），说明真实 harness 上的 agent 远未成熟；每条 rollout 起一个远程容器，规模化的算力与调度成本不低；「错误恢复薄弱」是作者自陈的短板，恰是长程 agent 最要命的一环；结论主要在开放权重与特定 harness 上得到，闭源 harness 能否照搬未知。

Eval / 评测

Tencent WorkBuddy Bench — 抗污染的多域编码 agent 基准

核心动机：编码 agent 的评测最怕数据污染。作者的做法不是靠「保密题目」，而是把抗污染建在构造方式上——任务不从公开 issue 文本里搬，而是从真实的 commit、PR、业务场景里逆向反推，再重写到「用原始来源做网络搜索也复原不出题面」的程度。因为整套数据集是开源放出的，抗污染就落在「这种构造 + 数据集版本化」上，而非保密。

横向对比：WorkBuddy Bench 是统一评测框架，横跨四个工作域——Code（仓库级工程）、Web（前端开发）、Office（办公/业务流程）、Security（红蓝对抗），每个子集有各自的验证方式。任务用统一的「任务目录」格式，在两套 agent harness（CodeBuddy Code 与 Claude Code）下按可复现协议运行；任务目录、环境镜像、评测 harness、测试与参考解全部开源，「端到端可复现、可直接审计」。它给出跨模型家族的 leaderboard，但因为每个子集用不同的打分工具，「分数不可跨子集比较」，并刻意不报全套平均分。

优点：把抗污染从「藏题」改成「改造真实工程产物 + 版本化」，方向比保密可持续得多；四域覆盖（尤其 Web/前端与 Security 红蓝对抗）比纯 SWE-bench 式仓库补丁更贴近真实工作面；显式在两套 harness 上跑，正好回应「换 harness 会不会换结论」的公平性顾虑；全量开源、可审计，起步成本低。 缺点：「不报全套平均分」虽然科学，但也让「谁更强」难以一句话总结，实用检索性打折；抗污染最终仍靠人工改写质量，规模化后一致性存疑；摘要与页面未给具体 leaderboard 数字，实际区分度要看全文；四域打分工具各异，横向解读需要读者理解每套指标含义。

ICAE-Bench — 把编码 agent 当「交互式项目搭建者」来评

核心动机：随着「vibe-coding」流行，大家期待 agent 从不完整的产品意图出发搭出能跑的软件，而不只是补全一段已完全指定的代码。但现有基准评的还是「静态、完全指定」的任务，跟这种转变对不上——真实场景里 agent 要做规划、澄清需求、用工具、调试、仓库级搭建。

横向对比：ICAE-Bench 在「交互式项目搭建」设定下评编码 agent：从一条模糊的产品需求起步，用一个自动化的 User Agent 模拟交互动态。三个关键设计：其一，每个任务把「模糊性」锚定在一个真实的开源仓库、且有可执行行为上，避免无约束的胡乱发挥；其二，交互通过 User Agent Data 落地——模拟用户只「揭示隐藏约束」，而不凭空发明新需求、也不泄漏实现痕迹；其三，评测用标准化黑盒测试 + 多维诊断，覆盖功能正确性、语义与 API 相似度、结构保真度、设计质量、交互质量。摘要未报具体分数。

优点：把评测对象从「补全代码」升级到「从模糊需求搭出项目」，紧扣真实的 agent 工作形态，选题有前瞻性；用「真实开源仓库 + 可执行行为」锚定模糊性，是个巧妙的约束——既保留开放性又可判分；User Agent「只揭示、不发明、不泄漏」的设定，抑制了模拟用户把答案喂出来的常见漏洞；五维诊断（含交互质量、设计质量）比单看通过率更贴近「好软件」的定义。 缺点：摘要无任何模型分数，基准的实际区分度与难度未知；核心依赖一个 automated User Agent，它的质量与偏差会直接决定评测可信度，却难以校准；「交互质量 / 设计质量」这类维度靠 LLM 判分，脆弱性与主观性风险高；锚定在既有开源仓库，可能限制任务的多样性与新颖度。

世界模型与具身

WorldWeaver — 用「跨 agent 世界状态寄存器」维持多智能体世界的一致性

核心动机：多智能体的交互式世界模型，既要生成一致的观测，又要维持一份持久的世界状态。问题在于：现有自回归管线把「观测历史」当作条件上下文往后传，这在多智能体、多视角设定下让「共享状态」很难维持——每个 agent 看到的只是自己那路观测，全局状态无处安放。落点在「交互式世界环境」，故收入本线。

横向对比：WorldWeaver（W²）是个流式的多智能体视频扩散模型，核心是跨 agent 世界状态寄存器——一组可学习的 token，用来存共享世界信息、跟踪每个 agent 的状态，并在每生成一个 chunk 后动态更新。这些寄存器由多种信号监督：单个 agent 状态、全局状态视图（含鸟瞰）、以及场景文本。架构上用 Mixture-of-Transformers，把「世界状态建模」与「视觉帧建模」的权重分开。实验在双人 Minecraft 视频生成上做，作者称显式的世界状态建模「提升了逻辑一致性与生成质量」。摘要未给具体数字。

优点：把「共享世界状态」从隐式的观测历史里抽出来、做成显式可更新的寄存器，切中多智能体世界模型的真痛点；寄存器用「单体状态 + 全局鸟瞰 + 场景文本」多信号监督，比单纯拼历史帧更结构化；Mixture-of-Transformers 分离世界状态与视觉帧建模，职责清晰、可扩展；落点在交互式环境而非纯生视频，符合「世界模型作为可交互环境」的方向。 缺点：摘要与页面都没有定量结果，「提升一致性与质量」缺硬指标支撑，难横比；只在双人 Minecraft 这一受控游戏环境验证，向更开放/更多 agent 的场景外推未知；流式扩散 + 多寄存器的推理时延与显存开销未交代；世界模型以视频为载体时，长程物理一致性与因果正确性仍是老大难，本文未量化。