1. 题目分析Agent 执行任务时经常需要等待外部 LLM、搜索服务或工具返回。等待期间虽然不持续消耗 CPU请求携带的上下文、连接和执行状态却可能一直占用资源。并发任务越多、下游响应越慢这部分存量就越大最终可能先耗尽内存或连接池而不是计算能力。异步编程减少了线程阻塞但不会自动释放任务引用的数据。例如一个挂起的协程仍可能保留召回文档、完整 Prompt 和流式响应对象大量这样的协程同时等待资源占用仍然会累积。因此把同步调用改成异步调用只解决了等待成本中的一部分。治理需要同时回答三个问题允许多少任务等待、等待期间必须保留什么、哪些任务能够保存状态后退出当前执行进程。不同等待阶段的处理方式并不相同首先要分清排队等待、在途调用和异步业务等待。1.1 算清等待占用排队、在途调用和业务等待首先要分开统计。排队任务还没有调用下游可以只保存任务标识和输入引用在途调用已经发出需要维护网络流及必要上下文业务等待则可能只是等一个外部作业结束有机会把执行现场落盘让 Worker 退出。这三类等待如果都实现成“创建一个协程然后一直挂着”就失去了分别治理的空间。先用一个容量示例看清问题某模型接口平均每秒发出 100 次调用平均耗时从 2 秒变成 20 秒。在各自稳定、统计边界一致的条件下平均在途数约从 200 增加到 2000。如果每次调用连带保留 256 KiB 数据仅这部分存活对象就从约 50 MiB 增加到 500 MiB还没有计入连接缓冲和运行时开销。这是估算不是生产测量持续过载、尚未稳定时也不能直接拿这个关系预测峰值。因此治理对象不是抽象的“异步任务太多”而是有多少任务停在哪一步每个任务还占着什么占到什么时候。排查时把任务数与堆内存、线程、文件描述符、连接池等待对应起来才能判断是阻塞线程过多、上下文保留过大还是在途调用没有上限。挂起任务仍然持有上下文和网络资源这份账会决定优化顺序先避免等待独占执行线程再限制等待任务的存量随后缩小每个任务的持有范围。只有外部协议支持恢复时才进一步把长等待移出进程。1.2 释放执行线程如果等待先占满的是线程池就要把网络调用改成真正的非阻塞 I/O。调用发出后运行时保存恢复所需的现场把执行线程交给其他就绪任务数据返回时再调度原任务继续。这释放的是线程的等待时间不是原任务的全部资源。判断是否真正非阻塞不能只看函数上有没有async。异步函数内部调用同步 HTTP SDK仍可能阻塞事件循环大段 JSON 解析、文档处理等 CPU 工作也会让其他任务迟迟得不到调度。Python asyncio 文档明确指出在事件循环线程直接执行阻塞计算会延迟其他任务和 I/O。暂时无法替换的同步 SDK可以放到独立、有界的线程池但提交入口也必须限量。仅把线程数设为 20再往执行器里塞十万个任务只是把阻塞转移到了队列和 Future 对象上。取消调用方的等待也不能当成后台线程已经停止Future 的取消规则不允许借一次取消操作终止已经开始执行的工作。非阻塞执行释放线程但保留任务现场完成这一步后线程数可能下降内存却仍然上涨。这并不矛盾线程可以复用挂起任务引用的 Prompt 和检索结果还在。接下来必须控制的是任务存量而不是继续增加协程数量。1.3 限制等待存量限制要发生在创建重量级执行任务之前。假设模型只允许 100 个在途调用入口却先为十万个请求创建协程、加载历史、拼好 Prompt再让它们竞争 100 个许可那么调用数虽然受控等待区仍可能先耗尽内存。更合理的路径是入口先做准入任务以轻量描述进入有界队列调度器有承接能力时才取出任务、加载当前步骤需要的数据并申请下游调用许可。队列里保存run_id、step_id、截止时间和输入引用不把完整对话与文档副本带进去。先准入再创建执行任务这里至少有两条边界。第一条限制系统接纳多少等待工作同时考虑条数、字节和等待时间第二条限制实际发出多少调用按模型、检索、Tool 分别控制。父任务受控后子分支也不能无限展开否则一次检索扇出就能绕过入口限制。队列满了要按接口契约拒绝、限时等待或转入已经具备持久化承接能力的异步流程。不能不断创建新的生产者任务让它们阻塞在入队操作上队列长度没变队列外的等待者却一直增长。客户端请求体的读取和大小限制也应前置不能等到解析完巨大输入才判断是否接纳。另外连接池大小不能代替调用并发限制。HTTP/2 可以在连接上复用多个请求流所以“只有几十条连接”并不意味着只有几十个在途调用。准入控制的是工作存量调用许可控制的是下游压力两者都需要独立观测。1.4 缩短资源持有时间任务数有了上限还要避免一个任务在等待模型时占住本来已经用完的资源。否则 100 个合法的在途调用也可能同时扣住 100 条数据库连接拖慢完全无关的状态查询。以“读取会话—调用模型—保存结果”为例读取状态应在短事务中完成随后结束事务、归还连接网络等待期间只保留必要的状态快照及版本号。模型返回后再开一个短事务校验版本、提交结果。不能为了防止别人改会话就把数据库事务跨越几十秒模型调用版本冲突应由写入规则处理。与数据库连接相反模型在途许可必须覆盖整个模型调用。协程进入等待时若把许可归还新请求会继续发出实际在途数立刻突破上限。流式响应尤其容易出错收到响应头不代表调用结束许可要到响应流消费完成或本地调用清理结束时才回收。远端是否真的停止仍需另行确认。不同资源按各自生命周期持有内存也按这个思路处理。当前步骤不再需要的召回原文及时解除引用大型 Tool 结果保存为受控的对象引用下一步按需读取日志和追踪记录不要再长期复制一份完整 Prompt。只改一个局部变量还不够如果闭包、缓存或日志队列仍持有对象它就不会被回收。共享 HTTP 客户端可以复用连接但每次响应流都要在成功、异常和取消路径中关闭。HTTPX 的异步流文档专门提醒手动流模式需要负责关闭响应。复用客户端与及时关闭单次响应并不冲突前者减少连接创建后者防止资源泄漏。1.5 把长等待落盘经过前面几步普通网络等待已经变成“数量受限、现场精简的在途调用”。但如果 Tool 启动的是一个耗时十分钟的外部作业仍用协程等待十分钟就值得进一步改变执行方式提交之后保存恢复依据退出当前 Worker收到完成事件时再继续。这一步的前提是外部作业脱离当前连接仍能执行并且可以重新定位结果例如提供稳定的作业 ID、状态查询或可靠回调。普通 LLM 流式连接没有这种能力时不能把协程状态序列化一下就宣称连接也能无成本恢复。满足条件后先持久化检查点、操作标识和待提交事件再由提交器发起外部作业。这样即使 Worker 在提交前后宕机也能根据同一个操作标识查证或幂等提交而不是丢掉任务或盲目创建第二份作业。任务记录保存下一步要恢复的位置、外部关联标识及截止时间内存中不再保留完整执行栈。长等待落盘后通过可靠事件恢复回调路径同样要可靠。先把收到的事件持久化再确认接收推进任务状态和安排恢复之间也不能留一个“状态已改通知丢了”的窗口可以通过事务内的待调度记录衔接。回调可能比任务写入等待状态更早到达因此要能按操作标识暂存、匹配不能只接受已经标成 WAITING 的任务。没有回调但可以查询时用共享调度器扫描到期记录按退避和限额查询不为每个任务创建一个常驻轮询协程。Temporal 的异步 Activity 完成机制也体现了这种分离执行函数返回与业务活动完成可以是两件事。真正节省资源的是让业务等待由持久化状态承接而不只是换一种await写法。1.6 处理慢消费与取消还有一种等待发生在结果已经返回之后模型持续生成用户网络却很慢。此时如果读取端不断收 Token再放进一个无限队列前面的并发控制仍然挡不住单个流持续积累内存。应为每条流和所有流合计设置字节预算。达到水位后让读取或生产过程等待消费端腾出空间持续超过时限再按产品约定终止交付或者把后续结果保存到持久化存储允许用户稍后获取。Node.js 的流背压说明展示了忽略写入反馈导致缓冲持续积累的问题。具体实现仍要核对 SDK 是否提前预读水位阈值也不能被误当成进程内存的绝对硬上限。慢消费者触发缓冲限制与退出策略暂停本地读取不等于远端模型暂停生成或停止计费。因此背压解决本地缓冲取消策略处理是否还要继续执行两者不能混为一谈。用户断开后短时交互任务可以按约定取消已经接纳的后台业务任务则可以继续运行并保存结果不能简单把连接生命周期当成任务生命周期。一旦决定取消要停止派发新的子调用关闭响应流清理定时器、缓冲和引用并归还本地许可。对已经发出的有副作用 Tool取消等待并不能证明业务没有发生迟到的成功结果仍应写入操作记录交给后续查询或补偿流程处理。1.7 验证回收闭环验收要沿着最初的资源账逐项对应排队任务是否有界在途调用是否受控单任务保留字节是否下降完成或取消后资源是否能回收持久化等待是否还能被及时唤醒。只看 CPU 和总 QPS会漏掉这个问题的主体。压测时保持外部到达速率逐步拉长下游耗时再注入永不返回、同步 SDK 阻塞、慢客户端和重复回调。预期结果不是“所有请求都继续接收”而是系统在容量边界内运行超出的请求得到明确处理已经接纳的任务仍有可查询状态。恢复时还要测试大量等待任务同时就绪确认它们仍经过有界调度而不是一次性把上下文全部加载进内存。重点观察各阶段等待数与年龄、存活堆对象、事件循环延迟、线程和连接池占用、取消后的残留任务以及回调到重新执行的延迟。资源释放后进程 RSS 不一定立刻下降所以应结合堆分析判断对象是否仍被引用而不是只盯操作系统的内存曲线。最终形成的闭环是少接纳不必要的等待少持有等待中的资源能落盘的等待不常驻退出和恢复都重新经过容量控制。异步 I/O 只是这个体系的起点。2. 参考回答我会先区分排队等待、在途调用和外部业务等待统计各阶段的任务数、保留内存、连接占用和等待时间定位到底是哪类资源先耗尽。执行层使用真正的非阻塞 I/O同步 SDK 放进有界执行器但不会把协程当成免费资源。准入要放在创建大量任务和加载上下文之前排队只保存轻量描述并分别限制队列容量、子任务展开和下游在途调用。资源按阶段持有数据库读完就归还连接网络等待不跨长事务模型许可则覆盖完整调用不能一进入等待就释放。大对象按需加载响应流在成功、异常和取消路径都要关闭。对于有作业 ID、查询或回调能力的长任务我会保存检查点和操作关联把等待落盘通过可靠事件恢复普通流式连接不能假装支持这种挂起。慢客户端还需要字节级背压与超时退出。最后用下游变慢、永不返回、集中唤醒和取消故障验证资源有界、回收完整并区分本地取消与远端业务结果。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
1. 题目分析Agent 执行任务时经常需要等待外部 LLM、搜索服务或工具返回。等待期间虽然不持续消耗 CPU请求携带的上下文、连接和执行状态却可能一直占用资源。并发任务越多、下游响应越慢这部分存量就越大最终可能先耗尽内存或连接池而不是计算能力。异步编程减少了线程阻塞但不会自动释放任务引用的数据。例如一个挂起的协程仍可能保留召回文档、完整 Prompt 和流式响应对象大量这样的协程同时等待资源占用仍然会累积。因此把同步调用改成异步调用只解决了等待成本中的一部分。治理需要同时回答三个问题允许多少任务等待、等待期间必须保留什么、哪些任务能够保存状态后退出当前执行进程。不同等待阶段的处理方式并不相同首先要分清排队等待、在途调用和异步业务等待。1.1 算清等待占用排队、在途调用和业务等待首先要分开统计。排队任务还没有调用下游可以只保存任务标识和输入引用在途调用已经发出需要维护网络流及必要上下文业务等待则可能只是等一个外部作业结束有机会把执行现场落盘让 Worker 退出。这三类等待如果都实现成“创建一个协程然后一直挂着”就失去了分别治理的空间。先用一个容量示例看清问题某模型接口平均每秒发出 100 次调用平均耗时从 2 秒变成 20 秒。在各自稳定、统计边界一致的条件下平均在途数约从 200 增加到 2000。如果每次调用连带保留 256 KiB 数据仅这部分存活对象就从约 50 MiB 增加到 500 MiB还没有计入连接缓冲和运行时开销。这是估算不是生产测量持续过载、尚未稳定时也不能直接拿这个关系预测峰值。因此治理对象不是抽象的“异步任务太多”而是有多少任务停在哪一步每个任务还占着什么占到什么时候。排查时把任务数与堆内存、线程、文件描述符、连接池等待对应起来才能判断是阻塞线程过多、上下文保留过大还是在途调用没有上限。挂起任务仍然持有上下文和网络资源这份账会决定优化顺序先避免等待独占执行线程再限制等待任务的存量随后缩小每个任务的持有范围。只有外部协议支持恢复时才进一步把长等待移出进程。1.2 释放执行线程如果等待先占满的是线程池就要把网络调用改成真正的非阻塞 I/O。调用发出后运行时保存恢复所需的现场把执行线程交给其他就绪任务数据返回时再调度原任务继续。这释放的是线程的等待时间不是原任务的全部资源。判断是否真正非阻塞不能只看函数上有没有async。异步函数内部调用同步 HTTP SDK仍可能阻塞事件循环大段 JSON 解析、文档处理等 CPU 工作也会让其他任务迟迟得不到调度。Python asyncio 文档明确指出在事件循环线程直接执行阻塞计算会延迟其他任务和 I/O。暂时无法替换的同步 SDK可以放到独立、有界的线程池但提交入口也必须限量。仅把线程数设为 20再往执行器里塞十万个任务只是把阻塞转移到了队列和 Future 对象上。取消调用方的等待也不能当成后台线程已经停止Future 的取消规则不允许借一次取消操作终止已经开始执行的工作。非阻塞执行释放线程但保留任务现场完成这一步后线程数可能下降内存却仍然上涨。这并不矛盾线程可以复用挂起任务引用的 Prompt 和检索结果还在。接下来必须控制的是任务存量而不是继续增加协程数量。1.3 限制等待存量限制要发生在创建重量级执行任务之前。假设模型只允许 100 个在途调用入口却先为十万个请求创建协程、加载历史、拼好 Prompt再让它们竞争 100 个许可那么调用数虽然受控等待区仍可能先耗尽内存。更合理的路径是入口先做准入任务以轻量描述进入有界队列调度器有承接能力时才取出任务、加载当前步骤需要的数据并申请下游调用许可。队列里保存run_id、step_id、截止时间和输入引用不把完整对话与文档副本带进去。先准入再创建执行任务这里至少有两条边界。第一条限制系统接纳多少等待工作同时考虑条数、字节和等待时间第二条限制实际发出多少调用按模型、检索、Tool 分别控制。父任务受控后子分支也不能无限展开否则一次检索扇出就能绕过入口限制。队列满了要按接口契约拒绝、限时等待或转入已经具备持久化承接能力的异步流程。不能不断创建新的生产者任务让它们阻塞在入队操作上队列长度没变队列外的等待者却一直增长。客户端请求体的读取和大小限制也应前置不能等到解析完巨大输入才判断是否接纳。另外连接池大小不能代替调用并发限制。HTTP/2 可以在连接上复用多个请求流所以“只有几十条连接”并不意味着只有几十个在途调用。准入控制的是工作存量调用许可控制的是下游压力两者都需要独立观测。1.4 缩短资源持有时间任务数有了上限还要避免一个任务在等待模型时占住本来已经用完的资源。否则 100 个合法的在途调用也可能同时扣住 100 条数据库连接拖慢完全无关的状态查询。以“读取会话—调用模型—保存结果”为例读取状态应在短事务中完成随后结束事务、归还连接网络等待期间只保留必要的状态快照及版本号。模型返回后再开一个短事务校验版本、提交结果。不能为了防止别人改会话就把数据库事务跨越几十秒模型调用版本冲突应由写入规则处理。与数据库连接相反模型在途许可必须覆盖整个模型调用。协程进入等待时若把许可归还新请求会继续发出实际在途数立刻突破上限。流式响应尤其容易出错收到响应头不代表调用结束许可要到响应流消费完成或本地调用清理结束时才回收。远端是否真的停止仍需另行确认。不同资源按各自生命周期持有内存也按这个思路处理。当前步骤不再需要的召回原文及时解除引用大型 Tool 结果保存为受控的对象引用下一步按需读取日志和追踪记录不要再长期复制一份完整 Prompt。只改一个局部变量还不够如果闭包、缓存或日志队列仍持有对象它就不会被回收。共享 HTTP 客户端可以复用连接但每次响应流都要在成功、异常和取消路径中关闭。HTTPX 的异步流文档专门提醒手动流模式需要负责关闭响应。复用客户端与及时关闭单次响应并不冲突前者减少连接创建后者防止资源泄漏。1.5 把长等待落盘经过前面几步普通网络等待已经变成“数量受限、现场精简的在途调用”。但如果 Tool 启动的是一个耗时十分钟的外部作业仍用协程等待十分钟就值得进一步改变执行方式提交之后保存恢复依据退出当前 Worker收到完成事件时再继续。这一步的前提是外部作业脱离当前连接仍能执行并且可以重新定位结果例如提供稳定的作业 ID、状态查询或可靠回调。普通 LLM 流式连接没有这种能力时不能把协程状态序列化一下就宣称连接也能无成本恢复。满足条件后先持久化检查点、操作标识和待提交事件再由提交器发起外部作业。这样即使 Worker 在提交前后宕机也能根据同一个操作标识查证或幂等提交而不是丢掉任务或盲目创建第二份作业。任务记录保存下一步要恢复的位置、外部关联标识及截止时间内存中不再保留完整执行栈。长等待落盘后通过可靠事件恢复回调路径同样要可靠。先把收到的事件持久化再确认接收推进任务状态和安排恢复之间也不能留一个“状态已改通知丢了”的窗口可以通过事务内的待调度记录衔接。回调可能比任务写入等待状态更早到达因此要能按操作标识暂存、匹配不能只接受已经标成 WAITING 的任务。没有回调但可以查询时用共享调度器扫描到期记录按退避和限额查询不为每个任务创建一个常驻轮询协程。Temporal 的异步 Activity 完成机制也体现了这种分离执行函数返回与业务活动完成可以是两件事。真正节省资源的是让业务等待由持久化状态承接而不只是换一种await写法。1.6 处理慢消费与取消还有一种等待发生在结果已经返回之后模型持续生成用户网络却很慢。此时如果读取端不断收 Token再放进一个无限队列前面的并发控制仍然挡不住单个流持续积累内存。应为每条流和所有流合计设置字节预算。达到水位后让读取或生产过程等待消费端腾出空间持续超过时限再按产品约定终止交付或者把后续结果保存到持久化存储允许用户稍后获取。Node.js 的流背压说明展示了忽略写入反馈导致缓冲持续积累的问题。具体实现仍要核对 SDK 是否提前预读水位阈值也不能被误当成进程内存的绝对硬上限。慢消费者触发缓冲限制与退出策略暂停本地读取不等于远端模型暂停生成或停止计费。因此背压解决本地缓冲取消策略处理是否还要继续执行两者不能混为一谈。用户断开后短时交互任务可以按约定取消已经接纳的后台业务任务则可以继续运行并保存结果不能简单把连接生命周期当成任务生命周期。一旦决定取消要停止派发新的子调用关闭响应流清理定时器、缓冲和引用并归还本地许可。对已经发出的有副作用 Tool取消等待并不能证明业务没有发生迟到的成功结果仍应写入操作记录交给后续查询或补偿流程处理。1.7 验证回收闭环验收要沿着最初的资源账逐项对应排队任务是否有界在途调用是否受控单任务保留字节是否下降完成或取消后资源是否能回收持久化等待是否还能被及时唤醒。只看 CPU 和总 QPS会漏掉这个问题的主体。压测时保持外部到达速率逐步拉长下游耗时再注入永不返回、同步 SDK 阻塞、慢客户端和重复回调。预期结果不是“所有请求都继续接收”而是系统在容量边界内运行超出的请求得到明确处理已经接纳的任务仍有可查询状态。恢复时还要测试大量等待任务同时就绪确认它们仍经过有界调度而不是一次性把上下文全部加载进内存。重点观察各阶段等待数与年龄、存活堆对象、事件循环延迟、线程和连接池占用、取消后的残留任务以及回调到重新执行的延迟。资源释放后进程 RSS 不一定立刻下降所以应结合堆分析判断对象是否仍被引用而不是只盯操作系统的内存曲线。最终形成的闭环是少接纳不必要的等待少持有等待中的资源能落盘的等待不常驻退出和恢复都重新经过容量控制。异步 I/O 只是这个体系的起点。2. 参考回答我会先区分排队等待、在途调用和外部业务等待统计各阶段的任务数、保留内存、连接占用和等待时间定位到底是哪类资源先耗尽。执行层使用真正的非阻塞 I/O同步 SDK 放进有界执行器但不会把协程当成免费资源。准入要放在创建大量任务和加载上下文之前排队只保存轻量描述并分别限制队列容量、子任务展开和下游在途调用。资源按阶段持有数据库读完就归还连接网络等待不跨长事务模型许可则覆盖完整调用不能一进入等待就释放。大对象按需加载响应流在成功、异常和取消路径都要关闭。对于有作业 ID、查询或回调能力的长任务我会保存检查点和操作关联把等待落盘通过可靠事件恢复普通流式连接不能假装支持这种挂起。慢客户端还需要字节级背压与超时退出。最后用下游变慢、永不返回、集中唤醒和取消故障验证资源有界、回收完整并区分本地取消与远端业务结果。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
