运维 Agent：把诊断、审批与执行拆成三条边界

工程学习与设计笔记。示例使用合成场景；适用版本与参考资料见正文。

告警来了：消费延迟连续十分钟增长，任务没有失败。把日志交给模型，它可能很快建议“重启任务”。但重启也可能清空缓存、触发重放、扩大积压。运维 Agent 最值得工程化的部分，是把证据变成可验证的操作，而不是让建议更像专家口吻。

本文用一个虚构的流处理作业说明设计方法，所有阈值只是演示，不对应任何线上系统。

先定义它能决定什么

诊断流程可以固定为：确认告警有效性、收集证据、构造候选原因、执行低成本验证、形成处置计划。模型负责提出下一条值得验证的假设；程序负责身份、权限、参数校验和执行预算。

例如“下游写入变慢”必须关联到相同时间窗口内的 sink 延迟、错误率、重试量和上游背压。仅凭消费延迟不能排除流量突增、分区倾斜和资源竞争。证据缺失时输出“尚不能区分”，比把最常见原因写成定论更有用。

工具不必暴露通用 shell。可以提供 get_job_metrics、get_recent_changes、get_checkpoint_summary 等窄接口，每个接口限定资源范围、时间跨度和返回大小。原始日志作为待分析数据处理，其中出现的命令不能自动变成执行指令。

一个操作计划应有的字段

审批不能只展示“是否同意优化”。需要把审批绑定到确定的目标和参数：

{
  "plan_id": "incident-42-plan-2",
  "resource": "stream-job-demo",
  "action": "set_sink_concurrency",
  "before": 16,
  "after": 12,
  "expected_config_version": 8,
  "evidence": ["metric-snapshot-17", "change-record-9"],
  "observe_seconds": 300,
  "rollback_to": 16
}

降低并发只是这个示例中“下游被过量请求压垮”的候选操作，并不是通用调优建议。执行前还要检查目标版本没有变化、资源健康状态仍满足前置条件、审批没有过期。计划参数变了，旧审批就不再有效。

Amazon Bedrock 的 return control 可以把模型拟调用的动作交回应用处理；用户确认机制则允许对指定动作加入确认。这些是接入点，真正的授权校验仍应在执行服务内完成。Bedrock return control 、用户确认。

超时是未知状态，不是失败证明

最容易出事故的时刻，是操作已生效但响应丢失。执行器不能因为请求超时就换一个 ID 重试。

execute(plan, operation_id):
  校验审批绑定的计划哈希与操作者权限
  原子登记 operation_id；已完成则返回原结果
  读取目标配置，校验 expected_config_version
  以 operation_id 调用支持幂等的控制接口
  超时 -> 标记 UNKNOWN -> 查询操作记录与目标状态
  确认结果 -> 持久化结果和实际配置版本

如果底层接口不支持幂等，就需要资源锁、版本条件更新与操作账本共同约束，并承认仍可能存在无法自动判定的状态。此时转交人工核对，而不是让模型推测“应该没执行”。

有持久化工作流也不等于外部动作只执行一次。以 LangGraph 为例，中断恢复会重新运行中断所在节点之前的代码，因此有副作用的动作不能随意放在审批等待之前。LangGraph interrupts 。

回滚也需要前置条件

“把并发改回去”只有在资源仍属于这个计划、期间没有其他人修改配置时才安全。回滚应使用执行成功后得到的版本作为条件；发现人工新变更，就停止覆盖。某些动作如重放消息、删除状态不可用反向参数恢复，计划里必须明确补偿方式或禁止自动执行。

观察阶段同时看收益和副作用：积压斜率是否变小、吞吐是否恢复、失败与重复输出是否增加。只看告警消失不够，告警可能只是被静默了。验证结果写入事件记录，并把未解决的问题作为后续任务，不能直接沉淀为“成功 SOP”。

怎么验收这条链路

先构造五类演练：真实下游限流、突发输入、指标缺失、执行响应丢失、审批后配置被人工修改。分别验证诊断证据、是否误执行、是否重复执行、能否识别过期计划。

指标按事件统计：正确定位事件数 / 有标注事件数；无需人工补证据的计划数 / 全部计划数；未经有效授权的执行数；执行后恢复且未引入新故障的事件数 / 已执行事件数。故障恢复时间必须从同一告警起点计时，并拆出等待人工、查询和执行的时间，避免把流程变化误报为模型能力提升。

一个可上线的运维 Agent，可以先稳定完成“收集证据与准备计划”，再逐步开放窄范围动作。真正有价值的自动化，是每次动作都说得清为什么做、实际做了什么，以及怎样证明它有效。

参考资料

Amazon Bedrock：Return control ，应用接管动作执行的接口语义。
Amazon Bedrock：User confirmation ，动作确认机制。
LangGraph：Interrupts ，中断、恢复与节点重放边界。本文采用框架中性伪代码，具体 API 以项目锁定版本为准。