一、项目背景与核心目标

（一）技术背景

Model Context Protocol（MCP）作为 AI 大模型的标准化交互协议，能够实现 AI 与各类数据源、工具的无差别对接，而 OPC UA 是工业场景中 PLC 设备通信的主流协议。搭建 OPC UA-MCP 桥接服务可解决协议兼容性问题，为 AI 管控工业设备提供通信基础。

在桥接服务的基础上，引入大语言模型（LLM）并开发集成客户端，能够实现自然语言指令驱动的工业设备交互，无需人工编写复杂调用脚本，大幅降低工业 AI 应用的使用门槛，适配企业级智能管控的实际需求。

（二）项目目标

1. 开发基于 Python 的异步 MCP 客户端，实现与 OPC UA-MCP 桥接服务的稳定通信；
2. 完成客户端与企业级 LLM 接口的对接，支持自然语言指令到 MCP 工具调用的自动转换；
3. 实现智能交互逻辑，支持工具调用结果的自动解析与多轮推理，满足工业场景下的节点查询、数据读写需求；
4. 验证端到端集成链路的可用性，确保从自然语言输入到工业设备数据返回的全流程顺畅运行。

二、前置环境准备

为保障集成流程顺畅，需提前配置以下基础环境与工具：

1. 编程语言环境：Python 3.13+（确保异步库与 MCP 依赖兼容性）；Node.js 18+（用于 MCP Inspector 调试）；
2. 依赖管理工具：uv 或 pip，需安装aiohttp（异步网络请求）、python-dotenv（环境变量管理）、mcp（MCP 协议客户端库）；
3. 服务依赖：已部署运行的 OPC UA 模拟服务器、Python 版本 OPC UA-MCP 桥接服务；
4. 辅助工具：代码编辑器（VS Code）、终端工具（Windows Terminal/iTerm2）、LLM 接口访问权限（含有效 API Key）。

三、核心开发与实施细节

（一）核心代码功能架构

本次开发的llm-client.py作为集成核心，主要包含5 大功能模块，各模块职责如下：

模块名称	核心功能	关键技术点
MCP 客户端初始化模块	建立与 MCP 服务的连接、获取可用工具列表	基于mcp.ClientSession的异步会话管理、AsyncExitStack资源自动清理
LLM 工具封装模块	将 MCP 服务工具转换为 LLM 可识别的函数格式	解析 MCP 工具的inputSchema，生成符合 LLM 调用规范的参数描述
LLM 接口调用模块	构造请求参数、发送异步请求、解析流式响应	aiohttp异步 POST 请求、流式响应分块解析、JSON 格式校验与容错
智能推理交互模块	实现多轮工具调用与结果处理逻辑	基于系统提示词的指令引导、对话历史管理、迭代推理控制
交互循环模块	提供命令行交互入口，接收用户查询并返回结果	asyncio.to_thread实现同步输入异步处理、资源优雅关闭

（二）完整代码逐段说明与注释

1. 导入依赖包（基础环境准备）

python

运行

# 操作系统相关操作（如路径处理）
import os
# 系统参数与退出操作相关
import sys
# JSON数据格式解析与序列化（用于LLM请求/响应、工具参数处理）
import json
# 生成唯一会话ID（用于LLM接口请求标识）
import uuid
# Python异步编程核心库（实现非阻塞IO、异步任务调度）
import asyncio
# 异步HTTP请求库（替代同步requests，提升并发处理能力，适配工业多设备查询）
import aiohttp
# 异步上下文管理器（用于自动管理多个异步资源，避免资源泄露）
from contextlib import AsyncExitStack
# 加载.env文件中的环境变量（管理敏感配置如LLM API Key）
from dotenv import load_dotenv

# MCP协议相关核心导入（实现与MCP服务的通信、会话管理）
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
from mcp.types import PaginatedRequestParams, PromptReference

# 加载项目根目录的.env文件，读取配置项
load_dotenv()
# 初始化LLM原始输出日志文件（追加模式，UTF-8编码避免中文乱码），用于调试与问题排查
log_file = open("llm_raw_output.log", "a", encoding="utf-8")

代码说明：

• 导入分为「基础工具包」「异步编程包」「MCP 协议包」三类，职责清晰；
• load_dotenv()自动加载.env配置，避免硬编码敏感信息；
• 提前创建日志文件并以追加模式打开，确保全程记录 LLM 原始输出，便于后续调试。

2. 定义 McpClient 核心类（客户端核心封装）

python

运行

class McpClient:
    def __init__(self):
        """类初始化方法：初始化所有核心属性，为后续会话做准备"""
        # MCP会话对象（用于与MCP服务进行交互）
        self.session = None
        # MCP标准输入输出传输对象
        self.stdio = None
        # MCP写入操作对象
        self.write = None
        # 异步资源管理栈（自动管理所有异步上下文资源，确保优雅关闭）
        self.exit_stack = AsyncExitStack()
        # LLM接口API Key（访问企业级LLM接口的身份凭证）
        self.llm_api_key = "sk-bdc1da565cf343c1b99d7732a1692dd1"
        # 最大推理迭代次数（避免无限循环，提升鲁棒性）
        self.max_iterations = 5
        # 可用MCP工具列表（存储从MCP服务获取的工具元数据）
        self.available_tools = []  # 初始化工具列表

代码说明：

• 构造方法仅做属性初始化，不执行复杂逻辑，保证类实例创建的轻量性；
• 核心属性均赋予初始值（None或空列表），避免后续调用出现「属性未定义」异常；
• max_iterations限制最大推理次数，是工业场景下的容错设计，防止因 LLM 决策异常导致程序卡死。

3. MCP 服务连接与初始化（建立通信链路）

python

运行

    async def connect_to_server(self, server_script_path: str):
        """
        初始化MCP会话，建立与OPC UA-MCP桥接服务的通信连接
        :param server_script_path: OPC UA-MCP服务端脚本路径（如opcua-mcp-server.py）
        """
        # 构造MCP服务端参数：指定运行命令为python，参数为服务端脚本路径
        server_params = StdioServerParameters(
            command="python",
            args=[server_script_path]
        )
        # 建立标准输入输出传输通道，并将其加入异步资源管理栈
        stdio_transport = await self.exit_stack.enter_async_context(stdio_client(server_params))
        self.stdio, self.write = stdio_transport
        
        # 建立MCP客户端会话，同样加入资源管理栈，确保退出时自动关闭
        self.session = await self.exit_stack.enter_async_context(ClientSession(self.stdio, self.write))
        
        # 初始化MCP会话，完成与服务端的握手协商
        await self.session.initialize()
        print("\n成功连接到 OPC UA MCP Server")

        # 调用MCP会话的list_tools方法，获取服务端所有可用工具
        response = await self.session.list_tools()
        self.available_tools = response.tools
        
        # 打印可用工具列表，便于用户查看当前支持的功能
        print("\n连接到具有以下工具的服务器：", [tool.name for tool in self.available_tools])

代码说明：

• 异步方法connect_to_server是建立 MCP 通信的核心，所有操作均为异步非阻塞；
• StdioServerParameters指定 MCP 服务的运行方式，适配 Python 版本的 MCP 服务端；
• 两次调用enter_async_context将传输通道与会话加入资源栈，实现「自动销毁」，无需手动关闭；
• 最终通过list_tools()获取服务端工具列表并存储，为后续 LLM 工具封装提供数据支撑。

4. MCP 工具转 LLM 可识别格式（协议适配核心）

python

运行

    def mcp_to_llm(self) -> list:
        """
        将MCP服务提供的工具，转换为LLM能够识别的函数调用格式
        :return: 符合LLM调用规范的工具列表
        """
        llm_tools = []
        # 遍历所有从MCP服务获取的可用工具
        for tool in self.available_tools:
            # 初始化工具参数与必填项列表
            params = {}
            required = []
            
            # 解析MCP工具的输入模式（inputSchema），提取参数属性与必填项
            if tool.inputSchema and "properties" in tool.inputSchema:
                params = tool.inputSchema["properties"]
                required = tool.inputSchema.get("required", [])
            
            # 构造符合LLM函数调用规范的工具对象
            llm_tool = {
                "type": "function",
                "function": {
                    "name": tool.name,  # 工具名称（与MCP工具一致，确保调用匹配）
                    "description": tool.description,  # 工具描述（引导LLM正确理解工具用途）
                    "parameters": {  # 工具参数规范（LLM需遵循该格式传入参数）
                        "type": "object",
                        "properties": params,
                        "required": required
                    }
                }
            }
            # 将构造完成的LLM工具加入列表
            llm_tools.append(llm_tool)
        
        # 返回转换后的LLM工具列表
        return llm_tools

代码说明：

• 该方法是「MCP 协议」与「LLM 调用」的适配桥梁，解决两者格式不兼容的问题；
• 严格解析 MCP 工具的inputSchema，提取参数与必填项，确保 LLM 调用时参数不缺失；
• 构造的格式符合主流 LLM 的函数调用规范，便于 LLM 理解并生成正确的工具调用指令；
• 兼容inputSchema为空的边缘情况，避免因工具元数据不完整导致解析失败。

5. 异步 LLM 接口调用（自然语言解析核心）

python

运行

    async def call_llm(self, messages: list, tools: list = None, system_prompt: str = "") -> dict:
        """
        构造标准消息格式并调用LLM接口，处理流式响应并返回解析结果
        关键优化：异步请求、流式响应解析、输入长度截断、容错处理
        :param messages: 对话消息列表（用户输入+历史记录）
        :param tools: LLM可用工具列表
        :param system_prompt: 系统提示词（引导LLM决策与格式输出）
        :return: 解析后的LLM响应结果（字典格式）
        """
        # 构造完整消息列表：先加系统提示词，再加对话历史
        full_messages = []
        if system_prompt:
            full_messages.append({"role": "system", "content": system_prompt})
        full_messages.extend(messages)

        # 生成唯一会话ID，用于LLM接口的会话跟踪
        session_id = str(uuid.uuid4())
        # LLM接口地址（企业级DeepSeek流式接口）
        llm_url = "https://open-api/1.0/llm/v1/deepseek/stream"
        # 构造请求头：包含身份验证与数据格式声明
        headers = {
            "Authorization": f"Bearer {self.llm_api_key}",
            "Content-Type": "application/json"
        }

        # 构造核心Prompt：严格约束LLM的输出格式，避免冗余内容
        prompt = f"""请严格按照以下要求返回，不要添加任何多余文字：
                1. 仅返回 JSON 格式的工具调用指令，无其他解释/说明
                2. 如果需要调用工具，返回：{{"tool_name":"工具名","parameters":{{"参数名":"参数值"}}}}；
                3. 如果已获取足够信息，返回：{{"content":"自然语言回答"}}；
                4. 工具名必须从以下列表中选择：{[tool['function']['name'] for tool in tools]}
                5. 参数必须匹配工具的必填项，格式正确
                用户需求：{messages[-1]['content']}
                对话历史：{json.dumps(messages[:-1], ensure_ascii=False) if len(messages) > 1 else "无"}"""

        # 关键优化1：Prompt长度截断，避免超出LLM接口输入限制（最大5000字符）
        max_prompt_length = 5000
        truncated_prompt = prompt[:max_prompt_length] if len(prompt) > max_prompt_length else prompt

        # 构造最终请求数据
        data = {
            "session_id": session_id,
            "content": truncated_prompt,  # 传入截断后的Prompt
            "messages": full_messages
        }
        
        # 关键优化2：截断messages中过长的content，进一步避免超出接口限制
        for msg in data["messages"]:
            if len(msg.get("content", "")) > max_prompt_length:
                msg["content"] = msg["content"][:max_prompt_length]

        # 打印LLM原始输入片段，便于调试
        print(f"【LLM 原始输入片段】: {data}")

        try:
            # 异步发送HTTP POST请求：使用aiohttp实现非阻塞调用，提升并发能力
            async with aiohttp.ClientSession() as aio_session:
                async with aio_session.post(
                        llm_url,
                        json=data,
                        headers=headers,
                        timeout=aiohttp.ClientTimeout(total=120)  # 关键优化3：增加超时时间（120秒），适配工业场景慢响应
                ) as resp:
                    # 检查响应状态码，非200则抛出异常
                    resp.raise_for_status()

                    final_response = None  # 保存最后一个有效的内层响应（DeepSeek流式接口最后返回完整结果）

                    # 分块解析流式响应（每次读取16384字节，平衡效率与内存占用）
                    async for chunk in resp.content.iter_chunked(16384):
                        if not chunk:
                            continue
                        # 解码分块数据，忽略无法解码的字符，避免解析失败
                        chunk_str = chunk.decode("utf-8", errors="ignore")
                        # 按行分割数据，处理流式接口的逐行返回格式
                        for line in chunk_str.splitlines():
                            line = line.strip()
                            # 过滤非标准响应行（仅处理以"data: "开头的行）
                            if not line.startswith("data: "):
                                continue
                            # 提取核心数据（去除前缀"data: "）
                            data_line = line[6:].strip()
                            if not data_line or data_line == "[DONE]":
                                continue

                            # 打印LLM原始输出片段并写入日志
                            print(f"【LLM 原始输出片段】: {data_line}")
                            log_file.write(f"【LLM 原始输出片段】: {data_line}\n")
                            
                            try:
                                # 关键优化4：双层JSON解析（外层是接口响应，内层是LLM输出）
                                # 解析外层响应：{"status":200,"data":"{...}","message":"ok"}
                                outer_json = json.loads(data_line)

                                if "data" not in outer_json:
                                    continue

                                # 解析内层响应：处理转义双引号，避免JSON解析错误
                                inner_str = outer_json["data"]
                                inner_str = inner_str.replace('\\"', '"')
                                inner_json = json.loads(inner_str)

                                # 更新最终响应（流式接口最后一条数据为完整结果）
                                final_response = inner_json

                            except json.JSONDecodeError:
                                # 关键优化5：容错处理，忽略格式错误的分片数据，继续处理下一条
                                continue

                    # 若未获取到有效响应，返回默认值
                    if final_response is None:
                        return {"content": "LLM 返回空响应"}

                    # 打印大模型最终输出，便于调试
                    print(f"大模型最终输出：{json.dumps(final_response, ensure_ascii=False)}")
                    return final_response

        except Exception as e:
            # 捕获所有异常并抛出，便于上层调用处理
            raise Exception(f"LLM 调用失败: {str(e)}")

代码说明：

• 该方法是客户端与 LLM 接口交互的核心，包含 5 大关键优化，适配工业场景的稳定性需求；
• 采用「双层 JSON 解析」处理流式响应，适配企业级 DeepSeek 接口的返回格式；
• 全程添加日志打印与写入，便于后续排查接口调用问题；
• 所有异步操作均封装在async with上下文管理器中，确保连接自动关闭。

6. 多轮智能推理与工具调用（业务逻辑核心）

python

运行

    async def process_query(self, query: str) -> str:
        """
        实现核心业务逻辑：LLM解析指令→MCP工具调用→结果解析→多轮推理，最终返回自然语言回答
        :param query: 用户输入的自然语言查询指令
        :return: 格式化的最终回答结果
        """
        # 初始化对话消息列表，存入用户当前查询
        messages = [{"role": "user", "content": query}]
        iteration = 0  # 初始化推理迭代计数器
        final_answer = None  # 初始化最终回答

        # ========== 关键：强化系统提示词，引导LLM做出正确决策 ==========
        system_prompt = """
            你是一个 OPC UA 智能助手，需要完成以下步骤满足用户需求：
            1. 首先判断是否知道用户要查询的变量对应的 OPC UA 节点ID：
            - 如果不知道，先调用 `get_all_variables` 工具获取所有变量列表，找到目标变量的节点ID；
            - 如果知道，直接调用 `read_opcua_node` 工具读取节点值；
            2. 获取节点值后，将原始数据转换为自然、易懂的人类语言回答；
            3. 仅在获取到最终数据后返回自然语言回答，否则继续调用工具；
            4. 工具调用格式必须是 JSON：{"tool_name":"工具名","parameters":{"参数名":"参数值"}}
            """

        # 多轮推理循环：未获取最终回答且未达到最大迭代次数时，持续推理
        while iteration < self.max_iterations and not final_answer:
            iteration += 1
            print(f"智能体推理迭代 {iteration}/{self.max_iterations}")

            # 步骤1：将MCP工具转换为LLM可识别格式
            llm_tools = self.mcp_to_llm()
            
            # 步骤2：调用LLM，获取决策结果（工具调用指令或自然语言回答）
            resp_json = await self.call_llm(messages, llm_tools, system_prompt)

            # 步骤3：处理LLM响应结果——工具调用分支
            if "tool_name" in resp_json:
                tool_name = resp_json["tool_name"]
                tool_params = resp_json.get("parameters", {})
                print(f"智能体调用工具：{tool_name}, 参数：{tool_params}")

                # 调用MCP服务的对应工具，执行工业设备查询/操作
                tool_result = await self.session.call_tool(
                    name=tool_name,
                    arguments=tool_params
                )
                
                # 提取工具返回结果的文本内容
                result_text = tool_result.content[0].text
                print(f"工具返回结果：{result_text}")

                # 步骤4：将工具调用与结果加入对话历史，供下一轮LLM推理参考
                messages.append({
                    "role": "assistant",
                    "content": json.dumps({
                        "tool_call": resp_json,
                        "tool_result": result_text
                    })
                })
            
            # 步骤5：处理LLM响应结果——自然语言回答分支
            elif "content" in resp_json and resp_json["content"]:
                final_answer = resp_json["content"]
            
            # 步骤6：兜底逻辑——直接识别节点ID并调用工具（提升用户体验）
            else:
                if "ns=" in query and "i=" in query:
                    # 从用户查询中提取节点ID
                    node_id = [s for s in query.split() if "ns=" in s][0]
                    # 直接调用read_opcua_node工具读取节点值
                    tool_result = await self.session.call_tool(
                        name="read_opcua_node",
                        arguments={"node_id": node_id}
                    )
                    final_answer = f"当前 {node_id} 节点的值为：{tool_result.content[0].text}"
                else:
                    final_answer = "抱歉，我无法理解你的需求，请输入如'读取 ns=2;i=3 节点值'的指令"
                break

        # 步骤7：迭代次数耗尽仍未获取回答，返回友好提示
        if not final_answer:
            final_answer = f"抱歉，经过 {self.max_iterations} 次尝试后仍无法满足你的需求。"

        return final_answer

代码说明：

• 该方法实现了「用户查询→LLM 决策→MCP 调用→结果反馈→多轮迭代」的完整业务流程；
• 系统提示词是核心，严格约束 LLM 的决策逻辑，确保其按照工业场景的需求调用工具；
• 对话历史的管理是多轮推理的关键，让 LLM 能够基于上一轮的工具结果继续决策；
• 增加兜底逻辑，直接识别用户输入中的节点 ID，提升用户体验与程序鲁棒性。

7. 命令行交互循环（用户入口）

python

运行

    async def chat_loop(self, server_script_path: str):
        """
        提供命令行交互入口，实现持续的用户查询与结果返回
        :param server_script_path: OPC UA-MCP服务端脚本路径
        """
        try:
            # 步骤1：先连接到MCP服务
            await self.connect_to_server(server_script_path)
            print("OPC UA MCP已启动")
            print("输入查询（如：读取 ns=2;i=3 节点值）| 输入 quit/exit/q 退出")

            # 步骤2：持续接收用户输入，实现循环交互
            while True:
                # 关键：使用asyncio.to_thread将同步input函数异步化，避免阻塞事件循环
                query = await asyncio.to_thread(input, "\n请输入查询: ")
                query = query.strip()
                
                # 步骤3：处理退出指令，终止循环
                if query.lower() in {"quit", "exit", "q"}:
                    break
                
                # 步骤4：忽略空输入，避免无效调用
                if not query:
                    continue
                
                # 步骤5：处理用户查询，获取最终结果并打印
                result = await self.process_query(query)
                print(f"\n【最终结果】: {result}")
        
        finally:
            # 步骤6：无论是否发生异常，均优雅清理资源
            await self.exit_stack.aclose()  # 关闭所有异步资源（MCP会话、传输通道等）
            log_file.close()  # 关闭日志文件，确保数据写入磁盘
            print("\n连接已关闭")

代码说明：

• 该方法是用户与客户端交互的入口，提供简洁清晰的命令行提示；
• 使用asyncio.to_thread解决同步input函数阻塞异步事件循环的问题，是异步编程中的常用技巧；
• finally块确保资源无论是否发生异常都会被清理，避免资源泄露与数据丢失；
• 支持多种退出指令（quit/exit/q），提升用户操作的便捷性。

8. 主函数与程序入口

python

运行

async def main():
    """
    程序主入口：处理命令行参数，初始化McpClient并启动交互循环
    """
    # 步骤1：检查命令行参数是否完整
    if len(sys.argv) < 2:
        print("用法: python llm-client.py <server_script_path>")
        sys.exit(1)
    
    # 步骤2：提取MCP服务端脚本路径参数
    server_script_path = sys.argv[1]
    
    # 步骤3：初始化McpClient实例并启动交互循环
    client = McpClient()
    await client.chat_loop(server_script_path)


if __name__ == "__main__":
    # 步骤1：Windows平台特殊配置，解决异步事件循环兼容性问题
    if sys.platform == "win32":
        asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy())
    
    # 步骤2：运行异步主函数，启动整个程序
    asyncio.run(main())

代码说明：

• main()函数处理命令行参数校验，确保程序运行参数完整；
• 针对 Windows 平台添加特殊事件循环配置，解决asyncio在 Windows 上的兼容性问题；
• asyncio.run()是 Python 3.7 + 引入的异步程序入口，自动管理事件循环的创建与关闭。

（三）集成部署与运行步骤

1. 启动基础服务

   • 启动 OPC UA 模拟服务器：进入opcua-local-server目录，执行python main.py；
   • 启动 OPC UA-MCP 桥接服务：进入opcua-mcp-server目录，执行python opcua-mcp-server.py；
   • 确认两个服务均保持运行状态，终端无报错信息。

2. 配置环境变量

   • 在项目根目录创建.env文件，添加 LLM 接口配置：

     plaintext

     LLM_API_KEY=sk-xxxxx
     LLM_API_URL=https://open-api/1.0/llm/v1/deepseek/stream
     

   • 修改代码中llm_api_key和llm_url为.env读取方式（可选，提升配置灵活性）。

3. 安装客户端依赖

   bash

   运行

   # 使用uv安装
   uv install aiohttp python-dotenv mcp
   # 或使用pip
   pip install aiohttp python-dotenv mcp
   

4. 运行 LLM-MCP 集成客户端

   bash

   运行

   python llm-client.py opcua-mcp-server/opcua-mcp-server.py
   

   • 成功启动后，终端输出OPC UA MCP已启动，等待用户输入查询指令。

（四）功能验证与测试用例

测试用例	输入指令	预期结果	实际验证
节点值读取（已知 ID）	读取 ns=2;i=101 节点值	LLM 直接调用read_opcua_node，返回该节点的温度 / 压力等数据	终端输出节点具体数值，结果正确
节点值读取（未知 ID）	读取所有温度传感器的值	LLM 先调用get_all_variables获取变量列表，再读取对应温度节点值	成功返回所有温度传感器的节点 ID 与对应数值
边缘情况测试	读取不存在的节点 ns=99;i=0	LLM 调用工具后返回错误信息，客户端生成友好提示	终端输出 “节点不存在” 相关提示，无程序崩溃
多轮交互测试	先查变量列表→再查某节点值	对话历史被正确记录，LLM 基于历史信息直接调用对应工具	第二轮查询无需重复获取变量列表，响应速度提升

四、常见问题排查与解决方案

问题类型	典型诱因	解决方案
MCP 客户端连接失败	服务端脚本路径错误、MCP 服务未启动	核对server_script_path参数；确保 OPC UA-MCP 服务已先于客户端启动
LLM 调用返回空响应	API Key 无效、接口 URL 错误、请求参数格式不合法	检查 API Key 权限；核对llm_url与企业接口地址一致；验证请求 JSON 格式
流式响应解析失败	LLM 返回数据格式不标准、存在转义字符错误	加强代码中 JSON 解析的容错处理；增加日志记录原始响应数据用于排查
工具调用参数缺失	LLM 未正确识别工具必填参数	优化系统提示词，明确要求必须传入所有必填参数；增加参数校验逻辑
程序退出时资源泄露	未正常关闭 MCP 会话或日志文件	确保使用AsyncExitStack管理资源；在finally块中执行文件关闭操作

五、总结

本次项目成功完成了OPC UA-MCP 桥接服务与 LLM 的端到端集成，核心成果如下：

1. 开发了基于异步架构的 MCP 客户端，实现了与桥接服务的高效、稳定通信，支持资源自动管理；
2. 完成了 MCP 工具与 LLM 调用格式的适配转换，通过系统提示词实现了自然语言到工具调用的智能映射；
3. 构建了多轮推理交互逻辑，支持自动决策工具调用流程，无需人工干预即可完成工业设备数据查询；
4. 验证了集成方案的可行性，打通了 “自然语言输入→LLM 指令解析→MCP 工具调用→工业数据返回” 的全链路，为后续 AI 模型深度集成工业系统奠定了基础。

六、后续优化方向

1. 增加写入操作支持：扩展客户端功能，实现通过自然语言指令修改 OPC UA 节点值；
2. 优化对话记忆机制：引入持久化存储（如 Redis），支持跨会话的对话历史管理；
3. 提升容错与监控能力：增加服务健康检查、异常自动重试机制，部署可视化监控面板；
4. 适配多模型调用：支持切换不同厂商的 LLM 接口，提升方案的通用性。