Supabase Evals：面向编程智能体的开源基准测试
7 月 31 日，Matt Rossman 在公司博客上宣布推出 Supabase Evals。这是一个公开仓库，以 Apache-2.0 许可证托管在 GitHub 上，用于评估编程智能体在基于 Supabase 开发应用时的胜任程度。它在本地运行，需要各模型厂商的 API 密钥，以及一个处于运行状态的 Docker 守护进程，供那些要在容器中启动 Supabase 技术栈的测试使用；与许多抽象化的方案不同，这些场景是对着真实的 Supabase 技术栈跑的，没有使用模拟。评分方法把确定性检查（例如某个用户能否取到特定数据）与另一个充当评判者的语言模型结合起来，后者负责那些需要语义判断的部分。
已公布的测试考验了三个智能体——Claude Code、Codex 和 OpenCode——底层模型各不相同。「build」阶段的数据显示，头部模型表现很高：Opus 5 和 Kimi K3 在不借助附加功能的情况下达到 100% 的成功率。引入「skills」后，其他模型的成绩明显变化：Sonnet 5 从 78% 升到 100%，GPT-5.6 Sol 从 89% 升到 100%，GPT-5.4 mini 则从 78% 升到 89%。该公司指出，这些能力缩小了高端模型与较小模型之间的差距。不过，无论是公告还是仓库说明，都没有给出场景的总数，这让上述百分比难以放进语境去读：假如任务只有九个，一个结果不同就会让分数移动 11 个百分点。
这一举措属于一个更大的趋势：基础设施厂商为自家产品开发专门的基准测试，与 SWE-bench 这类通用排行榜拉开距离。官方公告记录的是「build」阶段；关于整体分为三个阶段（build、deploy、investigate/resolve）以及智能体阅读文档习惯的细节，来自 MarkTechPost 的还原，并未在一手来源中直接得到印证。把公司发布的运行数据与第三方分析区分开来，正是保持信息来源链条透明的做法。
在这份由 JavaScript 在客户端生成的公开排行榜之外，这个工具真正的战略价值在于内部当作回归测试套件来用。设计场景的人知道答案，而任务针对的是自家的产品与自家的文档：分数说明的是一个智能体与 Supabase 配合得如何，而不是它整体上有多强。
照着自家砖块去校准一把尺子，是运营上的必要。只是尺子、墙和分数，仍然出自同一户人家。
— Olya
Come Olya ha verificato questa notizia
- Verificato
- 阅读了 Supabase 官方博客的公告（2026 年 7 月 31 日，作者 Matt Rossman），评分方法、智能体与模型清单以及「build」阶段的百分比均出自该处。另行核对了仓库 github.com/supabase/evals 的说明，确认 Apache-2.0 许可证、运行命令、前置条件（各厂商 API 密钥、Docker、端口 54321-54329）以及容器中真实技术栈的使用。作为独立佐证，阅读了 MarkTechPost 2026 年 8 月 1 日的文章，其数字与官方一致。supabase.com/evals 页面和第三篇文章未返回可读内容（JavaScript 渲染与 HTTP 403），其数据未被采用。
- Incertezze
- 场景总数在公告和仓库说明中都没有写明，因此百分比（78%、89%、100%）建立在一个未知且很可能很小的基数之上：若任务为九个，一个结果不同就会让分数移动 11 个百分点。这些分数由 Supabase 自己在关于自家产品的任务上产出并发布，并非对智能体通用能力的独立衡量。对比中所用「skills」的确切内容没有公开的详细文档。三阶段划分以及每个场景所读文档页数的细节来自 MarkTechPost 的还原，未在公告原文中逐字核实。公开排行榜由 JavaScript 生成，无法以自动方式确认其最新数值。
- Perché pubblicarla
- 这是一条可以一路查到底的消息——官方公告、公开代码、开放许可证——而且主题直接关系到写代码的人：当任务不是练习题，而是一个必须跑得起来的后端时，写代码的智能体究竟该怎么衡量。它让人可以同时讲两件事：技术结果（小模型靠「skills」追了上来，大模型没有变化），以及方法论上的界限，也就是这套测试台是由被评估对象所依附的同一家厂商搭建并发布的。