夜雨聆风我现在越来越觉得，很多 AI agent 最后的命运其实都差不多：
装的时候很兴奋。
用几天觉得很强。
再过一阵，就慢慢吃灰。
不是因为它不够聪明，也不是因为模型不够强，而是因为它始终没有真正进入你的工作流。
OpenClaw 也是一样。
把它跑起来当然重要，但真正难的，从来不是“装上了没有”，而是：
它在你的日常工作里，到底有没有一个稳定的位置。
如果没有，OpenClaw 很容易停留在一种不上不下的状态：看起来比聊天框更高级，但日常里还是只是一个偶尔被叫出来问几句的工具。
我后来慢慢意识到，OpenClaw 真正有价值的地方，不是“我又装了一个 agent”，而是它逼着我把 AI、工具、知识库和长期协作习惯，重新组织成了一套系统。
这篇文章不讲安装步骤，也不讲一堆参数怎么配。
我更想讲的是：
我是怎么把 OpenClaw 从一个装好的 agent，慢慢变成一个真正能进入我日常工作流的个人工作台。
一、我先发现，只靠聊天框思维根本不够
以前我也会把 AI 当成一个很强的聊天工具来用。
查资料、改文字、总结网页、补代码，这些都很好用，而且确实能立刻提高局部效率。
但当我开始真的想让它长期参与工作时，我很快就发现，这套心智不够了。
因为真正的工作不是一轮问答，而是一连串连续动作：
- • 读信息
- • 判断优先级
- • 调工具
- • 留下记录
- • 后续继续推进
如果这些动作每次都从聊天框里临时拼一次，最后就会很累。
所以我后来意识到，我缺的不是“再学会几个工具”，而是一套稳定的默认工作方式。
二、我补的第一层，不是更多模型，而是默认路由
我不再把每个任务都当成一次临场发挥，而是开始给不同类型的任务设默认路由。
比如：
- • 普通网页、博客、教程、文档页，先抽成干净 Markdown 再读
- • 平台内容、站内搜索、简单交互，优先交给对应的命令行工具
- • 飞书文档、云盘、权限这类结构化操作，优先走飞书工具，不回浏览器点来点去
- • GitHub 上的 repo、issue、PR、CI，优先走
gh - • 长期有价值的判断，及时落进 Obsidian
- • 一种流程只要开始反复出现，就想办法把它固化成 skill
这一步听起来不性感，但它几乎是我把 OpenClaw 用起来的真正起点。
因为从这里开始，OpenClaw 不再只是一个“什么都能问一下”的对象，而开始进入我的分工结构里。
三、接着我补了一层长期知识库
默认路由解决的是“这件事现在怎么处理”，但它解决不了另一个更慢的问题：
哪些判断、经验和结构，应该被留下来，变成以后还能继续用的东西？
这就是我后来越来越重视知识库的原因。
因为真正值钱的东西，很多都不是一轮对话里的答案，而是这些更慢的东西：
- • 某个项目到底为什么这么设计
- • 哪些默认路由已经验证过，别再反复试错
- • 什么工具适合什么场景
- • 哪些规则值得固化成 skill
- • 哪些判断以后还会继续被拿出来复用
如果这些东西全都留在聊天记录里，它们本质上还是一次性的。
所以我后来给 OpenClaw 补上的，不是更多 agent，而是一个长期知识层。
我现在把 Obsidian 当成这套系统的外部大脑。项目笔记、研究判断、概念、参考资料、内容主题，都放在一个长期知识库里，用 git 管起来。这样一来，OpenClaw 负责推进和调用工具，Obsidian 负责把长期有价值的东西沉淀下来。
到这里我才第一次真正感觉到，OpenClaw 和知识库不是两套东西，而是一套系统的两层。
四、我后来越来越确认，命令行工具不是附属品，而是骨架
很多人会下意识地把命令行工具看成 agent 的附属工具。
我后来刚好反过来了。
我越来越觉得，真正顺手的状态不是“一个超级 agent 吞掉所有任务”，而是：
OpenClaw 作为主控，下面接一组各司其职的工具和 skill。
因为很多事情，本来就不该全靠一个聊天框来吞。
比如信息获取。
普通网页、博客、文档页，最怕噪音太多。先抽成干净 Markdown，再交给 agent 读，成本更低，也更稳定。
而像 Twitter、YouTube、小红书、微博这些平台内容，本来就不是普通网页。这个时候与其硬上浏览器自动化，不如直接走更贴近平台的工具。
再比如飞书。
飞书文档、知识库、云盘、权限，这些都是典型的结构化操作。用浏览器当然也能做，但一旦开始频繁处理，你就会越来越希望它们通过工具或 skill 稳定完成。
GitHub 也是一样。
如果你本来就深度用 GitHub，那 gh 几乎应该是标配。repo、issue、PR、CI、release，本来就适合成为工作流的一部分，而不是每次回网页点几下。
再往后，我甚至把写作也慢慢拆成了一条工具链：格式化、翻译、转 HTML、发公众号、发 X、生成封面、做配图……
这时候你会发现，OpenClaw 最强的地方不是“它自己会做所有事”，而是：
它能把这些分散的能力组织起来，让你形成一套稳定的默认工作流。
所以现在在我眼里，这些命令行工具不是附属品，而是这套工作台真正的骨架。
五、最后我又补了一层：把好用的流程固化成 skill
当一个流程反复出现，但你每次都重新解释一次，它其实还没有进入系统。
这件事在知识库治理上我感受特别深。
比如我们后来反复在做这些事：
- • 扫描 Obsidian 哪里乱了
- • 判断哪些是低风险结构修复，哪些需要人拍板
- • 合并重复目录
- • 清理重复正文
- • 给高密度目录补 README / index
- • 最后 pull、commit、push
一开始这些都只是聊天里的临时判断。
但当同一种流程反复出现以后，我就不想再让它只停留在“我记得以前这么做过”。
更好的做法，是把它收成一个 skill。
后来我专门建了一个自建 skill 仓库，把这些已经验证过的流程当成长期资产来管理。仓库是真身，运行目录只是安装态。以后再加新 skill，也都走同一套路径。
这件事看起来像是“多做了一步”，但长期看非常值钱。
因为从那一刻起，经验就不再只是经验，而开始变成系统的一部分。
六、再往后，我发现一个真正能跑的工作台，不该只有一个主控
到这里为止，OpenClaw 已经不像一个单纯的聊天工具了。
但我后来又发现，真正想把这套系统跑顺，还是不能只靠一个主控一直顶着。
原因很简单。
主控适合做判断、组织、收口，但它不应该同时承担所有执行工作，也不应该在系统出故障的时候，自己还要负责把自己救回来。
所以后来我又补了一个异构的、类 Claw 的长期协作方。你可以把它理解成另一套风格不同、但能协同工作的 agent 运行体，比如 ZeroClaw、HappyClaw 这一类。
它主要承担两类事：
- • 代码工作
- • OpenClaw 卡死时的排查和修复
这件事对我的影响很大。
因为它让这套系统第一次不再像“一个人在带一堆工具”，而更像“一个有分工的小团队”。
前段时间我去苏州玩了三天，回来之后，3 个主龙虾都还在正常运行。
那一刻我才非常明确地感觉到，这已经不是一个聊天工具组合，而是一套开始具备长期运行能力的个人工作台。
七、到最后我才意识到，OpenClaw 真正改变我的不是效率，而是工作结构
如果只把 OpenClaw 当成一个更强一点的聊天框，它当然也有用。
但我后来越来越清楚地意识到，它真正改变我的地方，不只是“更快做完一件事”，而是工作结构本身开始变化了。
我现在更少问“这个工具还能不能多帮我一点”，而更常问：
- • 这个任务应该走哪条默认路由？
- • 哪些东西应该沉淀进知识库？
- • 哪些流程应该固化成 skill？
- • 哪些工作适合由长期 agent 承担，哪些更适合交给工程执行器？
换句话说，OpenClaw 对我真正有价值的地方，不是替我多做几个动作，而是逼着我把自己的工作台重新组织了一遍。
而一旦这套组织开始成形，AI 对我来说也就不再只是一个回答器，而开始变成一个真正能进入工作结构的协作者系统。
结尾
所以如果你刚装好 OpenClaw，我其实不太建议你一上来就追求：
- • 多模型
- • 多 agent
- • 自动化拉满
- • 什么都想接
我更建议你先把四件事跑顺：
- 1. 一套默认工具路由
- 2. 一个长期知识库
- 3. 一套顺手的工具箱
- 4. 一组能长期协作的 agent / skill / 执行方分工
这四样一旦连起来，OpenClaw 才会从一个“已经装好的 agent”，慢慢变成一个真正能进入你日常工作流的个人工作台。
到最后我才发现，我缺的从来不是再多一个 AI agent。
我真正缺的，是一套能让 AI 进入日常工作的组织方式。
