痛點拆解：不是模型「變笨」，而是系統提示裡根本沒有可執行清單
痛點 1：能力口述化。維運把「怎麼發版、怎麼查日誌」寫在群組公告裡，模型在會話內看不到版本化清單，於是每一輪都重新發明流程，耗時且易與真實 runbook 衝突。
痛點 2：長對話漂移。沒有結構化 CONTEXT 時，後續輪次會稀釋早期約束；代理看似「忘記」禁止操作，實為上下文視窗與摘要策略下的資訊遺失。
痛點 3：改 JSON 不重啟。Skills 與部分外掛路徑在執行期快取；只改磁碟檔案不冷重啟閘道，會與 MCP 子程序殘留疊加，表現為「設定寫了但工具清單不變」。
痛點 4：通道無回應誤判為模型問題。實際卡在 pairing、webhook 或代理層；若跳過 閘道分層排查去改 Skills，只會南轅北轍。
痛點 5：Skills 與權限混為一談。Skills 描述意圖與步驟；workspaceAccess 與 shell 畫像決定能否真的寫入磁碟。缺一層都會出現「說得頭頭是道但工具拒絕」或「工具過強但描述缺漏」。
痛點 6：目錄掛載延遲。技能樹若放在慢速掛載，冷啟動掃描會拉長首次回覆；遠端建置節點宜本機 SSD 再加 rsync／SFTP 快照。
Skills 與結構化 CONTEXT：和純最小權限文互補的兩塊拼圖
最小權限回答「允許觸碰的磁碟邊界」；Skills 回答「在邊界內建議的操作序列與術語」。CONTEXT 檔則提供穩定短約束：專案代號、環境別名、簽核入口、常用指令範本，避免把十萬字手冊塞進 system 提示。
發現機制應可稽核：技能目錄、命名規範、與發布分支的對應關係要寫進內部文件；變更走審核，與 反向代理與 TLS 設定同級對待。
與 sessions_spawn 與 allowAgents 併用時，Skills 裡應寫明「何時才允許 spawn」，否則並發子代理會放大漂移。
需要上網檢索時，把 web_search 提供方與出站邊界寫進同一維運表，避免 Skills 描述與網路政策打架。
可量化基線：用多條指標判斷「上下文工程」是否生效
統計每百輪對話中「重複詢問已寫在 CONTEXT 的欄位」次數，目標逐月下降。記錄 Skills 呼叫成功率與失敗原因標籤：未發現、參數不全、權限拒絕、通道錯誤應分開。
把冷重啟次數與設定變更工單綁定；無工單卻頻繁重啟往往意味快取或子程序洩漏。監控閘道啟動到首次成功回覆的耗時，異常上升常與技能掃描路徑過大有關。
為高風險操作保留 HITL 命中率與人工駁回率，Skills 應引用相同工單編號規則。
決策矩陣：僅靠 system 提示、僅 Skills，或 Skills+CONTEXT+權限三聯
| 模式 | 適用 | 收益 | 風險 |
|---|---|---|---|
| 超長 system 提示 | 個人試用 | 寫得快 | 難維護、易漂移、難稽核 |
| 僅 Skills 無 CONTEXT | 工具多、流程少 | 可發現工具 | 邊界與術語仍分散 |
| Skills + CONTEXT | 團隊生產 | 可版本化、可審核 | 需規定目錄與命名 |
| 三聯 + doctor 階梯 | 遠端 Mac 7×24 | 排障可重現 | 維運表更厚 |
選定一列作為預設，把例外情境記在 runbook，而不是讓每位工程師私藏一份「我的提示詞」。
實作步驟與設定片段（欄位名隨版本演進，僅示意骨架）
{
"workspaceAccess": { "root": "/var/openclaw/work/acme" },
"skills": {
"searchPaths": ["/var/openclaw/skills/team", "/var/openclaw/skills/shared"],
"manifest": "/var/openclaw/skills/manifest.json"
},
"contextFiles": [
"/var/openclaw/context/PROJECT.md",
"/var/openclaw/context/BOUNDARIES.md"
]
}
步驟一 在儲存庫或設定庫中定義技能目錄與 CONTEXT 範本。步驟二 在測試閘道載入後執行 openclaw doctor，對照 維運文。步驟三 完整冷重啟並驗證工具清單與技能中繼資料一致。步驟四 用合成對話探測「應引用 Skills」與「應拒絕越權路徑」兩類案例。步驟五 將工作區目錄納入與建置產物相同的 rsync／SFTP 快照策略，減少多機漂移。
強相關 CTA 與閱讀順序
建議順序：閘道 doctor → MCP 冷重啟 → 本文 Skills／CONTEXT → workspaceAccess → web_search → HITL → 反向代理 → 首頁 了解託管節點。
把「技能版本、CONTEXT 雜湊、閘道映像版本」寫進同一則發布註解，回滾時才能三元對齊。
FAQ 與為何用 SFTPMAC 穩定遠端 Mac 工作區
Skills 能取代程式碼審查嗎？
不能。Skills 是執行期指南，敏感邏輯仍應在儲存庫與流水線裡受控。
多台閘道如何同步 Skills？
用快照化目錄與固定標籤發布；避免每台機器手工 scp 不同版本。
CONTEXT 應放在產品儲存庫嗎？
產品事實常與程式並存；營運邊界可放在權限較緊的維運儲存庫，分層治理。
總結：Skills 與 CONTEXT 把「代理能做什麼」從聊天裡抽出來，變成可發現、可審核、可與 doctor 對齊的資產。
局限：自建遠端 Mac 須自行維護磁碟、權限與同步節奏；若希望Apple 原生環境＋可預期的 SFTP／rsync 工作區交付，減少手工複製技能樹與上下文漂移，SFTPMAC 託管遠端 Mac 讓團隊把精力放在技能內容與閘道策略，而不是反覆對齊多台機器上的目錄樹。
穩定工作區目錄與閘道設定一併版本化，託管環境更易做到技能與 CONTEXT 的可重複發布。