企业官网建设流程全解析

1. 传统应用接入 AI 的真实困境：为什么你的系统还在“只读不思考”

很多做工业物联网、MES、SCADA 的朋友都遇到过同一个尴尬：系统里跑着成百上千个测点，数据采集、报警、存储都做得挺完整，但一到“让 AI 帮我分析一下”就卡住了。大模型的知识来自预训练语料，它根本不知道你车间里那台 Modbus 设备此刻温度是多少，也不知道 485 总线上挂的几个子设备是不是在线。你问它“网关里配置了几个子设备”，它只能给你编一个听起来很像的答案。

这个问题的本质，是大模型和你的业务系统之间缺一条标准化的通道。早期大家用 Function Calling 硬编码，每个工具写一个函数描述，模型返回 JSON 你去解析执行。能用，但每接一个新系统就要重写一遍胶水代码，工具一多维护成本直接爆炸。MCP（Model 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 Include="ModelContextProtocol" Version="0.1.0-preview.6" /> <PackageReference Include="ModelContextProtocol.AspNetCore" Version="0.1.0-preview.6" />

然后在服务注册处加上 MCP Server 和工具类型。WithTools<DeviceTool>()这行的意思是把DeviceTool类里所有标注了McpServerTool的方法注册成可被模型调用的工具：

services.AddMcpServer().WithTools<DeviceTool>();

接着在管道配置里映射 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 IEnumerable<string> 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 Dictionary<string, 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/api，API Key 填你在 TaoToken 创建的 Key，Model 填你选的模型 ID。这三件套缺一不可，Base URL 和 Key 是模型通道，Model ID 决定用哪个模型做工具调用决策。

然后在cline_mcp_settings.json里添加 IoTGateway MCP Server。注意url是 MCP Server 的 SSE 地址，transportType必须是sse，autoApprove里列出你信任的只读工具，这样模型调用时不用每次手动确认：

{ "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，参数deviceName=Modbus、variableName=temperature，拿到返回值后组织成自然语言。我实测返回的是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 列表是空的，通常是WithTools<DeviceTool>()没生效，或者DeviceTool类缺少[McpServerToolType]特性。重新编译确认没有报错，再检查MapMcp()是否在正确的管道位置调用。

变量返回 null：工具能调通但返回 null，多半是设备名或变量名对不上。先用DevicesList和GetDeviceVariables确认实际名称，注意大小写和空格。IoTGateway 里配置的设备名是什么，调用时就传什么，别自己猜。

排查顺序建议：先 Inspector 验证 MCP Server 本身，再验证模型 API 通道，最后验证两者在 Cline 里的组合。分层排查比一上来就怀疑整条链路快得多。

6. 从联调到落地：把 MCP 能力接进你的存量系统

链路跑通之后，真正有价值的是把这套模式复制到你的实际业务里。IoTGateway 只是个载体，核心思路是：你已有的业务服务通过构造函数注入到 MCP Server 的工具类里，每个工具方法对应一个业务能力，加[McpServerTool]和Description就完成了暴露。设备查询、订单状态、库存数量、工单进度，只要是只读或可控写的业务方法，都能这样接进来。

模型通道侧用 TaoToken 统一 Key 和 Base URL，MCP 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 。先把本文的四个工具跑通，再按你的业务方法逐个替换，这是最稳的落地路径。