Orbi

免费增值Web

访问官网

Orbi是Agent时代的软件黑灯工厂，用AI自动完成GitHub Issue开发任务，经独立AI评审后自动合并发版。

分类：AI编程工具->AI编程助手

标签：AI编程 AI代码生成 AI编程助手 AI辅助编程 AI代码审查 AI程序员 AI软件工程师 AI软件开发开发者工具 AI智能体 Agent智能体 AI编程智能体 AI工作流自动化 AI任务自动化开源

访问官网

详细介绍

工具简介

Orbi 是一款面向软件开发团队的 AI 自动化编程工具，官方将其定位为“Agent 时代的软件黑灯工厂”。它的核心理念非常直接：提个 Issue，收个版本。开发者只需要在 GitHub 上提交一个 Issue，Orbi 就能用 AI 完成其中的开发任务，代码经过另一个独立 AI 会话的评审，通过后自动合并，再按照仓库既有的流程发布版本。整个过程无需人工一直守着，极大地降低了重复性开发工作的管理成本。

与市面上许多停留在“代码补全”或“对话式编程”层面的 AI 工具不同，Orbi 把Issue 作为最小执行单元，但它管理的并不是孤立的 Issue。它通过 Epic 和 Milestone 确定工作范围，用 blockedBy 排定任务依赖关系，借助 Review/Fix 循环让 PR 逐步收敛，最后通过 Release Issue 把一组结果冻结成正式版本。这意味着 Orbi 覆盖的是从需求到发版的完整交付链路，而不仅仅是写几行代码。

Orbi 由 orbi-build 团队出品，采用 AGPL-3.0 开源协议，核心永久免费，支持自托管部署，代码不必离开开发者自己的机器。同时官方也提供 Orbi Cloud 云端服务，前 3 次交付免费且无需绑定信用卡。截至目前，Orbi 已经在自己的仓库中合并了 798 个由它自己提交的 PR，发布了 132 个版本，并积累了 240 个以上的 GitHub Star，这些公开数据本身就是其能力的有力证明。

主要功能

Issue 驱动的自动化开发

Orbi 的工作起点是一个被打上 ai-ready 标签的 GitHub Issue。当 Issue 被标记后，Orbi 会认领该任务，并在一个隔离的 Worktree 工作区中编写代码。这种隔离机制保证了不同任务之间互不干扰，也避免了开发过程污染主分支。Issue 中描述的验收项会成为后续评审的依据，确保 AI 交付的代码真正符合需求，而不是“看起来差不多”。

独立 AI 评审与修复闭环

代码写完后，Orbi 会启动另一个独立的 AI 会话来审查这份代码。审查者会对照 Issue 的验收项逐项检查 PR，如果发现问题就进行修复，修复后会重新运行全量测试，再对修复后的 Head 提交下结论。这种“写代码的 AI”和“审代码的 AI”相互分离的设计，有效降低了单一模型自说自话的风险，让交付质量更有保障。

自动合并与版本发布

评审通过后，Orbi 只合并那个真正收到 Verdict 的 commit，并绑定唯一的 SHA 作为合并证据，确保合并的是经过审查的确切代码版本。随后它会打上 Tag，按照仓库流程发布版本。从官方展示的真实案例来看，Issue #1306 到 PR #1309 的审查合并仅用了 1 小时 27 分，再到发布 v0.5.42 总共约 6 小时 42 分，同一天内即可完成从需求到发版的闭环。

依赖与范围管理

Orbi 支持通过 Epic 和 Milestone 确定整体范围，用 blockedBy 排定 Issue 之间的依赖顺序，避免任务乱序执行。Review/Fix 机制让 PR 不断收敛，Release Issue 则把一组已完成的结果冻结成版本。这种结构化的管理方式，使得 AI 自动化开发不再是零散的任务堆砌，而是有节奏、可追溯的工程流程。

失败可恢复的运行记录

Orbi 强调“失败不产生第二套故事”。Issue、PR、Label、Journal 和 Run ID 共同构成完整的现场记录，即使运行中断，也能凭这些信息恢复到同一现场继续执行。GitHub 本身就是记录载体，开发者可以随时回溯每个环节，检查某个版本是如何从 Issue 一步步走到 Release 的。

开源自托管与自带模型

Orbi 核心以 AGPL-3.0 协议开源，支持自托管部署，代码不离开用户自己的机器。它允许用户自带模型端点，灵活选择底层 AI 模型。安装需要 Python 3.14、git、gh、systemd 和一个模型端点，官方提供了一键安装脚本，缺什么依赖 orbi doctor 命令会直接点出来，降低了部署门槛。

使用方法

使用 Orbi 有两种主要路径。第一种是云端试用：访问官网通过 GitHub 授权并安装 App，即可免费体验前 3 次交付，无需绑卡。第二种是自托管部署，在满足依赖的机器上执行官方提供的一键安装脚本，或手动克隆仓库、安装工具、复制配置文件后运行 orbi setup 完成初始化。配置好模型端点后，给 Issue 打上 ai-ready 标签，Orbi 便会自动接管后续的开发、评审、合并与发版流程。

产品优势

Orbi 的最大优势在于端到端自动化：它不是辅助写代码，而是直接交付可发布的版本。其次是质量保障机制，独立评审加唯一 SHA 绑定，让合并证据清晰可查。第三是开源与数据自主，自托管模式让代码安全可控。第四是真实可验证，所有交付过程都在 GitHub 上公开可查，包括 Issue #48 到 PR #193 再到 Release v0.2.0 这样的完整案例。

应用场景

开源项目维护：维护者可以将常规 Issue 交给 Orbi 处理，减轻社区维护压力。
小型开发团队：在人力有限的情况下，用 AI 承担重复性开发与发版工作。
独立开发者：把想法写成 Issue，让 Orbi 完成实现到发版的全流程。
企业自托管场景：对代码安全要求高的团队可自行部署，数据不出内网。

核心功能

Issue 自动认领与隔离开发

给 GitHub Issue 打上 ai-ready 标签后，Orbi 自动认领任务，并在隔离的 Worktree 工作区中编写代码，避免任务间互相干扰，保证主分支干净。

独立 AI 代码评审

由另一个独立 AI 会话对照 Issue 验收项审查 PR，发现问题自动修复并重跑全量测试，再对修复后的 Head 提交下结论，形成写审分离的质量闭环。

自动合并与发版

评审通过后只合并收到 Verdict 的那个 commit，绑定唯一 SHA 作为证据，随后打 Tag 并按仓库流程发布版本，实现从 Issue 到 Release 的全自动交付。

Epic 与依赖管理

通过 Epic 和 Milestone 确定工作范围，用 blockedBy 排定 Issue 依赖顺序，Review/Fix 让 PR 收敛，Release Issue 把结果冻结成版本，流程结构化可追溯。

失败可恢复的运行记录

Issue、PR、Label、Journal 和 Run ID 构成完整现场记录，运行中断后可凭这些信息恢复到同一现场，GitHub 本身即为可回溯的记录载体。

开源自托管与自带模型

核心以 AGPL-3.0 开源，支持自托管部署，代码不离开用户机器，并允许自带模型端点，灵活选择底层 AI 模型，兼顾安全与自由度。

一键安装与依赖检查

提供一键安装脚本，需要 Python 3.14、git、gh、systemd 和模型端点，缺失依赖时 orbi doctor 命令会直接指出，降低部署与调试门槛。

优缺点分析

优点

+端到端自动化，从 Issue 到 Release 全流程无需人工值守，官方数据显示同一天内可完成从提交 Issue 到发版的闭环

+写审分离的独立 AI 评审机制加唯一 SHA 合并证据，交付质量与可追溯性有保障

+AGPL-3.0 开源且支持自托管，代码不离开自有机器，数据安全可控，还可自带模型

+真实交付记录公开可查，已在自身仓库合并 798 个 PR、发布 132 个版本，可信度高

缺点

-自托管部署需要 Python 3.14、git、gh、systemd 等环境依赖，对非技术用户有一定门槛

-核心围绕 GitHub 生态构建，非 GitHub 用户或使用其他代码托管平台的团队难以直接受益

-价格模式信息不明确，云端服务除前 3 次免费外的后续收费细则需进一步确认

适用人群

开源项目维护者小型软件开发团队独立开发者与个人创作者对代码安全有要求、需要自托管的企业研发团队

常见问题

Q: Orbi 是如何保证 AI 生成的代码质量的？

Orbi 采用写审分离的机制：一个 AI 会话负责编写代码，另一个独立的 AI 会话负责对照 Issue 的验收项审查 PR。审查者发现问题会进行修复，并重新运行全量测试，再对修复后的 Head 提交下结论。合并时只合并真正收到 Verdict 的那个 commit，并绑定唯一 SHA 作为合并证据。这种设计有效避免了单一模型自说自话，让交付质量更可控。

Q: 使用 Orbi 需要付费吗？

Orbi 核心以 AGPL-3.0 协议开源，自托管永久免费，代码不离开用户自己的机器。官方还提供 Orbi Cloud 云端服务，前 3 次交付免费且无需绑定信用卡。至于云端服务后续的收费细则，建议访问官网价格页面确认最新信息。

Q: 自托管部署 Orbi 需要哪些环境条件？

自托管需要 Python 3.14、git、gh、systemd 以及一个可用的模型端点。官方提供了一键安装脚本，也可以手动克隆仓库后安装工具、复制配置文件并运行 orbi setup 完成初始化。如果缺少依赖，运行 orbi doctor 命令会直接指出缺失项，方便排查。

Q: Orbi 支持哪些代码托管平台？

目前 Orbi 深度围绕 GitHub 生态构建，通过 GitHub Issue、PR、Release 等机制完成从需求到发版的闭环，使用前需要 GitHub 授权并安装 App。对于使用 GitLab、Bitbucket 等其他托管平台的团队，目前并非其直接支持的目标场景。

Q: Orbi 的交付过程可以追溯吗？

可以。Orbi 强调失败不产生第二套故事，Issue、PR、Label、Journal 和 Run ID 共同构成完整现场记录，运行中断后也能恢复到同一现场。由于所有操作都发生在 GitHub 上，开发者可以随时回溯每个环节，例如官方公开的 Issue #48 到 PR #193 再到 Release v0.2.0 的完整案例，任何人都能自行检查全过程。