给同步LLM客户端外面套asyncio.wait_for，并不能保证超时后后台工作已经停止。调用方可以收到TimeoutError，asyncio任务也可以显示cancelled，而线程里的函数仍在运行。若这时立即重试，或把并发额度还给下一次请求，实际在途工作就可能超过你以为的上限。

下面用本地线程与事件复现这个差异：不访问模型、不发网络请求，却能观察到容量为1的协程信号量对应两个仍在执行的工作线程。先分清谁停止等待、谁收到取消、谁真正结束，再给接口定义超时语义。Read in English。

超时首先约束的是等待关系

Python的wait_for说明规定：超时时取消被等待对象并抛出TimeoutError，而且会等待取消完成，总等待时间可能超过配置值。因此timeout不是任意同步函数的强制终止开关，也不是严格到毫秒的总耗时承诺。

如果被等待的是合作式协程，取消会在合适的挂起点注入CancelledError，清理逻辑还可能继续执行。但本文讨论的是另一个边界：协程只是等待一个已经在线程里启动的同步函数。取消这条等待关系，不会把正在执行的普通函数改造成可随时打断的协程。线程任务尚未开始时，取消可能阻止它执行；所以后面的实验必须先确认started，结论只针对已经运行的工作。

CPython v3.13.0的to_thread实现将函数交给run_in_executor后等待结果。再看线程池Future的取消规则：工作已经执行时，取消无法将它停下来。asyncio.Task与concurrent.futures.Future不是同一个对象，不能只看前者的cancelled就宣布后者的工作已经退出。

容量1为何仍能出现两个工作线程

考虑async with semaphore包住wait_for(to_thread(…))的写法。信号量跟着协程作用域释放；等待超时后，这个作用域可以结束，但底层线程还没有完成。下一次调用拿到额度，再开一个工作线程，前一个仍然占着资源。

这种信号量限制的是当前作用域内的协程数量，没有自动变成“实际存活工作”的计数器。真实SDK若也有连接池、重试和服务器队列，资源关系还会更多；本例只证明两个层级之间的缺口，不外推某家模型服务会产生多少连接或费用。

下面先让第一个worker明确报告started，再开始短超时等待，避免把“任务还没进入线程”误当成“线程运行后被取消”。第一个超时后，第二个调用重复同样过程。直到两个调用都退出前，测试闸门一直关闭，所以线程不会因为工作恰好完成而消失。

十三项检查，看见取消之后的工作

worker增加active计数，等待gate，gate开放后再向effects列表写入自己的名字，最后减少active并报告finished。这些都是本进程的教学状态，不是文件写入、外部接口或真实业务副作用。

import asyncio,threading,sys
from concurrent.futures import ThreadPoolExecutor
checks=0
def check(ok):
    global checks
    assert ok
    checks+=1
async def main():
    asyncio.get_running_loop().set_default_executor(ThreadPoolExecutor(max_workers=4))
    gate=threading.Event();lock=threading.Lock()
    state={'active':0,'peak':0};effects=[];jobs=[]
    sem=asyncio.Semaphore(1)
    def worker(name,started,finished):
        with lock:
            state['active']+=1
            state['peak']=max(state['peak'],state['active'])
        started.set()
        try:
            if not gate.wait(3):
                raise RuntimeError('test cleanup gate timed out')
            with lock:effects.append(name)
            return name
        finally:
            with lock:state['active']-=1
            finished.set()
    async def call(name):
        started=threading.Event();finished=threading.Event()
        async with sem:
            task=asyncio.create_task(asyncio.to_thread(worker,name,started,finished))
            jobs.append((task,finished))
            check(await asyncio.to_thread(started.wait,1))
            try:await asyncio.wait_for(task,.02)
            except TimeoutError:check(True)
            else:raise AssertionError('expected timeout')
            check(task.cancelled())
            check(not finished.is_set())
    try:
        await call('one')
        await call('two')
        with lock:
            check(state['active']==2)
            check(state['peak']==2)
            check(effects==[])
    finally:
        gate.set()
        for task,finished in jobs:
            if not await asyncio.to_thread(finished.wait,1):
                raise RuntimeError('worker did not finish')
    with lock:
        check(state['active']==0)
        check(set(effects)=={'one','two'})
    print(checks,'thread-lifecycle checks passed; Python',sys.version.split()[0])
    print('async semaphore capacity1; observed worker peak',state['peak'])
    print('late effects after caller timeouts',sorted(effects))
asyncio.run(main())

本次实际运行Python 3.15.0标准库，十三项检查通过：两个worker均已开始，两个调用都超时，两个asyncio任务标记取消，但超时后finished仍未设置；active与peak为2；开放闸门后两次晚到状态写入出现，最终active回到0。参考的实现固定为CPython v3.13.0，不能把运行版本写成3.13。

20毫秒只是用于触发这段小测试的等待超时，不是对运行机器延迟的测量。事件等待也有1秒、3秒的失败上限，finally负责开放闸门并等待线程退出；代码不会把永久挂住的worker留在后台。真实系统不应照抄这些教学时长作为生产配置。

调用方超时，不等于操作失败

在测试闸门开放前，调用方只知道自己没有按时获得结果。它既不能断言worker已经成功，也不能断言worker不会再做事。开放闸门后effects出现两个名字，就是这个不确定窗口的一个本地反例。

接到真实工具调用时，应该区分至少三个状态：调用方已超时；本地worker是否仍活跃；远端操作是否已经完成。即使本地网络连接被关闭，远端是否撤销，也要依赖服务的协议与执行状态，不能由本地异常类推出来。

因此重试前先判断操作是否可安全重做，并用服务支持的操作标识或状态查询解决结果不明。站内Agent工具调用的幂等重试讨论的是重复提交的业务语义；本文补的是更早一层的生命周期证据，不重复设计一套幂等协议。

把并发额度绑定到实际结束

如果目标是限制实际在途同步工作，应让工作管理层保留句柄，并在真实完成或确认退出后释放对应资源额度，而不是只在请求协程超时离开时释放。调用方可以先返回“超时、结果未知”，工作仍由受控的执行器管理和观测。

这不意味着给所有任务加shield就算修好。shield改变的是取消传播，不能强行停止已运行线程；若保留后台任务，就还需要保存引用、收集最终结果或异常、限制队列并处理关闭过程。本文没有执行shield变体，不把它当成验证过的完整修复。

线程池的max_workers可以限制池内同时执行的线程数，但不会自动为无限提交提供背压，也不会终止已有工作。示例明确设为4，才能让两个阻塞worker和检查事件的短辅助调用共同运行；把它设为1后运行现象会变，不应让读者把本例峰值当成默认线程池参数。

更合适的解决方式取决于工作本身：支持合作停止的循环可检查停止事件；支持取消或期限的SDK应按其协议使用；确实需要强隔离的工作可能需要进程或外部worker。提出停止请求与确认停止完成仍是两个状态，本文没有测试这些替代方案。

把三条时间线分别记下来

排查LLM网关超时时，至少记录请求开始、调用方超时、本地工作开始与结束，以及可取得的远端操作状态。活跃请求数与活跃工作数分开计数，才能发现“前端已经空闲，后台仍积压”。记录时避免把prompt、凭据或用户私密数据带入日志。

与请求背压与队列相连的地方，是准入额度究竟对应哪种资源：排队请求、正在等待的协程，还是已经启动的工作。一个名叫Semaphore的对象不会替你完成这项资源定义。

如果这段可执行的取消反例帮你定位了超时后仍在工作的线程，欢迎在文末自愿支持。可以复用的是started、timeout、finished三类证据，以及把额度释放与真实退出对齐的检查方法。

来源与补发说明

Python wait_for · Executor Future.cancel · CPython v3.13.0 to_thread

核对Python官方取消约定及固定CPython v3.13.0实现。示例实际运行本机Python 3.15.0标准库，不涉及模型、网络或远端停止协议。保留2026年10月22日19:00北京时间文章日期，实际补发时间另行记录，不表示此前已公开。