AI 智能体最棘手的生产事故，往往不会触发传统告警：接口返回 200、延迟正常、模型成功生成内容，最终结果却是错的。Amazon Bedrock AgentCore optimization 关注的正是这类“静默失败”，通过跨会话发现、解释并排序行为失败模式，帮助团队优先修复影响最大的缺陷。
健康检查正常，不等于任务完成正确
传统服务监控擅长回答这些问题：
- 请求是否成功返回？
- 响应时间是否超过阈值？
- CPU、内存或错误率是否异常？
- 模型调用和工具调用是否发生异常？
但智能体还需要回答另一组问题：
- 用户要求取消订单，智能体是否真的取消了正确订单？
- 智能体是否调用了正确工具，并传入正确参数？
- 最终回复是否与工具执行结果一致？
- 遇到缺失信息时，它是主动澄清，还是自行猜测？
例如，一次会话可能没有任何技术错误：模型生成成功，工具返回成功，最终回复也语句通顺。但如果用户要求退款 100 元，智能体却只创建了 10 元退款，这次任务在基础设施层面是成功的，在业务层面却已经失败。
因此，生产可观测性不能只记录 status=success。至少还要保留用户目标、智能体决策、工具参数、工具结果、最终答复以及业务验证结果。
从单次异常转向跨会话失败模式
孤立查看一条轨迹，很容易把问题归因于“模型偶尔不稳定”。跨会话分析则能揭示更有修复价值的模式，例如：
- 特定意图经常选择错误工具；
- 当订单包含多个商品时，退款金额更容易出错；
- 工具已经拒绝操作，最终回复却仍声称操作成功；
- 缺少账号信息时，智能体没有发起澄清；
- 某一版本的提示词发布后，任务成功率持续下降。
AgentCore optimization 的价值不只是找出失败会话，还在于发现、解释和排列这些重复出现的失败模式。排序尤其重要：一个每天出现两次的严重错误，与一个每天影响数千次会话的中等错误，需要完全不同的处理优先级。
团队可以用一个简单模型评估修复顺序：
影响分数 = 失败会话数 × 业务严重度 × 模式置信度
实际使用时，还可以加入受影响用户数、资金风险、合规风险和人工处理成本。分数不是为了制造绝对精确的数字，而是为了让修复顺序可以解释、可以复核。
可以这样实践：构造一个最小失败模式分析器
下面的示例不代表 AgentCore optimization 的真实 API，而是一个可以直接运行的本地原型。它演示如何把会话级验证结果聚合为失败模式，并按影响分数排序。接入实际系统时，可以将示例数据替换为从日志平台、对象存储或智能体追踪系统导出的记录。
将以下内容保存为 analyze_agent_failures.py，然后使用 Python 3.10 或更高版本运行：
from collections import defaultdict
sessions = [
{
"session_id": "s-001",
"intent": "refund",
"pattern": "wrong_refund_amount",
"severity": 5,
"confidence": 0.98,
"passed_health_check": True,
"business_success": False,
},
{
"session_id": "s-002",
"intent": "refund",
"pattern": "wrong_refund_amount",
"severity": 5,
"confidence": 0.95,
"passed_health_check": True,
"business_success": False,
},
{
"session_id": "s-003",
"intent": "cancel_order",
"pattern": "claimed_success_after_tool_rejection",
"severity": 4,
"confidence": 0.90,
"passed_health_check": True,
"business_success": False,
},
{
"session_id": "s-004",
"intent": "order_status",
"pattern": None,
"severity": 0,
"confidence": 1.0,
"passed_health_check": True,
"business_success": True,
},
]
patterns = defaultdict(lambda: {
"sessions": [],
"severity_total": 0,
"confidence_total": 0.0,
})
for session in sessions:
silent_failure = (
session["passed_health_check"]
and not session["business_success"]
and session["pattern"] is not None
)
if not silent_failure:
continue
item = patterns[session["pattern"]]
item["sessions"].append(session["session_id"])
item["severity_total"] += session["severity"]
item["confidence_total"] += session["confidence"]
ranked = []
for name, item in patterns.items():
count = len(item["sessions"])
avg_severity = item["severity_total"] / count
avg_confidence = item["confidence_total"] / count
impact_score = count * avg_severity * avg_confidence
ranked.append({
"pattern": name,
"count": count,
"impact_score": round(impact_score, 2),
"sessions": item["sessions"],
})
ranked.sort(key=lambda row: row["impact_score"], reverse=True)
for index, row in enumerate(ranked, start=1):
print(
f"{index}. {row['pattern']} "
f"score={row['impact_score']} "
f"sessions={','.join(row['sessions'])}"
)
运行命令：
python analyze_agent_failures.py
预期输出：
1. wrong_refund_amount score=9.65 sessions=s-001,s-002
2. claimed_success_after_tool_rejection score=3.6 sessions=s-003
这个原型有意把“系统是否健康”和“业务是否成功”拆成两个字段。没有这层区分，静默失败会被成功请求淹没，后续分析也就失去了入口。
让诊断结果能够指导修复
发现模式之后，团队还需要把解释落到可修改的组件上。常见的定位路径包括：
- 工具选择错误：检查工具描述是否重叠，提示词是否提供了明确选择条件。
- 参数提取错误：增加结构化输出约束，并在执行前做类型、范围和业务规则校验。
- 工具结果被误读：要求最终回复引用结构化执行状态，禁止仅依据自然语言猜测成功与否。
- 缺少澄清步骤：为订单号、金额、身份等关键字段设置必填条件。
- 多步骤任务中途偏离：记录计划、每步结果和终止原因，以便识别偏离发生在哪一步。
修复后不要只重跑一条示例。应把该模式下的历史失败会话整理成回归集，同时加入相似但本来成功的会话，避免修复一个问题后破坏正常路径。
上线前后的采用清单
引入 AgentCore optimization 或类似的行为分析机制时，可以按以下顺序推进：
- 为高价值任务定义可验证的业务成功条件，而不是依赖模型自评。
- 统一记录会话 ID、用户目标、模型决策、工具调用、工具结果和最终答复。
- 对敏感字段做脱敏，并设置日志保留期限和访问权限。
- 先覆盖退款、支付、权限变更等高风险流程，再扩展到低风险问答。
- 按影响范围、严重度和置信度排列失败模式。
- 将已确认模式转化为离线评测与发布前回归测试。
- 修复后持续观察模式发生率，而不是只确认代码已经部署。
边界也要明确：模式聚类和自动解释可以加快定位，但不能天然证明根因。低置信度模式需要人工抽样复核；涉及资金、安全或合规的操作，还应保留确定性校验和人工审批。真正可靠的智能体运维，需要把 AgentCore optimization 提供的跨会话洞察，与业务断言、回归评测和变更管理结合起来。