Agent Orchestrator：一个本地优先的工程控制平面

gpgkd906 · 2026-03-29T12:05:13.000Z

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. 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 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. 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. 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. - GitHub: - Docs: - Auth9: - Install: brew install c9r-io/tap/orchestrator or cargo install orchestrator-cli orchestratord - License: MIT

gpgkd906，持续分享值得阅读的内容。关注

我花了很长时间在XP/TDD风格下工作，所以当AI编程工具变得足够实用时，我很快就采用了它们。我遇到的第一个瓶颈不是代码生成，而是验证：AI可以快速编写代码和测试，但我仍然是那个审查实现、点击流程、检查日志、检查数据库状态并判断结果是否正确的人。

这促使我把认可感往左推。在实施之前，人工智能必须制定测试计划。实现后，它还必须执行这些计划：驱动浏览器、检查日志、检查数据库状态、创建故障工单、修复并重新测试直到输出收敛。

Auth9成为该方法的试验场。一旦它明显工作，我就开始构建Agent Orchestrator，这样整个过程就不用我手动监督每一步了。

到二月中旬，我已经在 Auth9 中使用了早期的 Orchestrator 风格自动化。三月中旬，我在迄今为止最高风险的重构中使用它：用原生 auth9-oidc 引擎替换无头 Keycloak 配置。

核心替换在3天内完成，同样的方法和工具帮助收敛后续技术债务，并在月底前完成了社区OIDC认证测试。那时我开始确信这不仅对新建工作有用，也适用于管理真实系统中高风险变更。

当时，“编排”是我最关心的词，这也是项目名称的由来。后来，OpenAI的“Harness Engineering”框架为我赋予了作品更宽广的名称。该项目目前是一个本地优先的Rust控制平面，用于长期运行的代理工作流：YAML资源、SQLite支持的任务状态、机器可读的CLI输出、结构化日志以及围绕shell代理的防护栏。

- GitHub： - 文档： - Auth9： - 安装：brew install c9r-io/tap/orchestrator 或 cargo install orchestrator-cli orchestratord - 许可证：MIT

添加评论

点踩

分享查看原文

参与讨论