从 AI Studio 到生产，真正让项目翻车的往往不是模型：Google 昨天列的三个“原型悬崖”很现实
Google Cloud 昨天发了一篇很接地气的文章，题目大意是：
AI 原型准备上生产前，
创业团队应该回答哪 10 个问题？
我觉得里面最有价值的不是那 10 个问题，而是开头列的三个“默认失败模式”：
1. API Key 泄漏，48 小时内跑出一大笔账单
2. 从 AI Studio 迁到企业平台时，因为没人负责 IAM，路线图卡住几周
3. 上线后开始 429，因为默认项目配额根本扛不住真实流量
这三个问题非常典型。
它们共同说明了一件事：
AI 原型到生产的最大断层，经常不是“模型效果”，而是身份、容量和治理。
很多团队原型阶段已经能做到：
Prompt 很好
模型效果不错
Demo 很惊艳
真正上线时却死在完全不同的地方。
AI Studio 的最大优点，也恰好是生产阶段的最大风险来源
原型工具的目标就是降低摩擦。
比如：
拿一把 API Key
几分钟开始调用
这非常好。
如果一开始就强迫团队先配置：
Cloud Project
IAM
Service Account
VPC
Quota
Billing
Logging
很多想法根本不会被验证。
问题是：
原型路径太顺
很容易让团队误以为：
这套身份方式也适合生产
于是 API Key 被继续放在：
- 前端代码；
.env；- CI；
- 开发机；
- Notebook；
- Slack；
- Agent 沙箱。
直到有一天泄漏。
API Key 最难治理的地方不是“字符串会被偷”
真正的问题是它通常缺少：
明确主体
用途
细粒度权限
短生命周期
一个 Key 被五个服务共用以后，日志里只知道：
key-123 调用了模型
却不知道：
哪个服务
哪个用户
哪个任务
为了什么
所以生产阶段应该尽量从：
Secret possession
升级到：
Identity based access
原型和生产不要强行统一身份方案
我反而赞成 Google 给出的思路：
原型先快
生产再迁
关键是：
迁移必须被明确计划
不要变成：
“先用 Key，后面有空再改。”
“后面”通常永远不会来。
可以在项目第一天就写：
prototype:
auth: api-key
allowed_environment: local-dev
production:
auth: service-identity
api-key: forbidden
这样技术债至少是显式的。
第二个“原型悬崖”：IAM 没 Owner
Google 提到，有团队从 AI Studio 迁移到企业 Agent 平台时，因为没人负责 IAM，项目会直接卡几周。
这个问题我非常熟悉它的组织形态。
研发说：
安全团队给权限。
安全团队说：
业务先说需要什么权限。
业务说：
我们也不知道 Agent 到底要什么。
最后所有人等。
所以 Agent 项目开始时，IAM 不能被当成上线前 Checklist。
它应该一开始就有 Owner。
我会给 Agent 项目明确三个身份负责人
Human Identity Owner
负责：
用户登录
角色
租户
人员变更
Agent Identity Owner
负责：
Agent Service Identity
Workload Identity
凭证签发
Capability Authorization Owner
负责：
哪些 Agent
能调用哪些 Tool
这三件事经常被一个“权限”概念混在一起。
实际上它们是三个系统。
第三个悬崖：429
Demo 阶段最容易产生一个错觉：
请求都很快
因为：
只有 1—3 个开发者
上线以后可能突然是：
5000 用户
定时任务
Agent Fan-out
Retry
然后第一天开始：
HTTP 429
这不是模型能力问题。
是容量模型没做。
AI 配额不能只按用户数估
传统 SaaS：
1000 用户
可能只有 50 并发
Agent 场景：
一个用户请求
→ 8 次模型调用
再加：
Sub-Agent
Judge
Embedding
Tool
所以容量应该从：
用户数
换成：
Workload Envelope
一个 Workload Envelope
workload:
peak_user_rps: 50
avg_model_calls_per_run: 6.8
p95_model_calls_per_run: 14
avg_input_tokens: 18000
avg_output_tokens: 3200
retry_ratio: 0.04
然后算：
Peak Model RPS
Peak Token/min
Concurrent Runs
而不是上线以后才看 429。
Google 还强调了一个差别：AI Studio 和企业平台不是“同一个东西换个入口”
Google 的说法很清楚：
AI Studio 更适合：
快速验证想法
API Key
低配置门槛
企业平台会多出：
IAM
Service Account
VPC Service Controls
Cloud Logging
Monitoring
Reserved Capacity
Regional Endpoint
Compliance
很多创业团队看到后会觉得：
太重了
但这些“重”的东西，正是第一个企业客户安全评审会问的。
原型架构最大的错误是“为了快，把未来完全写死”
例如：
client = GeminiClient(
api_key=os.getenv("GEMINI_KEY")
)
散落在 80 个文件。
以后迁身份就很痛苦。
更好的第一天就包一层：
public interface ModelGateway {
ModelResponse call(
ModelRequest request);
}
开发环境：
ApiKeyModelGateway
生产环境：
WorkloadIdentityModelGateway
这样原型仍然很快，但不会把身份实现写进业务逻辑。
配额也应该通过 Gateway 集中治理
不要每个服务自己打模型。
统一经过：
Model Gateway
可以做：
Quota
Rate Limit
Budget
Retry
Fallback
Telemetry
当 429 出现时，不需要修改几十个业务服务。
一个非常实用的限流层
public record ModelQuotaPolicy(
String tenantId,
String modelProfile,
int requestsPerMinute,
long tokensPerMinute,
int concurrentRuns) {
}
至少同时限：
Request
Token
Concurrency
只限请求次数对大上下文任务不够。
429 以后不要盲目重试
很多 SDK 会自动 Retry。
如果是：
quota exhausted
重试只会继续失败。
应该识别：
Retry-After
Quota Type
Reset Window
并决定：
等待
切模型
排队
拒绝低优先级任务
我会给任务加 Priority
public enum TaskPriority {
INTERACTIVE_HIGH,
USER_NORMAL,
BACKGROUND,
BATCH
}
配额紧张时：
先暂停 Batch
再减 Background
保证交互任务
而不是所有请求一起 429。
成本也是一个“配额”
很多项目技术上还能跑。
但：
账单已经超预算
所以除了 Provider Quota，还要有：
Internal Budget Quota
例如：
tenant:
daily_budget_usd: 500
warning: 0.7
throttle: 0.9
hard_stop: 1.0
到 90%：
强制路由便宜模型
而不是等财务月底看到发票。
原型到生产还需要把“谁拥有这些东西”写清楚
我会做一张表：
| 项目 | Owner |
|---|---|
| Model Gateway | AI Platform |
| IAM | Cloud Platform |
| Agent Policy | AI Platform + Security |
| Quota | Platform |
| Budget | Product Owner |
| Logging | SRE |
| Data Retention | Security/Legal |
| Incident Response | SRE |
如果一行写：
TBD
它就是上线风险。
生产 Readiness Review 不需要很官僚
可以只有 15 个问题：
身份怎么做？
Key 是否存在生产？
权限最小吗？
配额够吗？
429 怎么处理？
预算上限？
日志？
敏感数据？
模型故障？
Tool 故障？
Retry Budget？
人能暂停 Agent 吗？
版本能回滚吗？
谁 On-call？
删除数据怎么做？
真正答清楚，比做 60 页 PPT 有价值。
原型代码可以脏一点，但“边界”必须干净
这是我的核心判断。
你可以先：
不做最漂亮的架构
不做所有自动化
但这些边界最好第一天就抽象：
Model
Identity
Tool
Storage
Telemetry
因为它们后面几乎一定会变。
如果直接散进业务代码，迁移成本会很高。
Google 昨天列的三个默认失败模式：
Key 泄漏
IAM 卡住
429 爆掉
看起来都是云平台问题。
其实背后是同一个问题：
原型阶段优化的是“最快跑起来”，生产阶段优化的是“谁能用、能跑多少、出了问题能不能管住”。
两者不是同一个系统目标。
所以我现在做 AI PoC 时，会在第一天就加一句：
这个实现只允许活到 PoC 结束。
然后明确写出生产替代方案。
最危险的从来不是临时代码。
而是：
临时代码因为 Demo 成功，
被默认变成了生产架构。
更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/