北京
周三下午，Planck的工程师Uri Peled盯着监控面板时，一条异常曲线让他停下了滚动。十几个AI Agent请求的端到端延迟在过去一周悄悄涨了快一倍，而底部那条来自LLM供应商的“请求完成耗时”却几乎没变。“这不对劲，”他回忆道，“如果是模型变慢了，整体曲线应该同步上移，但现实偏偏是两条线分叉得越来越开。”
这是Planck在生产中规模化部署LLM Agent时踩到的一个隐蔽陷阱——不是算力不足，不是模型太慢，而是异步系统里那些小到可以忽略不计的CPU任务，在数百个Agent、上千个并发请求的放大效应下，变成了整个系统的头号瓶颈。
Planck的内部架构并不复杂：一个服务收到请求后，同时触发五个顶层Agent；每个Agent又会用asyncio同时扇出大约30个子Agent调用，每个子Agent调用本质上是一次向LLM服务（比如OpenAI或Anthropic）的HTTP请求。既然几乎全是I/O密集操作，用协程并发看起来是最自然不过的选择——直到他们开始在日志里看到越来越多的超时错误，以及让人无法解释的“模型很快，Agent很慢”现象。
“一开始我们几乎认定，一定是LLM提供商在说谎。”Peled在复盘文章中写道，“日志显示OpenAI的请求完成得很快，但我们的Agent就是需要很久才回复。直到我们做了一次端到端的profiling，才发现——OpenAI没问题，是我们的代码出了问题。”
问题藏在一串非常简单、每一行单独看都毫无毛病的异步代码里。随着生产环境Agent数量增长，单次请求触发的协程数量轻松突破三位数、四位数。虽然每个协程的CPU时间极短，但当数千个协程在同一个事件循环里调度、执行、等待I/O、再被唤醒，上下文切换和调度开销累积成了一个不可忽视的“微型CPU瓶颈”。这些任务单个来看不过几微秒，却因为数量暴增而互锁，最终拖慢了整个事件循环的吞吐。
这个发现颇有些反直觉：所有人都在讨论LLM的Token生成速度和推理延迟，但真正在规模化部署时率先拖垮系统的，反而是那层常常被视作“免费”的异步调度开销。Peled直言，如果没有走到对事件循环行为做精细化剖析这一步，团队很可能还在盲目地增加Agent数量、扩建算力，然后把问题归咎于不可控的外部厂商。
Planck的解法并未在本次披露中完全展开，但Peled明确传递了一个信号：当Agent数量爬升到几百量级时，对异步框架内部行为的理解和优化，已经和选用多快的模型至少同等重要。他们正在重新审视调度策略，减少不必要的协程炸裂，并引入更细粒度的超时和限流机制，来避免那些“微小CPU任务”在系统中形成堆积效应。
对于正在将LLM Agent推向生产环境的AI工程师而言，Planck的这段踩坑经历至少给出了两条可操作的提醒：第一，不要把“I/O密集”当作无上限并发的安全保证，事件循环本身有肉眼看不见的瓶颈；第二，在怀疑模型供应商之前，先好好看看自己的异步代码——真相可能就藏在每一次被忽略的随机延迟里。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
