单机 agent 用来试玩很顺手，但真开始拆活，很快就会发现问题不在模型，而在协作本身。

一台机负责资料，一台机负责审阅，一台机负责最终表达，另一台机负责总控、催办和收口。只要任务真的分散到几台 VPS 上，事情马上就不再是“模型够不够强”，而会变成一些更现实的问题：机器怎么互通、任务怎么交接、文件怎么传、谁卡住了、主控怎么知道。

我这次折腾的重点，其实就是把这件事从“几个 agent 一起聊天”拉回到“多机器工作流”。最后落下来的方案并不花哨：Tailscale 负责把机器拉进一张内网，task-bus 负责传任务、附件和状态。

关键不是“多 bot 一起说话”

很多人一提多 agent，第一反应就是把几个 bot 拉到一个群里，让它们互相说话。

这个思路看起来很热闹，但真落到工程上，问题会很快冒出来：谁负责什么不清楚，中间产物容易丢，状态不可见，最后看起来所有节点都在动，实际上没人真正交付结果。

所以我后来把这套协作关系收敛成四个固定角色：

• main：总控、派单、催办、验收、收口
• nano：第一手资料位
• sg：审阅和结构收敛
• jp：最终表达和验收位

角色一旦明确，很多东西反而简单了。多机协作不是群聊，它更像接力跑：上一棒要交得清楚，下一棒才能接得稳。

为什么底座选 Tailscale

原因其实很直接：我不想为了几台机器之间互通，就把一堆协作端口直接暴露到公网。

Tailscale 的价值不在“看起来高级”，而在于它先帮我解决了最基础也最麻烦的那一步：把分散的机器拉进同一张受控内网。

这样一来，节点之间的 task-bus 监听就可以直接挂在 tailnet 地址上：

• main -> XXXX:18100
• nano -> XXXX:18101
• sg -> XXXX:18102
• jp -> XXXX:18103

这带来的好处很实际。人访问站点，继续走公网入口或者 Tunnel；机器之间跑协作，则老老实实走内网。两条线分开之后，边界会清楚很多。

为什么 task-bus 要故意做得克制

我一开始就没想把它做成“远程互控平台”。

当前这条总线只做四件事：

• POST /task
• POST /upload
• GET /status
• GET /health

说白了，就是：收任务、收附件、查状态，不做远程执行。

这里之所以故意收得很死，是因为多机协作最怕的不是“不够自动化”，而是太早把执行面放出去。系统还没稳定，边界还没想清楚，节点之间就开始互相调命令，后面一定会变脏，也一定会出安全问题。

所以第一阶段的目标一直很明确：先把消息、附件、状态这三件事做稳，再谈更复杂的能力。

这条链已经不是想法了

现在这套结构已经有真实目录、真实 consumer、真实产物。

每台机器上都有类似的目录：

• inbox/
• artifacts/
• archive/
• logs/

几个关键 consumer 也已经在跑：

• de_consumer.py
• sg_consumer.py
• jp_consumer.py

对应的接力链路也已经能完整走通：

main -> nano -> sg -> jp -> main

更重要的是，这不是嘴上说通了，而是真的有中间产物落盘：

• candidate-list.md
• de-raw-output.txt
• sg-review.md
• jp-final.txt

这也是我后来越来越在意的一点：有没有 evidence。

多机协作里，没有文件、没有日志、没有可验证回执，就不算进度。这个原则听起来很硬，但一旦节点变多，它反而是避免假进度最有效的办法。

这次最值钱的，不是跑通，而是踩坑

如果只说“我们把多机协作搭起来了”，那这篇东西其实没什么价值。真正有意思的，反而是这次踩出来的几个坑。

第一个坑，是把跨机器 team 误当成本地 subagent。

这两者看起来都叫多 agent，但根本不是一回事。本地 subagent 更像一个 runtime 里的分支；而现在这套 main / nano / sg / jp，是分布在不同机器上的 team。派单方式、状态可见性、失败定位，全都不一样。

第二个坑，是把“投递成功”当成“任务完成”。

文件进了 inbox，甚至显示 processed，都不代表真正交付了结果。只有产物落盘、状态回传、链路闭环了，才能算真的推进。否则看起来像在动，其实只是系统在空转。

第三个坑，是旧桥接链路总会伪装成“最短可用”。

赶时间的时候，人很容易回到老习惯：SSH 上去，直接往对方 inbox 塞 JSON，觉得反正也能跑。这个办法的确快，但它只解决“送到”，不解决“闭环”。回执、状态、失败升级、审计，这些东西全都会跟着打折。

第四个坑，也是这次让我印象最深的一个：通道走对了，协议也得走对。

我后来人工接管了一次 nano，本来以为已经改成 Tailscale /upload + /task 就没问题了，结果还是翻车。原因很简单：我自作主张换了附件命名，写成了新的 research pack；但 sg_consumer.py 只认原来那套固定文件名，结果它虽然收到了任务，还是直接 blocked。

这件事把一个规则钉得很死：

人工接管某一环，不代表可以顺手发明新的中间协议。现有 consumer 吃什么，你就得喂什么。

最后按标准格式重新投喂，这条链才恢复正常，sg -> jp -> main 也才顺利跑完。

我现在怎么理解这套系统

如果要我一句话总结，我会说：

这套东西最有价值的地方，不是让几台机器上的 agent 终于“聊起来了”，而是把多机协作慢慢做成了一条可验证、可交接、可收口的工程链。

这和演示型多 agent 最大的区别就在这里。

演示型系统最看重“看起来很聪明”；工程型系统更在意：

• 有没有 evidence
• 有没有明确责任人
• 有没有任务状态
• 有没有中间产物
• 卡住之后能不能回收
• 最后能不能收口

这些东西听起来不浪漫，但真做久了会发现，它们比“模型多能说”重要得多。

后面还要补什么

当然，这条链现在还没到稳态。

后面至少还有几件事要继续补：

• 更明确的 timeout 和升级机制
• 更严格的 ACK / delivery 规则
• 更细的 ACL
• 更稳定的附件协议约束
• 更完整的审计记录

换句话说，Tailscale 只是底座，task-bus 只是第一版骨架。真正成熟的多机协作系统，还得继续往上长。

不过至少到这一步，我已经比较确定一件事：比起让更多 agent 一起说话，先把任务、状态、附件和收口做好，才是多机协作真正能落地的起点。

#OpenClaw #Tailscale #MultiAgent #VPS #自动化 #运维