让 AI 修 Bug 先证明测试失败：ApolloOffice 的本地 Issue 到 PR 流程
把 GitHub Issue 交给编码 Agent 自动修复，最难的不是让它生成补丁，而是确认补丁真的解决了问题，而不是碰巧让测试变绿。ApolloOffice 尝试把这件事做成一条可审查的本地工作流：从 Issue 或外部错误报告开始，经多个专职 worker 复现、修复、测试和审查，最后生成 Pull Request。它目前标注为 beta，适合想实验“自动修复但保留人工把关”的开发者，不应当作无人值守的生产承诺。
不只生成补丁，而是验证修复因果
项目 README 描述的核心机制是先验证回归测试：修复前测试应失败，应用修复后测试应通过，同时项目自己的测试命令也要通过。这个“红变绿”检查，比单看 Agent 的解释更有价值，因为它要求测试确实能捕获原问题。不过，测试通过仍不等于修复正确；测试覆盖面和断言质量仍需维护者把关。
ApolloOffice 将流程拆成 Scout、Guard、Vet、Hunter、Repro、Fixer、CI、Reviewer、Submit、Watcher 等角色。它们负责从线索筛查到 PR 跟踪，不是十个必须单独配置的外部服务。README 也说明，每个 worker 可以选择不同模型或提供商；本地 Claude Code、Codex、API 密钥以及 Ollama 等路径均在其支持说明中列出。
从仓库到可审阅的 PR
仓库的快速启动要求 Git、已登录的 GitHub CLI，以及至少一种 AI 提供商。下载对应系统的发布二进制并启动：
apollo-office
首次启动会显示一次性登录链接。按界面引导添加机器和仓库，并检查项目测试命令。README 还列出以下管理命令：
apollo-office login-link apollo-office autostart on apollo-office status
添加仓库后，工作流可以处理已有 bug 报告，也可以主动寻找问题。提交前默认等待人工批准；维护者可检查 diff、验证证据和 PR 文案，再决定是否提交。README 提供切换为自动提交的选项，因此团队应在启用前明确权限、分支保护与审批策略。
把 CI 或错误告警送进同一队列
除了 GitHub Issue，项目还支持通过 POST /v1/report 接收自有工具提交的报告。README 举例提到错误追踪器、CI 脚本，并列出 Sentry、GlitchTip webhook，以及将失败的 GitHub Actions 运行上报的集成。这样做的价值在于把“发现问题”和“复现、修复、验证”放进同一个队列，而不是让告警直接触发未经审查的代码改动。
每个仓库都需要配置实际的测试命令；如果测试不稳定、依赖外部服务或会修改共享数据，自动执行前应先准备隔离环境。项目支持本机 Docker 隔离，也可通过 SSH 使用可达机器。GitHub 凭据由本地应用管理，README 声明不会经过项目维护者的服务器；但自托管仍需保护运行机器、令牌和网络入口。
适合试点，不适合盲目放权
ApolloOffice 的实用之处不在“有很多 Agent”，而在它把复现、回归测试证据、CI 和人工批准串成可检查的链路。可以先选一个低风险仓库试点：限定可处理的标签或报告来源，使用独立工作目录和最小权限 GitHub 身份，保留默认人工批准，并审查它生成的测试是否真正覆盖缺陷。
该项目处于 beta 阶段，自动 rebase、提交和远程执行等功能都应在团队自己的环境中验证。将它视为自动化助手而不是责任主体，才是更稳妥的使用方式：Agent 可以缩短从告警到候选补丁的时间，合并决策仍应由了解代码库的人作出。