一个不给人类做 Dashboard 的 BaaS，拿了 12K Star

去年 7 月，一个叫 InsForge 的项目在 GitHub 上线。一年后，12K Star。

它做的事不新鲜——BaaS（后端即服务），Supabase 的同行。Firebase 2009 年就开始了。

但它做了一个少见的决定：不给人类做 Dashboard。

● ● ●

Dashboard 是为谁设计的？

你用过 Supabase 吗？登录进去，左边一列菜单：Table Editor、SQL Editor、Authentication、Storage、Edge Functions……每个功能点进去是一个可视化界面。点点鼠标，建表、设权限、配 OAuth。

这套设计假设了一个前提：操作者是人类。

但 2026 年的编程正在变化。Claude Code、Codex、Hermes Agent——AI 编程工具在写代码、做 Code Review、提交 PR。它们能写前端，能写后端逻辑，能写 SQL。

然后呢？

然后卡在了「去 Dashboard 点几下」这一步。Agent 不会点鼠标。它只能告诉你：「请手动创建 users 表，然后运行以下迁移……」

像一个自动驾驶汽车开到了收费站，然后让你下车去窗口缴费。

● ● ●

Agent 的操作界面是文件

InsForge 的解法：把所有后端配置放进一个 TOML 文件。

[database]
  name = "my-app"
  extensions = ["pgvector", "pg_cron"]

[auth]
  providers = ["github", "google"]

[storage]
  buckets = ["avatars", "documents"]

[functions]
  "process-upload" = { runtime = "deno", path = "./functions/process-upload.ts" }

然后 Agent 就能操作了。读取文件 → 理解当前配置 → 编辑 → insforge config plan 预览变更 → insforge config apply 推到后端。

Agent 的操作界面是文件。Dashboard 对它来说是盲区。

这是 InsForge 最核心的设计决策。Dashboard 是文件的只读视图——反过来不行。你在 Dashboard 改的东西，Export 回 TOML 就行。

他们管这叫 Config as Code，今年 5 月上线。技术上不复杂，但设计哲学和 Supabase 完全不同。

● ● ●

后端也能分支

Git 让你分支代码。但数据库怎么办？dev 和 prod 两套库，改了 schema 发现不对，想回滚——通常就是手动重建。

InsForge 的方案：insforge branch create feature-x。

这行命令在 AWS 上启动一套独立的后端实例——独立 EC2、独立 Postgres、独立配置。Agent 在这个分支上改 schema、调 RLS 策略、加函数，改完 insforge branch merge feature-x。

合并策略挺细：

• 纯新增的表和函数 → 直接合
• 改了现有表 → 对比三份快照（分支创建时的父状态、当前父状态、分支当前状态）
• OAuth client_secret、API_KEY → 自动排除，不参与合并
• 用户数据 → 默认不合，只合 DDL

Agent 擅长迭代，但数据库 schema 变更一旦出错很难回滚。有了分支，Agent 能像操作代码一样操作后端——分支、改、测、合。

● ● ●

诊断闭环：Agent 自己修 Bug

第三个设计是诊断工具。

insforge diagnose 拉取三类信息：安全发现（RLS 策略检测）、数据库健康检查、错误日志。

加 --ai 参数，Agent 自己解释诊断结果。更关键的是，API 返回的错误里带了 nextAction 字段——不只是「出错了」，而是「下一步该干什么」。

比如 RLS 策略缺失，nextAction 提示：「需要为 posts 表添加 SELECT 策略。」Agent 看到这个，自己写 SQL、自己 apply。

三个组件构成闭环：Config as Code 让 Agent 能写配置 → 后端分支让它能安全测试 → 诊断闭环让它能自己修 Bug。

InsForge Agent 闭环

● ● ●

和 Supabase 比

比的不是谁更好，是给谁用。

12K Star vs 99K Star，差距很大。但差距不在技术——Supabase 的企业合规、扩展生态、社区文档是实打实的壁垒。InsForge 赢不了也不想赢这些。

如果未来三年越来越多的代码是 Agent 写的，后端基础设施长什么样？InsForge 给出的答案和 Supabase 不一样。

● ● ●

现在还太早

几个客观问题：

成立不到一年。2025 年 7 月上线，生产环境验证不足。

迁移工具匮乏。现有 Supabase 项目想迁过来？没工具。只适合 Greenfield 项目。

企业合规缺失。没 SOC 2，没 HIPAA，企业客户不用想。

部分闭源。Agent Finder 标注为 "Partially" 开源——Apache 2.0，但核心功能可能有保留。

还有一个微妙的问题：Agent 驱动的后端平台，人类怎么 Debug？

Agent 改了 TOML、开了分支、合了 schema——不熟悉 CLI 的团队成员根本看不见。Dashboard 有个好处：任何人都能点进去看一眼表结构、查一下数据。InsForge 的 Dashboard 是「只读视图」，干净，但也意味着排障门槛更高。

如果你的团队只有一个人用 AI Agent 开发，其他人还在传统方式，InsForge 得慎重。

● ● ●

信号

InsForge 不是要挑战 Supabase。它是第一个认真把 AI Agent 当作用户来设计的后端平台。

2010 年代，AWS 把服务器管理从「人登 SSH」变成「API 调用」。DevOps 工具链的默认假设从「人类操作 Dashboard」变成「脚本调 API」。

2026 年，AI Agent 正在成为新的「脚本」。但大部分后端基础设施还停在「Dashboard 给人类用，API 给脚本用」的阶段。Agent 卡在中间——它会用 API，但很多操作在 API 里表达起来很笨拙（Schema Diff 是典型）。

InsForge 的设计回答了这个问题：Agent 最好的操作界面是文件。 Config as Code 不只是功能，是一种 Agent 原生的交互范式。

Grafbase 的 CEO Fredrik Björk 最近在一个采访里说："AI agents will drive a fundamental shift from GUIs to configuration languages." 他觉得未来十年，Agent 驱动的软件开发会重塑界面设计——从可视化 GUI 走向可机器编辑的配置语言。

InsForge 是这个趋势的早期实践。它也许不会取代 Supabase，但方向是对的：工具要同时考虑人类和 Agent 两个用户。

资源：

• InsForge 官网: insforge.dev
• GitHub: github.com/InsForge/InsForge
• 文档: docs.insforge.dev
• Sealos 博客分析: sealos.io/blog/insforge
• Agent Finder 评测: agent-finder.dev