一句话：InsForge 是开源的后端基础设施平台，专为 AI coding agent 设计；一条 prompt 就能让 Claude Code / Cursor 的 Agent 直连数据库、认证、存储、边缘函数、托管和 AI 网关。
写在前面
现在的 coding agent 已经能写前端、改逻辑、跑测试，但一到后端就卡壳：建表要你手动跑 migration、存文件要你开 S3、接登录要你配 OAuth、调模型要你写 gateway。
本质上不是 agent 不够强，而是
后端能力没有像代码一样变成可调用资源。
InsForge 的解法很直接：把后端原语全部包装成 agent 可读、可配置、可执行的后端上下文，让 coding agent 像 backend engineer 一样读 schema、跑 migration、部署函数、查日志。
一、它解决什么问题
| 维度 | 说明 |
|---|---|
| 核心问题 | coding agent 只能写代码，不能安全、结构化地操作真实后端 |
| 一句话卖点 | 给 agent 一个完整的 BaaS 后端平台，从数据库到 AI 网关全可调用 |
| 定位 | Agent-native backend platform for agentic coding |
| 协议 / 官网 | https://insforge.dev |
| 部署 | Docker Compose / Railway / Zeabur / Sealos |
| 生态 | MCP Server、CLI + Skills、TypeScript SDK、多框架模板 |
二、支持范围与能力边界
InsForge 不是一个“数据库客户端”，而是一个 完整后端底座：
- Authentication：用户管理、登录态、OAuth、session
- Database：PostgreSQL，支持 pgvector，可跑 migration
- Storage：S3 兼容文件存储，上传 / 管理 / 访问控制
- Edge Functions：边缘无服务器函数，可部署 agent 产物
- Model Gateway：OpenAI 兼容 API，多 LLM provider 统一入口
- Compute：长运行容器服务，当前 private preview
- Site Deployment：站点构建与托管
Agent 不是只能“看”这些能力，而是能 配置和操作：建表、加字段、配 auth provider、部署函数、拉日志。
三、Agent 交互方式
这是 InsForge 和传统 BaaS 最大的区别：
- MCP Server：自托管或云端都可暴露成 MCP tool，任何兼容 MCP 的 agent 直接调用
- CLI + Skills：云端模式下，agent 从终端直接调用 Skills 操作后端
- 读后端上下文：agent 能拉文档、schema、metadata、runtime logs，不用你再 paste
- 配置原语：agent 能直接做 migration、建 bucket、配 auth、部署函数
结果就是：agent 不只是“写代码”，而是能 端到端交付全栈应用。
四、与同类工具对比
| 维度 | InsForge | Supabase | Firebase | 自建后端 |
|---|---|---|---|---|
| Agent 原生 | MCP + CLI Skills | 有 SDK，非 agent 优先 | 有 SDK，非 agent 优先 | 自己封装 |
| 部署 | Docker / Railway / Zeabur / Sealos | 自有云 / Docker | Google 云 | 自运维 |
| 数据库 | Postgres + pgvector | Postgres | Firestore | 任意 |
| 边缘函数 | ✅ | Edge Functions | Cloud Functions | 视选型 |
| AI Gateway | ✅ 多 provider 统一 | ❌ | ❌ | 自己接 |
| 模板生态 | ✅ 全栈模板仓库 | ✅ | ✅ | 无 |
| 开源 | Apache 2.0 | Apache 2.0 | 专有 | 视项目 |
结论：如果你要的是 agent 直接操作的后端平台，InsForge 的 MCP-first 设计比 Supabase/Firebase 更贴近 coding agent 工作流；如果你要的是更成熟的开源 BaaS 生态，Supabase 更稳。
五、实战：3 步跑通
Step 1：本地启动
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
Step 2：接 MCP Server
按文档连接 InsForge MCP，在 agent 里发送：
I'm using InsForge as my backend platform, call InsForge MCP's fetch-docs tool to learn about InsForge instructions.
Step 3：多项目隔离
同一台机器可跑多个 InsForge 实例，各自独立数据库、存储、端口，用
--env-file + -p projectName 隔离。
六、风险与坑
- Compute 仍是 private preview：长运行容器服务还没 GA，重度后端任务要观望。
- 早期项目，commit 活跃但生态年轻：4,207 commits 说明开发快，但生产级稳定性需要时间验证。
- 自托管不轻：Docker Compose 能起，但 Postgres + PostgREST + Auth + Deno 全家桶对机器配置有要求。
- CLI + Skills 目前 cloud only：自托管主要走 MCP，云端才有完整 CLI Skills 体验。
- 模板库多但质量参差：
insforge-templates覆盖 admin / auth / CRM / e-commerce，适合脚手架，不适合直接当生产模板。
七、总结
InsForge 最值得装的理由有三：
- 把后端变成 agent 可操作资源：不只是 API，而是 schema / migration / logs / config 全可读可写
- MCP-first，不绑死某款 agent：Claude Code / Cursor / OpenClaw / LangGraph 都能接
- 从本地开发到云端部署一条线：Docker / Railway / Zeabur / Sealos，不用换架构
先试一周：用 MCP 接一个 InsForge 本地实例，让 coding agent 帮你建一张表、跑一次 migration、上传一个文件，再决定要不要把 compute 和托管也放进去。
参考
- GitHub：https://github.com/InsForge/InsForge
- 官网：https://insforge.dev
- 文档：https://docs.insforge.dev/introduction
- TypeScript SDK：https://github.com/InsForge/InsForge-sdk-js
- 模板仓库：https://github.com/InsForge/insforge-templates