AI硬件要可靠执行动作，应把耗时可能波动的感知与推理，和有明确截止时间的设备控制分开设计。推理侧给出任务意图，控制侧根据当前状态、指令有效期和设备约束决定能否执行，并持续反馈结果。判断架构是否合适，不能只看模型平均响应多快，还要看最慢情况下会发生什么。
这件事在机器人上尤其突出，在电机、门锁、家居网关和带运动机构的智能终端上同样适用。一次晚到的回答可以重新问，一条已经过时却仍然执行的运动命令，可能直接改变设备行为。
2026年10月21日，Comau公布了与NVIDIA推进工业机器人物理AI的合作方向，涉及边缘计算与工业控制器的结合。它提示了一个值得持续观察的方向：AI进入设备后，计算平台与控制系统需要共同规划。合作公告并不直接回答具体项目的控制时限，工程设计仍需回到任务本身。Comau原始公告
先问动作什么时候必须完成
“实时”指任务需要在规定的截止时间内完成，并非单纯运行得快。ROS 2官方实时系统背景文档将低延迟与实时性明确区分：平均延迟低，不代表每次都能在期限内返回。这个区别决定了模型应放在哪一段执行链。ROS 2实时系统背景
以一台带摄像头的移动设备为例，识别用户想去哪个房间，可以允许重试和交互；维持运动控制，则需要按设备定义的周期处理状态。两项任务都很重要，但它们对时间、失败和恢复的要求不同。如果把它们塞进一个等待大模型返回的流程里，模型繁忙、网络重连甚至日志写入，都可能影响下一次控制更新。
需求评审时，应逐项写清动作的触发条件、允许等待时间、过期后的处置，以及哪一层有权终止。没有这些信息，“低延迟”“实时交互”很难成为可验收的指标。对话等待时间和执行器控制周期也应分别记录，避免一个漂亮的端到端平均值掩盖控制端的异常。
时限不是选完芯片之后才补上的数字。它会影响处理器分工、总线、任务调度、缓存策略和网络依赖。如果业务允许较长思考，但动作必须及时停止，就应给“开始”和“停止”设计不同的路径。停止动作不宜排在一串待完成的模型请求后面。
将执行链分成四个可以单独检查的部分
感知与推理负责理解输入、形成目标和计划。它可以使用本地模型或云端服务，但输出需要成为结构化任务，例如目标对象、动作类型、目标状态和有效条件。自然语言解释适合给人看，设备执行则需要稳定字段。
指令校验负责把计划与此刻的设备事实对齐。模型生成答案时的状态，和控制器真正收到指令时的状态，可能已经不同。因此校验不只检查参数格式，还要检查设备模式、状态版本、指令是否仍有效，以及是否与当前任务冲突。校验失败后，应明确拒绝或重新规划，不能一边报错一边部分执行。
实时控制负责在既定约束内驱动设备。它接收的是已经限定范围的目标，而不是自由文本。具体项目可采用独立控制器、隔离任务或其他经过验证的架构；是否满足时限，需要结合操作系统、调度、驱动、总线与执行机构测量，不能仅凭“使用ROS 2”下结论。
状态反馈负责说明动作真正进行到哪里。请求已收到、动作已开始、目标已达到和失败退出，是不同事件。让上层智能体把“收到请求”误当“执行完成”，会使后续计划建立在错误状态上。反馈最好能回到原任务，并带有可追踪的指令编号和终止原因。
| 执行环节 | 需要回答的问题 | 重点记录 |
|---|---|---|
| 感知与推理 | 用户要完成什么任务？ | 输入时间、目标、模型与配置版本 |
| 指令校验 | 现在还能执行这条指令吗？ | 有效期、设备状态、拒绝原因 |
| 实时控制 | 动作能否在规定条件内完成？ | 控制周期、超时、保护状态 |
| 状态反馈 | 设备实际做到了哪一步？ | 任务编号、完成状态、终止原因 |
四段分工不等于必须采购四块板。它首先是一份接口与责任划分。可以先在同一平台中划清任务边界，再根据时限、负载和故障隔离要求决定硬件分区。反过来，即使买了两块板，如果它们仍共享不可控的阻塞链路，也不能自动获得可靠执行。
最容易遗漏的是过期指令
设想用户先要求设备移动，随后改变主意。第一次推理请求因网络波动晚到，如果系统只按收到的顺序执行，旧目标仍可能覆盖新目标。解决这类问题，需要把“这条指令何时仍然有效”写进协议，而不只给消息加一个发送时间。
一个实用的指令契约可以包含任务编号、指令序号、目标状态、状态版本、有效期限和取消关系。控制侧在执行前核对有效性；任务被取消或替代后，迟到的结果不再重新激活动作。具体字段由业务确定，但过期、取消、重复到达和乱序到达都应有明确处理结果。
涉及多个设备时还要注意时钟条件。不同设备的绝对时间未必严格一致，不能把一个未经同步的时间戳直接当成可靠依据。可以结合本地单调时钟、接收侧超时和序号等机制设计有效性判断，并通过真实网络条件验证。时间字段看起来齐全，不代表时间语义已经一致。
重复请求也需要可预测行为。同一个任务编号再次到达，是返回当前状态、拒绝重复，还是重新执行，应在接口中写清。对于动作类设备，网络重试不应默默变成再次运动。将任务编号贯穿推理、校验、执行和反馈，排查时才能分清“没收到”和“收到但拒绝”。
断网时保留什么能力，要先做决定
把模型部署到本地可以减少部分网络依赖，但本地推理同样受到内存、温度、并发和存储的影响。断网策略不应简单写成“自动切本地”，还需说明本地模式支持哪些任务、接受哪些输入、何时恢复联网，以及恢复后如何处理积压请求。
对带动作的产品，可以按任务拆分：基础状态读取是否仍可用；当前动作是继续、暂停还是退出；新的复杂任务是否拒绝；用户能从哪里看到原因。不同产品的合理策略不同，关键是保证行为有定义。不能让云端失败后，控制器长时间等待一个永远不会来的结果。
恢复联网也不应把全部旧任务重新投递。应先同步当前设备状态，再决定是否重新规划。比如门已经由人工关闭，旧的“关门”计划就没有必要再次执行。恢复流程处理的是当前事实，而不是把断线期间的命令队列原样补完。
验收时要看失败路径，而不只是成功演示
测试可以从任务时限表展开。对每一种动作，同时准备正常输入、迟到结果、取消、重复请求、乱序、反馈丢失、控制侧重启等情况。每项测试都应写明预期状态，并保留统一时间基准下的事件记录。没有预期结果，日志再多也很难判断是否通过。
性能记录建议分成多个阶段：输入到达、推理开始和结束、校验完成、控制器接受、动作开始、动作结束。这样才能区分模型慢、排队慢、传输慢和机械动作本身慢。汇总平均值之外，应检查超时与异常样本；若要声明最坏情况上界，测试范围与证明条件还需足以支撑该说法。
压力条件要贴近产品：同时运行图像输入、语音服务、日志和升级任务时，控制行为是否变化；长时间运行后，温度与资源占用是否改变响应；服务重启时，状态是否一致。这些问题决定系统能否在日常环境中工作，不能仅凭桌面演示推断。
安全相关功能需要独立评估其适用标准与验证流程。普通任务校验、软件超时或一段模型提示词，都不能直接等同于安全认证。工程验收可以检查可靠性行为，但涉及人身与机械风险时，应由具备相应能力的人员完成系统级安全设计与确认。
用一个晚到的结果检查架构
评审时可以推演这样一条事件链：设备正在执行任务A，用户取消A并发起任务B；随后A的模型结果才返回。合格的协议应让A保持取消状态，而不是因为收到了结果就重新启动。同时，B的反馈必须对应B，不能沿用A的完成标志。这个推演不依赖特定模型，却能暴露任务编号、取消状态与反馈关联是否缺失。
还可以继续追问：控制器重启后是否记得旧任务已经失效？上层服务超时重试时，设备会不会重复执行？若状态反馈中断，界面显示的是“进行中”“结果未知”，还是错误地显示“成功”？把这些分支逐一写出来，再对应到接口与测试，比只讨论模型延迟更容易发现系统问题。
立项前准备一张时序责任表
产品负责人提供真实任务与用户可接受的等待；算法侧说明输入、输出和资源条件；嵌入式侧列出控制任务、通信与保护行为；应用侧负责状态呈现、取消和恢复。最后共同确定每条边界由谁实现、在哪里测量、失败后由谁接管。
对于普众数智的板卡与智能体项目讨论，可以先从设备、动作、接口、时限和验收场景这五类资料开始。把要求落到同一张表上，板卡选型、模型部署和控制系统才有共同依据。需要准备项目资料时，可查看AI智能终端项目准备清单，先明确已有条件与待确认问题。
可靠的执行链并不追求所有事情都由同一个模型完成。它让理解、判断、动作与反馈各自承担清楚的责任：允许思考的地方充分思考，必须按时完成的地方给出确定行为，无法执行时及时、准确地说明原因。