现在搭建《过山车大亨》类游戏比以往更容易

这篇文章我准备花不少篇幅讲我们是怎么做出一个《过山车大亨》的，但在开始之前，我得先声明一下。有些人可能知道，我本人一直对那些拿几百个 agent 把某个库移植到 Rust、或者拼出一个半吊子浏览器的营销噱头不太感冒。这类过程总让人觉得是精心挑选过的。是，行吧，我明白你的 agent harness 勉强能造出个 Chrome，可它解决我的业务需求了吗？这些从来都是营销噱头，吹得天花乱坠，实际交付的却少得可怜。

所以本着不夸大其词的精神，我想先说明：现在做一个《过山车大亨》真的非常非常容易。除此之外我什么都没主张！我敢说这套工具大概率也能用来做很多别的东西，但我确确实实知道的是，你肯定能做出一个《过山车大亨》。不信的话，可以去 opencoaster.noriagentic.com 试试我们的《过山车大亨》，说不定能启发你做一个自己的。或者做点别的也行。

我们从今年年初就开始运营一个软件工厂。碰到的一个问题是自动化疲劳。我们有太多小的 agent 进程，7×24 小时地做着太多琐碎的事。单独看每个进程都很好理解，但很快我们的 agent Slack 频道就被刷屏了。严格说“刷屏”这个词可能不太准确，因为那些信息勉强算是有用的，但你根本没办法全部消化，于是也就没人会去读。最后我们干脆关掉了一半的自动化。

说细一点，我们的软件工厂跑在一批临时云 VM 上（我们对云厂商基本不挑，但托管云一般喜欢用 modal）。这些 VM 由一个中央 orchestrator 管理。编排层负责所有组织级别的事情，比如凭据、跟踪传入事件。它还为集群里的每台 VM 管理一个状态机，并保存着如何触发各类自动化的信息。

在我们的系统里，一个 automation 本质上就是一个包含三个字段和若干子字段的数据结构：

每当 automation 的触发事件发生，orchestrator 就把相关的 agent 信息发送到某台 VM 上，用 automation 的 prompt 启动进程。每台 VM 外围都有一层代理网络，用于安全和跟踪。orchestrator 会监视运行该 automation 的机器的网络流量；当流量安静一段时间后，就把它关掉。

只要有正确的 scope，VM 里运行的 agent 就能和 orchestrator 通信，修改组织级别的设置。这让搭建任何类型的自动化都变得极其简单。 literally 在聊天里随便问一个 agent：

这真的很了不起！但如果你像我一样有点 AI 精神病，每两小时就往 agent 那儿扔一堆新想法，那很快就会彻底失控。比如说，我们真的需要一个每 30 分钟检查一次 Twitter 和 LinkedIn 的 agent 吗？这大概够得上 Anthropic 新出台的“禁止虐待模型”禁令了。至少它让我们大部分的 agent 通讯变得没法用了。你能看到大家翻过第十五条 AI 摘要、总结、请求之类的东西时，眼神都木了。

为了让这些 pipeline 更好管理，我们试了几种不同的办法。

这很酷，但它并没有帮我们理清自动化的组织方式。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）