Agent 长任务耗时显著变长时，如何定位原因并优化？

核心回答

如果同类 Agent 任务原来约 5 分钟，现在变成 15～20 分钟，我会先对齐任务规模和版本，再比较正常与异常任务的执行时间线，判断是执行步骤变多了、某一步变慢了，还是并发与排队造成等待。先定位占据关键路径的环节，再做针对性优化。

具体会把模型调用、工具执行、检索、重试和任务调度串起来，看每一步的耗时、次数、输入输出规模和错误。模型慢就检查排队、上下文和生成长度；工具慢就查外部服务、超时与重试；循环变多就查失败反馈、重复动作和停止条件。互不依赖的步骤可以并行，但不能破坏数据依赖或业务正确性。最后用同类任务复测完成率、总耗时、尾延迟和成本，确认提速没有靠漏做任务实现。

先找出多出来的时间花在哪里

挑选任务目标、资料量、输出要求相近的正常与异常样本，记录模型、提示词、工具、代码和配置版本。任务从读一份文档变成读整个目录，或新增复杂产物，本来就可能增加耗时，不能只比较两个总分钟数。

给一次任务关联统一标识，沿时间线检查每个模型与工具调用，包括排队、开始、结束、重试和等待。既看单次调用，也看次数与累计消耗：一次模型请求从几秒变成几十秒，与模型多调用了几十轮，是两类问题。

并行任务的耗时不能直接相加，父步骤时间也可能已经包含子步骤。要找真正决定结束时间的依赖链：例如多个检索同时进行，最后一个慢检索才是汇总开始的等待点；优化一个早已完成的分支，对总时长可能没有明显帮助。

按证据检查三类原因

执行量增加。 检查是否重复搜索同一问题、反复读大文件、上下文不断累积，或工具失败后模型换一种说法继续调用。把动作、参数、结果与下一步状态对照，判断新增步骤是否带来有效信息。修复状态推进和终止判断，给单工具、单任务设置合理的调用与时间预算。

单个环节变慢。 模型侧区分首次可见输出和完整生成耗时，并比较输入、输出与缓存命中情况；工具侧拆分连接、服务处理、文件读写和结果传输。出现超时或限流时，还要检查 SDK、工具层和任务层是否重复重试，避免一次故障被多层放大。详见如何解决大模型 API 服务响应延迟？。

并发与资源等待。 检查任务队列、连接池、限流额度、CPU、内存与磁盘，以及同步代码是否阻塞事件循环。并发扩大后共享额度更紧、工具返回更大或汇总等待更长，可能让总时长反而上升。不能因为使用了异步框架，就推断所有步骤都在并行执行。

优化要对应到具体环节

无效步骤多，先改计划、工具说明、结果裁剪和停止条件，把已得到的关键事实保存在合适状态中，减少重复劳动。长资料按需读取，保留任务需要的证据与定位，避免每轮都回传全部内容。

独立资料检索可以设置有界并发，再汇总；依赖前一步结果的查询不能强行并行，多个步骤修改同一资源也要处理冲突。工具持续故障时，按错误类型采用有限重试、退避或适用的降级，并把未完成的部分交代清楚。超时后的写操作先核对实际结果，避免重跑产生重复副作用。

对模型瓶颈，可以在质量允许时使用更合适的模型、减少无关上下文和重复输出，并利用服务支持的公共前缀缓存。流式展示能让用户更早看到进度或文字，但不会自动减少后续模型、检索与工具的总工作量。

怎样判断这次优化有效

使用相近难度的固定任务集，在可比负载下对照。除了中位数，还看 P95 等尾延迟、成功率、产物完整性、关键事实与引用质量，以及每个完成任务的总成本。失败和取消任务的消耗也计入，避免只统计成功样本。

可以重放已保存的只读工具结果以缩小排查范围，再单独检查真实工具；付款、发信、写文件等动作需要隔离或替身，不能为了复测直接重复线上操作。检查超时后是否仍残留后台任务、连接或重试，确认用户看到结束时，资源也得到正确回收。

对应教程

参考资料