使用 Amazon Bedrock AgentCore Observability 优化生产智能体

当你的 AI 智能体从原型阶段走向生产环境时，挑战的重点从「让它工作」转变为「保持它快速高效」。在本系列的第 1 部分中，我们讨论了调试两种常见智能体故障：无限循环和工具调用错误。那些场景处理的是已损坏的智能体。在本文中，我们解决一个不同的挑战：正确运行但性能不佳的智能体。响应时间慢和内存增长无限制是在解决初始调试问题后最常见的运维问题。它们不会触发错误告警，但会逐渐侵蚀用户信任并随时间推移增加成本。

借助 Amazon Bedrock AgentCore 的 AgentCore Observability 功能和 Amazon CloudWatch，你将学会如何识别智能体执行路径中的性能瓶颈，并诊断长期运行会话中的内存问题。你还将实施监控实践，在用户发现问题之前捕获性能下降。更多信息和最佳实践，请参阅 Amazon Bedrock AgentCore 的 AgentCore Evaluations 功能和 AgentCore Insights。

你需要具有 Amazon Bedrock AgentCore 访问权限的 AWS 账户、已启用的 CloudWatch Transaction Search 以及已部署的智能体。详细设置说明请参见第 1 部分。

Scenario 3：性能瓶颈

当智能体正确运行但响应过慢时，就会遭遇性能瓶颈。你期望获得亚秒响应，但却体验到多秒延迟。智能体成功完成任务，但延迟使其不适合互动使用场景。这个场景特别具有挑战性，因为「慢」是相对的。对于批处理智能体可以接受的响应时间，对于客户服务聊天机器人来说是不可接受的。你必须为特定使用场景建立性能预算，然后系统地识别哪些组件违反了这些预算。

需要警惕的症状

性能下降通常逐步显现。智能体可能初期响应时间为 2 秒，符合预期，但随着功能增加、集成更多工具或累积更多内存，延迟逐渐攀升至 5 秒、10 秒，最后变得不可用。P95 响应时间超过阈值，用户放弃会话，但错误率仍保持较低。智能体运行正确但响应太慢。

图 1 — 会话详情，展示多条追踪记录且延迟一致较高。三次调用花费 7.5-8.2 秒（平均跨度延迟），表现出系统性性能瓶颈而非偶发性缓慢。这种模式表明智能体架构需要优化。

要找到瓶颈，先从识别高延迟请求开始。查询 CloudWatch 中超出性能预算的智能体调用：

fields @timestamp, RequestId, Latency
| filter Operation like /InvokeAgent/
| filter Latency > 3000
| sort Latency desc
| limit 50

此查询返回耗时超过 3 秒的智能体调用（根据需要调整阈值），按延迟排序。选择一个代表性的高延迟请求并记下其 RequestId。

接下来，分析请求时间线以了解时间如何分配：

fields @timestamp, Operation, Duration, SpanName
| filter RequestId = "<RequestId>"
| sort @timestamp asc

此查询展示请求内的操作序列及各操作耗时。寻找消耗不成比例时间的操作。常见的罪魁祸首包括内存检索操作、工具调用、令牌生成和可能并行运行的顺序操作。

图 2 — OpenTelemetry 追踪时间线，在三个顺序执行的 execute_event_loop_cycle 操作中显示 17 个跨度。工具（customer_lookup、order_history）逐个执行而非并行执行，每个循环等待前一个完成。这种顺序模式在每次工具调用中加重延迟。

特别检查内存检索延迟：

fields @timestamp, MemoryRetrievalLatency, MemoryNamespace
| filter RequestId = "<RequestId>"
| stats avg(MemoryRetrievalLatency), max(MemoryRetrievalLatency) by MemoryNamespace

内存检索应在 200 毫秒以内完成，这是用户开始察觉到互动应用中明显延迟的阈值。更高的延迟表明内存组织效率低下。

检查工具调用延迟以识别缓慢的集成：

fields @timestamp, ToolName, ToolLatency
| filter RequestId = "<RequestId>"
| sort ToolLatency desc

此查询识别哪些工具对总体延迟的贡献最大。单个缓慢工具可能成为整个智能体工作流的瓶颈。

性能瓶颈通常源于三个根本原因。缓慢工具执行在外部工具响应缓慢时发生，因为优化不佳、过载或网络问题。延迟通过顺序调用叠加，所以一个 2 秒的工具调用三次会变成 6 秒的瓶颈。过度令牌生成是一个因素，因为基础模型（FM）顺序生成令牌，意味着 500 令牌响应比 100 令牌响应耗时 5 倍，同时影响延迟和成本。最后，顺序处理，逐个而非并行执行独立操作，增加成本和计算时间。

对于缓慢工具执行，实施缓存、连接池和适当的数据库索引以降低响应时间。设置超时限制并考虑更快的工具替代方案。如果工具持续滞后，单独对其进行分析。问题可能是网络延迟、冷启动或资源争用，而不是工具逻辑本身。

对于内存检索，用特定主题分区（如偏好、历史和领域知识）替换单个大命名空间，以缩小搜索范围。将旧对话总结为紧凑条目而非逐字存储，并为每个命名空间设置大小限制，如 100 条偏好、50 条最近消息或 500 条领域事实。

对于令牌生成，优化提示词以鼓励简洁直接的 2-3 句回答，除非请求更多细节。添加显式长度约束并用告警监控令牌使用，以检测意外长响应。

对于顺序处理，并行运行独立工具调用。总耗时 4.5 秒的顺序调用（2s + 1.5s + 1s）在并行化时降至仅 2 秒，通常用最少努力就能将延迟削减 50% 或更多。要验证优化，重新运行「识别瓶颈」部分的延迟查询。确认 P95 响应时间现在落在性能预算范围内，且追踪时间线在预期处显示并行执行。

Scenario 4：长期运行会话中的内存问题

当智能体在内存使用增长无限制的会话中运行时，就会遭遇内存问题。智能体累积上下文，最终命中令牌限制、丧失重要上下文或耗尽可用内存。会话意外失败，你丧失对话状态。这个场景对支持扩展工作流的智能体特别成问题，如客户服务会话、研究助手或监控智能体。没有正确的内存管理，这些使用场景就无法实现。

需要警惕的症状

当存在异常长期的智能体会话时，令牌使用随会话时长线性增长。随着内存存储增大，内存检索延迟随时间增加。会话以内存不足错误或上下文窗口超出错误意外终止。

图 3 — memorygrowth_Agent 的会话详情，显示 6 条追踪、15.7K 总令牌消耗，以及单个会话内 3,757 毫秒的平均追踪延迟。令牌使用随每次后续调用而增长，表现出无限制的上下文累积。在跨越数小时的生产会话中，这种模式导致上下文窗口耗尽和意外会话失败。

要识别内存使用量高的长期运行会话：

fields @timestamp, SessionId, SessionDuration, MemorySize, TokenUsage
| filter SessionDuration > 3600
| sort MemorySize desc
| limit 20

此查询返回持续超过一小时（3600 秒）的会话，按内存大小排序。选择一个内存使用量异常高的会话并记下其 SessionId。

检查内存提取模式以验证整合是否进行中：

fields @timestamp, MemoryExtractionStatus, MemoryExtractionLatency, MemoriesExtracted
| filter SessionId = "<SessionId>"
| sort @timestamp asc

图 4 — CloudWatch Logs Insights 显示，209 条与记忆相关的日志条目集中出现在 18:20 左右。记忆操作的激增表明，AI 智能体正在存储信息，但没有进行整合。每次调用都会通过 add_conversation_note 和 add_user_context 工具添加新的记忆条目，却不裁剪或汇总旧数据，这体现了无界增长模式。

记忆提取应在整个会话期间定期进行。如果你发现长时间没有进行任何提取，说明 AI 智能体未能正确整合记忆。

检查记忆提取失败：

fields @timestamp, ErrorMessage, MemoryExtractionStatus
| filter SessionId = "<SessionId>"
| filter MemoryExtractionStatus = "Failed"

记忆提取失败会阻止 AI 智能体整合上下文，从而导致无界增长。常见的失败原因包括：汇总过程中超出 token 限制、无法处理的无效记忆格式、向记忆存储写入时发生网络超时，以及阻止记忆更新的权限错误。

分析记忆命名空间的组织情况：

fields @timestamp, MemoryNamespace, MemoryCount, MemorySize
| filter SessionId = "<SessionId>"
| stats sum(MemoryCount) as TotalMemories, sum(MemorySize) as TotalSize by MemoryNamespace
| sort TotalSize desc

记忆分布在不同的命名空间中。命名空间组织不当会导致记忆检索和整合效率低下。如果你发现单个命名空间包含数千条记忆，这就是一个危险信号，说明你的 AI 智能体需要采用更合理的记忆组织方式。

记忆问题通常源于设置配置不当，请根据记录内置的日期时间元数据进行筛选。若要深入了解 AgentCore memory 的工作原理，请参阅 AgentCore memory。

要解决记忆问题，请确认你的记忆策略包含整合配置，使 AgentCore memory 能够随着时间推移合并并汇总记录，而不是无限期地累积记录。在策略定义中使用命名空间模板来组织记录，确保检索范围始终限定在相关上下文内。设置 eventExpiryDuration，控制原始事件的保留时长（7–365 天）。有关实现细节，请参阅 AgentCore memory implementation。

在介绍完两部分中的四种故障场景后，我们现在转向生产环境的最佳实践，以便在这些问题发生之前加以阻止。前面介绍的故障排查工作流可以帮助你在问题发生时作出响应，而设计完善的可观测性策略则能帮助你主动发现问题。AgentCore 与 CloudWatch 的集成为这种主动式方法提供了基础，让你能够实时了解 AI 智能体的运行状况和性能。

为生产环境中的 AI 智能体、记忆系统和网关启用全面的检测能力。配置 CloudWatch logs、CloudWatch metrics 和 OpenTelemetry traces。

为关键指标配置 CloudWatch alarms。为错误率（5%）、第 95 百分位（P95）延迟（3 秒）以及每个会话的 token 使用量设置阈值。不要等到用户报告问题。让 CloudWatch 在指标超过可接受阈值时向你发出警报。

创建运维仪表板。构建一个主仪表板，展示调用总数（最近 24 小时）、错误率（当前值与基线的对比）、P50/P95/P99 延迟、token 使用趋势以及活跃会话数量。创建针对各个 AI 智能体的仪表板，展示特定 AI 智能体的调用模式、工具使用明细、记忆消耗趋势、错误类型分布以及每个会话的成本。每天检查这些仪表板，以便在趋势演变成问题之前发现它们。

在真正需要可观测性基础设施之前，就应当进行投入。从第一天起，就将监控纳入开发流程。与产品经理和利益相关者共享仪表板，让所有人都了解 AI 智能体的性能。当有人诊断出棘手的生产问题时，应与团队分享解决方法，从而积累有关常见故障模式的组织知识。

要大规模监控工具准确性，可以使用 Amazon Bedrock AgentCore Evaluators 持续、自动地评估 AI 智能体的行为。Evaluators 不需要等到故障发生后再手动检查跟踪记录，而是实时检查 AI 智能体会话，并依据预定义的质量标准进行评分。Amazon Bedrock AgentCore Insights（预览版）基于 Evaluators 构建，并提供分诊分析。Insights 可以提供故障分析、用户意图提取和执行摘要。

测试完本文介绍的优化技术后，请清理资源，以避免产生不必要的费用。

对于 CloudWatch 资源，请删除调试期间创建的测试 CloudWatch dashboards，移除为测试目的设置的 CloudWatch alarms；如果不再需要旧的 CloudWatch log groups，请考虑将其归档或删除。

对于 AgentCore 资源，如果你专门为本教程创建了测试 AI 智能体，请通过 AgentCore console 将其删除。移除在记忆优化测试期间创建的所有测试记忆命名空间。删除用于性能测试的所有临时工具集成。

为了优化成本，请检查 Amazon CloudWatch Logs 的保留设置，并根据合规要求进行调整。可以考虑使用 CloudWatch Logs data protection，降低旧日志的存储成本。

要删除 CloudWatch log groups：

aws logs delete-log-group --log-group-name /aws/bedrock-agentcore/your-agent-name

要移除 CloudWatch alarms：

aws cloudwatch delete-alarms --alarm-names your-alarm-name

除了第 1 部分介绍的调试场景之外，性能瓶颈和记忆问题是生产环境中 AI 智能体最常见的运维挑战。通过使用 CloudWatch traces 和 metrics 进行系统化诊断，你可以确定延迟究竟源于工具运行缓慢、记忆检索效率低下、token 生成过多，还是顺序处理。对于长时间运行的会话，监控记忆增长模式并实施整合策略，可以让 AI 智能体在长时间交互中保持稳定。

准备好将这些技术付诸实践了吗？如果尚未为生产环境中的 AI 智能体启用 AgentCore Observability，请先完成这项工作。这个一次性设置将为本文介绍的所有内容奠定基础。为关键指标设置 CloudWatch alarms。针对你的特定 AI 智能体和工作流创建故障排查手册，记录你运行的查询、表明问题存在的阈值，以及你实施的修复措施。

在非生产环境中练习调试。有意引入故障，并练习使用本文介绍的工作流进行诊断。在真正需要于生产环境中排查问题之前，先培养相关的熟练度。与团队分享这些知识，确保每位负责 AI 智能体运维的人员都了解这些调试技术，并知道如何使用 AgentCore 的可观测性功能。

生产环境中的 AI 智能体经常会因为本可避免的原因而发生故障。借助正确的可观测性工具、系统化的故障排查方法，以及将每个问题都视为改进机会的文化，你可以及早发现问题、快速解决问题，并构建能够赢得持久信任的 AI 智能体。

有关 AgentCore 和可观测性功能的更多信息，请访问 AgentCore documentation。要开始使用 AgentCore，请访问 AgentCore console。有关其他 CloudWatch 监控最佳实践，请参阅 CloudWatch User Guide。