Circle K 用 Agent 缩短故障初步排查

Circle K 把故障初步排查从 45–60 分钟压到平均不足 15 分钟，靠的不是让 AI 接管生产环境，而是让它先收集日志、检查资源、查代码，再把证据交给值班工程师。团队内部指标显示，耗时下降了 67–75%。

这篇案例值得看的是整条调查链如何组织，以及为什么后来从多个 Agent 迁到单个 Agent。对维护 Node 服务、全栈应用的团队，它提供了一套可参考的排查流程，但这些数字还不足以证明 AI 已经能可靠地自动修复故障。

省下的时间，主要花在收集证据上

Circle K 在 27 个国家经营超过 17,200 家便利店和加油零售门店，AWS 上的系统支撑收银、会员和电动汽车充电业务。服务多了，告警之外的调查工作也跟着增加。

他们用 Grafana 监控多个 AWS 账户。容器重启、错误率升高、延迟突增、部署失败，都会触发告警。工程师随后需要去 CloudWatch 查日志、去 Amazon OpenSearch Service 看应用日志和分布式追踪、检查 Amazon ECS 任务，再到 GitHub 对照内部运行手册。

这些动作重复率高，还依赖值班人员对服务的熟悉程度。团队因此把目标定为自动整理上下文、输出结构化发现，保留工程师的判断和修复职责。

这个案例压缩的是故障初步排查时间，不是故障恢复时间。

选择 Amazon Bedrock 也有明确前提：Circle K 已经运行在 AWS 上，可以沿用 IAM、VPC 和日志体系。相比他们评估过的自管开源 Agent 方案，托管服务减少了模型托管、工具编排和安全控制的维护工作。Amazon Bedrock Knowledge Bases 则负责检索增强生成（RAG），也就是先找内部资料，再让模型结合资料分析，无需另行维护向量数据库。

原文还将 Bedrock 不向模型提供商共享客户数据、不使用客户数据训练基础模型，列为满足其安全要求的原因。这是他们的选型依据，不能替代其他团队自己的数据处理评估。

为什么先查日志，再让 Agent 搜代码

第一版系统用 Amazon Bedrock Flows 编排，入口是一条清晰的消息链：

Grafana → Amazon SNS → Amazon SQS → AWS Lambda → Flow。

Flow 先并行调用两个 Agent。AWSResourceExplorerAgent 跨 AWS Organizations 管理的业务账户，检查 ECS 任务、Application Load Balancer 目标健康状态，以及 CloudWatch 指标和日志。

OpenSearchExplorerAgent 则查询应用日志和分布式追踪，并独占知识库访问权限，检索描述服务及其依赖的产品卡片。单独拆出它，是因为 OpenSearch 返回的数据量大，需要控制每个 Agent 的上下文大小。

等这两路调查完成，GitHubExplorerAgent 才搜索相关仓库、应用代码、基础设施定义和近期提交。它此时已经拿到了错误和组件线索，搜索范围会小得多。

最后，AnalysisPrompt 节点做一次不附带工具的模型调用，将三路结果整理成可能根因、证据、服务及负责人、建议操作。Lambda 再把摘要发到 Slack，工程师可以在 2 分钟内扫完。第一版从告警到消息通常需要 5–15 分钟。

原文用一个例子解释这条链：某服务 HTTP 5xx 错误率连续 3 分钟超过 5%。资源检查发现连接池耗尽，日志出现连接 PostgreSQL 时的「connection refused」，代码搜索发现服务每次请求都新建数据库连接。分析节点再关联到告警前 10 分钟启动的营销活动，形成以下消息：

Summary: XYZ Service 5xx errors caused by connection pool exhaustion
Root cause: Scheduled marketing campaign drove traffic spike; connection pool max (50) insufficient for load
Evidence: OpenSearch logs show "connection refused" at 14:32 UTC; ECS shows 3 task restarts since 14:30
Owner: XYZ team (backend)
Next steps: Add Amazon RDS Proxy to pool connections, or update the service to reuse existing connections instead of opening a new one per request; consider an Auto Scaling rule for future campaigns

要关注 Evidence 和 Next steps 两行：摘要应当让人能核对证据，也能看到下一步选项。不过，原文没有交代营销活动信息从哪里进入系统，这个关联过程仍有缺口。

迁到单个 Agent，解决的是调查过程越来越长

Flows 版本运行了数月，简单故障可以在 10 分钟内完成排查。后来服务集合没有变化，日志量和调查上下文却持续增长，部分任务超出了单个 Flow 节点能够完成的范围。

团队先尝试更严格地过滤日志、缩短上下文窗口、把部分服务拆到独立 Flow。有效，但没有消除增长压力。

随后，他们将 Agent 逻辑容器化，迁到 Amazon Bedrock AgentCore Runtime，2026 年 4 月投入生产。原先三个专业 Agent 合并成一个 Agent，在同一会话中继续完成资源检查、日志查询、代码搜索和知识库检索。AgentCore Gateway 把数据源统一暴露为工具，集中管理访问控制。

Runtime 支持最长 8 小时会话，但当前系统仍由 Lambda 发起调查、等待结果并发送 Slack 消息，Agent 要在 Lambda 最大超时限制的 15 分钟内返回。

Runtime 能运行 8 小时，不代表这条同步调用链也能等待 8 小时。

迁移带来的另一个收益是保留调查中间状态。第一次查日志发现线索后，Agent 可以继续定向查询，不必丢掉前面的上下文。OpenTelemetry 追踪通过 CloudWatch 展示每步耗时、知识库查询和瓶颈，帮助团队调整提示词；容器化部署也让框架和调查步骤更容易变更。

生产数据方面，团队报告简单故障在 5–8 分钟收到摘要，复杂多服务故障在 15 分钟内完成初步排查，后者此前人工处理可能超过一小时。

原文给出的几条实施经验，比选择几个 Agent 更实用：

• 先由 Lambda 查询日志，把相关日志正文直接放进提示词。早期只提供日志组名称和时间范围，再让 Agent 通过 action groups 查询 CloudWatch，延迟更大，也容易拿回过多数据。
• 用日志发现缩小代码搜索范围，避免没有线索就遍历仓库。
• 把提示词、工具定义和调查步骤从编排结构中拆出来，让迁移执行平台时可以复用。
• 分别调整检索与生成。团队测试后认为知识库默认配置最适合自己的数据，但没有提供检索对照结果，也没有公布模型名称和具体 temperature 值。

我的判断

我认可它把 AI 放在证据收集与整理环节。相比直接要求模型判断根因，这套流程先拿到资源状态、日志和代码，再生成摘要，工程师有机会沿证据复核。统一输出也有助于跨团队升级处理，不必重新口述一遍调查经过。

但 67–75% 来自团队内部指标。原文没有公布样本量、统计周期、故障类型分布，也没有提供根因判断正确率、误报漏报率和单次成本。这能支持「他们的初步排查变快了」，还不能支持「任何团队接入都会得到相同收益」。

这里也缺少与规则查询、固定排查脚本的对照。对于服务和故障类型比较固定的团队，预设日志查询加运行手册匹配，也可能省掉不少操作。AI 是否值得加入，应看剩余工作需要多少跨来源关联判断，而不是只看告警数量。

同样，多 Agent 变成单 Agent 并不能证明后者普遍更好。此次迁移针对的是调查时长、状态保留和运行方式，原文没有做两种架构的效果对比。

当前系统仍由工程师修复。接入 AWS DevOps Agent、执行任务重启、扩容和部署回滚，以及增加 Jira、Confluence、运行手册，都是后续计划；计划中的修复动作会先在 Slack 获取工程师批准，不能算作已经落地的能力。

能拿来做什么

• 如果 Node 或全栈服务的值班时间大量花在切换工具上，先把一次告警所需的日志片段、资源状态、服务依赖和负责人整理成固定摘要，再评估哪些关联分析需要模型完成。
• 设计代码检索时，先从日志里提取错误、组件和时间线，再搜索相关仓库、基础设施文件及近期提交，让每次搜索都有明确线索。
• 把调查步骤与执行平台分开维护，并记录各步骤耗时。以后从固定工作流迁到持续会话时，可以保留查询和分析逻辑，同时检查入口函数的超时限制。
• 试点时同时记录排查耗时、工程师采纳情况、根因判断正确率和调用成本，避免只凭 Slack 消息生成速度判断系统是否有效。