本期播客原文约 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章经
思考事物本质
热门跟贴