AI 助手变慢先查这四处

客服、研究和内部办公团队把 AI 助手投入实际使用后，常会遇到一种隐蔽故障：答案没有报错，等待时间却从几秒逐渐拉长。AWS 在一篇技术博客中给出了排查方法。对运维人员而言，关键不是立刻更换模型，而是先找出时间究竟耗在哪一步。

先定义什么叫“慢”

不同任务不能共用一个速度标准。批量整理资料可以多等一会儿，在线客服则需要快速回应。因此，第一步是为具体场景设定“性能预算”，也就是团队能够接受的最长响应时间。

AWS 的示例使用 Amazon Bedrock AgentCore Observability 观察 AI 助手的执行过程，再通过 Amazon CloudWatch 查询日志和指标。前者用于记录助手每一步做了什么，后者用于集中查看耗时、调用次数和异常。

排查时先筛选超过预算的请求，再选择一个有代表性的慢请求，查看它的完整时间线。不要只看总耗时和报错率：请求可以成功返回，但用户早已因等待而退出。

沿时间线检查四个位置

来源将常见耗时归为四类：外部工具调用过慢、记忆检索低效、生成内容过长，以及本可同时进行的操作被依次执行。

外部工具可能是数据库、订单系统或其他服务。若某个工具长期占据大部分时间，应把它单独测试，继续区分网络延迟、冷启动、资源竞争和工具自身处理速度。AWS 博客提出缓存、连接复用、数据库索引和超时限制等处理方向，但具体选择仍取决于现有系统。

“记忆”是助手保存并取回历史信息的机制。来源建议按偏好、历史记录、领域知识等主题拆分，而不是把所有内容塞进一个大空间；旧对话可压缩为摘要，并为不同类别设置容量限制。

回答过长同样会拖慢请求。博客解释，模型按顺序生成文本，内容越长，耗时和用量通常越高。可在提示词中要求默认用两三句话直接回答，需要时再展开，并持续观察异常增长。

修改后要用同一标准复测

如果多个工具互不依赖，可以考虑并行调用。AWS 给出的演示计算是：三个操作依次耗时2秒、1.5秒和1秒，总计4.5秒；并行后由最慢的一项决定，约为2秒。这只是说明机制的示例，不能直接视为所有业务都能获得相同幅度的改善。

每次调整后，应重新执行原来的耗时查询，并比较相同指标。来源建议关注第95百分位响应时间，即把请求从快到慢排列后，处于95%位置的耗时；它比平均值更容易暴露少量但严重的慢请求。

判断优化是否有效，可以看两点：该指标是否回到团队预先设定的预算内；执行时间线中，预期并行的操作是否确实发生重叠。若只是平均速度下降，最慢的一批请求没有改善，问题仍未解决。

长会话还要防止记忆膨胀

客服会话、研究助手和持续监控任务可能运行很久。来源指出，若历史内容不断累积而没有整理，检索会越来越慢，还可能触及上下文或内存限制。

团队可以检查长会话中的记忆大小、文本用量和提取状态，确认系统是否定期合并、总结旧记录，并排查失败原因。AWS 还建议按主题限制检索范围，为原始事件设置保留期限；其文中给出的可配置范围为7至365天。

这些办法适用于已经接入相关 AWS 服务、且能够取得请求日志与执行轨迹的生产环境。博客中的3秒告警线、200毫秒记忆检索时间等均是厂商给出的示例或建议，上线前应依据自身任务、用户容忍度和成本重新设定，不能机械照搬。

来源

• AWS Machine Learning Blog：Optimizing production agents with Amazon Bedrock AgentCore Observability，2026年7月31日