從 The Runtime Contract 看機器人安全

🎬 影片／照片位置：

觀看重點：觀察原始動作如何被安全條件攔截、修改，以及系統是否留下修改原因。

機器人可以由 AI policy、傳統控制器或遙操作系統產生動作。這些來源即使在測試資料上表現良好，放到沒有看過的環境裡，仍可能輸出速度過快、超出關節範圍或接近碰撞的命令。

年會第四場介紹 The Runtime Contract：在動作送到硬體之前，先經過一層即時安全檢查，把不符合限制的動作攔下或修正，再輸出給機器人。

本篇只回答一個問題：執行時安全層至少要檢查、修改與記錄哪些資料？

安全層不是另一個會聊天的模型

最基本的資料流可以寫成：

安全層可以使用規則、最佳化、Control Barrier Function（CBF，控制屏障函數）、可達性分析或其他方法。方法可以不同，但責任相同：在每個控制週期判斷動作是否符合已定義的限制。

它不是保證所有風險都會消失。安全條件沒有被定義、感測資料不可信或硬體故障未被監測時，框架仍然可能漏掉危險。

不同機器人，原始動作的意思不同

對移動式機器人而言，動作可能是線速度與角速度；對機械手臂而言，可能是關節位置、關節速度、末端位姿或相對位移；對夾爪而言，則可能是開合位置或力量命令。

因此，一套可重用的安全框架需要把介面與安全條件分開：

• Adapter：把不同硬體的輸入與輸出轉成共通格式。
• Constraint：定義速度、加速度、關節、碰撞與工作區限制。
• Fallback：決定限制被觸發後要限幅、停止、退回或交由人員處理。
• Logger：記錄原始動作、修正動作、觸發原因與延遲。

模組化的目的不是讓功能看起來更多，而是更換機器人時，不必把紀錄、重播與限制管理全部重做。

四種最基本的執行時限制

前兩類較容易轉成數值；硬體狀態需要設備遙測；任務語意則可能需要場景理解與明確流程規則。越接近高層語意，越不能只靠單一即時模型回答。

安全不只是不碰撞，還要避免永遠卡住

如果兩台機器人為了不碰撞而同時停止，而且之後都不再前進，系統雖然沒有撞擊，任務也沒有完成。

安全工程常把「不進入危險狀態」與「仍能持續完成任務」分開考慮。後者可用活性理解，例如多機器人系統需要避免死結，必要時決定誰先退讓、誰繞行，以及多久後交由人員處理。

這個觀念會在後面的雙臂避碰與器械交接文章反覆出現：沒有碰撞，不一定代表控制器成功；也可能只是兩支手臂都不敢動。

被修正的動作是重要資料

如果安全層把原始動作 a_raw 改成安全動作 a_safe，至少應留下：

timestamp
observation / state version
a_raw
triggered_constraint
a_safe
processing_latency
robot_response
task_outcome
human_override

這些資料可以回答：

• 哪一類動作最常被攔截？
• 哪個場景或模型容易觸發限制？
• 修正後是否仍能完成任務？
• 安全計算是否拖慢原本控制週期？
• 人員是否經常推翻系統處置？

年會示範也提到以 YAML stackfile 管理設定、重播既有資料，並比較不同安全條件攔截了多少動作。重播不能取代實機驗證，但可以先用相同資料比較規則差異，降低重複讓硬體冒險試錯的次數。

Human-Agent Teaming 的責任分界

年會第一場最後談到 human-agent teaming：人、agent 與機器人之間不是單向命令關係。

在低風險情況下，agent 可以提出建議；接近既定安全界線時，安全層可能暫時接管或阻擋；遇到規則沒有涵蓋的異常時，則需要把狀態、原因與可選處置交給人員。

這個分工必須事前定義，不能只寫「必要時由人工介入」。至少要說清楚誰能停止、誰能恢復、哪些動作需要雙人核准，以及系統如何留下稽核紀錄。

可以支持到哪裡？

本文說明的是執行時安全架構，不代表只要增加 filter 就能達成完整機器人安全。機構防護、功能安全、風險分析、硬體故障、通訊、資安、人因與場域程序仍需分別處理。

若應用涉及醫療場域，這一層也不能取代醫療器材風險管理、軟體生命週期、人因工程、電氣安全與臨床評估。

今天帶走三件事

1. 模型或控制器輸出的動作，在送往硬體前仍應經過可解釋的安全檢查。
2. 安全層需要同時處理限制、退回策略、延遲與完整紀錄。
3. 沒有碰撞不等於任務成功，還要確認系統沒有死結或永久停滯。

前三篇已經把任務、Physical AI 閉環與執行時安全說清楚。Day 4 開始進入 Physical AI Studio：先不碰 3D 軟體，從一段中文製程腳本開始。