2026年7月，Supabase 做了一件事——它开源了一个叫 Evals 的评测框架。不是给自己的数据库测性能，而是给 Claude Code、Codex 和 OpenCode 这三个 AI 编程 Agent 打分。考的是真实任务：建一个数据库 schema、修一个挂掉的 Edge Function、改一条写错的 RLS 访问策略。
这件事放在半年前看，可能只是一个开发者工具公司的常规操作。但放在今天，放在 Supabase 刚刚宣布的几组数据里，它的含义完全不同。
一个被 AI Agent 改变的后端平台
2026年6月，Supabase 宣布完成 5 亿美元 F 轮融资，估值 105 亿美元。CEO Paul Copplestone 在公告中直接点明了一个关键事实：Claude Code 是今年年初以来 Supabase 最大的数据库创建来源。在 Supabase 平台上，数据库创建量同比增长了 600%，而其中超过 60% 的新数据库是由 AI 工具发起的——包括 Claude Code、Codex、Cursor、Bolt.new、Lovable 等。
这不是概念验证阶段的数字。这是发生在生产环境中的事实。Supabase 的用户量在八个月内翻了一倍，接近 1000 万开发者。而驱动这一增长的，不再是传统意义上用鼠标点开 Supabase 控制台的人类开发者，而是那些在终端里敲一行命令就开始自动部署后端的 AI Agent。
7月31日，Supabase 工程师 Matt Rossman 在官方博客中宣布开源 supabase/evals。他给出的理由非常直白：
“随着越来越多的人通过 Agent 而非手工方式将 Supabase 项目部署上线，我们想要一种方法来衡量这种体验，而不是靠猜测。”
这句话点出了整个行业正在经历的结构性转变。当 AI 编程 Agent 从“辅助写代码”进化到“自主部署项目”，后端平台发现自己成了 Agent 的“执行环境”。但问题随之而来：这些 Agent 写的代码到底好不好？它们能不能正确配置数据库权限？会不会在部署时炸掉一个 Edge Function？以前，这些问题的答案靠人类 Code Review 来回答。现在，人类根本来不及看。
评测的“考卷”长什么样
Supabase Evals 的考卷分为两个套件：Benchmark 和 Regression。前者覆盖 Supabase 用户真实旅程中的关键环节，追求广度；后者针对已知的失败模式做深度覆盖，Supabase 内部每天跑以监控回归。
每道考题都在真实的 Supabase 环境中执行——框架会拉起一个托管版 Supabase 栈和一个本地 CLI 项目，Agent 通过 MCP 服务器和 CLI 与系统交互。评分结合了确定性检查（比如某个用户是否能访问特定数据、Edge Function 是否返回预期结果）和 LLM-as-a-judge（需要语义判断的场景）。为了减少假阴性，Agent 在失败后有一次重试机会。
最意外的发现：Skill 没那么重要
最容易想到的结论是“加载了官方 Skill 的 Agent 表现碾压”。但 Supabase 的实测结果打脸了这种预期。
在 Build 阶段，搭载 Opus 5 和 Kimi K3 的 Agent 在不加载任何 Skill 的情况下就拿到了 100% 的分数。Skill 的加载确实缩小了差距——Sonnet 5 从 78% 升到 100%，GPT-5.6 Sol 从 89% 升到 100%，GPT-5.4 mini 从 78% 升到 89%——但这个差距远没有想象中大。
这意味着当前最先进的 AI 编程 Agent 已经足够了解 Supabase 的基本用法。官方 Skill 的真正价值不在“教它们怎么用”，而在“帮它们更新过时的知识”——比如当 Supabase 发布了新包 @supabase/server 时，Agent 的预训练知识还没更新，这时 Skill 的引导就变得至关重要。
Agent 的“死穴”在哪里
Supabase Evals 暴露了三个非常具体的 Agent 弱点。
第一，Agent 不习惯声明式工作流。 Supabase 的声明式 schema 本应让 Agent 用单个文件描述数据库结构，不再需要在多个迁移文件之间推理。但即使在已经使用声明式 schema 的项目中，Agent 仍然倾向于手动写迁移文件。这种“路径依赖”说明 Agent 更擅长模仿人类写过的代码模式，而不是主动选择最优的工作方式。
第二，新库的发现率极低。 Supabase 发布了 @supabase/server 来简化 Edge Function 的认证模板代码，但 Agent 仍然手写 supabase-js 做认证。这不是能力问题，是信息差问题——Agent 不知道有新包存在。
第三，文档阅读习惯差异巨大。 Codex 系的 Agent 每个场景平均读约 8 页文档，而 Claude Code 只读约 2 页。Claude Code 在加载了 Skill 的情况下，仍然有超过 60% 的场景没有查阅 Supabase 文档。这组数据揭示了一个容易被忽视的事实：不同 Agent 的“信息获取策略”完全不同，而这种差异直接影响了它们在真实任务上的表现。
从“卖水人”到“裁判”
Supabase 的估值从 2025 年 3 月的 20 亿美元飙升至 2026 年 6 月的 105 亿美元，15 个月内翻了超过 5 倍。它在 AI 编程浪潮中的定位非常清晰——不是做 AI 模型，不是做编程 Agent，而是做 AI Agent 的“后端基础设施”。
但 Evals 的推出意味着 Supabase 正在从“卖水人”升级为“裁判”。当 Claude Code 和 Codex 的用户都在用 Supabase 部署项目，谁来决定哪个 Agent 写出来的后端代码质量更高？Supabase 通过开源 Evals，实际上在定义“AI 编程 Agent 的 Supabase 能力”这一细分领域的评价标准。
这不是一个商业闭环，但它是一个标准制定权的争夺。在 AI 编程 Agent 的竞争格局日益白热化的今天——搭载 Claude Opus 4.8 的 Agent 在 SWE-bench Verified 上拿到 88.6%，搭载 GPT-5.5 的 Codex CLI 在 Terminal-Bench 2.1 以 83.1% 逼近——谁掌握了评测标准，谁就在事实上拥有了“什么样的代码算好代码”的话语权。
从 SWE-bench 到 Supabase Evals：评测正在“去学术化”
过去两年，AI 编程 Agent 的评测主要依赖 SWE-bench 这类学术基准。但 SWE-bench 的考题本质上是“修 Bug”，是设定好的独立问题。Supabase Evals 的不同之处在于，它考的是“完整建一个项目”——从建 schema 到写 Edge Function 再到配权限——更像一个真实开发者的工作流。
这种“从做题到做事”的评测升级，正在成为行业趋势。当 AI 编程 Agent 的能力已经足够完成独立任务，下一个问题就是：它们能不能在真实的生产环境中，端到端地交付一个可用的项目？Supabase Evals 给出的不是最终答案，但它提供了一个可复用的框架。而这，比任何一个具体的分数都更有价值。
谁会是赢家
对 Claude Code 和 Codex 这样的 Agent 来说，Supabase Evals 既是压力也是机会。压力在于，任何在 Benchmark 上暴露的弱点都会成为竞品营销的靶子。机会在于，这套开源框架让它们可以针对性地优化——比如让 Claude Code 多读文档，让 Codex 学会声明式 schema。
对 Supabase 来说，Evals 的战略价值远远超出“改善开发者体验”这个表面叙事。当越来越多的 AI Agent 以 Supabase 为后端创建项目，Supabase 事实上掌握了 Agent 质量的“验收标准”。这是一个平台型企业最舒服的位置——我在卖水，我也在定义水的质量标准。
对行业来说，Supabase Evals 的推出标志着 AI 编程 Agent 评测已经进入“真实任务时代”。下一个被开源评测的，可能是 AWS、Vercel、Cloudflare 的 AI 编程能力——每个平台都有可能推出自己的 Evals。而这场“评测大战”的真正赢家，不是分数最高的 Agent，而是那个定义了“什么叫做好”的平台。
当每个 AI 编程 Agent 都在争夺“最强”的称号时，真正握有话语权的，不是跑分最高的那个，而是设计考卷的那双手。
快报