云端 OpenClaw 遠(yuǎn)程執(zhí)行本地進(jìn)程原理機(jī)制詳解：Gateway、approvals 與 system.run 到底誰在判定、誰在執(zhí)行？

前言

在使用 OpenClaw 搭建“云端 Gateway + 本地 Windows 節(jié)點(diǎn)”的遠(yuǎn)程執(zhí)行體系時(shí)，最容易混淆的一件事，不是命令本身怎么寫，而是命令到底是誰決定能不能執(zhí)行，誰又真正負(fù)責(zé)把它跑起來。

很多人在剛接觸這套架構(gòu)時(shí)，腦子里往往會(huì)把幾個(gè)概念混在一起：

• 以為云端 Gateway 已經(jīng)設(shè)置成 tools.exec.host=node，那命令就一定能直接在本地執(zhí)行；
• 以為 system.run 既是執(zhí)行器，也是審批器；
• 以為白名單只要在云端配一次，就對(duì)所有節(jié)點(diǎn)通用；
• 以為 node.list 能看到節(jié)點(diǎn)，就說明 nodes run 一定能成功；
• 以為 SSH 隧道通了，就代表整條遠(yuǎn)程執(zhí)行鏈路已經(jīng)完全打通。

實(shí)際上，這些理解都只看到了局部，沒有把 OpenClaw 的控制面、執(zhí)行面、安全聯(lián)鎖、協(xié)議分層放在一個(gè)統(tǒng)一的框架里看。

這篇文章就圍繞一個(gè)核心問題展開：

OpenClaw 的遠(yuǎn)程命令執(zhí)行，到底是如何從“云端發(fā)起請(qǐng)求”一步步走到“本地機(jī)器真正啟動(dòng)進(jìn)程”的？

如果要用一句最直白的話概括整套機(jī)制，那就是：

Gateway 負(fù)責(zé)調(diào)度和下令，node 負(fù)責(zé)暴露本機(jī)能力，本地 approvals 負(fù)責(zé)決定這臺(tái)機(jī)器最后是否同意執(zhí)行，而 system.run 負(fù)責(zé)真正把命令跑起來。

這四者不是一個(gè)東西，也不是同一層邏輯。只有把它們徹底拆開，很多現(xiàn)象才能解釋得通。

一、先把最容易混淆的三層拆開

在 OpenClaw 的遠(yuǎn)程執(zhí)行體系里，最值得先建立的不是某個(gè)具體命令，而是“分層思維”。

從原理上看，至少要把下面三層分開理解：

1. 云端 Gateway 的默認(rèn)執(zhí)行策略層
2. 本地執(zhí)行主機(jī)上的 approvals / allowlist 層
3. 真正落到主機(jī)上執(zhí)行的 system.run 層

很多問題之所以越排越亂，根本原因就在于把這三層混成了一層，以為“能連上節(jié)點(diǎn) = 節(jié)點(diǎn)一定能執(zhí)行 = system.run 已經(jīng)有權(quán)限跑命令”。

實(shí)際上并不是這樣。

更準(zhǔn)確地說，OpenClaw 的設(shè)計(jì)是一個(gè)典型的“控制平面與執(zhí)行平面分離”架構(gòu)：

• 控制面在 Gateway 一側(cè)，負(fù)責(zé)決定請(qǐng)求該發(fā)給誰、按什么規(guī)則發(fā)、是否要求審批；
• 執(zhí)行面在 node 一側(cè)，負(fù)責(zé)把本機(jī)真實(shí)能力暴露給 Gateway；
• 主機(jī)側(cè)安全聯(lián)鎖又獨(dú)立存在于執(zhí)行主機(jī)本機(jī)上，作為最后一道安全閘門；
• system.run 只是執(zhí)行動(dòng)作的最終落點(diǎn)，并不是前面所有策略判斷的替代品。

所以，要真正讀懂“再結(jié)合 approvals 去調(diào)用 system.run”這句話，首先就要知道：

system.run 不是先執(zhí)行再審批，而是前面所有策略都通過之后，才有機(jī)會(huì)真正啟動(dòng)進(jìn)程。

二、第一層：云端 Gateway 的默認(rèn)執(zhí)行策略到底在管什么

先看第一層，也就是最上層的Gateway 默認(rèn)執(zhí)行策略。

在你的這套部署中，像 tools.exec.host、tools.exec.security、tools.exec.ask、tools.exec.node 這幾個(gè)配置，實(shí)際上都屬于這一層。它們定義的不是“某臺(tái)主機(jī)上的本地規(guī)則”，而是控制面默認(rèn)想怎么發(fā)起執(zhí)行請(qǐng)求。

1.1tools.exec.host：決定默認(rèn)執(zhí)行位置

這個(gè)配置決定的是：

• 到 sandbox 執(zhí)行；
• 到 gateway 所在機(jī)器執(zhí)行；
• 還是發(fā)給某臺(tái) node 執(zhí)行。

也就是說，它解決的是一個(gè)最頂層的問題：

默認(rèn)把執(zhí)行請(qǐng)求發(fā)到哪里。

它只是“調(diào)度意圖”，不是最終執(zhí)行結(jié)果。

1.2tools.exec.security：決定默認(rèn)安全模式

這個(gè)配置不是在本地機(jī)器上直接執(zhí)行白名單，而是定義 Gateway 在形成執(zhí)行請(qǐng)求時(shí)默認(rèn)遵循什么安全策略，比如：

• deny
• allowlist
• full

它表達(dá)的是控制面對(duì)于執(zhí)行請(qǐng)求的默認(rèn)安全態(tài)度。

1.3tools.exec.ask：決定默認(rèn)是否彈審批

這個(gè)配置決定在控制面層面，遇到執(zhí)行請(qǐng)求時(shí)要不要交互確認(rèn)。例如：

• 始終不提示；
• 未命中規(guī)則時(shí)提示；
• 總是提示。

本質(zhì)上它解決的是：

在請(qǐng)求進(jìn)入執(zhí)行面之前，控制面是否希望引入用戶交互式審批。

1.4tools.exec.node：決定默認(rèn)目標(biāo)節(jié)點(diǎn)

當(dāng)執(zhí)行目標(biāo)是 node 時(shí)，這個(gè)配置負(fù)責(zé)指定默認(rèn)發(fā)給哪一臺(tái)節(jié)點(diǎn)。

它解決的不是權(quán)限問題，而是路由問題。

1.5 這一層的本質(zhì)：定義“默認(rèn)執(zhí)行意圖”

因此，把這幾個(gè)配置合起來看，就能發(fā)現(xiàn)一個(gè)很重要的結(jié)論：

tools.exec.* 本質(zhì)上是在定義 Gateway 這一側(cè)的默認(rèn)執(zhí)行意圖，而不是對(duì)執(zhí)行主機(jī)作最終裁決。

也就是說，即便你已經(jīng)把云端 Gateway 配成“默認(rèn)發(fā)到 node、默認(rèn)走 allowlist、默認(rèn)不 ask”，它也只代表：

• 請(qǐng)求會(huì)優(yōu)先往 node 發(fā)；
• 安全模型按 allowlist 預(yù)期處理；
• 控制面默認(rèn)不額外交互。

但這還遠(yuǎn)遠(yuǎn)沒有走到“命令一定會(huì)在 Windows 上成功執(zhí)行”那一步。

三、第二層：什么是本地 approvals，它為什么才是主機(jī)側(cè)最后一道閘門

理解了 Gateway 的默認(rèn)策略之后，接下來要看第二層：執(zhí)行主機(jī)本地的 approvals。

這是很多人第一次接觸時(shí)最容易忽略，但實(shí)際上最關(guān)鍵的一層。

3.1 approvals 不是云端全局規(guī)則，而是執(zhí)行主機(jī)本地規(guī)則

所謂“本地 approvals”，最直接的理解就是：

真正負(fù)責(zé)執(zhí)行命令的那臺(tái)機(jī)器，自己本地保存的一份命令運(yùn)行規(guī)則文件。

如果你的執(zhí)行主機(jī)是 Windows 節(jié)點(diǎn)，那么這份文件通常就在 Windows 用戶目錄下，例如：

C:\Users\你的用戶名\.openclaw\exec-approvals.json

這說明一件非常重要的事：

approvals 不是放在云端 Gateway 上給所有機(jī)器通用的全局白名單，而是每一臺(tái)執(zhí)行主機(jī)各自持有的一份本地規(guī)則。

換句話說，誰負(fù)責(zé)真正落地執(zhí)行，誰就有自己的審批文件。

3.2 approvals 管的不是“模型想不想執(zhí)行”，而是“這臺(tái)機(jī)器愿不愿意執(zhí)行”

這層的意義必須說透。

大模型、CLI、Gateway 都可以形成“執(zhí)行請(qǐng)求”，但真正承擔(dān)風(fēng)險(xiǎn)的是執(zhí)行主機(jī)本身。因?yàn)橐坏┟盥涞?，它影響的是那臺(tái)機(jī)器上的：

• 文件系統(tǒng)；
• 用戶目錄；
• 桌面環(huán)境；
• 本地腳本；
• 系統(tǒng)命令；
• 甚至某些可訪問的網(wǎng)絡(luò)資源。

所以 approvals 的本質(zhì)不是模型側(cè)行為約束，而是資產(chǎn)擁有者視角下的主機(jī)安全聯(lián)鎖。

可以把它理解成一句非常白的話：

云端可以“建議執(zhí)行”，但本地機(jī)器有權(quán)說“這條命令我不接”。

3.3 為什么 approvals 必須放在執(zhí)行主機(jī)本地

這是 OpenClaw 這套設(shè)計(jì)最值得理解的地方之一。

如果所有審批都只放在云端，那就意味著：

• 遠(yuǎn)端控制面一旦配置錯(cuò)誤，可能直接影響所有執(zhí)行主機(jī)；
• 本地主機(jī)對(duì)自己資產(chǎn)的最后控制權(quán)會(huì)被削弱；
• 安全邊界會(huì)全部前移到遠(yuǎn)端，不符合“風(fēng)險(xiǎn)由資產(chǎn)擁有者最終把關(guān)”的原則。

而把 approvals 放在執(zhí)行主機(jī)本地，就實(shí)現(xiàn)了一個(gè)非常典型、也非常合理的機(jī)制：

最后一道生死線不在控制面，而在實(shí)際承擔(dān)風(fēng)險(xiǎn)的宿主機(jī)一側(cè)。

這就是為什么說 approvals 是 node host 的 guardrail，是主機(jī)側(cè)的 safety interlock。

3.4 approvals 里真正判定什么

這一層一般會(huì)包含類似下面這些維度：

• security
• ask
• askFallback
• allowlist
• 按 agent 生效的規(guī)則

其中最敏感的，就是 allowlist。

因?yàn)樗苯記Q定：

哪些命令入口、哪些腳本、哪些可執(zhí)行程序，允許在這臺(tái)機(jī)器上被遠(yuǎn)程觸發(fā)。

如果一個(gè)命令沒有命中 allowlist，又沒有可用的審批 UI，那它就會(huì)停在 approvals 這一層，而不是繼續(xù)往下進(jìn)入真正的執(zhí)行層。

這也就是很多人會(huì)碰到的那種現(xiàn)象：

approval required (approval UI not available)

這個(gè)報(bào)錯(cuò)的真正含義不是“system.run 壞了”，而是：

命令在本地 approvals 這一關(guān)被攔住了，根本還沒有機(jī)會(huì)真正落到 system.run。

四、第三層：system.run 到底是什么，它是不是“最終權(quán)限擁有者”

講到這里，才輪到第三層，也就是很多人最先注意到、但最容易誤解的 system.run。

4.1 system.run 的本質(zhì)：真實(shí)主機(jī)上的命令執(zhí)行器

如果用一句話給它定性，那么最準(zhǔn)確的說法是：

system.run 是執(zhí)行器，不是裁判器。

它的職責(zé)非常單純：

• 在節(jié)點(diǎn)主機(jī)上啟動(dòng)一個(gè)真實(shí)的本地進(jìn)程；
• 把命令真正交給宿主機(jī)操作系統(tǒng)去運(yùn)行；
• 返回執(zhí)行結(jié)果、錯(cuò)誤信息或運(yùn)行狀態(tài)。

你可以把它類比成“遠(yuǎn)程桌面環(huán)境里的啟動(dòng)程序動(dòng)作”，也可以把它理解成“節(jié)點(diǎn)主機(jī)暴露出來的 CreateProcess 接口入口”。

它負(fù)責(zé)的是把命令跑起來，不是負(fù)責(zé)決定“這條命令是否應(yīng)當(dāng)被允許跑起來”。

4.2 為什么說 system.run 很敏感

因?yàn)橐坏┧徽嬲{(diào)用，落地的就不再是 OpenClaw 自己的內(nèi)部邏輯，而是宿主機(jī)上的真實(shí)命令執(zhí)行。

它理論上可能啟動(dòng)的對(duì)象包括但不限于：

• 系統(tǒng)自帶命令，如 where.exe；
• 用戶自己編寫的批處理腳本，如 paper_scan.cmd；
• PowerShell；
• 其他被允許的本地二進(jìn)制程序；
• 依賴本地環(huán)境變量的命令入口。

這就是為什么 system.run 看似只是一個(gè)“命令執(zhí)行能力”，但它的權(quán)限邊界非常敏感。因?yàn)樗坏┱娴谋挥|發(fā)，本機(jī)真實(shí)資源就可能被訪問或修改。

4.3 它不是“無限授權(quán)”，而是“繼承宿主機(jī)運(yùn)行身份的能力”

這里必須糾正一個(gè)很常見的誤區(qū)：

很多人會(huì)把 system.run 想象成一個(gè)天然擁有高權(quán)限的系統(tǒng)級(jí)執(zhí)行器，仿佛只要通過了它，就等于自動(dòng)拿到了這臺(tái)機(jī)器的全部控制權(quán)。

這并不準(zhǔn)確。

更嚴(yán)謹(jǐn)?shù)睦斫鈶?yīng)該是：

system.run 本身并不憑空創(chuàng)造權(quán)限，它繼承的是 node host 運(yùn)行賬戶在宿主機(jī)上的權(quán)限邊界。

這意味著：

• 如果 node host 是以普通用戶身份啟動(dòng)的，那么 system.run 啟動(dòng)出來的進(jìn)程通常也只是普通用戶權(quán)限；
• 如果 node host 可以訪問當(dāng)前用戶目錄、桌面、文獻(xiàn)目錄，那么 system.run 在規(guī)則允許的前提下，原則上也可能訪問這些位置；
• 如果某些操作需要管理員權(quán)限，而 node host 當(dāng)前沒有提權(quán)能力，那 system.run 也不會(huì)神奇地自動(dòng)越權(quán)。

所以，system.run 的權(quán)限上限，大體上就等于：

啟動(dòng) node host 的那個(gè) Windows 用戶本來能做什么。

4.4 為什么最佳實(shí)踐不是直接放開 PowerShell，而是只放固定腳本入口

從工程實(shí)踐角度看，最穩(wěn)妥的做法通常不是 allowlist 一個(gè)功能極強(qiáng)的通用解釋器，而是只允許固定用途的腳本入口，例如：

paper_scan.cmd
paper_rename.cmd
paper_classify.cmd

這樣做的好處非常明顯：

• 把執(zhí)行能力收斂到你自己定義過的流程入口；
• 降低遠(yuǎn)程任意命令拼接帶來的風(fēng)險(xiǎn)；
• 便于審計(jì)、回放、排錯(cuò)；
• 更適合作為可控的自動(dòng)化節(jié)點(diǎn)能力暴露給 Gateway。

所以，真正安全的思路從來不是“給 system.run 更多權(quán)力”，而是：

讓 system.run 只被允許走你定義好的、邊界清晰的受控入口。

五、把整句話講透：什么叫“再結(jié)合 approvals 去調(diào)用 system.run”

這是最值得拆開講透的一句話。

原話聽起來容易讓人誤解成一種線性直覺：

• 先調(diào)用 system.run；
• 再看 approvals；
• 不通過就攔掉。

但真實(shí)機(jī)制恰恰不是這樣。

更準(zhǔn)確的理解應(yīng)該是：

控制面先決定原則上怎么發(fā)，本地主機(jī)再?zèng)Q定這條請(qǐng)求是否允許落地，只有兩邊都通過之后，system.run 才會(huì)被真正調(diào)用。

換句話說：

不是先跑了再審批，而是審批通過之后才真正執(zhí)行。

六、按時(shí)序看完整判定鏈：一條命令是怎么一步步落地的

如果把整個(gè)過程按時(shí)間順序展開，通常可以拆成下面 5 步。

第 1 步：模型、CLI 或自動(dòng)化流程形成執(zhí)行請(qǐng)求

一切的起點(diǎn)，都是某個(gè)控制面主體發(fā)起了一個(gè)“希望執(zhí)行命令”的請(qǐng)求。這個(gè)主體可能是：

• 模型驅(qū)動(dòng)的操作；
• CLI 命令，如 openclaw nodes run；
• 自動(dòng)化任務(wù)；
• UI 上的某次執(zhí)行動(dòng)作。

這一階段還沒有真正碰到執(zhí)行主機(jī)，只是生成了一個(gè)執(zhí)行意圖。

第 2 步：Gateway 根據(jù)tools.exec.*看默認(rèn)策略

接下來，Gateway 會(huì)先根據(jù)自己的默認(rèn)配置來判斷：

• 這條請(qǐng)求應(yīng)該發(fā)到 sandbox、gateway 還是 node；
• 安全模式默認(rèn)是什么；
• 遇到執(zhí)行是否需要彈審批；
• 默認(rèn)目標(biāo) node 是哪一臺(tái)。

注意，這一步仍然只是控制面判斷。

它解決的是“原則上應(yīng)該怎么發(fā)”，不是“執(zhí)行主機(jī)是否最終同意執(zhí)行”。

第 3 步：Gateway 把請(qǐng)求轉(zhuǎn)發(fā)給目標(biāo) node

當(dāng)目標(biāo)是某臺(tái) node 時(shí)，Gateway 會(huì)把這條請(qǐng)求通過與 node 的連接通道發(fā)過去。

這一步體現(xiàn)的是控制面與能力宿主之間的轉(zhuǎn)發(fā)關(guān)系。

也就是說，Gateway 并不是自己替 node 執(zhí)行命令，而是：

把控制面形成的執(zhí)行請(qǐng)求，交給具備相應(yīng)能力的 node host。

第 4 步：node 在本機(jī)讀取exec-approvals.json再判一次

到了這一步，事情才真正進(jìn)入主機(jī)側(cè)安全聯(lián)鎖。

node 會(huì)根據(jù)本機(jī)的 approvals 規(guī)則再做一次判斷，包括：

• 這條命令是否符合本地 security 策略；
• 是否命中 allowlist；
• 是否需要 ask；
• 未命中時(shí)是否走 askFallback；
• 當(dāng)前環(huán)境有沒有可用審批 UI。

這一關(guān)非常關(guān)鍵，因?yàn)樗淼氖牵?/p>

即使 Gateway 愿意發(fā)，本地執(zhí)行主機(jī)也仍然可以拒絕。

第 5 步：前面都通過后，node 才真正調(diào)用system.run

只有在前面所有條件都通過后，才會(huì)真正落到最終執(zhí)行層。

也就是：

• node 調(diào)用 system.run；
• 宿主機(jī)啟動(dòng)本地進(jìn)程；
• 返回真實(shí)執(zhí)行結(jié)果。

這一步才叫“命令真正落地”。

因此，整條鏈路最準(zhǔn)確的白話版可以概括成一句：

先在控制面決定原則上允不允許發(fā)，再在執(zhí)行主機(jī)決定這臺(tái)機(jī)器到底準(zhǔn)不準(zhǔn)跑，最后才真正啟動(dòng)進(jìn)程。

七、為什么node.list能成功，不代表nodes run一定成功

這是遠(yuǎn)程執(zhí)行場(chǎng)景里最常見、也最容易讓人誤判的問題之一。

很多人看到：

• gateway call node.list 能拿到節(jié)點(diǎn)；
• 節(jié)點(diǎn)狀態(tài)是 paired；
• 節(jié)點(diǎn)狀態(tài)是 connected；

就會(huì)自然得出一個(gè)錯(cuò)誤結(jié)論：

既然節(jié)點(diǎn)在線，那執(zhí)行命令肯定沒問題。

其實(shí)這個(gè)推理跳過了很多層。

7.1node.list成功，只能說明“節(jié)點(diǎn)注冊(cè)與連接層”是通的

當(dāng) node.list 正常返回時(shí)，它最多只能說明：

• SSH 隧道大概率沒問題；
• Gateway 本身在工作；
• 節(jié)點(diǎn)確實(shí)已經(jīng)注冊(cè)到 Gateway；
• 當(dāng)前節(jié)點(diǎn)連接狀態(tài)正常；
• Gateway 能看到節(jié)點(diǎn)的能力聲明。

但這些都還只是“能看到節(jié)點(diǎn)”，不等于“能成功調(diào)起節(jié)點(diǎn)能力執(zhí)行命令”。

7.2nodes run失敗，可能卡在更后的任意一層

nodes run 真正失敗的位置，可能在后面很多層里：

• CLI 當(dāng)前版本的節(jié)點(diǎn)命令調(diào)用通道本身存在不穩(wěn)定；
• Gateway 到 node 的具體命令分發(fā)過程中斷；
• 節(jié)點(diǎn)能力聲明與調(diào)用不匹配；
• approvals 未命中 allowlist；
• 審批 UI 不可用導(dǎo)致卡在 approval required；
• 本機(jī)命令入口不存在；
• system.run 啟動(dòng)目標(biāo)進(jìn)程失敗。

因此，node.list 與 nodes run 根本不是同一個(gè)層次的成功標(biāo)準(zhǔn)。

一個(gè)是在看：

我能不能看到節(jié)點(diǎn)。

另一個(gè)是在看：

我能不能穿過整條執(zhí)行鏈，最終讓命令在主機(jī)上真的跑起來。

這兩者之間隔著：

• 協(xié)議層；
• 角色層；
• 能力層；
• 主機(jī)審批層；
• 最終執(zhí)行層。

所以，node.list 能成功，只能證明“前幾層沒問題”，絕不能直接推出“命令執(zhí)行鏈已經(jīng)完全打通”。

八、所謂“遠(yuǎn)距離通信協(xié)議層級(jí)需要對(duì)應(yīng)”，到底是什么意思

很多人在排查遠(yuǎn)程節(jié)點(diǎn)問題時(shí)，會(huì)說一句很抽象的話：

協(xié)議層級(jí)需要對(duì)應(yīng)。

這句話如果不拆開，很容易流于空泛。其實(shí)它背后講的是一整套分層鏈路。

要把它說清楚，可以從下往上分成六層來看。

九、第一層：網(wǎng)絡(luò)可達(dá)層——先解決“能不能連到”

這是最底層。

例如你的架構(gòu)里，可能是這樣的：

• 云端 Gateway 監(jiān)聽在云服務(wù)器 127.0.0.1:18789
• Windows 本地通過 SSH 隧道，把本地 18790 映射到云端 127.0.0.1:18789

這一層的職責(zé)只有一個(gè)：

讓本地 node 看起來像是在連本地端口，實(shí)際上流量通過 SSH 轉(zhuǎn)發(fā)到云端 Gateway。

注意，這一層只解決了“TCP 路能不能打通”。

它解決不了下面這些問題：

• Gateway 協(xié)議是否正確；
• WebSocket 是否握手成功；
• 鑒權(quán)是否通過；
• 角色是否匹配；
• 節(jié)點(diǎn)能力是否存在；
• approvals 是否放行。

所以網(wǎng)絡(luò)通，不代表執(zhí)行通。

十、第二層：WebSocket 連接層——不是裸 TCP，而是承載會(huì)話語義的連接

node host 并不是向某個(gè)隨便的 TCP 端口發(fā)送字符串，而是要連接到 Gateway WebSocket。

這意味著 SSH 隧道里承載的，不是“裸 TCP 上隨便發(fā)點(diǎn)字節(jié)”，而是：

WebSocket over forwarded TCP

也就是說，網(wǎng)絡(luò)可達(dá)只是基礎(chǔ)，真正進(jìn)入 OpenClaw 通信語義的起點(diǎn)是 WebSocket 連接建立成功。

如果這一層失敗，哪怕端口是通的，node 也沒法變成一個(gè)真正掛接到 Gateway 上的能力宿主。

十一、第三層：Gateway 協(xié)議層——連上了，不代表會(huì)說“同一種話”

即使 WebSocket 連上了，也還不夠。

因?yàn)樵?WebSocket 之上，OpenClaw 還有自己的一套消息協(xié)議。

從抽象上看，這一層會(huì)涉及類似這樣的消息結(jié)構(gòu)：

• Request：請(qǐng)求某個(gè)方法調(diào)用；
• Response：返回成功或失敗；
• Event：推送某類狀態(tài)事件。

也就是說，SSH 隧道和 WebSocket 只是通信管道，而 Gateway 協(xié)議層才是真正約定：

• 消息長(zhǎng)什么樣；
• 誰發(fā)請(qǐng)求；
• 誰回響應(yīng)；
• 如何標(biāo)識(shí)方法、參數(shù)、結(jié)果和錯(cuò)誤；
• 初始握手時(shí)如何表明身份和能力。

所以，“協(xié)議層級(jí)需要對(duì)應(yīng)”在這里的第一重含義就是：

鏈路打通了，不代表雙方已經(jīng)能用同一種協(xié)議語義正常通信。

十二、第四層：角色與作用域?qū)?mdash;—為什么 CLI 和 node 同樣連著 Gateway，干的事卻完全不同

繼續(xù)往上，就進(jìn)入角色層。

在這套體系中，雖然很多東西都連接到同一個(gè) Gateway，但它們并不是同一種身份。

例如可以粗略區(qū)分為兩類：

• operator：CLI、UI、automation 這類控制面客戶端；
• node：暴露能力的宿主，例如 system、browser、screen 等。

這個(gè)區(qū)分非常關(guān)鍵，因?yàn)樗鼪Q定了：

• 誰負(fù)責(zé)發(fā)請(qǐng)求；
• 誰負(fù)責(zé)提供能力；
• 誰擁有讀取、寫入、管理、配對(duì)等不同范圍的操作權(quán)；
• 誰可以注冊(cè)自身能力，誰只是去調(diào)用別人的能力。

所以，即使 CLI 和 node 同樣都“連著 Gateway”，兩者在體系里的角色完全不同：

• CLI 更像調(diào)度者、管理者、調(diào)用者；
• node 更像資源宿主、能力提供者、執(zhí)行者。

這也是為什么不能簡(jiǎn)單地把“連上 Gateway”理解成“所有連接對(duì)象都擁有同樣的能力”。

十三、第五層：節(jié)點(diǎn)能力聲明層——節(jié)點(diǎn)在線，不代表什么命令都能接

再往上，是很多人經(jīng)常忽視的一層：節(jié)點(diǎn)能力聲明。

node 被 Gateway 看到，只代表這臺(tái)機(jī)器已經(jīng)作為一個(gè)能力宿主接入了系統(tǒng)。但它真正能做什么，還要看它對(duì)外聲明了哪些能力和命令。

例如某個(gè)節(jié)點(diǎn)可能聲明：

• caps: browser, system
• commands: browser.proxy, system.run, system.run.prepare, system.which

這表示 Gateway 不是“想給它發(fā)什么就發(fā)什么”，而是只能調(diào)用它明確聲明過的命令入口。

因此，如果某個(gè)節(jié)點(diǎn)只聲明了瀏覽器代理能力，卻沒有聲明 system.run，那它即使在線，也不具備執(zhí)行本地命令的能力。

所以這里又出現(xiàn)一個(gè)非常關(guān)鍵的判斷：

節(jié)點(diǎn)在線 ≠ 節(jié)點(diǎn)具備目標(biāo)能力。

要真正能執(zhí)行命令，還必須滿足：

• 節(jié)點(diǎn)在線；
• 節(jié)點(diǎn)已配對(duì)；
• 節(jié)點(diǎn)聲明了 system.run；
• 命令分發(fā)正確到這臺(tái)節(jié)點(diǎn)。

十四、第六層：主機(jī)審批層——這才是“能不能真的落地”的最后裁決

在前面所有層都通過后，最后仍然要回到主機(jī)本地 approvals。

這一步的意義可以總結(jié)成一句：

即使控制面通了、協(xié)議通了、角色對(duì)了、能力也存在，本地機(jī)器仍然保有最終拒絕權(quán)。

這是整套架構(gòu)最穩(wěn)的地方，也是最容易被忽略的地方。

因?yàn)樵诤芏噙h(yuǎn)程控制系統(tǒng)里，人們習(xí)慣把“控制面已經(jīng)授權(quán)”理解成“執(zhí)行面必然服從”。但 OpenClaw 這里并不是這樣的邏輯。

它保留了一條非常明確的原則：

宿主機(jī)對(duì)自己的命令執(zhí)行擁有最終同意權(quán)。

也正因?yàn)橛羞@一層，系統(tǒng)才能做到在遠(yuǎn)程調(diào)度和本地主機(jī)安全之間取得平衡。

十五、把整條鏈濃縮成一句真正準(zhǔn)確的話

如果把前面六層再壓縮成一句最準(zhǔn)確的話，那就是：

隧道層、WebSocket 層、Gateway 協(xié)議層、角色/作用域?qū)印⒐?jié)點(diǎn)能力層、主機(jī)審批層，必須一層層都通過，最后 system.run 才會(huì)真正落地執(zhí)行。

這句話看似長(zhǎng)，但它恰恰解釋了遠(yuǎn)程執(zhí)行中最常見的誤區(qū)：

• 不是“能連上”就等于“能執(zhí)行”；
• 不是“能看到節(jié)點(diǎn)”就等于“能下發(fā)命令”；
• 不是“聲明了 system.run”就等于“這臺(tái)主機(jī)愿意執(zhí)行”；
• 不是“Gateway 默認(rèn)允許”就等于“本地 approvals 會(huì)放行”。

只有把這些層分開，排障思路才會(huì)變得清晰。

十六、最容易出現(xiàn)的幾個(gè)誤區(qū)，一次講透

誤區(qū) 1：Gateway 配成host=node就等于節(jié)點(diǎn)一定能執(zhí)行

錯(cuò)誤原因在于把“調(diào)度目標(biāo)”當(dāng)成了“執(zhí)行結(jié)果”。

host=node 只能說明默認(rèn)往節(jié)點(diǎn)發(fā)，不代表本地 approvals 一定放行，也不代表節(jié)點(diǎn)一定聲明了正確能力，更不代表目標(biāo)命令一定存在。

誤區(qū) 2：system.run 自己決定權(quán)限

system.run 不是自帶無限權(quán)限的神秘接口。它只是在 node host 的宿主環(huán)境里啟動(dòng)進(jìn)程，權(quán)限邊界取決于運(yùn)行 node host 的那個(gè)本地賬戶。

誤區(qū) 3：云端安全策略能替代本地 approvals

不能。云端策略解決的是“控制面怎么發(fā)”，本地 approvals 解決的是“宿主機(jī)愿不愿意接”。這兩者不是重復(fù)關(guān)系，而是串聯(lián)關(guān)系。

誤區(qū) 4：SSH 隧道通了，遠(yuǎn)程執(zhí)行就沒問題了

SSH 隧道只解決網(wǎng)絡(luò)可達(dá)，后面還有 WebSocket、協(xié)議、角色、能力、審批等層次。

誤區(qū) 5：node.list正常，nodes run失敗一定是架構(gòu)錯(cuò)了

不一定。很多情況下更可能是：

• 節(jié)點(diǎn)命令調(diào)用鏈不穩(wěn)定；
• 能力分發(fā)存在問題；
• approvals 未命中；
• 審批 UI 缺失；
• 本地命令入口未放行或不存在。

十七、從安全設(shè)計(jì)角度看，這套機(jī)制為什么合理

如果把 OpenClaw 這套設(shè)計(jì)放到更一般的軟件架構(gòu)視角去看，會(huì)發(fā)現(xiàn)它其實(shí)非常像成熟系統(tǒng)里常見的“多層聯(lián)鎖”思想。

17.1 控制面與執(zhí)行面分離

這樣做的好處是：

• 調(diào)度邏輯集中；
• 執(zhí)行能力分布式暴露；
• 不同宿主機(jī)可以擁有不同能力與不同安全邊界；
• 節(jié)點(diǎn)側(cè)可以根據(jù)自己的風(fēng)險(xiǎn)暴露程度設(shè)置本地審批規(guī)則。

17.2 本地宿主機(jī)保有最終決定權(quán)

這避免了“遠(yuǎn)端控制面一旦出錯(cuò)，所有本地主機(jī)被一鍋端”的風(fēng)險(xiǎn)。

17.3 白名單而不是全開放

從安全角度看，遠(yuǎn)程自動(dòng)化系統(tǒng)最怕的不是“功能不夠強(qiáng)”，而是“邊界不清”。

把 system.run 收縮為少量固定入口腳本，實(shí)際上是在把“通用執(zhí)行器”改造成“受控流程觸發(fā)器”。這比直接開放一個(gè)通用 shell 要穩(wěn)得多。

17.4 多層串聯(lián)比單層放權(quán)更可審計(jì)

當(dāng)系統(tǒng)分成：

• 調(diào)度層；
• 協(xié)議層；
• 能力層；
• 審批層；
• 執(zhí)行層；

每一層都可以成為排障點(diǎn)、審計(jì)點(diǎn)、日志點(diǎn)。這對(duì)線上系統(tǒng)穩(wěn)定性和安全性都非常重要。

十八、實(shí)戰(zhàn)建議：如何把 system.run 用得既穩(wěn)又可控

如果目標(biāo)是讓 OpenClaw 在本地 Windows 節(jié)點(diǎn)上執(zhí)行自動(dòng)化流程，又不想把風(fēng)險(xiǎn)放大，比較推薦的思路不是“盡可能開放”，而是“盡可能收斂”。

18.1 不要優(yōu)先開放通用解釋器

例如不要一上來就把 PowerShell、cmd 的任意執(zhí)行能力完全放開。

因?yàn)檫@等于把 system.run 變成一個(gè)泛用遠(yuǎn)程 shell，安全邊界會(huì)非常大。

18.2 優(yōu)先只開放固定用途腳本

更好的做法是圍繞任務(wù)設(shè)計(jì)穩(wěn)定入口，例如：

paper_scan.cmd
paper_rename.cmd
paper_classify.cmd

每個(gè)腳本只干一類事，參數(shù)也盡可能收斂。這樣既方便 allowlist 管控，也方便后續(xù)擴(kuò)展自動(dòng)化流程。

18.3 把復(fù)雜邏輯放進(jìn)腳本，不要放進(jìn)遠(yuǎn)程拼接命令

讓遠(yuǎn)端只觸發(fā)入口，把真正復(fù)雜的業(yè)務(wù)邏輯固化在本地腳本里，會(huì)比遠(yuǎn)程拼接長(zhǎng)命令穩(wěn)定得多，也安全得多。

18.4 排障時(shí)一定分層看問題

不要一看到執(zhí)行失敗就只盯著 system.run。正確做法應(yīng)該是按層往下排：

1. 網(wǎng)絡(luò)層通不通；
2. WebSocket 是否已連上；
3. Gateway 是否能看到節(jié)點(diǎn)；
4. 節(jié)點(diǎn)是否已 paired / connected；
5. 節(jié)點(diǎn)是否聲明了目標(biāo) command；
6. 本地 approvals 是否命中 allowlist；
7. 目標(biāo)命令入口在宿主機(jī)上是否真實(shí)存在；
8. node host 運(yùn)行身份是否具備足夠權(quán)限。

只有這樣，問題定位才會(huì)高效。

十九、一個(gè)幫助理解的總流程圖

下面用一個(gè)簡(jiǎn)單的 ASCII 流程圖，把這整套機(jī)制串起來：

[模型 / CLI / 自動(dòng)化]
          |
          v
[Gateway 控制面]
  - 讀取 tools.exec.host
  - 讀取 tools.exec.security
  - 讀取 tools.exec.ask
  - 讀取 tools.exec.node
          |
          v
[將請(qǐng)求轉(zhuǎn)發(fā)給目標(biāo) node]
          |
          v
[node host 本機(jī)]
  - 讀取 exec-approvals.json
  - 校驗(yàn) security / ask / allowlist
          |
   通過?  |----------------------否-------------------->
          |                                          [approval required / reject]
          v
[調(diào)用 system.run]
          |
          v
[Windows 本地真實(shí)進(jìn)程啟動(dòng)]
          |
          v
[返回執(zhí)行結(jié)果]

這個(gè)圖最重要的意義，是把“誰負(fù)責(zé)什么”徹底分開：

• Gateway 負(fù)責(zé)調(diào)度與默認(rèn)策略；
• node 負(fù)責(zé)承接請(qǐng)求與暴露本機(jī)能力；
• approvals 負(fù)責(zé)主機(jī)側(cè)最終放行；
• system.run 負(fù)責(zé)真正執(zhí)行。

二十、結(jié)語：真正應(yīng)該記住的不是命令，而是判定鏈

很多人學(xué)習(xí)遠(yuǎn)程執(zhí)行系統(tǒng)時(shí)，最先關(guān)注的是命令怎么寫、端口怎么轉(zhuǎn)發(fā)、節(jié)點(diǎn)怎么配對(duì)。但從長(zhǎng)期來看，真正決定你是否能把系統(tǒng)用穩(wěn)、排障排準(zhǔn)、邊界管住的，不是這些表層操作，而是對(duì)整條執(zhí)行判定鏈的理解。

OpenClaw 這套機(jī)制的關(guān)鍵，不在于某一個(gè)點(diǎn)多么復(fù)雜，而在于它把“調(diào)度”“能力暴露”“本地審批”“真實(shí)執(zhí)行”明確拆成了不同層。

也正因?yàn)檫@種分層足夠清晰，它才具有兩個(gè)非常重要的優(yōu)點(diǎn)：

一方面，控制面可以統(tǒng)一調(diào)度云端與本地節(jié)點(diǎn)，具備良好的擴(kuò)展性；另一方面，本地宿主機(jī)又始終保有最后一道安全控制權(quán)，不會(huì)因?yàn)檫h(yuǎn)端一個(gè)配置就把執(zhí)行權(quán)完全放飛。

所以，最后只需要記住一句最核心的話：

Gateway 負(fù)責(zé)“調(diào)度和下令”，node 負(fù)責(zé)“暴露本機(jī)能力”，本地 approvals 負(fù)責(zé)“這臺(tái)機(jī)器最后是否同意執(zhí)行”，而 system.run 負(fù)責(zé)“真的把命令跑起來”。其中任意一層沒過，命令都不會(huì)真正落地。

這句話理解透了，OpenClaw 遠(yuǎn)程執(zhí)行的大部分原理和排障邏輯，基本也就通了。

附：一段最簡(jiǎn)明的總結(jié)，適合作為文章摘要或開頭導(dǎo)語

在 OpenClaw 的遠(yuǎn)程執(zhí)行架構(gòu)中，云端 Gateway 負(fù)責(zé)根據(jù) tools.exec.* 配置形成默認(rèn)執(zhí)行策略，決定請(qǐng)求原則上發(fā)往哪里、按什么安全模式處理、是否需要審批；目標(biāo) node 負(fù)責(zé)作為能力宿主接收請(qǐng)求，并在本機(jī)讀取 exec-approvals.json 做最后一道主機(jī)側(cè)判定；只有當(dāng)控制面策略與本地 approvals 同時(shí)放行后，節(jié)點(diǎn)才真正調(diào)用 system.run 在宿主機(jī)上啟動(dòng)本地進(jìn)程。因此，system.run 是最終執(zhí)行者而不是最終裁判者，SSH 隧道打通、節(jié)點(diǎn)在線、node.list 成功都不等于命令一定能落地執(zhí)行，真正的執(zhí)行鏈必須依次通過網(wǎng)絡(luò)層、WebSocket 層、Gateway 協(xié)議層、角色/作用域?qū)?、?jié)點(diǎn)能力層和主機(jī)審批層。

到此這篇關(guān)于云端 OpenClaw 遠(yuǎn)程執(zhí)行本地進(jìn)程原理機(jī)制詳解:Gateway、approvals 與 system.run 到底誰在判定、誰在執(zhí)行?的文章就介紹到這了,更多相關(guān)OpenClaw 遠(yuǎn)程執(zhí)行本地進(jìn)程內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持腳本之家！

最新評(píng)論