新一代 AWS Resilience Hub 实战：使用 Agent 加速韧性工程

摘要：本文介绍如何使用 Kiro CLI 与自建 Hermes Agent，持续对比 AWS Resilience Hub 评估结果，并结合经人工确认的长期记忆生成韧性评估报告。

01一、引言

05五、总结

一、引言

韧性工程的多数环节都高度依赖外部资源：评审架构是否满足 RTO 和 RPO、设计并执行故障演练、整理结论并跟踪整改。正因为依赖人力，这些工作往往只能按项目或按年度进行，需要较长的周期进行重新评估。新一代 AWS Resilience Hub 用生成式 AI 完成故障模式评估，单次评估周期只需约数十分钟，评估本身已不再是瓶颈；瓶颈转移到了评估之后，即把评估结果转化为组织可以使用的结论。对于重视业务连续性和合规的组织而言，韧性不是一次性的结论，而是需要持续证明的能力，这要求评估结果能够定期沉淀为可追溯、可比较的报告。这项工作长期依赖专家经验，难以规模化，而具备长期记忆的 Agent 能够延续组织的判断，让这项工作以稳定的质量持续进行。本文介绍如何把这部分工作交给 Agent，使韧性评估能够按期持续进行。

本文首先介绍新一代 AWS Resilience Hub 的评估能力与原生报告；随后结合 AWS 韧性生命周期框架，说明 Agent 如何与 Resilience Hub 分工，按期留存评估记录、逐期对比，并结合组织决定撰写报告；最后给出报告 skill 的提示词示例，并以 Kiro CLI 与 Hermes Agent 为例介绍部署方式与实测效果。

二、新一代 AWS Resilience Hub 与评估报告

新一代 AWS Resilience Hub 以韧性策略为中心组织评估。负责统一制定韧性标准的运维或架构团队在策略中定义可用性 SLO、多 AZ 与多区域的 RTO 和 RPO、备份间隔等目标；每次故障模式评估针对每个策略组件给出达标判定（可达成或不可达成），并列出导致不达标的风险项。评估引擎根据资源配置推断出的前提会以 AI 断言的形式展示，供人审阅和修正（参考 Assertions 文档）。服务还原生提供故障模式评估报告，每份报告对应一次评估。报告汇总了本次评估的达标判定、识别出的风险项及整改建议，可以导出存档，作为该时间点的评估记录交给架构和运维团队安排整改，也可以作为合规审查的证据。

在之前的《AWS DevOps Agent 实战：如何使用生成式 AI 加速故障演练》一文中，我们用 Kiro 与 DevOps Agent 把演练从高度依赖人力的手工操作，转变为低成本、可复现的流程。本文将聚焦于韧性生命周期中的运营阶段：评估由 Resilience Hub 完成，报告由 Agent 按期生成，跨期变化来自每期留存的记录，判断上下文由长期记忆提供。

三、Agent 如何与 Resilience Hub 协作生成评估报告

本方案把生成评估报告的工作分给三方。Resilience Hub 负责评估本身。Agent 以只读方式读取评估结果，每期留存记录并按固定规则与上一期逐条对比，再结合组织判断撰写报告。最终结论由人确认，人作出的决定再沉淀为 Agent 的长期记忆，供下一期使用。这样，报告既能按期自动产出，每一项结论又都能追溯到评估数据或组织决定。

3.1 AWS 韧性生命周期框架

AWS 在韧性生命周期框架中，把韧性改进描述为一个持续循环的过程，分为五个阶段：设定目标、设计与实施、评估与测试、运营、响应与学习。框架建议组织把这一生命周期作为标准流程来运营，像软件开发生命周期一样随每次迭代重复，并逐步深化各阶段的实践。框架还指出，评估与测试从上线前开始，但不止于上线前，进入运营阶段后仍要持续进行。框架没有规定每个阶段由谁执行，下表中“本方案的对应做法”一列是我们基于这一框架所做的分工设计。在本方案中，评估由 Resilience Hub 完成，目标设定和对风险项的决策由人负责。Agent 承担的是长期依赖专家投入、难以按期进行的持续性工作，包括三项：把每次评估的结果与历史结果对照，整理成负责人可以直接据以决策的材料，并把上一轮的决定带入下一轮。按期生成的评估报告是这些工作的载体，用来串联各阶段的产出，并在迭代之间传递结论。

框架阶段	框架中的关注点	本方案的对应做法
设定目标	从业务出发明确所需的韧性水平及衡量方式	负责统一制定韧性标准的运维或架构团队在韧性策略中定义可用性 SLO、多 AZ 与多区域的 RTO 和 RPO、备份间隔，作为报告中范围与目标的依据
设计与实施	预判故障模式，按目标作出设计选择，制定变更管理策略	本方案不介入设计，只把资源与配置变更作为重新评估的触发条件
评估与测试	通过测试与评估确认应用能否满足韧性目标，并在运营阶段持续进行	Resilience Hub 按策略执行故障模式评估，以变更触发为主、定期兜底，产出达标判定、风险项和 AI 断言；故障演练用于验证评估结论
运营	通过可观测性与运营实践维持并改进韧性	Agent 每期留存评估记录并与上一期按风险项逐条对比，判断结论是否因变更而过期，再依据对比结果与组织记忆撰写报告并投递
响应与学习	应对中断事件，从运营经验中总结并沉淀改进	负责人审阅报告，确认或修正评估前提，对风险项作出整改或接受的决定；这些决定与演练结论写入长期记忆，供下一期报告引用

如需进一步了解框架及相关实践，可参考以下资料：

3.2 执行步骤

本文聚焦在运营阶段：前一个阶段是评估与测试，产出由 Resilience Hub 生成；后一个阶段是响应与学习，由人作出决策。运营阶段在两者之间承接，把评估结果转化为决策依据，再把决策带入下一轮。以下四个步骤是本文方案的实施方式，不是框架规定的流程。其中第 1 步属于评估与测试阶段，第 2、3 步属于运营阶段，第 4 步属于响应与学习阶段：

评估：Resilience Hub 按韧性策略执行故障模式评估，单次评估周期约数十分钟。框架在部署后活动中把自动化的持续评估列为最佳实践，Well-Architected 的 REL08-BP03 也建议把评估集成到部署流程中。本文据此以变更触发评估为主，并按固定周期执行一次兜底评估。
状态留存与逐期对比：这一步由 Agent 执行。Agent 以只读身份调用 Resilience Hub 的接口，读取服务的韧性目标、历次评估的达标判定、当前风险项、评估前提和服务事件，把本期记录保存为文件，再与上一期记录按风险项 ID 逐条对比，先写出对比结果，再进入撰写。
报告撰写：这一步由 Agent 执行。Agent 按本文编写的报告 skill 规定的结构和规则，读取对比结果以及长期记忆中的组织决定，生成固定七个部分的报告，并投递给负责人。
人工确认与回写：负责人审阅报告，确认或修正评估前提，对风险项作出整改或接受的决定。这些决定写入长期记忆，在下一期报告中引用。这一步是本文提出的做法，我们没有找到官方先例，其效果见后文的实测结果。

需要说明的是，新一代 Resilience Hub 会保留两年的评估历史，但不能按某次历史评估回查当时的风险项清单，因此本方案需要在服务之外逐期留存风险项清单。整个过程只读取 Resilience Hub，修正评估前提、发起重新评估等操作都由人执行。另外，服务事件只记录 Resilience Hub 侧的变更，不包括资源内部的配置修改，这类变更需要由 AWS Config 或 IaC 流水线另行触发重新评估。留存的记录属于评估数据，不属于 Agent 的记忆。Agent 的长期记忆只用来保存已接受的风险、负责人和复核日期等组织决定。报告的结构和撰写规则固定在 skill 中，还会指出评估之后发生的变更，并在需要时建议重新评估。Agent 只有读取权限；修正前提、发起重新评估等写操作只提出建议，由人确认后执行。

四、技术实现与效果

两种实现由相同的四个部分组成，主要差别在长期记忆的产生方式、调度方式、权限约束和部署形态：

组成部分	作用	Kiro CLI	Hermes Agent
记录与对比	Agent 按提示词以只读方式调用 Resilience Hub 接口，保存每期记录，并与上一期按风险项 ID 逐条对比	通过受限的 shell 工具只运行只读命令，记录写入 `records/` 目录	通过最小权限 IAM 角色运行命令，记录写入工作目录
报告 skill	规定读取、记录、对比与撰写的步骤和规则，内容即下文的提示词示例	放在 `.kiro/skills/` 下按需加载	安装后用 curator 的 pin 功能锁定
组织决定	已接受的风险、负责人、复核日期等，由人确认	人维护的决定文件，每次会话读取	Agent 用 memory 工具写入 `MEMORY.md`，每次会话自动带入
调度与投递	按期触发并把报告送达负责人	外部调度，报告写入文件	内建 cron 与飞书投递

权限边界方面，Kiro CLI 通过工具白名单只允许 Agent 运行 Resilience Hub 的 list 和 get 命令，并只能写入记录和报告目录；Hermes 使用客户托管的最小权限 IAM 策略，只允许读取 Resilience Hub 以及调用指定的 Amazon Bedrock 模型。本次实测中，读取服务事件时不指定事件类型会因达标状态更新类事件出现解析错误，因此本文显式指定需要读取的事件类型。

4.1 提示词示例

AWS 在 Agent Toolkit for AWS 中提供了一组官方的 Resilience Hub skills，覆盖评估运行、风险项处置和报告生成等任务，但不涉及跨期对比和组织记忆。本文编写的 skill 在此基础上，规定了读取、留存、对比和撰写四个步骤，可按组织的评审与合规要求调整。以下提示词即该 skill 的内容：

你是韧性评估报告的撰写助手。请严格按以下四步生成本期的 Resilience Hub 韧性评估报告。接口细节可参考官方 resilience-hub-failure-mode-assessment skill。

## 约束
- 只允许运行 `aws resiliencehubv2` 的 `list-*` 和 `get-*` 命令，所有命令都加 `--output json`。
- 不得运行任何 create、update、start、delete、import 命令，不得修改风险项、评估前提或任何资源。
- 命令报错时，在报告中如实写明“采集失败”及错误信息，不得推测或补全数据。

## 第一步：读取本期状态
1. 列出所有服务，取每个服务的 serviceArn 和 name：
   `aws resiliencehubv2 list-services --output json`
2. 对每个服务读取韧性目标和当前达标判定（取 effectivePolicyValues、achievability）：
   `aws resiliencehubv2 get-service --service-arn <serviceArn> --output json`
3. 读取历次评估（取 assessmentSummaries 中的 assessmentId、assessmentStatus、endedAt、achievability、totalFindings），并找出最近一次 assessmentStatus 为 SUCCESS 的评估：
   `aws resiliencehubv2 list-failure-mode-assessments --service-arn <serviceArn> --output json`
4. 读取当前风险项（取 findingId、name、status、severity、policyComponent）。该接口只返回当前状态，不能按历史评估查询：
   `aws resiliencehubv2 list-failure-mode-findings --service-arn <serviceArn> --output json`
5. 读取评估前提，按 source 统计 USER 与 AI_GENERATED 的数量，并保留 AI_GENERATED 断言的 text：
   `aws resiliencehubv2 list-assertions --service-arn <serviceArn> --output json`
6. 读取最近一次成功评估之后的服务事件（取 timestamp、eventType）。必须显式指定事件类型，否则接口会因达标状态更新类事件出现解析错误：
   `aws resiliencehubv2 list-service-events --service-arn <serviceArn> --start-time <最近一次成功评估的 endedAt> --event-types SERVICE_RESOURCES_ASSOCIATED SERVICE_RESOURCES_DISASSOCIATED SERVICE_INPUT_SOURCES_UPDATED SERVICE_POLICY_ASSOCIATED SERVICE_POLICY_DISASSOCIATED ASSERTION_CREATED ASSERTION_UPDATED ASSERTION_DELETED --output json`

## 第二步：留存本期记录
把以上结果写入 `records/<本期日期>.json`，每个服务包含：name、韧性目标、达标判定、最近一次成功评估的 assessmentId 与 endedAt、风险项清单（每项的 findingId、name、status，按接口返回原样逐条记录，不得汇总或省略）、评估前提数量、评估后的服务事件类型。该文件是下一期对比的唯一依据。

## 第三步：与上一期对比
1. 读取 `records/` 中日期早于本期的最新一份记录；没有则本期为基线，跳过对比。
2. 只按 findingId 机械对比：只在本期出现的为新增；只在上期出现的为移除；两期都有但 status 不同的为状态变化。
3. 逐个策略组件比较达标判定，只列出取值不同的组件。
4. 先把新增、移除、状态变化、达标判定变化的清单和数量写入本期记录的 comparison 部分，再开始撰写报告。严重度不做跨期比较。

## 第四步：撰写报告
报告按以下部分组织：
1. 范围与目标：列出每个服务的韧性目标。
2. 达标状态：列出各策略组件的达标判定，并说明与上一期相比的变化。
3. 风险项变化：列出新增、移除和处置状态发生变化的风险项。
4. 处置与证据：列出已关闭的风险项；对已接受的风险，注明负责人和复核日期。
5. 评估前提：说明已由人确认的前提数量，并列出尚待确认的 AI 断言。
6. 结论时效：说明最近一次成功评估的时间、评估之后发生的变更，以及是否建议重新评估。
7. 后续行动：只列出由以上内容直接推出的行动，并注明依据所在的部分。

撰写规则：
- 跨期变化只采用 comparison 中的结果，不凭印象比较前后状态。
- 状态为 OPEN 的风险项，只有在组织决定中存在明确决定时，才能标为已接受风险。决定中有风险项 ID 时按 ID 对应；没有 ID 时，风险项名称须与决定中的名称相同或以其开头；对应到多项时不作标注，注明需人工确认。
- 已接受风险的复核日期早于或等于本期日期时，视为逾期，在“处置与证据”中标出，并列入后续行动，提醒负责人复核。
- 评估之后有服务事件或没有成功评估时，只建议重新评估，由人批准执行。
- 没有成功评估的服务，只输出“范围与目标”和“结论时效”两部分，并注明尚无成功的评估。
- 不补充事实中没有的信息；无法确定的内容注明需要人工确认。报告中不出现字段名，一律用中文说明其含义。
- 各部分标题不加序号；交叉引用使用部分名称，不使用“第几节”。

4.2 部署与运行

本方案对部署形态没有限制：只要 Agent 能够加载 skill、以只读方式访问 Resilience Hub，并且能读写记录文件，就可以运行。本文以 Kiro CLI 和自建的 Hermes Agent 为例。Kiro CLI 既可以由工程师交互使用，审阅评估前提、维护组织决定，也可以以无交互模式按期运行；Hermes 内建定时任务，能够与飞书等协作平台集成，适合按期自动生成报告并推送给负责人。

Kiro CLI 没有内建调度，可由运行环境中的 cron 直接触发；如果使用 Amazon EventBridge Scheduler，则需要通过 AWS Systems Manager Run Command 在托管节点上执行。以下命令以无交互模式运行：

kiro-cli chat --agent rh-report --no-interactive --trust-tools=read,write,shell \
  "按 resilience-periodic-report skill 生成本期韧性评估报告，写入 reports/2026-10.md"

以下是 Kiro CLI 按上文提示词生成的报告节选。为了验证跨期对比，我们在上一期记录中构造了新增、移除、状态变化和达标判定变化各一处，Agent 全部正确识别，并指出了构造记录与评估时间不一致之处：

# 韧性评估报告（本期日期：2026-10-09）

## 达标状态（orders-db-service）

| 策略组件 | 本期判定 | 与上期相比 |
|---|---|---|
| 可用性目标 | 可达成 | 无变化 |
| 多可用区恢复时间/恢复点目标 | 不可达成 | 由「可达成」变为「不可达成」 |
| 两次备份之间的数据恢复时间目标 | 可达成 | 无变化 |

## 风险项变化（orders-db-service）

与上期相比：新增 1 项，不再出现 1 项，处置状态变化 1 项。

| 变化 | 风险项 | 状态 |
|---|---|---|
| 新增 | Aurora 集群及实例未开启删除保护（0006273c-…） | 待处理 |
| 不再出现 | Aurora 实例使用突发性能实例规格，不适合生产（deadbeef-…） | 上期为待处理 |
| 状态变化 | Aurora 集群缺少跨区域备份或复制（7c4301fa-…） | 待处理 → 已解决 |

不再出现的风险项在本期接口中已查不到。接口只返回当前状态，无法说明它是被修复、被撤销还是因其他原因消失，需人工确认。

## 处置与证据（orders-db-service）

已接受的风险（依据组织决定）：

- NLB 仅覆盖两个可用区，降低可用区故障容忍度（7ed21ee5-…），状态仍为待处理。负责人：张三。复核日期：2026-11-01，晚于本期日期，未逾期。
- 其余 9 项待处理风险在组织决定中没有对应条目，不标注为已接受风险。

……

## 后续行动

| # | 行动 | 依据 |
|---|---|---|
| 1 | 人工核对：同一次成功评估下，本期与上期风险项清单为何出现新增、消失和状态变化 | 风险项变化 |
| 2 | 批准并重新评估 orders-db-service，以获得与当前资源状态一致的结论 | 结论时效 |
| 3 | 批准并重新评估 hk-crossregion-service；评估前需先解决调用方角色权限与资源拓扑问题 | 结论时效 |
| 4 | 人工确认 2 条 AI 生成的评估前提 | 评估前提 |

Hermes 以 gateway 常驻运行，由 systemd 系统服务管理，开机自动启动。飞书使用 websocket 长连接模式，不需要公网入口，通过 FEISHU_ALLOWED_USERS 限定可以使用机器人的用户（参考 Hermes 飞书集成文档）。组织决定由 Agent 通过内建的 memory 工具写入 MEMORY.md，每次会话开始时作为快照注入系统提示词；历史会话可以用 session_search 检索（参考 Hermes Persistent Memory 文档）。记忆可以在对话中直接产生，但需要约束写入的内容。Hermes 内建 cron，定时任务在全新会话中执行，报告 skill 安装后通过 curator 的 pin 功能锁定，避免被自我改进流程修改：

hermes curator pin resilience-periodic-report
hermes cron create "0 9 1 * *" \
  "按 resilience-periodic-report skill 生成本期的 Resilience Hub 韧性评估报告。" \
  --name rh-periodic-report \
  --skill resilience-periodic-report \
  --deliver feishu:<用户 open_id> \
  --pin

Hermes 可以通过飞书机器人接收任务并把报告直接回复在对话中。下图只展示消息交互与报告投递形式；报告内容与跨期对比效果以上方的文字和 Kiro CLI 报告节选为准：

[图 1]

五、总结

在这篇文章中，我们向您介绍了如何结合新一代 AWS Resilience Hub 与具备长期记忆的 Agent 加速韧性工程。生成式故障模式评估把单次评估周期缩短到约数十分钟，Agent 则承担评估之后的解读、跨期比较和报告撰写，使韧性评估能够按期持续进行，而不再受限于专家的投入。为了保证报告可信，我们把评估数据和组织判断分开处理：每期的评估数据以记录文件留存，由 Agent 按风险项 ID 逐条对比，不进入长期记忆；已接受的风险、负责人和复核日期等组织判断才由 Agent 的长期记忆保存，并约束其写入和使用方式。Kiro CLI 以经人维护的决定文件承载组织记忆，权限控制精细，适合交互式审阅；Hermes 以内建的 memory 工具、cron 和消息投递支持无人值守的周期任务，但需要常驻部署才能发挥这些能力。

结合上一篇介绍的演练方法，韧性生命周期中的评估与测试阶段和运营阶段都可以由 Agent 加速，并且互相提供输入：评估报告的后续行动给出下一次演练的对象，故障转移优先级与灰度故障检测；演练得到的结论又可以写入记忆，在下一期报告中作为验证证据。如需进一步讨论如何在您的环境中加速韧性工程，欢迎联系您的 AWS account 团队。

➡️ 下一步行动：

相关产品：

Amazon DevOps Agent — 解决和预防事故的代理
Amazon Aurora — 适用于 PostgreSQL、MySQL 和 DSQL 的无服务器关系数据库服务
Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
Amazon EventBridge — 大规模构建事件驱动应用程序
Amazon IAM — 身份管理和访问权限

相关文章：

立即咨询 → 从 AI 规划到落地实施，我们的专家团队为你全程护航。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客