AWS演示用Lambda Durable Functions与Bedrock自动执行DevOps Agent调查后的修复
AWS博客给出一个示例方案：DevOps Agent完成根因分析后，EventBridge触发工作流，Bedrock从允许列表中挑选修复工具，只读操作自动执行，改配置类操作暂停等待人工批准。
AI解读：AWS在博客中演示了一套自动修复工作流，接在AWS DevOps Agent的调查之后，用Amazon EventBridge、AWS Lambda Durable Functions和Amazon Bedrock把调查摘要转成待批准的修复动作。
DevOps Agent仍被建议保持在观察并报告模式，不直接修改生产资源；该方案补上的是问题解决环节，改基础设施的操作需人工批准。
Amazon Bedrock只能从一份预先审核的Lambda函数允许列表中选择工具；只读工具自动运行，会改变基础设施状态的操作会让durable function暂停并等待人工信号。
示例场景中，模拟的devops-agent-timeout函数因 3 秒超时失败，Bedrock读取现有配置后提议把超时改为 30 秒，经一次批准后由工具函数完成修改。
AWS称暂停期间不消耗计算资源，审批可跨数分钟、数小时甚至数天，恢复后从检查点继续；当前批准信号为批准或拒绝，回调接受任意JSON，可用于参数覆盖或审阅意见。
AWS提醒，发送给Bedrock的调查摘要和它提出的修复建议都由AI生成，批准前必须检查完整工具参数，人工批准环节是安全控制。
AWS在机器学习博客中发布一篇技术文章，演示如何在AWS DevOps Agent完成事故调查后自动执行修复。方案由Amazon EventBridge、AWS Lambda Durable Functions和Amazon Bedrock组成，目的是把调查摘要转成预先验证、可一次批准就执行的修复动作。
文章称，客户通常把包括DevOps Agent在内的可观测性代理保持在观察并报告模式：代理诊断问题，但不直接修改生产资源。这套工作流补上的是问题解决步骤，凡会改变基础设施状态的操作都要先暂停并等待人工批准。
工作流如何衔接调查与修复
文章描述，DevOps Agent完成调查后发出包含症状、发现和根因分析的事件；EventBridge规则收到事件并触发devops-agent-trigger函数。该函数打包调查摘要，调用devops-agent-remediation-durable持久函数。持久函数把调查上下文发给Amazon Bedrock，Bedrock分析发现并从允许列表中找出可用的修复工具。
Bedrock根据调查发现和可用工具提出具体修复动作。只读动作由持久函数自主运行；涉及基础设施变更的动作会让工作流挂起，等待人工批准后再执行。持久函数按代理循环运行，反复调用Bedrock、执行获批工具并把结果送回对话，直到修复完成。
- 触发函数负责从AWS DevOps Agent日志中获取调查摘要
- 初始Bedrock调用会先判断是否需要读取当前配置，例如从允许列表调用lambda_get_function_configuration
- 修复工具每个都是执行特定、范围明确动作的Lambda函数，例如读取Lambda配置或更新IAM策略语句
- 当前批准信号为批准或拒绝
安全边界与暂停机制
文章称，为防止意外改动，编排器强制使用一份预先审核的修复工具允许列表，Bedrock只能从这个集合中选择和调用工具。工作流还区分只读操作与变更操作：只读工具无需人工介入，变更基础设施状态的操作会让持久函数暂停执行，等待批准信号。
AWS说，Lambda Durable Functions在这里的作用是检查点进度并暂停，等待期间不消耗计算资源，之后从暂停处恢复。作者称，等值班工程师介入时，系统已收集相关配置、把根因与可用修复动作对应起来，并准备好一套预先验证的改动供一键批准。文章提醒，发给Bedrock的调查摘要和它提出的修复建议均由AI生成，批准前应始终复核；人工批准环节是安全控制，批准者必须检查完整工具参数。
- 允许列表限制Bedrock只能调用预先批准的工具
- 只读操作自动执行，变更操作暂停等待人工批准
- 持久函数可暂停数分钟、数小时甚至数天，恢复后从检查点继续
示例：3 秒超时改为 30 秒
文章用一个Lambda函数超出配置超时的场景做端到端演示。示例中部署了devops-agent-timeout函数并触发超时错误，然后在AWS DevOps Agent控制台发起调查。调查耗时几分钟，DevOps Agent关联CloudWatch指标、日志和函数配置后给出根因分析，指出函数超时时间对该工作负载不足。
持久函数启动代理循环后，第一次Bedrock调用判断需要先检查当前函数配置，于是从允许列表调用只读工具lambda_get_function_configuration，结果显示超时值为 3 秒。下一轮Bedrock认为 3 秒是失败根因，提议改为 30 秒，并调用lambda_update_function_configuration。由于这是变更动作，持久函数暂停并等待批准。
批准后，持久函数恢复、调用工具函数更新配置，最终输出确认超时从 3 秒改为 30 秒。文章称，从事故检测到自动修复的整个过程只要求工程师执行一次批准动作。文章同时说明，批准回调当前接受任意JSON，因此可扩展为携带参数覆盖或审阅意见，再送回Bedrock对话以在执行前调整建议。
- 模拟函数devops-agent-timeout因 3 秒超时报错
- Bedrock提议将超时提高到 30 秒，即原值的 10 倍
- 批准可通过AWS CLI的send-durable-execution-callback-success或Lambda控制台完成
- 最终配置显示LastModified为 2026-05-22T11:11:28.000+0000
部署前提与资源
文章列出的前提条件包括：已安装并配置AWS CLI、Python 3.14或更高版本、已安装AWS CDK、一个活跃的AWS DevOps Agent空间，以及可选的Kiro与Agent Toolkit for AWS。使用Kiro时，事故模拟、部署和清理可用自然语言提示完成。
用AWS CDK部署会创建三个Lambda函数（devops-agent-trigger、devops-agent-remediation-durable、devops-agent-lambda-tool）和一条Amazon EventBridge规则。AWS称CDK按最小权限原则自动处理IAM权限，例如授予EventBridge调用devops-agent-trigger的权限、授予该函数aidevops:ListJournalRecords以便获取调查摘要、授予持久函数bedrock:InvokeModel权限。
文章最后给出清理步骤：用cdk destroy删除CDK资源，并手动删除用于模拟事故的devops-agent-timeout函数、其IAM角色和CloudWatch日志组。
- 前提包括AWS CLI、Python 3.14+、AWS CDK和一个活跃的AWS DevOps Agent空间
- 完整CDK模板托管在GitHub的sample-automate-remediation-post-devops-agent-investigation仓库
- AWS称新增修复能力只需更新工具注册配置，不需要修改编排器代码