最新

我非常好奇听听一位软件营销人员的看法，为什么你认为旧金山的广告如此针对科技公司和科技工作者，与其他城市相比，这种现象甚至成为了当地文化和氛围的一部分。 显而易见，旧金山是一个人口密集的城市，拥有众多科技公司，消费能力强，创业文化盛行等等，但我记得在旧金山以外的地方几乎没有看到过科技广告。即使是像巴黎或伦敦这样的大城市，似乎也极少见到。 为什么会这样？除了上述原因，还有其他因素吗？

我在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

我们创建Operator23是因为看到团队在数十个工具之间手动连接自动化，实在让人感到痛苦。你只需用简单的英语描述你想要的，它就能在900多个应用中自动部署。无需YAML，无需奇怪的可视化构建器，也不需要在集成方面拥有博士学位。只需告诉它你的需求，它会处理剩下的事情。 我们真正解决的问题是，当前的自动化是碎片化的。你的营销团队使用一种工具，销售团队使用另一种，运营团队又使用三种。将它们连接起来就像是一场定制脚本和脆弱集成的噩梦。Operator23位于中间，能够理解它们的所有语言。你可以专注于真正想要自动化的内容，而不是与API和Webhook纠缠不清。 我们与自动化团队进行了交流，反馈一致：他们希望工具能够无缝协作，而不必头疼。这正是Operator23所做的。一次部署，自动化整个技术栈。说实话，这种工具早该存在了。