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

本栏目聚焦 AI / LLM / Agent / Harness，不收录纯图像、纯视频生成方向；世界模型与具身作为「智能体在物理世界的延伸」保留。本期时间窗为 7 月 25 日至 8 月 5 日。产品线没有新旗舰模型落窗——Claude Opus 5 差一天（7 月 24 日），Gemma 4 在 4 月，DeepSeek 仅更新了 V4-Flash-0731 checkpoint——故工业界只收两条最贴本栏目主题的动态：Google 把 Agent Skills（SKILL.md + 渐进披露）做进 Genkit Go（7-31），并上线多模型路由网关（8-4）。论文这批 v1 提交时间集中在 7 月 29 至 8 月 3 日（UTC）；7 月 24–28 一段本窗内未收，寻源覆盖有限。所选论文大致落在「自演化 / 记忆 / 失败诊断」几类（如 SkillRise、Metis、Model or Harness?、SWE-Touch），但这只是本期取样，不代表当周主线。

模型 & 产品

Agent Skills in Genkit Go（Google 把「技能」做进 agent 框架）

Google 于 7 月 31 日在其 AI 应用框架 Genkit 里加入 Agent Skills：把「专门知识」打包成可发现、按需加载的能力，agent 只在需要时才把它拉进上下文。已覆盖 TypeScript / Go / Dart / Python，这篇讲 Go。值得注意的是，它的抽象——SKILL.md 加渐进披露——和 Anthropic 在 Claude Code 里的 Agent Skills 高度同构，「技能作为模块化、按需披露的能力包」正在成为跨厂商的公共约定。

  • 机制：走「渐进披露」（progressive disclosure）三段式——Discovery（扫 SkillPaths 下的 SKILL.md，只把 frontmatter 元数据注入 system prompt）→ Activation（请求匹配某技能描述时调 use_skill 工具）→ Execution（把 SKILL.md 全文加捆绑资源加载进活动上下文）。一个技能就是一个目录：必需的 SKILL.md（frontmatter 元数据 + body 指令）加可选的 scripts / references / assets。好处是 token 效率（初始只加载元数据）、纯 markdown 像代码一样分发、可捆绑确定性脚本当「真相源」。
  • 生态：建在 Genkit 中间件架构上（WrapModel / WrapTool / WrapGenerate 三层 hook），靠监控 prompt、匹配描述来激活技能。
  • 接入：go get github.com/firebase/genkit/go，CLI 可选（curl -sL cli.genkit.dev | bash）；示例含一个 recipe CLI 与一个多模态「文艺复兴」修复 app（正确激活 paintings 技能修复 Ecce Homo）。
  • 局限：触发完全靠 frontmatter 描述写得好不好，写不到位就漏触发或误触发；渐进披露把复杂能力拆成多跳加载，调试与可观测性成本随之上升。

统一的 AI 模型路由 API（Google Cloud API Gateway）

8 月 4 日，Google Cloud API Gateway 新增模型路由能力（Public Preview）：一个 serverless 的 AI 流量入口，接收 OpenAI 兼容请求，转发到不同后端模型，开发者既不用写死 endpoint、也不用自己维护开源代理。定位是「把选模型的自由留给开发者」。

  • 机制：在 OpenAPI 3.x spec 里用新的 x-google-api-management 扩展定义路由规则；backend 把虚拟模型名映射到 Vertex 模型地址；router 指定 defaultModel 加覆盖规则（如默认走 Gemini、请求 Claude 时切过去）；路径（如 /v1/chat/gemini-claude）经 x-google-model-router 绑到 router；网关把 payload 转码成后端原生 schema 再转发。示例可路由到 Gemini / Claude / OpenAI OSS-GPT（均托管在 Vertex 上）。
  • 生态：可与 Gemini Enterprise Agent Platform 搭配——agent 出口先过 Agent Gateway 做安全治理，再交给 API Gateway 动态路由；也能单独用作限流与 token 计费。
  • 局限：一个 router 里所有 backend 必须同 host（如 aiplatform.googleapis.com），本质是「同 host 换模型 / 换路径」而非跨 host 路由；仍在 Public Preview。

论文精选

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

LLM / Agent

SkillRise — 跨任务「技能进化」的 agentic RL

  • https://arxiv.org/abs/2607.26784 ｜ 实用性 4 ／ 创新性 4
  • 16 位作者，Zhiyuan Yao 领衔；含 Yuxin Chen、Weiwen Liu、Yongliang Shen 等，cs.LG / cs.AI；7 月 29 日提交。

核心动机：LLM agent 经常面对一批「相关但独立」的任务，它们共享可复用的模式，但标准 agentic RL「把每个任务当成独立的 episode」，白白丢掉了这层共性。已有的技能学习要么反复刷单个任务，要么用多阶段管线把「抽取 / 检索 / 执行」耦在一起，难训难改。

横向对比：SkillRise 是一个统一的 RL 框架，把相关实例排成一条由易到难的序列，用同一个策略在两件事之间来回切换——解当前的题、和维护一份「不断进化的技能文档」交给下一个任务。信用分配是跨任务解耦的：解题用当前结果监督，文档维护用折扣后的下游结果监督。在 ALFWorld、WebShop、ScienceWorld 上，它拿到参评方法里最强的 Pass@1，比最强基线高 2.3 到 8.5 个百分点；还观察到「跨任务的测试时 scaling」——相关任务序列越长表现越好，哪怕每题只做一次；同时比多阶段管线降低了运行开销。

优点：把「相关任务共享模式」这层被 RL 丢掉的结构显式做进训练，而不是靠更长的单任务采样；「解题 + 维护技能文档」用一个策略统一起来，比多阶段管线干净；解耦的信用分配让「学会做题」和「学会攒经验」各自有明确的监督信号；2.3–8.5 个点的增益有实测、且跨三个经典 agent 环境。 缺点：只在三个受控的文本 agent 环境验证，向开放长程任务外推待证；技能文档的质量决定天花板，坏经验会顺着序列传递下去；「由易到难」的排序前提是任务间关系已知，真实任务流未必给得出；摘要未交代文档随序列增长后的膨胀与检索成本。

Metis — 把「记忆」做成一个基础模型

  • https://arxiv.org/abs/2607.26760 ｜ 实用性 4 ／ 创新性 4
  • 17 位作者，Zeyu Zhang 领衔；含 Zhiyu Li、Junchi Yan、Xu Chen、Tat-Seng Chua 等，cs.CL / cs.LG；7 月 29 日提交（46 页）。

核心动机：agent 的多数能力都已内化进基础模型，唯独记忆仍然是外挂的（外部向量库、检索式记忆）。作者点出「native memory 能力基本没人系统探索过」，目标是把记忆直接做进模型骨干。

横向对比：Metis 自称「首个 memory foundation model 原型」——给基础模型一个原生的记忆状态，历史信息被压进模型、再经「记忆注意力」检索。它用大规模、记忆专用的训练数据配多个优化目标，走 mid-training 学到这套能力；关键设计是在线记忆维护是 gradient-free 的，只需一次前向就能更新；推理时模型权重冻结，记忆状态经标准前向变换即可流动。作者开源了项目与模型 checkpoint。摘要给的是「extensive experiments」这类定性说法，未列具体分数。

优点：把「记忆」从外挂检索抬成模型的一等能力，方向上很有想象力，也契合本期「让 agent 记住经验」的主题；gradient-free、仅前向的在线更新，避免了持续微调的成本与灾难性遗忘顾虑；权重冻结、记忆态随前向流动，工程上好接；开源 checkpoint 便于复现。 缺点：摘要无任何 benchmark 数字，「原生记忆」相对成熟外置检索到底强在哪难独立核验；46 页的大工程，训练配方复杂、复现门槛高；gradient-free 前向更新的记忆容量、写入冲突与长期遗忘特性未量化；native memory 与外置记忆的边界、以及在多轮长程 agent 上的失败模式仍待验。

Harness / 工程实践

Model or Harness? — agent 失败到底该怪谁的分类法

核心动机：现有评测习惯把 agent 失败塌缩成一个系统级结果（成没成），把根因和「该怎么修」都藏了起来。作者把它提成一个**「修复归属问题」**（repair-assignment）：同一个可观测的失败，可能得靠模型后训练、harness 工程、环境重设计，或干脆是基准本身要修——取决于它的真实成因。而已有分类法都是 benchmark-specific、缺一套共享结构。

横向对比：他们提出一个以交互为中心的分类法，把失败定位到「它发生在哪一条交互上」并指名负责的组件。具体是把 41 种失败模式各自安到「两个组件之间的一条边」上，再配一个「fault side」标出修复该落在哪侧——从而把模型侧、harness 侧、环境 / grader 侧的故障区分开。这套 schema 意在跨架构泛化：从编码助手到长程个人助理再到多智能体系统。可复现性上，用独立的推理 agent 当 judge、跨四个前沿模型验证，最强 judge 对人类标注的 Cohen’s κ 达到 0.76，作者认为这说明类别「抓的是共享结构、而非标注者的个人偏好」。

优点：把「错误暴露点 ≠ 该修的地方」这一 agent 工程的核心痛点，直接框成可操作的「修复归属」，选题极贴工程现场；41 类落到「组件间的边 + fault side」，比一张扁平错误清单更能指导「谁去改」；显式区分模型 / harness / 环境三侧，正好回应本栏目关心的「harness 到底有没有责任」；κ=0.76 的可复现性验证让分类法不只是拍脑袋。 缺点：κ=0.76 距完美一致仍有距离，边界 case 的归属会有争议；可复现性依赖 agent judge，本身可能带模型偏差；41 类的划分是否穷尽、是否正交，摘要难判断，要看全文；这是一套「描述与定位」框架，本身不自动修复，落地价值取决于团队愿不愿按它分诊。

Deletion Avoidance — LLM 改代码时「不敢删」

  • https://arxiv.org/abs/2607.28887 ｜ 实用性 4 ／ 创新性 4
  • 「To Add Is Machine, To Delete Is Human」；Amir M. Ebrahimi 等 5 人，cs.SE / cs.AI / cs.LG；7 月 30 日提交。

核心动机：LLM 打的补丁能过测试，却常常损害可维护性。作者聚焦一个具体病症——「删除回避」（deletion avoidance）：该删的代码，模型系统性地留着不删。

横向对比：他们在 SWE-bench Verified 上评前沿模型，把其中 34 个 Verified 任务改造成「目标代码若还在就 fail」的测试；又新建一个基准 CanItDelete（200 个从真实 commit 挖来、整个所需编辑就是「删」的任务）；再对 GPT-5.6 Sol 做四段累加的 prompt 消融，外加一个后训练修复的 pilot。数字很扎实：即便是五个模型都能解出的任务，对开发者补丁的删除召回最高也只有 71.7%；模型能为 超过 92% 的所需删除定位到正确文件，却只在不到 52% 的情况下删对了确切的行；29.0% 的通过补丁用了「Guard-and-Go」模式（包一层 guard / fallback 而不是删掉）；在改造后的测试上，四个前沿模型从 63.2% 掉到 41.9%；CanItDelete 上最好的模型仍约 1/5 失败、较小的开源模型掉到 18.0%。就算把确切该删的行喂给它，prompt 消融也只把成功率抬到 80.5%。

优点：命名并量化了一个真实、普遍、却少被单独测的失败模式，对天天用 agent 改代码的人极有共鸣；「定位对文件 92% 但删对行 <52%」这组对照，干净地说明问题出在「敢不敢删」而非「找不找得到」；CanItDelete 加改造测试，把「过测试」与「真删干净」解耦；「Guard-and-Go」这个观察本身就是可复用的 code review 信号。 缺点：即便供确切行，成功率也只到 80.5%（模型转而删过头、或改成加代码），说明缓解还没到位；后训练修复只是 pilot，作者把行为定性为「欠训练而非做不到」，偏初步结论；基准聚焦「以删除为主」的编辑，日常混合型编辑里这一效应占比多大未直接给；主要在 SWE-bench 谱系上测，别的代码域的普适性待验。

Frontis-MA1 — 在 ML 工程里做递归自改进

核心动机：递归自改进（RSI）要的是「能改进『造 AI 这件事本身』」的系统，作者称之为 AI4AI。他们主张把机器学习工程（MLE）当作研究 RSI 的落地测试床——因为它可执行、反馈可验证。

横向对比：作者放出 OpenMLE 这套开源全栈系统——带执行反馈的任务环境（OpenMLE-Gym）、算子学习（OpenMLE-RL）、长程搜索（OpenMLE-Evo）。在其上后训练一个 35B 的 meta-evolution agent，用四个原子的程序进化算子（Draft / Improve / Debug / Crossover），先 SFT 再 RL，最后组进一个「学习与进化耦合」的搜索循环。数字：在 MLE-Bench Lite（每任务 12 小时、单张 RTX 4090 限 12GB 显存）上，Medal Average 从基座的 39.39% 提到 60.61%（OpenMLE-Evo），OpenMLE-Evo-Max 进一步到 71.21%，作者称「超过 GPT-5.5 + Codex、逼近 GPT-5.6 Sol 与 2.8T 的 Kimi K3」；在留出的 NatureBench Lite 上两个组件都可迁移：换上训练后模型 Match-SOTA 从 50% 升到 70%，换上 OpenMLE-Evo 从 20% 升到 50%。权重与全栈开源。

优点：把飘忽的「递归自改进」落到 MLE 这个有可验证反馈的具体域，比空谈 RSI 务实得多；四个原子算子 + 搜索循环的拆法清晰，且 SFT+RL 后再组合，训练路径可复现；在受限算力（单张 4090、12 小时）下报数，成本设定诚实；权重与全栈开源，社区能直接接着做。 缺点：「逼近」闭源大模型与 Kimi K3 仍是逼近而非超越，35B 靠搜索循环追平的代价要看全文；全栈搜索的算力与时间成本本身不低，Evo-Max 的开销未细拆；MLE 作为 RSI 测试床，能否外推到更开放的「改进 AI 本身」仍是开放问题；RSI 最要命的收敛性与安全性，摘要未交代。

Eval / 评测

SWE-Touch — 用户会中途改你的代码，编码 agent 还稳吗

核心动机：真实软件开发多发生在共享工作区里——agent 干活的同时，用户可能在查看、甚至直接改代码。但现有仓库级基准大多假设 agent 独自工作，或把用户参与限制成「发消息」，测不出 agent 对「工作区正在被别人改」这件事的感知与适应。

横向对比：SWE-Touch 用验证过的 Counter-Edits（对任务相关代码做的、与完成任务相冲突的合理编辑）来做压力测试：先从多条修复轨迹里挖出任务关键代码区，用一个专门的 User Patch Generator 造出这些编辑，在 agent 走到相关代码时、连同上下文用户消息一起注入。九个编码模型在 SWE-bench Verified，外加 SWE-Bench Pro、DeepSWE 的长程任务上评测。结果：Counter-Edits 让 SWE-bench Verified 的平均解决率降 7.7 个百分点，且这种退化在两个长程基准上持续存在。轨迹分析把失败归因于「对变化中工作区的弱感知」——agent 要么留着冲突的代码、要么不复查仓库就直接覆盖。结论一句话：强自主表现，并不等于共享工作区所需的状态感知。

优点：把评测从「agent 独自闭门解题」推向「有人同时在改」的真实协作面，选题贴近实际研发；Counter-Edits 从真实修复轨迹里挖关键区再造冲突，比随机扰动更有针对性；同时覆盖短程与两个长程基准，退化的一致性更有说服力；轨迹级归因（留冲突 / 盲覆盖）给出了可改进的具体方向。 缺点：Counter-Edits 由生成器造，其真实性与多样性直接决定基准质量；只测「注入式冲突编辑」这一种协作扰动，真实协作里的编辑形态更宽；7.7 个百分点是平均降幅，跨模型的分布与最坏情况要看全文；对「怎么修」只给了能力清单（检测变更、调和冲突、验证受影响行为），尚无解法。

ScrambleToolBench — 给了地图，agent 却还在盲目穷举

  • https://arxiv.org/abs/2608.02358 ｜ 实用性 4 ／ 创新性 4
  • 5 位作者，Vernon Toh、Navonil Majumder、Nancy F. Chen、Soujanya Poria 等，cs.CL；8 月 3 日提交。

核心动机：自主 agent 理应能纯靠交互搞懂一个陌生系统的运作方式，哪怕没有文档。但作者认为现有工具使用基准都不够——它们「暴露语义化的工具 schema、且环境是静态的」，于是 agent 靠的是先验知识，而非真正的探索发现。

横向对比：ScrambleToolBench 是个交互式终端基准，专门隔离出「行为推理」这一能力：剥掉语义线索、强制一个「连续任务课程」，逼 agent 必须靠试错去学工具行为；再加动态难度——mapping drift（映射漂移）、随机动作失败、限时执行窗——来考「环境在变时 agent 会不会修正假设」。核心发现（定性、未给分数）颇扎心：初期发现成功并不迁移成稳健适应；一旦出现结构性变化（如 mapping drift），agent 会跳过 cycle tracing 这类演绎手段，表现出**「信念惯性」或退回穷举搜索**；更要命的是，给更多测试时推理只会放大这种昂贵的暴力搜索，而非带来演绎式的恢复；持久记忆能限制误差累积，却解决不了高效的结构推断。

优点：把「真发现 vs 靠先验」这条缝隙隔离出来，直击当前工具使用评测「泄题」的通病；mapping drift + 随机失败 + 限时窗的动态设定，专门考「环境变了会不会改主意」，比静态工具集更难也更真实；「更多推理反而放大暴力搜索」是个反直觉且有工程价值的发现，提醒别指望 test-time scaling 包治百病。 缺点：摘要只给定性结论、无模型分数与难度分布，区分度要看全文；「行为推理」的隔离设定较受控，向真实带文档系统的外推需谨慎；结论主要呈现为「当前 agent 的缺口」，对基准自身的稳健性与可复现性着墨少；「持久记忆有帮助但不够」这类判断的边界条件未展开。

AgentStream — 自演化 agent 扔进「任务流」还灵不灵

核心动机：自演化 agent 号称能从积累的经验里持续变强，但多数研究都用「独立评测」——每个任务单独考。于是 agent 在真实流式设定（任务一个接一个、领域来回切）下的行为「其实还没被搞清楚」。

横向对比：AgentStream 是个统一评测框架，覆盖多种「进化组件」的自演化 agent：把已有的 agent 基准重组成一条可配置的任务流，定义三种测试时场景——Isolated（孤立）、Sequential（顺序）、Interleaved（交错），逐步改变流的范围与领域组成。作者组合评测了 5 种自演化方法 × 3 个前沿基础模型，把「模型能力 / 方法架构 / 流式场景」三者的影响拆开看。主要发现（未给具体分数）：自演化的可靠性随场景大幅波动；它的收益被模型能力「门控」、且随模型变强呈非单调；没有哪一种方法能在所有模型和场景上通吃。结论是一句方法论主张：自演化 agent 该在真实任务流下评，而不是孤立单任务。

优点：把「自演化到底靠不靠谱」放到贴近真实的流式设定里考，戳中当前评测的盲区；三场景（孤立 / 顺序 / 交错）逐级加压，能分离「场景」这个变量；5 方法 × 3 模型的因子化设计，让「是模型强还是方法强」可归因；「收益随模型变强非单调」是个有价值的反直觉信号。 缺点：摘要无具体分数，结论偏定性与方法论主张；把已有基准重组成流，流的真实性与代表性会左右结论；只覆盖 5 方法 × 3 模型的组合，规模仍有限；「非单调」等发现的成因（是方法与强模型不匹配，还是评测噪声）未深挖。

世界模型与具身

StatePlay — 让游戏世界模型「记住规则」，而非只画得像

  • https://arxiv.org/abs/2607.26754 ｜ 实用性 3 ／ 创新性 4
  • 5 位作者，Zijun Lin、Zeqing Wang、Cheston Tan、Bihan Wen、Yeying Jin，cs.CV；7 月 29 日提交。

核心动机：现有游戏世界模型能生成逼真、可交互的画面，却忽略了「游戏是由显式机制支配的」——血量、技能、终止条件这类状态相关的规则。不建模内部状态，模型就会产出「看着可信、却违反游戏规则」的 rollout。落点在「交互式世界环境」的规则一致性，故收入本线。

横向对比：StatePlay 让模型联合预测视觉内容与游戏状态，以支持「机制一致」的生成。架构用 MoT（mixture-of-transformers）风格：视觉分支与状态分支各自保留表征、又能跨模态交互，让预测出的状态去引导帧的生成；每个分支用各自合适的目标训练。数字上，状态预测的平均归一化 L1 距离 低于 0.06；相比不显式建模状态的模型，生成 rollout 的机制保真度提升 18.6%。

优点：把「世界模型要不要懂规则」这个常被忽视的维度显式做进来，切中「画面可信但规则错」的老问题；视觉与状态双分支、又跨模态交互的 MoT 设计，职责清晰、可扩展；给了状态预测精度（L1<0.06）与机制保真度（+18.6%）两个硬指标，不只是定性；「状态引导帧生成」是让世界模型可交互、可玩的务实一步。 缺点：只在「有明确规则」的游戏域验证，向开放世界或规则隐式的场景外推未知；方法要求状态可枚举、可标注，复杂游戏的状态空间难穷尽；长程 rollout 下机制会不会漂移、因果是否一致，摘要未量化；+18.6% 相对提升的绝对基线水平如何，需看全文对比。