MCPModel Context Protocol由 Anthropic 于 2025 年开源到 2026 年已成为智能体生态的互操作基础——Claude、Cursor 及各类 Agent 开发框架均以 MCP Server 作为工具暴露的标准形态。对工业软件而言这意味着集成成本结构的根本变化。过去接一个 AI 客户端就要定制一次集成适配它的认证方式、它的工具描述格式、它的调用约定每多支持一个客户端集成工作量线性增长。MCP 把这个曲线压平了平台只需实现一次 MCP 端点即可对所有 MCP 客户端开放。但实现端点四个字里藏着真正的工作量——认证怎么做、权限怎么收口、一次调用经过哪些站。本文拆开这条链路。一次调用的完整链路DC3 的 MCP 面落在 HTTP 网关上POST /mcp协议是 JSON-RPC 2.0支持 initialize、ping、tools/list、tools/call 四类方法。以一次查询 3 号车间在线设备的 tools/call 为例逐站看下去。第一站客户端发现与注册。MCP 客户端先从网关的 RFC 9728 保护资源元数据端点/.well-known/oauth-protected-resource拿到授权服务器地址、支持的 Bearer 传递方式与 scope 清单——不需要任何文档标准客户端自动完成发现。随后客户端向授权端点注册/oauth2/register平台支持授权码含 PKCE、client_credentials、refresh token 三种许可类型机器智能体通常走 client_credentials从/oauth2/token换取一张 RS256 签名的访问票据。第二站请求到达 /mcp。客户端把工具名与参数装进 JSON-RPC 请求体Authorization 头携带 Bearer 票据。网关先做票据校验RS256 签名按票据头里的 key id 对照密钥验证签发方与受众声明逐一核对时间声明由解析器处理网关侧的公钥从授权中心的 JWKS 端点/oauth2/jwks以带缓存的短周期拉取——私钥从不离开授权中心。票据缺失或无效时返回 401挑战头里带着元数据端点地址把客户端引回正确的取票路径。第三站可见性与授权。校验通过后授权中心按票据解析主体上下文检查 scopetools/call 要求调用类 scopetools/list 要求列表类 scope工具可见性按连接与权限双重过滤——同一张目录不同连接看到的工具集合可以不同。高风险工具还带确认门槛风险分低、中、高三档低档只读常显中档默认隐藏需显式开启高档必须确认后才可调用。第四站工具执行。这是最容易被误解的一站MCP 工具不是新的业务通道而是既有平台能力的协议化封装。平台的工具目录由聚合器从各中心服务的 REST 接口快照合成——设备查询、点位读写、上一篇文章里的分析九端点都是既有的、带访问控制的 REST 控制器tools/call 解析出目标工具后网关把参数转发到对应后端端点执行。协议是新的权限体系与业务实现是既有的这是有意的设计。第五站审计。每次调用落一条审计记录成功与失败都记审计写入失败不会把一次已执行的成功调用伪装成客户端错误——职责边界是明确的。令牌统一一套身份三个入口智能体接口最大的风险面在认证而认证的问题出在历史上平台跑着两套互不相认的令牌体系Web 与 CLI 用的登录令牌是 HS256 共享密钥签名、固定 12 小时有效期只在/api/v3各路由上校验MCP 的 OAuth 令牌是 RS256 非对称签名、15 分钟有效期加 30 天可轮换刷新只在/mcp上校验。同一个智能体要持有两套身份两套体系各自演进随时可能漂移。统一的设计原则是不发明新令牌类型、不新建权限存储而是把每个维度归到既有的最优所有者上再把验签收敛到网关一个裁决点一个签发方OAuth 流程统一签发Web 端、CLI、智能体客户端用同一套身份体系浏览器会话保留 httpOnly Cookie 形态但共享同一个验签器与权限真源一套验签网关的令牌解析链按序尝试——HS256 登录票据与 RS256 OAuth 票据各有一个解析器先到先得未知算法立即拒绝两者产出同一种扩展主体头下游服务信任这个头部下游零改动风险分层 TTL只读操作长有效期可调用操作短有效期高危操作走确认换取——把令牌有效期从一刀切变成按能力爆炸半径分级。设计原则一句话智能体获得的每一项能力均来自真实主体的显式授权权限不因协议切换而扩大。scope 投影RBAC 权限的受控收缩MCP 对外的 scope 词表是四个工具列表、工具调用、高危工具调用、资源读取。容易走错的一步是为这四个 scope 单独建一套配置——两套并行的权限存储一个发布周期内必然漂移。DC3 的做法是投影scope 在授权时从主体既有的 RBAC 绑定计算出来有可读权限绑定才有读 scope有可调用的工具绑定才有调用 scope。投影规则是按风险档累加、只收不放——一个混合了低风险与高风险绑定的主体不会因为存在高危项而失去普通工具的访问没有绑定记录的主体降级到最小集而不是清零。网关与 MCP 授权用同一口井取水给 CLI 发令牌和给 MCP 连接授权永远一致。CLI 的双传输dc3-cli 围绕这套凭据模型重构了接入方式。dc3 auth login --oauth走动态客户端注册与授权之后同一张 OAuth 票据服务两条通道常规命令device、point、dashboard 等以 Bearer 票据访问 REST 接口dc3 tools list与dc3 tools call则以同一张票据对/mcp发 JSON-RPC——这是 CLI 的双传输设计命令面直接读机器可读的工具目录而不是为每个领域硬编码后端路径。退出码语义也随凭据体系对齐认证类错误统一映射到独立退出码方便脚本与 Agent 框架消费。通用智能体客户端接入是同一件事的另一面在 Claude Code 的配置里指向网关的/mcp地址智能体即可自动发现平台全部工具。验证路径dc3 config set gateway url→dc3 auth login --oauth→dc3 tools call ...。适用范围与限制MCP 接口处于快速迭代阶段工具清单与 scope 细粒度持续完善以 docs 与仓库 design 文档为准MCP 解决的是智能体对工业平台的标准调用不涉及模型推理质量——调用链路的确定性与回答的质量是个问题经典登录票据在/mcp不被接受MCP 端点要求 OAuth 票据——两条体系的互通在网关解析链上完成而不是在端点上放宽。结语把整条链路串起来看MCP 给了工业平台一个标准化的智能体接口而真正决定这条接口能不能用在生产环境的是它背后的三件事——统一的凭据体系、投影自既有权限的 scope、复用既有业务实现的工具执行。协议负责互操作工程负责安全与确定。前者由标准解决后者每个平台都要自己做一遍。仓库GitHub pnoker/iot-dc3 · Gitee pnoker/iot-dc3GVP文档docs.dc3.site · book.dc3.site · demo.dc3.site · CLI 手册 dc3-cli/README.md MCP 落地工业平台：从大模型对话到设备点位
MCPModel Context Protocol由 Anthropic 于 2025 年开源到 2026 年已成为智能体生态的互操作基础——Claude、Cursor 及各类 Agent 开发框架均以 MCP Server 作为工具暴露的标准形态。对工业软件而言这意味着集成成本结构的根本变化。过去接一个 AI 客户端就要定制一次集成适配它的认证方式、它的工具描述格式、它的调用约定每多支持一个客户端集成工作量线性增长。MCP 把这个曲线压平了平台只需实现一次 MCP 端点即可对所有 MCP 客户端开放。但实现端点四个字里藏着真正的工作量——认证怎么做、权限怎么收口、一次调用经过哪些站。本文拆开这条链路。一次调用的完整链路DC3 的 MCP 面落在 HTTP 网关上POST /mcp协议是 JSON-RPC 2.0支持 initialize、ping、tools/list、tools/call 四类方法。以一次查询 3 号车间在线设备的 tools/call 为例逐站看下去。第一站客户端发现与注册。MCP 客户端先从网关的 RFC 9728 保护资源元数据端点/.well-known/oauth-protected-resource拿到授权服务器地址、支持的 Bearer 传递方式与 scope 清单——不需要任何文档标准客户端自动完成发现。随后客户端向授权端点注册/oauth2/register平台支持授权码含 PKCE、client_credentials、refresh token 三种许可类型机器智能体通常走 client_credentials从/oauth2/token换取一张 RS256 签名的访问票据。第二站请求到达 /mcp。客户端把工具名与参数装进 JSON-RPC 请求体Authorization 头携带 Bearer 票据。网关先做票据校验RS256 签名按票据头里的 key id 对照密钥验证签发方与受众声明逐一核对时间声明由解析器处理网关侧的公钥从授权中心的 JWKS 端点/oauth2/jwks以带缓存的短周期拉取——私钥从不离开授权中心。票据缺失或无效时返回 401挑战头里带着元数据端点地址把客户端引回正确的取票路径。第三站可见性与授权。校验通过后授权中心按票据解析主体上下文检查 scopetools/call 要求调用类 scopetools/list 要求列表类 scope工具可见性按连接与权限双重过滤——同一张目录不同连接看到的工具集合可以不同。高风险工具还带确认门槛风险分低、中、高三档低档只读常显中档默认隐藏需显式开启高档必须确认后才可调用。第四站工具执行。这是最容易被误解的一站MCP 工具不是新的业务通道而是既有平台能力的协议化封装。平台的工具目录由聚合器从各中心服务的 REST 接口快照合成——设备查询、点位读写、上一篇文章里的分析九端点都是既有的、带访问控制的 REST 控制器tools/call 解析出目标工具后网关把参数转发到对应后端端点执行。协议是新的权限体系与业务实现是既有的这是有意的设计。第五站审计。每次调用落一条审计记录成功与失败都记审计写入失败不会把一次已执行的成功调用伪装成客户端错误——职责边界是明确的。令牌统一一套身份三个入口智能体接口最大的风险面在认证而认证的问题出在历史上平台跑着两套互不相认的令牌体系Web 与 CLI 用的登录令牌是 HS256 共享密钥签名、固定 12 小时有效期只在/api/v3各路由上校验MCP 的 OAuth 令牌是 RS256 非对称签名、15 分钟有效期加 30 天可轮换刷新只在/mcp上校验。同一个智能体要持有两套身份两套体系各自演进随时可能漂移。统一的设计原则是不发明新令牌类型、不新建权限存储而是把每个维度归到既有的最优所有者上再把验签收敛到网关一个裁决点一个签发方OAuth 流程统一签发Web 端、CLI、智能体客户端用同一套身份体系浏览器会话保留 httpOnly Cookie 形态但共享同一个验签器与权限真源一套验签网关的令牌解析链按序尝试——HS256 登录票据与 RS256 OAuth 票据各有一个解析器先到先得未知算法立即拒绝两者产出同一种扩展主体头下游服务信任这个头部下游零改动风险分层 TTL只读操作长有效期可调用操作短有效期高危操作走确认换取——把令牌有效期从一刀切变成按能力爆炸半径分级。设计原则一句话智能体获得的每一项能力均来自真实主体的显式授权权限不因协议切换而扩大。scope 投影RBAC 权限的受控收缩MCP 对外的 scope 词表是四个工具列表、工具调用、高危工具调用、资源读取。容易走错的一步是为这四个 scope 单独建一套配置——两套并行的权限存储一个发布周期内必然漂移。DC3 的做法是投影scope 在授权时从主体既有的 RBAC 绑定计算出来有可读权限绑定才有读 scope有可调用的工具绑定才有调用 scope。投影规则是按风险档累加、只收不放——一个混合了低风险与高风险绑定的主体不会因为存在高危项而失去普通工具的访问没有绑定记录的主体降级到最小集而不是清零。网关与 MCP 授权用同一口井取水给 CLI 发令牌和给 MCP 连接授权永远一致。CLI 的双传输dc3-cli 围绕这套凭据模型重构了接入方式。dc3 auth login --oauth走动态客户端注册与授权之后同一张 OAuth 票据服务两条通道常规命令device、point、dashboard 等以 Bearer 票据访问 REST 接口dc3 tools list与dc3 tools call则以同一张票据对/mcp发 JSON-RPC——这是 CLI 的双传输设计命令面直接读机器可读的工具目录而不是为每个领域硬编码后端路径。退出码语义也随凭据体系对齐认证类错误统一映射到独立退出码方便脚本与 Agent 框架消费。通用智能体客户端接入是同一件事的另一面在 Claude Code 的配置里指向网关的/mcp地址智能体即可自动发现平台全部工具。验证路径dc3 config set gateway url→dc3 auth login --oauth→dc3 tools call ...。适用范围与限制MCP 接口处于快速迭代阶段工具清单与 scope 细粒度持续完善以 docs 与仓库 design 文档为准MCP 解决的是智能体对工业平台的标准调用不涉及模型推理质量——调用链路的确定性与回答的质量是个问题经典登录票据在/mcp不被接受MCP 端点要求 OAuth 票据——两条体系的互通在网关解析链上完成而不是在端点上放宽。结语把整条链路串起来看MCP 给了工业平台一个标准化的智能体接口而真正决定这条接口能不能用在生产环境的是它背后的三件事——统一的凭据体系、投影自既有权限的 scope、复用既有业务实现的工具执行。协议负责互操作工程负责安全与确定。前者由标准解决后者每个平台都要自己做一遍。仓库GitHub pnoker/iot-dc3 · Gitee pnoker/iot-dc3GVP文档docs.dc3.site · book.dc3.site · demo.dc3.site · CLI 手册 dc3-cli/README.md