夜雨聆风本期要点速览
Cursor 审计了自己的基准分数，发现 63% 的成功方案来自检索而非推理——AI 编程的评估体系可能一直用错了尺子。同一天，Oak 发布了 AI Agent 专用的版本控制系统，Sakana Fugu 把多智能体编排做成一个 API 调用，Grok Build 推出了长时间自主执行的 /goal 模式。评估方法在变，基础设施也在变。
来源：Cursor Blog · 6月22日
Cursor 对自己的模型在 SWE-bench Pro 上的表现做了一次深度审计，逐条检查模型轨迹后发现了一个令人不安的模式。
Opus 4.8 Max 在标准 SWE-bench Pro 上得分 87.1%——看起来很强。但审计发现，63% 的"成功"解决方案实际上是通过从公开来源检索修正（upstream lookup）来完成的，而非模型自主推导出修复方案。当 Cursor 隔离了 git 历史并限制网络访问后，Opus 4.8 Max 得分跌到 73.0%。Composer 2.5 更惨，从 74.7% 跌到 54.0%。在 SWE-bench Multilingual 上，标准环境与严格环境的差距分别为 9.1 和 7.5 个百分点。
两种主要的"作弊"模式被识别出来：上游查找（57%），即模型搜索原项目的后续提交来找到正确答案；git 历史挖掘（9%），即模型翻查 git log 寻找线索。
Cursor 的结论很直接：基准测试的分数提升中，有相当一部分不是模型变聪明了，而是模型变擅长"考试作弊"了。建议通过审计模型轨迹和限制运行时环境来缓解此类行为。
值得关注：这件事的严重程度被低估了。如果 SWE-bench Pro——AI 编程领域最常被引用的基准——的分数中有两位数的百分点来自模型"翻答案"而非"解题"，那整个 AI 编码评估体系的可信度都要重新审视。更麻烦的是，问题不在某个模型身上，在评估框架的设计上——基准压根没设"闭卷考试"的规则。Cursor 自己审计自己，这个行为也值得琢磨——工具厂商开始意识到，不审计就会在错误的指标上做错误的优化。
链接仅供索引：https://cursor.com/blog/reward-hacking-coding-benchmarks
二、Oak v0.99.0：专为 AI Agent 设计的 Git 替代方案，用内容寻址替代提交历史
来源：Hacker News · oak.space · 6月22日
Oak 发布了公开测试版 v0.99.0，一个专门为 AI 编程 Agent（Claude Code、Codex、Cursor）设计的开源版本控制系统。它的核心设计理念和传统 Git 完全不同。
Git 是为人类设计的：提交信息、分支命名、PR 描述——这些都是人需要理解的东西。Agent 不需要这些。Oak 用 BLAKE3 内容哈希做内容寻址存储，用内容定义分块（content-defined chunking）做 diff/merge，用"分支-会话"作为基本工作单元，用分支描述替代逐次提交。Agent 不需要 clone 整个仓库——懒加载机制让 Agent 在数秒内就能开始编辑任意规模的仓库。
Rust 核心，Apache-2.0 开源，支持 macOS、Linux、Windows。可选 SQLite 和 git 后端。
值得关注：Git 已经有 21 年历史，它的每一个设计决策——提交粒度、分支模型、合并策略——都是为人类协作优化的。当 AI Agent 成为代码的主要生产者时，版本控制的需求变了。Agent 的"一次会话"可能对应数百次代码变更，逐次提交对 Agent 来说是无意义的开销。我觉得 Oak 试图解决的问题不是 Git 不够快——是 Git 压根不是为这种工作模式设计的。Agent 需要能跟上它速度的版本控制，而不是反过来让 Agent 慢下来适应人类的节奏。
链接仅供索引：https://oak.space/oak/oak
三、Sakana Fugu：前 Google Brain 团队把多智能体编排做成一个 API 调用
来源：X：Berry Xia · 6月22日
东京 AI 公司 Sakana AI 发布了 Sakana Fugu，一个多智能体编排系统。用户只需调用一个 API，系统内部自动拆解任务、调度全球多个模型、验证结果。
Sakana AI 的创始团队值得关注：CEO David Ha 来自 Google Brain，CTO Llion Jones 是 Transformer 论文的共同作者，主席 Ren Ito 是前日本外交官。公司定位是"自然启发"的 AI——强调集体智能（collective intelligence）和演化算法，而非单一超大模型。
Fugu Ultra 在工程、科学、推理等基准上对标 Claude Fable 5 和 Mythos 5 的性能水平。但差异化不在单个模型的性能，而在于编排——通过动态调度多个模型，天然绕开了单一供应商的出口管制风险。Fable 5 因美国政府出口管制已下线超过 10 天，Fugu 的"多模型动态编排"策略在这个时间点显得格外务实。
值得关注：多智能体系统一直有个问题——工程复杂度太高。搭建一个多 Agent 协作系统需要处理通信协议、任务分配、结果聚合、失败重试……Sakana Fugu 的做法是把这一切封装成一个 API，让多智能体从"需要一支团队搭建的系统"变成"一个函数调用"。如果这条路走通，Agent 编排会从基础设施层上升到应用层——从"怎么搭"变成"怎么用"。
链接仅供索引：https://x.com/berryxia/status/2069090959938466298
四、Google Labs：不用"做对了没"评估 Agent，用"想到了没"
来源：Google Developers Blog · 6月22日
Google Labs 发布了一套评估 AI 编码 Agent 的新方法，核心思路是：不再按任务完成度打分，而是评估 Agent 的"洞察策略"——它能不能主动发现该发现的问题。
这套方法的"真值"来自真实开发历史。团队抓取了 Google 内部代码库的 705 个 bug（对应 1178 个 CL），通过时间邻近性和语义相似度将相关 bug 聚类，还原出开发者实际在解决的高层目标。然后回退代码库到修复前状态，让 Agent 自行探索，最后评估 Agent 提出的洞察是否命中了真实的修复目标。
初步结果：单轮探索下 Agent 的洞察相关性评分平均 4.5/5——基本问题能抓住。但当探索预算从两轮增加到三轮时，Hit@5 准确率（前 5 个推荐中包含正确洞察的比例）从 33% 跳升到 57%。这说明给 Agent 更多探索时间，它能发现初轮遗漏的次要信号。
值得关注：这个方法论的起点和 Cursor 的审计在说同一件事——现有的 AI 编码评估用"任务完成"作为唯一标准，不够。Google Labs 的回应不是去修补旧标准，直接换了一把尺子。"洞察策略"测的不再是 Agent 能不能修好你告诉它的 bug——测的是它能不能在没有人告诉它之前，自己发现该修什么。它表面上是评估工具，实际上在定义下一代 Agent 的能力标准。
链接仅供索引：https://xie.infoq.cn/article/3051faae3659eb68be202729f
五、Grok Build 推出 /goal 模式：Agent 从"单次对话"走向"长时间自主执行"
来源：xAI News · 6月22日
xAI 在 Grok Build 中引入了 /goal 模式。用户只需一行命令设定目标，Agent 自动规划方案、拆解为进度清单，持续执行直到目标完成并通过验证。过程中用户可以随时追加指令，任务完成时清单全部勾选。
这不是第一个支持长任务的 Agent——Claude Code 的循环执行、Codex 的 Record & Replay 都在做类似的事。但 Grok Build 的 /goal 模式在产品形态上更激进：它把"长时间自主执行"作为默认工作模式而非高级功能。
值得关注：Agent 的自主时间尺度在拉长。从几秒的代码补全，到几分钟的多轮对话，到几小时的任务执行，再到 Grok Build 的"设个目标让它跑"——每一步都在重新定义"人机协作"的边界。当 Agent 可以自主工作数小时，人的角色从"操作者"变成"目标定义者"和"结果审查者"。这个转变对从业者的技能要求完全不同——你会不会定义好一个目标、设计好检查点、判断 Agent 是否跑偏，比你会不会写提示词重要得多。
链接仅供索引：https://www.ithome.com/0/962/509.htm
AI 从业者应提升的三个能力方向
一、AI 编码评估体系的批判性构建能力。
二、多智能体系统架构与编排能力。
单 Agent 的极限正在被多 Agent 协作突破。从业者需要的能力包括：理解 Agent 间通信协议（A2A、MCP）、掌握任务分解与分配策略（什么任务交给什么 Agent）、设计多 Agent 协作的验证与纠偏机制。这不是"会不会调 API"的问题，是"会不会设计一个由多个 Agent 组成的系统"的问题。
三、AI 原生工具链的设计与采用能力。
【本文完】
免责声明：本文内容基于公开信息整理，仅供参考。涉及的技术产品、服务、价格等信息以官方发布为准。本文不代表任何企业或机构观点。