Anthropic 提出的这套连接规范核心是把 AI agents 和实验室设备、机器人之间的数据与控制流统一起来。标题里用的是 “plumbing spec”直译是管道规范意思就是连接逻辑。它想解决的是 agent 如何调用真实设备的问题。适合正在做 AI 自动化实验、机器人控制、实验室信息化的人看。对我来说最有价值的是它把设备能力抽象成接口让 agent 可以在不同设备上复用同一套操作逻辑。不过也别急着当成万能方案。这类规范给的是连接框架真正能不能把一台设备跑起来至少要看设备本身是否有可编程接口、是否支持外部控制、有没有授权通道。下面按我理解的落地顺序拆一遍。1. 先弄懂 agent 接设备的真正难点1.1 agent 从“读数据”到“动设备”变化在控制回路过去我们做的很多 AI agent本质上是文本进、文本出。模型读一段文档调用一个搜索接口生成一段回复。这个阶段并不需要严格的控制回路。你说“帮我查一下天气”模型调天气 API拿到 JSON再把它翻译成一段人话。就算 API 返回慢一点、格式乱一点影响也不大。但接实验室设备和机器人就完全不一样。你让 agent 操作一台机械臂不是让它把“机械臂应该移动”这句话输出出来而是要它发出精确的坐标指令要它等机械臂运动到位要它确认传感器读数要它在夹取失败时决定重试还是放弃。这个流程里必须有一个实时反馈回路下发指令。等待设备执行。读取设备状态。判断执行结果是否达到预期。根据结果决定下一步动作。如果中间任何一步没有闭环agent 就只是一个遥控器而且是一个看不见遥控结果的遥控器。Anthropic 这次提案里最有价值的地方不是把设备控制包装成“自然语言随便说”而是尝试把设备能力变成 agent 可以查询、调用、验证的标准接口。1.2 设备接入为什么比 API 接入更复杂普通 API 有一个特点服务端大多数时候是稳定的返回结构是固定的网络超时可以重试。设备不是这样。设备有自己的物理状态。机械臂可能正在执行动作离心机可能正在高速旋转培养箱的温度可能还没升到设定值。如果 agent 不管设备当前状态直接发一条“移动到坐标”的指令轻则任务失败重则设备损坏。设备还有状态字段不一致的问题。同一台设备不同固件版本的返回字段不一样不同厂商的设备连“是否空闲”这样的概念都表达得不同。没有统一规范的话agent 每接一种设备就要写一套适配逻辑。这样不仅开发成本高而且容易出错。更麻烦的是设备操作有不可逆性。API 调用失败了可以删掉那条记录重来。机器人如果已经把一个试管打翻了它不会因为你重新调用一次就自动恢复原状。所以设备接入的第一原则不是“能不能调通”而是“调错了之后能不能安全退出”。1.3 “plumbing spec”解决的是连接而不是算法很多人看到这类规范第一反应是 Anthropic 要让 agent 更聪明。其实不是。它更像一套“连接插座”的标准。它不决定 agent 怎么规划任务不决定机器人怎么避障不决定实验方案怎么设计它只决定 agent 和设备之间怎么描述能力、怎么传输请求、怎么返回结果、怎么处理错误。这个定位非常重要。如果一套规范把算法也定义了那它就很难落地因为设备厂商、实验室系统、机器人中间件都有自己的玩法。但如果只定义连接层大家就都能接受。所以看这套规范时别期待它能让一个普通 agent 直接操纵任何机器人。它解决的是“接得上”“调得动”“看得懂结果”这几个基础问题。真正要让 agent 稳定地完成实验室任务还需要做任务编排、状态管理、异常恢复这些是规范之外的工作。2. 跑通这类连接先要理解几个核心概念2.1 设备能力描述不能只给 agent 一个黑盒要让 agent 调用设备第一步不是写代码而是让 agent 知道这个设备能做什么、不能做什么、调用时需要注意什么。我把这个叫“设备能力描述”。它至少应该包含下面几类信息设备 ID用来区分同型号多台设备。设备类型机械臂、移液工作站、温控模块、视觉传感器等。支持的操作比如移动、抓取、读取温度、停止。操作参数比如移动需要目标坐标温控需要目标温度和持续时间。设备状态空闲、忙碌、报警、离线。限制条件比如最大移动速度允许的温度范围夹爪最大开合宽度。这类描述写得好不好直接决定 agent 调用设备的成功率。如果只给 agent 一个“start”接口agent 根本不知道传什么参数。如果描述里写清楚“start 接口接受 x、y、z 三个浮点数坐标单位是毫米范围是 0 到 800”agent 才能生成有效指令。在规范的语境里这种描述通常会以结构化 JSON 或类似方式暴露给 agent。实际落地时我建议把设备能力描述当作接口文档来维护而不是随手写在配置文件里。2.2 请求响应、长连接、任务队列怎么选不是所有设备调用都适合“请求-响应”模式。你要先判断任务类型。请求-响应适合短任务。比如读取当前温度、查询设备状态。agent 发一个请求设备立即返回结果。这个模式最简单超时时间可以设置短一点。长连接流式推送适合持续输出数据的设备。比如摄像头、光谱仪、实时传感器。agent 需要订阅数据流而不是每隔几秒轮询一次。任务队列适合耗时操作。比如让机械臂完成一组搬运动作或者让 PCR 仪运行一个完整程序。这类任务一旦下发可能需要几分钟甚至几小时。agent 不应该同步等待而应该把任务提交进去然后定期查询状态或者等设备端通过回调通知完成。判断依据很简单如果一条指令执行时间超过 5 秒就不要用同步请求。如果任务会改变设备物理状态就必须支持取消和恢复。如果多个 agent 会操作同一台设备就必须加互斥锁否则会出现两个任务同时控制一个机械臂的情况。2.3 心跳、超时和状态同步设备连接稳定比普通 API 连接稳定更重要。因为设备端的异常不会自动恢复。我建议至少做三件事心跳agent 或连接网关定期向设备发送心跳确认设备还在线。连续几次心跳失败就要标记设备离线停止下发新任务。超时分级连接超时、指令等待超时、任务完成超时要分开设置。连接超时可以短一点比如 5 秒。任务完成超时要根据设备实际执行时间设置不能拍脑袋。状态同步设备执行任务时agent 需要缓存当前任务 ID 和设备状态。如果 agent 重启了要通过状态查询接口把未完成任务找回来而不是当成新任务重新下发。这里最容易踩的坑是任务已经下发agent 因为超时报错但设备其实还在执行。如果 agent 立刻重试就会导致同一台设备同时执行两个任务。稳妥的做法是先查询设备状态再决定是否重发。3. 即使不用官方规范也可以照着设计一套最小连接方案3.1 环境准备和前置条件你不需要等 Anthropic 的规范正式落地才做实验。只要你的设备支持编程控制就可以先按通用思路搭一套最小连接方案。前置条件通常包括这几项设备本身有可编程接口。比如 TCP 服务、串口、Modbus、HTTP API、ROS 消息接口。如果设备只能通过自带软件操作没有对外接口那这套方案不适用。能找到设备协议文档。至少要知道怎么连接、怎么鉴权、怎么收发指令。有一台可以和设备通信的电脑或边缘盒子。注意端口、网段、串口权限。有一个隔离的测试环境。我建议先用模拟器或设备厂商提供的仿真环境验证逻辑再真机操作。3.2 最小连接流程从模拟设备开始第一次做这套连接的时候不要一上来就接真机械臂。先用一个模拟设备跑通链路。最小流程是这样的启动模拟设备服务监听一个本地端口。在 agent 配置里注册这个模拟设备填好地址、端口、协议类型。agent 查询设备能力列表确认能读到设备名称和可用操作。agent 下发一条最简单的指令比如“读取当前状态”。校验返回结果是否为预期 JSON。走通这五步再逐步增加控制类指令。为什么要先跑模拟设备因为真机出问题时你无法确定是设备本身的问题还是你的连接逻辑有问题。模拟设备可以把变量降到最少。3.3 控制指令与结果回传的示例配置下面是一份通用示例配置用来描述一个实验室机器人。它不是 Anthropic 官方格式只是说明这类规范大概长什么样。{ device_id: lab-robot-01, device_type: robot_arm, transport: { protocol: mqtt, endpoint: localhost:1883, timeout_ms: 5000 }, capabilities: [ { name: move_to, params: { x: float, y: float, z: float }, returns: { position_reached: bool, error_code: int } }, { name: read_temperature, params: {}, returns: { temperature: float, unit: string } } ], constraints: { x_range: [0, 800], y_range: [0, 600], z_range: [0, 400], movement_speed_limit: 200 } }这份配置里要注意几点protocol 不要轻易选错。如果设备只支持串口配置里就不应该填 MQTT。capabilities 要描述清楚参数类型和返回字段。agent 调用前会根据这个结构生成指令。constraints 是安全边界。agent 生成坐标时会参考这个范围避免下发越界指令。3.4 验证成功和失败的标准很多人以为“连接不报错”就是成功。不够。设备连接至少要验证四层能建立连接。能读取设备能力描述。能下发指令并收到响应。设备真实执行了动作且结果与预期一致。第 4 层最容易被忽略。你用一条指令让机械臂移动到某个坐标设备返回了 “position_reached: true”看起来成功了。但你要检查机械臂是不是真的到了那里位置误差在多少毫米以内有没有碰撞报警。这些信息往往不在主返回字段里而在设备日志里。失败判断也一样。设备返回 error_code 只是最低标准。你还要关注任务执行中的设备震动、温度异常、夹爪压力异常这些不会直接变成 API 错误但会影响实验结果。注意做设备接入测试时旁边最好有一个人盯着设备实际状态。不要只盯着终端日志。真机运行时物理状态比日志优先级高。4. 设备接入时的参数设置与判断标准4.1 输入输出格式怎么定设备接入这类场景输入输出格式定得好不好决定 agent 能走多远。我建议遵循几个原则第一数字参数统一带单位。比如坐标一律用毫米温度一律用摄氏度时间一律用秒。避免 agent 猜单位。第二布尔字段不要滥用。设备状态里的 “ready” 字段如果文档没说清楚是指“硬件就绪”还是“任务队列有空位”agent 就会误判。第三错误码要带描述。agent 拿到一个 error_code1007如果不知道这个数字代表什么它只能把原始错误原文交给用户。协议文档里要把错误码和错误描述、恢复建议一起维护。下面是一个建议的输入输出格式表场景输入输出判断标准查询设备状态设备 ID状态、当前任务 ID、错误码状态值为 idle/busy/error/offline下发移动指令目标坐标、速度执行结果、误差实际位置与目标差在允许范围内读取传感器传感器名称数值、单位、时间戳数值在合理量程内取消任务任务 ID取消确认、当前设备状态设备回到空闲状态4.2 超时、并发和重试怎么给设备调用的超时、并发、重试不能参考普通 API 的默认值。你要按任务级别设置。状态查询类超时 3 到 5 秒。重试 2 次。因为这类操作不影响设备物理状态。控制指令类超时根据设备执行时间估。比如机械臂移动到目标点需要 10 秒超时就设 20 秒。不要设 3 秒。长任务类不设同步超时。提交任务后进入“已接收”状态然后定时查询。单次查询超时 5 秒整个任务可以等 30 分钟。并发数要保守。一台机械臂同时只能执行一个移动指令这个没有争议。但一台温控设备可能允许同时读温度和设定温度因为读操作不改变状态。所以并发控制要按操作类型拆不能粗粒度限流。重试策略也要分类。读取温度失败可以立刻重试。移动指令失败不能无条件重试。如果移动失败是因为设备报警重试只会重复触发报警。应该先查询设备状态再决定是重试、暂停还是人工介入。4.3 资源占用与任务吞吐怎么评估不要只看“能不能跑通”还要看设备接入后的稳定性。评估一套设备连接方案我通常关注这几个指标指令响应时间从 agent 发出指令到收到最终响应耗时多久。如果超过预设超时要调参数。设备空闲比例设备在实验周期里有多长时间处于 idle。如果空闲过多可能是任务编排不合理如果频繁 busy可能是并发限制没生效。任务失败率连续 100 条控制指令里失败多少条。失败率超过 1% 就要查原因。日志完整性每次设备操作有没有任务 ID、入参、出参、执行时间、错误码。没有完整日志任何问题都只能靠猜。这里有一个很容易踩的坑只看 CPU 和内存。设备控制任务真正要盯的是设备状态一致性不是服务器资源。服务器 CPU 只用 5%但设备可能已经卡在某个中途状态直到超时才报错。5. 批量任务、多设备协作和常见问题排查5.1 批量操作与设备抢占单设备跑通之后下一步通常是批量任务。批量不是简单地把一个指令复制多次。批量任务要注意设备任务队列和资源竞争。假设你有一个 96 孔板需要让机械臂按顺序往每个孔里加液。这个任务的特点是设备动作有顺序依赖不能并行。这时候就要把整批操作建模成一个任务而不是让 agent 发 96 条独立指令。另外一种批量是不同设备之间的流水线机械臂从 A 设备取样本放到 B 设备检测C 设备记录结果。这种场景下agent 不能只和单台设备通信还要维护一个跨设备状态表。多条指令同时下发时一定要先抢锁。设备端如果没有锁机制你就要在连接网关里加一层互斥控制。我见过很多问题都是两个 agent 实例同时给同一台设备发指令导致的。设备没有坏但实验步骤乱套了。5.2 多设备协同时的权限和命名多设备接入时命名和权限比单设备重要得多。命名要遵守一套统一规则。比如设备 ID 包含楼号、实验室编号、设备类型、设备序号B2-Lab03-RobotArm-01。不要用“机械臂1”“robot1”这种命名。agent 在同一个任务里可能同时操作十几台设备命名不清晰会导致调用错对象。权限也要分级。普通开发环境里agent 可能只需要读取设备状态。到了生产实验环境你要给不同 agent 设置不同的设备操作权限。有的 agent 只能读温度不能启停设备有的 agent 只能操作特定区域的机器人。这些权限最好也通过统一配置管理而不是写在每台 agent 的代码里。5.3 常见报错的排查顺序设备接入报错时我的排查顺序是固定的先看设备是否在线。很多时候报错不是协议问题是设备离线了。看设备日志确定设备有没有收到这条指令。如果设备根本没收到问题在网络层。看设备返回的错误码。错误码表示设备收到指令但拒绝执行优先级比日志高。看参数范围。设备报参数错误先检查 agent 生成的坐标或温度是否越界。看任务是否冲突。同一台设备是否已经在执行另一个任务。看权限。agent 是否有执行这个操作的权限。如果你用的是外部 AI 服务来驱动 agent还要单独检查 API 地址、密钥、网络连通性。这类报错的提示信息不一定准确可能是密钥过期也可能只是域名解析失败。我的建议是先把网络连通性和认证信息排除掉再往下查设备协议。遇到设备任务卡住不要急着重启。先查询设备当前状态和任务进度确认是不是任务已经实际完成但状态回传丢失。6. 实际落地时的边界与建议6.1 哪些场景适合接入哪些先不要硬上这类连接规范最适合的场景是有明确接口、重复度高、需要自动化的实验室和机器人任务。比如移液、称量、扫码、温控记录、样品转运。这些任务操作标准明确设备本身有接口agent 接入后能明显减少人工干预。不适合硬上的场景也很明显设备没有稳定接口只有厂商成套软件。操作过程依赖大量人工判断没法用固定参数描述。设备当前状态无法可靠读取agent 无从知道操作是否成功。安全等级太高比如涉及危险化学品操作建议维持人工或半自动模式。不要因为“AI 很火”就把所有设备都接给 agent。连接规范解决的是可编程设备的接入问题解决不了物理世界的不确定性。设备本身不支持、状态不可知、操作不可逆这三条占任何一条都要谨慎。6.2 从小规模验证到生产化扩展比较稳妥的路径是四步第一步单设备跑通。只接一台模拟设备确认连接、调用、返回、日志都正常。第二步接一台真机做最小安全测试。真机第一次运行时速度调低范围缩小旁边有人守看。第三步单任务闭环。让 agent 独立完成一个完整实验步骤比如“从 A 管取 5 微升液体加到 B 孔”。这个阶段不看吞吐只看正确率和稳定性。第四步多设备、多任务队列。在单任务稳定之后再把批量、并发、权限、日志监控补上。我见过很多团队在第二步和第三步之间翻车。原因是第二步只验证了“设备能被远程控制”但没有验证“agent 能在出错时安全处理”。远程控制不等于自动化实验。自动化实验要求的是结果可预期、错误可恢复、过程可追溯。6.3 关注规范后续变化但先做基础建设Anthropic 这次提案目前更多是方向性的东西。具体协议怎么演进、厂商会不会跟进、最终定义成什么格式都还有变数。所以在落地时我不建议把代码深度绑定到某一个特定规范上。更好的做法是先把基础能力做扎实设备能力描述模型。统一的指令网关。任务状态管理。日志和错误码规范。模拟设备测试环境。这些东西不管最终规范怎么变都用得上。等真正的标准成型时你的设备接口只需要做一层适配而不是重新开发。从更长远的角度看agent 接物理设备这个方向一定会慢慢标准化。不是说所有设备都必须听 agent 的而是说当 agent 需要操作设备时它应该有一个干净、可验证、可回溯的通道。这个通道就是这轮提案真正想解决的东西。对普通开发者来说不用等最终标准出来才动手先把你的设备能力描述清楚把控制链路打通把排查流程固定下来后面接什么规范都是顺水推舟的事。