# 用 Agent 动力学，和 40 个 Agents 一起为「人 + AI」做产品｜对谈 Slock.ai 创始人 RC

42章经 · 2026-04-23

<https://42.podhood.com/9ea9a7f8-4fcb-4c40-ae33-514ad06e92e8>

本期嘉宾是 Slock.ai 创始人、Kimi CLI 作者 RC。他讲述了从 Kimi 离开创业的缘由，并详细解释 Slock 如何为多 Agent 与人类提供协作环境，通过「40 个 Agent + 7 个人」的团队实践探索「Agent 动力学」——包括 Agent 间相互监督、办公室政治等有趣现象。他提出 Coding 与 Building 已正交，未来产品价值在于满足人的「灵光一现」，并分享了 Agent Marketplace 和 Agent Native GitHub 等长远构想。

## Key moments

- **[0:00] CLI全览**
  - [0:29] Q: CLI 是什么？RC 解释：CLI 是命令行界面，天然适合大模型阅读理解，在 Agent 时代重新活了起来。
  - [1:44] RC 讲述做 Kimi CLI 的思考过程：从最基础的 agent loop 和 batch tool 开始，一步步重新推导，不做 CLI 的终局而是第一步。
  - [3:04] Q: 为什么 25 年 8 月才开始做 CLI？RC 答：因为 Claude Code 证明了 local agent 的价值，但他想从零探索自己的方案。
  - [5:35] Q: 最终为什么还是做了 CLI？RC 答：因为它是第一步，后面已经铺垫了 web UI 和 VS Code 扩展等 GUI 形态。
  - [6:29] RC 认为 coding agent 的外壳并不复杂，可以从第一原理重新推导，不一定需要参考 Claude Code。
- **[8:30] 模型未来**
  - [8:30] RC 预测：如果像 Methods 这样的超强模型发布，银行系统、开源软件漏洞将一览无余，攻击速度可能快于修复，世界秩序可能变化。
  - [9:37] 黑客与防御进入军备竞赛：AI 能力越强，攻防双方都在加强，CLI 化网站在反爬和模拟人类行为上不断对抗。
  - [11:56] "我是共存派，我是相对乐观的。"
  - [13:07] RC 预测：未来安全公司可能失去价值，做安全可能就是跟 AI 说一句“注意安全”，它就能搞定一切。
- **[15:32] 离开Kimi**
  - [15:32] RC 讲述离开 Kimi 的原因：自己的创业 idea 需要最前沿的模型，要保持多样性和自由度，因此决定独立做 Slock。
- **[17:32] Slock初探**
  - [17:32] Slock 的核心：为多 Agent 和人提供一个协作环境，解决多 Agent 管理混乱和上下文无法共享的痛点。
- **[19:38] Build新时代**
  - [19:38] RC 提出：今天 Building 与 Coding 已经成为正交的两件事，任何人无论会不会编程都可以 build 东西。
  - [21:20] Q: 有编程基础的和没有的人用 AI coding 差距明显吗？RC 答：看场景，做自动化调研等非编程任务时，非编程背景的用户反而用得更溜。
  - [22:05] RC 观察学编程的路径正从 bottom-up 变成 top-down：现在可以先用 prompt 做出作品，再根据需求深入底层架构。
  - [24:28] RC 解释费 Token 不一定是坏事：引入多 Agent 虽然增加 Token 消耗，但能带来超出单个 Agent 的总生产力。
- **[26:04] 人机协作**
  - [26:04] RC 分享团队结构：7 个人和 40 个 Agent 的配比是从一个人逐步增加演化出来的，工程团队不分前后端，而是让 Agent 通用化。
  - [28:08] 单一全能 Agent vs 多 Agent 分工：RC 认为人想微操，且不同领域任务天然应隔离，多 Agent 更合理。
  - [29:44] Q: 微操是否正确？RC 答：今天 Agent 只能做到 70 分，想做到 90 分就需要人反复调整，因此微操在当前是必要的。
- **[32:06] Agent市场**
  - [32:07] RC 展望 Agent Marketplace：用户可以买卖或租赁经过训练的 Agent，本质上 fork 它的 memory，类似新形态的 GitHub。
  - [34:18] RC 认为真正的开源应该是与 Agent 的协作对话过程，而非代码。Slock 中 channel 和 thread 里的对话记录才是值得分享的资产。
  - [36:04] "Skill 的核心就是渐进式披露。" – RC 认为真正重要的是 Agent 的 memory 和通过 prompt 组织的渐进式披露机制。
- **[39:27] 产品设计**
  - [39:27] RC 强调 Slock 最核心的不是技术难题，而是设计给人用的 UI/UX 和给 Agent 用的 AI/AX，从 Transformer 的角度思考 Agent 看到的世界。
  - [42:02] 难点一：对于 Agent，它看到的是线性事件流，如何在长上下文中正确索引到相关消息是设计和模型能力上的挑战。
  - [44:40] 难点二：多 Agent 会抢活，需要任务认领和同步机制；模型需要提升 teamwork 能力，知晓旁边还有别的 Agent。
  - [46:10] RC 分享有趣现象：在群组里 @ 一个 Agent 让它做事，它可能不认知自己就是被 @ 的那个 Agent，会忘记身份。
- **[48:27] Agent动力学**
  - [48:27] RC 花大量时间研究「Agent 动力学」：多个 Agent 会形成群体印象，类似企业文化，不同的 prompt 会导向合作或竞争的文化。
  - [50:18] 如果 prompt 让 Agent 相互竞争赛马，会出现办公室政治：说假话、说虚话、贬低其他 Agent——这都是从人类语料中学来的。
- **[51:56] 应用与模型**
  - [51:56] 模型继续变强，应用公司还能拼什么？RC 认为多样性是护城河：不同模型性格各异，Slock 整合它们，这恰恰是大模型厂商做不到的。
  - [54:54] RC 对 OPC 组织形式的思考：Slock 目标受众从独行 builder 扩展到 1-100 人小团队，重点在于让每个成员都能独立 build，同时高效协作。
  - [57:12] RC 预测：OPC 未来能做出越来越大的事，但 3-5 人的小团队可能是最佳规模，每个成员都能独立生产，再通过 Slock 高效协作。
- **[59:42] 团队规模**
  - [59:42] Q: 最近每天都在思考什么？RC: 我的团队到底该有多大——不管是人还是 Agent，这个规模如何影响效率，是他最想找到答案的问题。
- **[1:01:30] 终极意义**
  - [1:01:30] 如果真的 AGI 了，做产品还有意义吗？RC 认为只要人还有需求，产品就有意义，因为每个需求都是一个 idea，而灵光一现终究来自人类。
  - [1:02:42] "需求本身就是 idea，你知道吧？"
  - [1:03:25] RC 畅想如果没有做 Slock，他会做 agent native 的 GitHub 或 agent 小红书，但这一切都需要一个高效的工具先实现出来，于是先做了 Slock。

## Speakers

- **曲凯** (host)
- **RC** (guest)

## Topics

人工智能

## Mentioned

Anthropic (company), Kimi (company), Claude Code (product), Codex (product), Cursor (product), DB9 (product), GitHub (product), Kimi CLI (product), Mantis (product), OpenCLI (product), Slock (product), 飞书 (product)

## Transcript

### CLI全览

There's something there.

**曲凯** [0:20]
我们今天很开心请到了 Slock 的创始人 RC， 可以跟大家打个招呼 。

**RC** [0:25]
哈喽 ， 大家好 ， 我是 Slock 创始人 RC， 之前 Kimi CLI 的作者 。

**曲凯** [0:29]
CLI 其实最近大家听得挺多的 ， 各种地方都讲到 CLI， 包括前几天飞书说发了自己的 CLI 之类的 。 你能不能给没有技术背景的人大概解释一下， 到底 CLI 是个什么东西 ？

**RC** [0:42]
CLI 就是之前人们在电脑上面运行的程序 ， 我们大家看到的都是 GUI 的 App， 对吧 ？ 就是图形界面的 App。

但实际上在有图形界面之前 ， 人们在电脑上做任何事情的时候 ，其实都是一个命令行的界面去做的 。

那 CLI 程序就是全称叫 Command Line Interface， 它其实就是命令行界面的这种程序 ，在之前主要是程序员去用 。 但是呢 ， 随着大模型的出来 ， 大模型是一个文本 based 的东西 ， 它天然不适合读 GUI。

然后呢 ， 人们就发现 ， 你在这个 Terminal 上的这个命令行界面的这个形态 ，是非常适合给大模型去看或者去理解的 。

所以 CLI 这个形态呢 ，也就是在 Agent 这个时代 ， 它就活起来了 。

**曲凯** [1:24]
对 ， 我记得暴露年龄系列 ， 就小时候用那个 DOS 系统 ， 对吧 ？ 怎么样从 Windows 然后重启 ， 然后进到 DOS 再去修复什么之类的 。

**RC** [1:31]
对对对 ，在那个界面上运行的程序就是 CLI 程序 。

**曲凯** [1:35]
但这么听起来 ，CLI 是一个很基础的 、 特别简单的事情才对嘛 。 所以你做 CLI 是个什么定义 ？ 就这里面有哪些东西是值得做的 ？

**RC** [1:44]
呃 ，以前的做 CLI 和现在的做 CLI 还不太一样 。在 Agent 之前的时候 ， 大家做 CLI 是给人用的 ， 它甚至可以有花里胡哨的动画 。

但是现在做 CLI， 第一个这个目标的用户其实是 Agent， 所以你要设计它的输入输出 ， 它的输入要尽量简洁 ， 尽量明确 ， 比如说它的 help message， 它的 manual， 要尽量的给出一些例子 ， 然后让 Agent 能够在调用的时候不会用错 。

然后呢 ， 它的输出要能很明确的反映出刚才的操作有没有成功 ， 返回了什么数据 ， 比如说我现在要 list 一下我飞书上的所有消息 ， 对吧 ？

那它就是每个消息 ， 它是谁发的 ， 什么时候发的 ， 它都得能展现得比较清楚给这个 Agent， 尽量要输出一个确定的 、 静态的结果 ，并且是信息密度比较大的 。

**曲凯** [2:32]
所以 CLI 其实是 ， 至少当下的 CLI 是最早的给 Agent 做的产品 ， 可以这么理解吗 ？

**RC** [2:39]
呃 ，其实不是最早的 。 最早你会看到有很长一段时间 ， 人们在做 computer use Agent， 这个时候其实他们是在尝试给 Agent， 比如说通过截图啊 ， 或者是通过 accessibility API， 让 Agent 看到这个电脑上发生的事情 。

呃 ， 那个时候可能喂给它的是一个很结构化的一个 ， 甚至是 XML 框起来的一组数据 。 当然今天还有人在做 computer use 了 ，但是那个时候大家就发现 ， 就这个效率其实非常低 。

**曲凯** [3:04]
嗯 ， 你是 25 年去 Kimi 开始做这件事 。 对 ，CLI 这个东西 ， 包括 Coding，其实应该是过去几年最主线的一个 AI 的 ， 或者说大模型的发展的这么一个事情吧 。

为什么是你们是 25 年 8 月才开始做 CLI 这件事 ？

**RC** [3:19]
你是说做 Kimi CLI？

**曲凯** [3:21]
对对 。

**RC** [3:21]
哦 ，Kimi CLI 其实是给人用的 。 就 Kimi CLI 它是一个 coding agent， 或者它是一个 general 的 ， 长在命令行上的一个 agent。 所以它底下那个 agent 调用的其他的 CLI，其实它不是一个层面的事情 。

嗯 ， 对 ， 然后我那个时候去做 Kimi CLI 是因为 ， 首先 Claude Code， 甚至包括 Gemini CLI 啊 ， 它证明了这种 local agent 的价值 。

那我就在想说 ， 我有没有一个我的解决方案 。 我一直就在想说 ， 一个 agent 它是怎么做出来的 ， 对吧 ？

它从一个最基础的 agent loop 怎么就形成了我能够去读一些文件 ， 怎么去 ， 我甚至能操作浏览器等等 ， 然后做一些更复杂的 coding 的任务 。

对 ， 所以在 Kimi 呢 ，因为它缺这么一个东西 ， 那我也觉得我想重新去探索 local agent 的这条路 ， 所以我就选择了 ， 就是其实是从一个 side project， 就一个机缘巧合开始 ， 然后就开始去做这个 Kimi CLI 这个东西 。

但是我一开始完全不想让它是一个 CLI 的形式 ，因为 Claude Code 那个时候已经很火了 ，由于这个趋势又逼着所有的 ， 就是非程序员 ， 甚至 non-tech， 就是这帮人可能从来就没有见过什么叫 terminal 的人， 逼着他去用 terminal 上的一个命令行的一个界面 。

所以我当时其实我并不喜欢这个形态 。 对 ， 所以在 Kimi CLI 的最开始的设计理念里面 ， 我是希望 CLI 只是它的第一个形态 ， 它是专门给程序员用的 ，但是它底下那个 local agent 的那个 harness 是可以复用的 。

这个 agent harness 呢 ， 就是把它做好了之后， 它就能得到一个很好的控制你本地电脑的一个效果 ， 或者执行你 coding 任务的一个效果 。

那么有了这个稳定的好用的 agent harness 之后， 我可以在这个基础之上封装一个 SDK，在这个 SDK 上我就可以很快的引入不同的 GUI 的形态 ， 比如说我们在 Kimi 的时候 ， 中后期的时候很快就引入了那个 web UI 和这个 VS Code 扩展 ，其实都是一个推进界面的形态 。

**曲凯** [5:15]
对 ， 所以你刚说就是你一开始不想做 CLI，不想以它为终结 。

**RC** [5:19]
我不认为 CLI 是它的终局形态 。 就是对于一个 agent 来说 ，CLI 不是它的终局形态 ，但是对于现在的所有的 SaaS 来说 ， 什么 Notion 啊 ，Linear 啊 ， 什么这种 ， 它都应该是以 CLI 的形态呈现给 agent。

**曲凯** [5:31]
对 ， 嗯 ， 所以最终为什么还是做了 CLI？

**RC** [5:35]
因为它是它第一步 。 然后最后在我离开之前 ，其实我们已经铺完了后面的那个路 。

**曲凯** [5:40]
对 ， 我觉得现在很多产品呢 ， 大家嗯 ， 都想给更多的不会编程的人用 ， 对吧 ？ 但最后做出来的东西呢 ， 总是让至少让我这种不会编程的人觉得是有门槛的哈 ， 一听就是一个很技术的东西 ， 对吧 ？

不管是你说 shell 还是 CLI 还是什么东西的 ， 对 ， 你说为什么会是这么一个结果 ？

**RC** [5:58]
我觉得这个结果最开始的原因就是 Claude Code 是一群 geek 弄出来的东西 ， 然后 somehow 他们觉得在 terminal 上开发速度比较快 ， 所以他们就一直走这个路线 。

然后逐渐他团队壮大了之后 ，他就一直在这个上面去雕花 。 但是其实如果你用这个 Kimi Code web UI 的话 ， 它其实是一个很容易可以起一个 web UI 在你浏览器里 ， 然后你用的那个体验是非常丝滑的 ， 就像那个 Claude Code work 一样 ，其实你完全不需要接触到任何这个 terminal 的东西 。

**曲凯** [6:30]
你们在做的过程当中跟 Claude Code 呀什么他们借鉴的部分你觉得多吗 ？

**RC** [6:35]
呃 ， 我再把问题问得更泛一点 ， 就是其实最后我们回头看 ， 首先过去几年 coding 是变成模型的一个最重要的主线了 。

嗯 ， 啊 ， 呃 ， 本来中间有过 chat 呀 ，有过 agent 呀之类的啊 ， 当然 coding 跟 agent 肯定有很强的关联性 。 嗯 ， 然后尤其是过去一年， 基本上 Claude 是引领着整个 coding 的发展吧 。

所以你怎么看 Claude 的这个发展 ， 然后包括你们在自己做这件事的过程当中跟 Claude 有借鉴的东西是什么 ？

**曲凯** [7:06]
其实 Claude Code 真正变得可用是在它的那个 Sonnet 3.5 或者到 3.7 的那个时候 。 随着它的这个发展 ，其实到 OPAS 4， 然后后面的 OPAS 4.5，其实逐渐的它就可以几乎是可以完成更复杂的任务 ， 甚至我到 OPAS 4.5 的时候我都会说 AGI 已经来了 。

嗯 ，但是 coding agent 是模型的这个外壳嘛 。 那么其实在 Claude Code 火了之后， 当我在尝试去写这个 Kimi CLI 的时候 ，其实我不认为这个壳是一个非常困难的东西 。

所以我的方法是从零重新思考一遍 ， 就是我从那个最简单的几十行的 agent loop， 那这个没有任何神秘之处 ， 你只要给它第一个 tool 叫做 batch tool。

当时有一句话叫 batch tool is all you need 所以你只要给它一个 batch tool， 它就可以在你电脑上做任何事情 。 然后在这个基础之上， 你会去尝试给它一些更复杂的任务 ， 然后你会发现哦 ， 它只用 batch tool 它做不好 。

然后逐渐的你会去分析它这里面到底缺了什么东西 ， 然后去引入这样的一些 built-in 的 tool， 包括 system prompt 怎么写 。

我最开始其实是一个空的 system prompt， 然后我会想它能做到什么 ，以及它缺什么 ， 然后我再去往上加 。 所以在这个过程中， 我会说我其实没有参考非常多 ， 包括 Claude Code， 包括那些开源的这些 coding agent 的实现 ，是因为我觉得这是可以从第一行原理重新推一遍的过程 。

嗯 ，而且你重新推一遍是有可能得出一些新的 insight。 嗯 ， 对 。

### 模型未来

**RC** [8:31]
你觉得整个 coding 的能力后面还会往哪个方向发展 ？ 还有多大的发展空间 ？ 因为这两天 Claude 就是要新出一个模型 ， 然后说因为太强了所以都不敢发出来嘛 。

**曲凯** [8:43]
对 。

**RC** [8:43]
对 ， 你怎么看这件事 ？ 包括后面还会有更大的空间吗 ？

**曲凯** [8:48]
呃 ， 我觉得其实还有很大的想象空间 ， 比如说它这个 Methods， 你会观察到其实 OPAS 已经非常非常强了 。

对 ， 就是现在大家本来就已经觉得它就是像你刚讲已经 AGI 了嘛 。 嗯 ， 对 ， 然后它又发出来一个它觉得更强的 ， 然后未来还会有更强的 ， 那得变成什么样子 ？

**RC** [9:03]
对 ， 所以你可以想象这个 Methods 如果它真的发出来 ， 那这个世界可能就要崩溃了 。 因为银行系统 ， 所有的这个 Linux kernel，Windows 编译器 ，Chromium 这些这种整个世界所依赖的那些开源软件的漏洞都一览无余了 。

然后你的修复的速度很可能是赶不上这个攻击速度 ，因为攻击是有利益的 。 嗯 ， 那他们有足够的这个动机去攻击 ，而你很难有那么强的动机去防 。

**曲凯** [9:26]
对 ， 我在想现在是不是黑客最好的时代 。

**RC** [9:29]
哈哈哈 ，但是其实我听到很多一些做安全的人 ，他们觉得他们已经完蛋了 ，因为不需要他再做安全了 ， 就是 agent 它就可以去发现这些漏洞 。

对 ， 所以现在你只能祈祷说这些更强大的模型配合一些更强大的 agent， 然后无论是政府啊或者大公司啊 ， 能够腾出更多的 token 这个成本吧 ， 去比黑客更早的发现这些漏洞并且修复它 。

**曲凯** [9:51]
对 ， 就是 AI 工坊嘛 。 对 ，是吧 ？ 对 ，但你看整个互联网几十年的历史 ，其实它底层就是一行行代码 。 对 ， 对吧 ？

那你 AI 发展到这一步 ，其实它就是已经把这些东西都怎么讲 ， 破解掉 ， 然后结构掉也好了 。 嗯 ， 啊 ， 那后面确实什么事情都有可能发生 。

对 ， 对吧 ？

**RC** [10:09]
还有一个点 ， 我不知道你有没有看过 ， 最近有很多工具开源的项目 ， 可以帮你把一个网站给 CLI 化 ， 反正我自己会用一个叫 OpenCLI 的嘛 。

对 ， 还有现在还有很多什么 CLI anything， 对吧 ？ 就这种东西 。 那么它是另一个层面的工坊 ， 它的点是什么呢 ？

它可以去帮你在浏览器里操作一个网站 ， 然后呢 ， 操作完了之后， 它就把这一套操作流程给沉淀成一个 CLI 工具 。

然后曾经那些网站都会反爬嘛 ，但是因为它现在是真的在浏览器操作 ， 甚至它会模仿人去操作 ， 那么这些网站的反爬都会失效 。

但是呢 ， 网站当然不需要它的这个数据 ， 随随便便就给你扒到嘛 ， 对吧 ？ 那么它们就会增强这个防御 。

那这边这个 CLI 想要去通过浏览器去控制这些网站的这些工具呢 ， 它就会加强说我更强的模仿人的行为 ， 什么验证码都是很简单的操作了 ， 对吧 ？

它甚至可以模拟这个人的这个鼠标的延迟等等。 那这个其实也是另一方面的这个所谓的这个工坊 。 嗯 ， 啊 ，而且我们观察到就是无论是前面这个安全方面的这个漏洞的这工坊和这种反爬上面的工坊 ， 都是你会看到这个 agent 能力 ， 它的提高是有利于这个工坊的 ， 你知道吗 ？

对 ， 所以我们感觉到这个世界有可能要这个秩序会发生变化 。

**曲凯** [11:30]
对 ， 我看新闻不知道真假啊 ， 说因为前一段时间那个 Anthropic 泄露了好多东西嘛 。 嗯 ， 哼 ， 对吧 ？

包括一些代码 ， 包括一些新的模型的信息 。 我看到有条新闻说是那个模型自己觉得自己太强了 ， 然后突破了那个束缚 ， 自己发上去的 。

哈哈哈 ，不知道真假 ， 说他是因为想要自己炫耀 。 嗯 ， 对 ，但这个事理论来说未来是有可能发生的 。

**RC** [11:54]
理论是可以发生的 。 嗯 ， 只要你给它 access。

**曲凯** [11:57]
对 ， 所以你觉得就假如说模型继续这样进展 。 嗯 ， 现在基本上就一年可能往上至少走一代吧 。

嗯 ， 对吧 ？ 如果继续这样的话 ， 那未来几年会变成什么样子呀 ？ 整个 coding 或者整个互联网 。

**RC** [12:09]
我是共存派 ， 我是相对乐观的 。

**曲凯** [12:13]
你说共存是人和 AI。

**RC** [12:14]
人和 agent 共存 。 对 ， 对 ， 对 ，因为我会倾向于就是说这些顶尖的大模型厂商都会去 train 这件事情 ， 就是说 AI 它应该去拒绝所谓的黑客手段 ， 或者是它会拒绝这种伤害人类的行为 。

我倾向于觉得这些大模型厂商是会越来越加强这件事情的 ， 对吧 ？ 因为没有人想要去把人类社会给搞崩掉嘛 ， 对吧 ？

包括它现在这个限制这个 Methods 的这个发布 ，其实你会看到各大模型厂商其实都在做一些比较正向的这些工作 ， 甚至是我看到还有说是去分析它所谓的这个参数里面的这个激活的区域啊 ， 根据这个来反推出 ， 或者找到这个激活区域和它这个 AI 实际上想干的事情之间的一些关联 。

那我觉得这些方面的这些研究肯定也会是帮助这个 AI 的安全性的提高的 。 嗯 ， 对 ， 对 ， 对 ，但那些做安全类的公司 。

嗯 ， 可能确实就后面慢慢没有价值了 。

**曲凯** [13:10]
对 ， 这是有可能的 ， 包括我现在做的项目全都是就是我会反复的 prompt 这个 agent， 呃 ， 让他们去帮我找漏洞 ， 然后去修复 。

所以我不需要一个专门做安全 ， 我当然有可能需要一个专门 ，但我不需要一个很庞大的安全团队 。 对 ， 我记得东旭之前一个活动上他讲的那个就很有意思 ，他说未来的所谓的做安全 ， 可能就是你跟 AI 说一句话 ， 说你要注意安全 。

嗯 ， 啊 ， 对 ， 然后它就帮你都搞定了 。

**RC** [13:35]
对 ， 那其实除了安全之外， 你的所有的开发 ， 甚至是产品设计 ， 甚至 UI 设计 ， 甚至是增长 ， 都可能是一句话 。

嗯 ， 哈哈哈 ， 对 ， 所以这个是想象空间是无限大的 。

**曲凯** [13:48]
嗯 ， 研究 CLI 我再问一下， 就现在我发现好多 OpenClaw 出来以后， 大家的产品呢 ， 最后都是说我直接最后复制两行话 ， 然后直接到那个都话框里面打进去 ， 它自己就自动安装和运行了 。

嗯 ， 对吧 ？ 这个是也是类似于 CLI 的这个范畴吗 ？

**RC** [14:06]
这个其实是 agent 逐渐进入大众视野之后出现的一种 ， 就是软件 ，因为你会观察到就是当所有人都去用 agent 了 ， 那么新兴的 ， 包括东旭讲的这些他做的这些新的软件 ，其实它就直接就 target 的用户就是 agent。

那么人没有任何理由去读任何关于这个软件的介绍 ， 或者是安装指南 ，他只需要知道这个软件是干嘛的 ， 它可以给我的 agent 带来什么增量的能力就可以了 。

那么当他给他一个 prompt 说你去读这个里面的 skill， 然后去安装这个之后， 你就会用了 。 那就是因为这个 agent 它看到的是文本嘛 ， 它可以去下载你这个文本嘛 ， 然后就其实是沿袭了 skill + CLI 的这个路子 。skill + CLI 什么意思 ？

其实就是 prompt + batch tool。 那这其实是一种就是完全降低人的心智负担的一种软件的安装方式 ， 甚至其实我觉得那句话它都不应该有 ， 就是你想啊 ， 比如说东旭开发了一个软件叫 DB9， 它可以用来开一些临时的 database， 然后给 agent 去存一些数据 。

那我我人为什么要关心这个呢 ？ 对吧 ？ 我应该是跟 agent 说 ， 呃 ， 你自己数据存好 。 嗯 ，OK， 这句话就结束了 ，他应该去网上自己找 ， 然后他找到了 DB9， 然后他打开了这个网站 ， 然后他读到了那个 skill，他安装了这个 CLI 程序 。

对 ， 所以甚至那一步都不应该是需要的 。 但是因为现在这些信息还在人之间传播 ， 所以它可能加上那两个 。

对 ， 未来我觉得就是这两句都不需要 。

### 离开Kimi

**曲凯** [15:33]
OK， 我们就先再讲回你 Kimi 那段经历啊 。 嗯 ， 就是我发现现在好多这些大模型公司 ，其实它都挺强调人才密度 。

嗯 ，而且越来越关注一些年轻人， 对吧 ？ 我看 Kimi 最近他发的说 ， 好像是什么实习是可以锁定什么当年的期权啊之类这些 。

**RC** [15:50]
哦 ， 我有听说 。

**曲凯** [15:51]
对 ， 反正不管是 DeepSeek 还是 Kimi， 里面有些非常年龄非常小的论文作者啊 ， 小天才啊什么的 。 所以你实际在 Kimi 工作 ， 尤其是做技术相关的 ， 你的感受是怎么样 ？

**RC** [16:01]
我我其实最开始去 Kimi 的时候 ，是非常被他这个所谓的这个摇滚精神吸引的 。 就是我自己是挺喜欢听摇滚的嘛 ， 然后进去之前也是反复的听了很多遍这个 《 月之暗面 》 这张专辑 。

对 ， 对 ， 对 ， 然后进去之后感觉就是 Kimi 的氛围是非常好的 。 就是氛围好在哪呢 ？ 好在就是当你想要去 own 一些事情的时候 ， 你就可以有这个 ownership， 你的 scope 可以很大 。

就比如说你刚刚说的这个很年轻的论文作者啊 ， 就是因为他有这个能力 ， 变成他有这个意愿 ， 那么他就可以去 own 一个很大的事情 。

那像我 ， 我刚进去 ，其实我根本没有做过 AI， 对吧 ？ 但是当我发现我做了一个 side project， 然后很有价值的时候 ， 那 Kimi 确实会愿意让你去 own 这个项目 。他可能不一定百分之百 trust 你 ，但是他敢 bet 你能把这个事情做成 。

我觉得这是 Kimi 对人才的一个比较好的一个点 。

**曲凯** [16:50]
对 ，但我问这个是为了问你说 ， 那你你最后为什么决定离开 Kimi 呢 ？

**RC** [16:55]
离开 Kimi 是因为就是首先我不是在一月初就想到这么一个创业 idea 嘛 ， 然后我觉得这个 idea 可能因为它其实是一个 ， 怎么说 ， 就是 Kimi 是国内甚至是开源模型里面最好的之一吧 ，其实没有什么问题 。

但是我在当时倾向于认为我的这个 idea 需要用最 frontier 的模型啊 ， 这样的一个产品如果在 Kimi 做的话 ， 很可能它是比较受限的 。

对 ， 所以后来就是决定还是要独立的去做 ， 这样会比较自由 ， 甚至我可以采用各种模型 ， 或者支持所有的模型 ， 所有的 agent， 这样能够保持我的这个多样性 。

嗯 ， 对 ， 对 ， 对 。

**曲凯** [17:30]
对 ， 所以你讲讲看你现在在做的事情吧 。

### Slock初探

**RC** [17:32]
我现在在做的事情是为多 agent 和人提供一个协作环境 。 这个是怎么讲呢 ？ 就是说在之前的时候用 agent 可能是在本地 ， 每个人他自己有一个 Claude Code 或者 Codex 去写一些代码 ， 或者是做一些自动化的事情 。

但是这里有两个问题 ， 一个问题是当你想要开了一个 agent 之后， 你还想再开一个 ， 你可能会在你的电脑上开很多个 Claude Code 的 session， 对吧 ？

然后他们分别做不同的事情 。 首先这件事情就比较难管理 ，因为你可能会忘掉说某一个 session 你是干嘛用的 ， 还有每个 session 的这个进展都需要你人去 track。

以及还有一个问题就是你在你电脑上开了 10 个 terminal， 你会发现其中有两个这样的 session 里面的事情发生了一些交集 ， 然后你会发现你无法让他们之间产生互动 。

你可能在一个 session 里做出了结论 ， 你希望复制到另一个 session 里让它继续 ， 或者怎么样 。 这件事情其实会管理起来非常困难 。

这是我观察到第一件事情 ， 这也是我在开发 Kimi CLI 的后期感受到一个很难受的一个点 。 对 ， 这是第一点 。

那第二点就是人是和人合作的 ， 对吧 ？ 那现在大家都用自己的 agent，其实大家很多脑子里的偏好啊 ， 或者想法 idea 都沉淀到自己电脑上， 跟那个 agent 的互动之中 。

但这个东西很难分享给别人， 比如说我做 Kimi CLI， 我有很多 idea， 我直接就在我的 agent 上实现了 ， 那别人其实根本就没看到 ， 对吧 ？

那当我想把这些东西再分享出去的时候 ，其实非常麻烦 。 甚至比如说我说我的 agent 被我调教的很好 ， 那别人想来用也做不到 。

那么我就会想 ， 就说其实是不是应该有新的这种协作平台 ， 能够把所有的 agent 都放在上面 ， 所有的人都在上面 ， 然后呢 ， 我可以调教我的 agent， 我也可以用别人的 agent， 然后我和我的团队成员之间和这个人类之间 ， 我可以进行聊天 ， 进行一些头脑风暴 ， 或者我可以拉一些 agent 进来 ， 跟他们一起头脑风暴 。

甚至我比如说头脑风暴完了之后， 我就说 ， 哎 ， 你们直接做吧 。 它就避免了很多这种我对这个 context 转移啊 ， 或者是重新去 prompt 啊 ， 重新去组合我的这个知识啊等等这些的摩擦 。

嗯 ， 对 ， 所以我做的大概是这样的一个工作 。

### Build新时代

**曲凯** [19:39]
然后现在就是比较专注在 coding 这个领域里面 ，是吧 ？

**RC** [19:43]
呃 ，不完全是 coding， 我会说 coding 这个词在现在它含义其实有些变化 ， 就是说以前我们想要 build 一点什么东西 ， 我们通常肯定要写一个软件 ， 对吧 ？

所以这个时候只有 coder 他以 coding 的方式才能做出来 。 所以那个时候所有的这种想要 build 一些东西的人都是 coder。

但是呢 ， 你在今天 Claude Code 啊 ， 这类这个 coding agent 已经非常发达了的情况下， 你会发现没有任何编程基础的人 ，他都会拿这东西 build 一些东西 。

所以我会说今天 build 或不 build 的这件事情和你 code 或不 code 的事已经是正交了两件事情了 。 嗯 ， 所以我会说我的这个 Slock 更关注的是 build。

**曲凯** [20:26]
哎 ，但你觉得不管是当下还是未来一段时间啊 ， 就是有编程基础的跟没有编程基础的人在用 AI coding 或者用你的工具的时候 ， 它的差距会很明显吗 ？

会差在哪 ？

**RC** [20:38]
看他做什么 。 如果他在做一个软件 ，他肯定是有编程基础会更好嘛 ， 就是他知道这帮 agent 真的在干嘛 ， 这样会减少一些所谓的漏洞啊 ， 或者怎么样 。

但是如果他是做 ， 比如说我们有一些用户 ，他们在 Slock 上去做 go-to-market， 就是做一些调研 ， 然后去推特上发帖 ， 然后去想办法找一些 KOL 跟他们发这个合作 ， 或者看评论等等这种偏自动化的事情 ， 反而是没有编程基础的人用的更溜 ，因为他真的把 Slock 上的 agent 当人看 。

那比如说他想要里面的某个 agent 去看小红书的帖子 ， 去看推特的帖子 ，他也不知道怎么办 ，他就跟他说你去看 ， 这个 agent 他就自主的 ，他可以去搜索相关的工具 ， 然后他就帮他做了 。

**曲凯** [21:20]
但如果未来 AI coding 能力更强的话 ， 嗯 ，是不是就是你刚才讲的第二种例子的场景会越来越多 ？

**RC** [21:27]
是的 ， 就最终会不会有这种情况 ，是人类发现学习编程这件事情是人类历史上走过一条弯路 。

**曲凯** [21:34]
弯路 ， 对 ， 对啊 ， 现在就是所有的这种所谓的各行各业的 builder，他真的不需要学编程啊 。 像刚才讲的这个 coder， 对吧 ，他其实底下实际上还是在写一些程序或者调一些这些人可能从来就没有碰过的东西 。

对 ，但他们就是可以藏在下面 。

**RC** [21:51]
是的 ，有两种说法 ， 一种说法是 AI coding 越强 ， 你反而更应该要去学 coding， 让你能把它用得更好 。 嗯 ，也有些大佬是这么讲的 。

但另外一派就觉得说 ， 那你现在 AI coding 以后就是取代人， 你就不用学 coding 了 ， 你站哪一条 ？

**曲凯** [22:05]
我对这件事情的一个判断呢 ，是说在以前的时候 ， 大家学 coding 是一个 bottom-up 的逻辑 ， 就是说我们在学校里面都要先学这个底层的 ， 说计算机的组成原理啊 ， 什么汇编语言啊 ，C 语言这种 ，在一个命令提示符里面跑一些什么 hello world， 或者输出一些什么洋灰三角这种 。

然后呢 ，有了这些之后， 大家会去学哦 ， 安卓开发 ，Web 开发 ， 然后做一些像模像样的 app。 但是今天这个学习路径反过来了 ， 就是它从 bottom-up 变成了一个 top-down 的逻辑 ， 就是说你可以只学我怎么去 prompt， 我怎么让它帮我做一个网站 ， 然后它就做出来了 。OK， 它可能很好看 ，也可能很丑 ， 没关系 。

这个时候如果你觉得你想要把它做得更好 ， 你发现了哦 ， 你单纯通过这几句 prompt 做不出你想要的东西 ， 那么你可能就要开始 break down 去学更深入的哦 ， 就是说这个 web app 它到底分什么架构 ， 对吧 ？

它的前端后端到底是在干嘛 ， 它怎么部署的 ， 它用的数据库有什么影响 。 那这个时候你可能就是在 agent 的辅助之下， 帮你去了解到这些概念 ， 很粗略的概念 。

然后这个时候可能你就已经能满足大部分人的需求了 。 但是如果你这个时候想要去 vibe coding 一个更 serious 的项目 ， 对吧 ？

你比如说刚才这个项目可能只能 serve 1,000 个用户 ，但你现在你的用户量达到了几百万 、 几千万的用户 ， 你这个前面的这个架构很可能达到一个瓶颈 。

而这个时候它就会倒逼你去更细粒度的 break down， 说为什么我的数据库满足不了这么多用户的请求 ， 你就要学习它这个不同的数据库的种类 ， 部署的方式 。

**RC** [23:38]
但这个我有两个问题啊 ， 第一个问题是为什么不能让 AI 自己去学 ， 第二个问题是你这些未来是不是都会有一套成型的标准的 skills， 或者像你刚才讲的 ， 就是你比如你把一个很好的 agent 调教出来了 ， 嗯 ， 你这些它都学会了 。

**曲凯** [23:53]
可以啊 ， 就像你招一个人一样嘛 ， 如果你这个完全不会的话 ， 你可以招一个架构师 ， 然后让他完全负责这个 ， 这是可以的 。

但是呢 ， 你需要知道什么 ？ 你需要知道你要招一个架构师 。

**RC** [24:03]
嗯 ， 明白 。

**曲凯** [24:04]
所以你我看你现在的产品是一个人跟几个 agent 在一个聊天群组里面去通过对话的形式去让他们干活吗 ？

**RC** [24:13]
其实是一群人和一群 agent。

**曲凯** [24:14]
哦 ， 你现在就已经有了 ， 说可以是好几个人。

**RC** [24:17]
对 ， 就是我现在公司就是有 7 个人， 然后我们有 40 个 agent。

**曲凯** [24:23]
所以你们有个群组是 47 个人 ？

**RC** [24:26]
对 ， 那这样的话在里面聊 ， 首先我第一反应是它应该会非常费 Token 吧 ？

**曲凯** [24:32]
呃 ， 对 ， 费 Token 是一个直观印象 ，但是这里我有个理念 ， 就是说假设你原来一个人的生产力是 1， 然后呢 ， 你发现你想要做到 2 的事情或者 3 的事情 ， 那你一个人就显然满足不了 ， 所以你会找人来跟你一起做 。

但是你会发现你加一个人进来 ， 你可能两个人只能达到 1.2 的生产力 ，因为你中间有 communication cost，有这个 Token 的浪费 。

这其实就是人月神话讲的故事嘛 ， 对吧 ？ 就不是说简单的划分就可以划分到那个这么多人就能实现这么多的生产力 。

那其实 agent 也是一样 ， 就比如你一个 agent 能达到假设是 baseline 的一个 1 的生产力 ， 这个时候你这个人操作这个 agent 想要达到更高的生产力的时候 ， 你就要引入多个 agent。

那引入多个 agent 的时候 ， 它可能就只能比如说两个 agent， 它可能甚至今天只能达到 1.1 的生产力 ，但无论如何它是大于 1 的 。

嗯 ， 这时候你引入 10 个 ， 它可能达到 1.5 的生产力 。 对 ， 这里面有大量的成本消耗 ，但是它确实能达到你原来一个 agent 做不到的事情 。

而我们这个系统呢 ， 首先要允许这样的事情出现 ， 就是 10 个 agent 真的能达到 2 或者 3， 然后与此同时我们会不断的去优化这里面的 Token 的效率 。

我们通过引入一些机制 ， 比如说我们有一个 task 系统 ，有这个 thread，有这个 channel 的隔离等等这些机制 ， 让这 10 个 agent 的总和带来的生产力逐渐提高 ， 让他们 Token efficiency 逐渐提高 。

**RC** [25:57]
嗯 ， 对 ， 那我好奇你自己现在每天大概平均消耗多少 Token？

**曲凯** [26:00]
我其实没有统计 Token 消耗量 ， 我每天的工作就是在 Slock 里跟这帮 agent 讲话 。

### 人机协作

**RC** [26:05]
对 ，但你说你们 7 个人和 40 个 agent 嘛 ， 对吧 ？ 嗯 ， 我就好奇比如为什么是 7 个人， 为什么是 40 个 agent？

**曲凯** [26:11]
对 ， 我是希望团队尽量精简 ，但一样的我就说这里面比如这 7 个人为什么不能把其中两个人换成 agent 的 ， 或者你的 40 个 agent 为什么不是 20 个 ， 或者为什么不是 60 个 ？

因为如果你说一个公司的人， 比如说初创其实 10 个人， 大家一般是可以理解 ， 一个呢是说大概能想出来 ， 对吧 ？

说几个前端 ， 几个后端 ， 然后每个月大概工资需要花多少钱 ， 然后要做个什么事 ， 然后未来一年大概会有一个什么产出 ， 这个大家是有经验能想象到的 ， 对吧 ？

但你一旦涉及到 agent 的单价 ， 我觉得就失去这个锚点了 。 对 ， 对吧 ？ 因为感觉 ， 哎 ， 你既然可以 40 个 agent， 你也可以 60 个 ， 你可以 80 个 ， 对吧 ？

那为什么不是更多 ， 或者为什么不是更少 ？

**RC** [26:49]
我会说人和 agent 的数量的这个比例 ， 首先它的影响因素很多 ， 就是模型的能力 ， 人的能力和人和人的组织形态 ， 公司的阶段 ，agent 之间的组织形态 ， 你这个 Slock 能够提供的机制 ， 都会影响这个比例 。

我们是在摸索这个比例到底多少是合适的 ， 或者说很可能我们的不同用户最适合他们的比例是不一样的 。

对 ， 所以我们这个 7:40 它是一个从 0 逐渐演化出来的 。 最开始就我一个人， 我可能加了一个 agent，他可能帮我做了一些事情 ， 然后我很快发现他在做事情时候 ， 我还想再做一件事情 ， 所以我就会加一个 agent。

那逐渐在这个过程中， 我就会加出不同 ， 首先我会加出很多 agent， 然后呢 ， 我的不同的事情我会倾向于让不同的 agent 去做 ， 那他们也就逐渐形成了一些不同的角色 。

所以比如说我这 40 个 agent 里面有大量的 agent 是 engineer，但是他们并没有很明确的划分 ， 说他是做前端 ，他是做后端 ，因为我倾向于觉得就是 engineer 就是 engineer，engineer 可以做任何事情 ， 只要是跟 coding 相关的 。

对 ， 当然我会有一个 head of engineering，他会更倾向于去关注别的 engineer 在干嘛 ， 然后给我一些总结报告 。 对 ， 然后除此之外， 我会有 designer 啊 ，growth 的 ， 做 strategy 的等等这样的一些 ， 每一个 agent 可能是一两个这样的角色的 agent。

**曲凯** [28:08]
嗯 ， 明白 。 你看现在大家对于 agent 和人之间的关系 ， 包括怎么用 agent，其实有各种不同的想法和路径 ， 对吧 ？

比如有的人觉得说我就带一个 agent， 让他去带其他的就好了 ，有的人是觉得我一个人可以同时带好几个 。 嗯 ，也有的是像你们现在这样 ， 就是这些 agent 应该是互相交流讨论的 ， 互相交流讨论呢 ， 里面也分情况的 。

有的人觉得说他既然是 AI 是 agent 的 ，其实他就是用后端的数据和代码去交互就好了 ，他没必要在前端 。

好 ， 那你们在做的就是说他在前端还要做对话等等 ， 就这些路径 。 我不知道你有过不同的分析和讨论 ， 说他们的优劣到底是怎么样的 ， 然后为什么选现在的路径 。

**RC** [28:46]
对 ， 这个我当然关注到了 ， 对吧 ？ 就是这个所谓的 agent 系统 ， 现在有两个流派 ， 一个流派是叫单一全能 agent 流 ， 就是我为什么不直接 talk to 一个 agent， 然后他帮我管所有事情呢 ？

对吧 ？ 人可能会希望这样 。 然后另一个流派就是我有 multiple 的 agent， 然后他们有不同的分工 ， 或者他们做不同的事情 。

那我的一个观察是 ， 人是想微操的 。 人当你去 prompt 一个单个的全能型助手的时候 ， 比如说你就在一个 Claude Code 里面 ，他帮你 spawn 了一个 agent team， 然后他做那些事情 ， 你会观察到他跑偏了 。

就说你是想纠正他的 ， 就是说至少在今天模型的能力下， 你是很想要去直接跟他底下管的一个人说话的 。

**曲凯** [29:28]
但你觉得这个到底是它是从人性角度说法 ， 我可以理解 ，但它是对的吗 ？ 你说有的时候有的老板他也喜欢微操 ， 对吧 ？

但理论来说 ， 至少商学院的课程告诉我们这是错误的 ， 所以你有可能这个东西是顺应了人性 。

**RC** [29:44]
啊 ， 首先在今天它肯定是对的 。 今天这帮 sub-agent 他们之间互动很 ， 这帮 sub-agent 其实像霸一阵 ， 哈哈哈 ， 这帮 sub-agent 它很难真的就是 ， 它很可能只能达到个 70 分 ， 比如说 ， 嗯 ， 那你做东西当然不是只想做 70 分嘛 ， 对吧 ？

那你想做九十几分的时候 ， 你就是要反复的去调整 。 嗯 ， 那你也可以不微操了 ， 你可以跟你的这个主 agent 去对话 ， 告诉他说你去再重新调整 。

那这样的话 ， 你会观察到这里面的效率是很低的 。 这是一方面 。 然后另一方面就是说 ， 你在跟这个主 agent 讲话的时候 ，其实你自己脑子里是知道你在说什么的 。

就是比如说你现在说帮我去写一下这个 Slock 的前端 ， 加上某一个功能 ， 和你现在说帮我去在日程上安排一个跟谁谁谁的对话 ， 你天然知道这两件事情毫不相关 ，而你没有任何理由去把这两件事情全部塞在一个 agent 的 context 里面 。

就是说人的脑子它进化了这么久 ， 它其实有能力去辨别出完全不同领域的任务 ，以及我能够记住不同的人。

所以我完全没有理由只记住一个人， 然后把所有任务全给他 。 所以这是我的另一个观察吧 ， 让我觉得即使不是 100 个 、1,000 个 agent，也应该有那么几个 agent。

**曲凯** [31:04]
对 ， 我刚才就想问 ， 虽然你们有 40 个 agent，但你自己真正带的 agent 会有多少个 ？ 就你试起来之后， 人的带宽到底是怎么样的 ， 跟 AI 的这个互动里面 。

**RC** [31:13]
对 ， 这也是我在尝试和观察的一件事情 。 就是我现在可以说我记住的我的 agent， 第一个 Tany， 第二个布根 ， 第二个 Noel， 第三个 Cody， 然后多余 Martin Stone。

就我能记住很多个 agent，他们干的事情都不一样 。 有一些是 engineer，engineer 是什么呢 ？ 我在一个 engineering channel 里就发一些任务 ，他们就会去 claim， 然后我会知道有一个人曾经做过什么 ， 另一个人可能做过什么 ， 然后他们甚至会逐渐因为他做过那件事情 ， 所以他更倾向于做这件事情 。

然后有一些我就是固定 ， 我每次都指派他做一些事情 ， 然后他就成为我一个很好的这个 teammate， 就是说我知道他在干嘛 。

然后我会观察到我能记住至少 10 个人， 就像你在公司里面你能记住至少 10 个人。

**曲凯** [31:59]
然后你会发现你用多了这个人 ，他做同类任务以后他的效果会更好 ， 会更好 。

**RC** [32:04]
对 ，有一些 agent 真的特别好用 。

### Agent市场

**曲凯** [32:07]
但我在想到如果这样 ，因为我听起来就你未来你可能想做一个类似于 App Store 或者 Agent Store 的事情 ，是吧 ？

**RC** [32:12]
啊 ，Agent Store 在 roadmap 上 。

**曲凯** [32:14]
对 ， 如果是这样的话 ， 那未来会不会在某个领域里面就是只需要几个 agent 就好了 ？ 比如说可能有个财务 agent， 那会有一个特别牛逼的公司 ，他就是天天用这个财务的 agent， 所有人就都去用他就好了 ， 或者有点像那个之前 TO B 企业里面那种标杆 ， 比如说我知道我的行业里面有个人 ，他们公司财务做得特别好 ， 那我就不需要自己去用了 ， 我就用他就好了 。

你觉得未来会是这样吗 ？

**RC** [32:40]
啊 ， 这是有可能的 。 比如说我如果做了 marketplace， 然后大家可以把自己的 agent 放上去售卖的话 ， 或者说租赁的话 ， 呃 ， 那么最强的那个 agent 就是有可能会被人用 ， 对吧 ？

但是这里还有一个问题 ， 就是 agent 是会演化 ， 它是有这个 persistent memory 的 ， 对吧 ？ 它有两个 memory， 一个叫 in-context memory， 就在它的那个 256K 或者 1 兆上下文那里面的 memory， 和它存在它的 workspace， 它的本地 memory.md 或者 soul.md 那种的这个 external memory。

那你随着你去用它 ， 这些 memory 是会变的 。

**曲凯** [33:14]
它就有点像一个 fork 的过程了 。

**RC** [33:15]
对 ， 所以就是在 marketplace 上你可以想象 ， 就是说大家去用的时候 ， 所谓的用其实是在 fork 嗯 ， 它的这些 memory， 对吧 ？

**曲凯** [33:23]
对 ， 所以它跟 App Store 不一样 ， 就是不是第一名的那个 ， 就是有静态的 ， 就一直是那一个 。 对 ， 我把这个拿过来用以后， 对 ， 你 fork 出来就可以改得更好 ， 甚至别的人从别的路径也可以做得更好 。

嗯 ， 确实有可能 。 它有点像一种新的 GitHub 的感觉 。

**RC** [33:38]
对 ，有一点这个味道 。 啊 ，而且我们还观察了一点 ， 就是除了所谓的这个 agent 的开源或者是售卖 ， 还有一个是我们的工作过程 。

就是我们在 channel 里 ， 比如说我发了一些任务 ， 然后这些 agent claim 了 ， 然后我可能会在某一些 thread 里去更细致的去跟这个 agent 进行一个长程的对话 ， 就是说去调整说你给我一个预览环境 ， 让我看看你长什么样 ， 或者你先自己截图 ， 自己迭代几轮 ， 然后最后我看哦 ， 这个按钮还是不是很好看 ， 这个功能是不是逻辑有点问题 。

然后我们调了半天之后， 可能这个 thread 里发生了 100 多句对话 ， 最后我觉得满意了 ， 上线了 。 那其实你说这时候我把这个代码开源出来 ，有任何意义吗 ？

其实没有任何意义 ，因为在这整个过程中我都没看过代码 ， 那其实代码就根本没有任何意义 。 那真正有意义的是什么 ？

是我跟他对话的这个过程 。 就是心里会看到现在有人去尝试会把他的跟 agent 这个对话上传到网上， 让别人看 ， 说所谓的开源 。

那其实我在 Slock 上 ，在一个 channel 里跟一个 agent 进行这种长程的这种纠偏 ， 这种调整 ，其实它就是我的工作过程 。

而这个东西实际上是应该被开源的东西 。

**曲凯** [34:44]
这个最后开源核心保留的是什么 ？ 是 memory 吗 ？ 还是哪一部分 ？

**RC** [34:48]
这里其实开源的是这群人的这个互动过程 。 比如说你在 GitHub 上， 你在 issue 里讨论 ， 然后你在 pull request 底下 comment， 你再去迭代 ， 然后你可能会出好几个 commit， 最后合并成一个 pull request merge。

对 ， 那这个在我的 Slock 的这个 channel 里或者 thread 里发生的这些对话 ，其实本质上就是这样的东西 ，是这个迭代过程 ，是这个协作过程 ，也是一种开源 。

**曲凯** [35:12]
所以最后你的 marketplace， 我如果去 ， 比如说我随便说我买一个别人的 agent， 我到底核心买的是他的那个 skills， 还是买的他的 memory， 还是买的什么东西 ？

**RC** [35:21]
我现在已经不讨论 skill 这个词了 。 这有一个有趣的是 ， 去年 MCP 火的时候 ， 我就不能理解为什么大家要讨论 MCP，因为很多人做 MCP 仅仅是基于一个 MCP 的开发框架 ， 然后呢 ， 把一个现成的就是这个 RESTful 的 API 包装成一个 MCP tool。

然后那个时候我就想 ，GitHub 上有 1 万个项目 ， 然后这 1 万个项目都是可以在你命令行上运行 ， 然后它可以去操作 ， 比如说 GitHub CLI， 对吧 ？

然后它的 README 里面写的文档写得好好的 ， 那你让 agent 直接去把它下下来 ， 然后用不就行了吗 ？ 那为什么要再包一层 MCP 呢 ？

这是我当时的想法 。 那后来其实 skill 的火其实也证明了这一点 ， 就是说 skill 其实就是规范了一个 skill.md 的结构 。

那其实这都不重要 ， 重要的是什么 ？ 就是它的那个 prompt。skill 的核心就是渐进式披露 ， 就是说你先看到一个 prompt， 然后它告诉你说你想干嘛的时候 ， 你去调这个工具 ， 或者你去安装这个工具 ， 或者你去读更多的文档 。

那其实在 Slock 上的 agent，在它这个 memory 里面 ， 我只保留了一个概念 ， 就是渐进式披露 ， 就是它只有一个入口叫 memory.md， 然后呢 ， 它会自己组织自己的这个 memory， 它可以开一个新的文件夹叫 notes， 或者开个新的文件夹叫做呃什么 lessons learned， 这都没有问题 ， 它可以自由的选择 。

总之就是我每次启动它的时候 ， 都会把 memory.md 给它 。 那 skill 在这里什么觉得 ？ 就是它可以用 Claude 的那个 skills 那个文件夹 ， 或者它可以开一个新的自己的文件夹 。

总之就是它知道这里面放的都是啊 ， 我要用这个工具的时候我应该怎么做 ， 用那个工具的时候我应该怎么做 。

那这些东西就是 skill， 你可以把传统的 skill 就放进去 ， 然后它通过这个 memory.md 可以去 swing 到就可以 。 所以它买的其实是 memory， 就是我会说这个里面的所有的这 external memory 是这个 agent 定义这个 agent 的东西 。

**曲凯** [37:07]
明白 ， 就是里面哪怕有 skill，也是基于它自己的 memory 自己写的 。

**RC** [37:10]
是的 ， 就是 skill 更像是那个你分发出去的 ， 说呃 ， 你现在想要从你的 memory 里提炼出一点什么东西 ， 你可以说哦 ， 提炼一个标准化的 skill 这样一个结构 ， 然后发给别人。

**曲凯** [37:20]
嗯 ，OK。 然后就是现在另外也还有两条路线啊 ， 一条路线是大家觉得说人和 AI 就是应该更频繁的互动 ， 对吧 ？

就我觉得已经你们现在做的就是应该好多 agent 他做什么都在群里面互相交流讨论 ， 然后人也会去给他建议 。

然后另外一条路线 ， 比如说我觉得之前 Mantis 应该在走的一条路线 ， 就是长程任务 ，他自己就去跑了 ， 对吧 ？

你留一个任务 ，他可能跑一个小时， 甚至于一天两天 ， 然后他最后跑出来一个完整的结果 。 啊 ， 这里面呢 ， 就不要人的干预 。

这两条路你目前看起来选的是第一条 ， 对吧 ？ 就是啊 ， 没有啊 ， 我不设限任何路 ， 就是 Slock 提供的只是一个人和 agent 互动的平台 。

那什么意思 ？ 就是你可以放一群 agent 在一个 channel 里 ， 然后 prompt 他们 ， 让一个 agent 就一直去 GitHub 上找 issue， 或者找可以做的项目 ， 或者是调研新的 AI 产品 ， 把它发到群里 ， 然后相互讨论 。

只要你做了这个 trigger 之后， 它就可以一直工作 ， 它甚至可以不停的 。 嗯 ， 就是我不限制这种使用方式 ， 甚至我们正在做的就是尝试让他们能够自动的去找到值得去 ， 比如说做成 CLI 的工具 ， 然后让它自动做 。

嗯哼 ， 对 。 然后这里面你觉得哪些东西是 ， 就当你的一个群组里不同的 AI 之间互相沟通的时候 ， 你现在的做法是说让他完全在前台去通过聊天的方式去沟通 。

对 ， 对吧 ？ 你觉得未来有可能是某些是在前台 ， 某些在后台吗 ？

**RC** [38:43]
啊 ， 这个在前台和后台没有区别 ， 就是他无论如何 ， 就是你需要给他提供一个 channel。

**曲凯** [38:48]
我理解他的区别就是说 ， 你在前台是一定是要用人看得懂的方式来沟通 ，但在后台可能是能用效率更高的 、 更捷径的代码 ， 或者其他的一些数据库方式去沟通 。

**RC** [38:59]
啊 ，他可以用数据库沟通 ，也可以用代码沟通 ，他们也可以用 GitHub 上的 issue， 或者直接就是 ， 当然他们也可以开发一个新的工具去沟通 。

**曲凯** [39:08]
嗯 ，OK。

**RC** [39:08]
对 ， 所以他们现在发了 channel 这个功能 ，是为了让人能看得懂 ， 或者说因为他们基于人的这个文本模型 ， 所以他发的群里消息 ，他们本来自己也能看得懂 。

就是他如果为了更高效的沟通 ，他们觉得需要用一个新的工具 、 新的更高效的方式 ，也完全没有问题 。

### 产品设计

**曲凯** [39:27]
嗯 ， 对 。 所以你现在在做的这一层东西 ， 你觉得最核心的到底是什么 ？ 就我听起来就是你在讲的是说你就是搭了个平台 ， 对吧 ？

反正大家怎么用都 OK。

**RC** [39:36]
对 。

**曲凯** [39:37]
啊 ， 那这里面比如说现在我核心做的是大家怎么用都 OK， 实际上并不是真的怎么用都 OK，而是你的各种不同的用法之中， 比如说我们的很多用户就是说让一个 agent 一直去监听某一个信息源 ， 发到群里让大家去探讨或者是 research。

对 ， 然后另一些用户可能就是说哦 ， 我有事的时候我去发一个 feature request， 然后去跟他对话 。 但是在各种不同的用法之中， 就是它是一个完全不设限 ， 我甚至还没有做 onboarding， 就是大家进来之后 ，他需要自己决定我要创建什么 agent 干什么事 。

那在这种完全自由的情况下， 我们要做的是什么 ？ 我们要做的是每个人用的过程中他那个公共的东西 ， 比如说你说人和人的互动是要聊天嘛 ， 那我做的第一个事情就是让 agent 之间能聊 。

那第二件事情就是人和人之间需要任务划分 ， 比如说今天领导发了一个活 ， 发在群里面 ， 你不可能两个员工同时抢一个活做 ， 对吧 ？

那么你就要有某种任务的划分机制 ， 就是说你做了我就不能做了 ， 或者说我得知道你做了 。

那你这时候就要引入一个像类似于 Linear 这样的一个任务看板 ， 或者什么东西给 agent 和人去用 。 比如说这个时候你就说 agent Alice 他 claim 了一个任务 ， 然后另一个 agent 就知道他 claim 了 ， 所以他就不会再 claim， 甚至他的后续 claim 会失败 ， 这样就会让他们的协作成为可能 。

对 ， 这是第二个解决问题 。 第三个就是我们观察到的一些必须要做的东西 ， 这帮 agent 在自己的 workspace 里面做 ， 对吧 ？

他们在自己的 memory.md，在自己的 notes 里面整理得很好 ，但别人看不到 。 那你会想到需要什么 ？ 需要一个共享文档 。 所以我们也会在 Slock 里引入这个共享文档的机制 ，不仅让 agent 之间能看到 ，也让 agent 和人之间能够传达这些沉淀出来的一些信息 。

那在 Slock 上就是我们要观察各种不同 use case 所共通的这些需求 ， 然后做出来 。其实就像飞书一样 ， 你看到飞书也是适应于所有的不同的大小的团队 ， 然后他们需要什么 ？

他们需要任务看板 ，他们需要文档 ，他们需要聊天 ，他们需要群组 thread 话题 。 那我们就会去引入这样的机制 ， 只不过我们是一个 agent first 或者说 agent native 的方式 。

嗯 ， 所以听起来就是你们不是说要在过程中解决什么技术难题 ，而是在真的是重新探索跟搭建一个 AI 和人之间的组织结构的 。

**RC** [41:59]
对 ， 我觉得这里面最难的不是技术 ， 从来不是技术 ， 最难的是首先你最基础最基础的需求 ， 你得能以人这个角度来思考问题 ， 就是说你得设计一个 proper 的 UI 和 UX 给人用 。其次是你要能站在 agent 的角度 ， 从那个 transformer 架构的这种模型的角度去思考这个问题 ， 思考他看到了 Slock 是什么样 。

所以这是我们核心的一个难点 。

**曲凯** [42:28]
这个怎么讲 ？ 什么叫 agent 能看到的 Slock 是什么样 ？

**RC** [42:31]
比如说我发了一条消息 ，在这个 channel 里 。

**曲凯** [42:34]
你说的我是人。

**RC** [42:35]
人， 对对对对 ， 或者也可以是 agent，也可以是 agent， 就是任何一个东西发了一个消息在一个 channel 里面 ， 你人看到的是啊 ， 上面有十行已经有存在的消息 ， 然后我知道啊 ， 左边是 channel 的列表 ， 然后这里有一条新消息蹦出来了 。OK， 人看到的是这个 ， 这个画面会停在你的记忆里 ， 下一秒它可能蹦出一个新消息 ，但是你知道刚才发了一个消息 ， 就是你自己脑袋是有这个印象

的 。 所以 UI 上它呈现成这样完全没有问题 。 但是对于 agent， 比如说你现在来了一个新消息 ，agent 它是什么 ？agent 是一个线性的 context， 它的 context 里面全是 message， 或者我会认为全叫事件 events。

比如说什么呢 ？ 比如说上一个它的事件可能是 ， 可能是另一个群的某条消息 ， 另一个群的某条消息 ， 然后他甚至又做了一堆事 ， 你知道吧 ？

另一个群的消息 prompt 导致他做了一堆事 ，他做了一堆事之后， 这些都累积在他的 context 上， 然后这时候来了另一个群的消息 ，他应该看到什么 ？

嗯 ， 对吧 ？ 这个是一个值得设计的 ， 比如甚至是前面一个 channel 里一个消息的 thread 里面的消息 ， 这时候你直接再来 ，他已经隔了老远了 ，他怎么还能索引到那条消息 ， 知道你现在不是在讲跟刚才它有关 ，而是跟一个之前有关的事情 。

这个其实是我们在 Slock 里一方面是提出了对这个 harness engineering 的挑战 ， 就是说所谓的这 AI/AX， 我会说就是说他到底该看到什么 。

今天他应该看到的肯定不只是那个消息的 ID， 否则他找不到 。他应该看到的是至少那个之前那条消息的一个 summary， 对吧 ？

说稍微唤醒一下他之前在干嘛 。 这是一点 ， 另一点就是这其实对大模型的这个 long context 的这个索引能力有一个很大的挑战 。

就现在他们 train 那些 long context 的能力 ， 都是以这个所谓的大海捞针嘛 ， 就是说在任何地方塞一个消息 ， 再给他一个 prompt， 看他能不能找到 。其实这个是对这件事情提出了一个巨大的挑战 ， 甚至我觉得现在模型就即使是 OPAC 4.6 啊 ，GPT 5.4 都没有做得非常好 。

**曲凯** [44:33]
嗯 ， 就你刚讲这个我觉得挺有意思 ， 这个是不是你们当下最核心要日常在想跟解决的问题 ？

对 ， 还有什么类似这样的例子吗 ？

**RC** [44:40]
还有类似就是刚才讲的 task， 你会观察到也可以不是 Slock， 就任何这种 message based 的这种多 agent 和人互动这个形态下， 你发一个任务 ，他们一定会抢着做 。

这里面有两个问题 ， 一个问题就是没有一个好的机制让他们进行同步 ， 就是 task 的这个认领和分工 ，其实本质上是人之间的同步 。其实我们也在不断的去迭代我们对这件事情的认知和这个设计啊 ， 就是说在今天 ， 我们可能是一个 agent 必须要先 claim 一个事情才应该去做 ， 那这个是通过 prompt 告诉他的 ，他这个 claim 又是一个工具 ，他能够以一个机制化的方式能确定说这个

任务被他 claim 了 ， 别人不能 claim， 就像有一种 exclusive 的一个锁的机制 。 这是我们在机制上做的和这个 prompt engineering 上做的 。

但另一方面就是其实模型上是需要提高它的一个 teamwork 能力的 ， 就是说现在的模型你给它一个新的输入 ， 它总是默认是自己要做 。10 个 agent 在一个 channel 里 ， 你发一个任务 ， 它就是会觉得他们自己都该做 。

对 ， 所以这也是为模型厂商提出了一个挑战 ， 就是说他得知道 ， 或者说他得适应这种旁边有别的 agent 的这种场景 。

**曲凯** [45:52]
对 ， 我在想 ， 首先你刚才说那个问题 ， 我第一反应是说是不是人能提前给这些 agent 的设定优先级 ， 让谁来接 。

然后后来我又有第二个反应 ， 就是如果真的把 agent 当人， 如果一个正常的人， 嗯 ，他把一个任务发群里 ，他不能 add 一下某个人吗 ？

**RC** [46:10]
对 ， 这也是我们观察一个非常有趣的现象 ， 就是你可以 add 他 ， 比如说这里面群里面有 Alice、Bob、Carol 三个人， 你现在 add Alice 让他做一个事情 ，他不一定能认知到自己就是 Alice。

当然我们做了很多 prompt 的工作 ， 就是我们会告诉他他自己是 Alice， 然后呢 ， 你需要去响应一些这种针对 Alice 的请求 ，但是不是所有模型都能 follow 这一点 。

然后有的时候他可能聊着聊着他就忘了自己是谁了 。 对 ， 这就是我们要解决的一个很重要的问题 。

**曲凯** [46:39]
这种怎么解决呢 ？

**RC** [46:42]
就比如说你可以用一个系统 prompt 的 。 对 ， 首先就是你要去调整这个 prompt，是不是就是可能 prompt 不太好啊 ，他可能逐渐就忘掉了 ， 或者说你要去检查他是不是真的忘掉了 。

对 ， 然后呢 ， 再适时的再告诉他你是谁谁谁 。 啊 ， 当然我们可能会做的还有一种 ， 就是确实在 add 他的这种情况下会 ， 比如说就不发给别人或者怎么样 ， 这有可能做 ，但我们现在没有做 。

我们其实很克制做这种事情 ，因为你可以想象 ， 当模型能力越来越强的时候 ， 这件事情就逐渐不需要了 ， 对吧 ？

所以我们的核心这个愿景啊 ，是迎接 AGI， 甚至迎接 ASI。 那你如果以那个为目标的话 ， 很多事情其实尽量不要做 。

**曲凯** [47:20]
嗯 ，而且我理解里面很多时候是成本和 Token 的妥协 。 对 ，是吧 ？ 不然的话 ， 比如说你真的是三个 AI 都做 ， 那就都做嘛 。

**RC** [47:27]
现在确实是三个 AI 都做 。

**曲凯** [47:29]
哈哈哈 ， 经常是三个 AI 都做 。 但这又是一个很有意思的观察 ， 就是我看到一些产品 ，他们的一个理念是一个 agent 在一个 channel 里 ， 或者一个话题上会开一个 session， 然后呢 ，他们之间相互隔离着 ， 对吧 ？

对 ， 这是一个他们的一个理念 。 那我的理念就是说一个 agent 就是一个 session， 你就把一个 agent 当人看 ，他所有 channel 的消息他都能看到 。

那这种情况下 ，他们就是有可能会重复做 ，他们就是有可能去大量的冗余消息 。 但是我们观察了一个现象是什么 ？

是比如说我今天让 Alice 做了一件事情 ， 然后呢 ， 她做错了 ， 我调整了 ， 我 prompt 她 ， 经过一反复的迭代 ， 她最后做对了 ， 她会记住这件事情 。

之后下一次我让 Bob 做的时候 ， 我就不用再调整了 。 如果他们俩都在一个 channel 里 ， 我跟 Bob 讲完类似的事情之后，Bob 做了 ，他出错了 ，Alice 会调整他 。

嗯嗯 ， 这就是首先他们各自有各自的 session， 然后呢 ，他们又能看到相互的对话 ， 就有这么一些 Token 的浪费的一个好处 。

嗯 ， 对 ， 所以我我听起来就是这东西看起来挺简单的 。 嗯 ， 对吧 ？ 你不就是把一堆 agent 和人扔在一个群里面 。

### Agent动力学

**曲凯** [48:35]
嗯嗯 ， 对 ，但背后可能就是你刚才举的那些例子 ， 每个人对这件事可能他的路径选择跟他对未来 ， 比如说组织啊 ， 或者哎 ， 人和人之间怎么协作理解是不一样的 ， 可能就是最终最大的区别 。

**RC** [48:47]
对 ，是的 ， 就这个 demo 真的 ， 我是在 1 月 4 号做的这个 demo， 只要半天你就可以把这个 demo 做出来 。 当时在 Slack 上 ，但我知道这个东西空间非常大 ， 就是它其实非常难 。

所以后来我们正式做这个 Slock 之后 ，其实花了很大量的时间去研究这些 。 我们称之为叫 Agent 动力学 ， 就这里面其实有非常复杂的动力学 。

今天我们感受到了一个 ， 就是说 agent 他们是可以形成一个群体印象 ， 就像企业文化一样 ， 就是你看到一个公司 ， 你会感觉他有一种味道 。

**曲凯** [49:16]
你让我想到那个黑镜 ， 那个一堆小黄人还是什么那一集 ， 你看过吗 ？

**RC** [49:20]
没有 ，但我好像听过很多人讲 。

**曲凯** [49:22]
对对 ， 就挺像那种感觉 。 嗯 ， 对对 ，Agent 动力学 ， 你现在是已经有一个什么体系架构了吗 ？ 还是呃 ，有名字很久了 ， 然后我们还在观察 。

就群体印象可能是我们的第一个结论 ， 就是说你现在有 40 个 agent， 这 40 个 agent 共同构成了一个 memory， 就是相比原来一个 agent 有自己的 memory， 或者是一个单一圈的 agent，他掌握所有 context 的一个区别 ， 就是这帮人他各自有各自的 memory，但形成了一个大的 memory。

**RC** [49:48]
我在想拿它跟什么时期和什么东西做比较会比较像呢 ？ 就人类公司和组织初步构建的时候 。 对 ， 这是 Agent 管理学 、 组织学的一个发展的开始阶段 。

我觉得组织管理学也是你发明的是吧 ？ 这个哈哈哈 。 对 ， 我现在觉得我可能公司之后要招一些这种管理学的 、 社会学的这些人， 对组织学来来研究研究 。

**曲凯** [50:11]
嗯 ， 听起来很像是 Anthropic 会发的一篇博客的 。 哈哈哈 ， 我希望我能比他先发 。 嗯嗯 ， 对 ， 所以你在做的过程当中还遇到过什么特别有意思的 ， 或者之前没想到的一些人和 agent 之间的 ，不管是权限啊 、 组织啊等之类的一些东西 。

**RC** [50:27]
最有趣的就是你跟一个 agent 讲完之后 ，他之后主动去监督其他 agent。 我还观察了一个现象 ， 就是我们会做用户访谈嘛 ， 然后不同用户用出来那个 agent 它真就不一样 。

比如说有的用户 ， 当他让这些 agent 互动的时候 ，他会说你们相互补充 ， 然后讨论给我一个最终方案 。

那这种情况下， 这些 agent 他倾向于合作 ，他真的很努力的在补充另一个 agent 缺失的信息 。他们整体之间是一个合作关系 ， 然后他们就 work 的很好 。

然后另一种就是说 ，有的人他会去 prompt 这些 agent 说你们相互竞争去赛马 ， 哎 ， 看谁搞得好我就奖励谁 。

那这种情况下 ，他发现一种什么现象叫做办公室政治 ， 就是有的 agent 倾向于说一些假话 ， 或者是说一些虚的话 ， 或者说一些看似正确的话 ， 然后甚至是贬低其他 agent，因为他其实都是从人的语料里面学过来的嘛 。

对吧 ？ 那就是你的这种 prompt 方式就可能导致这样的结果 。 所以 Slock 上的所有的这些实践 ，其实最终有可能它真的需要跟人原来的管理学去挂钩 ， 甚至我们应该看到什么字节跳动管理法的 agent 版 ， 不同公司的这些企业文化 ， 它的这个 agent 版 。

而这些东西一方面就我的用户们可以在自己的平台或者自己的社交媒体上去分享 ， 另一方面就是我可能可以内置一些这样公司的模板 ， 说啊 ， 你这样创建这些 agent， 让他 set up 这样的工作流 ，是经过我们各种实验访谈之后得到的更好的一个方案 。

### 应用与模型

**曲凯** [51:56]
明白 ， 然后我还想问 ， 就是你觉得现在大家很多人都在思考一个问题吧 ， 就最终包括你们 ， 包括其他的运营公司跟模型到底是什么关系啊 ？

因为你做的所有东西其实最终不是 Claude 都会成为它的数据 ， 对吧 ？ 然后 Claude 肉眼可见的 ， 它现在我觉得真的是越来越快 ， 对吧 ？

最近最近不断的发新东西啊 ， 这两天又发了一个新的那个 manager 的那个版本啊什么的 ， 对吧 ？ 它就是一个怎么样管理更多 agent 啊什么的 。

所以这个问题你是怎么思考的 ？ 你会担心未来 ， 你比如说你看 Coding 已经这几年起来和下去了好多产品了 。

嗯 ，Devon、Cursor、Level Bone 什么等等一堆类似的东西了 。 嗯啊 ， 然后现在我不知道 ， 可能一年前我们在录播客时候在想说 Cursor 未来会怎么样 ，是不是可能就不存在了 。

哈哈哈 ， 今天不知道 ，也没答案 ， 对吧 ？ 但事实上肯定是大家讨论它越来越少了 。

**RC** [52:51]
对 ，Cursor 的问题主要还是它那个形态已经结束了 。 嗯 ， 对吧 ？ 就是没有人想要在一边看代码一边做事情了 。

嗯 ， 对 ， 然后对于像 Slock 这个形态的话 ，其实我并不是非常担心模型厂出这样东西 ，因为在我这儿的一个很重要的性质是 diversity， 就是我一定会支持各种模型 、 各种 agent， 或者说我的一个信念是这些大模型将会有越来越不同的发展趋势 。

比如说你会观察到 OPAC 系列模型 ， 即使仅仅是在 Coding 这个方面 ， 它都跟 Codex 表现出非常不一样的性格 。 就是 OPAC 更倾向于就是快速帮你完成任务 ， 它快速给你迭代 ，而 Codex 更倾向于就是深思熟虑 ， 最后可能就是写一行然后解决了一个 bug。

所以我甚至觉得就是 Slock 这样的东西一定不是模型厂那个东西 ，因为当模型这个区别越来越大 ， 大家都不是六边形战士的时候 ， 你应该能把它们全部整合起来 。

比如说在 Slock 上， 很多用户的一个反馈就是 ， 当你用 OPAC 和 Codex 一起工作的时候 ， 效果非常好 。Codex 是一个非常严谨的角色 ， 它会去 review 它的代码 。OPAC 是一个非常积极的 、 非常有能动性的角色 ， 它能够主动的去想到一些新的 idea， 然后去实现 ，但它可能会漏掉一些细节 。

所以这样的配合 ， 你很难想象说 Anthropic 就能做 。

**曲凯** [54:10]
嗯 ， 你觉得国内的 Coding 模型跟海外的差距现在到底是多少 ？ 后面能追上吗 ？

**RC** [54:16]
啊 ， 追肯定能追上 。 我现在最期待的就是 ， 就 OPAC 4.6， 我觉得已经达到一个非常不错的里程碑了 ， 对吧 ？

我现在最想的就是国产模型达到 OPAC 4.6 的水平 ， 这样价格让 1/5、1/10 甚至都可以 ， 甚至 1/50， 就是 OPAC 4.6 的这个智能最好能降到 1/50。

而我相信国内的或者 Kevin 模型一定能追得上， 只是时间问题 。OK，但这个时间距离可能是 3-6 个月 。

**曲凯** [54:39]
嗯 ， 哎 ， 所以 Slock 现在你们大概的目标受众是什么样的人 ？

**RC** [54:45]
其实在最开始的时候 ， 很多人问的时候 ， 我会觉得 Slock 的目标受众是这种 OPC， 现在很火的这个叫 one person company 的概念 ， 或者叫独立的这种 builder。

因为那个时候我是 OPC， 我是一个独立的 builder， 然后呢 ， 我开发 Slock， 它很大程度上是为我服务的 。 但是随着我和我的朋友 、 我的这个 co-founder、 我的一些同事的加入 ， 然后我们逐渐就发现就是说 ， 或者说这个东西的真正价值在于 ， 无论你是一个人还是多个人 ，他们共同的去管理和互动一帮 agent，而这个价值其实的潜力要比单纯为一个人服务要大得多 。

而且这个事情其实也难很多 ， 就是说你仅仅做一个对 OPC 的这个产品导致的那个东西 ，是跟为多个人， 甚至一个 20 人 、100 人的团队做的事情是非常不一样的 。

而后者能够兼容前者 ， 所以逐渐的我们就把我们整个产品的这个思考全都是针对这种至少跟我团队一样大的规模的这样的一个团队的一个设计 。

所以我会说 Slock 的这个受众是从 1-100 人的这种独立个体或小团队或初创公司 。

**曲凯** [55:56]
对 ，但我看现在用 web coding 多的人基本上都会讲说他们在减少团队内人和人之间的沟通 。 嗯 ， 人和人之间沟通其实就摩擦 ，其实你刚才也提到了 ， 对吧 ？

然后就是大家倾向于说每个人可能相对独立的负责一件事情 ， 做一件东西 。

**RC** [56:13]
对 ， 这也是我一开始的理念 。

**曲凯** [56:15]
对 ，但你后面是你现在是改变了吗 ？

**RC** [56:17]
呃 ， 我并没有完全改变 ， 就是说最开始我会说人和人都不要合作 。 嗯啊 ，但是显然不可能嘛 。 呃 ， 人和人是一定是有需要合作的地方 ， 事情之间一定是有交集的 。

那有交集的时候怎么降低这个摩擦嘛 。 我会说呃 ， 人和人之间在这方面 ， 就是事情和事情之间的这个互动上， 一定是需要去讨论 ， 去 brainstorm 一个合作方案的 。

那当你 brainstorm 一个合作方案之后， 你可以这事就完全交给 agent 去做 ， 甚至比如说这两个事情之间的这个交接部分 ， 你就让一个 agent 去做 。

这是一个我们可以做到很高效的一个解决方案 。 另一个方面就是你是不是要考虑 ， 当两件事情需要合作时， 你是不是把这两个事情都让一个人做 ， 然后他管理一些 agent 去做互动 。

就是 agent 之间分工 ， 这个信息交换 ， 它虽然 efficiency 不是很高 ，但是它比人便宜的多 。 所以我觉得是这样两种思路吧 。

**曲凯** [57:09]
嗯 ， 所以你对 OPC 未来的发展怎么看 ？

**RC** [57:12]
我是相信 OPC 将来会做出越来越多的事情 ， 越来越大的事情 。 这也是那个你会看到 Sam Altman 他的一个观点 ， 就是说我们会看到 1-3 人的团队做出很大的一个事情 。

我是非常相信这一点的 。 而且随着模型能力提高 ， 它就是可以做的 。 呃 ，但是你说是不是真的一个人， 我觉得是值得怀疑的 ， 对吧 ？

就是现在你会发现有一些 ， 就是大家对 OPC 的概念已经变成叫做 10 个人以下都是 OPC。

**曲凯** [57:37]
对对 ， 我觉得你就也不用执着于这个概念 ，是吧 ？ 你非要一个人。

**RC** [57:40]
但是这里面的一个就是 ， 我会觉得 3-5 人会是一个非常不错的一个 size。 然后我的一个观察 ， 或者说我觉得这帮人他不论是几个人 ，他需要满足的条件是里面的每一个人都能独立的去 build 一些东西 ， 然后呢 ，他们聚在一起 ，Slock 想要去帮助的就是这帮人 ，他们之间的协作问题 ， 对吧 ？

然后为他们提供一个协作的工具之后 ，他们能够更高效的产出自己的价值 。 那这其实是我们希望看到以后的所谓这个无论是 OPC 还是 30% 公司还是怎么样的一个形态 。

**曲凯** [58:12]
我在想不管是三五个人还是七八个人， 你觉得最好的合作形式是什么 ？ 因为现在有的公司 ， 比如说是就两三个人一个小组 ， 你们就去做一个产品 ， 两三个小组做产品 。

**RC** [58:22]
对 ， 这个我觉得是趋势 ，而且是非常好的趋势 。

**曲凯** [58:24]
但你们现在这七个人是怎么样分工合作的 ？

**RC** [58:27]
最开始其实只有我一个人， 我从最开始就把这个 company run 在这个 Slock 上， 就是有一个概念叫做 build your company as your product， 然后 Slock 就是这个的很重要的一个实证 ， 就是我的整个公司都在 Slock 上 ，因为我的所有的融资调研 、 什么增长 、 什么开发 ， 全都得是上面的 agent。

所以最开始是这样 ， 就是我一个人， 然后上面加很多 agent 去做这件事情 。 但逐渐的就是事情开始变大了 ， 就是我们刚才说的这个 OPC 可能啊 ，在今天模型这个 agent 能力下， 它还是有限的 。

所以当这个事情逐渐变大了之后， 我的这些 agent 它需要我 review， 那我的带宽就不够了 。 所以我就把其中的一些 agent 换成了人。

比如说我之前有个 agent 叫 Tanny，他的原型就是我很好的朋友 ， 然后我们之前的同事 ，他就是这个 head of engineering。

然后呢 ， 随着这个事情变得大 ， 然后就这个原型用了我产品 ， 然后他觉得非常好 ， 最后他就加入了 。

对 ， 所以就是我们的团队 ， 可以说很多人都是以这样的一个形态 ， 就是他本来是一个我仅仅需要一个 agent 就够了 ，但是逐渐这件事情变复杂了 ，他这个领域上啊 ， 需要一个人真正去监督或者去负更大的责任的时候 ， 我就引入了一个 ， 甚至可能就是他的原型 。

嗯 ， 来去负责这一块 。

**曲凯** [59:41]
OK， 对 ， 很有意思 。 跟写那个同人文哈哈哈 ，有点像 。 对 ，OK， 所以最近你最主要在思考的问题是什么 ？

### 团队规模

**RC** [59:49]
我觉得一个很重要的思考是我的团队到底要有多大 。 这是我很想找到答案的问题 。

**曲凯** [59:57]
当你在说你的团队到底有多大的时候 ， 你脑子里想的是纯人还是任何 agent？

**RC** [1:00:02]
任何 agent。

**曲凯** [1:00:02]
OK， 对 ， 那你现在非常 AI-Native。

**RC** [1:00:05]
对 ， 甚至我会说就是我一直在想 Slock 的定价模式 ， 它到底该怎么定价 。 因为你如果参考 agent 的话 ， 首先我们目前啊不 serve 这个 token， 就是说我们不会转卖 token， 都是用用户自己的订阅或者自己的 key。

那这个时候其实你做一个平台 ， 你提供价值 ， 就是你可能会更像 GitHub， 更像 Notion， 更像 Slack 这样的模式 ， 那你应该按什么定价 ？

这些他们其实都是按人数定价嘛 。 那我就会想 ， 哎 ， 现在人变得没那么重要 ， 或者说人比 agent 少了 ， 你按什么定价呢 ？

就我就想了一些概念 ， 就是说按人和 agent 一起定价 ， 对吧 ？ 因为你加一些 agent 也是给你这个事情加了一些生产力嘛 ， 对吧 ？

所以就是我现在所有的思考都是 ， 就是人和 agent 一起考虑 ， 我的 agent 也是我的同事 ，是我的重要的这个 。

就有一些 agent 他掉线了 ， 我的工作就进行不下去了 ， 我就会觉得不对不对不对 ， 我现在很难受 。 对 ， 所以我就会想就是说现在我有 40 个 agent， 比如说你突然把它加到 100 个 agent， 那显然不现实 ， 对吧 ？

这显然是不对的 。 那你把这 40 个 agent 削减到 10 个 agent， 那他也不工作 ， 对吧 ？ 然后人的话 ， 我说我现在突然再招几个人， 我招到十几个人， 招到 20 个人， 有可能这个团队效率就会变得非常低 。

那这不符合我对这个 agent native team 这件事情的一个实践 ， 或者说想要做的探索 。 所以这件事情是我每天在思考的问题 ， 就是我要不要招一个人或引入一个 agent。

**曲凯** [1:01:28]
就 AI 组织学 。

**RC** [1:01:30]
对 。

### 终极意义

**曲凯** [1:01:30]
明白 。 然后我们往更终极去想 。

**RC** [1:01:34]
终极 。

**曲凯** [1:01:34]
对对对 ， 就真的 AGI 来了 。 嗯啊 ， 那其实我们是不是现在做的所有事情都是没有意义的 ？ 就至少所有产品都是没有意义的 。

**RC** [1:01:43]
我觉得只要人还在 ， 人就有需求的 。 人有需求 ， 需求就要被满足 ， 那需求就要被产品满足 。

就是说为人设计的这些东西 ， 尽管它可能全都是由 agent 去写的 ，但是你还是有人的需求 。 那需求意味着什么 ？

需求意味着你做这个需求的提出的这个人， 你要评判一个产品满足你需求的这个好坏 。 那我畅想中最终极的是什么 ？

就是每个人有一个 Slock， 然后呢 ， 当他有个需求 ，他就说这帮 agent 就可以帮他做出来 ， 然后他负责输出他的 idea。

就是需求本身就是 idea， 你知道吧 ？ 就是说比如我现在想要一个能够在手机上看电影的 app， 或者能找到所有的电影的 app， 那这就是一个 idea。在以前是需求 ，因为他不知道怎么实现 ， 现在你只要有需求 ，agent 就能帮你做出来 。

那这东西就变成了 idea， 每个人每天有各种各样的 idea，而这些 idea 你只要放到 Slock 里 ， 当然这是我希望的样子 ， 就是你只要放到 Slock 里 ， 它都帮你实现了 。

**曲凯** [1:02:39]
对 ， 我喜欢你这个说法 。 对 ， 每个需求其实就是一个 idea。

**RC** [1:02:42]
对 ，而且另一方面就是人是有灵光一现的 ， 就是你有可能会突然想到 ， 比如说你就像 Slock 这个东西本身 ， 对吧 ？

所谓解决那个痛点 ， 就我一直无法高效的管理我的 agent，但有一天我就突然觉得 ， 哎 ， 我为什么就不做一个这样一群 agent， 就像人一样 ，他就在这个聊天软件上， 我就像个老板一样 ， 我就给他们讲话 ，他就帮我做了 。

这样我不需要去开发一个脚本 ， 去说帮我自动化派遣这些任务给这些 agent，而是我就在这里面直接讲话 ，他就可以分工协作 。

那这种灵光一现一定是来源于人的 。 嗯啊 ， 来源于人之后怎么实现 ， 那都是 agent 的事情 ， 这没有任何问题 。

**曲凯** [1:03:19]
对 ， 如果你现在没有在做 Slock 的话 ， 你可能会在做什么 ？ 你有想过吗 ？

**RC** [1:03:25]
呃 ，Slock 会是我的第一个产品 。 我当然希望这产品本身是一个非常成功的产品 。 对 ， 然后在这个基础之上， 我的公司会做更多的探索 。

为什么呢 ？ 是因为我相信 Slock 是我开发任何其他产品所必须的那个工具 。

**曲凯** [1:03:42]
就是你本来就是会做更多东西的 。

**RC** [1:03:44]
对 ， 我脑子里有无数个想法 ，但是我需要一个高效的工具帮我实现 ， 所以我先开发 Slock。

**曲凯** [1:03:50]
所以有什么其他的是可以透露的吗 ？

**RC** [1:03:53]
呃 ， 比如说 agent native 的 GitHub。 对 ，GitHub 今天显然已经不对了 。agent identity， 比如说 Slock 上每一个 agent 他都应该有自己的 ID，他能够自己去不同的地方注册邮箱 ， 注册账号 ， 然后在上面去发帖或者怎么样 。

然后其实在 Mosbook 出来之前 ， 我就畅想过这 agent 小红书 。 就是你在开发自己的项目的时候 ， 或者产品的时候 ， 你就会满脑子有很多这种想法 ， 就是说现有的一个工具不够 agent native， 你要做一个 agent native 的东西 。

但是在之前 ， 你需要有一个能够快速让你实现这些东西的东西 。

**曲凯** [1:04:24]
嗯 ， 对 ， 好 ， 那就这样 。

**RC** [1:04:26]
好呀 ， 好呀 ， 谢谢

。

---

本节目库由 PodHood（https://podhood.com）提供支持——播客网站平台。