prompt 与 agent 钩子有了并发上限：每个会话最多同时跑 24 个
钩子用得越多，越容易遇到一个隐蔽的问题：一次事件触发一堆模型驱动的钩子，子代理再各自触发一批，最后把会话拖慢甚至拖垮。CLI 2.1.312 给这类钩子加了明确的并发上限。
新规则
更新说明的内容可以归纳为三点：
- prompt 钩子和 agent 钩子，每个会话最多同时运行 24 个，子代理触发的也算在内；
- 在此之外，最多再容纳 12 个已经等待超过其事件超时时间的钩子；
- 钩子配置里的
timeout小于 1 秒时，按 1 秒计算。
注意这里说的是 type 为 prompt 和 agent 的钩子，也就是需要调用模型来判断或执行的那类，而不是普通的 command 钩子。
为什么要限制
prompt 和 agent 钩子每次运行都要发起模型请求，成本和耗时都远高于一条 shell 命令。在多子代理并行的场景下，比如一次 fork 出好几个子代理、每个都在频繁调用工具，PreToolUse 之类的事件可能在很短时间内触发几十上百次。没有上限时，这些请求会同时堆积，挤占速率限制，还可能让主对话迟迟得不到响应。
24 个的并发上限加上 12 个「超时后仍在等」的余量，相当于给钩子系统加了一个排队机制：超出的部分等前面的完成再跑，而不是一拥而上。
关于 timeout 的变化
以前有人会把 timeout 写成很小的值（比如 0.1）想让钩子「快速失败」。现在低于 1 秒一律当作 1 秒。如果你的配置里有这样的写法，行为会略有变化：钩子会多等一会儿才被判定超时。
建议
- 检查高频事件上的 prompt/agent 钩子。挂在
PreToolUse、PostToolUse上的模型钩子最容易撞到上限，能用 command 钩子做的判断尽量用脚本完成。 - 多子代理工作流要留意排队延迟。如果觉得子代理变慢，先看看是不是钩子在排队。
- 把 timeout 设成合理的秒数，不要依赖亚秒级超时。
小结
这条改动不需要你做任何配置，但会影响重度使用钩子的工作流：模型驱动的钩子从此有了上限和排队。升级后如果发现钩子的时序有变化，原因多半在这里。