Anthropic 最近提出的这套 plumbing spec连接规范目标很直接把 AI agent 和实验室设备、机器人之间的连接方式标准化。以往要让大模型操作一台移液工作站或机械臂需要针对每台设备写私有驱动、定制中间层、处理不同厂商的通信协议这套规范想解决的就是这种“每个设备一套接法”的碎片化问题。从公开信息看这更像一个面向物理世界的“MCP 式”标准提案。MCPModel Context Protocol解决的是 AI 访问软件工具和数据源的问题而 plumbing spec 要把硬件层的能力抽成统一接口让 agent 能通过标准化的指令集控制实验设备、读取传感器数据、执行机器人动作。它不直接替代你现有的设备控制软件而是在 AI 与设备之间加一层通用的“管道”。这篇文章会做几件事拆解这个规范要解决什么问题、和 MCP 是什么关系、对实验室自动化和机器人控制意味着什么、开发者可以怎么评估和接入以及最关键的——安全边界和工程化坑在哪里。如果你在做 AI Agent 应用、实验室自动化、设备控制中间件或者正在评估让大模型操作物理设备的可行性这篇可以直接往下看。1. 核心能力与规范要点速览由于这是一个正处于提案/讨论阶段的技术规范很多细节要以 Anthropic 官方后续发布的内容为准。下面基于标题和公开材料整理出几个值得关注的要点。能力项说明提出方Anthropic项目类型连接规范 / 接口标准plumbing spec目标设备实验室设备lab kit、机器人robots核心目标让 AI agent 用统一方式发现、控制、读取物理设备与 MCP 的关系从公开信息看属于同一方向的扩展把手伸向硬件层核心价值降低设备接入成本、减少私有协议耦合、支持跨厂商组合面向人群AI 应用开发者、实验室自动化工程师、机器人开发者、设备厂商硬件门槛取决于你要接入的设备不是规范本身的门槛当前状态提案讨论阶段需关注官方正式发布是否支持 API需要等正式规范从一致性角度必然会给调用接口是否支持批量任务从自动化场景看是刚需但具体由实现方决定适合场景实验室高通量实验、机器人任务编排、设备数据采集、自动化流程调度这份表格里凡是没写实的部分都做了保守描述。这套规范的价值不在于“又多了一个 AI 功能”而在于它可能成为连接数字智能和物理设备的公共协议层。2. 要解决什么问题设备接入的碎片化现在的 AI agent 要操作实验设备或机器人通常会遇到下面几类问题。第一类协议私有化。很多实验室设备厂商有自己的通信协议、SDK 和上位机软件有的走串口有的走 TCP有的只提供 Windows 动态链接库。想让 agent 控制设备先得搞清楚底层协议再写适配层每个设备都是定制化开发。第二类能力描述不统一。一台设备能做什么、有哪些参数可调、当前处于什么状态在不同的 SDK 里是完全不同的表达方式。有的用结构化接口有的只能解析软件日志。AI 模型面对这种不一致性很难做到泛化调用。第三类技能不可迁移。今天接了一台拍照显微镜明天换一台另一厂商的代码基本要重写。skill 无法复用做一套自动化流程的成本接近从零开始。第四类物理操作责任边界模糊。软件调用失败可以重试物理设备操作失败可能造成设备损坏或安全问题。现有协议没有一个共同的“安全护栏”约定。plumbing spec 从公共信息看就是想为这些问题提供一个相对统一的底座设备通过标准化的描述文件和接口暴露能力agent 通过标准化的指令集和设备对话调用方不需要关心设备是哪个厂商、走什么协议。3. 从软件工具到物理设备的连接层与 MCP 的关系MCP 在 AI 应用开发里已经不是一个陌生词。它的核心设计是让 AI 模型通过一套统一协议访问外部数据源和工具避免每接一个软件就写一套集成代码。目前主流的大模型 API 服务以及不少本地推理框架都已经把 MCP 作为工具调用的一种标准接口。plumbing spec 可以理解成同一设计思路向物理世界的延伸。软件世界里agent 要调用的是数据库、API、文件系统、搜索引擎物理世界里agent 要调用的是移液器、离心机、培养箱、机械臂、传感器。两者的核心模式是一样的能力发现、指令下发、状态读取、事件通知。只是物理世界多了一个约束操作不可逆容错率更低实时性要求更高。所以从架构上看参考 MCP 的成熟模式plumbing spec 大概率也会包含几类抽象概念设备发现agent 怎么知道当前环境里有哪些设备。能力描述每台设备支持哪些操作指令参数是什么有什么限制。指令执行agent 下发动作指令设备执行并返回结果。状态同步设备当前状态、传感器读数、任务进度怎么反馈给 agent。事件订阅设备告警、完成通知、异常中断等事件如何推送。这套抽象不是 Anthropic 独有但由 Anthropic 这样的公司提出意义在于有可能形成行业级标准而不是某家厂商的私有协议。从开发者的角度看如果 plumbing spec 能沿用 MCP 的一些术语和传输层设计那么已经熟悉 MCP 的团队可以很快迁移过来。复用已有的鉴权、会话管理、工具描述机制不需要再学一套完全陌生的协议栈。4. 典型场景拆解实验室设备和机器人接入下面看几个典型接入场景。这些场景不是规范文档的复述而是从行业痛点倒推出来的合理用例。4.1 实验室自动化实验室设备是这套规范最直接的受益场景。一个科研实验室通常有大量仪器移液工作站、酶标仪、PCR 仪、离心机、培养箱、显微成像系统。传统自动化实验流程是用专门的脚本语言或调度软件编排AI agent 很难直接参与。引入统一 plumbing spec 后agent 可以做到几件事自动识别当前可用的设备列表。读取每台设备的能力和参数范围。根据实验方案编排操作序列。执行过程中读取设备状态和传感器数据。根据中间结果动态调整下一步操作。典型应用如高通量筛选AI 规划需要测试的化合物组合控制移液工作站制备样品送到检测仪器读取结果再根据结果生成下一轮方案。这种闭环在传统架构里需要大量定制开发统一规范后可以大幅降低集成成本。4.2 机器人任务编排机器人场景比实验室设备更复杂因为涉及运动控制、路径规划、安全避障和实时反馈。plumbing spec 不太可能直接定义电机级的控制算法更可能定义的是“任务级”接口。例如机器人的手臂“移动到位置 A”。“抓取物体 B”。“从传感器 C 读取当前读数”。“执行完动作后返回状态”。这些任务级指令由机器人厂商在底层实现上层 agent 通过统一协议调用。好处是如果机器人硬件更换只要新的机器人也实现了同一套接口上层的任务编排逻辑就可以继续复用。4.3 数据回传与自动记录物理设备操作过程中会产生大量数据这些数据过去散落在各设备的软件里。统一连接层之后设备和 agent 之间的所有指令和状态数据都经过相同的传输通道天然形成操作日志和数据记录。这对实验可复现性和审计非常有价值。5. 接入架构与配置思路这里要提前说明Anthropic 还没有公布正式的规范文档下面的架构图示和配置文件只是基于行业常规做法做出来的参考模型用来帮助理解这类协议会长什么样。不能当作官方标准直接用。5.1 参考架构从全局看一套物理设备接入规范通常包含以下几个层级。┌─────────────────────────────┐ │ AI Agent / 工作流编排层 │ │ (理解意图、编排任务、决策) │ └─────────────┬───────────────┘ │ 统一协议调用 ┌─────────────▼───────────────┐ │ 连接层 / SDK │ │ 设备发现、指令下发、状态订阅 │ └─────────────┬───────────────┘ │ 适配器 ┌─────────────▼───────────────┐ │ 设备适配器Device Adapter │ │ 把统一指令翻译成厂商私有协议 │ └─────────────┬───────────────┘ │ 串口/网口/USB/厂商SDK ┌─────────────▼───────────────┐ │ 物理设备 / 机器人 │ └─────────────────────────────┘核心是中间那一层AI agent 不直接和设备厂商协议打交道而是通过统一连接层。连接层负责把标准指令翻译成设备能听懂的语言。设备厂商只需要实现一次适配器之后任何支持该协议的 agent 都能直接调用。5.2 能力描述信息配置物理设备接入的第一步通常是“能力注册”即告诉连接层这台设备是什么、能做什么。参考常见做法能力描述文件可能长这样{ device: { id: thermocycler-001, type: thermocycler, vendor: example-vendor, model: PCR-X1 }, capabilities: [ { name: set_temperature, description: Set block temperature, parameters: { temperature: { type: number, unit: celsius, min: 4, max: 99, required: true }, hold_time: { type: number, unit: seconds, required: false } } }, { name: read_temperature, description: Read current block temperature, parameters: {} } ] }这个文件的作用是让 agent 知道这台设备能设置温度、能读温度、温度范围是多少。AI 模型可以根据这些描述自动生成调用参数。实现中建议用 JSON Schema 做参数校验避免 agent 传了超出设备范围的参数物理设备直接报错甚至损坏。5.3 指令下发接口示例设备接入后agent 端通过统一接口下发指令。参考 MCP 的设计逻辑一个指令请求可能长这样{ method: device.invoke, params: { device_id: thermocycler-001, capability: set_temperature, arguments: { temperature: 95, hold_time: 120 }, timeout_ms: 30000 } }返回结果可能包含执行状态、设备返回值以及错误信息{ result: { status: completed, output: { observed_temperature: 95.2 }, duration_ms: 1820 } }注意这只是通用形态的示例。正式规范里方法名、传输层、错误码都会不一样。真正落地时以官方规范为准。5.4 Python 调用向量如果后续提供官方 SDK调用过程大概率会做得很简洁。可以参考下面的伪代码理解交互逻辑import plumbing_sdk # 初始化连接层 client plumbing_sdk.Client( endpointhttp://127.0.0.1:8300, api_keyyour_device_access_key ) # 发现可用设备 devices client.discover_devices() for device in devices: print(device.id, device.type, device.vendor) # 调用设备能力 pcr client.get_device(thermocycler-001) result pcr.invoke( capabilityset_temperature, arguments{ temperature: 95, hold_time: 120 } ) # 读取实时状态 status pcr.get_status() print(status)接口封装成这个程度AI agent 工具调用就能非常自然地接入。大模型只需要通过工具描述知道有哪些函数可以调用然后把参数填对就行。6. 对开发者的实用价值与落地路径如果一个实验室自动化平台或者机器人中间件厂商愿意接入这套规范从工程角度看价值体现在三个方面。6.1 降低集成开销过去每接一台设备需要读厂商文档、写协议解析、做异常处理、开发测试。如果设备支持统一规范这部分工作量会大幅下降。设备厂商只需要维护一个适配器不需要分别为每个客户定制接口。6.2 让 AI Agent 具备场景泛化能力当前的大模型已经能理解自然语言指令但让它真正操作设备缺的是对设备能力的结构化描述。规范一旦成型agent 可以通过能力描述自动理解新设备不需要针对特定设备重新训练模型。这意味着 agent 可以在不同实验室之间迁移只要设备都实现了同一套连接协议。6.3 业务系统的工程集成接入一套新的连接协议不是简单改几行代码。需要一个完整的落地清单确认设备是否支持新规范或者是否有官方适配器。确认设备厂商是否愿意提供适配层。建立连接层服务管理设备注册表和权限。配置日志和审计记录所有指令操作。先做仿真测试再上真实设备。逐步开放给 AI Agent 调用监控异常率。从安全角度这里特别建议真实物理设备的操作权限不要直接暴露给公网连接层至少做内网部署并加一层会话鉴权。6.4 现有的 MCP 生态作为跳板对已经在做 MCP 的团队来说评估这套规范并不难。可以先从“把物理设备封装成一个 MCP Server”开始在 MCP 工具框架里实现指令调用和参数校验。等到官方 plumbing spec 发布后把适配器的接口层替换成标准实现上层逻辑基本不用改。# 伪代码MCP Server 包装设备操作 from mcp.server import Server server.tool() async def run_pcr_protocol(protocol: str): Run a PCR protocol on the connected thermocycler. device device_manager.get(thermocycler-001) return await device.run_protocol(protocol)这种方式的好处是可以先跑通业务流程再对齐标准不会白白等待规范发布。7. 安全、权限与合规边界这部分是物理设备接入里最容易被忽略又最不能出问题的环节。7.1 操作安全软件接口调用失败可以重试但物理设备操作失败可能造成设备损坏、实验失败甚至人身伤害。接入规范中必须有操作护栏至少包括参数范围校验防止给设备下发超范围数值。高危操作二次确认。例如“启动电机”“释放液体”“加热到高温”这类动作agent 需要显式确认权限级别。实时急停能力。一旦出现异常操作人员必须能立即终止所有任务。执行超时限制。防止 agent 下发指令后无响应导致设备卡死。7.2 数据与隐私实验室设备读取的数据有可能是敏感数据比如医药研发数据、基因测序结果、个人健康相关信息。数据在设备与 agent 之间的传输必须加密同时要有访问审计明确谁能读取哪些数据、什么时候读取的。7.3 法律与授权边界任何 AI 自主操作设备尤其是医疗、生物、工业等领域的设备都必须遵守对应行业的法律法规。如果设备操作涉及人体样本、临床检测或需要监管审批的场景AI 自动化操作需要额外的合规审批。类似的声音克隆、人脸替换规则一样物理设备自动化不是技术通了就能用而是要确认符合行业监管要求。7.4 责任划分当 AI agent 操作设备出现事故责任归属是一个还没有定论的问题。设备厂商、集成商、模型提供方、操作人员之间的责任边界需要通过合同与制度明确约定。技术可以解决能力问题但解决不了责任问题。8. 工程化挑战与观察指标即使协议正式发布落地过程也不会一路顺畅。下面这些挑战值得提前关注。挑战说明建议关注点老设备兼容大量实验室在用的是多年前的仪器不具备网络接口厂商适配器支持程度实时性不足很多 AI 推理链路延迟偏高难以满足高实时控制指令下发与状态反馈延迟生态碎片化标准能不能落地取决于有多少厂商愿意跟进首批支持厂商名单安全标准缺失物理操作缺少统一的错误码和异常处理约定示例代码和规范文档质量模型误操作大模型生成的参数可能超出设备能力范围参数校验机制是否强制云端与本地混合部署设备和 agent 可能不在同一网络内部署模式是否支持多种拓扑落地时建议重点观察这几个指标单次指令的平均延迟设备越复杂延迟越不可控。指令成功率包括正常完成、超时、失败重试的比例。异常恢复时间设备出现异常后重新回到可用状态需要多久。适配器开发成本接一台新设备需要多少时间。这些指标可以在做技术选型时量化对比不同方案。9. 现在可以做的事规范还处于提案阶段但这不意味着你现在什么都不用做。有三件事可以提前准备。9.1 梳理设备和接口清单把自己实验室或项目里已有的设备列出来整理出每台设备的控制方式、通信协议、SDK 类型、支持的操作范围。无论未来标准怎么定这份清单都是接入工作的基础。9.2 在软件层先跑通 MCP 流程如果还没接触过 MCP可以先找一个本地模型或 API 服务配置一个最简单的 MCP Server让模型能够调用外部工具。这个流程和未来接入物理设备的思路基本一致先把逻辑链路练熟之后只是把软件工具换成设备工具。9.3 关注官方文档和生态工具后续如果正式发布大概率会提供 SDK、规范文档、示例设备和社区工具。首批关注的资料包括能力描述规范、鉴权方式、设备适配器开发模板、官方支持硬件列表。尽早接入并参与反馈也有机会影响标准的调整方向。10. 值得继续关注的几个方向这个规范最值得关注的点不是它让你的机器人突然变聪明而是它可能让不同厂商、不同型号的物理设备被同一套逻辑调用。一旦这个底座跑通上层 AI Agent 可以从“只会聊天的助手”变成“能操作真实世界的施工队”。建议优先验证这三点现有设备是否支持或可以适配统一协议。官方 SDK 和文档是否足够易用。在自己的业务场景里AI 自动操作设备能否达到可接受的成功率。最容易踩的坑是忽略物理世界的“状态不可恢复性”。软件工具调用失败不影响现实但机械臂动作出错可能直接撞坏设备。所以第一批接入建议用仿真设备或低风险仪器做验证不要直接拿昂贵设备做实验。后续可以扩展的方向还包括实验室全流程自动化编排从样品制备到数据采集全链路。跨实验室设备共享与远端控制。设备操作数据回流到模型训练闭环进一步提升 agent 对物理世界的理解能力。现在比较稳妥的做法是紧跟官方规范更新优先在 MCP 生态上积累工具调用经验等到规范成熟后再把现有系统迁移过来。对于已经在做 AI 自动化和设备控制的团队来说这个方向值得长期跟踪。