1. 本章要解决的问题

多数 OpenClaw 的不稳定并非源于某个单一错误决策，而是源于将良好组件组合时缺乏纪律性的使用模型。

在使用层，团队通常把任务设计、Skill 使用、Agent 角色、自动化、上下文控制和恢复视为独立主题。真正的难题出现在这些组件每天一起使用时。

一个常见的模式很容易识别：

• 团队创建了数个有用的任务；

• 每个任务单独运行良好；

• 他们为“方便”将其合并为一个宽泛的流程；

• Agent 的范围扩张以吸收异常处理；

• 为覆盖所有边缘情况添加了 Skill；

• 在组合行为未经验证之前就启动了自动化。

输出也许在一段时间内看起来仍然有效，但控制质量开始下降：

• 完成标准变得不一致；

• 每次运行的上下文持续增长；

• token 压力上升速度快于确定性；

• 故障恢复由计划式转为被动反应。

一个具体例子：

团队起初有三个稳定的任务：每日输入分拣、状态摘要草拟和后续准备。为了减少交接，他们将这三项合并为一次自动化运行，指令块很大，Agent 负有多项责任。随着时间推移，异常通过附加更多上下文和新增 Skill 来处理。运行经常完成，但监督工作增加、纠正循环增多，没有人能清晰说明何时停止、重置或再次拆分工作。

根本问题不是能