ManClaw logo
OpenClaw Best Practices
ManClaw 最佳实践
返回首页
Question To Action

从问题定位，直接进入治理动作。

这页不把最佳实践按功能平铺，而是按真实运行中最常见的治理问题组织。先找到你遇到的问题，再跳到对应动作、影响范围、推荐顺序和应该进入的页面。

问题导航 对应真实功能 治理顺序 页面入口
查看问题导航 查看方法论页

这一页帮你先判断什么

重点不是解释页面，而是先帮你判断当前问题更接近哪一类治理动作：

  • 这类问题更像是配置关系没看清，还是运行时上下文没收住
  • 现在应该去收紧 Tools / 技能、清 Session，还是迁移 Model ID
  • 遇到多 Agent、多 channel、多 workspace 时，优先核对哪一层关系
先找问题类型 不要先猜某个页面“可能有用”，先确认是配置关系、上下文残留、模型升级还是能力暴露问题。
再进具体页面 每个问题都会指向对应的 Best Practices、Agents、Channels、Skills 或 Models 页面，减少来回切页试错。
最后验证影响面 治理动作不是独立按钮，而是会影响 session、bindings、workspace 和能力暴露的真实变更。
Problem 01

为什么 Token 消耗还是很高？

最常见的原因不是模型本身贵，而是运行环境还没收住。很多系统默认只用 main Agent，所有 Tools、技能和上下文都让同一个 Agent 处理，结果一次请求会把太多不必要的信息带进来。

对应动作：按 Agent 收紧能力 对应页面：Agents / Skills / Plugins
常见信号 一个 Agent 同时挂了过多 Tools、技能和上下文，普通请求也会带出大量不相关能力说明。
推荐顺序 先看 Agent 职责，再看 Skills / Plugins 暴露，最后再判断是否需要拆分 Agent 或收紧默认能力。

先看什么

先确认是不是所有能力都默认挂在一个 Agent 身上，再看哪些 Tools 和技能其实不属于当前场景。

怎么处理

把“默认全开”改成“按职责放权”，先让 Agent 在最小能力集下工作，再按场景逐步增加 Tools 和技能。

Problem 02

为什么禁用能力后行为还是像旧的？

如果你已经禁用了插件、Tools 和技能，但请求体和行为还像旧的，问题往往已经不只是配置，而是旧 session 还在继续污染上下文。

对应动作：Session Cleanup 对应页面：Best Practices
常见信号 配置已经改了，但回复方式、调用习惯或工具选择仍然像旧版本，尤其常见于模型或技能刚切换之后。
推荐顺序 先确认这次改动是否真的落库，再清 Session，再观察下一轮请求是否回到新的配置边界。

先看什么

确认这次改动是否涉及模型、workspace、skills、Tools、bindings 或历史配置恢复。如果涉及，优先考虑清一次 Session。

怎么处理

在 Best Practices 页直接查看各 Agent 的 session store、会话数和 transcript 数量，逐个清理，再观察下一轮请求是否回到干净上下文。

Problem 03

为什么 channel 和 Agent 关系总看不清？

这类问题通常不是不会改配置，而是关系分散在 channels、bindings、Agent 默认值和 workspace 继承里。只看一处字段，很容易误判消息最后会进到谁。

对应动作：梳理 bindings 对应页面：Channels / Agents / Overview
常见信号 某个 channel 明明在线，但消息落点、默认模型或 workspace 行为和预期不一致，看起来像“随机进错 Agent”。
推荐顺序 先确认当前 Profile 与 workspace，再看 channel 实例和 bindings，最后再核对目标 Agent 的默认值与运行态。

先看什么

先确认当前 Profile 和 OpenClaw 工作区，再回到 Channels 页面看实例与 bindings，最后再核对目标 Agent 的 workspace、tools 和 session 状态。

怎么处理

不要把问题当成“某个 channel 有 bug”，而是把它当成一次配置关系核对：channel 指向谁，谁再决定模型、workspace 和能力暴露。

Problem 04

为什么模型升级总要改很多地方？

上游模型版本号变化以后，如果旧 Model ID 还被默认模型和多个 Agent 显式引用，升级动作就会变得很碎，容易漏改。

对应动作：一键更换 Model ID 对应页面：Best Practices / Models / Agents
常见信号 上游模型版本号已经变了，但默认模型、Agent 显式绑定和历史配置仍然散落着旧 ID。
推荐顺序 先补新 Model ID，再批量迁移引用，必要时再清 Session，避免“模型换了但行为还像旧版本”的错觉。

先看什么

先确认新 Model ID 已在 Models 页存在，再看旧值是否仍被默认模型和 Agent 显式引用。

怎么处理

用 Best Practices 页的一键更换 Model ID，把旧值批量迁移到新值；如果模型切换后行为还像旧版本，再补一次 Session Cleanup。

Problem 05

为什么 Feishu 能力暴露总是过大？

很多系统默认把文档、云盘、Wiki、权限类 Tools 和一整组 feishu-* 技能一起暴露给模型。这样虽然“都能用”，但上下文会越来越吵，Token 和风险边界都会迅速失控。

对应动作：收紧 Feishu 能力暴露 对应页面：Best Practices / Plugins / Skills
常见信号 模型明明只需要消息通路，却仍然带出文档、云盘、Wiki 或权限类能力说明，导致上下文又长又吵。
推荐顺序 先关掉不必要的 Feishu Tools 和相关系统技能，再按 Agent 与场景逐步放开真正需要的能力。

先看什么

先判断当前场景是否真的需要文档、云盘、Wiki 和权限相关工具；很多时候，消息通路本身才是必须保留的能力。

怎么处理

用最佳实践页的一键收紧动作先关闭不必要的 Feishu Tools 和相关系统技能，再按 Agent 逐步放开真正需要的能力。

Navigation Exit

继续深入

如果你已经定位到问题类型，就继续进入主站首页看整体能力边界；如果还想了解这套治理目标如何被组织成提示结构，再去方法论页继续看。

返回首页 查看方法论页