HexaShell 機器人研究：會修程式，為何精細插入仍卡關？（2026）

2026 年 10 月 16 日，Hongcheng Gao 等人在 arXiv 提交了 〈HexaShell: A Thin Harness for Exploring the Limits of VLM Agents as Robot Coding Agents〉，研究讓寫程式的 AI 透過簡單介面操作機器人，再把失敗修成可重用的工具。HexaShell 最值得讀的地方，是它把「能找出錯誤」與「能完成動作」放在同一張成績單上。

先看原文怎麼運作，再拆開成績的分母與測試條件，最後問：這種工具累積方式，離可靠的實體操作還有多遠？本文依作者公開論文與程式資料判讀，並對照 benchmark 的官方驗證規則；未執行機器人模擬。

HexaShell 的核心：失敗之後，留下可執行的修正

The harness translates and never decides.

中文：執行框架只轉譯命令，不替代理作決策。

HexaShell，第 3 節

Harness 可以理解為把 AI 的決定接到外部環境的執行層。這裡的分工是：一個代理嘗試任務，失敗後由另一個代理檢查紀錄、修改工具，再試同一場景；累積的工具在評測前凍結。改善的是工具程式，不是每次出錯後重新訓練一個模型。

想像機器人拿杯子時總是偏右：只在對話裡記下「下次往左」很難稽核；若改的是座標換算函式，就能檢查輸入、輸出與測試。這是程式形式的經驗累積值得研究的理由。模型是否真的學會更通用的操作能力，則需要另外設計跨場景驗證。

讓語言模型產生機器人程式已有研究基礎。Code as Policies 的原始專案就展示了以程式組合感知輸出與控制 API，包含回饋迴圈。HexaShell 把重點放在工具的保留與修復；不能把這段歷史寫成「第一次讓 AI 寫程式控制機器人」。理解模型、工具與執行層的分工，可接著看 Agent Harness 原理。

從像素到位置：工具替推理補上哪一段？

原文使用三個已校正的 RGB 相機，讓代理以影像與相機參數定位。工具可用兩個視角的對應點做三角測量，或讓視線與已知平面相交；必要時移動手腕相機補視角。OpenCV 的三角測量文件也明列，多張影像的二維對應點與投影矩陣可用來重建三維點。

這個分工有實際意義：看懂「紅色積木」與算出夾爪該去的座標，是兩種不同工作。幾何計算把一部分問題變成可重複運算；但它仍依賴相機校正、點的對應與平面假設。若夾住物體後遮住孔洞，重新量測的條件就變了。

原文的 Push T 個案尤其有說服力：作者追到跨相機的面積檢查出了問題；同一表面在不同解析度下占用的像素格數不同，工具卻用格數直接比較。修復後，同場景的後續嘗試完成任務。這段紀錄支持「可定位的程式錯誤能被修復」；單一成功個案的證據強度，仍須與整批凍結測試分開。

HexaShell 的 39.7%：先讀分母，再讀排名

作者報告在 RoboDojo 的 42 個模擬任務取得 39.7% 成功率、48.0 進度分數。公開結果檔列出 420 個 episodes；39.7% 採五類任務等權平均，並非將 420 次嘗試直接合併後的成功比例。進度分數則與完整成功率是不同指標。

這裡有三個會改變解讀的條件。第一，工具在開發場景完成後凍結，再測同一個 seed 的新 layouts；這是在固定場景生成規則內換擺法。第二，測試提示還帶有任務 recipe 與工具 notes。第三，榜上比較對象與本文系統的樣本數、seed 覆蓋及設定不同。這些差異都寫在論文實驗設定裡。

因此，我會把它讀成有價值的研究結果，而不直接把作者的「最佳成績」寫成已獲官方同條件驗證的冠軍。查閱當日，RoboDojo 官方驗證規則要求模擬以三個 seeds 報告平均與標準差，並經隱藏 layouts 驗證；官方已驗證排名與論文自行報告的比較，各有自己的證據門檻。

若你正在學習看 benchmark，可把這些問題接到 AI Evals 評估教學：先固定成功定義、輸入、預算與評分者，再比較分數。這也比只看一段成功影片，更接近可用的採用判斷。

接觸是重要瓶頸，但「不是推理」仍說得太滿

contact, not reasoning

中文：瓶頸在接觸，而不在推理。

HexaShell，作者的核心判讀

作者按物理互動分類：推、滑、按壓類平均成功率達 92.5%，精細插入類只有 8.3%。這是作者的分類統計，不是所有真實推動或插入工作的成功機率；也不能把兩組當成難度完全相同的對照實驗。

不過，這個落差提出了一個清楚的工程問題：把物件推到大致位置，與讓零件沿著窄孔順利進入，需要的回饋密度不同。接觸中只要姿態、摩擦或受力改變，先前算好的路徑就可能失效。合理的下一步是測試接觸期間持續量測、調整與停止的能力。

我同意接觸控制是這套系統的突出弱點；我存疑的是把它概括為「推理已經過關」。任務理解、視覺判定、動作選擇與執行互相影響，分類分數只能指出在哪些任務上容易失敗。要把原因完全歸給接觸，還需要能隔離其他因素的實驗。

作者也把下一步指向：夾爪拿住零件時繼續量測，並在接觸中修正。值得追蹤的可檢驗問題就是：增加這種回饋後，在相同新場景協定、時間與動作預算下，插入任務能否改善？把其他條件固定，才能知道補上的究竟是哪一段能力。

薄介面，不代表整套系統便宜或容易重現

「薄」描述的是代理接觸的介面，並不自動描述整套系統的建置成本。相機校正、運動轉換、模擬環境、工具測試與失敗分析，仍各自需要工作。對使用者而言，應該問的是完成一項正確任務花多少等待與工程維護，而不只是操作指令有幾個。

專案 README明列：釋出內容包含凍結工具與介面契約，harness 的 server、executors、agent container 與 evolution loop 尚未包含在這次釋出範圍。這表示研究者可以檢視工具邏輯，重現整條流程則還需要補足相應執行環境。

另外，原文附錄 D 說明了早期工具與人類同事的貢獻，以及對固定幾何常數的稽核與修正。因而，把成果說成「從零開始、完全無人介入的自我進化」會抹去實際開發條件。保留這些條件，反而讓工具改善的證據更容易評估。

接下來怎麼看：盯住三項可交付證據

如果你是開發者，先選一個失敗能被明確評分的小任務，保存輸入影像、工具版本、錯誤紀錄與修復前後結果。接受修復的依據應是重新執行後的外部檢查；再以未參與修復的場景測一次。需要把這段流程接成系統，可讀 最小 Agent Harness 實作。

如果你正在判斷具身 AI 的研究進展，下一份報告值得追三件事：跨 seeds 與場景條件的保持率、接觸中回饋的改善幅度、包含等待與失敗重試的完整成本。這三份證據各回答不同問題，不能互相代替。

如果你負責採用，先把精細接觸任務留在模擬與受控測試，訂好可量測的誤差、停止與碰撞條件，再逐步擴大。HexaShell 給出的啟發是把經驗變成能檢查的工具；採用的門檻，仍應落在你的任務能否持續、正確地完成。比較其他開放系統的評估邊界，可讀 Beam 權重開放與 Agent 評估。