Physical AI 基礎論述 / 06

機器人真正困難的地方：現實世界不會照 API 文件運作

機器人難，不只是因為模型還不夠聰明，而是因為真實世界沒有固定 schema、沒有保證延遲，也不會替摩擦、遮擋、碰撞、磨耗與人類行為提供乾淨的 API contract。

M.K.2026年9月6日8 分鐘閱讀

夕陽下的近未來濱水城市與山地交界，一台四足機器人在岩石與植被間移動，遠方自動運輸設備與無人機運作，呈現機器必須面對真實地形與不確定環境

M.K. / 文章與筆記實體 AI / AI 基礎設施 / 2026

如果把軟體工程師習慣的世界搬到現實裡，很多事情其實非常奢侈。

API 有文件，輸入有型別，服務會回傳狀態碼，資料庫可以重試，測試環境可以重建。就算外部服務失敗，我們通常還能 timeout、rollback、retry，甚至把整個 request 留到稍後再處理。

機器人沒有這種待遇。

地板不會告訴你摩擦係數，紙箱不會回傳「抓取點已變形」，透明玻璃不保證能被深度感測器正確看見，鬆掉的螺絲不會發 webhook，突然走進路徑的人更不會先呼叫你的 API。

這是我認為 robotics 最容易被低估的一件事：

機器人真正困難的地方，不只是讓 AI 「知道該做什麼」，而是讓整個系統在一個沒有 API contract 的世界裡，持續知道自己是否還能安全地做下去。

這和我前面談的 Physical AI 是同一條主線，但這篇要往工程現實再深入一步。Physical AI 的核心是 perception、reasoning、planning、action；機器人真正把這四件事串起來時，問題不是流程圖，而是每一層都會帶著誤差進到下一層。

數位世界的 contract，是物理世界最缺的東西

軟體 API contract 通常會定義幾件事：輸入格式、輸出格式、錯誤條件、timeout、版本與責任邊界。

真實世界幾乎沒有任何一項能完全保證。

一個機械手臂抓杯子，畫面看起來只是「辨識 → 接近 → 抓取」。但實際上需要同時處理：

杯子的位置估計有誤差；材質可能反光；把手可能被遮住；桌面高度和校正值有偏差；夾爪橡膠使用一段時間後摩擦力改變；杯子裡有沒有液體會改變重心；接觸瞬間還可能把物體推離原本位置。

這些不是 edge case。

它們就是物理世界的正常狀態。

Google DeepMind 在 2026 年推出 Gemini Robotics-ER 1.6 時，把 multi-view understanding、spatial reasoning 與真實環境理解放在核心位置。7 月發布 Gemini Robotics 2 時，又特別強調在現實不確定性下的安全，包括判斷任務是否可行、在不確定時要求人工介入，以及在人靠近時觸發安全停止。

這透露出一個很重要的方向：更強的 robotics AI 不只是「更會做」，也必須更會判斷什麼時候不該做。

感知問題不是「看不看得到」，而是「你有多確定」

Computer Vision 常用 accuracy、precision、recall 來描述模型表現，但機器人還多了一個更殘酷的問題：

錯誤感知會被轉成動作。

相機把物體位置估錯兩公分，對影像分類可能只是數字上的小誤差；對高速移動的機械手臂，兩公分可能就是碰撞。

遮擋尤其麻煩。機器人在移動時，自己的手臂也會遮住視線；拿起物體後，場景幾何又會改變。多鏡頭可以降低盲區，力覺與觸覺可以補足視覺，但感測器越多，也代表 calibration、時間同步與 sensor fusion 的問題越多。

因此我認為 robotics 裡真正有價值的 perception，不只是輸出「這是什麼」，而是同時輸出：

我看到了什麼、我有多確定、哪些區域看不到，以及這個不確定性是否已經高到不能繼續動作。

這也是為什麼 embodied reasoning 會變得重要。模型不能只回答場景裡有什麼，它必須把空間、視角、物體關係與行動後果一起理解。

接觸一發生，問題就從 AI 變成 physics

很多 robotics demo 最漂亮的部分，是機器人在物體碰觸前的規劃。

但真正困難往往從接觸那一刻才開始。

插頭插進插座、鑰匙轉進鎖孔、布料折疊、門把旋轉、零件卡榫裝配，這些任務都不是「移動到座標」就結束。接觸後的摩擦、變形、反作用力與幾何誤差，會形成新的狀態。

NVIDIA 在 2026 年介紹 Newton 的 contact-rich manipulation 時，特別把 tight-tolerance assembly、in-hand manipulation、cloth、cables 與 granular terrain 等問題納入更高擬真的物理模擬。Isaac Lab 也把高擬真物理與 contact modeling 當成縮小 sim-to-real gap 的重要手段。

這背後有一個很直白的事實：

機器人不能只「預測世界」，它還必須不斷量測自己剛剛那個動作到底造成了什麼。

所以成熟的 robotics system 必須是 closed loop。

不是 plan once, execute once，而是：

觀察 → 行動一小步 → 再觀察 → 更新狀態 → 修正 → 必要時停止。

這種 loop 的價值，比單次動作看起來有多聰明更重要。

延遲不是 UX 問題，而是控制問題

在 Web 服務裡，多 200 毫秒通常是體驗問題。

在機器人控制裡，延遲會直接改變系統動態。

感測器有 latency，影像 pipeline 有 latency，模型推理有 latency，網路有 latency，控制器也有 cycle time。更麻煩的是，這些延遲不一定固定。

如果機器人根據 300 毫秒前的畫面做出現在的動作，它其實是在控制一個已經不存在的世界狀態。

這也是 Edge AI 在 Physical AI 裡特別重要的原因。不是所有推理都一定要 local，而是 safety-critical loop 需要明確知道哪些決策不能依賴不穩定的遠端 round trip。

但 local inference 也不是萬靈丹。模型變小可能降低語意能力，運算加速會受功耗與散熱限制，感測器仍會有雜訊。

真正的系統設計問題，是把不同時間尺度拆開：

毫秒級的安全與低階控制由 deterministic mechanism 負責；較慢的 perception、planning 與 reasoning 處理更高層的目標；雲端再承擔不需要即時回應的更新、分析與較重模型。

這不是單一 AI 模型能解決的事，而是 system architecture。

機械磨耗會讓昨天正確的模型，明天開始漂移

軟體版本不變時，我們直覺上會認為系統行為應該大致相同。

機器人不是。

輪胎磨耗、關節背隙、夾爪表面老化、鏡頭髒污、電池衰退、馬達溫度、結構鬆動，都可能逐步改變同一個 command 產生的真實結果。

這也是我認為 Physical AI 和一般 software AI 最根本的差別之一：

模型不是在控制一個固定的執行環境，而是在控制一個會老化的身體。

因此 robotics observability 不能只看 software logs。它還需要看 actuator current、temperature、cycle count、calibration drift、collision history、sensor health，甚至動作成功率是否隨時間緩慢下降。

上一篇談 AI 智慧設備的產品生命週期時，我把 hardware、runtime、model、OTA 與 support period 視為一條變動中的 dependency chain。機器人再多一層：physical state 本身也在變。

安全不能建立在「模型大部分時候會答對」

當 AI 只輸出文字時，模型錯誤可以先由人看到。

當 AI 直接控制馬達，安全架構必須假設模型可能錯。

ISO 10218-1:2025 與 ISO 10218-2:2025 對工業機器人及其整合系統的安全要求，仍然把 inherent safe design、risk reduction、integration、commissioning、operation 與 maintenance 視為系統問題，而不是「AI 模型準確率夠高」就完成。

而且要注意，ISO 10218 本身主要聚焦 industrial robots，並沒有自動涵蓋所有 consumer 或 service robot 場景。

這個邊界反而很值得注意。

未來機器人若真正走出工廠，進入家庭、商場、街道與照護環境，安全問題會更難，因為外部環境不再受工程團隊控制。

我認為下一代 robotics safety 最重要的能力之一，不只是 emergency stop，而是 graceful uncertainty handling：

知道自己看不清楚，知道抓取結果和預期不同，知道任務條件已超出訓練分布，知道必須減速、重試、換策略，或把控制權交還給人。

Google DeepMind 今年把「不確定時主動要求人工介入」放進 Robotics 2 的安全評估方向，正好反映這種思路。

M.K. Angle：機器人真正要管理的是「不確定性債務」

軟體工程有 technical debt。

我認為 robotics 還有另一種更難看見的東西，我暫且叫它 uncertainty debt。

這不是正式業界術語，而是我用來描述一個系統裡那些「暫時能跑，但沒有被真正界定的不確定性」。

例如：

視覺模型在低光下會差多少？夾爪磨耗到什麼程度成功率會開始掉？網路延遲到多少必須切換 local mode？地面摩擦低到什麼程度要降低速度？感測器遮蔽多久後不能再相信上一幀狀態？連續三次抓取失敗時，是重試、換方法，還是停止？

如果這些問題沒有被轉成 engineering contract，demo 仍然可以很漂亮。

但系統只是在借債。

真正能規模化的 robotics 公司，不會只比誰的模型能做更多 task。我更在意誰能把這些不確定性逐步變成可量測的 operating envelope、failure mode、recovery policy 與 safety boundary。

換句話說，Physical AI 的護城河可能不是「模型最聰明」，而是「知道模型什麼時候不可靠，且系統仍能安全恢復」。

Simulation 很重要，但不能替真實世界簽保證書

模擬之所以重要，是因為真實世界測試昂貴、緩慢，而且某些危險情境不能靠大量真人試錯來蒐集。

NVIDIA Isaac Sim 與 Isaac Lab 都強調 physics simulation、synthetic data、domain randomization 與 robot learning；2026 年的 ManipulationNet 研究也直接把「真實世界的變異性」與「可重現、可比較的科學評測」之間的衝突視為 manipulation benchmark 的核心挑戰。

但 simulation 的角色不是證明「真實世界一定會這樣」。

它更適合用來大量找 failure modes、放大罕見情境，以及在進入實體測試前，把最明顯的錯誤先消掉。

最終仍然必須回到 field validation。

因為沒有任何 simulator 能替每一台實際出貨的機器，保證輪胎不磨、鏡頭不髒、地板不濕、人不突然走進來。

接下來真正值得看的，不是哪台 robot demo 最像人

我接下來更想追四個訊號。

第一，robotics benchmark 是否會從單次 task success，逐漸轉向 long-horizon reliability、recovery rate 與 uncertainty calibration。

第二，foundation model 的能力是否會和更 deterministic 的 safety/control layer 形成清楚分工，而不是讓一個大模型包辦所有時間尺度。

第三，simulation、fleet telemetry 與 field failures 能不能形成閉環，讓真實世界的新失敗快速回饋到測試與訓練環境。

第四，service robot 走進公共與家庭場景後，安全標準、責任邊界與 product support 是否會比模型 benchmark 更快成為採購門檻。

如果這些方向成立，未來 robotics 的競爭焦點會逐漸從「它能不能做」轉成「它能不能在未知條件下持續、安全地做」。

而這才是現實世界真正的 API contract：

不是世界承諾照你的規格運作，而是你的系統必須承諾，即使世界沒有照預期運作，仍然知道下一步該怎麼辦。

常見問題

為什麼機器人比一般 AI 軟體更難？

因為模型輸出會直接變成物理動作，而且感測、摩擦、接觸、機械磨耗、延遲與人類行為都會持續改變系統狀態。它不只需要做出正確判斷，還要能在錯誤與不確定性下安全恢復。

Simulation 可以解決 sim-to-real gap 嗎？

可以縮小，但不能完全消除。高擬真 physics、domain randomization 與 synthetic data 能大量增加訓練與測試情境，但真實材料、磨耗、感測雜訊與人類行為仍需要實體 field validation。

更大的 VLA 或 foundation model 能不能直接解決 robotics？

不太可能單獨解決。更強模型可以改善場景理解、規劃與泛化，但低階控制、時間同步、機械設計、安全冗餘、感測器健康與 failure recovery 仍是完整系統的一部分。

機器人安全是不是只要加 emergency stop？

不是。Emergency stop 是重要機制，但更成熟的安全系統還要處理風險降低、安全整合、感測器失效、human proximity、不確定性、降級模式與 recovery policy。工業機器人安全標準也把安全視為整個 robot application lifecycle 的系統問題。

什麼是本文所說的 uncertainty debt？

這是本文使用的分析框架，不是正式業界標準。它指系統中尚未被量化或轉成明確 failure/recovery contract 的不確定性。短期可能不妨礙 demo，但長期會成為可靠度與規模化部署的風險。