# 运维 Agent / Runbook / AIOps 官方方案详细学习笔记
Date: 2026-03-11


这篇文章的目标不是简单列一份名词清单，而是把几类和 `SafeOps Agent` 方向相近的方案，按“它到底解决什么问题、核心模型是什么、我能怎么上手”讲清楚。

我重点看的官方资料包括：

- StackStorm
- Rundeck / PagerDuty Runbook Automation
- OpenTelemetry Collector
- PagerDuty SRE Agent
- LangChain / LangGraph 的 human-in-the-loop
- OpenAI Agents SDK

如果先给出一句总判断，那么我的结论是：

- **StackStorm / Rundeck** 最接近“运维执行与 runbook 编排层”
- **OpenTelemetry Collector** 最接近“标准化采集层”
- **PagerDuty SRE Agent / LangGraph HITL / OpenAI Agents SDK** 最接近“AI 辅助分析与审批执行层”

所以，最先进的架构通常不是“让 LLM 直接 SSH 上去乱跑”，而是：

1. 先把数据采集标准化
2. 再把执行层做成确定性 workflow
3. 然后加审计、审批和权限边界
4. 最后再把 LLM 叠在上面做分析、归纳和建议

这也是为什么当前 **非 LLM、低权限、规则型** 的 SafeOps 路线是合理的。

## 1. StackStorm：事件驱动自动化的完整参考

官方资料：

- https://docs.stackstorm.com/overview.html
- https://docs.stackstorm.com/actions.html
- https://docs.stackstorm.com/workflows.html
- https://docs.stackstorm.com/orquesta/index.html
- https://docs.stackstorm.com/sensors.html
- https://docs.stackstorm.com/rules.html
- https://docs.stackstorm.com/reference/traces.html

### 1.1 它真正解决的问题

StackStorm 不只是“自动跑脚本”，它解决的是：

- 系统里发生事件后，如何自动识别并触发运维动作
- 如何把单步动作组织成 workflow
- 如何追踪一条自动化从触发到结束的全链路

它的核心模型非常经典：

- `sensor` 观察外部世界
- `trigger` 把事件结构化
- `rule` 决定是否启动自动化
- `action` 执行单步动作
- `workflow` 执行多步编排
- `trace` 把整条链路串起来

这个模型非常值得你学习，因为它把：

- 采集
- 判断
- 执行
- 编排
- 审计

拆成了不同层，而不是堆在一个 shell 脚本里。

### 1.2 最应该记住的几个概念

#### `actions`

`action` 是基本执行单元。官方示例里可以是：

- 本地 shell
- 远程 shell
- Python 脚本
- HTTP 请求
- workflow 本身

更重要的是 StackStorm 有 `runner` 抽象。也就是说它不是直接“随便跑命令”，而是先定义动作运行在什么执行器里。

这点对 SafeOps 的启发特别强：

- 未来最好不要只靠一个大而全的 shell runner
- 应该逐步区分：
  - 只读检查类动作
  - 远程执行类动作
  - HTTP 集成类动作
  - workflow 编排类动作

#### `rules`

规则的作用不是“执行”，而是“把事件和执行连接起来”。

一个 rule 通常包括：

- 触发器类型
- 匹配条件
- 执行的 action / workflow
- 参数映射

这意味着判断条件不再埋在脚本内部，而是外显成配置。

#### `workflows`

StackStorm 现代 workflow 引擎是 `Orquesta`。

官方强调它支持：

- 顺序流程
- 分支与汇合
- retry
- transition
- 上下文变量

这说明它已经不是“顺序跑几条命令”，而是一个真正的运维编排层。

#### `traces`

`trace` 是 StackStorm 的高级能力之一。

它可以把：

- 某个事件
- 哪条 rule 命中
- 哪个 action 被执行
- 执行结果如何

串成一条完整链路。

这一点非常像你以后可能需要的：

- run id
- workflow id
- 触发源
- 任务结果
- 最终报告

### 1.3 可以直接上手的命令

这些是官方 quick start 里非常值得自己跑一遍的命令：

```bash
st2 --version
st2 -h
st2 login st2admin -p 'Ch@ngeMe'

st2 action list --pack=core
st2 trigger list
st2 rule list

st2 run core.local -- date -R
st2 run core.local cmd="ls -al"
st2 run core.remote hosts='localhost' -- uname -a

st2 execution list
st2 execution get <execution_id>
```

这组命令可以帮助你建立最基本的直觉：

- StackStorm 不是先从 UI 学起，而是先从 CLI 学起
- action / trigger / rule / execution 是几个核心对象
- 执行历史天然是第一等公民

### 1.4 Rule 的最小学习例子

官方文档展示了 rule 采用 YAML 定义。一个简化学习版长这样：

```yaml
---
name: "sample_rule"
enabled: true

trigger:
  type: "core.st2.webhook"

criteria:
  trigger.body.name:
    type: "equals"
    pattern: "st2"

action:
  ref: "core.local"
  parameters:
    cmd: "echo webhook matched"
```

部署 rule 的典型命令：

```bash
st2 rule create /path/to/sample_rule.yaml
st2 rule list
st2 rule get examples.sample_rule_with_webhook
st2 rule update examples.sample_rule_with_webhook /path/to/sample_rule.yaml
st2 rule delete examples.sample_rule_with_webhook
```

测试 rule 的命令也很重要：

```bash
st2-rule-tester --rule=/path/to/rule.yaml \
  --trigger-instance=/path/to/trigger.json \
  --config-file=/etc/st2/st2.conf
```

这说明 StackStorm 不仅支持“上线规则”，还支持规则调试，这是成熟平台很重要的特征。

### 1.5 Workflow 的最小学习例子

官方 Orquesta 文档展示的是 YAML workflow 定义。
学习时你应该关心的不是语法细节本身，而是它表达了什么：

- 任务间依赖
- 成功或失败时如何跳转
- 上下文变量如何流动

官方的创建方式大概是：

```bash
st2 action create /opt/stackstorm/packs/examples/actions/orquesta-sequential.yaml
```

然后 workflow 会像普通 action 一样被注册。

这个设计非常漂亮，因为它意味着：

- workflow 本身也是 action
- 上层调度不用关心它内部是单步动作还是多步编排

### 1.6 对 SafeOps 的现实启发

如果你只从 StackStorm 学一件事，我建议学下面四件：

1. `trigger -> rule -> action/workflow` 的边界划分
2. action schema 和 output schema
3. trace 思维
4. workflow 不只支持 happy path，还支持失败路径和重试

## 2. Rundeck / PagerDuty Runbook Automation：以运维作业为中心的平台

官方资料：

- https://docs.rundeck.com/docs/enterprise/
- https://docs.rundeck.com/docs/about/introduction.html
- https://docs.rundeck.com/docs/manual/jobs/index.html
- https://docs.rundeck.com/docs/manual/jobs/job-workflows.html
- https://docs.rundeck.com/docs/manual/jobs/workflow-strategies/
- https://docs.rundeck.com/docs/administration/security/authorization.html
- https://docs.rundeck.com/docs/administration/security/audit-trail.html
- https://docs.rundeck.com/docs/api/

### 2.1 它真正解决的问题

Rundeck 不是一个“智能体平台”，它更像是：

- 多节点作业执行平台
- 可审批、可授权的 runbook 平台
- 面向人类操作员的自助运维系统

如果说 StackStorm 更像“系统自动响应事件”，那么 Rundeck 更像：

- 运维人员运行受控 job
- 或者系统通过 schedule / webhook / API 去触发已定义 job

### 2.2 核心对象

Rundeck 的核心对象是：

- `Project`
- `Node`
- `Job`
- `Workflow`
- `ACL`
- `Execution`

其中 `Job` 是核心单元。

一个 Job 里通常包含：

- 输入选项
- 节点过滤
- workflow 步骤
- 执行策略

这和“脚本扔到服务器上自己跑”的区别非常大，因为它把运维过程变成了可复用的、可被授权的对象。

### 2.3 最值得学习的设计点

#### Job 是一等公民

在 Rundeck 里，运维过程不是“命令历史”，而是 Job。

这带来的好处是：

- 别人能复用
- 权限可以绑定到 job
- 审计可以围绕 job 展开

#### Node Steps vs Workflow Steps

这是 Rundeck 文档里最容易被忽略，但非常重要的一个区别：

- `Node Steps`：对每个匹配节点执行
- `Workflow Steps`：全局执行一次

对多节点系统非常关键。

#### Workflow Strategies

官方文档里的三种策略特别有用：

- `Node First`
- `Sequential`
- `Parallel`

这意味着 workflow 不只是“按步骤排好顺序”，还可以表达：

- 在单节点维度滚动执行
- 在全体节点维度分阶段执行
- 并发执行

### 2.4 上手时最值得跑的接口

Rundeck 很多操作偏 UI，但官方也给了 API / CLI 路线。

最典型的 API 运行 job：

```bash
POST /api/14/job/[ID]/run
POST /api/12/job/[ID]/executions
```

官方文档里还给了带 options 的 JSON 示例，学习时可以把它理解成：

```json
{
  "options": {
    "input_key": "HelloWorld"
  }
}
```

也就是说，Job 运行时输入被正式建模了，而不是全靠 shell 参数拼接。

如果你偏 CLI，官方还有 `RD-CLI`。学习时建议重点记住：

- 它本质是 Rundeck API 的命令行封装
- 它能管理 jobs、executions、projects、keys、nodes 等对象

### 2.5 Webhook 驱动 Job 的方式

Rundeck 官方有 `Run Job Webhook Plugin`。

它的核心思路是：

- 接收 JSON webhook
- 把 payload 传给 job
- 支持把 payload 映射为 options、node filter，甚至 run-as user

这很像 StackStorm 的 webhook 触发规则，但它更偏 job 平台风格。

从你的角度看，这一点很重要，因为它表明：

- 一个 runbook 平台也可以接受外部事件触发
- 只是它的中心对象仍然是 job

### 2.6 ACL 和审计

Rundeck 官方在 ACL 和审计上的重视程度非常高。

这意味着它不是只解决“怎么执行”，而是同时解决：

- 谁可以看 job
- 谁可以运行 job
- 谁可以编辑 job
- 谁可以查看执行历史

一旦你的 SafeOps 从个人脚本变成团队工具，这部分几乎是必须补的。

### 2.7 对 SafeOps 的现实启发

如果你从 Rundeck 学习，我建议重点学：

1. Job / Workflow / Execution 作为正式对象
2. Node Steps 与 Workflow Steps 的区分
3. ACL 与审计思维
4. 错误处理不是附加逻辑，而是 workflow 的组成部分

## 3. OpenTelemetry Collector：现代采集层的标准答案

官方资料：

- https://opentelemetry.io/docs/collector/
- https://opentelemetry.io/docs/collector/installation/

### 3.1 它真正解决的问题

Collector 不是修复平台，也不是 workflow engine。
它的核心问题是：

- 如何把 metrics、logs、traces 用统一方式接收、处理、导出

也就是说，它是一个“遥测中转与处理层”。

### 3.2 你需要记住的组件模型

Collector 的核心组件是：

- `receivers`
- `processors`
- `exporters`
- `connectors`
- `extensions`

这对应一个非常现代的流水线模型：

1. 先接收
2. 再处理
3. 再导出

这个抽象特别重要，因为它把“采集”和“最终去哪儿”解耦了。

### 3.3 学习时最值得动手看的配置

Collector 的学习入口不是 CLI，而是配置文件。
一个最小学习配置大概长这样：

```yaml
receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  debug:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
```

这段配置足够帮助你理解：

- receiver 负责接入
- processor 负责处理中间层逻辑
- exporter 负责输出

### 3.4 为什么它对你重要

SafeOps 当前是轻量自定义方案，这没有问题。

但如果以后数据量、节点量、数据类型增长，你就会明显遇到两个问题：

- 采集格式不统一
- 后续分析层难以复用

这时 OTel Collector 的启发很重要：

- 采集层应该逐渐标准化
- 不同目标系统不应该各写一套 ad hoc 采集器

### 3.5 对 SafeOps 的现实启发

如果你只学一件事，就是：

- **采集层和执行层最好分开**

这会让你后面无论接规则引擎、报表系统、AI 分析层，都更容易。

## 4. PagerDuty SRE Agent：AI 调查与事故辅助层

官方资料：

- https://support.pagerduty.com/main/docs/sre-agent
- https://support.pagerduty.com/main/docs/agent-tooling-configuration
- https://support.pagerduty.com/main/docs/workflow-integrations

### 4.1 它真正解决的问题

PagerDuty SRE Agent 不是在解决“如何安全执行 shell”。
它更像在解决：

- 事故发生后，怎么更快理解上下文
- 怎么把日志、runbook、历史事件统一起来
- 怎么让值班工程师少花时间在重复调查上

### 4.2 最重要的能力边界

官方文档强调它可以：

- 摄取 runbook 与 SOP
- 结合历史 incident 学习
- 建议下一步动作
- 生成或优化 playbook
- 从日志系统检索上下文

换句话说，它更像：

- 调查型 AI copilot

而不是：

- 本地执行层

### 4.3 最值得学习的设计点

#### 证据驱动，而不是空想推理

官方资料显示，它会从：

- Grafana
- Datadog
- CloudWatch
- Confluence
- GitHub

等系统取数据。

这意味着它不是只靠大模型瞎猜，而是：

- 先取证据
- 再组织上下文
- 再给建议

#### Memory 层

官方提到了：

- incident playbook / scratchpad
- runbook memory
- incident summarization memory

这点很重要，因为这代表它并不是“单次问答工具”，而是带有事故记忆能力的系统。

### 4.4 对 SafeOps 的现实启发

如果你以后要加 LLM，我认为最合理的位置不是：

- 让 LLM 直接执行高权限运维动作

而是：

- 先让 LLM 做调查、总结、生成建议、复用历史案例

这才是更稳的 AI 引入路径。

## 5. LangChain / LangGraph 的 Human-in-the-Loop：现代 agent 安全边界的核心模式

官方资料：

- https://docs.langchain.com/oss/python/langchain/human-in-the-loop
- https://docs.langchain.com/oss/javascript/langchain/human-in-the-loop
- https://docs.langchain.com/oss/python/langgraph/human-in-the-loop

### 5.1 它真正解决的问题

它解决的是：

- 当 agent 想调用一个高风险工具时，如何强制人类审批

这类高风险动作通常包括：

- 写文件
- 执行 SQL
- 改配置
- 调用危险 shell 工具

### 5.2 最重要的运行逻辑

官方模式大致是：

1. 模型先提出一个 tool call
2. middleware 判断这个工具是否需要人工介入
3. 如需介入，则中断
4. 保存状态
5. 人类批准、编辑或拒绝
6. 系统恢复执行

关键点在于：

- 审批不是口头建议，而是 runtime 强制机制
- 状态必须可持久化和可恢复

### 5.3 为什么这对运维系统极其关键

很多“AI 运维”项目的最大问题不是模型不聪明，而是：

- 没有把审批做成运行时的一部分

一旦你未来想给 SafeOps 接入 LLM，这个模式几乎是必须借鉴的。

## 6. OpenAI Agents SDK：构建智能层的工程化工具

官方资料：

- https://openai.github.io/openai-agents-python/
- https://openai.github.io/openai-agents-python/agents/
- https://openai.github.io/openai-agents-python/running_agents/
- https://openai.github.io/openai-agents-python/config/
- https://openai.github.io/openai-agents-python/multi_agent/
- https://openai.github.io/openai-agents-python/handoffs/
- https://openai.github.io/openai-agents-python/human_in_the_loop/

### 6.1 它真正解决的问题

OpenAI Agents SDK 解决的是：

- 如何用一套比较少但够用的 primitives 来构建 agent 应用

它不是现成的 VPS 运维平台，而是用来构建“智能层”的框架。

### 6.2 核心 primitives

官方重点强调的原语包括：

- `Agent`
- `Handoffs`
- `Guardrails`

另外还有：

- `Sessions`
- `Tracing`
- `Human-in-the-loop`
- `MCP`

### 6.3 最值得学习的最小示例

学习它时，最有价值的不是先追很复杂的多 agent，而是看最小 agent：

```python
from agents import Agent, Runner

agent = Agent(
    name="OpsResearcher",
    instructions="You summarize operational context clearly."
)

result = Runner.run_sync(agent, "Summarize the differences between StackStorm and Rundeck.")
print(result.final_output)
```

这段例子虽然简单，但它让你建立两个关键认识：

- agent 是一个运行时对象，不只是 prompt
- 真正的应用能力来自 tools、handoffs、sessions、guardrails 的组合

### 6.4 更重要的是 Handoffs

官方多 agent 文档的一个非常重要的思想是：

- orchestration via LLM
- orchestration via code

这意味着你不一定要让模型主导全部流程。

对 SafeOps 而言，更合理的方式往往是：

- 执行层由 code 控制
- 分析层由 LLM 参与

### 6.5 HITL 的意义

官方 HITL 文档提到：

- tool 可以声明 `needs_approval`
- run state 可以保存并在审批后恢复

这和 LangGraph 的思路是同一类现代安全模式：

- 高风险动作必须审批
- 运行时必须可中断、可恢复

### 6.6 对 SafeOps 的现实启发

OpenAI Agents SDK 不是替代你当前 agent 的东西。

它更像未来如果你要加：

- 智能分析
- 工具编排
- 多 agent 协作
- 批准后执行

时可用的上层框架。

## 7. 横向比较：到底谁更像你的方向

如果从“像不像 SafeOps 当前方向”看，我会这么排：

### 最像当前执行层

1. StackStorm
2. Rundeck

原因：

- 都强调工作流、动作、审计、执行
- 都不是纯粹的 LLM 框架

### 最像未来采集层

1. OpenTelemetry Collector

原因：

- 它给你的是“采集标准化”的参考答案

### 最像未来 AI 分析层

1. PagerDuty SRE Agent
2. LangGraph HITL
3. OpenAI Agents SDK

原因：

- SRE Agent 提供事故调查与知识复用思路
- LangGraph HITL 提供审批边界思路
- OpenAI Agents SDK 提供可工程化的 agent runtime

## 8. 对 SafeOps 的推荐演进路径

如果把这些官方方案真正转化成你的路线，我建议顺序是：

### 第一步：继续强化当前非 LLM 执行层

优先补：

- action 输入输出结构
- run id / trace id
- workflow 失败路径
- 审计日志
- 模板化配置

### 第二步：逐步补事件驱动和标准采集

优先借鉴：

- StackStorm 的 trigger / rule 模型
- OTel Collector 的采集层思路

### 第三步：只把 LLM 放到分析层

优先做：

- 事故摘要
- runbook 检索
- 历史案例总结
- guided triage

### 第四步：如果未来真的要让 LLM 介入执行

必须先有：

- human-in-the-loop
- 可中断恢复
- 审批流
- 权限分层
- 命令白名单

## 9. 一组我认为最值得你自己动手跑的内容

如果你真的想把这些知识学扎实，不建议只看一遍文章。建议按下面顺序动手：

### 9.1 StackStorm

```bash
st2 login st2admin -p 'Ch@ngeMe'
st2 action list --pack=core
st2 run core.local cmd="uptime"
st2 execution list
st2 rule list
```

然后再动手试：

```bash
st2 rule create /path/to/rule.yaml
st2 execution list -n 5
```

### 9.2 Rundeck

学习重点不是先装一堆集群，而是先理解：

- Job
- Workflow
- Node filter
- API 运行方式

最应该看的调用入口：

```http
POST /api/14/job/[ID]/run
```

带 options 的 body：

```json
{
  "options": {
    "input_key": "HelloWorld"
  }
}
```

### 9.3 OpenTelemetry Collector

先读最小 pipeline 配置：

```yaml
receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  debug:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
```

### 9.4 OpenAI Agents SDK

先跑最小 agent：

```python
from agents import Agent, Runner

agent = Agent(
    name="ResearchAgent",
    instructions="Explain operations tooling in a precise way."
)

result = Runner.run_sync(agent, "Compare StackStorm and Rundeck.")
print(result.final_output)
```

然后再理解：

- tools
- handoffs
- sessions
- HITL

## 10. 结语

如果把这篇文章收成一句话，我会这样说：

> 现代运维 agent 的正确方向，不是先让模型获得更高权限，而是先让系统拥有更清晰的结构、更严格的边界、更强的审计和更好的可恢复性。

对 SafeOps Agent 来说，当前最有价值的路线不是“马上变成一个全自动 LLM agent”，而是：

- 向 StackStorm 学事件与 workflow
- 向 Rundeck 学权限与 runbook
- 向 OTel 学标准采集
- 向 PagerDuty SRE Agent 学调查与知识复用
- 向 LangGraph / OpenAI Agents SDK 学审批与智能层

这样走，后面不管你是继续做非 LLM 版本，还是做受控的智能版本，都会稳得多。

## 参考资料

- StackStorm Overview: https://docs.stackstorm.com/overview.html
- StackStorm Actions: https://docs.stackstorm.com/actions.html
- StackStorm Workflows: https://docs.stackstorm.com/workflows.html
- StackStorm Orquesta: https://docs.stackstorm.com/orquesta/index.html
- StackStorm Sensors: https://docs.stackstorm.com/sensors.html
- StackStorm Rules: https://docs.stackstorm.com/rules.html
- StackStorm Traces: https://docs.stackstorm.com/reference/traces.html
- Rundeck Enterprise: https://docs.rundeck.com/docs/enterprise/
- Rundeck Introduction: https://docs.rundeck.com/docs/about/introduction.html
- Rundeck Jobs: https://docs.rundeck.com/docs/manual/jobs/index.html
- Rundeck Job Workflows: https://docs.rundeck.com/docs/manual/jobs/job-workflows.html
- Rundeck Workflow Strategies: https://docs.rundeck.com/docs/manual/jobs/workflow-strategies/
- Rundeck Authorization: https://docs.rundeck.com/docs/administration/security/authorization.html
- Rundeck Audit Trail: https://docs.rundeck.com/docs/administration/security/audit-trail.html
- Rundeck API: https://docs.rundeck.com/docs/api/
- OpenTelemetry Collector: https://opentelemetry.io/docs/collector/
- OpenTelemetry Collector Installation: https://opentelemetry.io/docs/collector/installation/
- PagerDuty SRE Agent: https://support.pagerduty.com/main/docs/sre-agent
- PagerDuty Agent Tooling Configuration: https://support.pagerduty.com/main/docs/agent-tooling-configuration
- PagerDuty Workflow Integrations: https://support.pagerduty.com/main/docs/workflow-integrations
- LangChain HITL: https://docs.langchain.com/oss/python/langchain/human-in-the-loop
- LangGraph HITL: https://docs.langchain.com/oss/python/langgraph/human-in-the-loop
- OpenAI Agents SDK: https://openai.github.io/openai-agents-python/
- OpenAI Agents SDK Agents: https://openai.github.io/openai-agents-python/agents/
- OpenAI Agents SDK Running Agents: https://openai.github.io/openai-agents-python/running_agents/
- OpenAI Agents SDK Handoffs: https://openai.github.io/openai-agents-python/handoffs/
- OpenAI Agents SDK HITL: https://openai.github.io/openai-agents-python/human_in_the_loop/