产线巡检 Agent：从开发到评测优化闭环

制造业产线的日常运维里有个典型痛点：供电恢复后部分设备仍需人工重启，响应不及时就延长停机时间。让 Agent 接手"发现问题 → 判断原因 → 确认条件 → 调用工具恢复"这条链，是 Agent 在工业场景最直接的落法。这一课借产线巡检案例，看 Agent 交付的完整闭环——开发只是其中一环，评测驱动优化才是灵魂。

一、场景拆解：人工流程怎么变成 Agent 流程

以"来电后输送带未恢复"为例，两条路径对比：

• 人工：巡检员发现停机 → 查看设备状态与生产信息 → 判断原因（停电）→ 确认供电恢复 → 手动重启 → 上报；
• Agent：接入运行资料与设备状态数据 → 分析停机原因 → 确认具备运行条件后调用工具恢复产线 → 记录与上报。

注意"确认具备运行条件"这一步——Agent 可以自动判断，但恢复动作的触发条件要和客户运维规程逐条对齐，这是工业交付与互联网 Demo 最大的区别：规程就是法律。

二、Penguin Harness：把开发从"写代码"变成"给料"

人工构建这类 Agent 要写前后端、调效果，耗时耗力。Penguin Harness 的思路是：使用者提供四样东西——

1. 业务需求（产线巡检、异常处理流程）；
2. 输入示例（设备状态数据长什么样）；
3. 格式规范（输出与处置建议的结构）；
4. MCP 工具（重启设备、查询状态等可调用能力）；

框架据此自动开发 Agent 及配套网页应用，并结合评测反馈持续改进任务表现。基础使用四步：安装客户端 → 模型库接入模型 API（如 DeepSeek，填 API Key/地址/模型 ID）→ 用示例任务跑通一次交互 → 克隆 starter 仓库开始正式开发。

对 FDE 的启示不在工具本身，而在范式：交付物的重心从"我写的代码"转移到"我定义的需求、示例、格式与工具契约"——这四样才是可评审、可移交、可复制的资产。

三、评测驱动的优化闭环

原著把"开发与优化"并列为标题——Agent 上线不是终点：

1. 建评测集：把历史异常处置案例整理成"输入状态 → 期望判断与动作"的用例集；
2. 跑分定位：用评测找出 Agent 判断错误的模式（误判停机原因、条件不满足就建议重启、输出格式不稳定）；
3. 针对性改进：补需求描述、补输入示例、调格式规范、增删工具——改一轮测一轮；
4. 回归门禁：每次改动后全量回归评测集，防止"修一个坏一个"。

这正是交付工程线"评测体系从零建"的方法在 Agent 场景的具体化——没有评测集的 Agent 交付，等于把回归测试的责任甩给客户。

四、FDE 视角：工业场景的交付纪律

• 行业机理先行：不懂停电恢复规程就接不了这个活——工业 FDE 的第一周永远在跟客户运维学规程（呼应能力域 B1 行业机理与价值链）；
• 动作分级：查询类工具放开自动调用，恢复类动作设确认门槛或白名单条件——把"敢放进客户生产系统的边界"写进方案（呼应交付工程线的 Agent 动作约束）；
• 可复制性：需求文档 + 输入示例 + 格式规范 + 工具契约 + 评测集，五件套齐了，下一个产线的同类项目就是换数据重跑——从项目到产品化的路径就藏在这五件套里；
• 安全底线：工业系统任何写操作都要有审计记录与人工回退手段，方案里必须写明。

本课自测

1. Penguin Harness 的输入四件套是什么？为什么说它们才是可移交的资产？
2. "确认具备运行条件后再恢复"这一步为什么必须与客户运维规程逐条对齐？
3. Agent 评测优化闭环的四步是什么？没有评测集的交付有什么隐患？
4. 查询类工具和恢复类动作为什么要区别对待？