作者：Felix（Haro 协作整理）
最近持续用了 OpenClaw 一段时间，我对它的理解有了一个挺明显的变化。
刚开始接触这类系统时，很容易把注意力放在“模型够不够强”“功能多不多”“能不能跑起来”这些问题上。但我现在越来越觉得，如果真的打算长期使用它，真正需要关心的，可能不是模型本身，而是更底层的几件事：Skill 有没有被真正启用，Agent 有没有合理分工，以及整套能力结构是不是可持续。
我最近就在重新整理自己的 Skill 和 Agent。整理过程中，一个很直观的问题冒出来了：OpenClaw 里其实有不少对我很有用的能力，我之前并没有真正启用起来。
比如编程相关的模块，其实完全可以考虑交给 Codex 这类更适合代码场景的能力去处理。这个问题表面上看像是“换个模型”，但本质上更像是任务路由。如果不同类型的工作没有送到更适合的模块里，结果往往就是：该省下来的 token 没省下来，该提升的效率也没有真正提升起来。
类似的情况还不只出现在编程任务上。前一段时间，我自己的 web-search 通道就出过问题，这会直接影响信息检索类任务的稳定性。还有 summarize 相关能力，我一开始也以为可以沿用 ChatGPT Plus 或 Pro 账号的使用方式，后来整理时才发现，至少在我当前了解和接触到的路径里，它并不能简单靠订阅账号直接解决，很多场景下还是要走 API。
不过这件事对我现在来说，重点不在于“我已经强依赖 API 了”，而在于：我开始意识到，随着使用继续深入，后面很可能会进入一个更强依赖 API 的阶段。
这一点很关键。
因为在当前阶段，我其实还没有真正走到那一步。很多事情还处在整理、试用和重新理解结构的过程中，API 需求还没有被完全触发出来。换句话说，我现在面对的不是“API 已经成为刚需”，而是“如果后面想把更多能力真正接进工作流里，API 需求大概率会越来越强”。
这个变化意味着，我后面可能需要逐步调整策略。
如果只是把 OpenClaw 当成一个日常可用的 AI 工具，订阅制思路通常已经能覆盖掉相当一部分需求。但如果未来真的想把它进一步变成一个更稳定、更可编排的个人工作系统，那么有些能力最后大概率还是会落到 API 上。不是因为 API 更“高级”，而是因为很多 Skill、Agent 和自动化链路，天然就更适合建立在 API 调用之上。
但问题也在这里：一旦往那个方向走，成本问题就不能再被当成附属问题。
订阅制的特点是边界相对清楚，每个月花多少钱，心理预期比较稳定。而 API 计费不是这样。它更灵活，但也更容易随着调用次数、上下文长度、任务链路复杂度的增加而不断放大。尤其是当 Skill 和 Agent 开始真正协作起来之后，token 消耗很可能不是线性增长的，而是在某个阶段突然变得需要认真管理。
所以我最近一个越来越清晰的判断是：OpenClaw 这类系统，真正要管理的，不只是模型能力，而是能力结构本身。
Skill 解决的是能力颗粒度的问题：哪些能力应该独立出来，哪些能力值得长期启用。Agent 解决的是任务分工的问题：哪些任务该怎么路由，谁来承担什么职责。而 API 和 token 成本，则是在系统继续深入以后，很可能迟早要面对的约束条件。
也正因为如此，我现在会觉得，整理 Skill 和 Agent 这件事，本质上不是在“堆功能”，而是在提前整理未来的工作流结构。哪些能力值得打开，哪些能力值得保留，哪些能力后面可能要接 API，哪些地方一旦接 API 就必须同步考虑成本边界——这些问题，可能都要比“先接多少能力进来”更重要。
所以这段时间我最大的感受反而是：AI 工作流的关键，不只是把能力接进来，而是先想清楚这些能力以后要怎么长期存在。
至少对我来说，OpenClaw 用到现在，带来的一个真实变化就是：我开始不再只看“它现在能做什么”，而是开始看“它未来如果继续深入使用，会在哪些地方暴露出真正的结构性问题”。
而这些问题，恰恰可能比功能本身更重要。