真实硬件会受到接线、设备状态、固件、时序和外部输入影响。硬件智能体报告一次“成功”时，需要同时提供足以复查该结论的执行记录。
先看证据，再看结果
一条绿色状态表达了系统的判定。要评估这项判定，需要知道执行环境、目标设备、工具调用、关键输出、观察时间和验收条件。
如果这些信息散落在终端、聊天记录、个人脚本和设备日志里，智能体就无法形成可靠反馈，人也很难在失败后重建现场。
每次执行都要回答三件事：谁做了什么、设备如何响应、系统凭什么下结论。
闭环中的三类事实
执行事实
谁在什么工作区、针对哪个 HWPOD、调用了什么能力。执行事实建立动作与资源的对应关系。
观察事实
编译输出、烧录结果、串口响应、网络报文和仪器读数。观察事实说明真实世界发生了什么。
判定事实
系统依据哪些条件得出通过、失败或无法判定。判定事实让结论可以被质疑、复查和改进。
失败分类也是产品能力
硬件任务失败可能来自代码、工具链、设备离线、资源占用、接线、时序或验证条件本身。把所有失败都折叠成一个错误提示，会让人和智能体重复走同样的弯路。
Harness 运行测试，也把观察结果整理成结构化证据，并将失败归入可以处理的类别。下一次执行可以复用已验证的路径、绕开已知问题，或明确请求人工介入。
审计证据需要明确边界
证据系统围绕任务目标保留足以解释结论的事实。原始数据、摘要、最终截图和长期报告各有保存边界；界面直接展示事实来源与缺失状态，不用推测补空白。