安全与上线

只要你开始用大模型 API 做真实业务，问题就不再只是“有没有结果”，而是“谁能调用、花了多少钱、出错时怎么止损”。这也是为什么安全和运维要在接入早期就介入。

API key 只留在服务端

最基本的规则不要破：

• 前端不直接持有真实 key
• 仓库不提交真实 key
• 日志里不打印完整 token

如果你的业务必须让客户端触发调用，也应该先经过你自己的服务端，再由服务端去请求 api.clawsocket.com。

建议拆两类环境

CLAWSOCKET_API_KEY_STAGING=
CLAWSOCKET_API_KEY_PRODUCTION=

不要让测试环境和生产环境共用同一把 key。否则测试流量、压测或错误重试很容易污染生产额度和日志。

建议保留的运维面

1. 请求级日志

至少记录：

• 请求时间
• 业务场景
• 模型标签
• 响应耗时
• 状态结果

2. 额度观察

如果没有额度观察面，你通常会在两个最差的时刻发现问题：高峰期和客户投诉之后。

3. 限流策略

把限流放在服务端，不要完全依赖前端自觉。尤其是批量任务、重试逻辑和 agent 场景，很容易瞬间放大请求量。

发布清单

1. 已核对控制台中的 base URL、模型标识和 key
2. staging 与 production 使用不同密钥
3. 业务服务有超时、重试和 fallback
4. 日志不包含敏感字段
5. 预览模型不会直接承接核心流量
6. 出现异常时有明确的降级路径

一个保守但有效的上线顺序

1. 本地验证最小请求
2. staging 跑通业务链路
3. 小流量灰度
4. 观察日志和成本
5. 再决定是否放量

很多团队的问题不是技术做不到，而是把“灰度”省掉了。对大模型 API 来说，这一步尤其不能省。