AI 响应慢自查清单

前言

如果你觉得 AI 响应或执行任务的时间不合理，却又无从下手，可以按照本清单逐项检查。

本文从网络、模型、Agent及其工具、会话输入与输出等多个方面，给出具体的排查和优化方法。

一、问问 AI

无需多言，先问问 AI。

在你发生问题的会话中，让 AI 根据执行记录分析耗时原因。

请基于当前会话，分析本次任务耗时较长的原因。

重点检查：
1. 是否进行了重复或范围过大的搜索；
2. 是否调用了不必要的工具；
3. 是否执行了范围过大的构建、测试或视觉验证；
4. 是否存在工具调用失败、超时或反复重试；
5. 会话上下文是否过长；
6. Agent 规则、Skill 或工具配置是否增加了额外流程。

请区分：
- 已确认的问题；
- 根据会话记录推断的问题；
- 当前无法判断的问题。

最后按优先级给出优化建议，不要直接修改代码或配置。

需要注意的是 AI 分析有局限性，它只能分析当前会话中已记录的信息，无法直接感知未记录的网络波动或服务端状态。如果这一步没有找到原因，我们根据后续章节内容继续排查。

二、检查网络与服务

AI 编程 Agent 的请求需要经过本地网络、代理或中转服务，最后到达模型服务。任何一段连接不稳定，都可能导致请求建立缓慢、长时间无响应、中途断开或自动重试。

1. 检查代理和中转服务

如果使用网络代理，要留意节点的延迟和稳定性。

1. 优先选择口碑和稳定性经过验证的代理服务。
2. 选择延迟较低、连接稳定的节点，避免频繁自动切换、丢包率高或经常断线的节点。
3. 定期更新节点列表并测速。

实际案例：某低价代理服务每天下午 4 点左右频繁掉线。有同事使用它生成原型页面，耗时超过半小时，更换代理后，相同任务降到 8 分钟。

2. 开启 TUN 模式（虚拟网卡）

Agent 一般会优先尝试WebSocket 连接与模型服务通信。原因是WebSocket 可以保持长连接，减少重复建立连接的开销，也更适合持续接收模型的流式响应。

但我们使用网络代理后，部分 Agent 的 WebSocket 流量可能没有进入代理，导致连接失败或反复重试。

请检查代理工具的 TUN 模式（部分工具称为"虚拟网卡"）是否已开启，确保 WebSocket 流量正常经过代理。

实际案例：某 AI Agent 新建会话时连续出现重连 5 次，开启 TUN 模式后恢复正常。

三、检查模型与推理配置

模型能力和推理强度会影响响应速度。高能力模型和高推理强度通常会花更多时间思考和探索，任务耗时也会相应增加。

1. 选择合适的模型和推理强度

先检查当前的模型和推理强度。在保证结果质量的前提下，可以根据任务复杂度适当降低配置：

• 文案修改、代码解释、简单查询等任务，优先选择响应较快的模型，并使用较低的推理强度。
• 复杂调试、跨模块分析、架构设计等任务，选择能力更强的模型，并适当提高推理强度。

不要让所有任务都默认使用能力最强的模型和最高推理强度。

对于复杂度相同的任务，我们可以多次切换推理强度并反复试错后，去找到一个合适的点，达成生成质量与响应速度之间的平衡。

四、检查 Agent 规则与工具列表

Agent 执行任务时，需要读取相关规则，并判断是否使用 Skill 或工具。配置过多、内容重复或相互冲突，会增加理解和决策成本。

1. 精简全局规则和项目规则

打开 Agent 的全局和项目规则文件，例如 AGENTS.md 或 CLAUDE.md，检查是否存在不合理的内容：

• 删除重复、无关或已经失效的规则。
• 避免全局规则与项目规则相互冲突。
• 当前任务的临时要求直接写在提示词中。
• 详细规范按需引用，不要全部堆在主规则文件中。

也可以让 AI 辅助检查：

请检查当前生效的全局规则和项目规则，重点分析：

1. 是否存在重复内容；
2. 是否存在相互冲突的要求；
3. 是否包含与当前项目无关或已经失效的规则；
4. 是否把临时任务要求写成了长期规则；
5. 是否存在过长、含糊或可以合并的内容。

请列出问题所在的文件和具体规则，说明原因，并给出最小化调整建议。

只输出检查结果和建议，暂时不要修改文件。

2. 按需使用 Skill 和工具

工具不是越多越好，关键是与当前任务匹配。检查 Agent 全局和项目中安装、启用的 Skill 与 MCP：

• 警惕功能相似的 Skill，它们可能引入冲突或重复流程。
• 按需安装。不要启用当前用不到或不了解的 Skill 和 MCP。
• 正确选择安装范围。项目专用的 Skill 放在项目中，不要安装到 Agent 全局。
• 按任务场景关闭不必要的工具。例如，测试原型 Skill 的生成效果时，可以关闭截图和视觉比对；进行 UI 高保真还原时，再保留浏览器、截图和视觉验证能力。

也可以让 AI 辅助检查：

请基于当前任务和会话记录，检查 Skill 和工具的使用是否合理。

重点分析：

1. 启用的 Skill 和工具是否与当前任务相关；
2. 是否调用了不必要的搜索、浏览器、截图、构建或测试工具；
3. 是否存在功能重复的 Skill 或工具；
4. 是否因为 Skill 规则触发了不必要的执行流程；
5. 是否缺少完成任务或验证结果所必需的工具。

请区分"可以关闭""应该保留"和"需要补充"的 Skill 与工具，并说明理由。

只输出检查结果和调整建议，暂时不要修改配置。

3. 使用代码检索工具

在大型代码库中反复搜索和读取文件，会增加工具调用和上下文消耗。我们可以使用 codebase-memory-mcp、CodeGraph 等代码索引工具，让 Agent 通过结构化索引定位代码和调用关系，减少重复搜索。

五、优化会话上下文

会话中的历史消息、文件内容和工具输出会持续进入模型上下文。上下文越长，模型每轮需要处理的信息越多，也越容易受无关信息干扰，响应速度和生成质量都可能下降。

1. 保持会话干净、集中

一个会话尽量只处理一个连续任务。任务范围过大时，先缩小到具体模块、文件或问题，再让 Agent 执行。

• 将大型任务拆成多个阶段，逐步处理。Agent的 Plan模式或 Plan 类 Skill可以有效帮助我们完成该任务。
• 不在同一会话中混入无关任务。
• 避免粘贴大量无关代码、日志和文档。
• 让 Agent 按需读取解决问题所需的内容。

2. 及时开启新会话

出现以下情况时，可以考虑开启新会话：

• 开始处理与当前任务无关的问题。
• 会话已经积累大量历史内容。
• Agent 反复引用过时信息。
• 响应速度或回答质量明显下降。

新会话只需提供当前任务必需的背景，不要复制完整历史记录。可以通过引用原会话或生成交接摘要，保留必要上下文。

引用原会话

某 AI Agent 可以在新会话中通过 @ 引用另一个会话。这不同于分叉或静态摘要：新会话仍然保持独立，AI 会根据当前任务按需获取被引用会话的上下文。

其他 Agent 通常也提供有类似功能，以具体客户端为准，大家自行探索。

生成交接摘要

方案一：让 AI 直接生成

在原会话中使用以下提示词：

请把当前会话压缩成一份可交接给新会话继续执行的摘要。
不要写推理过程，不要复述无关内容，不要虚构信息，不确定处标注"待确认"，敏感信息脱敏。

请包含：
1. 目标
2. 已完成事项
3. 关键上下文、约束和决策
4. 关键文件、路径和当前状态
5. 未决问题
6. 下一步行动
7. 验证命令
8. 可直接复制到新会话的启动提示词

方案二：使用 Handoff Skill

也可以使用 mattpocock/skills 中的 handoff Skill，将当前会话压缩为可供新 Agent 继续执行的交接文档。

六、精简模型输出

输出内容越多，模型完成响应所需的时间越长，也会增加后续会话的上下文长度。

1. 明确输出方式

在提示词中说明需要的内容、格式和长度，例如：

• 只输出结论和操作步骤。
• 使用简短列表，不展开背景知识。
• 只分析问题，暂不提供修改方案。
• 先输出大纲，确认后再补充正文。

复杂任务可以分阶段输出，先确认分析或大纲，再继续生成完整内容，避免一次输出大量无用信息。

2. 使用 Caveman 压缩输出

推荐使用 Caveman 约束 AI 的输出风格，减少冗余表达和不必要的过程说明。

实测结果：经本人和项目组成员测试，使用 Caveman 后的输出效率提升超过 50%。

总结

AI 响应慢时，可以先让 AI 分析当前会话，再从网络、模型、Agent 配置、会话上下文和输出内容几个方面逐项检。

• 让 AI 根据当前会话分析耗时原因。
• 更新代理节点并测速，选择延迟较低、连接稳定的节点。
• 检查代理工具的 TUN 模式是否开启。
• 根据任务复杂度选择合适的模型和推理强度。
• 删除重复、无关、失效或冲突的 Agent 规则。
• 只使用当前任务需要的 Skill 和工具。
• 使用代码索引工具，减少重复搜索和读取文件。
• 保持会话主题集中，将大型任务拆分后逐步处理。
• 会话过长时，开启新会话或压缩上下文。
• 明确输出内容、格式和长度，必要时分阶段输出。

欢迎在评论区反馈问题和建议，让我们一起完善内容、沉淀知识。