系统告警出现后，工程师往往还不能立即修复问题，而要先在日志、服务状态、代码和内部文档之间寻找线索。AWS 11月2日披露，便利零售企业Circle K使用Amazon Bedrock构建AI事件分诊系统，把这段重复的信息搜集与初步分析过程自动化。

Circle K在27个国家运营超过1.72万家便利店和燃油零售门店，云端系统支持收银、会员和电动汽车充电等应用。随着服务数量增加，告警后的人工调查通常需要45—60分钟，工程师要依次查看CloudWatch日志、OpenSearch应用跟踪、ECS任务状态，并与GitHub中的运行手册和代码进行交叉核对。

多个智能体并行收集事件上下文

早期方案使用Amazon Bedrock Flows协调专业智能体。一个智能体检查跨账户的AWS资源、容器任务、负载均衡健康度和监控指标；另一个智能体查询OpenSearch中的应用日志与分布式跟踪，并从知识库获取服务依赖信息。

前两部分完成后，GitHub智能体根据已经发现的错误和组件范围，搜索相关代码仓库、基础设施定义与近期提交。最后，分析节点汇总三部分结果，生成固定格式的说明，包括可能的根因、支持证据、受影响服务、责任团队和建议措施，并发送到Slack。

从Flows迁移到AgentCore应对更长调查

随着日志量和调查上下文增加，部分事件需要更长时间处理。Circle K随后把流程迁移到Amazon Bedrock AgentCore Runtime，把原有步骤合并到一个可保持会话状态的智能体中，并通过AgentCore Gateway集中管理对OpenSearch、知识库和GitHub等数据源的访问。

官方案例称，系统从告警到生成Slack摘要通常耗时5—15分钟。AgentCore版本在2026年4月投入生产后，平均分诊时间由45—60分钟降至15分钟以内，按团队内部事件响应指标计算，降幅约为67%—75%；简单事件可在5—8分钟内形成摘要。

速度提升不等于自动执行修复

目前系统主要负责寻找可能根因和建议措施，真正的修复仍由工程师执行。Circle K计划进一步接入简单的重启、扩容或回滚操作，但仍要求工程师在Slack中批准后才运行。这一边界非常关键，因为日志相关性并不等于因果关系，错误的自动修复可能扩大故障。

案例还强调了几个工程经验：把相关日志内容直接交给模型，比只提供日志位置更有效；先通过基础设施和日志缩小范围，再搜索代码；并把分析逻辑与编排层分离，以便在底层运行平台变化时复用。

编辑观察：AI先承担信息搜集，人继续承担运维判断

Circle K案例说明，运维智能体最现实的价值不是完全替代工程师，而是先承担跨工具的信息搜集、整理和初步关联，让人在更完整的上下文中判断。企业可以从只读访问和建议模式开始，记录根因命中率、人工纠正率、分诊时间和误报情况，再决定是否开放有限的执行权限。

文中的时间改善与百分比来自Circle K团队内部指标和AWS官方客户案例，不应直接视为所有企业都能获得的通用结果。不同系统的日志质量、服务依赖复杂度和知识库完整性，都会显著影响智能体表现。

配图为AIcent原创AI生成实景风格示意图，非官方新闻现场照片，不使用第三方新闻图片。

参考来源：AWS Machine Learning Blog（2026年11月2日）。正文为基于官方消息的中文整理，编辑观察与事实披露分开呈现。