HackerNews中文版

我长期以来一直采用 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 设置。核心替换工作持续了 3 天，并且相同的方法和工具帮助我完成了后续的技术债务，并在月底前完成了社区 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 orchestratord` - 许可证: 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

Show HN: Agent Orchestrator，一个本地优先的Harness工程控制平面