返回博客
X24LABS

Stitch Agent 入门指南 (v1)

最初的 v1 安装指南：两个 CI job、一个 Docker 镜像、几条环境变量。保留作为历史参考。

历史文章。 本指南描述的是 Stitch v1，它运行在你的 CI 流水线内部，通过 Docker 镜像分发。如果你今天要安装 Stitch，请改看 Stitch 2.0 入门。stitch-monitor / stitch-heal 两个 job 和 ghcr.io/x24labs/stitch 镜像已经不再维护。

安装 Stitch 用不了五分钟。你在 CI 配置里加两个 job，剩下的 Stitch 会处理。没有服务器，没有要管理的 API key，也没有要盯着看的面板。

前置条件

GitLab CI 配置

把这两个 job 加到你的 .gitlab-ci.yml：

stitch-monitor:
  stage: .post
  image: ghcr.io/x24labs/stitch:latest
  script:
    - stitch monitor
  when: on_failure

stitch-heal:
  stage: .post
  image: ghcr.io/x24labs/stitch:latest
  script:
    - stitch heal
  needs: ["stitch-monitor"]
  when: on_failure

stitch-monitor job 在任何上游 job 失败时激活。它读取日志并识别失败。stitch-heal job 接过诊断并生成修复。

两个 job 都用 .post stage，所以会在你常规流水线 stage 之后运行。它们只在 on_failure 时触发，这意味着流水线通过时它们消耗的计算时间为零。

GitHub Actions 配置

在 .github/workflows/stitch.yml 加一个工作流文件：

name: Stitch
on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  heal:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/x24labs/stitch:latest
    steps:
      - uses: actions/checkout@v4
      - run: stitch monitor && stitch heal

这个工作流会在你的 CI 工作流失败时触发。它会 checkout 代码、运行 monitor、打上修复。

之后会发生什么

当你的流水线失败时：

  1. Stitch 读取失败日志
  2. 识别错误类型和相关文件
  3. 生成有针对性的补丁
  4. 通过重跑失败的检查来验证修复
  5. 如果修复通过，它会把 commit 推到一个 fix 分支并开一个合并请求

你像审查其他代码改动一样审查这个 MR。默认情况下自动合并是关闭的，你决定修复何时落地。

配置

Stitch 可以零配置工作。对于想要更多控制的团队，你可以通过环境变量设置选项：

验证配置

推一个故意破坏 lint 规则或测试的 commit。看着流水线失败，然后看着 Stitch 接手。几分钟内你应该能看到一个新分支和一个合并请求。

如果有什么不工作，检查 Stitch 的 job 日志。里面有完整诊断和修复尝试过程中遇到的任何错误。

下一步

返回博客