服务器 200、香港节点延迟正常、页面也打开了，但“加入购物车”的图层被遮住，用户仍然无法下单。这就是合成监控要解决的缺口：不只监控组件，而是按真实用户路径定期完成一次任务。
AWS 9 月 28 日发布一套 Amazon Nova Act 与 Bedrock AgentCore 实现：EventBridge Scheduler 定时启动，AgentCore Runtime 托管执行，Browser 工具为每次运行提供隔离浏览器，Nova Act 根据截图和自然语言执行动作，失败后通过 SNS 通知。官方样例代码已公开，典型 6 步旅程依页面加载情况需 2—4 分钟。
传统 Selenium 脚本常把 class 或 XPath 当成真相，界面重构就会大面积误报。Nova Act 用多模态大模型处理截图，官方说早期企业案例中浏览器流程准确率超过 90%。这是厂商案例，不是一条对所有网站的承诺；Agent 也会看错、点错，因此必须把“动作”和“结果断言”分开。
最小实践：别让一次模型抖动直接升级为事故
from dataclasses import dataclass
@dataclass
class Step:
name: str
ok: bool
ms: int
def assess(run):
required = {"search", "cart", "checkout"}
seen = {step.name for step in run if step.ok}
return required <= seen and sum(step.ms for step in run) < 10_000
runs = [
[Step("search", True, 800), Step("cart", True, 900), Step("checkout", True, 1200)],
[Step("search", True, 700), Step("cart", False, 1100), Step("checkout", False, 0)],
[Step("search", True, 750), Step("cart", False, 1300), Step("checkout", False, 0)],
]
results = [assess(run) for run in runs]
alert = len(results) >= 2 and results[-2:] == [False, False]
print("results=", results, "alert=", alert)
assert alert
保存为 journey_gate.py，用 Python 3.9+ 直接运行，无第三方依赖。代码不只要求三个关键结果全部出现，还限制总时间，并在连续两次失败后才告警。本次在 Python 3.9.6 实际运行，结果为 [True, False, False]，告警断言通过。这只验证状态与告警逻辑；本次没有 AWS 凭据，未实际运行 Nova Act 或 AgentCore。
真实实现中，每次旅程应使用新会话，避免 cookie、LocalStorage 或购物车残留让测试“假通过”。AWS 文档说 AgentCore Runtime 采用一会话一 Firecracker microVM，合成监控推荐临时会话。身份凭据放 Secrets Manager，运行角色只给打开浏览器和发告警的最小权限，监控账号不应有真实支付能力。
最常见的误区有三个：把“点了按钮”当成“结果正确”；为降低误报而无限重试，最终把真故障拖成数分钟后的延迟告警；只在一个地域运行，却宣称全球用户旅程正常。每个告警应保留失败步骤、截图或视频、总时间、会话 ID 和模型版本，但要对账号、地址和支付信息脱敏。
这套方法适合视觉改动频繁、选择器维护成本高，且业务结果可明确断言的流程。对于稳定 API、简单健康检查或每秒高频探测，传统脚本更快、更便宜、更可预测。我的判断是，Agent 监控不会替代指标、日志和追踪，它是第四层证据：用户真的能完成任务。
要让告警真的可处置，每个关键步骤要有独立的结果断言。搜索成功不是“输入框被点了”，而是页面出现与关键字相关的结果；加购物车成功不是“按钮消失”，而是购物车数量、商品标识与价格一致；结账就绪不是真正提交付款，而是到达明确的安全停止点。如果断言只复述 Agent 自己的动作说明，整个监控会变成模型给自己打分。
为了区分产品故障和 Agent 抖动，可以给相同旅程设置两类对照。一类是传统 API 或页面元素探针，用来证明后端基础能力；另一类是 Agent 旅程，用来证明真实交互。如果 API 正常、Agent 失败，优先检查界面、模型或提示词；如果两者都失败，更可能是真实业务事故。这种对照能显著缩短排查路径。
告警策略也不是越灵敏越好。支付页面可以每五分钟检查并在连续两次失败后告警，但一个每日才执行的报表流程，连续两次就意味着24小时的发现延迟。门槛要根据业务损失速度、模型单次失败概率和执行成本共同定义。对高价值旅程，可以在第一次失败后立即用另一个地域或不同测试账号复核，而不是无上限原地重试。
成本不能只看 EventBridge 的调度费用。AWS 示例将定时调用、Runtime会话、Browser会话、Nova Act 操作和通知分开估算。团队还应计入每次旅程的平均步数、重试次数、多地域倍数、证据存储和人工处置。一个月运行数千次的任务，即使单次不贵，也可能在重试与视频证据上累积出不小账单。
上线前最好做一次人为故障演练。例如临时隐藏购物车按钮、让价格接口返回错误币种、制造缓慢加载，检查 Agent 是否在正确步骤停止，告警是否附带足够证据，值班人能否不登陆生产账号就确认问题。如果 Agent 在首个关键断言失败后仍尝试后续结账，说明流程将“完成任务”错误地置于“可安全失败”之上。
还要定期复查监控自身的漂移。页面文案、商品数据和 Agent 模型会更新，去年有效的断言可能今天已经过宽或过窄。团队应保存一小组已知成功与已知失败录像，每次升级提示词、模型或浏览器镜像后先回放，确认告警敏感度没有静默变化。
你的线上监控能证明页面打开，还是能证明用户真的完成了任务？
关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn，转载请注明出处。
