关于Clawbot的一些想法

关于Clawbot的一些想法 这两天上手了一下clawbot感触还是挺多的。去年9月份去某个hackathon的时候做过一个项目，也是用telegram/whatsapp的交互，去让agent proactively跑异步的任务，同时任务有时候可以被群聊内容触发。出发点是相似的，但是最终呈现效果却完全无法跟别人比。我觉得主要差异其实落在整体产品/工程路线上，而且这也几乎是大部分hackathon toy projects的通病。 clawbot给人的第一感觉其实是它根本不是在做某个agent（这里我们把agent定义为一个有反馈机制可以不停自己读数据跑函数直到目标完成的程序），文档拿出来更像是传统操作系统/分布式系统的runtime/platform设计。 我觉得这恰恰可以看出，现在agent的主要bottleneck已经不在/不完全在模型性能上了。当我们能够用claude code+一些skills解决大部分电脑操作的时候，其实能够完成真正有用的tasks的全自动agent，其实更缺一整套系统能够把各个环节统筹衔接起来，不互相影响/冲突，让任务能够尽可能久的跑下去（这应该是性能上系统优化的主要目标）。而这恰恰是传统操作系统设计面对的问题。同时，因为LLM调用以及工具调用（有些甚至是模型现写的代码）的随机性，统筹进程和子进程之间的交互的不稳定性是无法避免的，这也是会看到很多分布式系统设计的理念（clawbot本身设计上就是可以放在不同nodes上跑的分布式架构）。 1. 最基本的抽象首先是own所有进程的daemon以及将其向外部expose的gateway，从而通过让整个系统和costly/不稳定的LLM call分离来隔离风险。 2. Webhook的event driven让agent可以有效率地对于环境变化做出反应。 3. 上来onboarding的时候对于各种动作的细粒度权限设置（快速复用本地已有的auth）和WhatsApp/telegram类似蓝牙配对的handshake机制去解决安全性的问题。 4. 同时完全local-based的特点让整个系统能够通过terminal更容易地access多种进程，本地的软件和claude code这样的工具都可以有效复用，各种权限管理也比类似manus那样cloud-based容易很多。 所以可以看出来之所以没有办法deliver如此惊艳的效果，大部分时候都不是因为缺少一个两个好想法，现在好想法其实越来越廉价了，更多时候是有没有一个成熟完备的系统设计确保整体性能上限足够高的同时让工程的精力不浪费在早就已经被解决过的经典顽疾上。 最后，其实也可以看出来ai coding tool大行其道的现在，写代码的成本在变低的同时，构建有竞争力系统的门槛没有被完全拉下来。对于agentic项目来说，工程能力上的优势可能会比想出新idea抢占先机带来的先发优势更加重要。idea碰巧击中用户，工程上碰巧选择了相对竞争者更优的路线是不够的。能够带来持续的竞争优势的是持续构建迭代的工程能力或者是持续抓住用户变化需求的能力。除非运气很好正好做了一个能够自己产生优势的东西（通过成本结构/网络效应），迷信先发制人、疯狂迭代来获取竞争优势是不现实的。 我觉得clawbot代表的系统化范式说不定会是主流方向，但也意味着除了在很专业化的方向未来这东西会很卷（系统设计不是秘密）。