1. 传统应用接入 AI 的真实困境为什么你的系统还在“只读不思考”很多做工业物联网、MES、SCADA 的朋友都遇到过同一个尴尬系统里跑着成百上千个测点数据采集、报警、存储都做得挺完整但一到“让 AI 帮我分析一下”就卡住了。大模型的知识来自预训练语料它根本不知道你车间里那台 Modbus 设备此刻温度是多少也不知道 485 总线上挂的几个子设备是不是在线。你问它“网关里配置了几个子设备”它只能给你编一个听起来很像的答案。这个问题的本质是大模型和你的业务系统之间缺一条标准化的通道。早期大家用 Function Calling 硬编码每个工具写一个函数描述模型返回 JSON 你去解析执行。能用但每接一个新系统就要重写一遍胶水代码工具一多维护成本直接爆炸。MCPModel Context Protocol就是在这个背景下被提出来的它把“模型调用外部工具”这件事从各家自定义变成了一套统一规范MCP Client 负责和模型对话MCP Server 负责暴露工具两边通过标准协议通信。这篇内容聚焦的是传统应用通过 MCP 协议接入 AI 能力的落地路径。我会用 IoTGateway 这个基于 .NET 8 的开源工业物联网网关做载体演示怎么在既有系统里加一个 MCP Server把设备清单、连接状态、变量当前值这些能力暴露给大模型再通过 TaoToken 统一 Key 和 API 通道完成工具调用与流式响应。适合谁看手里有存量业务系统、想快速验证 AI 增强效果、又不想大动干戈重构的开发者。读完你能拿到可复制的 MCP 服务端配置、Function Calling 定义示例以及 SSE 联调验证的完整步骤。先说清楚 MCP 和 Function Calling 的关系不然后面配置容易懵。Function Calling 像一家专门店你只需要某个特定产品时直接走进去一对一快速解决适合单一任务。MCP 像一个大型购物中心所有店铺遵循统一设计风格和支付系统你从同一个入口、用同一种支付方式就能在不同店铺之间顺畅切换。MCP 主要做了两件事统一命名把大模型运行环境叫 MCP Client、把 Function 叫 MCP Server统一开发规范把模型与 Function 之间的交互收敛成一个范式。理解这两点后面的代码就顺了。MCP 有两种传输模式选错了调试会很痛苦。stdio 是标准输入输出MCP Server 作为子进程通过标准流和主程序通信实现简单、延迟低适合本地开发和问题排查但不适合分布式或需要长连接实时更新的场景。SSE 基于 HTTP是单向实时数据推送机制服务器可以持续向客户端发送更新适合云端或分布式系统中需要实时数据流的应用。工业网关这种要长期在线、多客户端访问的场景SSE 是更合理的选择本文的配置也以 SSE 为主。2. TaoToken 前置准备统一 Key 与 API 通道让 MCP 调用不再到处找凭证在动手写 MCP Server 之前先把模型侧的通道打通。传统做法是每个应用各自申请 Key、各自配 Base URL工具一多凭证管理就乱。TaoToken 在这里的角色是统一入口你拿到一个 Key配一个 Base URL就能在 MCP Client、Cline、Codex 这些不同工具里复用同一套凭证模型 ID 按需切换。对做传统应用改造的人来说这能省掉大量“这个工具该填哪个地址”的试错时间。第一步是拿 Key。访问 https://taotoken.net/api-keys 登录后在控制台创建 API Key。建议按用途分 Key比如一个给 MCP 联调、一个给生产环境方便后续排查和轮换。创建后立刻复制保存页面刷新后完整 Key 不会再显示。这一步别偷懒我见过太多人 Key 丢了又重建结果旧配置全部失效。第二步是确认 Base URL。TaoToken 的 API 地址是 https://taotoken.net/api 注意这里不加任何查询参数直接作为 OpenAI 兼容接口的 base_url 使用。很多工具的配置项叫base_url或api_base填的就是这个。如果你用的是 Claude Code 这类走 Anthropic 协议的工具接入文档在 https://taotoken.net/doc 里面有对应的地址说明别把 OpenAI 兼容地址填到 Anthropic 协议的位置会直接 404。第三步是选模型 ID。MCP 场景下模型需要支持 Function Calling也就是能理解工具定义并返回结构化的调用意图。选模型时优先挑标注了工具调用能力的模型 ID 要填完整比如deepseek-chat这类。你可以在 https://taotoken.net/models 查看可用模型列表或者在模型对话页 https://taotoken.net/chat 先手动试一句“帮我列出所有设备”看模型会不会主动要求调用工具确认能力没问题再写进配置。这里有个容易踩的坑MCP Client 和模型 API 是两条独立的链路。MCP Client 负责连你的 MCP Server比如http://localhost:518/sse模型 API 负责连 TaoToken。两者配置项在不同位置别把 MCP Server 的 URL 填到模型的 base_url 里也别把 TaoToken 的 Key 填到 MCP Server 配置里。分清楚这两层后面排错会快很多。如果你打算长期跑编码类或 Agent 类任务可以了解下 Coding Plan https://taotoken.net/coding-plan 它在高频调用场景下更划算。但本文的联调阶段用按量 Key 就够了先把链路跑通再考虑套餐。准备好 Key、Base URL、模型 ID 这三样就可以进入 MCP Server 的编写环节了。3. 可复制配置IoTGateway 中编写 MCP Server 并暴露设备工具这一节是全文技术含量最高的部分我会把每一步的配置和代码都给全你照着改就能跑。环境准备Visual Studio 2022、Node v18.20.4、npx v10.7.0、VSCode v1.99.0。IoTGateway 源码在 https://github.com/iioter/iotgateway 克隆下来用 VS 打开。先加两个 MCP 官方 NuGet 包版本要对齐不然 API 可能不兼容PackageReference IncludeModelContextProtocol Version0.1.0-preview.6 / PackageReference IncludeModelContextProtocol.AspNetCore Version0.1.0-preview.6 /然后在服务注册处加上 MCP Server 和工具类型。WithToolsDeviceTool()这行的意思是把DeviceTool类里所有标注了McpServerTool的方法注册成可被模型调用的工具services.AddMcpServer().WithToolsDeviceTool();接着在管道配置里映射 MCP 端点。MapMcp()会暴露 SSE 端点默认路径就是/sse这也是后面 Cline 配置里要填的地址app.UseEndpoints(endpoints { endpoints.MapMcp(); });核心是DeviceTool.cs它定义了四个工具设备清单、设备连接状态、设备全部变量、单个变量值。注意每个方法的Description特性这段文字会作为工具描述发给模型写清楚模型才知道什么时候该调它using ModelContextProtocol.Server; using Plugin; using System.ComponentModel; using System.Linq; using System.Collections.Generic; using JetBrains.Annotations; namespace IoTGateway.MCP { [McpServerToolType] public sealed class DeviceTool { private readonly DeviceService _deviceService; public DeviceTool(DeviceService deviceService) { _deviceService deviceService; } [McpServerTool(Name DevicesList), Description(Get the list of sub-devices.)] public IEnumerablestring DevicesList() { return _deviceService.DeviceThreads.Select(x x.Device.DeviceName); } [McpServerTool, Description(Get the current connection status of the sub-device.)] public bool? GetDeviceStatus( [Description(name of device)] string deviceName) { return _deviceService.DeviceThreads .FirstOrDefault(x x.Device.DeviceName deviceName) ?.Driver.IsConnected; } [McpServerTool, Description(Get sub-device variables.)] [CanBeNull] public Dictionarystring, object GetDeviceVariables( [Description(name of device)] string deviceName) { return _deviceService.DeviceThreads .FirstOrDefault(x x.Device.DeviceName deviceName) ?.Device.DeviceVariables .ToDictionary(x x.Name, x x.CookedValue); } [McpServerTool, Description(Get the current value of a variable of a sub-device.)] public object GetDeviceVariable( [Description(name of device)] string deviceName, [Description(name of variable)] string variableName) { return _deviceService.DeviceThreads .FirstOrDefault(x x.Device.DeviceName deviceName) ?.Device.DeviceVariables .FirstOrDefault(x x.Name variableName) ?.CookedValue; } } }这段代码里DeviceService是 IoTGateway 已有的服务通过构造函数注入进来所以你的 MCP Server 天然就能访问网关里所有设备数据不需要额外写数据获取逻辑。这就是在传统应用里加 MCP 的好处业务能力是现成的你只是给它套了一层标准协议的外壳。跑起来之前先在 IoTGateway 里配置数据采集。启动项目后访问http://localhost:518/Login/Login登录按界面提示添加设备和变量。我测试时配了两个子设备一个 485 总线、一个 Modbus变量里有个temperature。配置完确认设备状态是已连接不然后面工具返回空值会以为是代码问题。4. 验证请求与成功结果Inspector 调试 Cline 接入 SSE 联调代码写完先别急着接大模型用官方 Inspector 单独验证 MCP Server 是否正常。在 PowerShell 里执行npx modelcontextprotocol/inspector它会启动一个本地调试界面浏览器访问http://127.0.0.1:6274/#resources。在界面里选择 SSE 传输方式URL 填http://localhost:518/sse点连接。连上后能看到 Tools 列表应该正好是四个DevicesList、GetDeviceStatus、GetDeviceVariables、GetDeviceVariable。逐个点开调试比如调DevicesList应该返回你配置的子设备名称数组。这一步能过说明 MCP Server 本身没问题问题就只可能在模型侧配置。接下来在 VSCode 里装 Cline 扩展把 MCP Server 接进去。Cline 的 API Provider 配置里Base URL 填https://taotoken.net/apiAPI Key 填你在 TaoToken 创建的 KeyModel 填你选的模型 ID。这三件套缺一不可Base URL 和 Key 是模型通道Model ID 决定用哪个模型做工具调用决策。然后在cline_mcp_settings.json里添加 IoTGateway MCP Server。注意url是 MCP Server 的 SSE 地址transportType必须是sseautoApprove里列出你信任的只读工具这样模型调用时不用每次手动确认{ mcpServers: { iotgateway: { disabled: false, timeout: 30, url: http://localhost:518/sse, transportType: sse, autoApprove: [ GetDeviceVariable, GetDeviceStatus, GetDeviceVariables, DevicesList ] } } }保存后 Cline 面板里应该能看到 iotgateway 这个 MCP Server展开能看到四个 Tool。如果看不到先检查 IoTGateway 是否在运行、518 端口是否被占用、SSE 地址是否写错。现在做两个真实任务验证。Task1 问“Modbus 子设备中temperature 变量当前值是多少”模型会先调用GetDeviceVariable参数deviceNameModbus、variableNametemperature拿到返回值后组织成自然语言。我实测返回的是The current value of the temperature variable in the Modbus sub-device is 29.32.这个 29.32 就是网关实时采集的值不是模型编的。Task2 问“网关中配置了几个子设备他们的连接状态怎么样”模型会先调DevicesList拿到设备名再对每个设备调GetDeviceStatus。返回结果是“网关中配置了 2 个子设备485 总线 - 已连接Modbus - 已连接”。这两个任务跑通说明从自然语言提问到工具调用再到结果组织整条链路是通的。SSE 联调时留意响应是流式的工具调用和最终回答会分阶段推送。如果你在浏览器 Network 面板看/sse请求能看到event: message这类分块数据。这也是 SSE 相比 stdio 的优势长连接保持多轮工具调用不用反复建连。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 逐个击破联调阶段最容易卡在几个固定报错上我把踩过的坑列出来你对照着查。401 Unauthorized这个基本是 Key 问题。先确认 TaoToken 的 Key 有没有填对注意别把 Key 填到 MCP Server 配置里它属于模型 API 配置。如果 Key 确认无误还是 401检查 Base URL 是不是https://taotoken.net/api多一个斜杠或少一个路径都可能被拒。还有一种情况是 Key 被删了或过期去控制台重新建一个。local proxy failed这个报错通常出现在 MCP Client 连不上 MCP Server 时。先确认 IoTGateway 进程在跑http://localhost:518/sse在浏览器能访问到会返回 SSE 流或连接保持。如果端口被占用换个端口重新映射。Cline 配置里的url要和实际监听地址完全一致localhost和127.0.0.1在某些环境不等价建议统一用127.0.0.1。reading choices 相关报错这类错误多半是模型返回格式和客户端预期不一致。检查你选的模型是否支持 Function Calling不支持工具调用的模型会返回纯文本客户端解析choices里的工具调用字段时就报错。换一个明确支持工具调用的模型 ID 再试。另外确认请求体里tools字段格式正确MCP Client 一般会自动转换但如果你手写请求要留意。OAuth 相关报错如果你在配置里误开了 OAuth 流程或者工具端要求鉴权而你没配会看到 OAuth 相关提示。MCP 的 SSE 端点默认不需要 OAuth检查cline_mcp_settings.json里有没有多余的鉴权字段。TaoToken 侧用的是 API Key 鉴权不是 OAuth别把两套机制混在一起。工具列表为空Cline 里能看到 MCP Server 但 Tool 列表是空的通常是WithToolsDeviceTool()没生效或者DeviceTool类缺少[McpServerToolType]特性。重新编译确认没有报错再检查MapMcp()是否在正确的管道位置调用。变量返回 null工具能调通但返回 null多半是设备名或变量名对不上。先用DevicesList和GetDeviceVariables确认实际名称注意大小写和空格。IoTGateway 里配置的设备名是什么调用时就传什么别自己猜。排查顺序建议先 Inspector 验证 MCP Server 本身再验证模型 API 通道最后验证两者在 Cline 里的组合。分层排查比一上来就怀疑整条链路快得多。6. 从联调到落地把 MCP 能力接进你的存量系统链路跑通之后真正有价值的是把这套模式复制到你的实际业务里。IoTGateway 只是个载体核心思路是你已有的业务服务通过构造函数注入到 MCP Server 的工具类里每个工具方法对应一个业务能力加[McpServerTool]和Description就完成了暴露。设备查询、订单状态、库存数量、工单进度只要是只读或可控写的业务方法都能这样接进来。模型通道侧用 TaoToken 统一 Key 和 Base URLMCP Client 侧用 SSE 保持长连接模型 ID 按任务类型切换。这套组合的好处是业务代码零侵入你不需要为了接 AI 去重构现有系统只是在外围加了一层协议适配。对于工业物联网这类设备种类多、数据格式杂的场景MCP 的标准化特性让系统兼容性和扩展性都更好未来接新设备或新服务时不用重写集成逻辑。如果你要长期跑 Agent 类任务可以看下 Coding Plan https://taotoken.net/coding-plan 高频调用下成本更可控。接入过程中遇到协议细节问题文档在 https://taotoken.net/doc 模型列表和对话测试分别在 https://taotoken.net/models 和 https://taotoken.net/chat 。先把本文的四个工具跑通再按你的业务方法逐个替换这是最稳的落地路径。