开源 · Issue 到发版 · 更新2026-10-20
开源 AI 编程 agent，从 Issue 做到发版
Orbi 是面向 GitHub 仓库的开源 AI 编程 agent。用 Orbi Cloud 可以省去本地安装和运行维护，也可以在自己的机器上部署。你在 GitHub Issue 写清需求和验收标准。Orbi 实现需求，创建代码变更请求（PR），交给独立会话评审；检查和必要审批通过后才合并。发版另开 Issue，按仓库的发版规则执行。
接入前先判断
开源 AI 编程 agent 怎么选
Orbi 从 GitHub Issue 接需求，把改动做到独立评审和合并。先确认这种交付方式适不适合你的仓库，再选择运行方式。
把需求和验收标准写进 Issue。
说清要得到什么结果，以及怎样检查。终端或 IDE 里的交互工具照常处理你想逐步确认的改动，Orbi 则按 Issue 交付任务。
先决定合并和发版怎么管。
Orbi 在评审、仓库检查和必要审批通过后合并。需要自己批准每次合并时，可用 GitHub 分支保护要求审批，Orbi 会等待。发版单独开 Issue，写清目标版本，同时加上 ai-ready 和 ai-release；相关任务与发版检查完成后，才创建 tag 和 GitHub Release。
选择由谁运行和维护。
Orbi Cloud 托管运行环境；自托管时，由你维护运行程序、模型连接和 GitHub 授权。如果接的是托管模型，代码上下文仍可能发给模型服务。用本地模型改变的是推理位置，Issue 和 PR 仍在 GitHub 上。具体接法见 提供方文档。希望把运行维护交出去，可以看下面的自托管与 Cloud 对比。
想比较更多工具，可以先读 OpenCode 替代方案和 Orbi 与 OpenHands 对比。也要核对具体跑法：OpenCode 也能跑在 GitHub Actions 里，有终端界面不等于只能在终端使用。
第一次先交一张结果能核对的小需求，看看 PR 和评审证据，再把更多需求放进任务池。
两种运行方式
用 Cloud，还是自己部署？
想省去安装和维护，可以用 Orbi Cloud；想自己选择部署环境和模型，可以自托管。两种方式都从 GitHub Issue 开始，按仓库规则推进编码、独立评审和合并。
| 自托管 | Orbi Cloud | |
|---|---|---|
| 如何开始 | 准备机器，安装 Orbi，接入模型和仓库，配置定时运行。 | 用 GitHub 登录，授权 Orbi App，再连接仓库。无需本地安装。 |
| 谁来维护 | 你负责运行机器、Orbi 更新和模型连接。 | Orbi 负责托管运行环境的部署与维护。 |
| 费用 | 不收 Orbi 软件使用费；机器和模型费用自行承担。模型成本估算口径见成本报告。 | 订阅包含托管运行和套餐内模型用量，支持按月或按年付费。 |
| 额度与限制 | Orbi 不设自托管交付额度；机器资源和所选模型服务仍有各自限制。 | 正式套餐按模型用量设置月度额度，具体额度见价格页。 |
也在比较托管 agent？Orbi 与 Devin 对比列出了上手、费用和交付流程的区别。
在自己的机器上运行
自托管需要准备什么
准备一台能持续运行 Orbi 的机器、模型连接和 GitHub 访问权限。Linux 使用 systemd 用户会话，macOS 使用 launchd。入门指南包含仓库选择、配置和服务部署的完整步骤，也说明了 macOS 目前的验证范围。
curl -LsSf https://raw.githubusercontent.com/orbi-build/orbi/main/install.sh | bash先准备 git、curl 和已登录的 GitHub CLI（gh ≥ 2.94）。安装脚本通过 SSH 克隆仓库，因此 GitHub SSH 访问也必须可用。Pi 是 Orbi 使用的编码 agent；尚未安装 Pi 时，还需要 Node ≥ 22.19 和 npm。
- 01 · 安装安装 Orbi
脚本会在缺少 uv 时安装它，再用 uv 安装 Orbi 和所需的 Python 3.14；缺少 Pi 时也会安装 Pi。默认检出目录为
~/.orbi/src，随后启动orbi setup。git、gh 和系统调度服务需要事先准备。 - 02 · 模型
- 03 · 仓库接入要处理的仓库
按入门指南选择 GitHub 仓库，保存
orbi.toml，再配置定时运行。gh auth status检查的是 GitHub CLI 登录状态，不能替代 SSH 访问检查。 - 04 · 第一个需求交付第一个需求
在已接入仓库新建 Issue，写清预期结果和验收标准，加上
ai-ready。Orbi 实现需求并创建 PR，后续定时运行再推进评审与合并。在 Issue 和 PR 查看进度；缺少信息、检查失败或等待必要审批时，可能需要你处理后才能合并。
常见问题
自托管常见问题
01数据存在哪里？
配置、任务工作目录和日志保存在运行 Orbi 的机器上。凭据位置取决于连接方式：API key 可以放在安装目录的 .orbi/env；Pi 账户登录默认使用 ~/.pi/agent/auth.json。Issue、标签、PR 和 Release 等交付记录保存在 GitHub。使用托管模型时，任务所需的代码上下文也会发送给模型服务。
02能用本地模型吗？
能，前提是 Pi 支持该模型端点的连接协议。Orbi 提供方指南包含本地 Qwen 模板。
03这是 Claude Code 的自托管环境吗？
不是。Anthropic 的 Claude Code 自托管环境把 Claude Code 云端会话放到你的基础设施执行，控制面仍由 Anthropic 托管。Orbi 使用 Pi 处理 GitHub Issue，从实现、独立评审推进到合并；合并仍须通过仓库检查和必要审批。
04怎么暂停新任务？
Linux 默认实例可用 systemctl --user disable --now orbi@1.timer 暂停后续启动，已经运行的任务会继续。请按实际 timer 名称操作，有多个启用的实例就逐个暂停。macOS 使用 launchd，不适用 systemctl。Linux 的 timer 和运行中服务检查见运维文档。
05一张 Issue 会交付什么？
功能或缺陷 Issue 会产出 PR、实现证据和独立评审。检查与必要审批通过后，Orbi 合并通过评审的提交版本。发版另开 Issue：加上 ai-ready 和 ai-release，写清目标版本。Orbi 按仓库发版规则执行，相关任务与发版检查完成后创建 tag 和 GitHub Release。完整流程见从 Issue 到发版。
06和 Devin 怎么比？
Orbi 与 Devin 对比分别比较了上手、费用和交付流程。
07Pi 和 Orbi 各负责什么？
Pi 执行编码和评审会话。Orbi 选择 Issue，分别启动这些会话，跟进任务进度，再处理合并与发版。两者的分工见 Orbi 如何基于 Pi coding agent 构建。
从第一个需求开始
把下一个需求交给 Orbi
用 GitHub 登录 Orbi Cloud，授权 App 并连接仓库，就能提交第一个需求。运行环境由 Orbi 维护，你在 GitHub 跟进实现、独立评审和合并。需要发版时，再单独提交发版需求。