北京
凌晨3点09分，终端窗口里四个面板同时刷新，编译完成的APK被推送到手机上，冷启动后登录界面完美呈现。而在git时间线上，从晚上7点38分到此刻，没有一行应用代码是由人手敲出来的。一个人，一晚上，用五个Claude Code代理并行驱动，交付了一个多租户的Flutter SaaS——包含消费者端、运营管理后台、QR签到、现场收银，以及部署好的Firebase后端。
这个说法的支撑很硬：仓库里的每一次提交、每一份目标文件、每一段观察者捕获的日志，都指向同一种编排模式。作者没有让任何一个代理触碰其他代理的目录，而是通过一个名为Hermes Agent的指挥层来分发任务。Hermes不写任何业务逻辑，它只干一件事：为每个面板写一个目标文件，扔进对应的Claude Code实例，然后挂上一个观察者，等它放好标记文件。一旦标记落盘，下一轮目标立刻重新播种。
这种并发模式的质疑集中在两点：多个AI同时改库会不会冲突，以及它们如何传递“完成”信号才不会互相等待。而实际的操作记录给出了答案。从文档记录看，2026年5月30日凌晨0点21分到28分之间，前端和后端同时落了两组提交，一组负责Firebase API接线和多租户数据模型，另一组做了并发基础设施升级，完全没有环锁。这依赖一个简单的约定：结果通过标记文件而非轮询来通知观察者，指挥层只读取这个文件来判定任务终结，随后清理、启动下一个目标。观察者窗口里甚至可以同时捕捉到APK安装成功和“前端完成”的ping——03:06:10 APK安装成功，03:07:10 前端标记“auth errors now show the real code”，新构建已经就绪。
一组真实的目标文件可以看清这种分工。一段给前端代理的目标写道：“GOAL: ship PRD-006 (auth routing fix + email/password) on the CLIENT FLUTTER APP only. Your turf is `ap`……”它严格限定了“只在客户端应用，目录仅限ap”。这种指令的精确性，加上每个代理拥有独立的壳环境和目录树，让四个、后来五个代理在同一个单仓库里并行打磨一个应用成为可能，而不会冒犯彼此的代码区间。
当然，将这一切串起来的不仅是Hermes。可见的底层是Herdr，一个为代理建造的终端多路复用器；编译好的APK通过Tailscale无线adb推到手机上；监测用的二维码扫描依靠mobile_scanner；自托管的Honcho记忆后端运行在本地Ollama之上。但这些只是组件清单。真正让人多看一眼的，是模式本身：用标记文件完成异步握手，用目录隔离保证并行安全，而人类全程只写目标文件。
这种方式能不能变成日常？一个晚上的实验结果并不能直接等同于生产级实践。但这次交付至少说明，多代理协同开发的门已经推开了一条缝。当指挥层足够轻量、代理的执行边界足够清晰时，代码仓库就不再是单线程的人类领地了。你甚至可以把这个实验看作一个微小的原型：把开发拆成可验证的子任务，让多个AI各自在一个隔离空间里跑完，最后拼成一个能运行的产品。至于代码质量、长期维护和设计一致性，那就是下一轮目标文件要回答的问题了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
