展示HN：Agent Orchestrator，一个以本地为主的Harness工程控制平面
我在XP/TDD风格下工作了很长时间，因此当AI编码工具变得足够实用以用于实际工作时，我迅速采用了它们。我遇到的第一个瓶颈不是代码生成，而是验证：AI能够快速编写代码和测试，但我仍然是负责审核实现、点击流程、检查日志、检查数据库状态并决定结果是否正确的人。
这促使我将验证工作向前推进。在实施之前，AI必须生成测试计划；在实施之后，它还必须执行这些计划：驱动浏览器、检查日志、检查数据库状态、为失败创建工单、修复问题并重新测试，直到输出收敛。Auth9（[https://github.com/c9r-io/auth9](https://github.com/c9r-io/auth9)）成为了这种方法的试验场。一旦它显然有效，我开始构建Agent Orchestrator，以便这个过程不再依赖于我手动监督每一步。
到二月中旬，我已经在Auth9内部使用早期的Orchestrator风格的自动化。在三月中旬，我在迄今为止风险最高的重构中使用了它：用本地的`auth9-oidc`引擎替换无头的Keycloak设置。核心替换在三天内完成，同样的方法和工具帮助解决了后续的技术债务，并在月底之前完成了社区OIDC认证测试。那时我对这种方法的信心增强了，我意识到这不仅对新项目有用，也能有效管理真实系统中的高风险变更。
当时，“编排”是我最关心的词，这也是项目得名的原因。后来，OpenAI的Harness Engineering框架为我提供了一个更好的名称来描述这项工作的整体形态。如今，该项目是一个以本地优先的Rust控制平面，用于长期运行的代理工作流：YAML资源、基于SQLite的任务状态、机器可读的CLI输出、结构化日志以及针对基于Shell的代理的保护措施。
- GitHub: [https://github.com/c9r-io/orchestrator](https://github.com/c9r-io/orchestrator)
- 文档: [https://docs.c9r.io](https://docs.c9r.io)
- Auth9: [https://github.com/c9r-io/auth9](https://github.com/c9r-io/auth9)
- 安装: `brew install c9r-io/tap/orchestrator` 或 `cargo install orchestrator-cli orchestratatord`
- 许可证: MIT
查看原文
I have spent a long time working in an XP/TDD style, so when AI coding tools became useful enough for real work, I adopted them quickly. The first bottleneck I hit was not code generation, it was verification: AI could write code and tests quickly, but I was still the person reviewing implementations, clicking through flows, checking logs, inspecting database state, and deciding whether the result was actually correct.<p>That pushed me to move validation further left. Before implementation, AI had to produce test plans. After implementation, it had to execute those plans too: drive the browser, inspect logs, check DB state, create tickets for failures, fix them, and retest until the output converged. Auth9 (<a href="https://github.com/c9r-io/auth9" rel="nofollow">https://github.com/c9r-io/auth9</a>) became the proving ground for that method. Once it was clearly working, I started building Agent Orchestrator so the process would not depend on me manually supervising every step.<p>By mid-February, I was already using early Orchestrator-style automation inside Auth9. In mid-March, I used it during the highest-risk refactor so far: replacing the headless Keycloak setup with a native `auth9-oidc` engine. The core replacement landed over 3 days, and the same method and tooling helped converge the follow-up technical debt and complete the community OIDC Certification tests by the end of the month. That was the point where I became confident this was useful not only for greenfield work, but for governing high-risk change in a real system.<p>At the time, "orchestration" was the word I cared most about, which is why the project got its name. Later, OpenAI's Harness Engineering framing gave me a better name for the broader shape of the work. The project today is a local-first Rust control plane for long-running agent workflows: YAML resources, SQLite-backed task state, machine-readable CLI output, structured logs, and guardrails around shell-based agents.<p>- GitHub: <a href="https://github.com/c9r-io/orchestrator" rel="nofollow">https://github.com/c9r-io/orchestrator</a>
- Docs: <a href="https://docs.c9r.io" rel="nofollow">https://docs.c9r.io</a>
- Auth9: <a href="https://github.com/c9r-io/auth9" rel="nofollow">https://github.com/c9r-io/auth9</a>
- Install: `brew install c9r-io/tap/orchestrator` or `cargo install orchestrator-cli orchestratord`
- License: MIT