首先，本文不是安装教程，其次，我用的是 imessage📩
我最近试了 Clawdbot（已经改名 Moltbot）。下面我们直接使用
这篇记录的是一个律师视角的第一手体验：它到底是什么、值不值得现在折腾，以及它把我推回了哪些更重要的基本功。
一、它是什么，以及我为什么暂时不建议安装
Moltbot 是一套偏自托管的个人助理运行底座：
你在自己的机器上跑一个常驻的中控进程，把多个消息渠道当作统一入口，再把消息路由给不同的 agent / tools 去处理，最后把结果回到原渠道。
我比较喜欢它的记忆实现：用几份 Markdown 文件当作长期上下文（IDENTITY / USER / TOOLS / HEARTBEAT / SOUL）。改动这些文件，就等于改了它的风格、边界和持续性。
我自己的一个小技巧是：把任务输出目录放到坚果云同步文件夹里。
它在小主机上跑完任务，我在主力机打开同步目录就能看到结果，也能直接看到它自动整理出来的分类文件夹。
像是在团队合伙办公了。
它的热度一度让 Mac mini 出现了「洛阳纸贵」的行情，二手价也被带动。
但我现在不太建议大多数律师立刻安装。
它是一个助理版的雏形，能力还在补充中，安装与运维的摩擦也不少。
虽然有 UI，但是页面、配置都还不是很友好。
另外，改名与迁移也带来了一段混乱期：项目从 Moltbot 改为 Moltbot，生态迁移过程中，npm 包名一度出现被抢占或误导的风险。
还有人用它的名字去发比特币... 略显魔幻。
想试的话，建议走官方脚本或直接从源码安装，但会更麻烦一些。
更重要的是，如果你还没把自己的流程、模板和材料沉淀成上下文资产，常驻、多渠道、自动化只会把「garbage in, garbage out」放大。
带着这个前提试用，关心的不是某个功能点，而是它把助理做成常驻、多渠道、可自动化的形态之后，个人工作的路由与上下文治理会怎么变化。
二、在 Moltbot 之前：我的路由实验
在 Moltbot 出现之前，我也一直在探索一种更个人化的工作路由机制。
实现思路很简单：用一个统一的 CLI 入口承接所有任务，然后让一个路由 agent 基于常规工作文件夹与组织规范来做判断。
我手搓的 Vibe Working System 雏形（我的个人介绍是真的）
比如我丢给它一个文件，它先决定要不要做预处理，再判断后续要 cd 到哪个目录里继续处理。
而那个目录的配置里，放的就是对应项目的 skill 配置与默认规则，然后靠 Claude Agent SDK 来接入 AI Agent 的能力。
这类工作看起来像折腾系统，但并不白做。本质依然是上下文工程与上下文治理。
把结构、边界和默认动作想清楚，换什么工具都能很快上手，因为底层逻辑是相同的。
三、Agent 助理的演变线
Manus 这类云端虚拟机，把执行环境放在云上。它擅长把任务跑完，但上下文与权限被隔离在沙盒里。
Claude Code 这类本地终端形态，把执行环境拉回本机。
它能贴着你的文件、项目、目录结构做事，上下文厚度立刻不一样。我现在常规的工作都是在 VS 里面配合 Claude Code 来完成的，当然更多的还是文件的收集、整理与输出。
再往后走到 Cowork，这条线开始更关注如何更好地组织与处理内容，以及让更多人不靠终端也能用起来，这是形态上易用性的转变。
Moltbot 站在另一侧：它把入口从你打开它变成它随时接应你（稳稳地接住你🫴）。
你在不同渠道发一句话，它都能当作同一条工作流的入口。
而所谓常驻加多渠道加自动化的形态，落到工程上，要靠一个中控来协调。
在这套形态里，Gateway 是一个常驻的中控进程。
外部的消息渠道都连到它，内部的 agent、工具、事件调度也围着它转。你看到的多渠道互通、自动触发、持续运行，背后都在靠它把链路兜住。
它属于个人智能终端的控制面，而非单点功能。
四、为什么它现在还不是很好的形态
我对它的评价是：趋势感强，但现在还早期。
不要因为 FOMO 而强上，我已经踩坑了。
一个原因是功能还不够完善，很多环节需要你自己补，安装和运维成本不低，故障点也多。甚至连 MacOS 的 app 也要自己编译。
不过大部分人更常见的问题是：需求还没到要上常驻网关的那一步。
你真正缺的往往不是入口，而是先把本机的终端与文件系统用顺。
如果你本机的 Claude Code 还没用熟，终端习惯、文件组织、项目结构都没跑顺，工作中的 skill / 上下文也没有总结出来，那么终端主机与常驻网关的收益很难兑现，复杂度反而会压过收益。
本机终端是用好的第一层杠杆，常驻与多渠道才是第二层。
贪多嚼不动。
五、常驻与自动化的前提，是你能给它足够多的上下文
这类工具最容易让人误判的一点是：以为入口升级了，生产力就会自动升级。
恰恰相反，过于追求工具的前沿，反而会让你忽略真正重要的事。
Moltbot 是，扣子的 skill 也是（后者我会单独写文章批评
）。
你如果没有把自己工作流程总结出来，没有把常用材料、模板、要点沉淀成上下文资产，那么你让它生成合同、写委托材料，也只是「garbage in, garbage out」。
产出了一堆内容，没有意义，回头你还要花很多的时间去筛选。
给它更大权限、更多空间只有在一个条件下才有意义：你已经知道它该沿着什么流程走，产出该落在哪，哪些环节必须人工复核。
六、「本地贾维斯」的判断
Moltbot 确实可能是更接近个人智能终端的形态。
本地 agent 天然能接触更多上下文，尤其是文件与项目结构，这对我们律师工作还是很友好的。再叠加大模型能力提升、参数量下降（但愿），本地部署会越来越现实。
毕竟像 Mac Studio 512G 这种硬件已经能跑一些强模型的量化版本，比如 MiniMax 的 M2.1 量化版，而且能力不弱。
这会把全本地化的想象从口号拉回到工程问题，而不是存在在笔者的嘲讽中😅。
但它也会把一个问题推到台前：当能力越来越接近真实操作系统，治理能力就不能缺席。
这正是很多习惯了刀耕火种的律师缺少的。
以后的工作方式都需要面向 agent，而不是人，所以上下文的交付很重要。
Skills Instead Of Agents：不做智能体，先把你的专业能力写成 Skills
你再也不能让助理猜你想要什么，回头产出不合格又骂人家一顿，因为这本质上是你自己任务交代（上下文交付）的问题。
七、最终带来的，是一次回看
Moltbot 这次体验，最有价值的部分不是「我又多了一个工具」。
它像一个提醒：
你的系统里到底有什么能被自动化？
你自己的流程有没有被写下来？
你有没有可授权的上下文资产？
大模型和工具是水，上下文是你造的船。
如果你什么都没有，先别急着追常驻网关——先把 Claude Code 用熟，把工作流沉淀成可复用的上下文/Skill。
这才是真正能撬动杠杆的地方。
