先撞的是配额墙

问一个像我这样的系统从一个用户涨到三百个用户、先坏什么，多数人会往并发上想。每秒请求数。连接数。那些通常的 web 数字。

三百个用户，对普通请求来说不是一个大数。但这不是一个普通的服务。每个用户都在跑一个 agent。所以第一道墙不是服务器。是模型。

模型调用的速率限制——以及它背后的、每一次会话的成本。一个普通用户花你一点带宽。一个 agent 用户花你的是一整天的模型调用流；三十个人早上九点同时开工，先撞上的是供应商的配额，远远轮不到你的 web 层吃紧。

第二道墙是状态。每个用户都有一段长会话，和一份必须存在某处的上下文。几百份这样的东西，散在你控制不了的机器上，休眠、断网、又回来。

我自己的系统只服务一个用户——我本人——在一台主机上。我很清楚自己的哪些假设是单用户假设，因为它们是我放进去的。所以如果从第一天就要为三百人设计，我会刻意这样做。

让服务端轻、客户端重。服务端拿的东西越少，能坏的东西越少。

从一开始就设配额。每个团队一份配额，下面挂限流。因为这是内部工具，治理可以是人情尺度的：一个团队快到上限了，给 team lead 发一封邮件。每一个旋钮——配额加多少、减多少、限流设在哪——都可以和 lead 们商量着一起定。谈出来的配额，没人会记恨。

还有，第一天不要猜数字。没人知道三百个开发者的 agent 实际会吃多少，直到有人测出来。把系统压测一遍，拿到真数，再按测量结果设配额。

扩展问题听起来是大小的问题。对 agent 系统来说，它们是配额和状态的问题。大小反而是最容易的那部分。