制造业 Agent 控制塔：从设备告警到可回滚处置，真正减少停机时间
AWS 2026 年 8 月公开的制造控制塔把 IoT SiteWise、工业数据、知识库与 Agentic AI 连接起来；Google 9 月的安全制造蓝图强调 MCP/A2A 与工厂安全边界；Microsoft 10 月则展示了物理 AI 在编程、仿真和预测维护中的收益。三者指向同一结论：工厂 Agent 首先应成为“异常协调器”，而不是直接控制设备的自由规划器。
典型故障处理需要操作员查看告警、趋势、维修手册、工单、备件和相邻产线状态。真正的成本来自信息分散和等待专家，而不只是诊断本身。
模型负责综合证据与编排工具，安全联锁、设备极限和停机权限永远由确定性系统掌握。
先统一资产语义，再谈 Agent
同一台电机在 PLC、MES、EAM 和数据湖里可能有四个 ID。控制塔需要维护 ISA-95 层级和跨系统映射，事件进入时附带资产、工单和生产影响：
class PlantEvent(BaseModel):
event_id: str
asset_id: str
site_id: str
ts: datetime
signal: str
value: float
unit: str
limit: float
work_order_ids: list[str]
production_impact_per_minute: float
Agent 查询的是 asset_id 对应的受治理视图，不能把自然语言设备名直接拼进时序库查询。每条证据保留来源、新鲜度和质量标记，避免拿三个月前的振动基线解释今天的故障。
把诊断和动作拆成两条路径
诊断路径可以并行调用趋势分析、相似故障、手册检索和备件检查；动作路径必须串行通过门禁。即使模型判断“降低转速”，最终命令也要由白名单模板生成：
def authorize(action: ProposedAction, state: AssetState) -> Decision:
if action.kind not in {"create_work_order", "notify", "request_speed_change"}:
return Decision.deny("ACTION_NOT_ALLOWED")
if action.kind == "request_speed_change":
if not state.local_operator_present:
return Decision.require_human("LOCAL_CONFIRMATION")
if abs(action.delta_percent) > 5:
return Decision.deny("DELTA_TOO_LARGE")
return Decision.allow(ttl_seconds=60)
Agent 只提交意图和依据；工业网关在执行时再次读取当前状态、校验 TTL 与联锁条件。授权后状态已变化，就必须拒绝旧命令。
用可回滚状态机管理处置
states:
detected: [investigating]
investigating: [recommendation_ready, escalated]
recommendation_ready: [approved, rejected]
approved: [executing]
executing: [verified, rollback, escalated]
rollback: [verified, escalated]
terminal: [verified, escalated, rejected]
每次转换写入事件账本：谁提出、使用了哪些数据、策略版本、谁批准、设备前后状态和回滚结果。Agent 超时或模型不可用时，原有 PLC/MES 逻辑仍独立运行，不能让工厂依赖云端对话才能生产。
制造业 ROI 应看停机分钟而不是问答次数
核心指标包括异常提前量、MTTA、MTTR、误报率、首次修复率、计划外停机分钟、备件等待时间和每次处置的恢复产值。AWS 案例给出的方向性结果包括意外停机最多降低 36%、MTTR 改善约 30%；企业评估时仍要用自己的瓶颈设备产值、维护合同和历史故障验证。
首期应从“读数据—建工单—推荐步骤”开始；只有当建议在影子运行中持续通过现场验证，才逐步开放低风险写操作。制造 Agent 的终点不是无人值守，而是让有限的设备专家覆盖更多工厂，同时不牺牲物理安全。