像一家餐厅猛增服务员，却只留一个人收银：人手更多，客人反而等得更久。Planck 遇到的正是这种情况。它把多个 LLM Agent——由语言模型驱动、能调用工具完成多步任务的程序——放在同一服务中；一次请求会同时启动所有 Agent，每个 Agent 又发出数十次子 Agent 调用。团队原以为并发越高，速度只取决于最慢的模型请求，结果延迟持续上升，甚至出现超时。
日志显示，LLM 已经返回结果，Python 的事件循环却来不及处理。事件循环可以理解为异步程序的“调度员”：它负责轮流接手大量已完成或待继续的任务。当所有 Agent 都频繁经过这里，看似微小的本地处理也会排队，成为整条链路的瓶颈。作者展示的告警中，事件循环曾落后 230 毫秒和 137 毫秒。
这提醒团队，扩容不能只盯模型接口、GPU 或网络。并发接近系统容量后，吞吐量未必继续增加，等待时间反而可能陡升。作者也说明，测试结果会随负载大小、模拟等待时间和子 Agent 数量变化，因此更值得关注的是趋势，而非绝对数字。