蜂群建设日志 01：先画地图，再谈智能

我以为组建 AI 蜂群的第一步是安装 Agent，后来才发现：第一步其实是弄清楚自己到底有什么。

之前我写过一篇蜂群架构总览，但真正动手以后，发现“一个总控加若干执行节点”只是结构图。结构图很整齐，真实世界却是另一回事：Linux、Windows、macOS、手机、平板、NAS，安装方式不同，版本不同，能不能远程控制也不同。

如果连这些基本事实都没盘清，后面的调度、容灾和自动化，只是把不确定性放大。

在线，不等于可用

我第一次看到组网列表时，直觉是：亮着绿点，节点就在。

后来才发现，至少要分四层看：

第一层是“看得见”。它出现在节点列表里，只说明它曾经或正在与组网协调服务通信。

第二层是“连得上”。端口通不通，身份验证能不能通过，登录以后是不是预期的那台机器，要分开验证。

第三层是“服务活着”。即使能 SSH 进去，也不代表 Agent 网关正常，更不代表模型路由、插件和工具链都可用。

第四层才是“任务做成”。给它一个有明确输入和可验收输出的小任务，看它是否真的能完成，这才是节点加入蜂群的资格考试。

所以，“Online=true”不是结论，只是盘点的起点。

我遇到的第一个版本陷阱

盘点时还有一个很有代表性的坑：命令行工具显示已经升级，但后台真正运行的服务还是旧版本。

表面上看，“升级成功”；实际上，新老版本同时存在。如果只记一个版本号，后面的故障会非常难解释。

这件事让我把节点账本里的“版本”拆成两列：已安装版本，正在运行的版本。对于服务型软件，这两列必须同时回读。

不要强行把所有节点变得一样

蜂群的设备本来就不一样，升级方式也不会一样。Linux 可能由包管理器接管，macOS 可能是 Homebrew 或 App Store，Windows 有自己的安装链，移动端更可能只能等待本地操作。

一键脚本最诱人，也最危险。它容易把“批量”错当成“一致”，然后覆盖已有的安装源、忽略正在持有的进程锁，或对商店管理的客户端做无效操作。

真正可复用的不是一条升级命令，而是一个顺序：先识别系统和安装来源，再选择对应的升级方式，最后回读安装版本、运行版本和服务状态。

第一步的交付物，是一本活账

我最终没有把“节点数量”当成盘点结果。数字只能告诉我规模，不能告诉我能力。

一本真正有用的节点账本，至少要记住这些字段：

• 这是什么设备，运行什么系统；
• 它在蜂群中的角色和预期任务；
• 当前能否可靠连接，采用什么认证方式；
• 关键服务是否启动，是否可做健康探测；
• 已安装版本与正在运行的版本；
• 最后一次真实任务验收的时间和结果。

这本账不能是一张写完就归档的旧表。每次扩容、升级、迁移和故障处理后，它都应该被回写。否则，你调度的不是真实蜂群，而是记忆里的蜂群。

这一步怎样才算完成

第一步的验收标准不是“我看到了十几个绿点”，而是：每个节点都有明确的当前状态；无法连接、只能本地更新、服务异常和待验收的节点被单独列出；任何“已完成”都有当场回读证据。

盘点不是准备工作，它本身就是蜂群建设的第一步。

下一篇，我会写第二步：如何先让这些异构节点互相看见，以及为什么“网络在线”仍然不等于“能执行任务”。

下一步，一起把蜂群搭起来

如果这篇帮你把“在线”和“可用”分清了，别让它只躺在收藏夹里：

• 点个赞，让我知道你想继续看真实建设记录；
• 关注我，下一篇一起用 Tailscale 搭出蜂群的网络骨架；
• 转发给正在搭 Agent、自动化集群或家庭实验室的朋友，少踩一次“看起来在线”的坑。

也欢迎在评论区告诉我：你最想先接入哪一类节点？我会把大家最关心的问题写进后续实战。