小球从 4 个迭代到 16 个，最后栽在边界上：ESP-Mosaico 远程 HIL 碰撞全链路实录
标签：*ESP-Mosaico、ESP-Claw、ChatCoding、远程 HIL、IM 飞书通道、Lua 动画、Agent 增量迭代、ESP_FAIL*
> 承接上一篇飞书远程呼吸动画 HIL 实战，本篇是同一条飞书 IM 通道、同一个`bounce`任务的增量迭代实录。
> 同样是一句话下发需求，Agent 在原有脚本基础上持续演化物理动画，一路叠加规则；同时我们会重点拆解：Agent 的任务管理、记忆继承、物理推演，以及最后一次扩容到 16 球时触发`ESP_FAIL`的底层边界。
> 环境：ESP-Mosaico V1.2 + ESP-Claw，飞书 IM 远程通道，后端 deepseek-flash，`exclusive=display`独占屏幕模式。
## 导读
ChatCoding 的魅力，不只是 “一句话生成一段代码”。
真正好用的硬件 Agent，是**带记忆、带上下文、理解正在运行任务、懂得硬件资源上限、支持增量修改**的。
本次案例是一套连续迭代的弹性小球物理动画：从最简单的 4 颗边界反弹小球起步，我们一步步提需求：增加数量、开启球间弹性碰撞、碰撞瞬间变色，直到尝试加到 16 颗小球，触发硬件侧返回`ESP_FAIL`报错。
全程都在飞书聊天窗口完成，没有登录网页控制台、没有本地编译烧录；同时我们顺着对话日志，看懂 Agent 每一轮后台调度逻辑。
## 一、整体链路回顾（复用远程 HIL 闭环）
核心机制不变：`exclusive=display`独占屏幕，新任务自动关停旧屏幕任务，防止多个绘图脚本抢占屏幕资源。任务 ID 统一命名为`bounce`，作为同一个动画项目持续迭代。
试验记录
## 二、逐轮迭代完整日志 + 后台逻辑拆解
### 第 1 轮：初始需求，4 颗小球，边界反弹，碰边界变色
用户指令：
> 4 个彩色小球在屏幕内碰撞反弹，碰到边界改变颜色，持续运动。独占屏幕。
Agent 执行流程：
1. 触发响应，解析需求：4 小球、边界反弹、触边变色、持续动画、独占屏幕
2. 检索异步任务：发现上一轮呼吸圆任务`e60d1cec`，判定任务已停止（旧动画任务生命周期结束）
3. 确认当前屏幕空闲，准备启动全新`bounce`任务
4. 调用`lua_run_script_async`下发脚本，再调用`lua_get_async_job`拉取任务快照自检
5. 更新会话记忆：`[显示;彩色小球]`
6. 返回结果摘要：4 球碰撞动画启动，实时时间差 dt 驱动，约 30 帧，速度 170–260px/s
后台逻辑要点：
Agent 自带**任务清单检索能力**，每次收到指令第一件事不是直接写代码，而是先查询板子上正在跑哪些异步任务；它能区分：是新建任务、还是修改已有任务。
这里 Agent 主动使用`dt`时间差驱动，而不是固定 sleep，保证不同帧率下小球运动速度稳定，属于硬件 Agent 自动做的工程优化。
试验记录
### 第 2 轮：增量需求：升级为 8 个小球
用户指令：
> 升级为 8 个小球
Agent 思考与执行：
1. 识别增量需求：**在当前 bounce 脚本基础上修改数量 N=8，其余物理逻辑保留**
2. 内部推演硬件画布约束：480×480 屏幕，评估半径 24px 的小球在画布内的排布空间
3. 代码变更评估：仅仅修改数字 N=4→N=8，单字符改动，脚本文件大小几乎不变
4. 下发更新脚本，重启同一个`bounce`任务
5. 自检快照，更新记忆：`[彩色小球;显示]`
6. 反馈摘要：8 球、保留原有边界反弹变色，30 帧；同时主动给出可选优化方向：缩小半径、调整速度、增加球间碰撞
后台逻辑要点：
Agent 拥有**会话记忆（Memory）**，它记住了上一轮整套物理规则：边界反弹、碰边变色、dt 驱动、30 帧。用户只说 “加到 8 个”，不需要重复描述全部规则，Agent 自动继承原有逻辑，只修改参数。
这就是增量迭代，区别于每次从零生成全新代码。
试验记录
### 第 3 轮：增量需求：速度加快，加上球与球之间的互相碰撞
用户指令：
> 速度加快，加上球与球之间的互相碰撞
Agent 执行逻辑：
1. 解析两处变更：①速度区间上调 ②新增球间弹性碰撞物理逻辑
2. 物理模型自动实现：等质量小球，沿连心线交换速度分量；并且增加**重叠分离迭代（每帧 3 次迭代）**，解决小球碰撞后卡在一起、粘连卡死的经典物理仿真 bug
3. 速度区间由 170–260 px/s → 提升至 320–480 px/s
4. 异步下发脚本，重启 bounce 任务，任务快照自检
5. 更新记忆：`[彩色小球;碰撞]`
6. 主动提示可选优化：碰撞瞬间也变色
后台逻辑要点：
Agent 不只是简单拼接功能，它懂物理仿真的坑。
普通代码生成器，只会写简单碰撞检测，很容易出现小球粘在一起；ESP-Claw 的 Agent 会主动增加分离迭代，规避刚体重叠卡死问题，适配嵌入式 Lua 沙箱的运行环境。
试验记录
### 第 4 轮：增量需求：球球碰撞瞬间也闪一下新颜色
用户指令：
> 球球碰撞瞬间也闪一下新颜色
Agent 执行逻辑：
1. 修改碰撞判断函数：区分「边界碰撞」和「球球碰撞」两套变色触发点
2. 增加碰撞校验：**只在相向碰撞（相对速度 vn<0）的时候变色**
3. 规避 bug：如果不做相向判断，小球分离阶段依然会触发碰撞判定，造成同一次碰撞反复闪烁、疯狂变色
4. 下发脚本，重启任务，自检状态
5. 返回摘要：8 球、边界碰撞变色、球间相向碰撞也变色，其余参数不变
后台逻辑要点：
这是非常典型的**边界条件防护**。Agent 理解物理上 “碰撞” 和 “分开” 是两个阶段，主动增加相对速度判断，避免视觉上的 bug，体现硬件 Agent 的工程思维。
试验记录
### 第 5 轮：扩容尝试：增至 16 个小球 → 触发 ESP_FAIL
用户指令：
> 增至 16 个小球
Agent 内部推演：
1. 需求：N=16，保留全部碰撞、变色物理逻辑
2. 提前评估风险：480 画布、半径 24px，16 颗球密度极高，碰撞频次爆炸，计算量大幅上涨
3. 下发脚本请求，板子侧返回报错：`HTTP 请求失败: ESP_FAIL`
报错解读：
`ESP_FAIL` 是 ESP 底层通用失败码，在这个场景下，根本原因：
- 小球数量翻倍，两两碰撞检测的计算量是 O (N²)：8 球是 28 次碰撞检测，16 球是 120 次碰撞检测
- Lua 沙箱单帧运算负荷超限，帧率暴跌、调度超时，任务加载失败
- 也存在内存占用上涨、Lua 脚本堆内存不足的可能性
Agent 能做上层逻辑推演，但**它无法突破 MCU 算力、内存的硬件天花板**，到这里就触碰到这个嵌入式平台的性能边界。
> 这正好对应我们之前文章聊的 ChatCoding 增量天花板：Agent 可以不断叠加需求，但硬件算力、内存是硬约束，到阈值就会失败。
## 三、飞书 IM 通道，同一个`bounce`任务的增量迭代实录（电脑版实时截图）
## 四、ESP-Claw 这套 Agent 体系的核心后台能力总结
1. **任务生命周期管理**
每次收到指令，先枚举当前异步任务，识别旧任务、判断是否需要清理、复用同一个任务名更新，而不是无限新建任务。依靠`lua_run_script_async`、`lua_get_async_job`两个原语完成热部署 + 状态自检。
2. **长期会话记忆（Memory Update）**
每一轮结束都会写入记忆标签，例如`[显示;彩色小球]`、`[彩色小球;碰撞]`。记忆用来记住这套项目的基础规则，用户只需要说增量修改，不需要重复完整需求，大幅降低用户输入成本、减少 Token 消耗。
3. **增量优先，而不是全量重写**
优先在原有脚本上修改参数、追加逻辑，而不是每次从头生成整套代码。这也是为什么长迭代场景下，搭配 deepseek-flash 的 KV 缓存，Token 成本可控。
4. **自带嵌入式物理仿真的工程常识**
知道 dt 时间差驱动、知道小球粘连问题、知道相向碰撞判定，不是只输出教科书式物理代码，适配资源受限的 MCU。
5. **具备硬件边界感知，但无法预判极限算力阈值**
Agent 可以预判画面拥挤、碰撞变多的风险，但是无法精准预判 Lua 沙箱算力上限，当计算复杂度突破 ESP32-S31 的实时调度能力，就返回`ESP_FAIL`。
## 五、实战踩坑与优化建议
1. **O (N²) 碰撞检测是算力杀手**
小球数量越多，碰撞检测次数平方增长。ESP-Mosaico 的 Lua 沙箱算力有限，8 球是这个物理 Demo 的舒适区间，16 球直接触达算力上限。
> 优化方案：空间哈希分区（grid 空间划分），降低碰撞检测次数，或者缩小小球数量、降低帧率。
2. **区分两种变色触发逻辑，一定要加相向速度判断**
球球碰撞不加 vn<0 判断，会出现一闪一闪、反复变色的视觉 bug，这是物理仿真高频坑。
3. **独占模式的价值**`exclusive=display`，自动关停旧绘图任务，避免多脚本同时刷屏，是屏幕类交互 Demo 必备的资源隔离机制。
4. **远程 IM 链路的失败特点**
远程通道会出现两类失败：LLM 侧 400 参数错误、设备侧`ESP_FAIL`硬件执行失败。
- 400：大多是模型名称、参数、API 配置问题
- ESP_FAIL：大多是脚本复杂度、内存、算力超出板子承载上限
5. **迭代节奏建议**
适合小步增量调参，一次只改一个变量（数量 / 速度 / 规则），不要一次性叠加大量修改，更容易定位失败点。
## 六、适用场景与边界
适合：
- 远程快速迭代交互动画、物理演示 Demo、创客可视化作品
- 循序渐进调效果，边看边改，适合教学演示、现场展示
- 验证简单物理、交互逻辑，快速验证创意
不适合：
- 高密度、高实时性复杂物理仿真（会碰到 MCU 算力天花板）
- 超大规模粒子、大量刚体仿真，这类场景更适合 VibeCoding，在 ESP-IDF 里做 C 层开发
## 结尾
这一组小球碰撞的迭代链路，是非常经典的 ChatCoding 增量范式样本。
从 4 球到 8 球、增加碰撞、碰撞变色，全程一句话迭代；Agent 记住项目上下文、维护任务、自动处理物理 bug，直到我们主动挑战硬件算力边界，撞上`ESP_FAIL`。
它直观展示了一件事：AI Agent 可以帮你快速迭代创意，但**硬件的算力、内存，永远是嵌入式开发的底层约束**。这也是我们一直在聊的：AI Coding Agent 是放大器，不是突破硬件物理上限的魔法。
附录：deepseek-flash 使用量截图（当天进行了二个系列的小试验）
