AI Agent 从原型进入生产环境后，工程重点会迅速变化：系统不再只是“能否完成任务”，还要回答一次会话为什么越来越慢、时间消耗在哪个工具调用上，以及长期运行时内存为何持续增长。Amazon Bedrock AgentCore Observability 与 Amazon CloudWatch 的组合，提供了从会话、执行步骤到资源指标的诊断路径，帮助团队用数据定位瓶颈，而不是依靠重放请求和猜测。
把一次 Agent 请求拆成可诊断的阶段
Agent 的总延迟通常由多段工作叠加而成：模型推理、工具选择、外部 API、知识检索、状态持久化以及重试。只记录请求开始和结束时间，会掩盖真正的问题。
进入生产环境后，至少应围绕以下维度观察执行过程：
- 会话维度：同一
session_id的持续时间、轮次、上下文增长速度和最终状态。 - 步骤维度：模型调用、工具调用、检索和记忆读写分别消耗多少时间。
- 依赖维度：外部 API 的延迟、错误率、超时和重试次数。
- 资源维度：进程内存、CPU、并发数，以及长会话期间的变化趋势。
AgentCore Observability 可用于查看 Agent 工作流的运行轨迹，CloudWatch 则适合汇总日志、指标和告警。诊断时不要只盯平均延迟。平均值可能很稳定，但少数长会话已经出现严重退化，因此更应关注 p95、p99 和最大值。
用关联标识串起会话、步骤与工具调用
可观测性的关键不是日志数量，而是能否沿着一次请求恢复完整执行路径。应用日志应保留稳定的关联字段，例如：
{
"timestamp": "2025-01-15T10:32:11Z",
"level": "INFO",
"event": "tool_call_completed",
"session_id": "session-8f21",
"trace_id": "trace-b74c",
"step": "lookup_inventory",
"tool": "inventory_api",
"duration_ms": 842,
"status": "ok",
"memory_mb": 418.6
}
字段名可以按现有遥测规范调整，但应确保 AgentCore 运行轨迹、应用日志和下游服务日志能够通过 session_id 或 trace_id 关联。敏感提示词、模型输出和工具参数不应未经处理直接写入日志；生产环境通常需要脱敏、采样和保留期限控制。
拿到结构化日志后，可以在 CloudWatch Logs Insights 中查询最慢的执行步骤。下面的查询假设日志已经包含前述 JSON 字段，可直接改造：
fields @timestamp, session_id, trace_id, step, tool, duration_ms, status
| filter event = "tool_call_completed"
| stats count(*) as calls,
avg(duration_ms) as avg_ms,
pct(duration_ms, 95) as p95_ms,
max(duration_ms) as max_ms
by step, tool
| sort p95_ms desc
| limit 20
如果某个工具的 p95 明显高于其他步骤，应继续区分是下游服务变慢、连接建立开销、限流重试，还是 Agent 在一次会话中重复调用了同一个工具。延迟优化不能只看单次调用速度，还要检查调用次数是否符合预期。
长会话内存问题要看趋势，而不是单点
长时间运行的 Agent 容易积累对话历史、工具结果、中间对象和缓存。一次内存快照只能说明“现在用了多少”，无法判断内存是否会随着会话轮次持续增长。
可以这样实践：在每个 Agent 轮次结束时记录进程常驻内存，并将指标发送到 CloudWatch。以下 Python 示例使用 boto3 和 psutil，运行前需要为执行角色授予写入 CloudWatch 自定义指标的权限，并安装依赖：
python -m pip install boto3 psutil
import os
import time
import boto3
import psutil
cloudwatch = boto3.client(
"cloudwatch",
region_name=os.getenv("AWS_REGION", "us-east-1"),
)
process = psutil.Process(os.getpid())
def publish_agent_memory(agent_name: str, session_age_minutes: int) -> None:
rss_mb = process.memory_info().rss / 1024 / 1024
cloudwatch.put_metric_data(
Namespace="ProductionAgents",
MetricData=[
{
"MetricName": "ProcessMemoryMB",
"Dimensions": [
{"Name": "AgentName", "Value": agent_name},
{"Name": "SessionAgeBucket", "Value": bucket(session_age_minutes)},
],
"Value": rss_mb,
"Unit": "Megabytes",
"StorageResolution": 60,
}
],
)
def bucket(minutes: int) -> str:
if minutes < 10:
return "lt-10m"
if minutes < 60:
return "10m-60m"
return "gte-60m"
if __name__ == "__main__":
publish_agent_memory(
agent_name=os.getenv("AGENT_NAME", "support-agent"),
session_age_minutes=int(os.getenv("SESSION_AGE_MINUTES", "75")),
)
print(f"metric published at {int(time.time())}")
这里没有把 session_id 作为 CloudWatch 指标维度，因为高基数字段会增加成本并降低聚合价值。具体会话标识更适合保留在日志或追踪数据中；指标维度应使用 Agent 名称、版本、环境和有限数量的会话年龄分桶。
判断内存问题时，可以将会话年龄与内存曲线放在一起比较：
- 内存随轮次持续上升且会话结束后不回落，可能存在对象引用未释放或缓存无边界增长。
- 只有长会话增长，通常应检查上下文历史、工具结果和记忆加载策略。
- 发布新版本后才出现阶跃式上升，应按 Agent 版本拆分指标并比较部署前后。
- 内存增长伴随工具调用次数增加，可能是重复规划或失败重试造成的间接压力。
从观测结果落实优化动作
发现慢步骤后，需要选择与原因匹配的修复方式。外部 API 慢可以设置明确超时、复用连接并限制重试；检索慢可以缩小候选集或调整索引；上下文持续膨胀则可以压缩历史、限制工具结果长度，并把不必进入模型上下文的数据存入外部状态存储。
告警也应围绕用户影响建立，而不是看到任意资源波动就触发。可以考虑监控这些信号：
- Agent 端到端延迟的 p95 连续多个周期超过目标。
- 工具错误率或超时率突然升高。
- 长会话的内存使用持续增长，并接近运行环境限制。
- 单次会话的步骤数或工具调用数异常增加。
- 新版本在相同流量下出现更高延迟或内存占用。
上线前的可观测性检查表
采用 AgentCore Observability 和 CloudWatch 时，建议先覆盖一条高价值 Agent 工作流，再逐步扩展，不必一开始采集所有提示词和中间状态。
- 为会话、轨迹和步骤建立一致的关联标识。
- 将模型、工具、检索和记忆操作拆成可独立观察的步骤。
- 同时记录端到端延迟、分步骤延迟、错误率和调用次数。
- 为长会话记录内存趋势，并避免在指标中使用高基数会话 ID。
- 对提示词、用户数据和工具参数实施脱敏与访问控制。
- 使用 p95、p99 和版本对比验证优化效果。
- 为遥测数据设置采样率、保留周期和成本预算。
可观测性的目标不是生成更多图表，而是缩短“发现异常、定位步骤、验证修复”的闭环。对生产级 Agent 而言，只有把执行轨迹与资源趋势放在同一条诊断链路中，性能优化和内存治理才会从临时排障变成可重复的工程流程。