在 AI 代码助手与 Coding Agents 快速普及的背景下，如何为这些智能代理提供一个可理解、可操作的 backend 语义层，成为工程实践中的新挑战。InsForge 是一个开源的 PostgreSQL 驱动后端平台，GitHub 星标数超过 8.3k，它将身份认证、数据库、存储、边缘函数、AI 网关等能力统一封装，为 AI Agents 构建了一个可推理的后端抽象层。本文聚焦其 AI Gateway 后端架构，探讨多租户隔离、统一认证与推理路由的工程化实现路径。
统一后端架构的设计动机
传统 Web 应用的后端设计通常以人类用户为中心，侧重于 RESTful API 的易用性和会话管理。然而，Coding Agents 的工作模式截然不同：它们需要理解后端提供哪些能力、如何调用这些能力、以及如何检查操作结果。这意味着后端必须暴露结构化的语义信息，而非仅提供黑盒 API。
InsForge 的设计理念是 “以 PostgreSQL 为单一数据源”，通过 PostgREST 自动从数据库 schema 生成 RESTful API，同时利用 PostgreSQL 的行级安全策略（Row-Level Security, RLS）实现租户隔离。平台的七大核心产品 ——Authentication、Database、Storage、Model Gateway、Edge Functions、Compute、Site Deployment—— 均围绕这一统一后端展开。对于 AI Gateway 而言，这意味着认证信息、模型配置、使用量统计全部存储在同一 PostgreSQL 数据库中，由同一套权限体系保护。
多租户隔离的数据库层实现
InsForge 的多租户架构建立在 PostgreSQL 的 schema 机制之上。每个项目（Project）对应一个独立的数据库 schema，项目内的所有表默认归属于该 schema。API 层通过 PostgREST 从 public schema 暴露数据，而真正的租户数据隔离由两套机制共同保障。
第一层是 PostgreSQL 角色（Roles）隔离。每个项目拥有独立的服务角色，PostgREST 使用该角色执行查询，确保不同项目之间无法跨 schema 访问数据。第二层是行级安全策略（RLS）。即使在同一 schema 内，RLS 策略可以根据当前用户的上下文过滤行数据，这对于共享 schema 的多租户场景尤为重要。InsForge 官方文档建议，对安全性要求较高的场景应使用独立 schema 加独立角色的组合，而对成本敏感的场景可采用共享 schema 加 RLS 的方案。
这种设计的工程优势在于：数据库既是存储层，也是权限控制层，无需在应用层额外实现租户过滤逻辑。对于 AI Gateway 而言，模型配置表（_ai_configs）和使用量统计表（_ai_usage）均遵循相同的隔离原则，确保不同项目的 AI 配置互不可见。
统一认证与 JWT 令牌体系
InsForge 的认证层采用 JWT（JSON Web Token）标准，支持 GitHub OAuth 和 Google OAuth 两种社会化登录方式。所有 AI Gateway 的请求必须携带有效的 JWT 令牌，后端在转发请求至 OpenRouter 之前完成令牌验证。
认证流程的核心步骤如下：客户端首先通过 OAuth 完成登录，获取 JWT 访问令牌；后续请求在 Authorization 头部携带该令牌；后端验证令牌签名与有效期后，从令牌中提取项目 ID（project_id）和用户角色（role）；AI Gateway 根据项目 ID 加载对应的 AI 配置，包括系统提示词（system_prompt）和默认模型。整个流程无需维护服务端会话状态，完全依赖令牌的自包含特性，适合分布式部署场景。
对于自托管部署场景，环境变量JWT_SECRET用于签名验证，生产环境建议使用足够长的随机字符串并定期轮换。OAuth 回调 URL 需要在各 OAuth 服务商处提前配置，本地开发默认使用http://localhost:7131/api/auth/callback/github等路径。
AI Gateway 的请求处理流程
InsForge 的 AI Gateway 不直接调用各个 LLM 提供商的原生 API，而是通过 OpenRouter 实现统一接入。这一选择带来三个关键工程收益：单一 API 接口访问 100 + 模型、统一计费与账单、內建自动故障转移与速率限制。
请求处理分为七个阶段。认证阶段验证 JWT 令牌并提取项目上下文；配置阶段从_ai_configs表加载该项目指定的 AI 配置；系统提示词注入阶段将配置中的 system_prompt 前置到消息列表；模型选择阶段确定实际使用的模型标识符（格式为provider/model，如anthropic/claude-sonnet-4.6）；转发阶段将构造好的请求发送至 OpenRouter；响应阶段处理流式输出（Server-Sent Events）或批量响应；最后的使用量记录阶段将 token 消耗写入_ai_usage表。
核心配置表结构如下：_ai_configs存储模型 ID、系统提示词、创建时间等配置信息；_ai_usage记录每次请求的输入 token 数、输出 token 数、图像生成数等指标，并通过 config_id 外键关联到具体配置。这种设计使得管理员可以按项目、按模型维度统计 AI 使用量，为成本分摊提供数据支撑。
推理路由与模型选择策略
InsForge 支持的模型覆盖主流提供商：OpenAI 的 GPT-5 系列、Anthropic 的 Claude 系列、Google 的 Gemini 系列、X-AI 的 Grok 系列、DeepSeek 系列、以及国内的 MiniMax 和 Kimi 等。路由的核心逻辑是 “配置驱动”—— 项目管理员可以在控制台为每个项目设置默认模型，也可以在 SDK 调用时显式指定模型。
对于需要动态路由的场景，InsForge 支持两种模式。一种是按需指定模式：调用方在请求中传递model参数，格式为provider/model，Gateway 直接转发至 OpenRouter 对应的模型端点。另一种是 fallback 模式：OpenRouter 本身支持在主模型不可用时自动切换至备用模型，这层保障对生产环境的稳定性至关重要。
工程实践中建议的模型选择策略包括：为日常代码补全任务配置响应快速的模型（如openai/gpt-4o-mini或anthropic/claude-haiku）；为复杂代码审查和重构任务配置能力更强的模型（如anthropic/claude-opus-4.5）；在控制台设置每项目的月度 token 限额，结合_ai_usage表的使用量监控实现成本可控。
BYOK 与凭证管理
AI Gateway 支持三种 OpenRouter API Key 来源，按优先级依次为：开发者自行配置的 BYOK（Bring Your Own Key）密钥、InsForge 云端托管的密钥、环境变量OPENROUTER_API_KEY。第一优先级用于让开发者使用自己的 OpenRouter 账户进行计费，后两者适用于自托管或云托管的默认场景。
BYOK 密钥在存储前经过 OpenRouter 验证有效性，并以加密形式存入数据库。管理员可以从控制台的 AI 页面管理这些凭证 —— 设置新密钥、轮换现有密钥、或删除密钥使其回退至下一优先级。这一设计使得团队可以在同一 InsForge 实例中并存多个计费账户，例如研发团队使用企业 OpenRouter 账户、个人项目使用私有账户。
关键工程参数与监控建议
部署 InsForge 的 AI Gateway 时，以下参数值得关注。JWT 令牌有效期默认值为 24 小时，可在认证服务配置中调整；对于需要更短会话周期的场景建议缩短至 1-2 小时并配合刷新令牌机制。流式响应采用 Server-Sent Events（SSE）协议，需确保负载均衡器配置了适当的连接保持（keep-alive）超时，建议不低于 60 秒。速率限制方面，OpenRouter 的默认限制为每分钟 60 次请求，自托管场景可通过OPENROUTER_API_KEY对应的账户配额自行调整。
监控体系应重点关注三个指标：请求延迟（从 Gateway 收到请求到开始返回流式数据的首字节时间）、token 消耗速率（按项目维度聚合的每小时消耗量）、错误率（按错误类型分类的 4xx/5xx 占比）。InsForge 的_ai_usage表提供了原始数据，建议通过 PostgreSQL 的物化视图或外部 BI 工具构建使用量仪表盘，实现按项目、按模型、按时间的多维分析。
技术选型的适用边界
InsForge 的统一 PostgreSQL 后端架构适合以下场景：需要为多个 Coding Agents 提供统一后端能力的开发团队、对多租户数据隔离有明确需求的 SaaS 产品、需要快速验证 AI Agents 产品想法的早期项目。其优势在于开箱即用的认证、数据库、存储、AI 网关一体化体验，星标数和活跃的社区（GitHub 8.3k Stars，35 个 Release 版本）为后续维护提供了保障。
然而，这一架构也存在明确的适用边界。对于需要超低延迟的实时推理场景（如毫秒级代码补全），经过 Gateway 一层转发会带来额外延迟，建议评估直接调用提供商 API 的可行性。对于需要复杂工作流编排的企业级 AI 应用，InsForge 的边缘函数（Edge Functions）能力相对基础，可能需要引入专门的编排层。数据量极大的场景下，PostgreSQL 的单节点架构可能在写入吞吐量上遇到瓶颈，此时考虑 PostgreSQL 分布式方案（如 CockroachDB 或 YugabyteDB）或将使用量统计迁移至时序数据库是更务实的选择。
小结
InsForge 提供了一种面向 AI Coding Agents 的后端范式：以 PostgreSQL 为统一存储与权限控制核心，通过 OpenRouter 实现多模型统一接入，结合 JWT 认证与 schema 级别多租户隔离，构建了从身份验证到推理路由的完整链路。其工程价值在于将传统后端的复杂能力封装为 AI 可理解的语义层，让 Coding Agents 能够自主发现、可配置、可持续地与后端交互。对于希望构建 AI 原生开发平台的团队，InsForge 的架构思路值得借鉴，尤其是在多租户隔离、认证体系、模型路由这三个核心维度上，其工程实践提供了可直接参考的解决方案。
参考资料
- InsForge 官方文档：https://docs.insforge.dev/core-concepts/ai/architecture
- InsForge GitHub 仓库：https://github.com/InsForge/InsForge