大模型在工业场景的落地存在三个具体障碍：
连不上 ------模型无法感知实时现场数据；不敢给 ------设备接口的权限控制难以放开；答不准------工业场景要求确定答案。
DC3 的 AI Agentic Center（dc3-center-agentic，基于 Spring AI 2）就是围绕这三个卡点设计的。以下先说明当前能力，再说明设计边界。
能力栈：模型在变，工具面不变
整个能力栈分三层看：
模型接入层------多模型兼容。 走 OpenAI API 风格的接口，GPT、Claude、DeepSeek、Qwen 这些主流模型都可以接。这一设计使平台层不绑定任何模型厂商，替换模型仅涉及配置变更。
Agentic Center------会话与工具的编排层。 多轮对话的上下文与记忆持久化到数据库（换个终端登录，会话还在），Tool Calling 把平台的业务能力注册成模型可调用的工具。
平台工具面------模型真正能触达的范围。 在访问控制之下，模型可以查询设备与点位、读写点位值、辅助构造与下发命令。注意这个范围的边界设计：模型调用的每一个工具，背后都是平台既有的 API 与权限体系------模型没有特权账号。
一次真实的对话发生了什么
以 Web 端 AI Chat 里一个典型问题为例："3 号车间最后一小时温度最高的设备是哪台？"
路径是：模型理解意图 → 发起工具调用（按租户与权限过滤的设备列表查询）→ 发起数据查询（最近一小时的温度点位数据）→ 拿到的是数据库里的确定数值，不是模型生成的估计 → 模型组织语言回答，并可生成趋势图。
这是对"答不准"的工程解法：数值来自数据库，语言来自模型------模型负责理解与表达，事实由平台数据保证。
告警场景类似：AI 辅助根因分析将相关设备的点位、命令历史与同类告警模式提供给模型，产出分析建议供运维决策。
刻意不做的三件事
- AI 不自主执行处置：停机、启停等命令动作由 AI 辅助构造，下发仍走平台命令链路并由人工确认。这一边界与网信办《智能体规范应用与创新发展实施意见》（2026-05）的"规范有序"要求一致；
- 不做无权限的裸调用。 每次工具调用都在调用者身份与租户上下文内进行，能查什么、能写什么，与人在平台上能做的完全一致；
- 不绑定模型：模型可插拔，平台能力不依赖特定厂商特性。
实事求是的边界
- AI 能力上限由所选模型决定，平台保证调用链路与数据面的正确性；
- 根因分析质量取决于点位建模完整度------数据不完整时分析缺乏基础。
仓库 ：GitHub
pnoker/iot-dc3· Giteepnoker/iot-dc3（GVP）文档：docs.dc3.site · book.dc3.site · demo.dc3.site（在线体验 AI Chat）