2 篇博文 含有标签「scalability」

当智能体（Agent）产品在生产环境中第一次崩溃时，值班工程师通常会查看请求率图表，发现它平稳得令人乏味。每秒 40 次请求，和昨天一样。没有峰值，没有波动，也没有明显的诱因。与此同时，系统却已火烧连营：到处都是超时，供应商返回 429 错误，队列深度直线飙升。那个本该解释故障原因的图表看起来完全健康，因为图表测量的指标错了。

QPS（每秒查询数）是我们从过去十年无状态 Web 服务中继承下来的单位。一个请求进来，你处理几十毫秒，发送响应，请求结束。在这种模式下，请求率和负载几乎是同一个数字，容量规划基本上就是“单台机器每秒能处理多少请求，再乘以机器数量”。这种思维模式根深蒂固，以至于我们不假思索地沿用。但对于智能体来说，它在悄悄地欺骗你。

你的负载均衡器将一个传入的智能体请求分配给副本 3。但用户的对话历史存储在副本 7 的内存中。副本 3 完全不知道过去六轮发生了什么，于是它从头开始，让用户一头雾水，你的值班工程师在凌晨 2 点被叫醒。你启用了会话粘滞。现在该用户的所有请求永远路由到副本 7。你用一个正确性问题换来了一个可扩展性天花板。

就在这一刻，团队意识到：AI 智能体的"水平扩展"和 Web 服务器的水平扩展根本不是同一个问题。修复方式不同，而那些看似直接的路径会以可预见的方式失败。