用 AgentCore 可观测性优化生产智能体

#用 AgentCore 可观测性优化生产智能体

智能体从原型进入生产后，挑战会从“让它跑起来”转到“让它又快又稳”。本系列第一部分走过两类常见故障的排查：无限循环，以及工具调用错误。那些场景处理的是已经坏掉的智能体。本文处理另一类问题：智能体结果正确，但表现很差。响应变慢，以及内存无界增长，是解决最初调试问题之后最常见的运维问题。它们不会触发错误告警，但会侵蚀用户信任，并随时间推高成本。

借助 Amazon Bedrock AgentCore 的能力智能体核心可观测性（AgentCore Observability），以及 Amazon CloudWatch，你可以学会沿智能体执行路径找出性能瓶颈，并诊断长会话中的内存问题。你还会落地一套监控做法，在用户察觉之前抓住性能退化。更多信息与最佳实践，请查阅 Amazon Bedrock AgentCore 的能力智能体核心评估（AgentCore Evaluations）和智能体核心洞察（AgentCore Insights）。

前提条件

你需要一个具备 Amazon Bedrock AgentCore 访问权限的 AWS 账户、已启用的 CloudWatch 事务搜索（Transaction Search），以及一个已部署的智能体。完整安装细节见该系列第一部分。

场景 3：性能瓶颈

智能体出现性能瓶颈，是指它工作正确，但响应过慢。你期望亚秒级响应，实际却是数秒延迟。任务能完成，但延迟使它不适合交互场景。这个场景特别难，因为“慢”是主观的。批处理智能体可以接受的耗时，对客服聊天机器人不可接受。你必须为自己的用例建立性能预算，再系统找出哪些组件超出预算。

需要留意的症状

性能退化往往是逐渐出现的。智能体一开始可能有可接受的 2 秒响应，但随着功能增加、接入更多工具或积累更多记忆，延迟会爬到 5 秒，再到 10 秒，然后变得不可用。第 95 百分位（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 秒瓶颈。令牌生成过多也是因素，因为基础模型（foundation models，FMs）逐个令牌生成，500 个令牌的响应耗时是 100 个令牌的 5 倍，同时影响延迟和成本。最后是串行处理：把彼此独立的操作一次做一个，而不是并行，会同时增加成本和计算时间。

修复

针对慢工具：用缓存、连接池和合适的数据库索引缩短响应时间。设置超时，并考虑更快的工具替代。如果某个工具持续偏慢，单独剖析它。问题可能是网络延迟、冷启动或资源争用，而不一定是工具逻辑本身。

针对记忆检索：用按主题划分的分区替代单一大命名空间（namespace），例如偏好、历史和领域知识，以缩小搜索范围。把旧对话摘要成紧凑条目，而不是逐字保存，并为每个命名空间设置大小上限，例如 100 条偏好、50 条近期消息或 500 条领域事实。

针对令牌生成：优化提示词，鼓励简短直接的回答，除非对方要求更多细节，否则控制在 2–3 句。加入明确的长度约束，并监控令牌用量，对异常长的响应设置告警。

针对串行处理：把独立的工具调用改为并行。串行合计 4.5 秒（2 秒 + 1.5 秒 + 1 秒）在并行后往往只剩 2 秒，经常能以很小的代价把延迟降低百分之 50 或更多。要验证优化，重新运行“找出瓶颈”一节中的延迟查询。确认第 95 百分位（P95）响应时间已落在性能预算内，并且追踪时间线在预期位置显示并行执行。

场景 4：长会话中的内存问题

长会话出现内存问题，是指会话期间内存用量无界增长。智能体不断堆积上下文，最终触及令牌上限、丢失重要上下文，或耗尽可用内存。会话意外失败，对话状态丢失。这对支持长流程的智能体尤其严重，例如客服会话、研究助手或监控智能体。没有适当的内存管理，这些用例就不实用。

需要留意的症状

当存在异常长的智能体会话时，令牌用量会随会话时长线性增长。记忆存储变大后，记忆检索延迟随时间上升。会话会因内存不足（out-of-memory）错误或上下文窗口超限（context window exceeded）错误而意外终止。

图 3：memorygrowth_Agent 的会话详情显示 6 条追踪、共消耗 15.7K 令牌，单次会话内平均追踪延迟 3,757 毫秒。令牌用量随每一次后续调用增长，表明上下文在无界堆积。在长达数小时的生产会话中，这种模式会导致上下文窗口耗尽和会话意外失败。

找出内存用量高的长会话：

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

该查询返回持续超过 1 小时（3600 秒）的会话，并按内存大小排序。挑选内存用量异常高的会话，记下它的 SessionId。

检查记忆抽取模式，确认是否在进行合并：

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

图 4：CloudWatch Logs Insights 显示，约 18:20 前后集中出现 209 条与记忆相关的日志。记忆操作尖峰表明智能体在存储信息时没有合并。每次调用都通过 add_conversation_note 和 add_user_context 工具新增记忆条目，却不修剪或摘要旧数据，这就是无界增长模式。

记忆抽取应在整个会话中定期发生。如果看到长时间没有任何抽取，说明智能体没有正确合并记忆。

检查记忆抽取失败：

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

记忆抽取失败会阻止智能体合并上下文，从而造成无界增长。常见失败原因包括摘要时超出令牌上限、记忆格式无效而无法处理、写入记忆存储时网络超时，以及阻止记忆更新的权限错误。

分析记忆命名空间的组织方式：

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

记忆分布在多个命名空间中。命名空间组织不当会导致检索和合并低效。如果看到单个命名空间里有数千条记忆，这是危险信号，说明智能体需要更好的记忆组织。

根因分析

内存问题通常源于配置不当，以及对记录内置日期时间元数据的筛选。若要更深入理解 AgentCore 记忆如何工作，请参阅 AgentCore 记忆。

修复

要解决内存问题，请确认记忆策略包含合并配置，使 AgentCore 记忆随时间合并并摘要记录，而不是无限堆积。在策略定义中使用命名空间模板组织记录，确保检索范围停留在相关上下文。设置 eventExpiryDuration，控制原始事件保留多久（7–365 天）。实现细节见 AgentCore 记忆实现。

生产最佳实践

两部分一共覆盖了四种失败场景之后，接下来是在问题发生前就拦住它们的生产最佳实践。前面的排障流程帮助你在出事时响应，而设计良好的可观测策略帮助你主动发现问题。AgentCore 与 CloudWatch 的集成提供了这种主动方式的基础，让你实时看到智能体的健康与性能。

为生产智能体、记忆系统和网关打开全面的插桩。配置 CloudWatch 日志、CloudWatch 指标和开放遥测（OpenTelemetry）追踪。

为关键指标配置 CloudWatch 告警。为错误率（百分之 5）、第 95 百分位（P95）延迟（3 秒）以及每会话令牌用量设置阈值。不要等用户来报问题。指标超出可接受阈值时，让 CloudWatch 通知你。

建立运维仪表板。主仪表板展示总调用次数（最近 24 小时）、错误率（当前值相对基线）、第 50／第 95／第 99 百分位（P50/P95/P99）延迟、令牌用量趋势，以及活跃会话数。为每个智能体再做仪表板，展示该智能体的调用模式、工具使用分解、内存消耗趋势、错误类型分布，以及每会话成本。每天查看这些仪表板，在趋势变成问题之前发现它们。

在你需要可观测基础设施之前就投入。从第一天起把监控做进开发流程。把仪表板分享给产品经理和干系人，让所有人理解智能体性能。当有人诊断出一个棘手的生产问题时，把方法分享给团队，积累常见失败模式的组织知识。

要大规模监控工具准确性，可以使用 Amazon Bedrock AgentCore 评估器（Evaluators），持续、自动地评估智能体行为。不必在失败发生后再人工复查追踪，评估器会实时检查智能体会话，并按预定义质量标准打分。Amazon Bedrock AgentCore 洞察（Insights，预览）建立在评估器之上，并提供分诊分析。洞察可以提供失败分析、用户意图提取和执行摘要。

清理

在本文中测试优化方法之后，清理资源以避免不必要的费用。

对于 CloudWatch 资源：删除调试期间创建的测试 CloudWatch 仪表板，移除为测试而设置的 CloudWatch 告警，并考虑归档或删除不再需要的旧 CloudWatch 日志组。

对于 AgentCore 资源：如果专门为本教程创建了测试智能体，通过 AgentCore 控制台删除它们。移除记忆优化测试期间创建的测试记忆命名空间。删除用于性能测试的临时工具集成。

对于成本优化：检查 Amazon CloudWatch Logs 的保留设置，并按合规要求调整。可以考虑使用 CloudWatch Logs 数据保护，以降低较旧日志的存储成本。

删除 CloudWatch 日志组：

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

移除 CloudWatch 告警：

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

结论

除第一部分的调试场景之外，性能瓶颈和内存问题是生产智能体最常见的运维挑战。借助 CloudWatch 追踪和指标做系统诊断，可以判断延迟来自慢工具、低效的记忆检索、过多的令牌生成，还是串行处理。对于长会话，监控内存增长模式并实施合并策略，可以让智能体在长时间交互中保持稳定。

后续步骤

准备把这些方法用起来？如果还没有打开，先为生产智能体启用 AgentCore 可观测性。这一次性设置是本文全部内容的基础。为关键指标设置 CloudWatch 告警。为你的智能体和工作流编写排障运行手册，写明你运行的查询、表示出问题的阈值，以及你实施的修复。

在非生产环境练习调试。故意引入故障，并用本文的流程练习诊断。在生产中真正需要之前，先练出排障的肌肉记忆。把这些知识分享给团队，确认每个运维智能体的人都理解这些调试方法，并知道如何使用 AgentCore 的可观测功能。

生产智能体的失败往往本可预防。有合适的可观测工具、系统化的排障方法，以及把每个问题都当成改进机会的文化，你就可以更早发现问题、更快解决，并做出能长期赢得信任的智能体。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/optimizing-production-agents-with-amazon-bedrock-agentcore-observability