Day 21｜跨機器的執行者：同一套規則搬到另一台

Day 20 停在一句話：我不在的時候，連驗的人都沒有。今天接住「沒有人在」這個前提往下走——人可以不在，但規則總該在。我原本以為這件事早就有保證：本機和隔離環境（也就是標題說的另一台）用的是同一份啟動腳本、同一份設定基準還原，每次啟動都重套一遍。回頭查才發現，同一份規則換一個執行環境，有一部分防線根本沒被掛上去。不是被繞過，是從來沒上去過。原因不在規則寫錯，而在那個環境的設定目錄，吃的不是同一份基準。

事故：以為套上了，其實套錯了

先講這份基準做了什麼。啟動腳本裡的設定基準還原共有 5 段（2026-09-27 重查）：從基座把設定檔還原回來；強制寫回一組固定的設定鍵；把權限模式固定成同一個值；把 hook 腳本同步進設定目錄；最後同步 slash command 與 subagent 定義。每一個設定目錄、每一次啟動，都跑同一套。

這個設計有一個沒寫出來的前提：它假設設定目錄所在的地方，就是寫這份基準的那台宿主。hook 登記寫的是宿主上的絕對路徑；那幾支 hook 要讀寫紀錄資料庫、自製記憶系統、推播、session 目錄，全是宿主上才有的東西。

隔離環境也有自己的設定目錄，而且同樣由這支啟動腳本準備。於是在 2026-09-23 之前，它至少有一次拿到的是通用那一份。現在腳本裡留著一段防再犯註解，寫明隔離環境的設定目錄一律改走專屬基準，禁止寫入宿主的 hook 登記（其中含宿主專屬的絕對路徑，在隔離環境內不存在）與較高的推理強度設定，並註明 9 月 21 日曾經誤套過。

這段是文件上的宣稱，不是我這輪重現出來的。我能確定的只有：誤套這件事存在，而且被記錄下來了。發生過幾次、有沒有造成後果，紀錄裡沒有，我不推算。

但光看機制就夠了。被誤套的設定表面上是完整的：hook 登記了、權限模式設了、推理強度也設了。可是登記上去的 hook 指向一條在隔離環境裡不存在的路徑。對那裡面的執行者來說，這條防線在設定檔上存在，在執行時不存在。照機制推，它也不會擋下啟動：工作照跑，只是該落下的那一刀沒落下。

這就是開頭那個矛盾的答案：規則是同一份，套用它的地方換了，規則自己不知道。

證據：兩條同步路徑，一個斷點

2026-09-27 我把工具鏈裡相關的三個檔案重查一遍，以下的查得數字都出自這一天。現在的基準函式一開頭多了一道判斷：這個設定目錄是不是屬於隔離環境的帳號？是的話，就整個改走隔離環境專屬基準，不再套通用那一份。

左邊是本機設定目錄，5 段基準完整套上；右邊是隔離環境設定目錄。虛線是 2026-09-23 之前的舊路徑：通用基準直接寫進去，hook 登記指向不存在的宿主路徑，這就是斷點。實線是加上分岔之後的新路徑。

專屬基準裡，允許進入隔離環境的 hook 被寫死成一份清單，只有 1 支：危險指令攔截 hook。其餘依賴紀錄資料庫、記憶系統、推播、session 目錄的 hook，一律不進去。渲染出來的清單如果剛好是空的，函式直接判失敗，不會寫出一份「沒有攔截層」的設定。

這裡要老實收斂：查得到的是「1 支攔截 hook 進得去、其餘全部不進去」這個結構性事實，不是比例。宿主上總共幾支 hook，本輪沒有算成分母，所以不寫百分比。

左欄是本機執行者：宿主上的各種 hook 與它們依賴的資料都在。右欄是隔離環境執行者：只掛進 2 條目錄、只有 1 支 hook。中間那一列是左邊有、右邊看不到的東西。

隔離環境啟動時只掛兩條目錄：暫存工作區與設定目錄，沒有第三條。宿主上的紀錄資料庫、記憶系統、session 目錄，從裡面看出去根本不存在。那幾支 hook 進不去的真正原因就在這：掛了也沒東西可接。

還有一個不利的口徑要揭露。這篇原本想比「另一台實體機器」和本機的差異，但工具鏈檔案談的都是隔離環境，找不到任何實體機器的對照數字。所以本篇講的是機制：同一份基準對兩種執行環境套用方式不同，不是實體機器層級的實測差異。

解法：規則分兩份，工作先分流

修法有三層。

第一層是分岔本身。與其讓一份基準猜自己身在何處，不如讓啟動腳本在入口先認環境：隔離環境走專屬那一份，hook 路徑改寫成隔離環境內部的路徑。規則從「一份到處套」，變成「兩份各自對得上」。

第二層是允許清單加失敗保護。專屬基準只放行明確列出的 hook，清單為空就拒絕寫出設定。這把原本那種靜默失效整個反過來：寧可啟動失敗讓我看見，也不要啟動成功卻沒有攔截層。

第三層放在派工端，決定哪些工作根本不該離開本機。把檔案送進隔離環境的工具有一份保護清單，檔案共 26 行，扣掉註解與空行後剩 20 行實際條目，每一條是一個路徑樣式；派工閘不讀它，比對的是寫死在閘裡的另一份較短清單。兩份的條目內容我都不列出。派工內容只要命中閘裡那份清單，或命中瀏覽器操作類的關鍵字，就判定留在本機、放行；其餘三種等級的執行者一律擋下，導去外包流程。放行和擋下兩種結果都會記錄，只有「這個功能沒開」與「不是受管的執行者類型」兩種情況不記。

我對這套設計的讀法是：碰得到敏感路徑的工作，留在規則掛得齊的地方做；規則掛不齊的地方，只接碰不到敏感路徑的工作。規則沒辦法對等搬過去，那就讓工作先分流。

新問題：掛不上去的規則，只能換成看不見

這一輪查完，我對「同一套規則」的理解變了。以前我以為規則是一份檔案，複製到哪裡就在哪裡生效。現在我知道，規則是檔案加上它依賴的環境：hook 要有路徑，要有資料庫可寫，要有記憶系統可讀。環境一換，同一份檔案要嘛靜默失效，要嘛根本不該被套上去。

所以隔離環境裡的執行者規則比本機少，這是刻意的。少掉的那些防線補不回來，能做的只剩另一個方向：既然管不齊它做什麼，就限制它看得到什麼——只掛兩條目錄，只接不碰敏感路徑的工作。

但這又把問題推回 Day 20。看得到的範圍縮小了，出事時身邊也沒有人。隔離環境裡的執行者碰到拿不定主意的事，它能問誰？

明日預告：Day 22｜無人值守：沒有人可以問的時候