Circle K云DevOps工程师Marek Klatowicz：预查询日志再交给Agent，比让Agent自行调API更有效

Circle K运营着27个国家超过17200家便利店和加油站，其云原生基础设施支撑着POS系统、忠诚度应用和电动车充电服务。当这些数字服务出现告警时，值班工程师过去需要45到60分钟在CloudWatch日志、OpenSearch链路追踪、ECS任务状态和GitHub运行手册之间来回切换，才能搞清楚发生了什么。Cloud DevOps工程师Marek Klatowicz与AWS联合撰文记录了他们如何用Agentic AI消除这段重复劳动。

系统的第一版基于Amazon Bedrock Flows编排三个专用Agent并行和串行工作：AWSResourceExplorerAgent检查基础设施状态，OpenSearchExplorerAgent拉取应用日志和分布式追踪，两者完成后GitHubExplorerAgent再搜索代码仓库定位根因。最后一个AnalysisPrompt节点汇总三路输出，生成包含根因、证据、责任团队和修复建议的结构化摘要，推送到Slack。整个流程5到15分钟完成。但Klatowicz在经验教训部分明确指出，第一版让Agent自己通过action group去查询CloudWatch日志，结果既增加了延迟，又经常返回超出处理能力的数据量。真正有效的做法是让Lambda函数预先查询日志，把相关错误行直接放进Agent的提示词里——Agent读到实际错误信息时推理更快。

随着数据量和知识规模增长，Flows架构遇到了硬约束：某些复杂事件需要的分析时长超出了单个Flow节点能完成的范围。团队先尝试在现有设计内优化——更激进地过滤日志、缩短上下文窗口、拆分服务到独立Flow——这些措施有帮助但不够。迁移到AgentCore Runtime后，完整调查在单一会话中运行，支持长达8小时的session，每一步可以按数据需要分配时间。三个专用Agent被合并为一个运行在AgentCore Runtime中的单一Agent，AgentCore Gateway统一管理对OpenSearch、Knowledge Bases和GitHub的工具访问。

Klatowicz认为支撑这次迁移的关键不是AgentCore本身的功能，而是一个更早的架构决策：团队始终将提示词、工具定义和分析步骤与Flow结构保持分离。这意味着从Flows切换到AgentCore时不需要重写分诊逻辑，只需要改变运行方式。他同时强调搜索顺序的设计：GitHub搜索必须在AWS资源和日志分析之后运行，因为此时Agent已经知道要查找哪个错误、哪个组件或哪次近期变更；如果一开始就无目标地搜索仓库，返回的结果多到无法使用。

需要指出的是，文中所有性能数据——平均分诊时间从45-60分钟降至15分钟以内、简单事件5-8分钟出摘要——均为Circle K内部事件响应指标的自报结果，未经独立验证。本文由AWS机器学习博客与Circle K工程师联合撰写，AWS作为平台提供商有展示成功案例的商业利益。文中未披露分母（同期事件总量变化）、未说明是否存在选择效应（是否复杂事件仍依赖人工），也未提供迁移前后的对比实验设计。

目前系统仍停留在'找到根因并推荐修复，工程师执行修复'的阶段。团队计划下一步集成AWS DevOps Agent实现简单自动修复（重启任务、扩容、回滚部署），每个操作在Slack中由工程师审批后执行。同时计划接入Jira关联工单、Confluence补充内部文档、将运行手册纳入知识库以匹配已知故障模式。