2026 OpenClaw 升級後「能聊天不能跑工具」：tools.profile 對照表、tools.deny 與 agent 覆寫分診 Runbook

升級後「能聊天不能跑工具」的六种常见根因（先分診再改設定）

1. tools.profile 落在 messaging / minimal：升級或向导預設收緊了工具面，表象是「会话流畅、一调 exec 就 not found」。
2. tools.deny 誤傷：为合規臨時 deny 了 exec / browser，變更单关闭後規則仍留在設定里。
3. agents.list[].tools.profile 覆寫全域：你以为改了全域，實際当前 agent 仍继承更窄的 profile。
4. 半升級導致 Gateway 未 reload：CLI 已读新設定，Gateway 行程仍按旧 allowlist 執行——與坏版本回滾里的 split-brain 同类，但未必需要回退映像。
5. 模型不具备可靠 tool-calling：弱模型把 tool call 当純文本吐出；此时改 profile 無效，应换模型或降任务复杂度。
6. 把「通道無回复」当「工具不可用」：應先走無回复分診，避免在 allowlist 层空转。

OpenClaw 的工具面不是「装了就全开」，而是由全域 profile → deny 列表 → agent 级覆寫三层疊加出的有效集合。2026 上游文档将 tools.profile 定義为基線 allowlist：minimal 僅保留会话狀态类能力；messaging 偏通道與 session；coding 覆寫文件系统、執行时、web、sessions、memory 等工程向工具；full 不做額外限制。許多團隊在升級後第一次踩坑，並不是 Gateway 掛了，而是設定契約从「預設可用」收緊为「顯式放行」，而變更单里没有写「改完必須 restart + 最小探針」——于是 on-call 在聊天視窗里反覆試同一句 prompt，浪費整整一个發布視窗。

若 Gateway 跑在会睡眠的個人筆電上，你还可能疊加「改完設定但 launchd/容器未 reload」的假象；把權威 Gateway 放在常電、獨占、可寫進工單的遠端 Mac 上，再用SSH 本地轉發访问 Control UI，能把「設定變更面」與「终端雜訊面」拆開，下文驗證階梯会強調必須在 Gateway 侧驗收，而不是只看 CLI 列印 success。

tools.profile 四維對照：該用 coding 还是 full？

实务上大多数自動化與研發向 Agent 应落在 coding：它覆寫文件讀寫、shell、web 擷取、session 與 memory 等能力，又比 full 更容易做安全评审。只有在你明确需要「不額外裁剪工具面」且已有配套稽核时，才考虑 full。messaging 適合純客服式轉發；minimal 只適合只要狀态、不要碰文件系统的场景。與Agents / Skills / memory_search 调优同读时，请把「工具面」與「上下文上限」放在同一變更单——否則会出現 memory 能搜、但 read 被 profile 挡住的半設定狀态。

从机制上看，Gateway 在会话启动时会根据設定解析出有效工具注册表，再交给模型做 tool-calling；若注册表里没有 exec，模型即使「想」调用也会被執行时拒绝，或在弱模型上退化为把调用意图列印成文本。这也是為何社区里「升級後突然只能聊天」的帖子，十有八九最終落在 profile 或 deny，而不是通道 token——但排查順序仍應先排除無回复，再進入本篇，以免在错误层浪費时间。

tools.deny 與 agent 覆寫：三层疊加的检查順序

推薦固定順序，避免 on-call 在三层之间跳步：①读執行中 Gateway 報告的有效 profile（或等价匯出）→ ②查 tools.deny → ③查当前 agent 的 agents.list[].tools.profile → ④再动全域 config。若你刚做过發行通道升級，请先在變更单里確認「是否附帶預設 profile 遷移」；需要回退映像时仍应走坏版本回滾，而不是無限堆 profile 試錯。

在多 agent 團隊里，常见事故是「全域已改成 coding，但正式 bot 仍綁定旧 agent 條目里的 messaging」。建议在工單里强制填寫被测 agent 名稱與觸發通道，并在驗收时分別對 CLI 直聊與 Telegram/Slack 各跑一次最小探針——两者走的会话路由可能不同。若 deny 列表來自安全團隊的臨時加固，请同時記錄到期时间與負責人，否則三个月後沒人記得為何 browser 被禁，只能再次從零排查。

六步「profile 對齐—重新啟動—探針驗收」Runbook

1. 凍結證據：儲存 openclaw --version、当前 tools.profile 與 agent 列表摘要、以及一次失敗對话的請求 id（若有）。
2. 症狀歸類：用上表判斷是 profile、deny、agent 还是模型层；若是「無回复」，停止本篇流程。
3. 設定目標 profile：研發自動化優先 coding；改前在工單寫明理由與回滾值。
4. 套用設定并重新啟動 Gateway：本機 openclaw gateway restart；Docker 用 docker compose restart 或等价，確保只有一個權威 Gateway。
5. 驗證階梯：openclaw doctor → openclaw gateway status → 最小非破壞探針（只读 read 或小範圍 exec echo）→ 若已接通道再跑 channels status --probe。
6. 留痕與防復發：把「升級後預設 profile」寫入 ROLLBACK.md / 內部 runbook；與钉版矩阵聯動，避免下次升級再次收緊卻不通知。

# 證據與對齐（字段以你们环境为准）
openclaw --version
openclaw config get tools.profile 2>/dev/null || true

# 常见修复路徑（改前请备份設定）
openclaw config set tools.profile coding
openclaw gateway restart

openclaw doctor
openclaw gateway status
# 最小探針：在 Control UI 或 CLI 觸發一次只读 read / 無害 exec

三條应寫進值班手冊的量化口徑

• 「chat-only 误報」占比：每週被標為「工具壞了」的工單中，最終根因为 tools.profile / deny / agent 覆寫的比例；若連續兩週 >40%，說明升級檢查表未包含 profile 驗收。
• 從改 profile 到探針全綠的分鐘数：小團隊建议中位數 ≤10 分鐘；若經常 >30 分鐘，多半是未統一 Gateway reload 路徑或 Docker/本機雙 Gateway。
• 重新啟動後仍失敗且進入回滾的比率：若 >15%，应並行排查模型能力與版本回歸，而不是繼續疊加 profile 變更。

这三條指标的目的，是把「能聊天」與「能跑工具」拆成可觀測事件。它们也適用於遠端常駐 Gateway：当你在六國節點上同時跑建置與 Agent 时，请在變更視窗避開磁碟與 CPU 峰值，否則探針失敗会被誤判为 profile 问题。

與 FinOps 視角的關聯在于：許多團隊会为「試 OpenClaw」买短租節點，卻在 profile 預設值上省不下时间——结果在租期最後一天才發現工具面被收緊，白白浪費驗收視窗。更穩妥的做法是：在 POC 第一天就把目標 profile、deny 空集、agent 覆寫策略寫進驗收清單，并與POC 扩容 KPI 矩阵里的「首日绿建置/绿 Gateway」並列，而不是把 Agent 當成聊天玩具單獨驗收。

收束：別把 allowlist 當成「玄學開關」

替代做法——在聊天里反覆换 prompt、或不經 restart 地多次改設定文件——能偶爾「碰對」，但不可稽核、不可在第二台機器復現，也無法向安全團隊解釋當時 Agent 實際擁有哪些工具權限。相對地，把 Gateway 放在常電、獨占、變更可工單化的遠端 Mac 上，用文件化的 profile 預設值 + 驗證階梯，能把 MTTR 从「一整晚試 prompt」壓到「十分鐘內可復盤」。

若你仍堅持在筆電上追新，至少要接受三項隱性成本：睡眠導致 Gateway 假死、合蓋後 reload 未生效、以及多人協作时「每人一份不同的 profile 口頭約定」。對需要7×24、可稽核、與團隊 CI 變更節奏對齐的 OpenClaw 正式 Agent，把环境落在 MACCOME 提供的 Mac mini（M4 / M4 Pro）與六國彈性租期上，通常比在個人裝置上與電源策略搏鬥更省总擁有成本；公開檔位可先對照多地區節點與租期指南，再與 SSH 轉發 Runbook 串聯拓撲。