AI 篇一：AICopilot 为什么是协同引擎

AICopilot 在这套 IIoT 体系里不是一个普通问答入口。它承担的是协同引擎角色：理解请求意图，检索项目资料，分析结构化业务数据，调用受控工具，并在有风险的动作前进入人工审批。

这个定位和管理中台、上位机平台的边界有关。管理中台是主数据、设备身份、配方版本和生产归档中心；上位机平台负责现场运行、插件化工序、PLC 任务和 Cloud/MES 双链路；AI 端不能重新定义这些制造业务规则。它只能基于已经存在的业务口径做解释、查询、分析和工具编排。

这张图展示的是 AI 端的能力边界。Intent Routing 负责分流，不直接吞掉所有业务。RAG 面向资料和规则，Text-to-SQL 面向只读数据分析，MCP 面向工具执行，Human-in-the-loop 面向风险控制。每条能力都能独立演进，不能为了省事揉成一个大服务。

AI 端不接管制造规则

AICopilot/AGENTS.md 里对项目定位写得很清楚：AI 可以引用云端业务语义，但不能静默改写云端业务定义。权限、设备、工序、上传语义需要对齐当前 cloud 业务；如果云端没有确认规则，AI 端不能自己发明。

放到 IIoT 项目里，就是几个边界：

• ClientCode 仍然是云端生成、客户端保存的寻址码。
• DeviceId 仍然是云端正式设备主键。
• bootstrap 仍然是边缘设备确认身份的入口。
• Cloud 上传仍然指向管理中台归档。
• MES 上传仍然是外部系统链路。
• 配方版本、设备绑定、产能归档仍然以管理中台规则为准。

AI 可以解释这些规则，可以检索对应文档，可以查询归档数据，也可以生成运维或分析建议。但 AI 端不能把 MES 改写成管理中台，也不能把上位机插件规则改写成另一套制造模型。

运行时依赖 Microsoft AI 抽象

当前 AI 运行时在 AICopilot.AiRuntime 中。项目引用了 Microsoft.Agents.AI.Workflows 和 Microsoft.Extensions.AI.Abstractions。这两个依赖把模型调用、工具调用、Agent 运行时和抽象接口组织起来。

AgentRuntimeFactory 会从容器里查找 IChatClientProvider，根据模型 provider 创建 chat client，然后接入 .UseFunctionInvocation() 和 .UseOpenTelemetry()。随后用 BuildAIAgent 创建运行时代理。这个结构把模型供应商、运行时、工具和业务服务隔开，后续替换模型或增加工具时，不需要把业务层改成某个 SDK 的形状。

RuntimeToolAdapter 负责把项目内的 AiToolDefinition 转成 AITool。如果工具不需要审批，就直接封装成函数；如果工具标记 RequiresApproval，就再包一层 ApprovalRequiredAIFunction。这说明审批不是文案层的提示，而是进入工具适配层的运行时约束。

分层结构和云端保持一致

AICopilot 不是直接堆接口。当前目录按 DDD 和应用分层组织：

• src/core：AiGateway、Rag、DataAnalysis、McpServer 等领域核心。
• src/services：命令、查询、工作流和应用编排。
• src/infrastructure：EF Core、Dapper、Embedding、EventBus、AI Runtime 等技术细节。
• src/hosts：HttpApi、AppHost、MigrationWorkApp、RagWorker 等启动和宿主。
• src/vues：前端。

这个结构和云端管理中台的分层方向保持一致。AI 端的业务规则进入 Core，应用编排进入 Services，数据库、SDK、模型和 MCP 协议进入 Infrastructure，控制器保持薄入口。

协同引擎的边界

AICopilot 的价值在于把几类能力串起来，但不篡改制造系统边界。面对“解释设备删除规则并检查某设备是否有历史产能”这类请求，RAG 可以检索业务规则，Text-to-SQL 可以查历史产能，最终结果再合并返回。面对“执行某个 MCP 工具修改文件或触发外部动作”这类请求，工具调用进入审批策略。

这就是协同引擎的含义：AI 不只是回答文字，也不直接替代业务系统；它在规则、数据、工具和人工审批之间做调度。制造规则由管理中台和上位机平台定义，AI 端按这些规则协助查询、解释和执行受控动作。

协同引擎不是聊天窗口包装

AICopilot 的能力边界不是“能不能回答一句话”，而是能不能把规则、数据、工具和审批串起来。Intent Routing 决定请求应该走知识检索、数据分析还是工具链路；RAG 找项目资料和规则；Text-to-SQL 读取结构化业务数据；MCP 提供工具执行；Human-in-the-loop 把高风险动作拦下来。

这几块能力必须分开。Routing 如果直接承接所有实现，后续会变成一个无法维护的大 agent；RAG 如果混入数据库写入，就会越过资料检索边界；MCP 如果不进审批，就会把模型输出变成无约束执行。当前架构把每条能力拆开，是为了让 AI 能协同，而不是让 AI 接管所有系统。

Microsoft 运行时提供的是组合能力

Microsoft.Extensions.AI 把模型调用抽象成统一 chat client，Microsoft.Agents.AI.Workflows 提供 agent/workflow 运行结构。项目自己的 AgentRuntimeFactory、IChatClientProvider、RuntimeToolAdapter 再把模型、工具和审批策略接入进来。这样模型供应商不是业务层的直接依赖，工具也不是 prompt 里的自由文本。

这种设计给后续重构留出了空间。模型可以换，工具可以增减，审批策略可以调整，但 AICopilot 的业务边界不变：它仍然是基于管理中台和上位机规则做检索、分析、调度和受控执行。

和三端边界的关系

管理中台决定设备、人员、权限、配方和归档口径；上位机平台决定现场运行、插件接入、PLC 任务和补偿；AI 端只能在这些口径上做协助。它可以回答为什么设备删除要检查历史依赖，可以分析某台设备一段时间内的产能，可以准备 MCP 工具动作，但不能绕过业务主链路。

这个边界让 AI 的价值更稳定。它不需要重新发明制造业务，只需要把现有业务规则和数据用更低成本调动起来。

重构方向要服务边界清晰

AI 端还在重构，写它时不能把未稳定的 UI 当成交付结果。更稳妥的表达是讲清楚当前架构方向：Intent Routing 负责分流，RAG 负责资料检索，Text-to-SQL 负责只读分析，MCP 负责工具接入，Human-in-the-loop 负责风险动作审批。

这个方向和管理中台、上位机平台能对齐。管理中台给 AI 提供业务规则和归档数据，上位机平台给 AI 提供现场运行和诊断语义，AI 端把这些信息组织起来辅助人处理问题。它不是第三套制造系统，也不是把所有功能都塞进聊天窗口。

当 AI 后续加入更多工具时，仍然要保留这个边界。查询和解释可以自动化，写入和外部副作用要进入审批。模型能力越强，边界越要清楚。