arXiv 2610.12549，Fly-by-Code，cs.RO，10 月 8 号挂上去的。这编号我记了两天，因为整篇论文翻来覆去就在讲一件特别朴素的事：具身智能体失败，多数时候不是脑子不够，是眼睛不够。
「执行反馈」这四个字被讲得太顺了，顺到没人问它凭啥成立。画张图。
自然语言指令
│
▼
┌────────┐ ┌────────┐ ┌──────────────┐
│ 生成程序 │ ──► │ 上机执行 │ ──► │ 执行反馈 │
└────────┘ └────────┘ └──────────────┘
▲ │
└────────── 改程序 ◄──────────────┘
这就是现在具身编码智能体的通行转法：你说人话，它写程序，程序跑出结果，结果反过来修程序。四个角，转圈，每一步都有代码撑着。
问题全在最后那个箭头。它底下压着两个从来没被写出来的前提：一，反馈能判断任务到底成没成；二，失败了，反馈里得剩下足够线索，告诉你该改哪一行。
空中操作把这两条同时打穿了。
一个卡在载荷上。无人机能挂多重的东西是有数的，相机为了轻，视野就得窄，覆盖范围压得很小。真正决定成败的那一下——夹爪合拢的瞬间、货物开始滑的那一下——经常就发生在画面之外。部分可观测，书上四个字，落到这儿就是：它压根没看见自己错在哪。
另一个卡在动力上。强动态耦合，控制裕度又小，一点延迟、一阵风，结果就翻脸。物理交互脆到同一个失败现象能有好几种成因，它看得见摔了，看不见为什么摔。
所以论文里有一句话我特别想单独拎出来：对同一份反馈反复分析，补不回从来没采到的观测，也分不清现有证据本来就不足以分辨的失败成因。
打个比方，闭着眼睛修表。你手指伸进去，摸到齿轮卡住了，但你看不见是哪个齿歪了。这时候你把手缩回来，把刚才摸到的那个感觉在脑子里过八十遍——没用，信息量就那么多。要么找只手电筒从缝里照进去，要么干脆拨一下，看哪个轮不跟着转。
AF 干的就是这两件事，名字就叫 View 和 Probe。
执行反馈 ──► 还有没说清的问题？
│
├─ 有 ──► 另写一个诊断程序 ──► 扔进仿真跑
│ ├ View ：换个信息量更高的机位，看之前没看到的结果
│ └ Probe：主动做一次物理试探，验证「是不是因为 X 才失败」
│
└─ 没有 ──► 回去改主程序
注意一个细节：诊断程序是另行合成的，不是把主程序再跑一遍。它是一次专门为了拿证据而写的代码。
这个比喻在这里漏风：修表的人心里有一张正确的图，他知道表应该怎么转；智能体没有。它的诊断程序是当场现写的，写歪了就是往反馈里再掺一层噪声。而且「伸手进去照一下」「拨一下试试」在真实世界里是要花电池、花时间、还可能把东西碰掉的——所以它才要在仿真里跑，而不是在真机上瞎试。
等等等等，先别急。我第一版把 AF 画错了。
当时我以为它是「让智能体多想一会儿」——把反馈那一格加宽，多分析几轮。画完我自己还挺满意，觉得挺合理。后来我对着 View / Probe 这两个词盯了半天，才反应过来画反了：它不多想，它去多拿证据。分析是沿着已有信息往下推，取证是往回走，去补那个洞。
重来。把「执行反馈」那一格劈成两半：
┌────────────── 执行反馈 ──────────────┐
│ 已经采到的 ｜ 本来就缺的 │
│ （分析再多也是这些） ｜ （分析