AWS DevOps Agent实战：故障调查与成本透明化

一份亲手实践的现场报告：真实账号、真实事故、真实调查输出——根据 CloudWatch 对每一项结论逐条评分，包括该智能体判断错误的两件事。

为什么还要再写一篇 DevOps Agent 文章

AWS DevOps Agent 到底是什么

你需要掌握的五个名词：Agent Space、Topology、Skills、Journal、Goal

启用之前就能预估的定价

实验环境：一个经过刻意设计、能够以可诊断方式失败的无服务器订单 API

20 分钟完成接入——以及四个容易踩坑的地方

将告警接入智能体：两种路径，以及该选哪一种

故意破坏生产环境：按分钟还原事故过程

证据链：智能体实际上能利用哪些信息

向智能体提问——以及它拒绝回答的那一刻

逐条评估调查结论

第二个根本原因，以及它证明了什么

读取智能体的思考过程：通过 API 查看审计日志

修复问题，以及预防措施应该为你带来什么

闭环：EventBridge、工单、Slack，以及向 Kiro 的移交

让智能体真正为你所用：技能、指令、触发器、自定义 SRE 智能体

这次实验花了多少钱，以及如何拆除环境

附录：可直接复制粘贴的检查清单

1. 为什么还要再写一篇 DevOps Agent 文章

大多数关于 AWS DevOps Agent 的文章都遵循相同的套路：引用“MTTR 最多降低 75%”这一数字，贴一张架构图，展示一张根本原因分析的截图，然后得出值班问题已经解决的结论。

也有一些例外值得你花时间阅读。AWS Networking & Content Delivery 和 Security 博客提供了相当不错的实践教程：部署一个存在故障的工作负载，将 CloudWatch 告警接入智能体，然后逐步演示真实场景。我会在 §7 中引用这些文章，而不会假装这条路径是我首先发现的。

但这些文章都是从外向内写的：这是功能，这是它运行时的样子。本文则从内向外展开——回答你在周一上午 09:00 被要求评估它时真正会遇到的问题：

接入过程中会在哪些地方出问题？

我的告警是 CloudWatch alarms。它们如何传递给智能体？（目前没有原生触发器。AWS 提供了两种不同桥接方案的示例，而且它们并不等价——见 §7。）

我如何判断它确实在工作，而不是只静静地待在那里？

每起事故究竟要花多少钱？

当它的根本原因分析出错时，我该如何发现？

最后一个问题，正是本文存在的原因。我构建了一个经过专门设计、会因多个看似合理的原因而失败的应用，将它弄坏，然后把事故现场交给智能体，并用 CloudWatch 核对它给出的每一个数字。它的最终结论是正确的，但对两个机制细节的判断有误——其中一个错误会让工程师去寻找一个根本不存在的配置项。

以下所有内容都来自 2026 年 7 月 31 日位于 us-west-2 的一个真实 AWS 账号。每个时间戳、容量数字和错误计数都直接复制自 CloudWatch 或智能体自己的输出。没有任何内容是重构或虚构的示例。账号 ID、Agent Space ID 和 API ID 分别被隐去为 <account-id> 和 <agentSpaceId>；除此之外，所有内容均为原文记录。

2. AWS DevOps Agent 到底是什么

AWS DevOps Agent 于 2026 年 3 月 31 日正式发布，此前曾在 re:Invent 2025 上宣布预览版。它是 AWS“前沿智能体”之一——该产品家族还包括 Kiro 和安全测试智能体——并构建于 Amazon Bedrock AgentCore 之上，拥有专用于记忆、策略、评估和可观测性的基础设施，而不是仅仅在模型外面套一层薄封装。

它分为两部分。

生产运维（正式可用）。这是目前真正值得你关注的部分。

发布管理（预览版，仅限 us-east-1）。包括发布就绪评审和自主发布测试——它会在合并前评审变更的影响范围和权限扩张情况，然后生成针对该变更的测试，而不是运行一套静态测试。预览期间免费。确实很有意思，但应该单独评估：所在区域不同，成熟度也不同。

运行区域。撰写本文时共支持 11 个区域：us-east-1、us-west-2、ca-central-1、sa-east-1、ap-south-1、ap-southeast-1、ap-southeast-2、ap-northeast-1、eu-central-1、eu-west-1、eu-west-2。

一个容易被忽略的要点：无论 Agent Space 本身位于哪个区域，它都可以监控关联账号中任意区域的资源。选择 Agent Space 区域时，应考虑数据驻留要求和团队所在位置，而不是让它与工作负载保持一致。你不需要为每个区域都创建一个 Agent Space。

它与你已有工具的区别

与 Amazon DevOps Guru 相比——DevOps Guru 做的是基于机器学习的异常检测：它从指标、日志、事件和跟踪数据中学习正常运行边界，然后标记偏差，并将其聚合成洞察。DevOps Agent 做的则是调查：它提出假设，查询日志、代码和部署历史来验证这些假设，最后写出包含缓解方案的结论。一个负责检测，一个负责诊断。两者承担的工作不同，实际重叠比它们的名字所暗示的更少。

与你的编码智能体加 CloudWatch MCP 服务器相比——这是一个坦诚的比较，而答案在于上下文和治理。如果你完成相应接线，编码智能体也能查询 CloudWatch。它做不到的是：维护一个持续刷新的跨账号拓扑；无需每位工程师单独配置就能与整个团队共享该拓扑；使用 IAM 边界限制智能体可以接触的内容；或者为每一个推理步骤保留不可篡改的审计日志。§12 会通过一个具体示例说明这为什么重要。

与 SRE 相比——它不是替代品。它是一个从不睡觉、速度极快，但你仍然必须检查其结论的第一响应者。见 §11。

3. 你需要掌握的五个名词

跳过这些概念，文档读起来就会像一团迷雾。

Agent Space——一个逻辑容器，用于定义智能体能够看到什么：哪些 AWS 账号、哪些第三方工具、哪些 MCP 服务器、哪些用户。隔离是实实在在的：通过专用 IAM 角色实现 AWS 账号隔离，同时还有用户访问隔离和数据隔离——调查、聊天记录和建议不会在不同空间之间泄露。可以为生产与非生产环境分别创建空间，或者按业务部门划分空间。

Topology——自动发现的资源关系图。后台学习智能体会扫描基础设施、遥测数据和代码，以推断应用及服务边界。在我的账号中，它仅根据 CloudFormation 堆栈边界就正确地将资源归入了不同应用，并明确将 CDKToolkit 和 aws-sam-cli-managed-default 作为脚手架排除。这正是“我能够查询 CloudWatch”与“我知道这个系统是什么”之间的区别。

Skills——模块化的 Markdown 指令集，是开放 Agent Skills 规范的一种实现（仅支持不可执行文件：Markdown、PDF、图片和数据）。分为三个层级：

• AWS 提供——内置并由 AWS 维护

• 用户定义——由你提供；包括运行手册、标准、关联规则和跳过规则

• 学习生成——智能体根据你的环境和过去的调查自行编写

每个技能都有包含名称和描述的 frontmatter，而描述承担着关键作用：智能体通过阅读描述来判断是否启用该技能。"RDS skill" 会被忽略。"Use this skill when investigating database latency, connection errors, or query timeouts for Amazon RDS instances" 则不会。

Journal——每次执行中所有消息、工具调用和推理步骤形成的不可篡改、只能追加的记录。智能体无法重写它。这既是你的审计轨迹，也是 §13 所展示的、唯一真正可用的调试工具。

Goal——按计划执行的目标。每个新空间都会默认获得一个目标：一个按照 rate(7 days) 运行的 ONCALL_REPORT 目标，用于生成包含预防建议的每周事故后分析报告。

4. 启用之前就能预估的定价

只需记住一个数字：每智能体秒 0.0083 美元，按秒计费，适用于所有三种类别（调查、评估和按需 SRE 任务）。空闲时间不收费，也没有承诺消费。

换算下来是每智能体分钟 0.50 美元，因此很容易心算：

一个每月进行 10 次调查的小团队：约 40 美元。一个每月进行 80 次调查并发起 100 次聊天的活跃团队：约 344 美元。按照 AWS 自己的示例，企业规模约为 2,366 美元。

可以免费获得的额度，按值得关注的程度排序：

AWS Support 抵扣额度。如果你订阅了付费支持计划，每月可以获得一定比例的 DevOps Agent 抵扣额度，其金额根据上个月的支持费用计算：Unified Operations 为 100%，Enterprise 为 75%，Business Support+ 为 30%。额度会在每月 10 日前发放，只能在当月使用，并于月末过期。对许多 Enterprise Support 客户来说，这实际上让 DevOps Agent 变成了免费服务。在从头构建商业论证之前，先检查这一项。

面向新客户的两个月免费试用，从第一次执行运维任务开始计算：每个试用月最多支持 10 个 Agent Space、20 小时调查、15 小时评估以及 20 小时按需任务。

新 AWS 客户可通过 AWS Free Tier 免费计划获得相应额度。

发布管理在预览期间免费。

定价页面上没有列出的成本：智能体会间接增加你的 CloudWatch 账单。它执行的每一次 Logs Insights 查询和跟踪数据检索，都会按照 CloudWatch 的标准费率收费。对于日志量很大的日志组，这笔费用不容忽视。请将其纳入预算。

随时检查你自己的用量：

aws devops-agent get-account-usage --region us-west-2

{
  "monthlyAccountInvestigationHours":   { "limit": -1, "usage": 0.0 },
  "monthlyAccountEvaluationHours":      { "limit": -1, "usage": 0.0 },
  "monthlyAccountSystemLearningHours":  { "limit": -1, "usage": 0.0 },
  "monthlyAccountOnDemandHours":        { "limit": -1, "usage": 0.0 },
  "usagePeriodStartTime": "2026-07-01T00:00:00+00:00"
}

limit: -1 表示未配置上限。注意第四个类别：系统学习时长单独计量，而且无论是否发生过事故，后台学习智能体都会运行。

实际测量下来，这篇文章花了多少钱

以下是完成第 10 节中的聊天会话和第 11 节中的调查后，实际的计量数据：

其中有两件事令我意外，而且都值得提前纳入规划。

对话的成本是调查的 3.3 倍。所有定价示例——包括 AWS 自己的示例——都把调查作为计费单位。实际运行中，调查持续了 3.2 分钟，远低于定价页面采用的 8 分钟，而在此之前寥寥几个聊天轮次却消耗了 10.5 分钟的智能体时间。聊天给人的感觉像是免费的，因为每次回复都很快；但它并不免费，而且成本会悄无声息地累积。如果你把它推广给整个团队，最终让你意外的账单项目将是 monthlyAccountOnDemandHours，而不是调查。

调查可能比你预算的更便宜。这次调查只用了 3.2 分钟，成本还不到一杯咖啡，却关联了四项服务，并还原出一条包含两个原因的故障链（第 11 节）。如果成本是让你对使用调查功能犹豫不决的因素，那么实际数字很可能比你直觉中的要小。

查看自己的计量数据时有一点需要注意：用量会在每个自然月重置，usagePeriodStartTime 会告诉你当前查看的是哪个周期。我的事故发生在 UTC 时间 7 月 31 日深夜，而调查落在了 8 月 1 日，因此两者出现在不同的计费周期中——如果只检查其中一个周期，很容易误读成“没有产生账单”。

要评估一个调查智能体，你需要一场存在不止一个合理原因的事故。一个在第 12 行抛出 KeyError 的 Lambda 说明不了什么——任何日志搜索都能找到它。我想要的是一种症状和原因分布在不同服务中的故障。

              POST /orders
                   │
        ┌──────────▼──────────┐
        │  API Gateway HTTP   │   access logs → CloudWatch
        │   API (prod stage)  │
        └──────────┬──────────┘
                   │
        ┌──────────▼──────────┐
        │  Lambda             │   X-Ray tracing on
        │  devops-lab-orders  │   structured JSON logs
        │  arm64, py3.13      │   env: WRITE_FANOUT
        └──────────┬──────────┘
                   │
        ┌──────────▼──────────┐
        │  DynamoDB           │   PROVISIONED
        │  devops-lab-orders  │   1 RCU / 1 WCU   ← the trap
        └─────────────────────┘

4 CloudWatch alarms ──► SNS ──► Lambda bridge ──► DevOps Agent webhook
  EventBridge (source: aws.aidevops) ──► CloudWatch Logs

整个机关都藏在两个参数里

WriteFanout:          # items written per API request. 1 = healthy.
  Default: '1'
TableWriteCapacity:   # provisioned WCU. Deliberately tiny.
  Default: 1

Lambda 根据 WRITE_FANOUT 进行分支：

if WRITE_FANOUT <= 1:
    _table.put_item(Item=_order_item(order_id))          # healthy
    return _response(201, {"orderId": order_id, "writes": 1})

# the "optimisation" that broke production
with _table.batch_writer() as batch:
    for line_no in range(WRITE_FANOUT):
        batch.put_item(Item=_order_item(f"{order_id}#{line_no}", line_no))

有三个细节让它表现得像一次真实事故，而不是一个玩具示例。

填充后的数据项。每个数据项都包含一个 900 字节的 notes 字段，因此会消耗完整的一个写入容量单位。如果没有填充，DynamoDB 针对单个数据项的取整机制会掩盖这个问题。

刻意设置得很短的重试预算。

_ddb = boto3.resource("dynamodb",
    config=Config(retries={"max_attempts": 2, "mode": "standard"}))

boto3 默认约 10 次的自适应重试会消化掉限流，把一次硬故障变成令人困惑的延迟。两次尝试意味着限流会表现为真正的错误、真正的 Lambda 调用失败以及真正的 API 5xx。

使用一次 BatchWriteItem，而不是调用 25 次。batch_writer() 会缓冲数据，并以每批 25 个数据项的形式刷写，这是 BatchWriteItem API 的上限。当 WRITE_FANOUT=25 时，每次调用恰好会发出一个携带 25 个数据项的请求。记住这个细节——它会成为第 11 节中最清晰的证据。

所有内容都位于同一个 SAM 模板中，其中包含结构化 JSON 日志、启用的 X-Ray、7 天的日志保留期，以及四个在 AlarmDescription 字段中包含实际运行手册文本的告警。最后这一点比表面看上去更重要；详见第 7 节。

6. 20 分钟完成接入

有四种受支持的方式：控制台、AWS CLI、CloudFormation/CDK（AWS::DevOpsAgent::AgentSpace + AWS::DevOpsAgent::Association），以及 Terraform（awscc_devopsagent_agent_space）。如果可以选择，请使用 IaC——这是生产环境访问配置，理应纳入版本控制。

精简后的 CLI 操作流程如下：

REGION=us-west-2
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)

# 1. role the service assumes to read your account
cat > trust.json <<EOF
{"Version":"2012-10-17","Statement":[{
  "Effect":"Allow",
  "Principal":{"Service":"aidevops.amazonaws.com"},
  "Action":"sts:AssumeRole",
  "Condition":{
    "StringEquals":{"aws:SourceAccount":"$ACCOUNT"},
    "ArnLike":{"aws:SourceArn":"arn:aws:aidevops:$REGION:$ACCOUNT:agentspace/*"}}}]}
EOF

aws iam create-role --role-name DevOpsAgentRole-AgentSpace \
  --assume-role-policy-document file://trust.json
aws iam attach-role-policy --role-name DevOpsAgentRole-AgentSpace \
  --policy-arn arn:aws:iam::aws:policy/AIDevOpsAgentAccessPolicy

# 2. role your humans use in the web app
#    (same trust policy, plus sts:TagSession)
aws iam attach-role-policy --role-name DevOpsAgentRole-WebappAdmin \
  --policy-arn arn:aws:iam::aws:policy/AIDevOpsOperatorAppAccessPolicy

# 3. the space
aws devops-agent create-agent-space --name "prod-ops" --region $REGION

# 4. let it discover the account
aws devops-agent associate-service --agent-space-id $SPACE --service-id aws \
  --configuration "{\"aws\":{\"assumableRoleArn\":\"arn:aws:iam::$ACCOUNT:role/DevOpsAgentRole-AgentSpace\",\"accountId\":\"$ACCOUNT\",\"accountType\":\"monitor\"}}" \
  --region $REGION

# 5. turn on the web app
aws devops-agent enable-operator-app --agent-space-id $SPACE --auth-flow iam \
  --operator-app-role-arn "arn:aws:iam::$ACCOUNT:role/DevOpsAgentRole-WebappAdmin" \
  --region $REGION

容易踩中的四个坑

1. 你的 AWS CLI 很可能太旧了。遇到的第一堵墙：

$ aws --version
aws-cli/2.32.22 Python/3.13.11 Windows/11 exe/AMD64

$ aws devops-agent help
aws: [ERROR]: argument command: Found invalid choice 'devops-agent'

winget upgrade --id Amazon.AWSCLI --accept-source-agreements
# or download https://awscli.amazonaws.com/AWSCLIV2.msi

CLI 和 SDK 各自独立演进，这会在两个方向上都带来问题。在同一台机器上的同一时刻：CLI 会直接拒绝 devops-agent，而 boto3 1.43.6 / botocore 1.43.7 却已经拥有可用的 devops-agent 客户端。因此，本文中的每一条 aws devops-agent … 命令都有一个两行的 Python 等价写法，无需升级任何东西就能使用：

import boto3
boto3.client("devops-agent", region_name="us-west-2").get_account_usage()

同一问题还有一个更隐蔽的版本：这个 boto3 版本提供了 get_operator_app，而且会返回 HTTP 200——但它的响应模型缺少较新版本 botocore 会返回的 operatorAppUrl 字段。调用成功了，数据却悄无声息地缺失，也没有任何错误。如果文档承诺的字段没有出现在响应中，请先升级，再调试其他问题。

（如果你卡在这里：Web 应用 URL 是确定的——https://<agentSpaceId>.aidevops.global.app.aws。）

2. iam:CreateServiceLinkedRole 不在托管策略中。拓扑发现使用 AWS Resource Explorer，而智能体角色需要创建 Resource Explorer 的服务相关角色。AIDevOpsAgentAccessPolicy 并未授予此权限：

{"Version":"2012-10-17","Statement":[{
  "Sid":"AllowCreateServiceLinkedRole",
  "Effect":"Allow",
  "Action":["iam:CreateServiceLinkedRole"],
  "Resource":["arn:aws:iam::ACCOUNT:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer"]}]}

跳过这一步，发现功能就会在没有明显提示的情况下表现不佳。

3. 通过 IAM 进入 Web 应用的身份验证链接会在 10 分钟后过期。首次查看时这没问题，但对于值班轮换而言毫无用处。在把它交给团队之前，请接入 IAM Identity Center（或直接接入 OIDC IdP——Okta、Entra ID）。

4. 两个控制台，而且这种划分并不直观。管理员在 AWS Management Console 中配置 Agent Space。运维人员则在一个拥有独立域名、位于 AWS 控制台之外的 Web 应用中完成所有实际工作——调查、聊天、拓扑分析和建议。如果你在 AWS 控制台中寻找调查界面，是找不到的。

确认它确实在运行

引导流程“成功”与智能体正常工作是两回事。我编写了一个状态脚本（lab/scripts/agent_status.py），用于一次性获取全貌。在我执行任何操作之前，它针对我的 Space 输出的真实结果如下：

=== account agent-hours this month (us-west-2) ===
  investigations : 0.00h (no cap)
  evaluations    : 0.00h (no cap)
  learning       : 0.00h (no cap)
  on-demand/chat : 0.00h (no cap)

=== my-first-devops-agent  (<agentSpaceId>) ===
  web app     : https://<agentSpaceId>.aidevops.global.app.aws
  association : aws <account-id> monitor -> valid
    webhooks  : none  <-- nothing can page this agent
  tasks       : 1
    [FAILED   ] SYSTEM_LEARNING  Create Agent Space Understanding Skills  <-- FAILED
  prevention recommendations : 0
  goal        : ONCALL_REPORT [ACTIVE] rate(7 days) (ENABLED)

请仔细阅读，因为这才是一个“成功完成引导”的 Agent Space 的真实状态：

零个 webhook——外界没有任何东西能够触发调查

初始学习任务早在三周前就已经 FAILED，却没有任何提示

零条建议，消耗的智能体小时数为零

这个 Space 自 7 月 6 日以来就一直闲置着，什么也没做。与其说这是对产品的批评，不如说是对引导体验的警告：这里没有明确的绿灯信号。请定期运行类似的状态检查。

7. 将警报接入智能体

用户指南列出了启动调查的三种方式：

内置集成——ServiceNow 工单、Dynatrace 问题、Datadog 事件、Splunk 或 New Relic 警报、PagerDuty 事件

Webhook——通用 HTTP POST，使用 HMAC 或 bearer token 进行身份验证

人工在 Web 应用中点击 Start investigation

CloudWatch alarm 不在这个列表中，SNS 也不在。它没有 alarm action、没有内置 CloudWatch 集成，也不支持将 EventBridge 直接作为输入。如果你使用 CloudWatch alarms 发出警报——对大多数 AWS 原生无服务器团队来说确实如此——就必须自行构建胶水代码。

这里我想谨慎一些，因为我第一次起草本节时连续写错了两次，而这两个错误都很有启发性。

更正 1：这一模式有完善的文档，只是不在用户指南里。AWS 至少发布过四次这种模式——Networking & Content Delivery 博客中的自动化网络事件响应文章（在 aws-samples 中附带可部署的 CloudFormation 模板）、Security 博客中的 Network Firewall 故障排查文章，以及两篇 repost.aws 文章。其中一篇 repost 文章开篇就指出，CloudWatch Alarms 是需求最多的集成。因此：产品确实存在缺口，但博客已经对此进行了非常全面的介绍。在自己编写任何东西之前先搜索这些内容——其中的示例质量很好，能帮你节省一个下午。

更正 2：确实存在一条 API 路径，而我漏掉了它。我最初写的是不存在 StartInvestigation API；从名称上看这没错，但实质上并非如此：

aws devops-agent create-backlog-task \
  --agent-space-id $SPACE \
  --task-type INVESTIGATION \
  --priority HIGH \
  --title "devops-lab-api-5xx in ALARM" \
  --description "$ENRICHED_CONTEXT" \
  --client-token "cw-devops-lab-api-5xx-2026-07-31T16:56:30" \
  --region us-west-2

--task-type 接受 INVESTIGATION、EVALUATION、RELEASE_READINESS_REVIEW 和 RELEASE_TESTING。create-backlog-task 就摆在我已经完整列举过的命令界面中，但我把它理解成了运维待办事项的记录功能，而不是调查入口。它正是 repost.aws 模式背后的机制：通过 EventBridge → Lambda → CreateBacklogTask，将 Incident Detection and Response 警报桥接进来。

这一点很重要，因为它意味着存在一条不需要 webhook、不需要共享密钥，也不需要控制台操作的路径。

两条路径的并列比较

该如何选择？如果你希望把所有内容都纳入版本控制，不进行点击式运维，也不需要轮换密钥，请选择路径 B。如果你已经在接收来自 Datadog 或 PagerDuty 的警报，并希望 CloudWatch alarms 以相同的格式从同一个入口进入，请选择路径 A。路径 A 也是经过更多实践验证的方案——aws-samples 模板采用的正是这条路径。

有一点我尚未验证，AWS 的文章也都没有说明：通过 {% raw %}CreateBacklogTask 创建的调查，是否会经过与 webhook 投递事件相同的分诊阶段——也就是决定 LINKED / SKIPPED / PROCEED，并在大约 20 分钟的窗口内对相关警报去重的阶段（§8）。这一行为只针对传入事件有文档说明，并未涵盖通过 API 创建的任务。如果你依赖分诊关联功能，以免为同一次故障支付三次调查费用，那么在决定采用路径 B 之前，请先对此进行测试。我宁愿明确指出这个未知点，也不愿凭空猜测。

路径 A，以及示例留给你自行处理的部分

我构建了路径 A，因为我希望它采用与 Datadog 或 PagerDuty 警报相同的负载格式。整个实现大约 40 行代码。

第 1 步——生成通用 webhook。这一步确实没有 API。在控制台中依次进入：你的 Agent Space → Capabilities → Webhook → Configure → Generate webhook，然后选择 HMAC 或 API key。

请选择 HMAC，并了解其中的原因：

将密钥存储在 Secrets Manager 中。之后无法再次获取它。

第 2 步——SNS → Lambda → webhook。签名仅使用标准库：

timestamp = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S.000Z")
signature = base64.b64encode(
    hmac.new(secret.encode(),
             f"{timestamp}:{body.decode()}".encode(),
             hashlib.sha256).digest()
).decode()

headers = {
    "Content-Type": "application/json",
    "x-amzn-event-timest