IoT DC3：把工厂车间接到 AI 智能体上

想象一条产线上的三台设备：一台老旧的西门子 S7 PLC，一台支持 Modbus TCP 的变频器，还有一台只会说私有 TCP 协议的温控仪。运维工程师要监控它们，得翻三本不同厂商的说明书；而当你想让 AI 助手"看一眼这台电机今天热不热"时，AI 面对的却是一堵由协议、点位表、注册地址砌成的墙。

IoT DC3（pnoker/iot-dc3）就是拆这堵墙的工程。它是作者 pnoker 自 2018 年 8 月起持续迭代的开源工业物联网运行时，2026 年开始明确转向 "Physical AI" 定位——把物理世界的数据接到 AI，再让 AI 通过受控、可审计的回路反向操作物理世界。

图：平台 Dashboard 总览，展示在线设备指标与数据趋势

它到底解决什么问题

DC3 的核心设计哲学是解耦设备与应用：驱动层负责把各类协议翻译成归一化的"点位数据"推入消息总线，应用层只通过统一 API 消费数据。加一个新型号设备不用改应用，写一个新应用也不用改驱动。

这在工业场景里价值极大——现场的设备品牌和协议是历史遗留的混合体，而上层需求（OEE 监控、数字孪生、AI 告警归因）却在快速变化。DC3 把这种"下层杂乱、上层灵活"的问题用微服务架构标准化了。

目前内置 36 个协议驱动模块，覆盖面相当宽：

类别	驱动
工业协议	Modbus TCP/RTU、OPC UA/DA、Siemens S7、BACnet/IP、EtherNet/IP、Omron FINS、Mitsubishi MELSEC、IEC 60870-5-104、IEC 61850、DNP3、DLMS、DLT645、KNX、M-Bus、SL651
IoT 协议	MQTT、CoAP、LwM2M、HTTP、BLE、Zigbee、LoRaWAN
数据桥接	MySQL、PostgreSQL、Oracle、SQL Server、Redis
基础通信	TCP/UDP、Serial、SNMP、CAN、Kafka
仿真调试	Virtual、Listening Virtual

工业协议这一栏是国内同类开源项目里少见的厚度，这也是它 2026 年能冲到 1288★ 的根本原因。

六层架构

DC3 采用六层微服务架构，横向切分而非纵向堆砌：

客户端 (Web/CLI/外部 Agent)
   ↓
Spring Cloud Gateway（统一 HTTP 入口）
   ↓
五大中心：Auth / Manager / Data / Agentic / Single
   ↓
消息总线（RabbitMQ 默认，可换 Kafka/Pulsar/MQTT5）
   ↓
36 个协议驱动
   ↓
现场设备

持久层用 PostgreSQL，额外挂了 TimescaleDB（时序）、pgvector（向量）、AGE（图）三个扩展，覆盖实时数据、历史曲线查询和设备拓扑关系三种需求。服务间调用统一走 gRPC + Protobuf，各服务无状态可水平扩展。

图：六层架构全景图，含 PostgreSQL 扩展与 ELK + Prometheus + Grafana 可观测栈

亮点：让 AI 真正能碰设备

大多数 IoT 平台和 AI 之间是"单向"的——AI 只能看图表。但 DC3 做了两个让 AI 反向操作物理世界的关键设计：

1. Agentic Center（端口 8600）

基于 Spring AI 2.0.1 构建的智能中心，把平台资源包装成一组工具：DriverTool、DeviceTool、PointTool、PointValueTool、ProfileTool、CommandTool、EventTool、UserTool、TenantTool、SystemTool。用户用自然语言问"三号产线昨天 3 点的能耗是多少"，LLM 通过 Tool Calling 查数据并生成图表；告警时 AI 辅助做根因分析与处置建议。模型侧兼容 OpenAI API 风格接口，GPT、Claude、DeepSeek、Qwen 都能接，也能指向自建的本地模型。

图：AI Agent 助手页面，支持自然语言设备查询、数据洞察与受控执行

2. MCP 工具网关

这是我认为最有前瞻性的一块。DC3 不只让自家 Agentic Center 用 AI，而是把平台能力以 Model Context Protocol 暴露给外部任意 AI 客户端——你的 Claude Code、Cursor 或自研 Agent 都能直接调用设备查询、点位读写等工具。

关键在于"安全、可控、可追溯"三个约束落到了工程实现上：OAuth 客户端注册、按工具粒度的授权、以及每次工具调用的完整审计链路。在工业场景里，AI 能读数据和 AI 能下发控制指令是两种完全不同的风险等级，把授权和审计做成平台内置能力而不是各家 Agent 自己实现，这个选择是对的。

上手门槛：真实但不高

源码开发路径官方文档写得很清楚，基础设施容器化、中心服务本地跑：

make up-db                              # 起 PostgreSQL + RabbitMQ
source dc3/env/dev.env.sh
mvn -s .mvn/settings.xml clean package  # 多模块构建

前置要求：JDK 21（低版本直接编译失败）、Maven 3.9+、Node.js 22+ 与 pnpm、Docker 或 Podman。服务端启动有严格顺序：Auth(8300) → Manager(8400) → Data(8500) → Agentic(8600) → Gateway(8000)。

更省事的是容器化路径。仓库根目录是一个统一多目标 Dockerfile，Maven 构建放在 builder stage 内部，宿主机连 JDK 都不需要装；BuildKit 缓存让多个服务镜像共用一次 Maven 构建。dc3/ 目录下有 8 套 compose 编排：dev、scale、swarm、native、single、local、db、optional，覆盖开发调试到生产集群的各种形态。dc3/deploy/ 下还有完整的 K8s 清单（含 HPA、PDB、Ingress、Secret 示例）和 Helm Chart。

值得注意的是 GraalVM native-image 支持：center 服务与 gateway 可以编译成原生可执行文件，冷启动时间和内存占用显著下降，这点对边缘侧部署很实用。

整体评价：部署难度中等（3/5），预计 30-60 分钟。有 Web UI（Vue 3 + Element Plus，中文界面完整），首次访问 dc3.site 或 demo.dc3.site 可先看效果再决定要不要落地。

生态与社区

指标	数值
Stars	1288
Forks	235
Watchers	16
Open Issues	36
贡献者	17 人
总提交	3665 次
2026 年内提交	1864 次
合并 PR	213 个
首次提交	2018-08-28
最近推送	2026-10-23

2026 年一年内 1864 次提交，占历史总量的一半——这是一个处于高速迭代期的项目，而非躺在旧版本上吃老本。CI 侧划分了 backend / cli / web / e2e / test / docker / codeql / security 九条流水线，前端用 Vitest + Playwright 双层测试，还有专门的 agentic-dialogue 评测套件（eval:agentic-dialogue、eval:agentic-scenarios），说明团队把 LLM 对话质量也纳入了工程化验证。

作者还维护了 Gitee GVP 镜像，对国内网络环境友好；仓库提供中、英、日、韩、西、俄、越 7 种语言 README。

争议与局限

AGPL-3.0 是一道真实门槛。 仓库同时提供商业授权说明：个人学习研究、内部使用、修改后开源均免费；但"将修改版作为商业服务提供给第三方"需要购买商业授权。对打算把它做成 SaaS 对外提供 AI 运维服务的团队来说，AGPL 的网络传染性会直接影响商业模式决策。这一点必须在上线前和法务确认。

技术栈较重。 Spring Boot 4 + Spring Cloud 2025 + gRPC + PostgreSQL(三个扩展) + 消息总线 + Vue 前端，全套拉起来对机器有要求（建议 8GB 内存起），且服务启动顺序严格。个人学习用 dc3-single 单体模式会轻松很多。

README 中的行业看板是 mock 数据。 12 个行业场景（智能工厂、水网、微电网、精准农业、智慧建筑、智慧交通、油气管线、智慧矿山、冷链、环境监测、智慧港口、充电桩）全部标注为 "built on IoT DC3 with mock data"。它们展示的是界面与交互形态，不是真实交付案例，别把它当成落地参考。

AI 能力仍在早期。 Agentic Center 的模块 README 明确写着自己是 "a thin Spring Boot shell"，真正的智能体逻辑在 dc3-common-agentic 里。对话评测脚本还在演进中，LLM 行为的稳定性需要实测验证——尤其考虑到它能下发设备写指令，生产环境务必从只读工具权限开始灰度。

生态规模有限。 17 位贡献者对于一个 3665 次提交的项目来说，社区参与度不算高，商业化支持主要依赖作者团队。

行业意义

DC3 折射出一条清晰的技术演进线：传统 IoT 平台 → 边缘云原生 → 物理 AI 运行时。前两代平台解决了"数据怎么连上来"，DC3 在此之上补上"AI 怎么安全地用起来"，并且通过 MCP 把这个能力开放给外部智能体，形成生态位。

它的 36 个工业协议驱动是实打实的工程积累，不是概念拼装；Spring AI + MCP + OAuth + 审计的组合拳，则是把"AI 操作工业设备"这件事从演示 Demo 推进到可治理的工程实践。这种"数据可见 → 可查询 → 可被 AI 调用 → 调用可授权可追溯"的完整闭环，是 Physical AI 落地必须补齐的一层基础设施。

对于工业物联网平台选型的团队，DC3 值得放进候选清单认真评估——尤其是协议驱动覆盖面和 MCP 网关这两点在国内同类项目中相当突出。需要提前想清楚的是 AGPL 授权边界，以及这套较重的云原生架构是否匹配你的团队运维能力。

---

数据采集时间：2026-10-24 | 数据来源：GitHub API + 官方文档站 | 分析对象：pnoker/iot-dc3 @ main