快速开始

理解 SprintLoop 最快的方式，是推一个小改动跑一遍。本页带你从一个冷启动的工作区，走到一个你签字放行的 lane 中由 agent 写出来并被 merge 的 pull request。规划十五分钟；如果你的 CI 慢，预算三十分钟。

你需要：一个你能 push 的 GitHub repo、一台装了 git 的工作机器，以及你想先竞速的那个 harness 对应的 Anthropic、OpenAI 或 Google AI API key。三个 key 一起带来也行——竞速这块界面在两个或以上时才有意思。

1. 注册并创建工作区

打开 https://app.sprintloop.ai/signup，用 Google、Microsoft 或邮箱登录。首次注册会创建一个带单座位的个人工作区——以后可以升级为组织工作区，不会丢历史。

进去后按 Cmd+K 打开命令面板，执行 Workspace settings → Identity。设一个工作区 handle（小写字母数字，如 acme）——这是出现在 lane 标题、审计导出、federation 收据里的名字。可读的显示名可以随便改；handle 不可改，以保持审计链稳定。

2. 连接仓库

Settings → Integrations → GitHub → Install the GitHub App。选择拥有目标仓库的 org 或个人账号，然后授权给 SprintLoop 想 dispatch lane 的具体那些仓库。这个 app 需要 contents: write、pull_requests: write、checks: read、members: read。它不申请 secrets、packages 或 admin endpoint 的权限。

安装完成你会回到 SprintLoop，每个已连接仓库一行绿色状态。挑一个，点 Open lane。工作区会准备一条作用域指向该仓库 main 分支的空 lane，等你给 brief。

本 walkthrough 的剩余部分，请使用沙箱仓库或一个功能分支——lane 会真的开一个 PR。

3. 带一个模型 key

Settings → Models → Add provider。粘贴 Anthropic、OpenAI、Google 或 Mistral 的 key。Key 加密存储，从不写日志。工作区在保存前会发一次单 token 请求验证 key 是否有效——这会扣不到一分钱，并把明显错误（撤销过的 key、错误 region）挡在真正 dispatch 之前。

可以加多个 provider。dispatch 界面上的 harness picker 只会展示有 key 的 harness。

4. Dispatch 第一条 lane

按 Cmd+N 打开 dispatch 对话框，或点左侧 + Lane。选已连接的仓库，给 lane 起个标题（第一次任务用 "Add a /healthz endpoint that returns commit SHA" 不错），选一个 harness——Claude Code、Codex、Cursor Compose、Aider 或 Devin。如果你有多个 key，Race 选项可用：选两到三个 harness，SprintLoop 会把同一个 brief 并行跑过每个 harness 并比较 diff。

点 Dispatch 之前，给 lane 划作用域：agent 能动仓库里的哪些路径？默认是整个仓库，但对第一条 lane，缩小作用域是有价值的——healthz endpoint 用 apps/api/healthz/** 和 package.json 就够。如果 agent 试图写作用域外的路径，会在存储层被拒。

点 Dispatch。不到一秒你就会在 lane 页上。

5. 看 lane 在跑

Lane 页有三个流：

Tool log —— harness 做的每一次 read、write、shell 命令、模型调用。每一条在追加前都被签名，页面会展示签名头一路向前。
Live diff —— agent 在工作树上的改动，每隔几秒刷新。
Sign-off —— 页面底部的槽，由你（或审批人）接受或拒绝该 lane。

第一条 healthz lane 通常 60–90 秒完成。harness 发”完成”信号后，Review Committee（Architect、Security、QA）会在右栏渲染各自判定。判定有三种：Looks good、Has questions、Block。Block 意味着至少有一位 reviewer 发现了一件严重到要把 merge 按钮禁用的问题，直到你做出覆盖。

6. 签字放行并 merge

在 sign-off 槽点 Approve。工作区会弹出一次内联确认（你在声明自己审过了 diff）。Approve 之后，SprintLoop：

用 lane 的签名 commit message 把分支 push 到已连接的 GitHub remote。
通过 GitHub API 开一个 pull request，正文里写入 brief、所用 harness、所调模型版本，以及指向 lane 审计页的链接。
把 lane 的链头戳进 federation root，并把收据写进工作区的 evidence/ bucket。
关闭这条 lane。

GitHub 会把 PR 走你平时的 CI。CI 过了，就像其他 PR 一样去 merge。如果你有要求 approval 的 branch protection，SprintLoop 的 sign-off 不能替代 GitHub 这边的人工 reviewer——它是内部的声明，不是 GitHub review。

刚刚发生了什么

你把一个 agent dispatch 到了一个有密码学溯源的、有边界的执行上下文里。它的每一个动作都被记录并签名。一组 reviewer agent 在你之前读了 diff。merge 产出一个 PR，六个月后你的团队还能审。

这就是整个闭环。文档里剩下的——竞速、Context Engine、MCP、Review Committee 的调优——都是把这个环收得更紧。

接下来去哪

Lanes —— 你刚刚用过的那个原语。值十分钟。
Harness 竞速 —— 怎么把同一个 brief 同时 dispatch 给两三个 harness。
API 参考 —— 如果你想从自己的系统里脚本化 dispatch lane。

如果出岔子，第一条 lane 最常见的卡点是作用域 claim 错了（agent 想动作用域外的文件然后停住）。把作用域放宽再 dispatch——工作区会记得你上次的 brief。