Agent 制造业：先把工单、设备信号和人工处置串起来，再谈智能工厂
制造场景最容易被包装成一个能自动排产和自动调机的智能工厂大脑，但真实落地往往先从异常解释、质量复盘和现场协同做起。
01.制造业最容易被写成“全自动智能工厂大脑”
一提到制造业和 Agent，很多文章马上会把目标写成：
- •自动排产
- •自动调机
- •自动检验
- •自动修复异常
这些方向当然有吸引力，但真实制造现场最难的问题，往往不是“算出一个最优答案”，而是：
- •当前工单、工艺版本和物料批次到底是不是一致的
- •告警、停机、换线和质检结果有没有被放到同一个上下文里
- •哪些动作可以自动做，哪些动作必须由班组长、设备工程师或质量工程师确认
- •现场留下来的记录，能不能支持后续追溯、复盘和责任划分
所以制造 Agent 更适合被设计成“异常处理与现场协同助手”，而不是一个越过 MES、QMS、SCADA 和设备互锁的全自动中枢。
02.先选一条可交付链路，而不是一上来碰自动控制
如果第一版就想覆盖全厂排产、设备参数优化、良率提升和预测性维护，项目通常会同时卡在数据、权限和安全边界上。
更现实的切入点通常是：
- •产线异常分诊
- •质量偏差解释
- •设备维修工单协同
- •班次交接摘要
以“现场异常助手”为例，一个可交付的第一版通常已经很有价值：
- •汇总工单、设备告警、工艺卡和质检记录
- •判断当前更像质量偏差、停机异常还是维修跟进
- •检索对应 SOP、点检项和历史处理经验
- •生成现场可执行的排查建议和交接摘要
- •不直接写入 PLC、修改配方或放行批次
这类链路比“自动调参的智能工厂大脑”更容易上线，也更符合现场治理逻辑。
03.一条能落地的制造链路，通常由四层组成
1. 工单与工艺事实层
这一层决定系统有没有资格理解现场到底发生了什么：
- •工单号、产品型号和批次
- •BOM、工艺路线和当前版本
- •设备、工位和班次信息
- •操作员、换线状态和上料记录
如果这层事实不清，后面的建议再流畅，也很难落地。
2. 设备与质量信号层
制造现场真正复杂的部分，在于信号来源很多而且节奏不同：
- •设备告警
- •传感器趋势
- •SPC 数据
- •质检抽样结果
- •停机与维修记录
Agent 的价值通常不是替代这些系统，而是把它们整理成一条人能读懂的异常上下文。
3. 分析与协同层
这一层最适合模型和检索系统结合：
- •汇总多系统事实
- •检索工艺卡、SOP 和维修手册
- •生成异常原因假设和排查建议
- •生成班组、设备、质量之间可共享的交接摘要
4. 人工确认与受控执行层
下面这些动作通常都不应该让 Agent 直接做：
- •改设备参数
- •放行或隔离批次
- •跳过质检步骤
- •修改生产节拍和排产优先级
这些动作必须留在互锁、审批和人工确认链里，否则系统很容易在“最需要谨慎”的地方越权。
04.模型负责整理与解释，系统负责互锁与执行
在制造场景里，一个更稳的职责拆分通常是：
更适合模型处理的部分
- •把告警、工单和质检信息整理成异常摘要
- •对比 SOP、工艺卡和历史案例
- •生成维修、质量或交接建议草稿
- •把复杂现场语言转成结构化待办
更适合系统处理的部分
- •提供实时工单、设备和质量事实
- •校验互锁、阈值和版本约束
- •创建或推进维修/质量工单
- •控制是否允许停线、调机、放行和报废
如果让模型同时承担“解释 + 控制 + 放行”的责任，最后最容易出问题的就是执行边界。
05.先让 Agent 输出结构化现场计划，再决定是否升级
相比让模型直接回答“这条线怎么处理”，更稳的做法是让它先输出一份受限计划。
from typing import Literal
from pydantic import BaseModel, Field
class ManufacturingPlan(BaseModel):
lane: Literal[
"quality_deviation",
"downtime_triage",
"maintenance_followup",
"shift_handoff",
]
work_order_id: str
equipment_ids: list[str] = Field(default_factory=list)
evidence_needed: list[str] = Field(default_factory=list)
recommended_actions: list[str] = Field(default_factory=list)
requires_supervisor_approval: bool = True
def run_manufacturing_workflow(plan: ManufacturingPlan, tools):
facts = tools.load_shopfloor_facts(plan.work_order_id, plan.equipment_ids)
docs = tools.search_process_documents(plan.work_order_id, facts)
draft = tools.generate_shift_summary(plan.lane, facts, docs, plan.evidence_needed)
checks = tools.validate_execution_guardrails(plan.recommended_actions, facts)
if plan.requires_supervisor_approval or checks.has_blockers:
return tools.route_to_supervisor(draft=draft, checks=checks)
return tools.execute_low_risk_ops_update(draft=draft, checks=checks)这个模式的价值在于：
- •先区分当前是在处理质量偏差、停机异常还是交接事项
- •需要补采的证据可以显式记录
- •高风险动作默认进入班组长、设备或质量复核
06.文件检索和受限代码工具，特别适合制造现场
制造现场经常会遇到大量非结构化和半结构化资料：
- •SOP
- •工艺卡
- •点检表
- •质检日报
- •维修记录
这类资料很适合通过文件检索先找依据，再通过受限代码工具做趋势分析、异常批次比对和报表汇总。
但“能分析文档和表格”不等于“可以直接改现场参数”。从分析走到执行，中间仍然需要业务系统和人工确认。
07.评估要看异常闭环，而不是只看“回答像不像老师傅”
制造 Agent 的评估，不应该只看它写出来的解释是不是像经验丰富的工程师，更应该看：
- •异常分诊是否准确
- •证据清单是否完整
- •人工补充最多集中在哪些环节
- •交接信息是否减少重复沟通
- •高风险动作是否都被正确拦下
这些指标更能反映系统有没有真的减少现场摩擦。
08.三个常见误区
1. 让模型直接调整设备参数或放行产品
模型可以帮助解释异常，但不应该越过互锁和审批去做高风险控制动作。
2. 忽视工艺版本、批次追溯和权限边界
制造现场很多问题都和版本、批次和授权有关，少了这些上下文，建议就很容易失真。
3. 只看实时告警，不看工单和质量背景
没有工单、换线、上料和质检背景，很多告警都只剩表面症状，难以形成可执行判断。
09.总结
制造 Agent 真正可交付的价值，不是变成一个“自动调机的超级大脑”，而是把原本分散在工单、设备、质量和交接里的信息组织成更稳的现场流程：
- •先把工单、工艺和信号事实拉齐
- •让模型承担解释、检索和协同
- •把受控执行留给系统和人工审批
- •用异常闭环而不是口号来评估系统价值
只要把这些边界设计清楚，Agent 就能成为制造现场的协作者，而不是新的风险源。