这篇文章的目标不是简单列一份名词清单，而是把几类和 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：事件驱动自动化的完整参考

官方资料：

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 里非常值得自己跑一遍的命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

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 定义。一个简化学习版长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

---
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 的典型命令：

1
2
3
4
5

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 的命令也很重要：

1
2
3

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 定义。 学习时你应该关心的不是语法细节本身，而是它表达了什么：

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

官方的创建方式大概是：

1

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：以运维作业为中心的平台

官方资料：

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：

1
2

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

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

1
2
3
4
5

{
  "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：现代采集层的标准答案

官方资料：

3.1 它真正解决的问题

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

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

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

3.2 你需要记住的组件模型

Collector 的核心组件是：

  • receivers
  • processors
  • exporters
  • connectors
  • extensions

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

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

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

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

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 调查与事故辅助层

官方资料：

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 安全边界的核心模式

官方资料：

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：构建智能层的工程化工具

官方资料：

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：

1
2
3
4
5
6
7
8
9

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

1
2
3
4
5

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

然后再动手试：

1
2

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

9.2 Rundeck

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

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

最应该看的调用入口：

1

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

带 options 的 body：

1
2
3
4
5

{
  "options": {
    "input_key": "HelloWorld"
  }
}

9.3 OpenTelemetry Collector

先读最小 pipeline 配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  debug:

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

9.4 OpenAI Agents SDK

先跑最小 agent：

1
2
3
4
5
6
7
8
9

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 版本，还是做受控的智能版本，都会稳得多。

参考资料