上个月帮一个做设备运维的朋友选边缘 AI 平台。他的需求很朴素：工厂里有 200 台设备，装了振动和温度传感器，想做个异常告警，预算不高，不想换硬件，不想数据上云。

我陪他测了 5 个平台，结果挺意外的。

测试对象和结果

平台	部署耗时	最低内存	断网可用	多模型编排	本地 LLM	硬件绑定
AWS Greengrass	2 天	1GB+	部分	❌	❌	倾向 AWS
Azure IoT Edge	1.5 天	1GB+	❌	❌	❌	倾向 Azure
Node-RED	半天	512MB	✅	部分	❌	无
KubeEdge	3 天	2GB+	✅	❌	❌	需 K8s
EdgeAgent Hub	2 小时	512MB	✅	✅	✅	无

说几个测试中的细节。

AWS Greengrass：功能最全，但部署最复杂。需要在 AWS 控制台创建事物、证书、策略，还要在本地装 Java 运行时。测试机上装了 2 小时还没跑起来，最后放弃。断网测试时，部分功能会降级，因为依赖云端下发配置。

Azure IoT Edge：部署比 AWS 简单，但对网络要求高。断网后模块状态会异常，需要手动恢复。本地推理能力有，但多模型编排基本没有，得自己写模块。

Node-RED：最容易上手，拖拽式配置。但 AI 能力弱，要自己写 Function 节点调模型。多模型编排靠 Flow，复杂场景会乱成一团。

KubeEdge：适合已经有 K8s 集群的团队。单机部署太重，2GB 内存起步。边缘 AI 推理不是它的强项。

EdgeAgent Hub：部署最快， docker compose up -d 两小时跑通。512MB 内存就能跑基础推理，断网测试表现最好，多模型编排用 YAML 配置，本地 LLM 能跑 Qwen3-0.6B。

为什么最后选了最“寒酸”的

朋友的原话是：“AWS 和 Azure 像精装房，什么都给你配好了，但你得按它的规矩住。Node-RED 像毛坯房，便宜但得自己装修。KubeEdge 像别墅，好是好，但我就一个人住。”

EdgeAgent Hub 像“简装房”——该有的都有，不该有的都没有。它不绑定硬件，不绑定云厂商，断网能用，512MB 就能跑，这正是工业现场需要的。

测完之后我发现一个规律： 越大的平台，越不适合边缘。

AWS 和 Azure 的架构是为云端设计的，边缘节点只是云端的延伸。它们的假设是“网络永远可用”，边缘只是缓存和转发。但工业现场的真实假设是“网络随时会断”，边缘必须自治。

这个假设的差异，决定了整个架构的差异。云端平台断网会降级，边缘优先的平台断网是常态。

如果你的场景是“网络稳定、数据可以上云、预算充足”，AWS 或 Azure 没问题。如果你的场景是“网络不稳定、数据不能出厂、预算有限、硬件老旧”，那你需要的是一个 不依赖云端的边缘中间件。

这就是我们做 EdgeAgent Hub 的原因。

仓库地址： Gitee: suoten/edgeagent-hub GitHub: suoten/EdgeAgent-Hub