今天已经可用
自托管，永久免费
在自己的机器、GPU 和模型凭证上运行 Orbi。自托管交付核心不收平台费。
- 仓库和密钥留在自己的机器上
- 使用本地模型或任意受支持的 Provider
- GitHub 保存长期生产记录
GitHub 原生的软件生产系统
让 GitHub Issue
变成经过审查的软件
不用迁移工作流。Orbi 直接读取仓库里已有的 Issue、依赖、Milestone 和 Release，把它们推进到实现、独立审查、故障恢复和精确合并。GitHub 始终是唯一事实源。
- Fair-code，永久免费
- 自托管 — 代码不离开你的机器
- 自带模型
01 号产线 / 运行中
orbi-build/orbi
- 范围 Epic + Milestone 确定版本边界
- 顺序 GitHub blockedBy 证据表明就绪才开工
- 生产 Issue #48 → PR #193 实现 · 测试 · 审查 · 修复 · 合并
- 出厂 Release v0.2.0 冻结 SHA · 完整门禁 · 不可变 Tag
ORBI 正在造 ORBI · 实时
0 GitHub Star
GitHub 实时数据暂时不可用。
0运行天数
0已关闭 Issue
0已合并 PR
0已发布版本
行业正在换挡
AI Agent 会写代码，
但交付仍然需要系统
当 Agent 能连续工作数小时、并行处理多个任务，瓶颈就从写代码转向：决定改什么、协调依赖、证明结果正确、控制权限，以及把一个精确版本安全送进生产。
Agent 越强，生产系统越重要。
- 01一次提示→长时间委派
- 02单个 Agent→按任务选择协作方式
- 03生成代码→交付版本和结果
- 04人盯过程→人只处理决策点
今天已经在运行
Orbi 如何把 GitHub Issue
自动做成正式发布版本
Issue 是最小执行单元，但 Orbi 管的不是孤立 Issue：Epic 和 Milestone 确定范围，blockedBy 排定依赖，Review/Fix 让 PR 收敛，Release Issue 把一组结果冻结成版本。
01组织
EpicMilestoneScope
聚合多个结果，但不让 Runner 把协调事项错当成可执行任务。
02排序
IssueblockedByReady
读取 GitHub 原生依赖；前置关闭以后，任务才自然进入生产。
03交付
WorktreeAgent测试审查 + 修复精确合并
第二场会话可以直接修复分支；只有刚刚审过的那个 Head 可以进入主分支。
04发版
冻结 SHA完整门禁Tag + Release
逐项核对范围和仓库状态，再发布不可变版本；发版不是让 Agent 临场发挥。
恢复总线
进程被杀、测试失败、提交没推出去——下一拍仍然回到同一个 Run、分支、Worktree 和 PR。
真实生产证据
一个 Issue：审查、
合并、发版全过程
Issue #48 进入真实的 Orbi 仓库。隔离运行完成实现，另一场会话审查同一份 Diff，PR #193 随后合并，最终随 Release v0.2.0 出厂——范围里的每个 Issue 都逐项核对过。今天仍然可以检查全过程，因为 GitHub 本身就是记录。
- 01会修复的独立审查
Reviewer 改代码、重跑全量，再对修复后的 Head 下结论。
- 02合并证据只绑定一个 SHA
最新底仓、可以合并，以及真正收到 Verdict 的那个 Commit。
- 03失败不产生第二套故事
Issue、PR、Label、Journal 和 Run ID 足够让重启恢复同一现场。
在你自己的仓库上跑一次
git clone https://github.com/orbi-build/orbi.git && cd orbi
uv tool install --force --reinstall --editable --python /usr/bin/python3 .
cp .orbi.example.toml orbi.toml
orbi setup --config orbi.toml需要 Python 3.14、git、gh、systemd 和一个模型端点。缺什么，orbi doctor 会直接点出来。
卡在环境、模型接入或工作流上？我们帮你把第一个 Issue 跑通，你踩的坑会变成我们优先修的 Issue。
你的工厂现场
可自托管，代码
不离开你的机器
Orbi 在仓库和模型访问本来就存在的地方运行。GitHub 保存长期协调和交付证据；你的机器执行真正的生产。
控制面GitHubIssue · PR · 依赖 · Release
RunnerOrbi策略 · 恢复 · 合并门禁
执行面你的机器仓库 · 模型 · 密钥 · 测试
按你的方式运行
自带模型即可
Claude、GPT 或本地模型
开源核心今天已经可用。托管 Cloud 是 Orbi 在同一 GitHub 账本上的商业托管服务，正以创始试点（席位有限）开放申请。
建议的 CLOUD 账单平台订阅 + 托管运行时 + 模型用量自带算力或模型，对应的用量费用归零；完全自托管开源核心，向 Orbi 支付 ¥0。
正在建设的方向 · 不是已上线清单
自主软件开发
的下一步是什么
今天，明确的 GitHub 任务和 Release Issue 进入产线。下一个阶段是闭环生产：软件从自身运行中提供证据，Orbi 把证据变成边界清楚的工作，Agent 执行，发布以后再用真实结果检验。
- 01 / 感知读取软件现场
故障、遥测、用户反馈、安全发现、依赖漂移。
- 02 / 决策提出下一项改动
让工作有证据，再按目标、依赖、风险和成本排序。
- 03 / 生产选择合适的智能
顺序任务用一个 Agent；真正可拆的任务才组织专业 Agent 协作。
- 04 / 证明把信心写成可执行门禁
测试、Eval、模拟、安全策略和明确的人工审批边界。
- 05 / 发布控制影响范围
不可变 Release、渐进交付、自动回滚和完整来源记录。
- 06 / 学习让结果回到下一轮
有效做法成为证据；失败成为可复现任务，而不是口耳相传。
模型会更换，Agent 会进化。长期产品是让目标、状态、权限、验证、成本和生产证据始终保持连续的那一层。
Orbi 不应该变成另一个聊天窗口或另一个看板。它应该成为 Agent 之上的生产控制系统。
动手之前
把 Agent 放进自己仓库前，
大家都会问的问题
01跑 Orbi 需要什么前提？
Git、一个 POSIX shell，以及你已经在付费的模型 API。Orbi 跑在 Linux 和 macOS 上，可以是自己的机器，也可以是自己的服务器。不需要 GPU——思考交给模型，模型可以是托管 API。
仓库、密钥和测试套件都留在原地。Orbi 不会把你的代码上传到我们运营的服务上。
02可以用哪些 AI 模型？
自带即可。Orbi 通过你的凭证驱动 Agent，Claude、GPT 和本地部署的开源权重模型都能用，以后想换也不必改工作流。
模型费用按你的价格付给你的 Provider，Orbi 不额外抽成：自托管核心不收平台费。
03和 Copilot、Cursor 有什么区别？
那些是编辑器——让你在敲键盘时更快。Orbi 管的是没人敲键盘的时候：从 Backlog 领一个 Issue，在隔离的 Worktree 里干活，最后交回一个已合并的 PR。
真正的区别在代码写完之后。另一场会话审查同一份 Diff、直接修复、重跑全量测试，只有通过审查的那个 Commit 才允许合并。这个审查环节才是产品本身。
04AI 写的代码谁来审？
另一场独立于写代码那场的 Orbi 会话，而且它能直接改分支，不是只留评论。它会针对自己的修复重跑测试，再对修复后的 Head 下结论。
最后一道关仍然是你。产出以普通 GitHub PR 落地，你现有的分支保护、必需检查和人工审批照常生效。
05跑到一半崩了怎么办？
下一拍回到同一个现场。因为 Issue、PR、Label 和 Run ID 存在 GitHub 里而不是进程里，进程被杀或测试失败不会产生第二套关于「刚才发生了什么」的说法。
重启会从这份记录里恢复出同一个 Run、分支、Worktree 和 PR。
06真的免费吗？托管 Cloud 是什么？
自托管核心在 Sustainable Use License 下永久免费：在自己的仓库上跑 Orbi 不花钱，个人用、公司内部用都一样，不限规模。只有把 Orbi 本身卖出去才需要商业授权——托管成服务卖给客户，或嵌入你收费的产品。
托管 Cloud 正以创始试点（席位有限）开放申请。计划是一个托管控制面，按平台订阅 + 托管运行时 + 模型用量计费，自带算力或模型时对应费用归零。申请通过后，伙伴会拿到自己的登录入口和状态页。
开源核心
装上这个开源 Agent，
然后关灯
Fair-code，自托管。接上你已经信任的模型。GitHub 继续做账本，让 Orbi 把工作推进到经过审查的结果。