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 串联拓扑。