Orbi
把 GitHub Issue 自动交付为经过独立审查的合并代码与版本标签。
按维度查看评分与理由
证据显示任务在隔离 worktree 中运行，基于冻结的主分支 SHA，经过独立审查和合并门禁后才合并；CI 权限也显式缩小到所需范围。GitHub Issue、PR、标签、评论、日志、分支、发布标签等外部效果及其数据流描述清楚，失败证据和旧运行会被保留。扣分点是系统以定时器全自动运行，只有 ai-ready 标签形成事前授权，合并和发布没有逐步用户确认；未提供完整运行时代码来核查所有凭据、日志脱敏和权限路径；Actions 仅固定到主版本标签而非不可变提交；合并或错误发布后的明确回滚流程不足。作者和许可证有署名，但给定的发布者身份仍未经企业注册表验证，不能确认组织主体。
README、打包元数据、工作流和测试替身对核心模型保持一致：GitHub Issues 是状态存储，任务经隔离开发、审查、门禁和交付；替身对未知命令、对象和限定符会快速失败，并携带退出码和错误文本。依赖可用性只获中等分，因为运行依赖 GitHub、gh、uv、Pi、模型提供商及用户级调度器，并要求较新的 Python 3.14；这些前置条件虽有检查说明，但所给材料不能证明它们在普通目标环境中持续可用。失败消息和 ai-blocked 人工升级路径说明充分，因此该项满分。
材料清楚区分自举模式、外部单仓库模式、Linux systemd 和 macOS launchd，并列出开发、审查、发布、状态查看、会话跟踪、诊断等场景。能力边界明确，包括 Agent 停在提交、Runner 负责推送和 PR、受保护分支不由 AI 直接推送，以及不可恢复失败交给人工。ai-ready 标签、工作流事件、分支和 SHA 门禁使触发条件精确。扣分来自环境适配仍有缺口：macOS 明示尚未在真实硬件验证，Ubuntu 24.04 默认 Python 和 gh 版本不满足要求，且 Windows 未被支持或讨论。
README 提供快速开始、流程、功能、文档导航、开发入口和许可证说明，信息架构及安装步骤完整；Orbi、orbi-cli 和 orbi 命令之间的命名关系也被明确解释。许可证全文、权利限制和商业使用边界齐全。扣分点是没有独立 FAQ 内容，示例主要集中于单一成功循环；变更记录依赖 GitHub Releases 链接，所给文件未包含版本历史或发布策略正文；维护渠道有 Discussions、仓库和作者名，但没有明确维护团队、响应承诺、安全联系或继任安排。
预期产物可直接使用：提交、PR、审查修复、合并记录、标签发布、Issue 评论和带 run_id 的日志形成完整交付链，且诊断、队列和会话命令支持运维。它相对手工串联工具具有明显增量价值，但所给材料主要由项目自身声明和测试替身支撑，缺少静态材料内的比较基准或独立案例，因此边际价值未给满分。成本收益只获中等分，因为收益说明清楚，但 Python 3.14、gh、uv、Pi、提供商凭据、调度器以及持续五分钟轮询的部署和运营成本没有被量化或系统比较。
源文件广泛引用具体 Issue 编号、文件职责、命令、SHA、PR 和发布流程；README 的产品描述与 pyproject、CI 权限、macOS 工作流及 GitHub/Git 测试替身相互印证，因此可追溯性和跨源一致性很强。扣分在事实与推断分离：部分文字把“已验证”“真实 REST 形状”“完整交付记录”等结论作为注释或项目声明给出，而本次材料没有对应全部测试用例、运行输出或外部记录正文；README 虽用“claims”并披露 macOS 限制，但并非所有强主张都同样标示其证据等级。
- 该系统会在 ai-ready 标签触发后自动修改仓库状态、推送分支、创建和评论 PR、合并代码并发布标签；部署前应在受限测试仓库核对分支保护、令牌权限、发布权限和人工停止机制。
- 本次仅为所给文件的静态审查；未执行测试、安装程序、GitHub API 调用、真实 Issue 到发布流程或 macOS 真机验证。
- Sustainable Use License 不是常见的宽松开源许可证，并限制商业分发及将 Orbi 作为付费服务或产品出售；商业集成前应核对完整条款并取得适当授权。
- 运行依赖 Python 3.14、较新版本的 GitHub CLI、uv、Pi、模型提供商以及 systemd 或 launchd 用户会话；尤其应验证目标操作系统、凭据存储、费用上限和依赖版本的可获得性。
- 工作流使用 actions/checkout@v5 和 actions/setup-python@v6 等主版本标签，而不是不可变提交；高保证环境应评估供应链固定策略。
这个 Agent 能做什么，适合哪些场景？
Orbi 是一个围绕 GitHub Issues 运转的自托管软件交付系统：它领取带有 `ai-ready` 标签的 Issue，并在独立 Git worktree 中完成开发。Pi 开发会话负责规划、实现、测试和验证，随后由 runner 同步基线、推送分支并创建包含 `Fixes #N` 的拉取请求。另一个独立审查会话检查 PR，并在同一会话中修复发现的问题；只有通过审查的提交头才能合并。Release Issue 可冻结具体 SHA 并发布标签，因此系统的输出包括提交、PR、合并结果和版本发布。GitHub Issues、评论、PR、CI 与 releases 构成唯一状态记录，无需数据库、队列或常驻守护进程；Linux 上由 systemd 用户定时器运行，macOS 使用 launchd。它适合愿意把任务与交付流程集中在 GitHub、并能接受 Python 3.14、Pi、GitHub CLI 和自托管调度依赖的团队。
Orbi 从带有 ai-ready 标签的 GitHub Issue 领取任务，记录当时的 origin/main SHA，然后创建功能分支和隔离 worktree。Pi 会话执行 plan → implement → test → verify，并以提交作为开发阶段的交付边界。orbi.runner 随后同步最新基线、推送分支并创建正文含 Fixes #N 的 PR。独立审查会话检查该 PR，并在同一会话中处理审查发现；merge gate 只允许合并已经审查的 head，AI 不直接推送受保护分支。可恢复失败返回原 PR 继续修复，不可恢复失败则给 Issue 标记 ai-blocked，等待人工决定。每次运行把分支、worktree、日志和 PR 关联到同一个 run_id；重试会创建新运行，同时保留旧证据。Release Issue 能冻结 SHA 并发布 tag；orbi add 用于派发任务，status 查看队列，session 跟踪 Pi 会话，install-units 安装调度单元，doctor 执行只读健康检查。
- 以 GitHub Issues 管理开发任务的小型工程团队，希望把明确、可执行的 Issue 自动转成经过审查的 PR。
- 维护自托管代码仓库交付流程的平台团队，需要每个任务都有隔离 worktree、分支、日志、PR 和统一
run_id。 - 需要自动修复审查问题的项目维护者，希望合并前由独立会话复核代码，并限制合并到已审查的提交头。
- 按 GitHub Issue 驱动发布的团队，希望冻结明确 SHA、生成版本标签，并让 Issue、PR 与 release 留在同一审计记录中。
- 不想维护额外任务数据库或消息队列的 GitHub 项目，愿意把 Issues、评论、CI 和 releases 作为完整状态账本。
这个 Agent 有哪些优点和局限？
- Issue、评论、PR、CI 和 release 同时承担任务状态与审计记录，不需要另建数据库、队列或任务系统。
- 每个任务使用独立 worktree，并把分支、日志和 PR 绑定到同一
run_id；重试不会覆盖旧运行证据。 - 独立审查会话、reviewed-head merge gate 和受保护分支限制形成具体的合并控制，而非只依赖开发会话自检。
- 失败采用显式分类：可恢复问题继续在原 PR 修复，不可恢复问题标记
ai-blocked，日志保留错误证据。 - 提供
setup、install-units和只读doctor，并支持 systemd 与 launchd 的定时运行。
- 工作流以 GitHub Issues 为唯一状态存储，未记录 GitLab、Bitbucket 或通用任务系统适配，因此非 GitHub 团队需要改变现有流程。
- 要求 Python 3.14 或更新版本；Ubuntu 24.04 自带的 Python 3.12 不满足要求，需要由 uv 额外配置解释器。
- 运行依赖 Pi 及其 provider、GitHub CLI 2.94+、GitHub 认证和用户级调度会话，部署链条不只是安装一个 Python 包。
- macOS launchd 支持在资料中明确标为尚未经过真实硬件验证，采用前需要自行验证。
- Sustainable Use License 允许内部使用和自托管，但销售托管版 Orbi 或将其嵌入付费产品需要商业授权。
如何安装或部署这个 Agent？
前置条件：Python ≥ 3.14、uv、Pi 及其 provider、GitHub CLI ≥ 2.94、Git、已认证的 GitHub 账户，以及 Linux systemd 用户会话或 macOS launchd GUI 会话。先执行：
git clone https://github.com/orbi-build/orbi.git && cd orbi
uv tool install --force --reinstall --editable --python python3 .若系统 Python 低于 3.14，把最后一个参数改为 --python 3.14，由 uv 配置兼容解释器。只安装 CLI 可运行 uv tool install orbi-cli；旧版系统 Python 使用 uv tool install orbi-cli --python 3.14。安装前检查：uv --version、pi --version、pi --print "reply with the single word: ok"、gh auth login、gh auth status，并在 Linux 执行 systemctl --user status，或在 macOS 执行 launchctl print gui/$(id -u)。
如何使用这个 Agent？
在仓库中创建配置并完成一次部署验证：
cp src/orbi/example_config.toml orbi.toml
orbi setup --config orbi.toml
PYTHONPATH=src python3 -m orbi.runner --config orbi.toml
orbi doctor --config orbi.tomlorbi setup 会检查已有的 GitHub CLI 认证、标签、systemd/launchd 调度单元和 checkout，并可重复执行。手动运行 orbi.runner 完成一个 tick；正常运行则由定时器每五分钟触发。准备好任务后，给 GitHub Issue 添加 ai-ready 标签，系统会领取并执行交付流程。可通过 status 查看队列、session 跟踪 Pi 会话；需要明确命令上下文时使用已安装的 orbi CLI。
这个 Agent 与同类方案有什么区别？
与把任务状态复制到独立数据库、消息队列或第二套项目管理系统的自动化平台相比，Orbi 直接以 GitHub Issues、评论、PR、CI 和 releases 为账本，减少额外状态基础设施，但也把核心工作流绑定到 GitHub。与单次运行的编码助手相比，它还覆盖定时领取任务、隔离 worktree、PR 创建、独立审查、合并门禁和标签发布。
常见问题
内部使用或大规模自托管需要付费吗？
它需要数据库、队列或常驻 daemon 吗？
自动生成的代码会直接进入受保护分支吗？
任务执行失败后会怎样？
ai-blocked，等待人工决定。可以在 Ubuntu 24.04 的系统 Python 上直接运行吗？
--python 3.14，让 uv 配置兼容解释器。