下午很快听了这期,发现之前的 clubhouse 的好友 George ,现在在 OC 是核心 Maintainer , 所以就很快探讨了一下我的几个困扰, 我突然厘清了几个有意思的部分,做了记录。 A 和 B 是个人认为的 齿轮如何转起来的
-----------------------
A)阶段一:一个问题,两种解法
Peter 最开始想做的是一个移动端可以控制的 CC,这是大家都有共识的痛点。大概在去年 9 月份左右,长任务能力刚出现的时候,其实有两个解决方法:
方法 A:Happy 的解决方法,做一个客户端,接 CC,接 Codex。
方法 B:OpenClaw 写一个 Gateway 去接入 Slack/Telegram。
典型的一个问题有两种解法,但会带来两个方向。OpenClaw 的方法在技术上带来一种可能的架构,就是连接更多 Driver。George 也强调了早期 Peter Hack 了很多接口,不少是违反 ToS 的,但通过 Hack 先证明 impact。
相比 Happy 客户端,这种方法会带来一个开放的架构,从 IM Drivers 开始,持续接入越来越多的应用,进入正循环。以至于飞书团队专门组建了一个团队来支持。
-----------------------
B)持续解决 Dirty 问题
其实这也是第一个问题的延续:Hack,做 dirty、unsexy 的东西极其重要。比如大家都遇到过的问题:
调用 API 时会有大量 JSON 结构的冗余,非常浪费窗口。据说 CLI 部分做了极致的优化。单次 workflow 调用时可能不是问题,但在长时任务中,这个问题就非常严重了。正是这些每个人都见过的、微小问题的累积,背后才是“Make it Happen”的关键。
-----------------------
C)为什么在中国比美国火得多?几个要素机缘巧合
核心还是开源。对中国来说:
政府需要依赖开源,大厂需要开源,SMB 和 KOL 也需要开源。当几个阵线连在一起时,产生了不可思议的化学反应(动员/协同)
@葬愛咸鱼 open source 在中国是一条正确且长期的路线。政府也需要通过开源赋能 SMB 和群众,来对抗大厂的高压。
总之,就这么谜一样地发生了。
-----------------------
D)云 vs 本地(说到底新一轮的 Cathedral vs. Bazaar?)
短期、表面上看是能力问题:比如浏览器里的 Cookies 共享,不少 Native OS 上的内容软件操作,看上去都是技术问题。理论上这些都可以被 API 化,浏览器能力也都能解决,只是需要时间。
长期来看是权力博弈问题:大量积累的 Native 内容的访问权限都掌握在巨头手里,应该会继续内化。这归根结底是权力博弈的问题。所有鼓励主机的做法,本质上都是在鼓励边缘的计算权限。这是我理想主义期待看到的方向。
----
云 Sandbox 肯定有优势,也适合下沉。我的问题是:这是不是也会带来更多 Drivers? 以及在中国推动下,开源是否会带来不一样的边缘可能性 ~