B 案生死驗證：WSL2＋docker engine 撐不撐得住無人登入

🔴 本文件記錄「B 案能不能成立」，不是「客戶要這樣裝」。 探路階段允許權宜手段 （改埠避開既有 agent、SSH 遠端下指令、手寫 .env）；權宜處一律標示 ⚠️探路權宜， 與「結論」分開寫。體例沿用 t71-windows-probe.md。

對應：design.md D18（B 案否決的理由之一是「常駐機制未驗」——本卡即為補驗）、 D17（Docker Desktop 路線）、t71-windows-probe.md §8（A 案登出全滅 P0）。

一句話判定：B 案不可行——WSL VM 的生命週期由 Windows 側常駐進程決定，而「Windows 側常駐進程」正是無人登入場景所缺的那樣東西，因此 B 並未繞開 A 的死穴，只是把「需要有人登入」換成「需要一個永不結束的 Windows 側進程」，而工作排程器（跑完即結束的模型）給不了它。

1.1 現場既有狀態（開工前盤點）

1.2 🆕 WSL distro 是 per-user 註冊（B 案佈建的第一個結構事實）

以 Administrator 身分執行 wsl -l -v 回沒有任何 distro，但 raymond 有兩個。 查註冊表證實 distro 掛在各使用者 SID 下：

HKEY_USERS\S-1-5-21-…-1101\…\Lxss   → docker-desktop, Ubuntu   （raymond）
HKEY_USERS\S-1-5-21-…-500\…\Lxss    → （空，Administrator）

意義：B 案的 distro 必須註冊在「執行排程工作的那個帳戶」名下；換帳戶跑就看不到它。 這也順帶保證了本次探路的隔離性——新開的 guidant-wsl 在 Administrator 名下， raymond 的 Docker Desktop 兩個 distro 全程未被觸碰。

1.3 佈建步驟與耗時（皆一次成功，無擋路項）

⚠️ 對日後任何 WSL 路線的規格輸入：交付包放在 Windows 檔案系統（/mnt/c）時 docker load 明顯變慢；若真要走 WSL 路線，應先把 tar 複製進 distro 的 ext4（/root 之類）再 load。

1.4 ⚠️探路權宜：與既有 agent 並存的處置

160 上已有 Docker Desktop 版 agent 佔用 8443，且其 .env 指向 https://192.168.50.191 （guidant-ai-prd-01，非 T-7.1 記載的 188——該設定在 T-7.1 之後被改過）。 本卡未動那份設定、未動那組容器，改為：

• 另開安裝目錄 C:\t74\b（.env + docker-compose.yml + certs-in/）
• 埠位移：資料面 9443（原 8443）、SeaweedFS 28333/28888/29333
• 雲端指向 188 DEV（.env、CA 與註冊 token 取自 188 上 /tmp/t66-final/ 的既有安裝）
• AGENT_HOSTNAME=WIN160-WSL-B（雲端可一眼分辨是哪一路線）

1.5 佈建結果（①的驗收證據）

INFO:agent:device_uuid computed: 5bd79796b9b2b1687fff565af29ca46cb1a00862b7f5a7a7d7e8195ef40ed0ed
INFO:agent:agent enrolled: agent_uid=642f815e-a3c8-4ee6-9863-f6c347fe2875 heartbeat=300s
INFO:agent:data-plane mTLS listening on 0.0.0.0:8443 (client certificate required)
INFO:agent:agent auth ready (mode=full, status=active, ...)
[integrity] 完整性驗證通過（114 個檔案，版本 0.2.28，kid 04b1e65f100c6c8f）

雲端 188 DEV（guidant_ai.compliance.remote_agents）：

 id |     name     |          base_url           |        fp        | status
  8 | WIN160-WSL-B | https://192.168.50.160:9443 | 5bd79796b9b2b168 | active

✅ ①結論：docker engine on WSL2 這條路，安裝面完全走得通， 且 agent 對 engine 與對 Docker Desktop 沒有任何行為差異（防竄改驗章、enroll、mTLS 全正常）。

2.1 第一層：SYSTEM 帳戶排程 —— 被 WSL 硬拒

卡片設計的做法是「工作排程器（SYSTEM 帳戶、不論使用者是否登入、開機觸發）」。 實測以 SYSTEM 身分執行 wsl.exe：

Running WSL as local system is not supported.

Error code: Wsl/WSL_E_LOCAL_SYSTEM_NOT_SUPPORTED

wsl -l -v、wsl --status 皆同一錯誤。

這不是權限沒調好或環境沒裝好，是 WSL 明文不支援 LOCAL SYSTEM。 卡片寫的那個做法不存在可行版本，必須換帳戶模型。

2.2 第二層：S4U 具名帳戶排程 —— 可以跑 wsl.exe

改用 Register-ScheduledTask 搭 S4U（Service-for-User，不需存密碼）：

$p = New-ScheduledTaskPrincipal -UserId 'JEDICOGY\administrator' -LogonType S4U -RunLevel Highest

實測結果（工作內容印出自身身分）：

whoami: jedicogy\administrator
sessionid: 0
--- wsl --status ---   Default Version: 2      ← 有回應，不再被拒

✅ 這一層通了：具名帳戶＋S4U＋session 0，可以在無互動 session 的情況下呼叫 wsl.exe。 （附註：schtasks /RU <user> /NP 這種寫法在 Server 2025 上被拒；要用 PowerShell 的 New-ScheduledTaskPrincipal -LogonType S4U。）

2.3 🔴 第三層：WSL VM 閒置自關 —— B 案死在這裡

排程能跑 wsl.exe 之後，容器也確實被拉起來了。但放著不管，agent 就沒了。

2.3.1 先講一個差點造成誤判的陷阱（觀察者效應）

最初我用 wsl -d guidant-wsl -- docker ps 反覆檢查，每次都看到容器 Up， 看起來一切正常。露餡的是 uptime：每次查詢它都從 0 重新算。

wsl.exe 只要被呼叫就會把 distro 喚醒（resume/boot）。 因此任何用 wsl.exe 做的健康檢查，都會把「已經死掉」變成「看起來活著」。

改用不碰 distro 的觀測面（Windows 側 wsl -l --running ＋ 雲端 DB 心跳）之後， 真相才出來。

2.3.2 無干擾觀測的實測結果

distro 在無人使用約 60 秒後自行停止（WSL 預設 vmIdleTimeout 即 60000ms）。 agent 隨之離線——restart: unless-stopped 與 systemctl enable docker 都救不了， 因為死的不是容器、也不是 docker daemon，是承載它們的整個 distro。

2.3.3 🔴 更精確的機制：不是「關機」，是 userspace 被凍結

進一步解剖（在 anchor 測試失敗後、resume 當下取證）：

dmesg 佐證（[438s] ＝ 00:14:34，即 resume 時刻）：

WSL (2 - init-systemd(guidant-wsl)) ERROR: WaitForBootProcess:3488:
      /sbin/init failed to start within 10000ms

結論：WSL 把 distro 的 userspace 整個凍結/收掉（kernel 與 VM 外殼保留）， 裡面沒有任何一層還醒著能自救——docker daemon 自己也被凍結了。 這比單純「關機」更棘手：關機至少可以靠「開機自起」補救，凍結則是連自起的那個東西也被凍住。

2.4 四種挽救手段，全部實測無效

手段 4 失敗的原因，正是本案最核心的結構問題： 放在 distro 裡面的東西，無法阻止 distro 被凍結——它跟著一起被凍。

2.4.1 反證測試：排除「是 S4U 排程設定造成的」這個替代解釋

手段 4 的 anchor 原本由 S4U 排程啟動，因此需排除一個可能： 會不會是排程工作結束時把 distro 一起收掉了（而非 WSL 本質行為）？

實測：停掉 watchdog，改從 SSH session（非排程）啟動同一支 anchor，只用無干擾觀測面看心跳。

事後檢查：wsl -l --running = 無執行中發行版；SSH 啟動的那支 anchor 進程同樣消失 （Windows 側只剩 Docker Desktop 於 14:49 啟動的 4 個 wsl.exe）。

✅ 反證成立：換一個啟動者（SSH session 取代 S4U 排程）結果完全相同， 死因是 WSL 的 VM 生命週期本身，不是排程工作的 context。

2.5 最後一搏：1 分鐘外部 watchdog —— 機制可行，但那不叫常駐

改成 S4U 排程每分鐘跑一次，主動偵測並復活（偵測 distro/anchor 狀態 → 重拉 → 補 portproxy）。 機制本身正確運作，但 boot.log 揭露了真相——每一個 tick 都報告「已經死了」：

00:16:32  distro running: False   anchor alive: False → anchor (re)launched → stack 回來
00:17:33  distro running: False   anchor alive: False → anchor (re)launched → stack 回來

即 distro 撐不過每次 tick 之間的不到 60 秒空檔。

⚠️ 這不是「常駐」，是「每分鐘重開機一次」。 後果：

• agent 每分鐘經歷一次容器停／起，心跳不連續
• 執行中的檢測任務會被腰斬（CINC/nmap 掃描動輒數分鐘）
• SQLite 與上傳中的證據檔在反覆硬停下有損毀風險
• 雲端顯示的 active 是假象——是被 watchdog 戳出來的，不是它自己活著

2.6 對照組：為什麼 Docker Desktop 的 distro 撐得住？

同一台機器上，raymond 的 Docker Desktop VM 從 14:49 活到隔日 00:20（約 10 小時）未死， 而 B 的 distro 撐不過 60 秒。差別不在 WSL 設定，而在：

Docker Desktop 有 com.docker.backend——一個 Windows 使用者態的常駐進程（實測 7 個進程）， 持續與 VM 通訊，所以 VM 一直「忙著」。B 案沒有這種 Windows 側常駐元件： 工作排程器是「跑完就結束」的模型。

這一點把 A 與 B 的死因統一了：兩者其實是同一個結構事實的兩面—— WSL VM 需要一個 Windows 使用者態的常駐看護，而「Windows 使用者態常駐」與「無人登入」本質衝突。 B 案並沒有繞開 A 的死穴，只是把「需要 Docker Desktop 且需要有人登入」 換成「需要一個永不結束的 Windows 側進程」——而排程器給不了它。

根因：WSL2 NAT 模式只做 localhost 轉送，不會把容器埠曝露到 LAN 介面。 這與 T-7.1 §5.1 的 Docker Desktop 行為（自動綁 0.0.0.0、Windows 側看得到 listener） 明確不同——B 在此退步。

3.1 兩條解法實測

portproxy 生效後（另加一條 inbound 防火牆規則 Guidant AI Agent B-case (9443)）：

188 → nc -z 192.168.50.160 9443     → OPEN
188 → openssl s_client               → CONNECTION ESTABLISHED, TLSv1.3
   peer cert CN = 5bd79796…（＝agent 指紋）
   issuer   CN = Guidant Agent CA (onprem-188)

3.2 ⚠️ portproxy 的維運代價（若日後任何 WSL 路線復活，這是硬規格）

WSL 的 eth0 是 DHCP（本次 172.31.22.105/20），每次 distro 啟動可能換 IP， 而 portproxy 規則寫死了目標 IP → 規則會靜默失效（TCP 連到黑洞，症狀是「雲端連不上但本機看起來正常」）。 因此安裝程式必須每次開機重算並更新規則（本次 watchdog 腳本已內建此邏輯並實測可運作）。

與 A 案對照：兩者都不是 Windows 主機身分—— A 綁在 docker_data.vhdx（machine-id 650cb79d…），B 綁在 guidant-wsl distro 的 vhdx。 漂移條件：wsl --unregister 後重 import 必然換一顆 machine-id，等同 A 的 factory reset。

⚠️ wsl --unregister 漂移未實機執行：該操作會摧毀現場，而②已判死， 保留現場的價值高於補一個可從機制上確定的結論（machine-id 由 import 時生成，重 import 必變）。 此項標記為推定、未實測。

1. 登出／冷重開機不登入（原驗證清單②的後兩個情境）——未執行。 理由：②已在更前面的一層判死（閒置 60 秒即凍結，比「登出才死」嚴重得多）， 且該兩項會中斷決策者的 RDP session／使機器離線數分鐘，成本高而不會改變結論。 ⚠️ 嚴格說，「冷重開機後排程器能否拉起」仍是未證項；但即使能拉起， 拉起後也只會回到 §2.5 的「每分鐘重開機一次」狀態。
2. Windows Update 等級重開機的韌性（原⑤）——同上，未測。
3. wsl --unregister 指紋漂移——推定必變，未實機執行（見 §4）。
4. 把 anchor 包成 Windows 服務（WinSW/NSSM）——未測，理由見 §8.2。
5. 派檢測任務端到端——未做。②判死後，端到端只能證明「戳醒時能用」，不能證明常駐。
6. B 在真正乾淨機（無 Docker Desktop）上的行為——本次是與 DD 並存的環境； 推定 WSL 生命週期行為一致（與 DD 無關），未驗。

8.1 判定

🔴 B 案（WSL2＋docker engine＋工作排程器常駐）不可行。

依據：無人值守常駐是本案的存在理由（B 相對 A 的唯一賣點就是解 A 的登出全滅 P0）。 實測顯示 B 不但沒解掉，還把問題惡化——A 至少在有人登入時能穩定長跑（DD 的 VM 實測 10 小時未死）， B 則是閒置 60 秒就凍結，只能靠外部 watchdog 每分鐘復活一次， 代價是心跳不連續、長時間檢測任務會被腰斬。

8.2 唯一未測的殘存候選，以及為何不建議追下去

理論上還剩一招：把「握著 distro 的那隻手」做成 Windows 側常駐服務 （用 WinSW/NSSM 把 wsl.exe -d guidant-wsl -- sleep infinity 包成 Windows Service）， 結構上模仿 Docker Desktop 的 com.docker.backend。這有機會成立（未測）。

但即使成立，也不建議：

1. 它要用的正是 FR-066.8（T-8.3）的 WinSW 工——同一份服務化工程投入， B 換來的是 Windows 服務 → wsl.exe → WSL VM → systemd → docker → 容器（六層）， 原生版換來的是 Windows 服務 → agent.exe（兩層）。
2. 六層各有自己的失效模式與觀測面（本卡已示範：光是判斷「它到底活著沒有」就有觀察者效應陷阱）， 查修成本高，且這些成本對原生版零複用。
3. 網路仍需 portproxy＋每次開機重算 IP；指紋仍是 VM 值；封閉網路還要額外備 rootfs。

這與 D18 當初否決 B 的理由（「常駐機制未驗、四層架構查修成本高、指紋仍是 VM 值、對原生版零複用」） 完全一致——本卡把其中「未驗」那一項補成了「已驗且失敗」。

8.3 對 D18 的回饋

D18 是在「B 案常駐機制未驗」的前提下做的裁示。本卡結論支持並強化該裁示：

• D18 對 B 的判斷正確，且理由可從「推測」升級為「實測」。
• 建議在 design.md D18 的「①②③④被排除選項」處，把 B 的排除理由補一句 「常駐機制經 T-7.4 實測否證（CM-1346）」並指向本文件。
• A（Docker Desktop）作為 demo/PoC 限定的定位不變且更站得住： A 在有人登入時穩定（實測 10 小時），B 連這點都做不到。

8.4 若首腦仍決定立 B 案，工作清單修正建議

（本節僅為完整性；以本卡結論不建議立案。若仍要立，下列為必要而非充分條件。）

判斷 WSL 上的常駐性，不能用 wsl.exe 觀察——它會把 distro 喚醒， 把「已經死了」變成「看起來活著」。

可用的無干擾觀測面：

同一個陷阱在本卡出現兩次（先誤判 distro 活著、後誤判 anchor 有效）， 兩次都是靠「換一個不碰它的觀測面」才看破。

🔴 未動的東西（確認清單）：raymond 的 Ubuntu／docker-desktop distro、 Docker Desktop 本體與其容器、C:\onepack\ 內容、8443 那條防火牆規則、 191／STG／POC 任何環境（全程只讀 188 DEV，寫入僅 agent 自行 enroll 產生的 id=8 一筆）。