华为云 AI DevSpace 体验版实测：3 小时容器跑通一个注塑车间巡检 Agent

一、为什么选体验版而不是买台服务器

做车间数字化最怕两件事：一是买完服务器发现方案不成立，二是方案成立但运维扛不住。华为云 AI DevSpace 的体验版刚好卡在一个合适的位置——3 小时容器、免申请、开通即用。我今天就用它跑了一个"注塑车间巡检 Agent"，从零到能对话，全程不到一小时，剩下两小时留给调 prompt。

二、环境启动的实测数据

点"前往 AI DevSpace 实践"之后，页面进入三步配置：验证参数 → 启动 eduswarm → 打开 eduswarm。我掐着表记了进度：

00s   正在配置实操环境  0%
12s   验证参数          41%
24s   启动 eduswarm     55%
48s   启动中            59%
60s   环境配置完成      100%
     剩余时长 02:58:39

一分零二秒进容器，比我在本地装一套 Jupyter + 依赖还快。这里有个必须记住的点：体验版容器 3 小时后强制释放，再次启动是全新容器，上一轮的代码、数据、装好的包全部消失。所以第一件事不是写代码，而是先想清楚哪些东西必须落到容器外。

三、巡检 Agent 的四个模块

注塑车间的巡检需求其实很朴素：机台报警了，要判断是缺料、模温异常、液压超压还是模具卡死，然后给出处理动作和责任人。把它拆成 Agent，就是四块：

• 采集层：OPC UA / Modbus 读机台状态，老机台没有接口就退化成人工点检表单录入；
• 判定层：把报警码映射成工艺语义，用规则兜底，规则覆盖不到的交模型；
• 处置层：输出处理动作清单，按机台型号查 SOP，标注停机风险等级；
• 闭环层：处理结果回写，形成"报警码 → 处理动作 → 耗时"的历史样本，用于后续优化。

真正难点在判定层。同一个"模温异常"，可能是加热圈坏了，可能是冷却水流量不足，也可能是热电偶漂移。只给模型一段报警文本，它一定会给你模棱两可的答案；必须把上一小时的模温曲线、冷却水进出口温差、同模号历史报警一起塞进上下文，它才能收敛。

四、核心代码：报警判定 + 上下文拼装

import json, time, statistics

ALARM_MAP = {
    "E101": ("缺料", "低", "补料后复位，观察 3 模"),
    "E207": ("模温异常", "高", "查加热圈电流、冷却水流量、热电偶"),
    "E315": ("液压超压", "高", "立即停机，查溢流阀与压力传感器"),
    "E402": ("开模不到位", "高", "查模具卡滞、顶针复位、机械手干涉"),
}

def build_context(machine_id, alarm_code, history):
    """把单条报警扩成模型能判断的上下文"""
    last = [h for h in history if h["machine"] == machine_id][-20:]
    delta = []
    if len(last) >= 2:
        delta = [round(b["mold_temp"] - a["mold_temp"], 2)
                 for a, b in zip(last, last[1:])]
    return {
        "machine": machine_id,
        "alarm": alarm_code,
        "semantic": ALARM_MAP.get(alarm_code, ("未登记", "中", "按 SOP 处理")),
        "mold_temp_series": [h["mold_temp"] for h in last],
        "mold_temp_delta": delta,
        "coolant_in_out": [h["coolant_in"] - h["coolant_out"] for h in last],
        "same_code_7d": sum(1 for h in history if h["alarm"] == alarm_code),
        "avg_handle_min": round(statistics.mean(
            [h["handle_min"] for h in history if h["alarm"] == alarm_code] or [30]), 1),
    }

def decide(ctx):
    """规则先兜底，规则不够再交给模型"""
    code = ctx["alarm"]
    if code in ALARM_MAP:
        reason, risk, action = ctx["semantic"]
        # 模温异常：看温差趋势再细分
        if code == "E207" and ctx["mold_temp_delta"]:
            rising = sum(1 for d in ctx["mold_temp_delta"][-5:] if d > 0.8)
            if rising >= 3:
                action = "模温持续上升，优先查冷却水流量与模具水路堵塞"
            elif rising == 0:
                action = "模温平稳但报异常，优先查热电偶漂移或接线松动"
        return {"risk": risk, "action": action, "need_model": False}
    return {"risk": "中", "action": None, "need_model": True}

这段代码的意图很明确：能确定的绝不让模型去猜，只把不确定的推给它。规则命中时直接返回，省一次调用、也省一次幻觉风险；未登记的报警码才走模型，这时上下文已经带齐了趋势和历史频次。

五、三个必须提前踩平的坑

坑一：容器会消失。3 小时到点释放，不做持久化就是纯白干。我的做法是代码推到 GitCode 私有仓库、数据和 prompt 配置放 OBS，容器只当临时算力。

坑二：依赖重装很慢。每次新容器都是从零开始，pip 装 torch 这种大包能吃掉三分之一时间。把 requirements.txt 和 pip download 下来的 wheel 一起放 OBS，启动时 pip install --no-index --find-links=./wheels -r requirements.txt，能把安装时间压到 40 秒以内。

坑三：模型给的答案很自信但可能是错的。第一次跑，Agent 对 E207 给出的处置是"更换加热圈"，而我明确告诉它模温在下降。原因是上下文里只放了报警码没放趋势。上下文不全的时候，模型不会告诉你它信息不足，它会编一个像样的答案——这条比任何 prompt 技巧都重要。

六、值不值得继续

体验版适合"验证方案可行性"这个阶段：一分钱不花，一小时能出结果，方案不成立就立刻停。真要上生产，体验版撑不住——容器会消失、没有固定入口、也没法接车间的内网设备。我的判断是：用体验版把 Agent 的判断逻辑和 prompt 磨到 80 分，再换持久化版接真实数据，这样最省钱，也最容易在老板面前拿出一个能演示的东西。

下一步我准备把处置动作接进企业微信，报警触发后直接推给当班组长，回复"已处理"自动回写，把闭环层跑通。