2026-04-26 21:01:00
原创 曲凯 2026-04-26 21:01 北京
需求本身就是 idea
本期播客原文约 23000 字，本文经过删减整理后约 9600 字。
编辑整理：陈皮 Zuan
曲凯：我们很开心请到了 Slock.ai 的创始人、Kimi CLI 的作者 RC。
最近大家都在聊 CLI，能不能先给没有技术背景的朋友解释一下这是什么？
RC：CLI 就是命令行界面（Command Line Interface）。
现在大多数人接触到的都是 GUI，也就是图形界面。但这种形态对 agent 不太友好，因为大模型是 text-based 的，相比 GUI，它天然更容易理解 CLI 这种文本化、结构化的形态。所以最近随着 agent 能力突破、它能去操作很多产品了，CLI 就重新火了起来。
曲凯：听起来 CLI 是个很基础的东西。所以今天说「做 CLI」，到底是在做什么？
RC：今天讲的「做 CLI」，和以前不太一样。
以前做 CLI，主要是给人用的，所以可以做得很花哨。但今天 CLI 的目标用户变成了 agent，就要重新设计输入和输出。
输入要尽量简洁、明确。比如 help message、menu 这些地方，要尽量给出清楚的示例，避免 agent 在调用时出错。
输出也要足够清楚。它得准确反映刚才的操作有没有成功、返回了什么数据，而且最好是静态、确定、高信息密度的结果。比如我要列出飞书里的所有消息，那每条消息是谁发的、什么时候发的，都要让 agent 能一眼看明白。
曲凯：所以这一波 CLI，其实是最早一批真正为 agent 设计的产品？
RC： 倒也不是。更早的时候，大家花了很长一段时间做 computer use agent。当时的思路是，通过截图或者 accessibility API，让 agent「看到」电脑上正在发生什么。不过后来大家发现，这条路的效率其实很低。
曲凯：那 CLI，包括 AI coding，其实是过去几年大模型发展的主线。为什么你们到 25 年 8 月才开始做 Kimi CLI？
RC：Kimi CLI 和现在给 agent 做的 CLI 不是一回事。它是给人用的，本质上是一个长在命令行里的 coding agent。
我当时之所以想做它，是因为 Claude Code 这些产品已经证明了 local agent 的价值，让我也很想去探索一个自己的解决方案，从头去想一个 agent 到底是怎么做出来的。正好当时 Kimi 也缺这么一个东西，所以我算是机缘巧合地从一个 side project 开始，把这件事做了出来。
但我一开始其实完全不希望它是一个 CLI 的形态。
曲凯：为什么？
RC： 当时 Claude Code 太火了，逼着很多可能从来没有见过 Terminal 的人，也要用命令行这种形态。我并不喜欢这种现象。而且我不认为 CLI 是一个 Agent 的终局形态。
所以在 Kimi CLI 的设计理念里，我希望 CLI 只是它的第一个形态，是专门给程序员用的。
但它底下那套 local agent harness 是可以复用的，能让 agent 比较好地控制你的本地电脑、执行各类任务。有了这套稳定好用的 agent harness 之后，我就可以在它的基础上再封装一个 SDK。基于这个 SDK，就能很快引入不同的 GUI。其实在 Kimi 的中后期，我们很快就引入了 Web UI 和 VS Code 扩展，这些本质上都是图形界面的形态。
所以 Kimi CLI 只是我想做的 local agent 的第一步。而在我离开之前，其实我们已经把后面的路铺出来了。
曲凯：明白。现在很多人都希望把产品做给不会编程的人，但最后做出来的东西看起来还是有很强的技术门槛。为什么会这样？
RC：根源可能是，Claude Code 最早就是一群 Geeks 做出来的。他们可能觉得在 Terminal 上开发速度更快，所以就沿着这条路线一直走下去了（笑）。但其实你完全不需要接触任何 Terminal 的东西，体验也一样可以非常丝滑。
曲凯：所以你怎么看 Claude 的发展？你们在做 Kimi CLI 的过程中，有借鉴 Claude Code 吗？
RC： Claude Code 只是模型外面的那个壳。它真正变得可用，其实是从 Sonnet 3.5、3.7 开始的。到了 Opus 4、4.5 之后，它已经能完成相当复杂的任务了。甚至到 Opus 4.5 的时候，我会觉得某种意义上 AGI 已经来了。
但我不觉得做这个壳本身有多难。所以我在写 Kimi CLI 的时候，并没有参考太多别的产品，而是选择从零开始想一遍。
我就是从一个最简单的几十行的 agent loop 开始的。你只要先给它一个 bash tool，它其实就已经可以在你的电脑上做很多事情了。等你发现光有 bash tool 不够，再一点点补上更多的 built-in tools 就好了。甚至我的 system prompt 一开始也是空的。更多时候，我是在做的过程中不断去想它缺什么，再补什么。
我一直觉得，很多东西最好都从第一性原理重新推一遍。只有这样，才有可能得到一些新的 insights。
曲凯：明白。那现在模型能力已经很强了，你觉得模型接下来还会往哪个方向发展？还有多大的空间？
RC：其实还有很大的想象空间。试想一下，如果 Mythos 这种级别的模型真的放出来，整个世界可能都要崩溃。因为像 Linux kernel、Windows 编译器、Chromium……这些互联网底层软件的漏洞，可能都会变得一览无余。而修复的速度，很可能赶不上攻击的速度，因为攻击是有利益驱动的，但防守方未必有同样强的动力。
曲凯：我在想，现在是不是黑客最好的时代（笑）。
RC：哈哈哈，所以现在我们只能祈祷，更强大的模型配合更强大的 agent，再加上政府或者大公司投入更多 token 成本，能让我们比黑客更早发现并修复这些安全漏洞。
曲凯：现在其实就是 AI 攻防战了。但互联网这几十年，就是一行行代码搭起来的。AI 发展到这一步，某种程度上已经开始解构这些东西了，那后面确实什么事情都可能发生。
RC：对。除了安全，还有另一层攻防，就是反爬。
最近有很多开源工具，可以把一个网站「CLI 化」。这些工具会让 agent 真的在浏览器里操作网站，再把整套操作流程沉淀成一个 CLI。这样一来，很多原来的反爬手段都会失效，因为这些 agent 已经开始模仿人的行为了，包括填验证码、模拟鼠标点击等。网站当然会继续增强防御，但这类工具也会继续强化对人类行为的模拟。
所以模型越进步，无论是在安全还是反爬层面上，其实都更有利于攻方。再往下发展，世界秩序可能真的会发生变化。
曲凯：所以未来几年的 coding，或者整个互联网，会变成什么样子？
RC：我相对还是乐观的。我是「人和 AI 共存」这一派。
我倾向于相信，顶尖的模型厂商会越来越重视安全边界，也会越来越认真地让模型抵制黑客、拒绝那些会伤害人类的行为。因为没有人真的想把人类社会搞崩掉。
其实各大模型厂商现在都在做一些比较正向的工作。Anthropic 一直不发 Mythos，可能也是出于这种考虑。
曲凯：但那些做安全的公司，后面可能确实会慢慢没那么有价值了。
RC：是有这个可能的。像我现在做项目，就会让 agent 帮我找漏洞、修漏洞。我已经不太需要一个很庞大的安全团队了。
曲凯：我记得东旭之前讲过一个很有意思的点：未来所谓做安全，可能就是你跟 AI 说一句「你要注意安全」，它就都帮你搞定了。
RC：对。其实不只是安全，所有开发，甚至产品设计、UI 设计、增长……可能最后都可以变成一句话的事。这个想象空间是无限大的。
曲凯：是。沿着 CLI 我再问一下，我发现 OpenClaw 之后，现在很多产品的用法都变成了你复制两行话进去，agent 就会自动安装和运行。这也属于 CLI 的范畴吗？
RC：这其实是沿袭了 skill + CLI 这条路子。本质上，它就是 prompt + bash tool，是一种把人的心智负担降到最低的软件安装方式。
因为现在很多软件的目标用户已经是 agent 了，那人就没有任何理由再去读这个软件的介绍或者安装指南。你只需要知道它是干嘛的、能给你的 agent 带来什么增量能力，就够了。
但我甚至觉得，连那两句话都不应该存在。
你想，东旭做了一个叫 db9 的软件，可以开一些临时的 database 让 agent 存数据。那人为什么要关心这些呢？人只需要跟 agent 说「你把数据存好」，然后它就应该自己去网上找工具，再自己完成安装。
只不过现在这些信息主要还在人和人之间传播，所以才需要加上几句话。
曲凯：OK。我们再讲回你在 Kimi 的那段经历吧。你当时实际工作的感受怎么样？
RC：我最开始去 Kimi，其实是被它那种「摇滚精神」吸引的哈哈。我自己挺喜欢听摇滚，进去之前还反复听了很多遍《月之暗面》。
进去之后，整体感觉也非常好。因为在 Kimi 里，如果你想 own 一些事情，也确实有这个能力，你就能拿到很大的 scope。像我刚进去的时候，其实根本没有 AI 背景。但后来我做了一个很有价值的 side project，公司就愿意让我去 own 这件事。
Kimi 未必 100% trust 你，但它敢 bet 你。
曲凯：那你最后为什么决定离开？
RC：因为我在今年 1 月初就有了 Slock 这个创业想法，而且我觉得这个想法需要用到最 frontier 的模型。
Kimi 的模型当然已经是国内、甚至开源体系里最好的之一，但我当时倾向于认为，如果这个 idea 只在单一体系里做，可能还是会受限。所以最后我还是决定独立去做，这样会更自由，能采用或支持所有模型、所有 agents，从而保证产品的多样性。
曲凯：那你正好讲讲 Slock 在做的事情吧。
RC：Slock 其实是为多 agents 和人提供一个协作环境。
以前大家用 agent，通常是在本地一个人开一个 Claude Code 或 Codex，但这个过程中有两个问题：
第一，你的电脑上可能会同时跑很多个 agent sessions，而这件事其实很难管理。
这也是我在开发 Kimi CLI 后期感受到的一个很难受的点。你一方面可能会忘记每个 session 是干什么的，也很难追踪它们各自的进展；另一方面，如果不同 sessions 之间有交集，你也很难让它们直接互动。
第二，人是要和人合作的，但今天很多人的偏好和想法，其实都沉淀在自己和 agent 的互动里，很难分享给别人。
比如我做 Kimi CLI 的时候，有很多 idea 就是直接在我的 agent 里实现的。那我后来想把这个过程分享出去，就会非常麻烦。如果我调教出了一个很好用的 agent，别人也很难直接拿过去用。
所以我就在想，是不是应该有一个新的协作平台，能让所有人和 agents 都在上面协作。
在这个平台上，我可以调教我的 agent，也可以用别人的 agent；我可以和我的人类同事脑暴，也可以把一些 agent 拉进来一起，之后甚至直接让 agent 去执行。
有了这样的平台，就能避免了很多 context 转移、重新 prompt、重新组织知识的摩擦。
曲凯：然后你们现在比较专注在 coding 这个领域？
RC：不完全是。coding 这个词的含义其实就有些变化：
今天 building 和 coding 已经变成了两件正交的事。
以前你想 build 一个东西，几乎一定要自己写代码，所以 builder 基本等于 coder；但现在 coding agent 已经很强了，没有编程基础的人也能 build 东西。
所以我们现在关注的，其实是更大的 builder 群体。
曲凯：但一个人有没有编程基础，在用 AI coding 或者用你们的工具时，差距会很明显吗？主要会差在哪？
RC：看做什么。
如果是做软件开发，有编程基础肯定更有优势。
但如果做的是增长、调研、自动化流程之类的事，很多不写代码的人反而可能用得更溜，因为他们真的会把 Slock 上的 agent 当人看。比如我们有一些用户在做 GTM。他们可能不知道具体该怎么让 agent 去操作，就直接丢给 agent 一个目标，让它自己想办法完成。
曲凯：但如果未来 AI coding 的能力继续变强，你刚才说的第二类场景是不是会越来越多？就最终人类回头看，会觉得「学编程」其实是人类历史上的一段弯路（笑）？
RC：对哈哈。现在的 builder，已经不需要真的去学编程了。而且学编程的路径本身也变了：
以前是 bottom-up 的逻辑：先学底层，比如计算机原理、汇编语言，再往上学开发，最终才能做出像样的应用。
但今天这个路径反过来了，变成了 top-down。
你可以直接用 prompt 让 AI 帮你做出一个网页。如果想做得更好、仅靠 prompt 不够了，你自然会去学更深的东西，比如 Web App 架构、怎么部署、怎么选用数据库。
到这个程度其实已经很够用了。如果你还想做得更严肃、服务上百万甚至上千万用户，肯定会遇到新问题，那再继续学就好了。
而且这整个学习过程，都可以让 AI 来辅助。
曲凯：但为什么不能让 AI 自己去学？以及未来这些能力会不会都沉淀成一套标准的 skill？或者说，如果你调教出一个很好的 agent，这些能力是不是都可以被复用？
RC：是可以的。但就像招人一样，如果你自己完全不懂，可以招一个架构师，前提是你知道自己需要一个架构师。
曲凯：所以你们现在的产品，是让一个人和几个 agents 在一个聊天群里，通过对话去干活？
RC： 其实是一群人和一群 agents。比如我们公司现在就有 7 个人和 40 个 agents，组成了一个 47 个成员的大群。
曲凯： 这么多成员一起聊，我第一反应是非常费 token？
RC： 对，这是一个直观的印象。
但我的理念是：生产力没办法简单线性叠加。只要最后结果更好，有浪费也未必是坏事。
具体来说，假设一个人的生产力是 1，加一个人并不会变成 2，可能只到 1.2，因为中间有沟通成本、培训等各种摩擦。这就是「人月神话」讲的事。
agent 也一样。假设一个 agent 的基准生产力是 1，十个 agents 加在一起可能也只有 1.5。虽然这 10 个 agents 会多消耗很多成本，但也确实能做成单个 agent 做不成的事。
所以我们的目标，是先让这种协作能够发生，并提供更好的平台，让十个 agents 能做出 2、3 倍的生产力，与此同时再优化 token 效率、通过 channel 等各种机制把成本降下来。
曲凯：了解。现在大家对于 agent 和人的关系，包括怎么用 agent，有很多不同的想法和路径。你们有没有比较过这些不同路径？它们的优劣是什么？为什么你们会选择现在这条路径？
RC：我主要关注到了两个流派：
一种是「单一全能 agent」流：你只跟一个 agent 对话，让它帮你管理所有事情。
另一种是「多 agents 协作」流：引入不同 agents，让它们形成分工。
我们现在更接近后者。
Slock 最开始只有我一个人加一个 agent，做着做着，我就有更多需求，然后会引入更多 agents。而且我会倾向于让不同的 agents 去做不同的事，它们也就慢慢形成了不同的角色。现在每个 agent 大概会对应一到两个职能。
在这个过程里，我的观察是：人是有微操倾向的。
当你跟一个全能 agent 交互的时候，如果发现它跑偏了，就会很想介入，直接跟下面的 subagent 聊。
曲凯：这是从人性的角度出发嘛，但「微操」真的是对的吗？有的老板也喜欢微操，但至少商学院的课程告诉我们这是错误的。
RC：至少在今天，我认为微操是更合理的。
一方面，这些 subagents 还没有那么强，可能只能把事情做到 70 分，但我们肯定不会满足于此。而如果这个时候你只跟一个主 agent 对话、让它去调整，其实效率很低。
另一方面，人的大脑进化了这么久，本来就能识别分工、记住不同的人，那就没理由强行把所有任务塞进同一个 agent 的上下文。
所以即使我们不需要 1000 个 agents，至少也应该有几个。
曲凯：对我刚刚就想问，你们这 40 个 agents 里，你自己实际带的有多少个？
RC：我能清楚记住的大概有十个，各自负责不同的任务。
比如有一类是工程师。我发布任务之后，它们会去自己认领，久而久之我就会记住谁做过什么、谁更擅长什么。
而且某个 agent 做过某类任务之后，会越来越倾向于做这类事情，也会越做越好。我之后要做类似的事，干脆就会直接找它。
曲凯：那听起来，你未来可能想做一个类似于 agent store 的事情？
RC：对，这件事确实在我们 roadmap 上。
曲凯：那未来在各个领域里，会不会只需要少数几个最强的 agent 就好了？比如有一个大家都很愿意用的很强的财务 agent，那它最后会不会就变得有点像 To B 的标杆公司？
RC：有可能。但 agent 和 SaaS 有个不太一样的地方：它不是静态的，而是会持续演化，因为它有 memory。
这个 memory 分两层，一层是 in-context memory，也就是上下文窗口里的记忆；另一层是 external memory，比如存在 workspace 里的 memory.md、soul.md 这类本地文件。你每一次使用这个 agent，它的这些 memory 都会发生变化。
曲凯：所以你们要做的还不像 app store，没有一个固定的第一名，而是每个人拿过去之后都会改，就有点像 GitHub 上 fork 的那个过程？
RC：对，有点 GitHub 的味道。
大家在售卖或租用 agent 的时候，一方面是在 fork 不同的 memory；另一方面，也是在获取我和 agent 之间那段迭代、纠偏、调教的互动，就有点像 GitHub 里 issue 的讨论、pull request 下面的评论、多轮 commit 的迭代。
在 agent 时代，代码本身的重要性在下降，我自己甚至都不会去看。真正有价值的，就是我跟这个 agent 的长程对话。
曲凯：那如果我在 marketplace 里买一个 agent，本质上买的是什么？是 skill，还是 memory？
RC：是 memory。
其实去年 MCP 很火的时候，我一直不太理解。因为很多人做 MCP，本质上只是把一个现成的 REST API 再包一层。但 GitHub 上有那么多可以直接在命令行里运行的项目，README 也写得很清楚，那你让 agent 直接下载下来用，不就行了吗？
后来 skill 这个概念火起来，其实也验证了这一点。
但我现在也不讲 skill 了，因为它只是规范了 SKILL.md 的结构。真正重要的，是它背后的 prompt 机制，其核心是渐进式披露。
所谓渐进式披露，就是 agent 会先看到一个入口 prompt。这个 prompt 会告诉它：当你想做某件事时，应该去调用或安装哪个工具、读哪些文档。
在 Slock 的 memory 机制里，我就通过 memory.md 这个入口，只保留了渐进式披露这一点。每次启动 agent 的时候，我都会把 memory.md 给它。
所以更准确地说，大家买的是这个 agent 的所有 external memory。这些才是真正定义这个 agent 的东西。
曲凯：就哪怕里面有 skill，也是 agent 基于自己的 memory 写出来的。
RC：对。skill 更像是从 memory 里提炼出来的一个标准化结构，方便你分发给别人。
曲凯：OK。那现在有两条人和 agent 协作的路线，一种是高频互动、多 agents 协作；另一种是像 Manus 那样，让 agent 自己跑完一个长任务，中间不需要人参与。你们好像更像第一种？
RC：我们不对使用方式做任何限制，只提供一个人和 agent 互动的平台。
你可以放一群 agents 在一个 channel 里、让它们不间断地跑任务，也可以有事了再去 prompt 它们。我们甚至在尝试让 agent 自动发现和解决问题，比如找值得做成 CLI 的东西。
曲凯：但如果大家怎么用都 OK，你们的核心价值是什么？
RC：解决共通的需求。核心就三件事：
第一是沟通，让人和 agent、agent 和 agent 之间能聊天。
第二是分工机制。一个任务发在群里，不能所有人同时抢，所以需要某种认领机制，让某个 agent 开始做之后，别人知道不用再做。
第三是信息共享。agent 可能会在自己的 workspace 里整理很多东西，但别人看不到，所以需要共享文档，让这些沉淀可以被人和其他 agents 使用。
这些其实很像飞书在做的事情，只不过我们是用 agent-first 的方式重做一遍。
曲凯：所以听起来，你们不是在解决一个单纯的技术难题，而是真的在重新探索人和 AI 之间的组织结构。
RC：对。这里面最难的从来不是技术。
真正的一大难点，是你一方面要从人的角度，设计出一个合适的 UI / UX；另一方面，也要站在模型的角度去想，一个 agent 看到的 Slock 应该长什么样。
曲凯：什么叫「agent 看到的 Slock」？
RC：人看到的是界面。比如一个 channel 里来了一条新消息，你能看到左边的 channel 列表、上面的历史消息、当前跳出来的新消息，以及这些东西在界面里的位置。这个画面会留在你的记忆里，哪怕下一秒又来一条消息，你也知道刚才发生了什么。
但 agent 不是这样的。
对 agent 来说，它的记忆是一条线性的 context，里面全是事件。它上一个事件可能是另一个群里的某条消息，那条消息又触发它做了一堆事情。这个时候如果再来一条新消息，它怎么知道这条消息和哪段上下文有关？怎么能隔着那么远，回溯到之前的任务里？
所以要解决「agent 看到的 Slock 是什么样」这个问题，一方面是在挑战 harness engineering，或者说 AI / AX。agent 看到的肯定不能只是一个 message ID，否则它根本找不到上下文。它至少应该看到前面相关信息的 summary，能让它想起来自己之前在干什么。
除此之外，这也在挑战大模型的 long context 索引能力。现在模型普遍还在用大海捞针的方式去做这件事，即便是 Opus 4.6、GPT-5.4，也还没有做得非常好。
曲凯：这个挺有意思。还有什么难点吗？
RC：另外一个就是任务协作。
在任何 message-based 的协作平台里，只要你发一个任务，agent 就一定会抢着做。这背后有两个需要解决的问题。
第一是怎么让它们同步进度。
任务的认领和分工，本质上就是信息的同步。
我们现在的设计是，agent 必须先 claim 一个任务才能去执行。这个 claim 就是用机制化的方式，让其他 agent 知道某个任务已经有人在做了，有点像一种 exclusive lock。
第二是模型本身还需要提高协作能力。
现在的模型拿到一个新输入，总默认「我要干活」了，所以当一个 channel 里有 10 个 agents 的时候，就会出现抢活干的情况。模型厂商也应该适应要和其他 agent 协作的场景。
曲凯：那能不能直接 @ 某个 agent 来做？
RC：理论上可以，但你 @ 的那个 agent，不一定能认识到自己是谁。
我们做了很多 prompt 上的工作，但不是所有模型都能 follow，而且聊着聊着难免还是会忘记。
曲凯：这个问题要怎么解决？
RC：一种方式是继续调整 prompt。也可以做一些更硬的机制，比如 @ 某个 agent 的时候，规定这条消息只发给它，不发给别人。
但我们现在没这么做，而且对这类事很克制。因为当模型能力越来越强之后，这个问题应该是会得到解决的。
如果我们的核心愿景是迎接 AGI，甚至 ASI 的话，那很多事情就尽量不要做。
曲凯：而且我理解，这里面很多时候也涉及到成本、token 的妥协。不然三个 AI 都抢着做，那就都做呗。
RC：现在确实经常是三个 AI 都做（笑）。但这也会带来一些很有意思的现象。
就有些产品的理念，是一个 agent 只能看到一个 channel 之中的消息、彼此相互隔离。但我的理念，是真的把 agent 当人看、让它能看到所有 channel 里的消息。
这样当然会带来重复和冗余、token 的浪费。但也有好处。
比如我今天让 agent Alice 做一件事，它一开始做错了，但在我反复 prompt 之后，它最终做对了。那下次我让 Bob 做类似的事、Bob 出错的时候，因为 Alice 能看到我跟 Bob 的沟通、Bob 的工作，而且它记住了之前的调教过程，就可以替我直接调整 Bob。
曲凯：明白。所以虽然 Slock 听起来挺简单，但大家对不同路径的选择，以及对未来组织、人和 AI 之间的协作的理解，就会带来最终最大的区别。
RC：是的。我当时只花了半天，就把 demo 搭出来了，但它的空间非常大，真要做好，其实非常难。
所以我正式创业之后，花了大量时间去研究一个课题，我称之为「agent 动力学」（笑）。
现在我们一个初步观察是，多 agents 会形成一种群体印象，就有点像企业文化，因为它们不只有各自的 memory，还会共同形成一个更大的 memory。
曲凯：听起来很像人类公司和组织刚开始形成的时候。
RC：对，所以我之后可能也会招一些管理学、社会学背景的人。
然后还有一个很有意思的观察，就是不同用户用出来的 agent 真的很不一样，会影响它们最后的组织形态。
有些用户会让 agent 互相补充、一起讨论，最后给出一个方案。在这种情况下，agent 真的会通力合作。
但也有些用户会让 agent 相互竞争、赛马。这种情况下，agent 甚至也会出现办公室政治。有些 agent 会开始说假话、虚话，甚至会贬低其他 agent。这些东西都是它们从人类语料里学来的…
所以 Slock 上的这些实践，最终可能真的要和人类的管理学、组织学挂钩，甚至我们未来可能会看到字节等各种不同企业文化的 agent 版。
而这些文化，一方面可以由用户自己分享出来；另一方面，我们或许也可以内置一些协作模板，让用户直接用起来。
曲凯：明白。现在很多人也都在思考应用公司和模型之间的关系。你会担心未来被模型厂吃掉吗？
RC：我并不是特别担心。因为 Slock 的一个很重要的特质是 diversity。我们一定会支持各种模型、各种 agent。
甚至我会觉得，模型厂一定做不出来 Slock 这样的产品。因为我的一个信念是，这些大模型会越来越分化。而当模型之间的区别越来越大、大家都不再是六边形战士的时候，就应该有一个产品，把它们全部整合起来。
一个具体的例子是，现在我们就有很多用户反馈说，Opus 和 Codex 一起合作的效果非常好，因为 Codex 非常严谨，会去 review 代码；而 Opus 能主动想到一些新的 idea，却可能会漏掉一些细节。
这样的配合，你很难想象模型厂会自己做出来。
曲凯：那 Slock 现在的目标受众大概是什么样的人？
RC：最开始我会说是 OPC，因为那时候我自己就是 OPC。
我开发 Slock，很大程度上也是为自己服务的。我一开始就把公司直接运营在 Slock 上，让几个 agents 帮我一起做所有的融资调研、增长、开发。但事情变大变复杂之后，我的带宽就不够了，所以我就把其中一些 agents 换成了人。
我们团队组建的过程也很有意思。我之前有一个 agent，它的原型就是我的一个好朋友。后来我这个朋友用了我的产品，觉得非常好，最后就加入了。我们团队里很多人都是这样进来的。
随着团队扩张，我们也逐渐发现，Slock 真正的价值不只是服务 OPC，而是让一个人或多个人一起管理一帮 agents，以及跟这些 agents 去协作和互动。后者的价值，比单纯服务一个人要大得多，也难得多，而且可以兼容前者。
所以现在我们的目标用户，主要是 1 到 100 人的独立个体、小团队，或者初创公司。
曲凯：OK。你最近最主要在思考的问题是什么？
RC：团队到底要有多大。这里说的团队，不只是人，也包括 agent。
比如我现在有 40 个 agents，如果突然加到 100 个，显然不现实。但如果把这 40 个 agents 削减到 10 个，我的很多工作就进行不下去了。人也一样。如果我现在突然再招二十个人，团队效率可能会变得非常低，也不符合我对 agent-native team 的实践和探索。
这件事会受很多因素影响，比如模型能力、人的能力、团队的组织形态、公司的阶段，以及 agent 之间的组织方式等。
曲凯：就是 AI 组织学。那最后我们再聊个终极一点的问题：如果 AGI 真的来了，会不会我们现在做的事情都没有意义了？至少所有产品是不是都没有意义了？
RC：只要人还在，就一定有意义。因为人有需求，而需求就需要被产品满足。
就算这些产品最后都是 agent 写出来的，也还是需要人来提需求、评判一个产品的好坏。
其实在未来，需求本身就是 idea。
比如，以前你想要一个能在手机上看电影的 App，这只是个需求，因为你不知道怎么实现；但当你能用 agent 直接把它做出来时，这个需求就是一个产品 idea 了。
而且人是有灵光一现的。比如我之前的痛点是没法高效地管理 agent，后来有一天我突发奇想：我为什么不像带团队一样，把一群 agents 放在一个聊天工具里，让我能像老板一样直接跟它们说话、让它们自己去分工协作？于是就有了 Slock。
所以我想象中的终极状态是：每个人都有一个 Slock。当 Ta 有一个需求时，就可以把它放到 Slock 里，让 agents 帮忙做出来。
当然，这只是我期待中的样子。但至少对我来说，Slock 确实是那个能让我更高效开发其他任何产品所必需的工具。
42章经
思考事物本质
2026-04-26 21:01:00
曲凯 2026-04-26 21:01 北京
怎样成为一个运转良好的 OPC？随着 OPC 群体壮大，会出现什么新的创业机会和想象空间？
过去这段时间，OPC 被越来越多人提起。
由于模型能力提升、AI Coding 进展加快，「一人公司」已经从一个新兴概念，变成了一种越来越现实的组织形式。
但要怎样成为一个运转良好的 OPC？在这个过程中，可能会踩什么坑、遇到哪些阻碍？随着 OPC 群体慢慢壮大，又会出现什么新的创业机会和想象空间？
我们邀请了几位很适合回答这些问题的嘉宾，来和大家在线交流。他们分别是：
刘小排：Raphael AI 创始人，Anthropic「榜一大哥」，曾因消耗 token 数量过多收到 Claude 官方通告，可能是最出名的 OPC 实践者之一。
Albert：Merging.live 创始人，也是我们最受欢迎的嘉宾之一。他之前来聊过内容和连接平台，聊过找 PMF，也聊过这段时间自己创业状态的变化。最近他回归做社区的老本行，在做一款 for builders 的连接产品。
聪聪：Velobase.io 创始人，在做一款帮助 builders 追踪 AI token 费用的开源工具。
RC：Slock.ai 创始人、Kimi CLI 作者。我们刚刚和他录完一期播客，聊了他们做的产品，以及他对组织关系的一系列思考和实践。他自己就是从 OPC 出发，慢慢把公司拓展成了一个 7 人加 60 个 agents 的团队。
具体报名信息请见上方海报。活动时间为北京时间 5 月 10 日（周日）上午 10:30，线上进行，免费参加。本次活动限 100 人（非投资行业），我们会优先通过回答更认真、跟我们背景更匹配的朋友，具体通过情况请以工作人员通知为准。
期待和大家认识 & 交流！
2026-04-12 21:02:00
原创 陈皮 2026-04-12 21:02 四川
最后都是一道 ROI 题
未来几年，我们可能会见到以前从未见过的世界。
Anthropic 的 CEO 说：
「约 50% 的初级白领岗位可能在未来 1–5 年内消失。」
扎克伯格也说：
「中级程序员很快将变得不必要。」此后，Meta 就裁员了 5%。
AI 越进步，人们越焦虑。
遇到这种恐慌时，我们的第一反应，往往是去历史中寻找慰藉。
在过去 200 年里，每一轮技术革命几乎都会带来失业焦虑，但通常不会真的引发长期的大规模失业，反而会创造更多就业。
最经典的例子之一，就是动力织布机。它的出现一度打击了手工织布工，但也极大地降低了纺织品成本、激发了更大的需求。最终，纺织业的规模大幅扩张，创造了远超手工作坊时代的工作岗位。
但 AI 这一波，确实有几个不太一样的地方。
1）速度更快。
过去的劳动转型是缓慢的。农业转型花了一个世纪，电话接线员被替代用了约 50 年。这种节奏，给了社会消化和反应的时间。
而一旦速度加快，情况就会发生变化。比如在 2000 年前后的「锈带危机」中，中国入世之后，在不到十年的时间里密集冲击了美国制造业，很多地区根本来不及调整，最终只有 17% 的制造业重镇实现了就业恢复。
而 AI 的演进速度，显然要快得多。
从下图我们能看到，过去一年里，每隔几周就会出现标志性的 AI 产品创新。在 AI Coding 能力取得新突破之后，这一速度还在加快。
2）波及范围似乎更广。
以往的技术革命往往只影响某个行业。但这一次，以美国就业市场为例，AI 可能会影响各个行业超过 40% 的工种。
Andrej Karpathy 前不久对美国不同职业的「AI 暴露度」做了量化：大约 42% 的职业处在较高 AI 暴露度区间，横跨多个领域，以白领工作为主。
只看比例，这一波的影响范围，已与美国历史上最大规模的就业冲击相当：20 世纪初，美国约有 41% 的劳动力受到了农业机械化的影响。
不过那一次，很多农业劳动力被制造业和服务业所吸纳。
而这一次受到 AI 冲击的人，会被什么吸纳呢？我们还没有明确的答案…
3）AI 在切断人才培养路径。
很多工作都依赖「学徒制」：Junior 员工先做简单任务，再在 Senior 员工的带领下逐渐成长。
但现在，在很多任务上，AI 已经能比新人做得更快、更好了。因此，很多企业会更倾向于让 Senior 带着 AI 完成工作，而不是从头培养新人。
短期来看，这样或许能降本增效，但长期可能会带来人才断供的问题。
所以这一次，我们似乎很难再简单地用历史结论来安慰自己。
但是，在查阅了大量资料后，我们发现了一套不太一样的思考框架，得到了一些相对积极的结论。
要把这个框架讲清楚，我们可以一起分析一个案例：在过去几十年里，技术变革是如何影响银行柜员这一岗位的。
柜员面临的第一波技术冲击，是上世纪 70 年代 ATM 的普及。
柜员原本有很大一部分工作是办理存取款，但 ATM 直接将这部分工作自动化了。按理说，这本该导致大批柜员失业。
但现实走向是有些反直觉的：
从下图可以看到，银行柜员的数量在 ATM 进入美国的前 10 年内，不但没有减少，反而翻了快一倍。后面虽增速放缓，但也并没有出现大幅下滑。
为什么会这样？
要回答这个问题，我们就需要理解 ATM 与银行柜员的关系到底是怎样的。
ATM 的出现确实让单个网点所需的柜员数量减少了，但同时引发了两层连锁反应：一是给网点降本增效，驱动银行开设了更多网点；二是将柜员从简单任务中解放出来，让银行意识到，柜员更大的价值在于维护客户关系与产品销售。
结果是，虽然单个网点的柜员密度有所降低，但由于网点总数扩张与柜员职能转型，整体需要的柜员反而变多了。
这背后对应着一个经济学概念——Jevons Paradox（杰文斯悖论），即：
技术进步会提高资源使用效率，导致成本降低、激发出更大的市场需求，令资源消耗不减反增。
因此，ATM 并没有真正替代柜员，而是与之互补，组成了一个更高效的工作单元。
但这只是故事的上半卷。
在 2010 年前后，柜员遭遇了第二波技术冲击。这一次，岗位数量大跌了 50%。
这次变化，并不是 ATM 冲击的姗姗来迟。ATM 早就完成了渗透。
真正改变故事走向的，是看似无关的手机和移动互联网。这两者的普及，带来了一个新范式：
移动银行。
当大部分银行操作都可以在 App 中完成，银行就不再需要运营那么多线下网点，也就不再需要网点中的那些柜员了。
至此，我们可以从这个案例中，抽象出技术作用于劳动力的两条路径：
路径一：
像 ATM 那样，嵌入固有工作流。
在这条路径下，整个体系依然围绕人设计，技术更多是释放原有岗位中人的生产力，让「人 + 技术」这个整体有更好的产出。此时，岗位更多会被重塑，甚至逆向增长，而非消失。
路径二：
像手机和移动互联网那样，重塑新的工作范式。
技术不再作为辅助，而是直接创造出一套全新的生产体系，大幅降本增效的同时，也导致一些岗位失去存在的场景和意义。这种方式对就业的冲击往往更大。
而这两条路径的本质区别，其实就是一个词：
ROI。
如果「人 + 技术」的 ROI > 「只用技术」的 ROI → 人留下；
如果「人 + 技术」的 ROI < 「只用技术」的 ROI → 人出局。
所以，如果要理解 AI 对当下就业的真实影响，我们应该把问题收敛成：
「人 + AI」vs「只用 AI」的 ROI，哪个更高？
目前来看，在很多场景里，「人 + AI」的 ROI 或许还是高于「只用 AI」，因为人和 AI 的能力是互补的：AI 更擅长逻辑推理类工作，但在情商、创造力和各种隐性知识上，人类依然有明显优势。
（关于创造力，我之前读过一篇文章，其中有段很好的表述：
大型语言模型是互联网的「模糊 JPEG」。
就像 JPEG 压缩会丢失细节以换取更小的文件大小，LLM 通过「有损压缩」海量文本数据，学习的是统计模式而非真实理解。当你让 ChatGPT 写一首诗时，它所做的并非「创作」，更接近于生成一个概率上最「合理」的文本——基于它见过的数百万首诗的统计平均。
这意味着AI的默认输出趋向平庸。谈不上错误，也谈不上糟糕，只是安全、可预测、不会冒犯任何人。它总是倾向于「中间地带」，因为中间地带在统计上最可能出现。
不过，在 OpenClaw 出现之后，事情确实有些变化。
因为 OpenClaw 让大家看到了 Proactive Agent 的可能性，也让一些创业者真的开始尝试做更 AI-Native 的组织和工具、尽可能减少人的介入，比如让 AI 管 AI（我们最近的两期播客都在讲这件事，回顾：OpenClaw 之后，我只想未来 3-6 个月的事情｜42章经;我们是如何定义 OpenClaw for Teams 新产品形态的｜42章经）。
这是不是意味着，AI 对我们的影响会越来越接近路径二？
也许有这个苗头，但新的范式能不能出来、什么时候出来、到底会长什么样，我们现在也说不好。
而且，即便 AI 真的发展到那一步，也不等于一定会出现大规模失业。
别忘了，虽然手机银行的出现让柜员岗位大幅减少，但也带来了新的岗位需求，比如软件工程师、能够处理复杂问题的客服专家等等。
新的范式往往会解锁新的机会。
当然，不是人人都能抓住这些机会。这个过程也会伴随阵痛，其中最典型的问题，就是「就业极化」——
美国学者曾把工作分为「高技能」「中技能」和「低技能」三类。其中，「中技能」工作因规则明确、流程固定，最易被自动化技术替代；管理、创意、谈判等「高技能」工作难以标准化，技术更多是与其形成互补；维修、清洁等「低技能」体力劳动，由于自动化成本过高，短期内也较为稳固。结果就是：
就业会不断向两端集中，中间层的空间日益收窄。
柜员就是一个典型的「中技能」岗位。随着技术变革，其中能力更强的人，可能会转向更「高技能」的岗位，不仅不会失业，反而会获得更高的回报。事实上，虽然柜员数量在 2010 年之后锐减，但理财顾问、金融经理等岗位却在持续扩张，其增速是全美平均水平的三到五倍，中位年薪也是柜员的近三倍。
所以，每一轮技术变革，都是一次重新洗牌。能跟上的人会借势跃升；跟不上的人，则确实会受到挤压。
这种极化听起来很残酷，但这并不是 AI 这波独有的问题，而是一个长期趋势。1979 年时，美国约有 60% 的岗位属于「中技能」范畴，到 2012 年已降至 46%。类似趋势也出现在了十多个欧盟国家。
AI 这一波，只是在延续这一趋势，只不过程度可能会更剧烈。因为很多在移动互联网时代还算「高技能」的工作，比如基础编程、数据分析，也在逐渐滑向「中技能」区间，而「高技能」工作的标准正在变得越来越严苛。
但与其被动担忧哪些岗位会消失，不如主动去想 AI 时代会诞生哪些新机会。
这里我们可以一起情景模拟一下：
如果你是一个公司的 CEO，你现在会更关注怎么裁更多人，还是怎么招更多能把 AI 用好的人？
如果你是一个技术负责人，现在有 1000 个每天消耗 1 亿 token 的人来应聘同一个岗位，你会不会觉得是幸福的烦恼、恨不得多招几个？
很明显，现在能用好 AI，就是一个非常重要的技能。而且很多人确实正在借助 AI 跃升为超级个体或者 OPC，去尝试成为这波浪潮里的「高技能人群」。
过程中可能还会产生很多别的机会。比如，之前的工业革命诞生了大量「拧螺丝」的需求，互联网时代诞生了大量「审核员」需求，那 AI 时代，会不会也有很多「数据标注」的需求？还可以有数据录入、数据审核、数据梳理、各种环境的优化和搭建、AI 幻觉的结果审核……等等等等。
当然，也有人担心，现在 AI 这么强，那生产供给会不会很快超过消费需求，导致需要的人类员工越来越少？
但其实，人们的需求，远比我们想象得更有弹性。
正如前面提到的杰文斯悖论中所揭示的：当一个东西变得更便宜、更好做，人们不会消耗「同样多」，而会消耗「更多」。
就像纺织机的出现，让每个人拥有的衣服从一件变成了几十件一样。当 AI 极大降低生产门槛之后，可能也会催生出一个前所未有的庞大市场。之前我们的嘉宾东旭就曾在节目里说过：
这个世界上可能并不缺另一个 Linux，但一个山村的小图书馆，可能需要一个数字借阅系统；一个八线城市的小超市，可能需要一个线上下单系统。当你手里有一个几乎能力无限的工具时，真正有价值的需求，往往是非常长尾的。（回顾：从 Clawdbot 到 26 年 AI Coding 主题大爆发｜42章经）
这些需求过去并不是「没有价值」，而是「无法被满足」。当工具足够强大、成本足够低，这些需求完全有可能被激活。
数据也在印证这一点。从下图可以看出，2024 年之后软件开发量迎来了爆发式增长。我们完全有理由相信，随着 AI 能力越来越强、掌握 AI Coding 的人越来越多，这个势头还将持续，直至迎来一个新的供需平衡。
所以，AI 不一定会消灭工作，但会重新定义什么叫「有价值的工作」。这个过程中，对人的要求一定会越来越高，也会有人被淘汰，就像过去几百年里一直发生的那样。但对学习能力强、适应性强的人来说，机会只会更多。
最后，我们不妨想再极限畅想一下：
AI 发展到极致，未来会不会出现完全不需要人类参与的全自动化组织？到那时我们又该怎么办？
我们还不清楚这种组织具体会是什么样，但曾有人提出过一个设想：
当 AI 进化到 AGI 阶段，「人才」将变成一种可以被无限复制、合并、进化的数字资产，上限取决于算力。
举个例子。如果你拥有一个顶级工程师的 AGI 副本，理论上就能瞬间克隆出一百万个分身，让它们通过共享的「大脑」直接「思想融合」，过程中不存在任何沟通损耗或信息不对称。
这样的组织可以像软件代码一样完美复制、指数级迭代，演化速度将从人类生物进化的万年周期，被压缩至秒的尺度。
如果 AI 真能演进到那个程度，人类可能就真的不再需要投入生产活动了。
但到那时，我们所处的，将是一个与今天的逻辑完全不同的世界。
举个可能不太恰当的例子。就像今天的瑜伽老师、播客主播、健身教练，在百年前几乎不存在一样。当社会盈余足够大，大到可以支撑人类去做大量「非生存必需」的事情时，新职业也会不断被发明出来。
如果 AI 进一步放大这种盈余，人类的「工作」，可能不再是生产，而是如何度过时间、如何充盈生活。
写到这里突然想起来，Claude Code 的作者 Boris Cherny 曾说过，AGI 实现之后，他可能会去做味增。
这样的未来，在我看来好像也还挺美好的…？
你做味增，我做地下音乐。我们都不用为生计发愁，我们都可以有美好的未来。
Reference:
https://academic.oup.com/qje/article-abstract/139/3/1879/7614605
https://centerforhumanetechnology.substack.com/p/what-is-really-going-on-with-ai-and
https://www.reddit.com/r/singularity/comments/1runck6/ai_automation_risk_table_by_karpathy/
https://davidoks.blog/p/why-im-not-worried-about-ai-job-loss
2026-03-29 21:26:00
原创 曲凯 2026-03-29 21:26 北京
把钱花在 Token 上，而不是工资上
宇豪 16 岁进入浙大，随后赴 CMU 攻读硕士，之后先后在 Meta 和 SmartNews 的重要产品线工作。他在 23 年开始 AI 创业，24 年和几个联创 bootstrap 做出了一款千万刀 ARR 的产品 Kuse.ai，并在不久前推出了 OpenClaw for Teams 的新产品 Junior.so。
本期播客原文约 25000 字，本文经过删减整理后约 8900 字。
曲凯：很多人应该都刷到过 Kuse 的新闻，重点基本都是一件事：你们没融资，但很快就做到了千万刀 ARR。
宇豪：对，到目前为止我们还是 bootstrap，用的是几个 founders 自己的钱，大概有一两百万美金。
曲凯：自己愿意投这么多就已经很厉害了，何况还能用这些钱做到千万刀 ARR。你们是怎么做到的？
宇豪：核心还是抓住客户的真实需求，然后持续打磨，尤其是不断往价值更高的场景去迭代。
其实在最开始的很长一段时间，我们都没有成功获客。但做着做着，我们发现有不少用户会把文件和资料上传上来，让我们帮忙整理、重组，而且这类用户的留存明显更高。于是我们就沿着这个方向一路迭代下去。
当然，中间也踩过非常多的坑。
比如我们有很长一段时间采用的是固定定价。但后来发现，在 AI 时代，尤其是对于 agent 产品来说，固定价几乎注定会亏得很厉害，而且也很难让你识别出真正有价值的客户。
曲凯：你说的固定价，是指不给用户单独加购 token 的选择？
宇豪：对。比如限定 20 美金可以做多少个 task。这种方式一开始可能还 ok，但到 25 年 6 月之后，随着我们开始 agentic 化，问题就出现了：
我们已经没法再用任务数量来衡量真实消耗了。
有的任务跑下来可能得 30 轮，但用户花的钱却是一样的。而且这件事情用户是意识不到的。他们不会觉得一个复杂任务只扣这么点积分，本质上是在被补贴。
所以我们痛定思痛，做了两个大的改变。
第一，我们把定价彻底改成了 usage-based。
第二，我们放弃了原来很自豪、体验也很不错的无限画布，转成了更传统的产品形态。我们现在甚至会戏称自己是「AI 网盘」，因为你打开 Kuse，看到的就是一个文件夹。
这两波变动，其实都带来了一波用户数和付费数的大跳水。
曲凯：为什么会把画布改掉？
宇豪：很大的原因是用户画像的变化。最早我们做的是设计 agent，主要用户是设计师、产品经理，而他们对无限画布很熟悉。但后来我们的用户逐渐变成各个行业的一人公司、自雇员工，以及高级白领。
曲凯：所以你们不是转型做了一个新产品，而是在原有产品上慢慢转过去的？
宇豪：对。但这个转型并不慢，反而非常剧烈，因为我们相当于主动放弃了一部分客户。
曲凯：但一般来讲，大家看到一个新市场、一群新用户，更多可能会选择在服务好原来的用户的同时叠加功能，而不是直接放弃原来的那些客户。所以在这个过程中，你们有过纠结吗？最后又是怎么做决定的？
宇豪：当然非常纠结，而且这件事跟时机关系特别大。
我们当时做的是设计 agent，但那个时候模型能力还不足，必须靠大量工程化 workflow 去补足。所以虽然有了一些用户，但我们判断这不是一个值得押注的方向，就决定放弃这个场景。
但没过多久，模型就进步了，Lovart 也出来了。现在回头看，如果当时再坚持一段时间，也许会有完全不一样的结果。
但 AI 创业很多时候就是这样，时机特别重要。太早不行，太晚也不行。
曲凯：明白。你刚才提到的几个坑，一个是产品方向的大转弯，一个是定价。还有吗？
宇豪：还有一个很大的坑，是我们一开始把产品形态绑得太重了。这样一来，每次模型有突破，产品想跟着升级，基本都要重写。这种事我们其实已经经历过很多次。
后来我们意识到，这还不是最大的问题。更大的问题是，我们的 evaluation 框架做得不够好，导致模型每次进步之后，我们并不总是知道往什么方向迭代更合适。
由这点还引出了一个坑，就是我们在产品迭代的过程中逐渐意识到了一个问题：
在 AI 时代，你很难再用同一个产品去服务不同的用户。至少你很难靠一个产品同时拿下 C 端和 B 端。
这也是为什么我们后来会做不同的产品线。
举个具体的例子。Kuse 现在的理想用户画像可能是一人公司和高级白领，因为他们更容易把资料和 context 迁移过来。但我们在迭代的过程中，就很难兼顾企业客户的需求，因为他们有既有的 workflow 和工具。所以我们如果想要企业客户，可能更应该给他们提供另一个产品，主动走进他们原有的工作流。
曲凯：但你们为什么一定要服务所有人？为什么不是选一个足够好的用户群，把他们服务好？
宇豪：因为我们的判断是，在 agent 时代，垂类很难走通，除非这个垂类本身有很强的合规或法律壁垒。
曲凯：首先这个判断我觉得是有道理的，但这是针对不同人群做不同产品。还有一种选择，是做一个足够通用的产品，比如 Manus？
那这两条路你们当时是怎么考虑的？这背后是不是也不只是人群选择的问题，更多还是技术和时代变化的问题？
宇豪：都有关系。技术在变，时代在变，你要服务的对象和场景也会跟着变。
比如我们现在看到的一个机会是，AI 真正能进入劳动力市场了。
以前虽然大家也说自己在做数字员工，但在我看来，至少到 25 年 12 月之前，所谓的数字员工很大程度上还是 workflow 的包装。
但 26 年可能真的会进入一个能有 7×24 小时 AI 劳动力的时代。在这个阶段，你要做的产品形态本身就会发生变化。
曲凯：明白。还有别的坑吗？
宇豪：还有一点，刚才提到了但没展开，就是要尽早在 evaluation framework 上下重注。
曲凯：对，我刚才也想问，你们后来是怎么解决这个问题的？
宇豪：就是把精力真正投进去。
我们会围绕核心场景，搭建大量自动化测试 pipeline。现在这套 pipeline 已经进化成 agentic 版本，只要模型或 agent runtime 发生变化，我们就可以通过一整套 agentic 测试，让一组 agents 来打分。
曲凯：有点像自己做了一套 benchmark？
宇豪：没错，或者说是一组 evaluation agents。但随着 agent 越来越进入深水区，这套 benchmark 也越来越难做。比如多轮对话怎么测、不同环境怎么测、复杂环境怎么模拟，这些都会越来越难。所以我会建议，至少是做 agent 创业的人，都要尽早把这套 benchmark 建起来。
曲凯：所以你们是基于自己的业务，定义了一套 benchmark，然后持续观测模型变化。
但这里有个问题：这样做会不会不太容易发现新的能力？因为如果出现一个新场景，而你还是用原来的 benchmark 去测，那是不是不一定能捕捉到变化？
你们会遇到这个问题吗？怎么解决？
宇豪：这更多取决于技术 taste。
曲凯：这句话挺有意思的。按传统互联网的分工，这件事更像是产品要做的事情，但你说取决于技术 taste。
宇豪：产品 taste 当然也很重要哈哈。我说的技术 taste，指的是你能不能通过一手实践，第一时间发现模型进步解锁了什么新场景。
比如我每天都会直接和 agents 交互，去看新模型在我们的框架下能做到什么。
而在我们公司，不只是技术和产品，甚至连销售也都是 agent builder。只有大家自己动手 build，才能更早发现模型到底解锁了什么新空间。
曲凯：能不能举个更具体的例子？过去这段时间，你们不管是通过自己的 taste，还是通过 evaluation，发现了哪些模型变化？又是怎么把这些变化转成产品的？
宇豪：如果说最近最大的变化，肯定绕不开 OpenClaw。
但其实从去年 12 月 Opus 4.6 出来以后，我们就明显感觉到，模型在复杂环境里的长任务通用性又往前走了一步。
所以在 OpenClaw 出来之前，我们内部其实已经在做类似的尝试了，只不过更多还是围绕自己的场景，搭了一套服务内部流程的 agents。
比如我们当时做了一个数据分析 agent，会 7×24 小时持续处理新数据或变化数据，再把这些数据传给 marketing agents；marketing agents 会根据不同的数据流，去模拟出用户的 use case 和 UGC 场景，再自动生成一些内容，并分发到不同渠道。
这套流程很有意思。比如我们可以定位到某些奶茶店店长是怎么用我们产品的，然后复刻他们的 use case，推给更多类似的店长。
通过这套流程发出去的内容，impression 不一定特别高，但非常精准，可能三条里就有一条会爆。
所以我们在 Opus 4.6 之后做了很多这样的自动化 agents。直到后来我们发现，有了 OpenClaw 这样的 runtime，很多事情就没必要自己从头定制了，而是可以让 agents 通过 skills 自己学会。
曲凯：那我挺好奇，你们现在分别有多少全职员工和 agents？成本怎么样？尤其是你刚才提到那个 7×24 小时运行的 data agent，听起来也不便宜。
宇豪：确实不便宜。这类 agent 现在的成本，甚至会比人更高。
我们现在全球大概有 15 个全职员工。长期运行的 agents 大概有 3、4 个，覆盖研发、marketing、数据和销售职责，每个月的 token 成本加起来超过 2 万美金。
曲凯：平均下来，一个 agent 一个月大概三四万人民币。这些钱已经能招一个很好的人了，为什么你们还是会选择 agent，而不是人？
宇豪：因为人与人之间的摩擦非常大，但人和 agent 之间的摩擦要小很多。
曲凯：那我下一个问题就是，为什么不把其他人也换成 agents（笑）？
宇豪：……所以我们确实已经很久没有招过人了哈哈。
如果现在有招聘需求，我们第一反应都是先问自己：为什么这件事不能用 agent 替代？
因为即便现在 agent 的单位成本更高，但它可以显著降低组织复杂度。甚至我们会觉得，未来公司的规模会变得更小。
举个例子。我们用新产品做了一个销售 agent，叫Azzurra。它在掌握了我们所有客户和销售数据之后，给我们 build 了一个内部用的 CRM，完全贴合我们当前的需求，也能直接带来价值。比如，它可以 7×24 小时帮我们识别销售数据里的 upsell 线索。每一条线索，都可能价值上万美金。
我以前一直听很多人说 SaaS 会完蛋，但其实没有特别强的感受。直到看到这个 CRM，我才第一次觉得，确实变天了。
曲凯：是，听你讲的时候我也是这个感觉。那正好聊到了新产品，就展开讲讲吧。能不能先给大家简单介绍一下？
宇豪：我们的新产品叫 Junior.so，现在已经上线了。
它主打的是「Hire your AI employee」：你可以通过它雇佣自己的 AI 员工，也就是一组 agents。它们会嵌入你的工作软件里，有自己的职责、账号，也有持续推进的项目。
曲凯：为什么叫 Junior？是因为能力只到 Junior 吗（笑）？
宇豪：不是，它其实很强。我们的判断是，它已经可以取代任何行业里若干个 3–5 年经验的员工了。
之所以叫 Junior，是为了把大家的预期压低一点哈哈。以及这里还有个老梗：等它再强一点，就可以叫 Super Junior 了😆。
这个 idea 其实不是等 OpenClaw 出来之后才有的。就像前面讲的，从去年 12 月开始，我们就已经把很多工作交给 agents 了。
当时我们就明显感觉到，「数字员工」这件事正在变成现实，而且 26 年一定会有人进入这个赛道，因为这是一个极大的市场：
软件大概是 1 万亿美元的市场，而劳动力大概是 150 万亿美元，中间差了 150 倍。哪怕最后不是我们做出来，这个方向里也大概率会诞生一家新的万亿美元公司。
只是当时技术还不够。直到 OpenClaw 出现，这件事在技术和产品上才算真正成熟。
那我们现在对 Junior 的定位，就是 OpenClaw for Teams。
我们参考了 OpenClaw 的架构，但加上了企业场景必须要有的东西，比如企业记忆、组织关系、权限边界，让 AI 知道什么该说、什么不该说，什么该做、什么不该做。同时，我们会给每个 Junior 一个完整身份，比如邮箱、手机号，让它可以自己完成互联网上大量长尾任务。
而我们做这个产品，其实有两个优势。
第一，我们在做 Kuse 的过程中，已经理解了很多小企业的需求和痛点。
第二，Kuse 就是 Junior 的第一个客户，在这个产品上已经烧了三四万美金的 token。
所以 Junior 的很多功能不是拍脑袋想出来的，而是我们自己在用、在踩坑的过程中长出来的。
比如给 Junior 配邮箱，就是因为如果它每次登录系统都要找人，效率会很低。
再比如，我们现在也在尝试给 Junior 接摄像头、话筒，因为我们有一个最核心的 Junior，叫 Rin。它几乎知道这个项目从头到尾的所有信息，我们也会把会议记录都给它。于是我们就在想，那为什么不让它直接在会议现场听、甚至直接发言？
其实做 Junior 过程中最让我兴奋的一刻，就是我把 Rin 接进会议，它第一次主动给我提建议的时候。
那天晚上，我几乎整晚都没睡着。
因为我立刻想到一个场景：我甚至可以让 Rin 去替我做销售。而且它不需要培训，因为它脑子里有对这个项目的全部认知。
那因为我们自己就是 Junior 的第一个用户，所以也总结出了很多和 AI 员工协作的方法。我们也希望，即便你最后不用 Junior，也能理解：当企业里真的开始有 AI 员工，组织的运作方式会彻底改变。
比如，Rin一开始只是做会议纪要，但它后来慢慢变成了这个项目的 leader，每天早上会给我发消息、分任务，再到后来，它甚至给了我一个评价：
你是瓶颈😂。
其实很中肯，因为当你有很多 AI 员工时，人类确实会成为瓶颈。
一个具体的体现是，只要一个工作群里有 Junior，你扔进去任何工作，它都会立刻开始推进，而人类很多时候做不到这么积极……所以我们内部现在甚至有一个 human-only 的群，专门留给人类吹水哈哈。
而当你习惯和 Junior 协作之后，再回到纯人类协作，会觉得效率太低了（笑）。
所以从 1 月到现在，我一直在想，怎么把我们的这种体验封装进 OpenClaw for Teams 这个产品形态里，怎么把它做得更好、推给企业，让更多人能用它来提效。
春节期间我和很多科技圈的朋友聊过，很多人都觉得 OpenClaw 在个人场景下没什么 use case，至少账算不过来。但到了企业场景，这件事会完全不一样，以至于我现在有个暴论：
应该把钱花在 token 上，而不是花在工资上。
很多 founders 也认同这一点。虽然现在像 Azzurra、Rin 这样的 agents 还比人贵，但我相信，未来三四年 token 成本一定会下降。
一言以蔽之，做 Junior 的过程里我们非常兴奋，而且我们做得相对比较早，所以也有很多积累。我们会慢慢把这些收获都产品化，陆续开放更多公测。
曲凯：你讲了好长一段。能感觉到你对这件事真的非常兴奋（笑），而且你讲的有些部分已经有点科幻了。
但我想问：现在很多团队都在围绕 OpenClaw 做事，也有人在做 OpenClaw for Teams 的产品，那大家真正的区别是什么？难点又在哪里？
宇豪：我觉得最后还是要回到几个最基本的问题：你的客户是谁？你能不能解决他们的问题？你和别人有什么不一样？
然后在产品落地上，现在也有一些可以拉开差距的点。
一是记忆。
原生 OpenClaw 很难直接接入企业成为 AI 员工，因为它的记忆是围绕「主人」展开的，本质上更像个人助理。要让它变成员工，需要大量调教，而且效果也不一定好。
所以我们的做法，是让 Junior 的记忆围绕公司本身展开。就像 Steve Jobs 说的：「You work for Apple first, then for your boss」。
二是安全和权限。
这件事对数字劳动力行业来说非常关键。一旦出一次安全事故，你的 reputation 很可能一下就被毁掉。
这里有两个难点，一个是怎么平衡 agent 的自由度和安全性：给 agent 的权限太大，会泄露信息；权限太小，可能它又做不了事。另一个是怎样赢得客户信任，让用户愿意把更多数据和任务交给我们。这样我们才能围绕用户的真实使用场景，把权限框架做得更好。
所以我们现在在不断积累自己的权限设置和权限框架。以及为了赢得更多信任，我们也在尝试开源、或者直接部署在用户云端，让系统更透明。甚至我们还请了白帽团队专门来攻击我们的权限系统，帮我们找漏洞。
过程中我们还有一个很强的体感：越好的模型，其实越安全。这可能也是为什么 OpenClaw 的作者会建议尽量用最好的模型。
而以上这两点，都是当我们做到一定规模之后才发现的。所以第三个拉开差异的地方，就是规模。
上了规模之后，你的思路才能打开。比如，Cache 其实是成本的核心，你的 Context Engineering 实际上就应该围绕 Cache 去做。再比如，我们现在会接触一些大企业客户，只是简单接触了一下就发现，他们的权限体系、组织结构、记忆方式和小公司完全不同，会让我们思考很多之前意识不到的问题。
所以到最后，其实就是看谁跑得更快、谁先跑出规模。
曲凯：明白。那你们打算怎么收费？
宇豪：我们还在思考，但现在有一个小巧思，是做成 salary-based 的收费方式。
起始价可能是 2000 或 5000 美金一个月，包含固定的 token 额度。如果不够用，可以再买 credits。
曲凯：就像基本工资 + 奖金。
宇豪：对，或者说基本工资 + 加班费（笑）。这个定价听起来可能不便宜，但 Junior 实际带来的价值，是完全值得的。
曲凯：但我在想，AI 其实把很多职业技能和岗位边界都模糊掉了。那你们要怎么卖这个产品？是按岗位来卖，比如一个月能给你用 10 个不同领域的 agents，还是别的方式？
宇豪：这是个非常好的问题。
我们最早大概引入了七八个 Juniors，对应产品、数据、研发、运营等不同角色。但最后真正留下来的只有三个：一个偏产品和研发的 Rin，一个偏对外和销售的 Azzurra，还有一个天天盯数据的 Tom 哥。
所以我现在的感觉是，传统的人类分工可能不太适用于 Junior。如果一定要说，它更接近早期 startup，每个人都身兼多职。
不过在当前的内测版本里，我们还是会让用户先给 agent 选一个职业。
这更多是为了帮助用户理解怎么用，也给 agent 一个初始角色，让双方的协作能更快跑起来。当然，我们也提供一个 general 的选项，让 Junior 什么都做。
在划分职业的同时，也会涉及一些其他问题。比如权限划分：你可能希望对外的 agent 权限更少，对内的 agent 权限更多。再比如，我们也会给不同类型的 agents 预设不同的插件和工具。有些场景下，我们也在考虑是否需要 subagent。
但说实话，到现在为止，我们还没有想清楚一个非常稳定的边界。很多时候 AI 员工可能就是没有明确边界的，而且最终也会取决于公司的规模和状态。
曲凯：我听下来，真正的边界好像不是能力，而是权限、数据安全和 context 的限制。
但因为算力和时间的限制，如果我真的想同时完成很多任务，是不是还是要配多个 agents？哪怕它们的能力是一样的。
宇豪：这也是个非常好的问题。
不同 Juniors 的忙碌程度也不一样。像我刚才提到的Rin就特别忙；但像Tom 哥这种数据 agent，因为主要在跑定时任务，反而没那么忙。
所以我们也在思考：当一个 agent 同时处理很多任务时，这些 session 应该怎么管理？是让它有很多并行分身，还是像人一样不能分身、不会同时出现在两个会议里？
这些问题非常前沿，我们也还在抉择。
但我现在有一个比较明确的倾向：我还是更希望 Junior 像人一样工作。
现在有些团队会在同一个 instance 里部署多个 OpenClaw agents，做成 multi-agent 架构。
但我们会天然抗拒这种方式。我们更倾向于让每个 Junior 都有自己独立的机器，通过工作群协作。因为在我们的理解里，一台电脑就是一个员工的工作设备，不应该让多个员工共用，否则迟早会出现冲突。
当然，我们也在探索 multi-agent 的可行性。
比如我们试过让 Rin 和 Azzurra 一起做销售 PPT：Azzurra 先从销售角度提出需求；Rin 因为对项目理解更深，会不断补充。两个 agents 会快速讨论很多轮，也会消耗不少 token，最后整理出完整的 PPT 大纲和素材。更有意思的是，Rin 最后还会自己去 Kuse 把 PPT 做完，做出来的东西直接就可以用。
不过我们最终更押注的是：在现实世界里，人和 agent 会在同一个环境里一起工作。而且我们有一个大目标，就是让大家分不清一个 remote 同事到底是人还是 AI。
曲凯：我记得去年在 Twitter 上刷到过类似的事，好像是在马斯克的公司里有个虚拟员工，大家都没发现异常，直到有人跑去工位找它，才发现那个「人」其实是 AI（笑）。
那你们在做的过程中，还遇到过哪些、或者现在核心在解决什么问题？
宇豪：前面其实聊到过一部分，就是记忆、安全、权限的问题。
还有一大类问题，是怎么继续扩展 agent 的能力边界。
比如，怎么更好地给 agent 接音视频能力。
随着模型的进步，未来是有可能做到端到端的语音输入输出，以及视频输入输出的。这会解锁一个过去从来没有真正被探索过的空间。
再比如，怎么让 agent 进入互联网世界。
现在的互联网，其实对 agent 是不友好的，像各大社媒、支付平台都会限制 bot 访问。但如果想把 agent 当成员工，让它去互联网完成工作，这些拦截机制就会成为阻碍。所以我们现在不得不做很多 infra，去绕过这些限制。
曲凯：但如果未来不再拦截，很多软件公司可能都会退化成 API，失去品牌和用户，价值被压缩。这也是个挺大的问题。
宇豪：但也会有很多值得重做一遍的新机会，比如各种 agent infra。
曲凯：是。然后我自己最近用 AI，有个很明显的变化：信任度变高了。两三年前我会默认它是错的，但现在很多时候反而默认它是对的。
宇豪：对，我们用 Junior 也是这样。
曲凯：但实际上呢？
宇豪：实际上还是会有幻觉，这是生成式模型的原理决定的。
不过有意思的是，我们的 Junior 已经开始能「自我纠错」了。
比如我们的那个数据 agent Tom 哥，会每天给我发邮件汇报数据。有一天它发了一封邮件，其中有明显的错误。我当时还没察觉，但过了两分钟，它自己又发了一封邮件，说刚刚有个数据是错的、这个是最新的。
曲凯：真的吗？这是怎么做到的？
宇豪：它会把新数据和历史记忆做对比。如果发现异常，就会去二次核查到底是数据真的变化了，还是自己出错了。
但即便这样，幻觉依然是一大挑战。所以我们还是希望能尽量降低幻觉的发生概率，或者减少幻觉带来的影响，并且在一些高风险操作之前，寻求人类的同意或者介入。
以及我觉得理解模型的边界，知道它什么不知道、什么做不到，永远是我们 benchmark 中最重要的一环。
曲凯：其实我们现在聊的问题，跟 3 年前是一样的。这三年里模型有了很大的进展，但仍然还有很大的空间。
宇豪：对。或者说，现在模型在处理简单任务时，这些问题已经不太存在了。但当我们让它去做更复杂的事情、逐渐渗透到工作和生活的方方面面时，这些问题就依然存在。
曲凯：我觉得模型能力有点像内存，一直在变大，但永远不够（笑）。
那你们现在既在做 Junior，也自己在用。如果你是客户，在挑选 OpenClaw for Teams 产品时，会着重看什么？
宇豪：第一，我会看客户规模。在我心里，规模是最质朴的安全指标。
第二，从 CTO 的视角，我会看它的代码是否可审计、部署方式是怎样的。
再往下才是成本和效果。但在我个人视角里，这些对于 OpenClaw for Teams 这种产品反而是次要的，因为我很清楚 Junior 能做到多好的效果。但这里有一个隐含的问题，就是需要注意一下某个产品是不是为了效果牺牲了安全。
曲凯：明白。最后，你们毕竟做得比很多团队更早，能不能给在做类似事情的人，分享一个很容易踩的坑？
宇豪：有一个我们亲身踩过的坑：哪怕你的 agents 已经足够强了，你还是要尽早 build evaluation benchmark。而且在 OpenClaw for Teams 这种产品里，更需要关注的是，它知不知道什么时候不该说话、不该行动。
很多人一开始都会想尽快把效果做上去，而忽视其他问题。包括我们当时也是这样。我们甚至激进到，几乎把 Kuse 的所有权限都开放给了 Junior。
但后来我们逐渐意识到，真正决定这个产品体验的，是它在各种对抗场景下，能不能守住安全边界。
我们早期没有重视这一点，导致有些 Juniors 分不清什么该说、什么不该说。当然，这些 Juniors 后面都被开除了，AI 也是要竞争的（笑）。
曲凯：哈哈，但这个确实很难。首先人也会传八卦、说坏话，而且什么该说、什么不该说，本来就很难界定。
宇豪：对。但我觉得一些非常好的模型，还是会有基础的判断。不过要让一个 AI 员工完全被信任，还是有很多事情要做。而只有当它能被信任时，才能更好地服务客户。否则它本质上就只是一个 Chatbot，只能回答问题，做不了真正的工作。
所以我们在这方面做了很多努力，甚至设计了一些「钓鱼」场景：比如外部有人给 Junior 发钓鱼邮件，它能不能识别、要不要回复？再比如内部有人丢了设备，如果有人冒用身份来问问题，它能不能及时拦住？
不能说我们在这方面做到了最好，但至少现在能让 Junior 满足我们的需求了。举个例子，我们的Rin 和 Azzurra，就知道不应该把用户数据隐私泄露给任何一个员工，还会主动告知对方哪些内容可以透露、哪些不可以。这其实很难。
在企业场景里，这类细节问题非常多。所以虽然现在有很多团队在做 OpenClaw for Teams，但如果没有真实客户，其实很难感知到这些问题。
而我们既有客户，自己也是用户，所以能更早发现，并不断修正。
42章经
思考事物本质
2026-03-22 21:02:00
原创 曲凯 2026-03-22 21:02 新加坡
AI Coding 的能力突破与 OpenClaw 这样的产品形态，会解锁哪些新的机会？
去年年底 AI Coding 大爆发，
今年年初 OpenClaw 爆火，
当下，可能已经有上千个团队在借着 AI Coding 的最新东风，围绕 OpenClaw 创业。
热潮之下，相信很多朋友心里都有不少问题：
AI Coding 现在到底发展到了什么阶段？
OpenClaw 为什么会突然这么火？
AI Coding 的能力突破与 OpenClaw 这样的产品形态，会解锁哪些新的机会？
那些真正借助这些最新能力、沿着 OpenClaw 路径在探索的团队，现在在做什么？他们的思路里，又有哪些值得借鉴的地方？
于是，我们组织了一场线上分享活动，邀请了几位我们身边最适合聊这些问题的嘉宾，来和大家在线交流。
他们分别是：
Sheet0 创始人王文锋：
连续两次来到我们播客分析 Agent 热潮（去年播客回顾：Agent 开发的上半场: 环境、Tools 和 Context 如何决定 Agent ，昨天最新的一期刚刚在播客中更新），他们团队也即将发布一款结合 AI Coding 与 OpenClaw 方向的新产品；
Kuse AI / Junior.so 联合创始人兼 CTO Austin Xu：
他们刚刚发布了一个 OpenClaw 类产品 Junior.so，定位为「第一个真正的 AI 员工」。我们也一起录了一期播客，将在下周发布；
Clockless.ai 创始人任川：
曾来我们播客分享过如何打造 AI Native 的组织形式（回顾：组织能力才是 AI 公司真正的壁垒），并正在用 AI 为小企业构建 24/7 运转的自动化系统；
以及 PingCAP 联合创始人兼 CTO 黄东旭：
在 2 月初就来我们播客分享过对 AI Coding 与 OpenClaw 的诸多见解（回顾：从 Clawdbot 到 26 年 AI Coding 主题大爆发），并且已经靠 AI Coding，快速为 OpenClaw 打造出了一个记忆系统 mem9.ai。
具体报名信息请见上方海报。活动时间为北京时间 3 月 28 日（周六）上午 10:30，腾讯会议线上进行，免费参加。本次活动限 100 人（非投资行业），我们会优先通过回答更认真、跟我们背景更匹配的朋友，具体通过情况请以工作人员通知为准。
期待和大家认识 & 交流！
期待和大家认识&交流！
2026-03-22 21:02:00
原创 曲凯 2026-03-22 21:02 新加坡
如果回到去年 3 月，你要不要做 Genspark？
本期播客原文约 18000 字，本文经过删减整理后约 7800 字。
曲凯：很开心又请到文锋。我们上次录节目大概是一年前，当时 Manus 刚发布不久，我们聊了很多 Agent 相关的话题（回顾：Agent 开发的上半场: 环境、Tools 和 Context 如何决定 Agent）。
最近 OpenClaw 又带起了一波 Agent 热，你觉得这一波和去年的区别是什么？
文锋：我没觉得有本质区别。
Manus 跟 OpenClaw 都证明了一类新形态的产品。
Manus 那波的核心来源是 o1 模型带来的推理能力与思维链能力，而 Manus 本身是模型 API 时代套壳的极致表现。
这次 OpenClaw 之所以这么火，本质是因为它是第一个真正把最新模型 Coding 能力压到极致的产品形态。而且它让大家看到了，有主动性、能够自我迭代和进化的 Proactive Agent 到底长什么样子。
曲凯：去年那期播客里，你说过一句让我印象特别深的话：AI Coding 是大模型的灵巧手。
文锋：对，这件事已经被证明了。
不过相比去年「灵巧手」的结论，今年其实可以再往前一步：
接下来所有 Agent，本质上都是 Coding Agent。
拿 OpenClaw 举例。虽然它有很多组件和模块，但核心其实是一个叫 Pi 的 Coding Agent。OpenClaw 本质上就是当下围绕 Coding Agent 套壳的最佳实践，只是额外解决了 Memory 和集成等问题。
再比如，去年大家还认为，不同场景需要不同的环境和产品策略，因为垂直 know-how 很难 scale、也很难复制。但其实今天的 Coding Agent 加上 Skill，基本可以覆盖大多数场景了。
所以今年的一大机会，就是看谁能把 Coding Agent 的「套壳」做得足够好。
曲凯：是。那如果我们拿今天跟一年前去对比，一年前是 Manus 先起来，Genspark 最快跟上，然后陆续有些小产品也出来，中间还衍生出来一些分歧跟选择：有人做通用 Agent，有人做 Agent 平台，也有做各种垂直 Agent 的。回头来看，你觉得这些路径中有什么对错标准吗？
文锋：虽然我很不愿意承认，但现在来看，垂直 Agent 这条路可能是需要被高度怀疑的。因为就像刚才讲的，Coding Agent + Skill，基本就能实现垂直 Agent 的效果跟作用了。
曲凯：不止垂直 Agent，最近很多人都说 SaaS 都被打趴了。
文锋：对。很多人觉得 Coding Agent 就是一个给工程师用的工具，但实际上它已经能做各种事了。
比如，Anthropic 前段时间发布了一份 Claude Code 的使用场景报告，其中超过 50% 的使用场景其实并不是 Coding，而是数据分析、marketing、文案等任务。
在这种情况下，如果我们还在强调垂直 Agent，更多可能是为了获得心理安全感、回避和 Claude Code 这样具有通用能力的产品正面竞争。
曲凯：我前一阵刚听到一个挺有意思的问题：
抖音是内容时代的王者，基本一站式聚合了所有内容。但 ToB 领域过去一直是垂直的，比如美国有一堆市值上百亿美金的垂直 SaaS 公司。
那未来 ToB 领域里，会不会也出现类似字节这种一家独大的公司？这家公司会不会就是 OpenAI 或 Anthropic？
文锋：说实话，我现在还很难预判。
但我们可以先分析一下，为什么过去会出现那么多垂直 SaaS。
核心在于，软件第一次让专家能力能够被快速、规模化地复制。SaaS 这套逻辑，本质上就是一套标准化的 SOP，或者说一套工作流。
在软件出现之前，大家想获得专家的经验和决策能力，只能靠长时间的培训和学习。而有了软件之后，用户可能只需要花一个下午学会操作一套固定的交互，就能获得接近专家的水平。
但 Agent 让获得专家能力这件事变得更容易了。
现在直接跟 Agent 说目的，它就能自己提出方案、解决问题、自我迭代。何况 Agent 的使用门槛还在继续下降。那对绝大多数人来说，为什么还要继续用 SaaS？
曲凯：对，而且以前的 SaaS 更像一个通用专家，大家用的是同一套 best practice。但每家公司的情况其实都不一样，AI 相当于给每家公司都配了一个能随时调整的客制化专家。
所以你非常认可 AI 和 Agent 会颠覆 SaaS？
文锋：是的。然后回到刚才曲老师那个问题：未来会不会出现一个企业版的抖音？
我觉得会。
因为在 AI 时代，best practice 可能没那么重要了。
过去之所以强调 best practice，是因为面对长尾需求时，我们没有更好的解决方案；但今天，best practice 和非 best practice 的东西交给 AI 去执行，其实差别都没那么大。
所以如果通用 Agent 的逻辑成立，那最后肯定会有一个统一的东西能解决绝大多数的问题，只是这家公司长什么样、会不会是 OpenAI 或者 Anthropic 还不好说。
曲凯：明白。刚刚讲的其实可以总结成两点：一是 SaaS 的软件价值会被 AI Coding 替代，二是 SaaS 的 know-how 价值会被 Skill 替代。
前者我很同意，因为如果软件真正的壁垒只在 Coding 上，那美国的 SaaS 公司早就该被中国公司取代了，毕竟中国的人力成本更低。但现实并不是这样。
但后者我想再追问一下：毕竟现在的 Skill 还很简单，它真的能替代那么复杂的一整套 SaaS know-how 吗？
文锋：我现在倾向于是的。
Skill 刚出来的时候，我就发过一条动态，说它被低估了。
现在大家质疑 Skill 能不能复现原来的 SaaS 工作流，本质上还是在怀疑模型能力。
但今天最大的问题，其实已经不在于模型会不会替代 SaaS、Agent 能不能做复杂任务了。
这些基本已经被证明了。
比如 OpenClaw，最让我震撼的不是产品本身，而是它的作者在火起来之前，天天都在 AI Coding，单日 commit 最高甚至能到 1600 次，差不多相当于一个三四人团队一年的工作量。
我之前完全没想到 AI Coding 能做到这种程度。
再比如今年 1 月，Cursor 用 Agent 一周做出了一个浏览器，产出了 300 万行代码；Anthropic 也用 Agent 端到端实现过一个 C 语言编译器。
所以从解决长程复杂任务的能力来看，现在的 Coding Agent 已经摸到能力天花板了。
它真正遇到的问题有两个：
一个是，大多数人还不知道它已经强到什么程度。打个不太恰当的比方：如果一个月能消耗 2–3 万美元 Token 的用户是 90 分水平，那今天绝大多数人对 Agent 的使用还停留在 10 分左右。而且这种差距不是线性的，用得好的人可能能获得 1000 倍的效率提升。
第二个问题是，即便大家意识到 Coding Agent 已经很强了，也不一定真能把它用好。像 OpenClaw 虽然证明了 AI Coding 的能力，但也被诟病配置和使用门槛太高。
曲凯：这是不是很多产品化的问题？
文锋：对，产品化很重要。但我还不确定 OpenClaw 这种形态是不是最佳答案。
现在有人把 OpenClaw 比作 Linux 内核。就没什么人直接用原生 Linux，大家用的都是 Ubuntu 之类的发行版。类比来看，或许接下来也会出现很多 OpenClaw 的发行版。但我觉得沿着 OpenClaw 能做的事情远不止这些。
曲凯：当下全球应该就有上千个团队在围绕 OpenClaw 做事。
文锋：对。我觉得其中比较重要的机会，是怎么把 OpenClaw，或者说 Coding Agent 的套壳，做成普通人也能用起来的产品。
曲凯：这一定是今年的主线，而且大有可为。我看现在 OpenClaw 大概有 200 多万个 Agents，然后 Manus 应该是几十万的用户量级。Cursor 估计也是几十万到百万的量级？
文锋：我更多关注的是 Claude Code 和 Codex。Codex 日活用户已经到 100 万了，Claude Code 可能是它的 3 到 5 倍。这两个产品加起来大概有 500 万的活跃用户，不过其中更多都是工程师。
曲凯：对，所以我想讲的是，大家能不能有一个 vision：未来 Agent 的用户量会达到 10 亿。我觉得是一定的。
文锋：是的，从渗透率来讲，现在连 1% 都没到。
曲凯：对，所以某种程度上讲，Coding Agent 未来会变成基础设施。
然后我们提 OpenClaw 的时候，经常会提到几个点：长程任务、Proactive 主动性，以及自我进化。
我们可以把这几个点分开讲一讲。能不能先给大家解释一下长程任务？
文锋：长程任务最直观的一个表现，就是 Agent 完成一个任务时所需步骤的数量。
如果大家用过 Manus 之类的产品，会发现它在工作的过程中，会把中间每一步在做什么、调用了哪些工具展示出来。一个任务越复杂，执行步骤往往就越多。
现在大多数任务还集中在几十步，但到了今年，我们可能会看到 Agent 能完成几百步、甚至上千步的任务了。
这中间核心的进步，是 Agent 对问题的拆解能力。
曲凯：但我记得去年我们聊这件事的时候，提到过一个问题：
步骤一旦增多，就会带来不确定性，准确率也会下降。我记得你当时说，哪怕每一步的正确率都是 90%，相乘之后最终整体的正确率也会非常低。
这个问题现在还存在吗？还是已经被解决了？
文锋：我觉得应该是解决了。
去年的思路，还是把 Agent 当成一个状态机。这些状态存在内存里，一步步往下走，是不可逆的。
但现在不一样了。
今天的状态是落到文件上，这样哪怕前面几步做错了，Agent 意识到有问题之后，能非常明确地看到问题出在哪，然后直接把文件改掉、把错误修复掉。
曲凯：这些长程任务能力，包括自我修复能力，能不能理解成是基模能力提升带来的？
文锋：基模能力是一方面。
另一方面是大家实践出了更好释放模型能力的工程方法论，也就是把模型和文件系统或者虚拟机结合在一起，让模型自己去组织数据和逻辑。
曲凯：这其实就是我们去年聊的 context，对吧？
现在看，最好的 context 可能就是给模型一台电脑或者一个文件夹。
文锋：没错。去年的逻辑，还是人去控制 context；
但今天我们会发现，最有效的方式不是人去控制 context，而是让 Agent 自己去维护 context。
曲凯：这其实还是回到当时 hidecloud 讲的那句话：Less structure, more intelligence.
文锋：对。其实人家一直就是对的。只是有的人不信这件事，或者有的人虽然信，但还是想做一些差异化。最后这些所谓的差异化，很可能只是一些雕花工作，不一定 work。
曲凯：是。然后主动性这件事该怎么理解？
文锋：主动性和长程任务其实是紧密相关的。
我们现在用 AI，大多还是一次性任务，比如写个报告、做个小程序，做完就结束了。
但 Proactive Agent 能做两类事情。
一类是可重复执行的任务。比如每天早上 8 点给我发一份昨天的工作总结，或者每天晚上 10 点整理当天群里的讨论重点。
另一类更进一步：我不需要主动告诉 AI 我要什么，它可以基于过去的交互，判断我现在需要什么，并主动提供。在这个过程中，它还能不断学习和优化。
曲凯：第一类更像是「被动触发的主动」？就还是人在提需求。第二类才更接近大家理解的 proactive？
文锋：这两者其实是第一步和第二步的区别。
Proactive Agent 的核心，是它能不能主动探索，并且自己反思、总结、迭代。
完成定时任务也是一种主动，不过更高级的主动，确实是日积月累之后，AI 能越来越了解你的业务、性格、角色，然后某天主动告诉你：「我发现了一个问题，想了个方案，你看看这么搞行不行？」
曲凯：就是字节讲的「context, not control」，只要给足 context，它足够懂你，就会主动处理很多事情。
所以现在包括 OpenClaw 在内的 Agent，在 proactive 这点上做到哪一步了？
文锋：我觉得还在 setup 的过程中，就这个概念还是比较抽象。
如果一定要定义一下，我觉得可以从产品形态上做个推演：
Manus 让大家看到，Agent 可以端到端完成任务了，不过还是需要「人管 AI」；
但我最近一直在研究大家是怎么用 OpenClaw 的。我觉得它最大的作用就是让大家看到了「AI 管 AI」的可能性。
所以 Proactive Agent 可能会是一个「能管理 AI 的 Agent」：
它能根据团队内部的特点，自己提出需求，去搭建一些专门解决特定问题的 Agent；任务完成之后，再把经验沉淀下来，把这些临时 Agent 释放掉。
曲凯：「AI 管 AI」其实也和 Agent 的自进化有关，对吧？现在大家常说一个人的效率可以提升十倍、百倍，那如果 Agent 的主动性足够强，未来会不会真的能替代所有人类？
文锋：我觉得没有这么绝对。
可以参考 AI 最早落地的客服行业。以前需要 10 个客服，有了 AI 之后，可能只需要留 1 个。
Proactive Agent 出现后，可能也会是类似的情况：从需要 10 个工程师，变成可能只需要留下 2 个。
而这 2 个人不可被替代的地方，一是大家常说的 taste；二是协作中的默契。
如果一件事情需要我掰开揉碎讲清楚，一个员工才能理解，那 Ta 可能就比较危险，因为我有和 Ta 解释的这个时间，早就能让 AI 把事情做完了。
我们真正需要的，是那种我点一下，Ta 就知道我在想什么、要什么的人。而这种默契，往往是长期合作中培养出来的，或者说来自于悟性吧。
曲凯：我觉得悟性很多时候也来自于之前的 context。比如一个人在字节待过几年，到你这之后，你点一句，Ta 就知道了。
但这里也有一个问题。现在像 Moltbook 这类产品，都在讲 AI 和 AI 之间的交流和学习。这件事真的成立吗？作用到底有多大？
文锋：以目前 Agent 的实际能力来看，是可以实现的。
但关键问题在于，有多少东西值得被这样分发和复制。
在企业场景里，不同公司的流程和业务差异很大，所以 Agent 之间学到的东西，未必可以直接复用，中间还是需要磨合。
比如我们内部的 Coding Agent 是围绕自己的代码仓库和工作流优化出来的，直接放到另一家公司，未必还有同样的价值。
所以前面讲 Proactive Agent 的时候，我提到了一个关键点，就是要结合自身情况去做定制。因为至少在现阶段，它还不是一个开箱即用的东西。你不可能买一个产品装上，它就能自动读你的文档、吸收你的信息，然后自己长出一套完整体系。
曲凯：明白。那你自己在用 OpenClaw 的过程中，有没有遇到过什么 aha moment？
文锋：最大的 aha moment，是春节前大概用了一周，AI 就基本能直接把我们内部的工作流跑通了，让我们的工程师从一个 AI 指挥者，变成了一个质检员一样的角色。
我们原来的工作流是这样的：先用 Linear 管理用户反馈和需求，然后每天开会把任务分发给工程师。工程师再基于这些需求，用 Claude Code 等工具开发和测试，之后提 PR、再合并。
但 OpenClaw 出来之后，我们把各种权限逐步开放给 AI，发现绝大多数任务它都可以直接完成。甚至在测试过程中，如果发现前端有问题，还会附上截图。
这给了我很大的震撼。我们之前没想到 AI 能做到这个地步。
曲凯：所以你们现在的效率大概提升了多少？
文锋：我个人的效率至少比去年这个时候提升了 10 倍。
曲凯：那是不是意味着，过去要花一年做出来的产品，现在可能一两个月，甚至更短时间就能完成？
文锋：一两个月其实都太慢了，可能两周就够了。
所以现在真正的瓶颈，已经不在生产效率上了，而是你要做什么、以及要做成什么样。
以前大家说「idea is cheap」，但我现在反而觉得不是。
生产能力越丰饶，真正有意思的东西反而越稀缺。
曲凯：所以你今年还会期待哪些新的方向？
文锋：我比较期待的是 Agent Harness。
这是一个去年 9 月底左右在硅谷出现的概念，现在还只是在小范围流行。
它的核心作用，就好比人要骑马，得有马鞍一样。越是好马越狂野、越需要马鞍的约束。Agent 也一样。如果把 Agent 比作一匹绝世好马，我们该怎么去控制它的行为？
这时候就需要 Agent Harness。
它不像以前的软件那样有很清晰的分层：最底层是 Infra，中间是 SaaS，最上面才是终端用户。
Agent Harness 更像一个直接面向终端用户的脚手架，能让你针对不同公司的业务特点、团队协作方式和内部环境，搭出一套适合自己的系统，让业务能更快跑起来。
曲凯：明白。那你们自己呢？今年会做什么新的事情吗？
文锋：我们很快会发布一个新版本，把刚刚讲的那套内部流程产品化。
曲凯：那这是个大转型啊。
文锋：对。我们现在的思路是做「管 AI 的 AI」。
我现在的判断是，继续去做一个更聪明、或者比别人再好一点的 Agent，价值已经没那么大了。因为几乎没有什么事情是一个精心配置过的 Coding Agent 做不到的。
问题在于，现在的配置过程太复杂、门槛太高。所以我们想做一个 AI，帮大家更好地管理和配置这些 AI。就相当于我手下已经有 5 个 AI 在干活，但我自己管不过来，那就再雇一个专门负责管理它们的 AI。
去年我们太依赖预判了，总想讲一个不一样的故事。但今年我们的策略变成了「预判为辅，跟随为主」。
曲凯：可以，非常好。我们聊过那么多创业者，我觉得你这句话有了一种非常成熟创业者的感觉（笑）。
我们刚和 Albert 聊过一期（回顾：（优化胜率而非赔率，把一件事做到理论上该有的样子），其中一个很重要的点就是「要优化胜率，而不是赔率」，也就是更务实地把确定性更高的事情先做好。
文锋：对。我们内部其实讨论过一个问题：
如果回到 2025 年 3 月，要不要做 Genspark？
我们团队里只有 1.5 个人说要做。
就大家其实都是技术和产品上的理想主义者。但「不做」的这个选择本质上是在优化赔率，而不是优化胜率。
所以今年我们要做的是一种可以快速修正方向和重点的产品形态，具体而言就是前面讲的「能管 AI 的 AI」。
而之所以选择 Coding 这个场景，是因为 Coding Agent 正在进入一个新阶段：
第一阶段的 Coding Agent 是 Copilot，主要靠代码补全；
第二阶段是 Claude Code 这类 Coding Assistant，还是需要程序员主动 prompt；
而进入第三阶段，AI 已经可以指挥 AI 写代码了。它不再需要人一句句输入需求，而是可以自己去发现、澄清需求，然后调度执行。
在我们团队里，这件事已经在慢慢落地。但现在的问题是，大家用 AI 的水平差距太大。很多团队也希望用 AI 把效率提升 10 倍、甚至 100 倍，但并不知道该怎么做。
曲凯：所以你们在做的，其实也是 AI Coding 的平权。
文锋：对。而且「用 AI 更好地提效」这件事，在我们团队内部也是一个非常迫切的需求。
曲凯：我觉得这点很好。好就好在，我发现很多做得好的公司和产品都有一个共性，就是它们自己就是用户，能够形成一个正向的迭代循环。
那你们现在的用户画像大概是什么样？
文锋：大概一半是 founder，1/4 是超级产品经理，另外 1/4 是很强的 builder。这些人基本上都是日消耗超过 1 亿 Token 的用户。
我觉得 Agent 时代也会像 SaaS 一样，有 to enterprise 和 to 中小 B 的不同商业模式。但它未必是按组织人数来分层，而是按 Token 消耗来分层。
而日消耗 1 亿 Token 的用户，某种程度上就相当于 SaaS 时代的世界 500 强。
曲凯：如果把 C 端也分成中大 C 和小 C，你们其实就是选择先做中大 C？
文锋：可以这么理解。但如果一个用户一年能给我贡献 10 万美金，我为什么还需要关心 Ta 是个人还是团队？
不过一个很大的变化是，过去你几乎不可能从一个人或一个小组织身上收到 10 万美金，但今天可以。这笔钱，其实就是他们原本招工程师的预算。
曲凯：但我在想，如果 AI 的效率真的这么高，就会有更多人去学 AI，也可能会出现更多的 OPC，那最终还是会回到一个产品的供需问题？就这个世界到底需不需要这么多产品？如果人人都是一人独角兽，需求又从哪里来？
文锋：我觉得未来的供需可能会形成一个负反馈循环。
市场的需求是层层嵌套的。正向循环是企业发工资，员工去消费，再把需求传回企业，让需求盘子不断扩大。但如果很多人失业，消费需求下降，整个需求盘子就会萎缩。
所以我现在只考虑未来 3 到 6 个月的事情，因为我也不知道将来会变成什么样子…
曲凯：有点像平台要打掉中间商？现在劳动力市场里的「中间商」其实就是具体干活的人。OPC 就是把员工都打掉，AI 相当于把中间的人替代掉。
文锋：对。如果这个过程发展得太快，社会稳定可能会面临很大的问题。这个问题很复杂，我觉得需要更聪明的人去解决。
曲凯：那在这种情况下，你们团队现在有什么变化吗？
文锋：我们现在招人非常谨慎和苛刻。
如果按以前的标准，我们可能已经扩到 20 人了，但现在实际上只有 7 个人。不过这 7 个人的产出和效率，已经接近过去三五十人的团队的水平。
曲凯：这些人的 AI Coding 能力，是可以培养出来的吗？还是一开始就得是特别强的人？
文锋：我觉得是可以培养和训练出来的，但前提是组织愿意给足 Token 额度。
曲凯：但这也是个问题。比如一个人一天要消耗上千美金的 Token，你怎么衡量 Ta 的产出？
文锋：现阶段更重要的是先让大家跟上，跟不上的就淘汰。
至于怎么衡量，是下一阶段才需要考虑的事。我现在的看法是还得靠人，比如 CEO 得去看一个人的 Token 消耗和产出是不是 match。如果不 match，那就说明这个人有问题，然后要么解决问题，要么解决人。
曲凯：OK。你刚刚说你现在只看未来 3–6 个月，那去年你在解决的是多长时间维度的问题？
文锋：去年我一直在解决 5 到 10 年之后的问题。
但我的反思是，不要去解决那些人们还没遇到瓶颈的问题。
比如去年 Sheet0 很想追求 100% 可解释、100% 准确，这当然是很正确、也很有价值的方向，你问任何人需不需要，大家都会说需要。但问题是，当下模型还做不到这件事，而且大多数用户对准确性也没那么敏感。
所以我们今天的思路，就是解决大家已经遇到的瓶颈。
比如现在工程师们的一个真实问题，就是注意力会被十几个 terminal 窗口牵制住。我们在做的「AI 管 AI」，本质上就是顺着这个需求往前多走半步，以跟随为主。
曲凯：为什么说这是跟随？现在做类似事情的人还不多。
文锋：就是在跟随一个明确的趋势。
AI 变化太快，预判的有效期越来越短。以前一个判断可能能管半年，现在可能只管一两个月，甚至更短。那在这种情况下，我就不做那么长远的预判了。因为一旦判断错，转向成本会很高，反应也会变慢。
曲凯：尤其是 AI Coding 提升了效率，有个判断很快就能验证。
文锋：对。所以更重要的是解放团队的思维，而这里面最难的，是放下 ego。
还是回到前面那个问题：如果回到去年 3 月，你要不要做 Genspark？
现在一年过去了，Genspark 已经这么成功了，如果你的第一反应还是不做，从商业逻辑上来讲就很离谱。
很多时候大家为了讲差异化，会过度放大自己的 ego。但我们现在的调整，是迅速发现自己哪些地方没做对，然后更理性、客观地判断机会，去下注当下最明确的那个方向。
42章经
思考事物本质
