我养了一只什么龙虾？

为什么开始折腾这个

2026 年一月下旬， Clawdbot 开始频繁出现在时间线上。当时并没有体验的想法，一是热点太多追不过来了，二是据说有安全问题也不想装到自己电脑。而且看起来这个新东西和大家在用的 Claude Code/Codex 也没什么本质区别？

后来读到 Frost Ming 的文章《创造一只龙虾，需要些什么？》，很受启发。我也很好奇从 pi-agent 到 openclaw 之间经历了什么，也许只有自己养一只，才能知道它为什么火。这就是我开始折腾 Nanobot 的初衷，它够简单，代码可读，改动成本低。

从 Nanobot 开始：先做减法

Nanobot 的代码量不大，逻辑也很清晰，不过还有删减的空间。删掉不需要的 Channel（只保留飞书），移除用不上的功能模块，只保留核心链路。

假期里的狼狈开局

恰逢春节假期，手边只有手机没有电脑，这个极端场景暴露了几个问题：

• 记忆压缩（consolidation）有问题
• 运行不太稳定，时不时报错
• 调试困难——Agent 在后台做了什么不可见

这些问题我提了一些 PR，部分很快被合并了。基础原型跑通后，我开始根据移动端使用的真实需求迭代——既然假期只能用手机，那就基于这个场景看看能迭代出什么龙虾。

为了好用做的几件事

让轨迹可见

使用的时候最烦的就是不知道它后台到底在干了什么，开始干了没有。我让它把工具调用的轨迹都发出来，这就能看到 Agent 的工具调用过程。至今我仍然觉得是个非常实用的功能。

加上 HITL

除了过程不可见，另一个让人不安心的点就是会不会发生误删文件等不可逆操作。我给这些操作加了人工确认环节，通过飞书卡片消息或者运营商认证通道的人工确认环节。

把 Feishu 用顺手

我觉得一个人没必要同时用多个channel，所以只关注飞书就行，花了不少时间把文档和消息能力补齐：

• 文档读写：能创建、编辑、读取飞书文档
• 文件传输：支持上传下载，打通手机与 Agent 的文件流
• 消息可见性优化：既能看见历史消息引用，也避免在群里刷屏

目标很简单：这些都是高频操作，让 Agent 真正能在只有手机的场景下完成闭环。

多 Agent 的尝试

通过启动时指定配置和workspace，可以实现运行多个实例，初衷是希望能不能通过一个父实例管理N个子实例。

我理解多 Agent 的场景主要有两个，一个是上下文隔离，另一个是提高并发。通过多实例进行上下文隔离太麻烦了，更好的做法是 Sub-agent。于是让它 spawn 时自动新拉一个群聊，作为新的 context space，这样同一个 agent 在不同的群里可以并行执行任务。

通过上面的多实例+多会话+异步的机制，已经完全能打满我个人的处理带宽，即使 agent 能干更多的活我也没有精力验收。

现在怎么样了

抛开网上的营销案例，从我个人的真实使用情况来看：

• 一些定时任务，监控告警之类的，以前也能做，只是现在更方便了
• 资讯整理与总结：比之前方便很多
• 自媒体：生产泔水肯定是容易多了，但是稳定产出高质量内容感觉还很难
• 代码开发：像是给 codex/claude code 接了移动端，也方便了

一些展望

• 目前在使用中关注 Agent 的工作过程应该还是有意义的，因为能够更好的知道它的能力边界。不过也许很快就不需要了，就像从 IDE 到命令行一样，随着成功率变高只关注结果就行。

• 有很多人抱怨 Openclaw 配置麻烦、容易报错，不过现在不好用的地方大概率是暂时的，因为现有的 infra 都不是 ai-native，为 agent 而造的。据说汽车刚出现时比马车慢多了，因为还没有适配汽车车轮的路。

• Openclaw 的一大价值是把人从电脑前解放。既然人不应该趴在电脑前，也不应该埋在手机里。现在通过 IM 软件交互可能是个中间态，下一步大概率会通过穿戴设备。输入靠语音输入基本解决（多模态可能还差些），输出侧关键是如何验收结果，下一步可能是穿戴设备（眼镜/耳机）+ 极简确认交互，而不是在聊天框里收发消息。

• 传统软件思维是寻找最小公倍数——做一个产品尽可能多地覆盖用户需求；而 Agent 时代可能是寻找公约数逻辑——提供原子化的能力单元（API），让每个用户用自然语言拼装出自己的 skill。因此集成类软件的空间会被压缩，原子化能力服务的需求则更大。

• Openclaw 的火爆，让没接触过 mac 的人买了 mac mini，让没用过飞书的人下载了飞书，让不知道云是什么的人有了自己的云服务器，让没coding过的人买了coding plan。2025 年时都说 2026 Agent 要爆发，不过可能没人想到会是这样爆发。