Claude最新Agent Teams45分钟搭建红白机游戏厅

先分享几个核心观察。昨天AI领域可谓风起云涌，Anthropic与OpenAI几乎在同一时间发布了各自的旗舰模型——Claude Opus 4.6与GPT-5.3 Codex，两款产品的发布时间相隔不到20分钟。关于模型参数、上下文处理能力等技术细节，相信各家技术媒体已经做了详尽分析，这里就不再赘述了。

真正让我感到振奋的，是Opus 4.6中一项名为Agent Teams的全新功能。简单来说，这意味着AI不再单打独斗，而是能够自主组建团队协同作业。这一设计思路极具启发性，我立刻进行了实际测试，做了一个小项目，最终效果远超预期。

在分享我的实验经历之前，先来看看Anthropic官方公布的一个令人震撼的案例。他们的工程团队发布了一篇博客，标题为“利用并行工作的Claude团队构建C编译器”。该团队启用了16个Claude实例并行运作，历时两周，执行了近2000次会话，投入了大约2万美元的成本。最终成果是一个包含10万行Rust代码的C编译器，它能够编译Linux 6.9内核（支持x86、ARM、RISC-V三大架构），同时还能编译QEMU、FFmpeg、SQLite等核心软件，在GCC的压力测试中通过率高达99%。更令人惊叹的是，它甚至能编译并运行经典游戏《毁灭战士》。

说实话，看到这个案例时我确实感到震撼。让我震撼的并非结果本身——10万行代码的编译器固然厉害，但也仅止于此。真正让我深思的是实现方式：16个AI各自独立负责一部分任务，通过文件锁同步代码，借助Git协调版本管理，自动认领任务、完成开发、提交成果。你仔细体会一下这种开发模式。其实同时开启多个Claude Code窗口处理不同任务并不稀奇，我之前也经常这样操作。但Agent Teams的真正威力在于，多个Agent之间能够自动协调配合，分别处理不同任务后再进行集成测试。这意味着：在AI写代码的过程中，人类的响应速度可能不再是限制效率的瓶颈。

16个Agent、2万美元、两周时间——这是大型项目的玩法，我既没有那样的耐心，也承担不起那样的成本，更何况两周后谁又知道会有什么新模型问世。我更关心的是，一个普通开发者利用这个功能做点小项目，到底行不行？开发速度是不是真的能快到令人难以置信？

该选什么项目呢？我想起之前开发“小猫补光灯”App时，为了隐藏一个开发者模式入口，我采用了红白机游戏经典的作弊码方式——在设置页面按照特定顺序点击开关来激活。当时我还发了一条状态：“玩过红白机游戏的玩家应该都不陌生，就是通过左左右右BABA之类的特殊按键组合调出开发者模式。”既然如此，不如干脆做一个红白机游戏网站，一个在线FC游戏厅，让用户直接在浏览器里畅玩经典游戏。要求也很简单：至少包含100个可直接运行的游戏，配有封面图，有分类导航，界面设计要漂亮。

说干就干。打开Claude Code，先开启Agent Teams功能（目前仍处于实验阶段，需在settings.json中手动启用），然后我只说了一句话：“创建一个团队，由3个队友并行完成以下任务：搭建一个红白机游戏导航站，具备丰富完整的红白机游戏功能，至少包含100个可直接运行的游戏。”

Claude稍作思考后，主动解释了为什么不建议使用过多队友：文件冲突会增加、协调成本会上升、Token消耗会更大。它建议使用3个队友，我认为这个方案非常合理。接着，它自动创建了3个队友：emulator-dev，负责模拟器核心引擎；ui-dev，负责整个前端界面；data-dev，负责游戏数据库。这三块任务互不依赖，天然适合并行开发。

然后这三个队友就开始各自工作，我只需在一旁观察。emulator-dev封装了jsnes这个JavaScript NES模拟器库，处理了60fps的画面渲染、基于Web Audio的音频输出以及键盘输入映射。ui-dev实现的界面效果出乎意料地出色：暗色主题搭配NES经典红色，还加入了CRT电视的开机动画和扫描线特效，游戏卡片也采用了仿NES卡带样式，悬停时会发出微光。data-dev则整理了133款游戏的完整数据，包括英文名、中文名、发行年份、分类、描述、玩家人数、ROM文件名、评分，并且为127款游戏配置了真实的盒装封面图。

最终结果如何？仅用了45分钟。Vite + TypeScript + jsnes的组合，实现了133款可直接运行的NES游戏，127张官方游戏封面，CRT电视模拟效果，12种分类筛选，中英文搜索功能，双人游戏支持，全屏模式以及响应式布局。总计超过4700行代码，188MB的项目文件。如果让我一个人从零开始开发，不使用AI，天知道需要多久，我可能根本写不出来。如果使用单个Claude Code会话，可能也需要2-3个小时，因为任务之间存在先后顺序，需要等待。Agent Teams的优势就在这里——三个队友同时工作，谁也不必等待谁。最后代码合并时几乎没有出现问题，除了要求对用户体验进行几次优化外，实际部署时一次bug都没有出现。

经过这次实践，我有几点心得体会想要分享。第一，3个队友确实是这种规模项目的最佳数量。文件冲突、协调开销、Token消耗都会随队友数量线性增长，3个队友各司其职最为高效。第二，分工的关键在于“无依赖关系”——模拟器、界面、数据天然互不干扰，能够同时推进。如果让一个做前端、一个做后端、一个做测试，后两个就只能干等。第三，成本确实较高，Agent Teams的Token消耗大约是普通会话的7倍，日常的小修小补还是使用单会话更划算，它更适合“从零开始建立一个完整项目”的场景。第四，AI选择jsnes作为模拟器是一个相当明智的决策，我没有指定具体技术栈，它自己选择了一个最成熟、最合适的方案，45分钟完成开发，实际使用体验非常流畅，我上网查阅后发现，还真没有见过加载速度更快的方案。

其实“让AI组队写代码”的概念并不新鲜，去年就有人手动开启多个Claude Code窗口，相当于一个人肉版的Agent Teams。Agent Teams的真正贡献在于将这一过程产品化了——你不再需要手动开启窗口、手动分配任务、手动合并代码，只需要说一句“建一个团队，把这件事做了”就足够了。Anthropic的产品负责人Scott White在发布会上说了一句很有启发性的话：“我们现在正在过渡到一种‘氛围式工作’（vibe working）。”Vibe coding大家都了解，就是对AI说“帮我写这个功能”。而Vibe working则更进一步，是对一个AI团队说“帮我把这个项目完成”。

今天这45分钟的体验，让我真切感受到了这种区别。不过有一点需要注意，能否用好这个功能，关键其实不在于编程技术，而在于你是否能够把一个大型任务拆分成几个互不干扰的小任务。说白了，这考验的是项目管理能力。话说回来，上上下下左右左右BA，调出的不是30条命，而是一个AI团队。如果你想看看我这个网站究竟做得怎么样，体验入口就在这里了。