AI编程代理将ESP32蓝牙OTA更新从8分钟缩短至22秒

在之前的一篇文章中，我们探讨了针对 Espressif ESP32-H2 芯片、基于 Matter over Thread 的空中下载（OTA）更新。为了有一个性能对比的基准，我们使用了 Espressif 官方的蓝牙 OTA 应用。但结果发现它很慢：一次更新耗时超过 8 分钟。如果你正拿着手机更新智能家居设备，这可不是好的用户体验。于是我们让 AI 编程代理去查明原因，并写一个更快的版本。它们花了 11.8 小时来完成实现并在硬件上运行。结果是：现在一次更新只需 22 秒。或者说：它在实验室里确实能用，但在现场却不行。代理们是在完美的实验室环境中开发这个方案的，没有考虑到杂乱的无线环境。把无线链路当作完美链路，是 AI 编程代理在硬件在环场景中常犯的错误之一。一旦意识到这一点，代理们就能够修复它。这个故事的寓意是：你的 AI 编程代理必须既能访问硬件在环，也能访问真实世界条件在环。

在我们上一篇文章中，AI 编程代理开发了六种方法来更新运行在 ESP32-H2 芯片上的 Matter 智能家居设备固件，并在一个 Groundrun 测试台上对每种方法进行了测量：一块 ESP32-H2 开发板、第二块开发板充当 Thread 边界路由器，以及一部手机，全部连接到一个运行器上，代理们通过 Groundrun 的命令行工具来驱动这个运行器。其中五种方法使用 Thread，即 Matter 用于电池供电设备的低功耗网状网络。第六种使用蓝牙，从一部运行 Espressif（该芯片的制造商）蓝牙更新应用的手机发起。我们加入这个作为参照点：蓝牙射频以 2 Mbit/秒运行，而 Thread 为 0.25 Mbit/秒。蓝牙更新耗时 8 分 4 秒。Matter over Thread 在其默认设置下耗时 8 分 38 秒。我们原本预计蓝牙会快好几倍。对于蓝牙更新来说，完成时间很重要。使用蓝牙时，用户从手机启动更新，并将手机放在设备旁边、保持应用打开，直到更新完成。一个手里拿着手机的人不会愿意等八分钟才完成更新。ESP32-H2 开发板、桌面运行器、手机。于是我们把硬件测试台交给代理们，并问了它们两个问题：为什么蓝牙更新这么慢，以及它最快能有多快？结果发现大部分时间都花在等待回复上：Espressif 应用每传输 4 KB 固件块，就需要在手机和开发板之间进行 27 次往返。第一个怀疑对象是射频。ESP32-H2 只有一个射频，它在 Thread 和蓝牙之间共享，而开发板在蓝牙更新期间会同时保持在其 Thread 网络上。也许这个并行网络就是罪魁祸首？为了测试这一点，代理们构建了 Espressif 的官方蓝牙更新示例，不包含 Matter 和 Thread，并针对这个示例固件运行 OTA 应用。使用该固件时，每 4 KB 固件块的更新速度为 1.22 秒。与启用 Thread 时速度相同。所以这不是罪魁祸首。代理们随后阅读了该应用的源代码。更新协议以 4 KB 块发送固件，开发板在接收时对这些块进行确认。应用将每个块拆分为 463 字节的数据包，一次发送一个数据包，等待开发板确认前一个数据包后再发送下一个。但开发板接受的蓝牙消息最大为 256 字节。因此手机的蓝牙软件将每个 463 字节的数据包拆分为三步：两部分加上一条最终的“写入”消息，并等待开发板确认每一步。每 4 KB 块总共 27 次往返。随后我们又给代理们增加了一个约束：尝试在不修改 Espressif 固件代码的情况下加快速度。因此任何加速都必须来自对手机应用的修改。以下是代理们所做的选择：这是每个应用处理一个 4 KB 块的样子：数据包 1 的第 1 部分、确认、第 2 部分、确认、写入数据包 1、确认……再重复 8 个数据包、块已保存、27 次往返。我们的应用，确认写入：数据包 1、确认、数据包 2、确认、数据包 3、确认……再重复 15 个数据包、块已保存、18 次往返。我们的应用，非确认写入：数据包 1 到 6、15 毫秒后、数据包 7 到 12、15 毫秒后、数据包 13 到 18、15 毫秒后、下一个块、块已保存、每块一次回复。代理们完成工作花了多长时间：从第一次提交到最后一次提交，代理们工作了 11.8 小时。工作被拆分为六项任务，每项由一个独立的代理运行：这些任务合计 10.0 小时。剩余的 1.8 小时是任务之间的时间，主要是在等待中间拉取请求的自动化测试运行。在编写任何代码之前，两个审查代理阅读了计划，一个检查事实，一个检查设计。它们发现了五个问题，必须在计划运行之前修复。测量任务是最长的，为 4.1 小时。十二次测量运行在测试台上花费了 57 分钟，其中包括两次在设置期间失败的运行及其重跑，以及每次更新前在 Matter 网络上设置开发板的时间。为了检查射频数据包的大小，代理们通过测试台驱动手机屏幕，在开发者设置中启用了手机的蓝牙日志，然后从日志中读取数据包大小。新应用的两种模式都比 Espressif 应用更快。确认模式处理 1.6 MB 镜像耗时 5 分 23 秒，非确认模式耗时 22 秒。十次实验运行每次都以成功的 OTA 更新结束。所以看起来一切正常。但所有这些运行都是在完美条件下完成的：从日志来看，没有一次运行需要重发数据包。这意味着该代码在实际部署时可能无法工作，因为现实世界中的无线链路往往有丢包，需要重发丢失的数据包。我们在最后一道关卡发现了这一点：当我们在蓝牙层面引入丢包以验证系统仍能工作时，在存在丢包的情况下，新的传输机制不再工作。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）