夜雨聆风现在用 Claude Code、Cursor、Codex 这类工具做全栈项目，
前端页面通常很快就能跑起来。
卡住的地方经常在后端。
数据库要建表，登录要配置，文件要存储，函数要部署，
API 要接，权限还要处理。Agent 能写代码，但后端配置一多，
就很容易在文档、控制台和错误日志之间来回绕。
InsForge 做的就是这件事：
给 AI coding agent 一个更容易操作的后端平台。
它是什么
InsForge 是一个开源后端平台。
项目主要围绕 Postgres、Auth、Storage、Functions、Hosting、
AI Gateway 这些后端能力展开。
官方对它的描述很直接：
它是一个给 AI coding agents 和 AI code editors 使用的后端开发平台。
它把数据库、认证、存储、函数这些后端基础能力，包装成 Agent 能理解、
能配置、能检查状态的语义层。
换句话说，它想减少 Agent 做后端时的摸索成本。
后端为什么卡
AI 写前端时，反馈很快。
页面能不能跑，按钮有没有效果，样式是否对齐，浏览器里一眼就能看到。
后端麻烦很多。
比如做一个 CRM 小项目，Agent 不只要写页面，还要处理这些东西：
• 用户注册和登录 • 客户表、订单表、任务表 • 文件上传和读取 • 服务端函数 • AI 模型调用 • 部署和运行状态 • 日志和错误排查
这些能力单独看都不难。
但放到一个产品里，Agent 很容易在配置里迷路。
InsForge 的思路是把这些后端能力集中起来，
再通过 MCP 和结构化文档告诉 Agent：有哪些能力、怎么用、现在状态怎样。
这对 AI 辅助开发很关键。
因为 Agent 不只需要代码示例，还需要知道后端当前到底配置成什么样。
Agent 能看懂后端
InsForge 的核心设计是 semantic layer。
它夹在 AI coding agent 和后端基础能力之间。
Agent 可以通过它获取文档、查看可用操作、配置后端能力，
也可以检查数据库、日志和状态。
README 里提到三个动作：
• Fetch backend context • Configure primitives • Inspect backend state
这几个词听起来普通，但实际很有用。
以前 Agent 做后端，经常只能根据提示词猜。
现在它可以主动获取后端上下文，再决定下一步怎么改。
这也是 InsForge 和普通 BaaS 的差别。
它不是只给人类开发者一个控制台，
它还在考虑 Agent 怎么理解这个控制台。
覆盖哪些能力
InsForge 覆盖的后端能力比较完整。
官方 README 里列出的核心产品包括：
• Authentication：用户管理、认证和会话 • Database：Postgres 关系数据库 • Storage：S3 compatible 文件存储 • Model Gateway：OpenAI compatible 多模型网关 • Edge Functions：边缘函数 • Compute：长时间运行的容器服务，当前是 private preview • Site Deployment：站点构建和部署
官网也强调，它可以给每个项目提供 Postgres 数据库、云存储、
OAuth 登录、Functions、Realtime 等能力。
对独立开发者或者小团队来说，这类组合很省事。
你不需要把数据库、登录、文件存储、AI 网关拆到多个平台里处理。
Agent 可以围绕一个平台继续往下做。
官方基准数据
InsForge 官网放了一组 benchmark。
数据来自 MCPMark，测试 AI coding agents 在后端任务里的表现。
官网展示的结果是：
按官网说法，InsForge 在这个测试里是 1.6x faster，
Token 用量少 30%，准确率高 1.7x。
这个数据不要理解成所有项目都一定如此。
benchmark 只能说明在对应测试任务里，Agent 使用 InsForge 更顺。
但它至少说明一件事：
InsForge 的设计确实在围绕 Agent 的后端操作成本做优化。
本地怎么跑
InsForge 支持云端使用，也支持 Docker Compose 自托管。
本地启动命令很简单：
git clone https://github.com/insforge/insforge.git
cd insforge
cp .env.example .env
docker compose -f docker-compose.prod.yml up启动后访问：
http://localhost:7130接下来按照页面提示连接 InsForge MCP Server。
README 里也给了验证方式。
可以让你的 Agent 调用 fetch-docs 工具，确认它已经知道怎么使用 InsForge。
I'm using InsForge as my backend platform, call InsForge MCP's fetch-docs tool to learn about InsForge instructions.这个 prompt 是 README 里的验证示例。
多项目部署
InsForge 也考虑到了多项目运行。
如果一台机器上要跑多个项目，可以为不同项目准备不同 env 文件，
再改端口配置。
比如第二个项目可以改这些端口：
POSTGRES_PORT=5442
POSTGREST_PORT=5440
APP_PORT=7230
AUTH_PORT=7231
DENO_PORT=7233然后分别启动：
docker compose -f docker-compose.prod.yml --env-file .env.project1 -p project1 up -d
docker compose -f docker-compose.prod.yml --env-file .env.project2 -p project2 up -d每个项目会有独立的数据库、存储和配置。
这点对做多个原型项目的人比较有用。
和 Supabase 的区别
InsForge 很容易被理解成 Supabase 替代方案。
这个理解没问题，但还不够准确。
Supabase 面向的是开发者。
InsForge 更强调 AI coding agents 怎么操作后端。
如果你不用 AI Agent，Supabase 这类工具已经很成熟。
如果你希望 Claude Code、Cursor、Codex 这类工具直接参与后端搭建，
InsForge 的思路会更贴近这个场景。
适合谁
InsForge 比较适合这些人：
• 用 AI Agent 做全栈应用的独立开发者 • 想快速做 SaaS、CRM、AI 工具原型的小团队 • 已经在用 Claude Code、Cursor、Codex 的开发者 • 不想在数据库、Auth、Storage、Functions 之间来回配置的人 • 想研究 MCP + 后端平台怎么配合的人
它也不是所有场景都必须用。
如果你的后端系统已经很成熟，或者团队已经有固定的云服务和运维流程，
迁移到 InsForge 未必有必要。
如果只是做一个很简单的静态页面，也用不上这么多后端能力。
另外，虽然项目是 Apache-2.0，但真正商用前还是要看清楚托管版、
自托管版、第三方服务和模型调用成本。
总结
InsForge 解决的是一个很具体的问题：
AI Agent 写前端越来越顺，但后端配置仍然容易卡住。
它把 Postgres、Auth、Storage、Functions、Model Gateway 和部署能力放在一起，
再通过 MCP 和语义层让 Agent 更容易理解和操作。
这条路线挺有意思。
以前 BaaS 平台主要服务人类开发者。
现在 AI coding agent 也成了使用者，后端平台的设计方式就会跟着变化。
如果你正在用 Claude Code、Cursor、Codex 做全栈项目，
又经常被数据库、认证、存储、函数这些后端细节拖住，InsForge 值得试一下。
GitHub：https://github.com/InsForge/insforge
官网：https://insforge.dev