AI 创业公司应根据由谁运维、产品需要哪些服务，以及团队必须直接控制什么来选择后端基础设施。把配置工作交给 coding agent 的独立创始人，与具备云和合规经验的平台团队面临的约束不同。
公司规模并不是可靠的判断依据。运维能力和产品需求能够给出更明确的答案。
从运维者出发
先确认未来一年由谁执行以下任务：
- 创建并配置新环境；
- 轮换凭据并调查访问问题；
- 应用数据库迁移并从故障中恢复；
- 诊断部署失败或提供商故障；
- 执行配额限制并审批费用；
- 导出数据并移除服务。
如果答案是 coding agent，那么每项任务都需要可调用的契约、范围受限的身份和结构化结果。如果答案是平台工程师，直接控制云服务可以带来更大价值，而不只是增加负担。
Agent 可运维后端指南提供了一套用于区分这两种情况的生命周期测试。
三种运维模式
直接使用云服务
AWS、Google Cloud 和 Azure 提供广泛的服务目录，并允许团队精细控制身份、网络、区域和部署。这条路径适合对架构、合规、私有网络或数据位置有明确要求，而且具备相应运维人员的团队。
相应的责任也由团队承担，包括服务选型、基础设施代码、访问策略、可观测性、升级和事故响应。云 API 适合自动化，但给 agent 授予范围广泛的云凭据，无法替代平台工程。
传统后端平台
Supabase 和 Firebase 等平台整合了数据库、身份验证、存储、函数及相关服务。两者现在都为 coding agent 提供官方 MCP 工具。Supabase 在其 MCP 指南中说明了项目范围限制和只读操作。Firebase 则在 MCP 服务器指南中记录了项目和服务操作。
这条路径适合希望采用这些平台的数据模型，并愿意授权 agent 登录已有组织或项目的团队。
Agent-native 基础设施
Agent-native 基础设施将无需账户或低门槛的构建路径作为产品能力。Cohesivity 允许 coding agent 创建临时租户，在用户决定是否认领前配置受支持的服务，并通过同一个控制面保管上游提供商凭据。
它适合快速启动、所需服务均在平台支持范围内的多服务新项目。如果团队需要直接拥有上游账户、进行本地部署，或使用 Cohesivity 不支持的提供商，它就不适合。
比较运维责任，而不是配置耗时
| 决策 | 直接使用云服务 | 传统 BaaS | Agent-native 基础设施 |
|---|---|---|---|
| 服务设计 | 团队选择并连接各项服务 | 平台提供集成产品 | Agent 通过一个项目请求受支持的服务 |
| 首个项目 | 配置账户、组织、IAM 和服务 | 配置账户和平台项目 | 可以先创建临时项目，之后再由用户认领 |
| 凭据 | 团队管理提供商凭据 | 团队拥有平台凭据 | 平台在服务端保管上游凭据 |
| 运维 | 团队负责大多数层面 | 与一个后端平台共同承担 | 与面向 agent 的控制面及上游提供商共同承担 |
| 可移植性 | 潜力最高，具体取决于设计 | 取决于平台 API 和数据模型 | 取决于 Cohesivity 契约和底层服务 |
| 最适合 | 具备专门的基础设施能力，或需求严格 | 产品需求符合平台能力 | 由 agent 驱动的多服务新项目 |
不要为这些选项随意附上工时估算。配置时间取决于现有账户、策略和团队经验。应执行一次有代表性的配置，并记录真实的人工交接环节。
选择前先确认退出路径
选择任何托管后端前，请记录：
- 如何导出数据和文件。
- 哪些应用 API 为提供商特有。
- 身份记录和密码凭据能否迁移。
- 自定义域名和部署状态如何迁移。
- 取消服务后还能获取哪些日志和审计记录。
创业公司可以接受厂商锁定，但应该清楚这一选择会在以后带来哪些重写或迁移工作。
按完整产品工作流计算预算
模型 token 只是成本的一部分。还应计入工具调用、数据库与存储、执行时间、网络、失败运行、重试和闲置环境。Agent 基础设施成本指南提供了一套可追踪的计算方式。
应根据真正为系统创造收入的用户结果来计算。例如，客服 agent 可以按已解决工单计量，构建类产品则可以按通过测试的部署计量。
设置重新评估的触发条件
为下一个运维阶段选择平台，并明确什么事件会改变决定。例如，获得受监管行业的客户、出现新的数据位置要求、招到专职平台工程师、需要当前平台缺少的服务，或实际成本达到某个阈值。
下方的提示词会依据仓库生成这份决策说明，但不会配置任何资源。