一条告警响起，工程师真正缺的往往不是另一条猜测，而是散落在监控、应用日志和代码仓库里的证据。Circle K在11月2日公开的技术复盘中，介绍了如何让AI先做这轮信息整理，再把可能原因、服务归属与修复建议交到Slack里。值得注意的是，这套系统不是刚刚上线的新产品：迁入AgentCore的生产部署发生在今年4月，本次披露的是架构演进与交付经验。

快速看点：先查运行状态，再定向查代码；从多个智能体串并联，迁到单智能体会话；当前仍由工程师执行修复。文章由Circle K云端DevOps工程师参与共署，提供了具名企业的流程细节，但没有完整公开统计样本和对照条件，本文不采用其中的提速百分比或成本收益数字。

第一步不是猜答案，而是缩小搜索范围

最初的入口沿用现有告警链路：Grafana经SNS、SQS触发Lambda，再交给Bedrock Flows。流程并行启动两个专职智能体，一个检查跨账户AWS资源及相关指标、日志，另一个搜索OpenSearch中的应用日志与调用轨迹。后者还能够利用产品知识卡，理解系统之间的依赖关系，避免只看单台机器。

这两路调查形成线索后，GitHub智能体才进入代码与基础设施仓库，检查相关实现和近期提交。顺序很重要：它不是拿着一句宽泛的报错去遍历全部代码，而是根据日志与资源调查收窄范围。这样做减少无关材料，也让后续判断能对应到具体证据，而不是把检索条数当成调查质量。

最后的分析提示只进行一次模型调用，不再使用工具，把已收集内容整理成可能原因、证据、责任服务和建议措施，再由Lambda发送到Slack。这里的“可能”不能省略：系统提供的是帮助定位的判断，不是已经证明的根因，更不是已经执行的修复回执。工程师需要检查证据、决定行动并确认服务状态。

为什么又从多智能体迁回单会话

旧流程运行数月后，压力主要来自待处理数据和上下文增长，而不只是服务数量增加。团队先尝试过滤日志、缩短上下文和拆分流程，之后把容器化智能体迁到AgentCore Runtime，并把原来三个智能体的职责合并进一个会话，保留资源、日志、代码和最终分析的调查步骤。迁移的核心是编排方式变化，不是把原有排查方法推倒重来。

新的Gateway承接OpenSearch、知识库和GitHub等工具入口，集中处理工具连接与访问控制；Lambda负责启动、等待结果和向Slack交付。Runtime会话帮助保存本轮调查的中间上下文，OpenTelemetry轨迹进入CloudWatch，便于检查工具调用与模型步骤。不过，会话环境仍有生命周期，不能把会话内记忆写成永久保存，也不能推断任务中断后一定无损续接。

对企业团队而言，这个选择说明智能体数量并不是架构成熟度指标。并行分工适合隔离不同的信息检索，单会话则可能减少交接与上下文搬运。哪一种更合适，取决于任务依赖、工具权限、可观测性和失败后能否解释，而不是流程图上有多少个Agent方框。

可复用的经验，藏在材料怎么交给模型

复盘中一个具体调整，是让Lambda先筛出与告警相关的日志行，把实际内容放进提示，而不只给模型日志组名称和时间范围。否则，工具可能返回过多数据，拖慢后续分析。另一个经验是先用日志形成线索，再定向检查代码；知识检索与提示参数也要结合企业自己的数据调试，不能把该团队使用的默认设置当成通用最优解。

团队还尽量让提示、工具和分析逻辑独立于编排框架，因此可以在迁移运行环境时复用调查能力。企业照此实施，仍需要单独整理服务归属、产品依赖和日志字段，明确工具可以读什么、调用身份是谁，以及证据如何留存。Gateway提供集中入口，并不等于业务授权自动齐备；跨账户调查也不代表可以无限读取所有账户数据。

这仍是一份具名客户与供应商共同披露的生产经验，不是可直接复现的完整开放基准。本站核对了公开复盘及Runtime、工具接入文档，没有运行其生产代码、调用模型或进入客户环境。文章中的示例调查不能被放大成所有故障都能定位的证明，告警遗漏、日志缺失和模型误判也需要独立测试与人工兜底。

小编判断

这次案例最值得借鉴的，是把AI放在“整理证据、减少交接”的位置。重启、扩容、回滚，以及经Slack由工程师批准的自动操作，在复盘中仍属于后续规划；Jira、Confluence和更多运行手册接入同样不能提前写成现有能力。上线验收应分别检查证据完整度、判断正确性和修复是否完成，而不是看到一份漂亮报告就结束工单。先让交接可信，再逐步扩大执行权限，才是更有价值的落地路径。