software

将 block/goose 转变为 AI SRE 代理

发布: (2026年1月14日 GMT+8 09:25)
6 分钟阅读
原文: Dev.to

Source: Dev.to

Cristian Angulo

这正是我开始尝试使用 block/goose 作为一个 AI 驱动的 SRE 代理 的原因。

在本文中，我将解释我如何配置 Goose，使其表现得像真实的 SRE：查询 AWS CloudWatch、对事件进行推理，并在 完全可复现的 Nix 环境 中运行。

什么是 block/goose?

block/goose 是一个自主代理框架，旨在使用 LLM（大型语言模型）加外部工具执行工作流。可以把它看作是一个 CLI‑native AI operator，它可以：

  • 调用工具（APIs、CLIs、MCP servers）
  • 维护会话上下文
  • 执行多步骤推理循环

对于 SRE 来说，Goose 的有趣之处在于它 并不试图取代工具 —— 它 orchestrates 它们。

为什么需要 AI SRE 代理？

真实的 SRE 大部分时间都在做：

  • 在日志、指标和告警中进行调查
  • 重复相同的诊断步骤
  • 将基础设施状态与最近的变更进行交叉对照
  • 减少运维琐事

该仓库将 Goose 转变为一个可以：

  • 查询 CloudWatch 日志、指标和告警
  • 推理 AWS 基础设施健康状况
  • 按结构化的事故工作流进行操作
  • 充当首响应调查员

这 不是 ChatOps 的噱头——它是一个运营助理。

架构概览

该设置有三个支柱：

  • Goose 作为推理引擎
  • MCP 服务器作为工具提供者
  • Nix Flakes 作为环境编排器
Goose (LLM Agent)
   ├── CloudWatch MCP Server
   ├── AWS CLI
   ├── GitHub MCP (optional)
   └── Local tooling (jq, httpie, docker, task)

所有内容都在 可复现的开发 shell 中运行。

可复现的环境 (Nix)

和我所有其他项目一样，这个项目也由 flake.nix 驱动。

为什么？ 因为 SRE 工具链非常脆弱：

  • AWS CLI 版本
  • Node 与 Python 工具链
  • 通过 uvx 或 npx 使用的 MCP 服务器

Nix 消除了所有这些漂移。进入 shell 后，你已经拥有：

  • AWS 凭证
  • Goose CLI
  • CloudWatch 工具
  • JSON 处理工具

无需 README 仪式。无需“先安装这个”。

配置 Goose 作为 SRE 代理

提供者与模型

NIXPKGS_ALLOW_UNFREE=1
GOOGLE_GEMINI_MODEL_NAME=gemini-2.5-flash
GITHUB_PERSONAL_ACCESS_TOKEN=
SENTRY_ACCESS_TOKEN=

快速、低成本且擅长工具编排——非常适合 SRE 任务。

CloudWatch 作为一等工具

CloudWatch MCP 扩展

GOOSE_PROVIDER: google
GOOSE_MODEL: gemini-2.5-flash
extensions:
  cloudwatch:
    enabled: true
    type: stdio
    name: cloudwatch
    description: AWS CloudWatch Observability (metrics/logs/alarms) via awslabs.cloudwatch-mcp-server
    cmd: uvx
    args:
      - awslabs.cloudwatch-mcp-server@latest
    envs:
      region: us-east-1
      profile: default
      FASTMCP_LOG_LEVEL: ERROR
    env_keys: []
    timeout: 30000
    bundled: null
    available_tools: []
  github:
    enabled: true
    type: stdio
    name: github
    description: GitHub MCP Server
    cmd: npx
    args:
      - -y
      - "@modelcontextprotocol/server-github"
    timeout: 30000
  sentry:
    enabled: true
    type: stdio
    name: sentry
    description: Sentry MCP Server
    cmd: npx
    args:
      - -y
      - mcp-remote@latest
      - https://mcp.sentry.dev/mcp
    timeout: 30000

这使得代理能够：

  • 获取指标
  • 查询日志
  • 检查告警
  • 对时间序列数据进行推理

这正是 SRE 手动检查的相同数据——只是更快。

Goose 如何表现得像 SRE

与其用通用问题提示 Goose，我把它当作团队成员来对待。

示例

  • “调查过去 30 分钟内出现的 5xx 错误升高情况。”
  • “检查延迟是否与一次部署有关联。”
  • “汇总该服务的 CloudWatch 警报。”

Goose：

  1. 选择合适的工具
  2. 查询 CloudWatch
  3. 解释输出结果
  4. 给出可读的诊断报告

没有仪表盘。没有点击。只给出答案。

为什么这样有效

  1. 工具，而非插件 – Goose 不会凭空捏造指标；它查询真实的 AWS API。
  2. 可复现性 – 任何人都可以克隆仓库并获得 相同的 SRE 代理。
  3. 可组合性 – 您可以添加：
    • GitHub MCP（用于关联 PR）
    • PagerDuty
    • Terraform 状态检查
    • 自定义运行手册

代理会随您的基础设施演进。

进入环境

nix --extra-experimental-features 'nix-command flakes' develop --impure

为什么使用 --impure？

  • AWS 凭证
  • Docker 套接字
  • 本地 MCP 二进制文件

这是有意为之且受控的。

What This Is Not

  • ❌ 替代值班工程师
  • ❌ 神奇的“修复生产”机器人
  • ❌ 另一个 ChatOps 玩具

This is:

  • 首次响应调查员
  • 上下文收集机器
  • 为 SRE 提供的力量倍增器

结论

SRE 工作是基于模式、重复且高度可观察的。通过将 LLM 驱动的代理与真实、可复现的工具相结合，我们可以自动化事件响应中嘈杂、重复的部分，同时让人类在只能由工程师提供的细微决策中保持参与。Goose，由 block/goose 提供动力，展示了一条通往 AI 增强 SRE 的实用路径，该路径既 可信 又 可扩展。

程序化的。

这使它对 AI 代理 完美——只要它们：

  • 使用真实工具
  • 在真实环境中运行
  • 尊重操作边界

使用 block/goose、MCP 服务器和 Nix，你就能得到恰恰如此。

如果你对真正能做运维的 AI 代理感兴趣，这里是一个很好的起点。

Back to Blog

相关文章

阅读更多 »