3 篇博文 含有标签「api」

你运行了一个负载测试。你的 p95 延迟是 450ms。你对此感觉良好，上线了该功能，然后两周后你的轮值告警响了，因为用户在周二上午 9 点看到了 25 秒的响应时间。

你的代码没有发生任何变化。没有部署，没有配置更改。供应商的状态页面显示“正常运行 (operational)”。然而，你的应用在业务高峰时段持续 20 分钟无法使用。

这就是 LLM 容量争用问题，也是工程师在被坑之前最常忽视的故障模式之一。

你的内容审核服务返回 {"severity": "MEDIUM", "confidence": 0.85}。下游计费系统将 severity 解析为枚举值 ["low", "medium", "high"]。一次模型更新后，服务偶尔开始返回首字母大写的 "Medium"。没有任何部署发生，没有 schema 变更。集成在生产环境中悄然崩溃，整整六天无人察觉——因为所有 HTTP 状态码都是 200。

这是 LLM 支撑服务 API 契约的根本问题：表面看起来像 REST API，但底层行为是概率性的。标准契约工具假设确定性。当这个假设被打破时，它是悄无声息地崩溃的。

2025 年中，一个构建多智能体（multi-agent）财务助手的团队发现其 API 开支从每周 127 美元飙升至 4.7 万美元。一个智能体循环——智能体 A 向智能体 B 寻求澄清，智能体 B 反过来询问智能体 A，以此类推——已经递归运行了 11 天。没有熔断机制（circuit breaker）拦截它，也没有及时触发预算报警。重试逻辑尽职地在每次超时后不断重试，使每一环节的失控成本不断叠加。

这不是一个关于模型质量的故事。这是一个关于分布式系统工程的故事——特别是关于大多数 LLM 应用开发者跳过的那部分，因为他们假设供应商会处理好这些。

事实上，他们并不会。