学习如果想有成效，就必须专心。学习本身是一件艰苦的事，只有付出艰苦的劳动，才会有相应的收获。——谷超豪

Open-Inspect：让编码代理在后台持续推进工作的开源系统

项目地址：https://github.com/ColeMurray/background-agents

写代码这件事，常常并不只发生在编辑器前的一段专注时间里。

一个需求需要拆解，一处异常需要排查，一组改动需要验证，多个仓库之间可能还存在相互关联的调整。真正耗时的部分，往往不是发出第一句指令，而是等待环境准备、等待代码分析、等待任务执行、等待结果回传，以及等待一个能够被审阅的拉取请求出现。

Open-Inspect 是一个开源的后台编码代理系统。它受到 Ramp Inspect 的启发，目标是让编码任务能够在后台运行：当人们继续处理其他工作时，代理可以在独立的开发环境中完成任务、处理代码、创建拉取请求，并通过网页、Slack、GitHub 拉取请求、Linear 问题或 Webhook 等入口与团队协作。

它试图将编码代理从一次性的对话窗口，变成一个持续运转的工作单元。

不必守在屏幕前等待任务结束

Open-Inspect 的核心，是后台运行的编码代理。

用户可以提交任务，然后将注意力转向别的事情。代理会在后台环境中继续工作，并拥有 Node.js、Python、git、浏览器自动化、VS Code 等开发工具。它不是只接收一句指令后给出文本回答，而是能够在完整开发环境中展开实际的软件开发工作。

这种形态让任务执行拥有了更清晰的节奏：

人发出需求
系统准备会话与沙箱
代理在后台处理工作
会话持续流式回传状态与结果
代码改动可以形成拉取请求
团队成员能够进入同一个会话，实时观察与协作

后台代理并不意味着过程不可见。相反，Open-Inspect 将会话、实时状态、事件流、产物与协作成员放入系统中，使任务能够在后台推进，也能够被前台观察。

从网页到 Slack，从 GitHub 到 Linear

编码工作并不总是从同一个入口开始。

有时，任务来自网页中的一段需求描述。有时，团队成员在 Slack 中提到一个机器人。有时，代码审查中的拉取请求需要自动检查。有时，一个 Linear 问题本身就是开发任务的起点。有时，外部系统通过 Webhook 发来信号，希望自动触发后续工作。

Open-Inspect 为这些工作入口提供了连接方式。

Web UI

网页界面提供完整的会话管理能力，包含实时流式输出、模型与推理强度选择、终端面板，以及多人协作状态。

在这里，会话不再只是孤立的一次交互，而是一段可管理的任务过程。用户可以创建会话、查看任务状态、观察沙箱运行情况，并通过界面继续补充指令。

Slack Bot

Slack 机器人支持通过提及或私信启动会话，也支持 PNG、JPEG、WebP 与 GIF 作为提示附件。任务执行后的结果会回到对应的消息线程中。

Slack 中的交流通常快速、碎片化且与上下文紧密相连。将编码会话放进消息线程，意味着任务可以从团队原本的沟通位置自然发起。

GitHub Bot

GitHub 机器人可以在拉取请求打开时进行自动审查，也可以响应拉取请求评论中的提及。相关配置可以按仓库进行设置。

这让代理能够进入代码审查的现场。当代码变更已经摆在拉取请求中时，机器人可以围绕这一变更启动工作。

Linear Bot

Linear 机器人支持在问题中提及或分配代理，以启动编码会话。它能够发布进度活动，并将最终形成的拉取请求与问题关联起来。

需求、问题、进度与代码变更由此拥有了一条连续的路径：从问题开始，到任务执行，再到拉取请求。

Webhooks

Webhook 为外部系统提供了通过已认证 HTTP POST 触发会话的方式。对于已有事件系统、内部平台或外部服务而言，这使编码代理能够成为自动化流程中的一个执行环节。

一个会话，可以容纳多人协作

Open-Inspect 支持多人会话。

多个用户可以进入同一个会话中协作，系统会显示当前活跃成员，并将实时流式信息同步给所有已连接的客户端。不同成员发出的提示会与其身份关联，提交中的作者信息也会反映提示的发起者。

这让代理会话不仅是人与机器之间的单线沟通，也可以成为团队共同参与的工作空间。

在一个多人会话里，团队成员可以同时关注任务进展。有人提出初始需求，有人补充约束，有人查看终端输出，有人等待结果。代理继续执行，信息则持续流动。

对于协作开发而言，任务本身通常不属于某一个人的孤岛。Open-Inspect 让会话具备了多人同时参与的能力，使背景中的自动化工作也能拥有共同的上下文。

提交归属，让提示与代码作者保持连接

当代理根据提示修改代码并产生提交时，提交归属是一个重要问题。

Open-Inspect 会将提交归属到发送提示的用户。README 中给出了对应的 git 身份配置方式：

await configureGitIdentity({
  name: author.scmName,
  email: author.scmEmail,
});

这种设计让提交记录能够保留提示发起者的信息。对于多人协作的会话而言，不同用户提出的工作请求不会在提交历史中失去来源。

系统也支持创建拉取请求，并使用用户的 GitHub OAuth Token 创建拉取请求，以保证归属正确，同时使用户只能在自己拥有写权限的仓库中创建拉取请求。

对于通过其他方式登录而没有源代码管理令牌的用户，拉取请求会回退到共享 GitHub App 机器人。

一次会话，处理多个仓库

许多真实任务并不局限于一个仓库。

一次改动可能涉及服务端、前端、共享库或多个独立项目。Open-Inspect 支持多仓库会话，让一个会话能够在同一个沙箱中处理多个仓库。

用户可以在创建会话时选择最多十个仓库。这些仓库会并排克隆到同一个沙箱中，代理可以进行协调修改，并为每个仓库创建对应的拉取请求。

系统也支持环境这一概念。

环境可以保存为一个具名的仓库集合，并拥有自己的密钥范围与可选预构建镜像。对经常需要一起工作的仓库而言，环境让多仓库协作不必每次都从头选择。

一个环境可以承载一组固定的工作上下文：哪些仓库会一起出现，哪些密钥会被注入，是否使用预构建镜像。它让多仓库任务拥有可复用的起点。

为重复工作准备的托管技能

编码代理的能力不仅来自模型，也来自任务开始前得到的指令与资料。

Open-Inspect 提供托管技能能力，用于创建可复用的指令和辅助文件，并在会话启动时提供给代理。

这些技能可以被分配到全局范围，也可以分配给指定仓库或环境。用户还可以保存个人配置文件，以便反复使用常见的技能组合。每个会话能够固定使用特定的技能版本，从而让行为具有可重复性。

对于经常出现的工程规范、开发流程、项目约束或任务类型，可复用的技能让代理不必每次都从零开始理解要求。

它像是为代理准备的一套工作手册：会话启动时，代理能够带着这套手册进入任务，而不是只带着一条临时输入。

从预热到快照，让会话更快进入工作状态

启动速度决定了后台代理是否足够自然地融入日常工作。

Open-Inspect 在会话启动上采用多层预热机制。

文件系统快照

每次提示之后，沙箱状态都会被保存。后续会话可以恢复已有状态，而不是重新克隆仓库。

这使连续任务能够延续之前的工作空间。代码、依赖、环境状态与已有上下文不必完全从头准备。

预构建镜像

预构建镜像可以按仓库或按环境启用。镜像每三十分钟使用最新提交与依赖重新构建。

当仓库或环境已经具备可用镜像时，新会话能够更快获得相应的开发基础。

主动预热

当用户开始输入提示时，沙箱就可以开始启动，而不必等到按下发送键。

输入尚未结束，环境已经开始准备。这种提前发生的动作，让等待时间被尽可能压缩到后台。

多模型支持，让代理选择更贴近任务

Open-Inspect 支持多个模型提供方，并且可以为每个会话选择模型与推理强度。

支持范围包括 Anthropic Claude、OpenAI Codex、xAI Grok、OpenCode Zen 与 Z.AI Coding Plan。

README 中列出的模型包含：

提供方	模型
Anthropic	Claude Haiku 4.5、Sonnet 4.5、Sonnet 4.6、Sonnet 5、Opus 4.5、Opus 4.6、Opus 4.7、Opus 4.8、Opus 5、Fable 5、Fable 5.1
OpenAI	GPT 5.4、GPT 5.5、5.3 Codex、5.3 Codex Spark
xAI 与 SuperGrok	Grok 模型
OpenCode Zen	Kimi K2.5、Kimi K2.6、Kimi K3、MiniMax M2.5、Qwen3.7 Max、GLM 5、GLM 5.1、GLM 5.2
Z.AI Coding Plan	GLM 5.2、GLM 5.3

OpenAI 模型可以通过现有的 ChatGPT 订阅使用 OAuth 方式接入，而不需要单独的 API Key。

Anthropic 模型可以通过连接 Claude 订阅的 Claude Agent Harness 运行。Grok 模型可以通过符合条件的 SuperGrok 订阅，借助控制平面管理的 OAuth 使用。

模型选择不再被固定在系统的一处，而是可以随会话变化。不同任务可以拥有不同的模型选择与推理强度。

每个会话，都在独立沙箱中运行

Open-Inspect 的每个会话都运行在隔离的沙箱后端中。

沙箱中预装了以下开发环境与工具：

Node.js 22
Python 3.12
Bun
git
GitHub CLI
build-essential

除了基础开发工具，沙箱还提供浏览器自动化能力。agent-browser CLI 搭配无头 Chromium，可用于截图、视觉差异比较与界面验证。

系统也提供可选的浏览器版 VS Code，并可通过 code-server 连接到会话工作区。终端通过 ttyd 提供，并可从会话界面访问。

对于需要运行本地开发服务的任务，系统支持通过加密隧道暴露最多十个开发服务器端口。对应地址会在 .openinspect/start.sh 执行前写入沙箱中的 /workspace/.tunnels.env。

在密钥处理上，系统使用 AES-256-GCM 加密。密钥可以按全局、仓库或环境范围进行配置，并在沙箱启动时以环境变量方式注入。系统也支持批量粘贴导入 .env 内容。

沙箱不是只有代码目录的一块临时空间，而是一个围绕开发任务构建的工作环境：工具、终端、浏览器、编辑器、端口与密钥，都能够在会话需要时进入其中。

控制平面与数据平面，各自承担不同职责

Open-Inspect 的整体架构分为控制平面与数据平面。

控制平面运行在 Cloudflare 上，承担会话管理、实时通信、事件流、GitHub 集成与密钥相关能力。每个会话对应 Durable Objects，内部包含 SQLite 数据库、WebSocket Hub、事件流与 GitHub 集成。

共享状态保存在 D1 数据库中，包含仓库范围的密钥等信息。

数据平面则是沙箱后端。每个会话拥有自己的沙箱，其中包含 Supervisor、Harness 与 Bridge。Harness 可以使用 OpenCode 或 Claude。沙箱运行于完整开发环境中，并通过 Bridge 与控制平面连接。

这种结构让系统中的不同部分各司其职：

控制平面管理会话状态与实时连接
沙箱负责实际执行编码工作
GitHub 集成处理仓库访问与拉取请求
密钥以加密形式保存，并在沙箱启动时提供
客户端通过网页、Slack、GitHub、Linear 与 Webhook 进入系统

并行子任务，让复杂工作不必排成长队

复杂任务通常可以被拆成多个部分。

Open-Inspect 支持子会话能力，代理可以将工作分解为并行执行的子任务。子会话会在各自独立的沙箱中运行，并使用不同分支开展工作。

spawn-child 可以创建子会话并立即返回，让父会话继续向前推进。send-child-prompt 可以向已有的直接子会话发送后续指令。get-child-status 与 cancel-child 则用于协调子会话的状态与执行过程。

系统对深度与仓库范围设置了限制与保护措施。

这种机制让父会话不必停在某一项耗时工作前等待。它可以继续处理其他部分，而子会话在独立沙箱中并行展开。对于包含多项相对独立工作的任务，代理能够将工作切分成多条并行的路径。

自动化任务，让编码代理按计划或事件行动

Open-Inspect 支持自动化能力。

自动化可以按固定计划运行，也可以响应外部事件。它不一定需要人在每一次任务开始时手动发出提示。

支持的自动化方式包括：

按小时、每日、每周、每月运行
使用带时区支持的自定义五字段 Cron 表达式
响应 Sentry 中的新错误、回归或关键指标告警
在 GitHub Actions 工作流完成时启动任务
依据工作流名称与结论进行过滤
通过入站 Webhook 接收外部事件
使用 JSONPath 条件过滤决定哪些载荷能够创建会话
对最多十个仓库进行多仓库扇出执行

一次计划自动化可以在多个仓库中运行，并分别创建会话与拉取请求。

系统会记录完整的运行历史。如果自动化连续失败三次，它会自动暂停。用户也可以手动触发自动化。

这让代理从被动响应输入的工具，进一步成为可以按时间表或事件信号行动的自动化执行者。

仓库启动脚本，让环境准备成为项目的一部分

仓库可以在 .openinspect 目录下定义两个可选脚本。

setup.sh 用于环境准备：

1
2
3

#!/bin/bash
npm install
pip install -r requirements.txt

start.sh 用于运行时启动：

1 2	#!/bin/bash docker compose up -d postgres redis

setup.sh 会在镜像构建与全新会话中运行。当会话通过预构建镜像或文件系统快照恢复时，系统会跳过该脚本。

对于全新的会话，setup.sh 失败不会阻止会话继续启动。但在镜像构建模式中，setup.sh 失败会导致构建失败。

start.sh 会在所有非构建模式的会话启动时运行，包括全新启动、预构建镜像启动与快照恢复。若该脚本存在且执行失败，会话启动也会失败。

两个脚本都会得到 OPENINSPECT_BOOT_MODE 环境变量。它的取值可以是：

build
fresh
repo_image
snapshot_restore

通过这些脚本，仓库能够将自身的依赖安装、服务启动与环境准备要求放进代理会话的启动流程中。

单租户安全模型

Open-Inspect 的安全模型明确面向单租户部署。

系统假定所有用户都是同一组织中受信任的成员，并且拥有对同一批仓库的访问关系。它不适合直接作为多租户系统使用。

系统使用共享的 GitHub App 安装来执行克隆、拉取与推送等 git 操作。控制平面在服务端生成短生命周期安装令牌，并在需要时通过 git 凭据助手提供给沙箱。

这意味着，拥有相应角色并被允许使用仓库的活跃用户，可以访问 GitHub App 已安装到的仓库。系统在创建会话前，不会验证某一位用户是否对特定仓库拥有权限。

创建拉取请求时，GitHub 登录用户会使用自己的 GitHub OAuth Token。这使拉取请求能够拥有正确的用户归属，也确保用户只能在拥有写权限的仓库中创建拉取请求。

系统涉及四类令牌：

令牌类型	用途	范围
GitHub App Token	用于克隆、拉取与推送认证	GitHub App 已安装的全部仓库
User OAuth Token	用于创建拉取请求与获取用户信息	用户有权限访问的仓库
Sandbox Auth Token	用于沙箱与控制平面之间的会话调用	单个会话
WebSocket Token	用于实时会话认证	单个会话

为了将访问范围控制在组织内部，README 给出了几项部署方向：

将系统部署在组织的 SSO 或 VPN 后方
仅将 GitHub App 安装到需要访问的仓库
限制登录用户、邮箱域名或活跃 GitHub 组织成员
在安装 GitHub App 时选择特定仓库，而不是全部仓库

如果需要支持多租户部署，则需要每个租户拥有独立的 GitHub App 安装、在会话创建时执行访问验证，并在数据模型中实现租户隔离。

以开源方式构建后台编码工作流

Open-Inspect 使用 MIT 许可证。

它建立在多种基础设施与工具之上，包括 Modal、Daytona、Vercel Sandbox、OpenComputer、E2B、Cloudflare Workers、OpenCode、Claude Agent SDK 与 Next.js。

这些组件共同构成了它的运行轮廓：边缘控制平面管理会话，云端沙箱提供开发环境，编码代理在环境中执行任务，网页与协作工具承担人与系统的连接，自动化机制则让任务可以按照时间或事件持续触发。

结语

Open-Inspect 想解决的，并不只是如何让模型写出代码。

它关注的是，如何让编码代理拥有真正可以工作的后台环境，如何让任务从网页、Slack、GitHub、Linear 或 Webhook 自然进入系统，如何让多人共同观察和推进同一段工作，如何让提交与拉取请求保留正确归属，以及如何让重复工作通过计划与事件自动发生。

从独立沙箱、浏览器自动化、终端与 VS Code，到多仓库环境、托管技能、预构建镜像、文件系统快照、并行子会话与自动化任务，Open-Inspect 将编码代理放进了一套更完整的工作结构中。

在这里，代理不是只能等待下一句输入的对话对象。

它可以在后台继续前进。