代码

代码是你请 Status200 AI 在你的存储库中工作的地方，就像你请一个编程代理那样：修复 bug、编写测试、解释代码、做一处更改。它打开时显示你提出请求的输入框，在框中选择存储库和分支，下面是所有任务；任务的页面是一段你可以回复的对话。Status200 也会自行启动任务，来源包括异常、追踪和调查。Runner 会克隆存储库，在新分支上编写更改，构建并测试它，然后打开拉取请求。每个拉取请求都由人来审查和合并：Runner 只能推送分支和打开拉取请求，仅此而已。

在存储库中请 AI 工作#

1. 打开代码#

   打开 产品 → 代码。页面以 要让 AI 做什么？ 开头，下面是你提出请求的输入框，再下面是所有任务，最新的在前。还没有存储库时，会改为提供 连接 GitHub（请参阅 开始之前）。侧边菜单中的 存储库 列出 AI 可以在其中工作的存储库，GitHub App 已无法访问的存储库则收在 未连接 下。每个存储库的页面也有同样的输入框，用于该存储库。

2. 选择存储库和分支#

   输入框从你上次选择的存储库开始。在它底部一行选择另一个存储库，并在旁边选择任务的起点分支：在你选择其他分支之前，是标有 默认 的存储库主分支。AI 从你选择的分支创建自己的分支，并向它打开拉取请求。

3. 说出你想要什么#

   用你自己的话写下更改、bug 或问题。在还没有提出任何请求时，代码会在 试试这样问 下给出几个示例。

4. 添加上下文#

   点击 添加上下文，把 AI 需要的东西交给它：存储库中的文件或文件夹、一条备注、一个链接，或项目中的一条记录。Status200 会在你发送请求时以你的权限读取每条记录，并保留交给 AI 的内容。

5. 开始任务#

   点击 开始任务，或按 Enter。任务的页面会打开，AI 的工作会在发生时显示在那里。

一个请求最多带 10 项上下文。Status200 读取的内容中的令牌、密钥、密码和电子邮件地址会在 AI 看到之前被遮盖，和 Status200 AI 读取你的数据的其他所有地方一样。

任务的对话#

任务的页面是一段对话：先是请求的内容和添加的上下文，然后是 AI 的回合——它边做边显示的步骤（读取和编辑的文件、搜索的内容、运行的命令）、它的回复、它更改的文件及其 diff，以及拉取请求。页面顶部显示任务在哪里工作（它的存储库和起点分支）、更改了多少行、一个指向其拉取请求的按钮，以及任务的状态：

要继续，请在底部的输入框中书写，它会在对话滚动时保持可见：回答 AI、添加上下文或要求更改。每条回复都是同一任务的下一个回合：在拉取请求仍然打开时，它在同一分支上工作，并推送到同一个拉取请求。一个任务一次只进行一个回合，所以 AI 工作时输入框会等待。每个回合的 日志 是它所做之事的逐字记录。

能读取存储库的人就能读取它的任务。请 AI 工作、回复和停止任务需要编辑该存储库的权限，查看更改的 diff 也一样：其他人只能看到哪些文件发生了更改。Status200 自行启动的任务（见下文）也在它们的存储库中，同样是你可以回复的对话。

修复运行的过程#

1. 你在代码中点击 开始任务，或在未解决的异常上点击 用 AI 修复，或者由其他按钮或触发器启动任务（请参阅 修复任务从哪里启动）。
2. 任务在其存储库的队列中排队，由存储库选择的 Runner 领取：你的某个 Runner，或者在存储库没有选择时，由全局 Runner 领取（参见 选择存储库的 Runner）。
3. Runner 获取任务的上下文。对于请求，就是它的内容、添加的上下文和到目前为止的对话；对于异常，就是它的类型、消息和堆栈跟踪。
4. 它把存储库克隆到自己的工作区并创建分支。异常修复的分支名为 oneuptime-fix-exception- 加上运行 id 的前几个字符。请求从提出时选择的分支开始，其拉取请求也向该分支打开。回复则改为在任务已打开的拉取请求的分支上工作。
5. 由项目的 LLM 提供商驱动的代码代理读取代码并编写更改。LLM 调用由 Status200 服务器发出，因此 Runner 从不持有你的提供商的 API 密钥，并且每次调用都会被计量并列在 AI 日志中。异常、慢追踪或事件的修复在工作时还会读取生产环境：存储库对应服务的异常、追踪、日志和指标（请参阅 修复中的生产遥测）。
6. 在你自己的 Runner 上，代码代理会在提交任何内容之前，按存储库的 AGENTS.md 所说的方式构建并测试它的更改，并修复失败的部分（请参阅 拉取请求之前的验证）。
7. Runner 提交、推送分支、打开拉取请求（对于请求，只在更改了代码时），然后删除工作区。

启动任务的页面会实时显示其状态。每个任务都列在 产品 → 代码 中它所在的存储库下：任务的页面就是它的对话，每个回合的 日志 中，Runner 读取或写入的每个文件和运行的每条命令各占一行。

每次运行都受服务器强制执行的预算约束：最多 40 次 LLM 调用 和 100,000 个输出令牌。运行中对生产遥测的查询也计入这 40 次调用。达到其中之一的运行会以迄今为止工作的摘要结束，而不是陷入循环。当项目设置了每日 AI 限制时，修复运行也计入这些限制。

修复任务从哪里启动#

这些按钮只出现在能够启动任务的地方。项目关闭 AI 时，它们都不会出现，异常的侧边菜单中也没有 AI Assistance。改进日志 和 改进跟踪 在连接代码仓库后出现，使用 AI 修复性能问题 只出现在值得修复的追踪上（参见 跟踪浏览器）。函数的 用 AI 修复 只会出现在应用自身的代码上：它占性能剖析时间或内存的 5% 以上，或者与对比的时间窗口相比占比增长了 3 个百分点以上（参见 持续性能分析）。

要打开异常的 AI Assistance 页面，请在 产品 → 可观测性 → 异常 下打开该异常，然后在侧边菜单中选择 AI Assistance。已解决或已归档的异常需要先标记为未解决。

Status200 AI 也会自行启动修复任务：来自发现代码更改的调查，来自因缺少遥测而没有结论的调查，以及来自关于异常和慢追踪的 AI Insights。每种都有自己的开关；请参阅 自动代码修复。

修复中的生产遥测#

Status200 掌握着你的代码在生产环境中的实际表现，因此修复不必只凭一条堆栈跟踪来工作。代码代理在工作时，可以查询该存储库对应的服务的生产遥测：

拉取请求的描述会写明代理查询了什么，以及查询结果显示了什么。其他任务，例如回归测试以及日志或跟踪改进，不会查询生产环境。

代理能读取什么，由 Status200 服务器根据任务本身决定：

• 只读。 查询在 Status200 服务器上运行，从不在 Runner 上运行，Runner 不持有任何能读取遥测的凭据。查询所做的任何事都无法更改你的项目。
• 仅限本项目，且仅限此存储库对应的服务。 你无需映射它们：它们是 Status200 认定与此存储库对应的服务，认定方式与它为修复查找存储库的方式相同——这些服务的异常堆栈跟踪经过该存储库的文件、服务与存储库同名，或者该存储库是项目中唯一的存储库。其他服务的遥测无法读取。
• 不读取私密事件，并且令牌、密钥、密码和电子邮件地址会在代理看到结果之前被遮盖，和 Status200 AI 读取你的数据的其他所有地方一样。
• 有上限。 每次运行最多 12 次查询，每次查询都计入运行的 40 次调用。

当没有服务对应到该存储库时，任务会像以前一样在没有生产遥测的情况下运行。

拉取请求的生产审查#

Status200 知道你的代码在生产环境中做了什么，因此它能用阅读 diff 的人看不到的信息来审查拉取请求。在代码中打开存储库的 设置 页面，在 更多设置 下开启 根据生产环境审查拉取请求 后，拥有写权限的人每打开或推送一个拉取请求，都会收到一条评论，说明生产环境对其所改代码的显示。每次推送时，这条评论都会原地更新，代码中存储库的 生产审查 页面会保存每次审查，并提供 重新审查。

当生产环境显示出问题时，Status200 AI 会把它与 diff 一起阅读，并加上 需要关注的问题：几条简短要点，每条都基于事实。它只在项目开启 AI 时运行，每个拉取请求每天最多 10 次，每个存储库每天最多 100 次，并像所有 AI 调用一样计量；事实每次都会在不使用 AI 的情况下读取。当生产环境对更改没有任何显示时，Status200 不会发布任何内容。

• 只有汇总数据。 评论只包含计数、耗时和代码名称：绝不包含异常消息、日志行、事件标题或个人数据。
• 公开存储库只得到链接。 任何人都能阅读公开存储库的拉取请求，因此在那里评论只链接到 Status200 中的审查，只有项目成员才能打开。存储库 设置 页面中 更多设置 下的 生产审查评论 可以在所有存储库发布 仅审查链接，或选择 即使是公开存储库也显示审查。
• 外部贡献者无法发起审查。 只有当拉取请求的作者以及向其推送的人都能写入存储库时，它才会被自动审查。其他人的拉取请求 - 外部贡献者、fork、机器人 - 会在拥有写权限的人评论 @oneuptime production review，或在代码中点击 重新审查 时被审查。
• 只读。 审查不克隆任何内容，也不运行拉取请求中的任何内容。它的 diff 和标题对 Status200 AI 来说是数据，绝不是指令：AI 没有任何工具，它写的内容会以文本形式放进评论。

对于 GitHub App 从现在起连接的存储库，此开关默认开启。在它出现之前连接的存储库会保持关闭，直到你开启它。

拉取请求之前的验证#

存储库在根目录的 AGENTS.md（编码代理读取的文件）中说明如何构建和测试它。代码代理在更改任何内容之前，会从任务起始的分支读取存储库的 AGENTS.md（没有 AGENTS.md 时读取它的 CLAUDE.md），并按其中所说的方式工作。两者都没有时，它会从存储库的 CONTRIBUTING.md、README、包脚本、Makefile 或 CI 工作流中了解做法。无需在 Status200 中进行任何设置。

来自 fork 的拉取请求中的任何内容都不会被当作存储库的指令读取：修订会拒绝这样的拉取请求，审查则读取基础分支。

存储库上设置的命令#

代码不再要求填写安装、构建和测试命令，但已有这些命令的存储库（之前设置的，或通过 API 或 Terraform 设置的）会保留它们。它们以只读方式显示在存储库 设置 页面 更多设置 下的 构建和测试命令 卡片上，移除命令 会移除全部三条。只要设置了其中任何一条，你自己的 Runner 上的每次修复运行都会在打开拉取请求之前也用它们检查自己的更改：

1. 代码代理完成后，这些命令会在 Runner 上克隆的工作区中、存储库的根目录下按顺序运行。每条命令最多运行 15 分钟，并带有 CI=true，因此不会有任何东西等待输入；第一次失败就会停止这一轮。
2. 失败时，失败命令输出的末尾会作为修复任务交回同一个代码代理，并指示它修正自己的更改，而不是削弱或跳过测试，然后再次运行这些命令。它最多进行 2 次修复尝试。这些尝试共享运行的 LLM 预算，它们的改动与修复进入同一个提交。
3. 结果（通过、失败或跳过，跳过表示未设置命令或使用全局 Runner）会写入拉取请求描述中的 Verification 部分，并记录在任务的拉取请求上。

仍未通过验证的更改不会被丢弃：拉取请求照样打开，并带有一个醒目的 "Verification failed" 部分，写明失败的命令，并以它的输出结尾。工作得以保留，由审查者决定。没有设置命令的存储库会被报告为已跳过，而不是暗示构建通过。

这些命令是你的团队编写的存储库设置，在你自己的 Runner 上运行：与运行手册的 Bash 步骤相同的信任模型。AI 从不编写或更改它们。Status200 为所有项目运行的全局 Runner 从不运行它们：在全局 Runner 上，修复会被写好并打开以供审查，验证报告为跳过，由你的存储库自己的 CI 检查这次更改。若要在拉取请求打开之前构建并测试修复，请运行 你自己的 Runner。

修复合并之后#

合并修复并不能修复任何问题，只有运行起来才算数。修复拉取请求合并后，Status200 会等待包含它的已记录部署（参见 部署与变更），并在那次部署中观察修复的目标。Code 中任务的拉取请求会说明结果，异常的 AI Assistance 页面、事件的 AI 日志以及修复来源的 AI 洞察也会说明：

在部署交付修复之前，修复显示为 已合并，等待部署，观察期间显示为 已部署，正在生产环境中观察。14 天内没有任何已记录部署包含的修复，或生产环境无法判断的修复，显示为 未在生产环境中验证。规则见 自动代码修复。回归测试、更好的错误处理、审查以及 Code 中的请求不会被观察：生产环境无法显示它们改变了什么。

开始之前#

任务需要三样东西。代码的请求输入框和异常的 AI Assistance 页面会在提供启动之前检查这三样，并说明缺少什么。

在自托管实例上，全局提供商是 config.env（Docker Compose）或你的 Helm values 中的一个配置块。对于自托管的 Ollama：

GLOBAL_LLM_PROVIDER_TYPE=Ollama
# An address the Status200 server can reach, never localhost.
GLOBAL_LLM_PROVIDER_BASE_URL=http://ollama:11434
GLOBAL_LLM_PROVIDER_MODEL_NAME=llama3.1
# No GLOBAL_LLM_PROVIDER_API_KEY needed — Ollama is keyless.

任何受支持的提供商都可以使用：所有提供商和每个环境变量请参阅 LLM 提供商。

你无需把存储库映射到服务。任务启动时，Status200 会把异常堆栈跟踪中的文件路径与你已连接的存储库进行匹配，从而找到存储库。如果没有匹配，它会退而使用与服务同名的存储库，再退而使用项目中唯一的存储库（当只有一个时）。AI Assistance 页面会显示它找到的存储库。

选择存储库的 Runner#

每个存储库都会选择 AI 在其中工作所用的 Runner：在代码中它的 设置 页面上，展开 更多设置，点击 Runner 卡片上的 编辑 并选择一个。GitHub App 导入的存储库在项目有 默认 Runner 时从它开始。没有选择的存储库在 全局 Runner 上工作，它由 Status200 为所有项目运行。

只有存储库选择的 Runner 才会收到它的任务和它的令牌。在 运行手册 → Runbook 代理 下关闭 使用全局 Runner 的项目中，每个存储库都需要项目自己的某个 Runner。Runner 的页面会列出选择了它的存储库。

运行你自己的 Runner#

要在其他地方运行 Runner，例如在靠近你的存储库的机器上：

1. 创建 Runner#

   在 运行手册 → Runbook 代理 下创建一个 Runner，然后点击它所在行的 显示设置说明。该命令中嵌有 Runner 的密钥，只有 Project Owner、Project Admin 或 Runbook Admin 可以读取。它看起来像这样：

   Bash

   docker run --name status200-runner --restart unless-stopped \
     -e STATUS200_RUNNER_ID=<runner-id> \
     -e STATUS200_RUNNER_KEY=<runner-key> \
     -e STATUS200_URL=<your-status200-url> \
     -d status200/runner:release

2. 为存储库选择它#

   在代码中存储库的 设置 页面上，展开 更多设置，点击 Runner 卡片上的 编辑 并选择该 Runner。Runner 会在下一次 heartbeat 时获取这一更改，大约一分钟之内；无需重启任何东西。

3. 检查它是否已连接#

   一两分钟内，Runner 会在 运行手册 → Runbook 代理 页面上显示为已连接。如果没有，请查看容器的日志（docker logs status200-runner），找出凭据或网络错误。

任何运行容器的方式都可以（Docker Compose、Kubernetes 等），只要它有这些变量，并且能通过 HTTPS 访问你的 Status200 实例：

来自调查的自动代码修复#

当 AI 调查 在事件或警报上发布根本原因分析，并且它审慎的分类建议修改代码时，调查卡片会提供 Open Fix PR from this analysis：一个以发布的分析为全部上下文的修复任务。当补救措施属于运维、仅涉及基础设施、来自外部、属于预期的拒绝、用户错误或没有结论时，该按钮会隐藏。只要 事件 → 人工智能 → 设置 的 自动修复新事件 （以及 警报 → 人工智能 → 设置 的 自动修复新警报）处于开启状态，符合条件的修复就无需点击即可进行。修复初始是关闭的，新项目也是如此。没有 AI 规则时，每个符合条件的修复都会打开；有规则时，只为规则匹配的对象打开，前提是该规则开启了 修复拉取请求 （新规则默认开启），并且只在它指定的代码存储库中打开。

修复开启时，以一个可信、有证据、可由代码更改修复的根本原因结束的调查，会把按钮创建的同一个修复任务放入队列。这一决定是服务器检查的受约束分类，绝不是对分析文本的模式匹配：只有对代码修复的肯定判定才会打开拉取请求。缺少证据、补救措施在代码之外以及分类失败，最终都不会做任何事。

其他一切都与按钮相同：

• 拉取请求以可供审查的状态打开，根据发布的分析编写，并且需要一个通过 GitHub App 连接的存储库（匹配的规则指定了存储库时，须是其中之一），以及一个在线、能在其中工作的 Runner：存储库选择的那个，或全局 Runner。
• 它计入该信号的每日修复任务限制（Daily Incident AI Fix Task Limit 或 Daily Alert AI Fix Task Limit，位于其 AI 设置页面的 更多设置 下）以及存储库的未关闭拉取请求上限，前提是其中之一已设置。未设置时，两者都不会限制任何东西。
• 每个触发器都会先查找同一事件或警报已在队列中或正在运行的修复任务，因此一个自动触发器和一次点击通常只会变成一个任务，而不是两个拉取请求。这项检查是写入前的读取，而不是锁，所以恰好在同一时刻的两个触发器仍可能都通过。
• 运行由系统写入，不记在任何人名下，也不会自行合并任何内容。

修复失败时#

隐私#

你的存储库的克隆位于 Runner 容器内的工作区中，运行结束时无论成功与否都会被删除。Runner 从不持有你的 LLM 提供商的 API 密钥：Status200 服务器代它发出 LLM 调用，生产遥测查询也由服务器运行。Status200 不保留你的存储库，也不会用你的代码进行训练。任务的日志会保留每个步骤输出的前 300 个字符，以便你检查 Runner 做了什么，其中可能包含代码片段。用你自己的 LLM 提供商（包括本地 Ollama）运行自托管的 Runner，你的代码就永远不会离开你的基础设施。

路线图#

已计划，目前尚不可用：

• GitLab 支持。 存储库只能通过 GitHub App 连接。

后续步骤#