Agent / Skill / MCP：我现在怎么继续长能力

作者：Felix （Haro 协作整理）

这两天我把 OpenClaw 里的本地能力做了一轮整理，核心目标不是“看起来更整齐”，而是让后面新增能力时，不容易再次长回一团。

我现在把本地能力先收成三层：

一句话就是：

这样分的原因很简单：能力一多，如果顶层入口什么都接、skill 什么都塞、底层工具又没有独立出来，后面复用和扩展都会越来越乱。

所以这次整理，我主要定清了三件事：

1. Agent 负责接住问题，不负责吃掉一切

顶层 Agent 现在更明确是领域入口。

比如：

它们负责分流和边界，不应该自己慢慢长成“什么都做的大 skill”。

Skill 更适合承载多步流程、业务判断和安全边界。

MCP 则只放那些已经稳定、可复用、低上下文耦合的底层能力，比如结构化查询、稳定 API 调用和单步动作。

一个我现在更明确的原则是：

不要把强依赖业务上下文判断的“脑子”直接塞进 MCP。

这次整理后，我把后续新增能力的默认顺序也定下来了：

这样就不容易一上来就先造新层级，或者把还没稳定的东西过早抽成底层能力。

为了让后面更容易维护，我还补了两类治理信息：

现在我会额外看三个维度：

这样后面回头看，就能更快分清：哪些已经稳定，哪些只是骨架先搭起来了。

我给几个 top-level agent 都明确补了“不要吸收什么”。

因为很多系统后面变乱，不是因为一开始结构错了，而是因为顶层入口慢慢把子层该做的事全吃进去。

这次整理后，我也把“新能力到底挂哪一层”的判断尽量交给 Haro 处理。

也就是说，后面我更适合直接提需求和目标，而不是先自己判断：

这部分交给 Haro 来收口：

这样对我来说更省脑子，也更稳定。

为了让自己少切到“架构判断模式”，后面我可以直接用这些话把需求丢给 Haro：

这次整理最后收成了三份互相引用的文档：

真正重要的不是“多了几份文档”，而是以后新增能力时，我终于有了一套更稳的默认判断顺序。

总结成一句话就是：

这会让我后面更容易长期复用已有能力，也更容易持续积累和优化，而不是越堆越乱。