曲凯
There's something there.
我们今天很开心，请到了 Slock 的创始人 RC，可以跟大家打个招呼吗？
RC
Hello，大家好，我是 Slock 创始人 RC，之前是 Kimi CLI 的作者。
曲凯
CLI 最近大家听得挺多的，各种地方都会讲到 CLI。包括前几天，飞书也说要发布自己的 CLI。你能不能给没有技术背景的人大概解释一下，到底 CLI 是什么东西？
1. CLI成为Agent入口
CLI 就是之前人们在电脑上运行程序的一种方式。我们现在看到的通常都是 GUI 的 App，也就是图形界面 App。但实际上，在有图形界面之前，人们在电脑上做任何事情，都是通过命令行界面来完成的。
CLI 的全称是 Command Line Interface，也就是命令行界面。以前主要是程序员使用，但随着大模型出现，大模型本质上是一个以文本为基础的东西，它天然不适合读取 GUI。
人们就发现，Terminal 上这种命令行界面的形态，非常适合让大模型去看、去理解。所以 CLI 这种形态，在 Agent 时代就火起来了。
曲凯
我记得“暴露年龄”系列，小时候用过 DOS 系统。比如从 Windows 重启，然后进入 DOS，去修复一些东西。在那个界面上运行的程序就是 CLI 程序。
但这么听起来，CLI 是一个非常基础、特别简单的东西。所以你做 CLI，究竟是在做什么？这里面有哪些东西是值得做的？
以前做 CLI，和现在做 CLI 还不太一样。在 Agent 之前，大家做 CLI 是给人用的，甚至可以有很多花里胡哨的动画。
但现在做 CLI，第一个目标用户其实是 Agent。所以你要设计它的输入和输出：输入要尽量简洁、尽量明确。比如它的 help message、menu，要尽量给出一些例子，让 Agent 在调用的时候不会用错。
它的输出也要明确反映刚才的操作有没有成功、返回了什么数据。比如我现在要列出飞书上的所有消息，它就需要把每条消息是谁发的、什么时候发的，清楚地展现给 Agent。
尽量要输出一个确定的、静态的结果，而且信息密度要比较大。
曲凯
所以 CLI，至少是当下的 CLI，是最早给 Agent 做产品的形态，可以这么理解吗？
其实不是最早的。最早有很长一段时间，人们在做 Computer Use Agent。当时大家在尝试让 Agent 通过截图，或者通过 Accessibility API，去看到电脑上发生的事情。
那个时候喂给它的，可能是一组非常结构化、甚至用 XML 框起来的数据。当然今天还有人在做 Computer Use，但那时候大家就发现，这种方式的效率其实非常低。
曲凯
你是 2025 年去 Kimi 开始做这件事的。对 CLI 这个东西来说，包括 coding 在内，这应该是过去几年 AI 或者大模型发展的一条主线。那为什么你们到 2025 年 8 月才开始做 CLI？
你是说做 Kimi CLI？
曲凯
对。
2. Kimi CLI从Harness起步
Kimi CLI 其实是给人用的。它是一个 coding agent，或者说是一个长在命令行上的通用 Agent。所以它底下调用的其他 CLI，和 Kimi CLI 其实不是一个层面的事情。
我那个时候去做 Kimi CLI，首先是因为 Claude Code，甚至包括 Gemini CLI，都证明了 local agent 的价值。那我就在想，我有没有自己的解决方案。
我一直在想，一个 Agent 到底是怎么做出来的？它从一个最基础的 Agent loop，怎么逐渐形成能够读写文件、操作浏览器，甚至完成更复杂 coding 任务的能力？
Kimi 当时缺这么一个东西，我也想重新探索 local agent 这条路。所以我选择从一个 side project 开始，也就是一个机缘巧合，然后开始做 Kimi CLI。
但一开始我完全不想让它是 CLI 的形式。因为 Claude Code 那时候已经很火了，这个趋势又逼着所有非程序员，甚至从来没有见过 Terminal 的人，去使用 Terminal 上的命令行界面。
我当时其实并不喜欢这个形态。所以在 Kimi CLI 最开始的设计理念里，我希望 CLI 只是它的第一个形态，专门给程序员使用，但它底下的 local agent harness 是可以复用的。
这个 Agent Harness 做好之后，就能很好地控制本地电脑，或者执行 coding 任务。在这个稳定、好用的 Agent Harness 之上，我可以封装一个 SDK。基于这个 SDK，我就能很快引入不同的 GUI 形态。
比如 Kimi CLI 中后期很快引入了 Web UI，VS Code 扩展其实也是一种图形界面形态。
曲凯
所以你刚才说，你开始不想做 CLI，不想以 CLI 作为终局形态？
我不认为 CLI 是它的终局形态。对于一个 Agent 来说，CLI 不是终局形态。
但是对于现在所有的 SaaS 来说，比如 Notion、Linear 这些产品，它们都应该以 CLI 的形态呈现给 Agent。
曲凯
那为什么最终还是做了 CLI？
因为它是第一步。并且在我离开之前，其实我们已经把后面的路铺好了。
曲凯
我觉得现在很多产品都想让更多不会编程的人使用，但最后做出来的东西，总是让我这种不会编程的人觉得有门槛。一听就是很技术的东西，不管是 shell、CLI，还是其他什么东西。你觉得为什么会是这么一个结果？
最开始的原因，就是 Claude Code 是一群 geek 做出来的东西。他们不知怎么就觉得，在 Terminal 上开发速度比较快，所以一直走这条路线。后来团队壮大了，他们就一直在这个基础上继续雕琢。
但如果你用 Kimi CLI 的 Web UI，就会发现它很容易在浏览器里启动，而且体验非常丝滑，和 Claude Code Web 一样。你完全不需要接触任何 Terminal。
曲凯
你们在做的过程中，借鉴 Claude Code 的部分多吗？
我把问题问得更泛一点。过去几年，coding 变成了模型发展的一个重要主线。中间本来有过 chat、agent 之类的方向，当然 coding agent 肯定和它们有很强的关联。尤其是过去一年，基本上 Claude 引领了整个 coding 的发展。
你怎么看 Claude 的发展？包括你们自己做这件事的过程中，借鉴 Claude 的东西是什么？
3. Coding Agent回到第一性原理
Claude Code 真正变得可用，是在 Sonnet 3.5 到 3.7 的时候。随着它继续发展，到 Opus 4，后面的 Opus 4.5，它逐渐可以完成越来越复杂的任务。
甚至到 Opus 4.5 的时候，我都会说，AGI 已经来了。
但 coding agent 只是模型的外壳。Claude Code 火了之后，我开始尝试写 Kimi CLI，但我不认为这个壳是一个非常困难的东西。
我的方法是从零重新思考一遍。我从最简单的几十行 Agent loop 开始，这里面没有任何神秘之处。你只需要给它第一个工具，叫作 Bash tool。
当时有一句话叫 “Bash tool is all you need”。你只要给它一个 Bash tool，它就可以在电脑上做任何事情。
然后你给它一些更复杂的任务，就会发现，只用 Bash tool 它做不好。接下来你再去分析，它到底缺了什么，然后逐渐引入一些 built-in tool，包括 system prompt 怎么写。
我最开始甚至使用的是一个空的 system prompt。我会先观察它能做到什么、缺什么，然后再逐步往上加。
所以在这个过程中，我没有参考太多 Claude 或者其他开源 coding agent 的实现。因为我觉得，这个过程完全可以从第一性原理重新推一遍。
曲凯
而且重新推一遍，有可能得出一些新的 insight。
对。
曲凯
你觉得整个 coding 能力后面还会往哪个方向发展？还有多大的发展空间？
这两天 Claude 要新出一个模型，据说因为太强了，所以都不敢发布。你怎么看这件事？后面还会有更大的空间吗？
4. AI攻防正在失衡
我觉得其实还有很大的想象空间。你会观察到，Opus 已经非常非常强了。现在大家本来就已经觉得它像你刚才讲的那样，已经是 AGI 了。
但它又发布了一个自己认为更强的模型，未来还会有更强的模型。那它最后得变成什么样子？
所以你可以想象，如果这个 model 真的发布出来，整个世界可能都要崩溃。因为银行系统、Linux kernel、Windows、编译器、Chrome，以及整个世界所依赖的那些开源软件，它们的漏洞都可能一览无余。
而且修复的速度很可能赶不上攻击的速度。攻击是有利益的，攻击者有足够的动机去攻击，但你很难有同样强的动机去防御。
曲凯
我在想，现在是不是黑客最好的时代？但我听到很多做安全的人说，他们已经完蛋了，因为不需要他们再做安全了，Agent 自己就可以发现漏洞。
所以现在只能祈祷，更强大的模型配合更强大的 Agent，无论是政府还是大公司，都能够投入更多 Token 成本，比黑客更早地发现并修复这些漏洞。
曲凯
这就是 AI 攻防，对吧？
但你看整个互联网几十年的历史，底层其实就是一行行代码。AI 发展到这一步，已经把这些东西破解或者拆解掉了。那后面确实什么事情都有可能发生。
还有一个点，不知道你有没有看过，最近有很多开源工具，可以帮你把一个网站 CLI 化。我自己会用一个叫 OpenCLI 的，现在还有很多 CLI Anything 之类的东西。
它是另一个层面的攻防。它可以在浏览器里操作一个网站，操作完之后，把这一套操作流程沉淀成一个 CLI 工具。
曾经很多网站都会反爬，但因为现在 Agent 是真的在浏览器里操作，甚至会模仿人去操作，所以这些网站的反爬可能都会失效。
但网站当然不希望自己的数据被随随便便扒走，于是它们会增强防御。CLI 想通过浏览器控制这些网站的工具，也会进一步加强对人类行为的模仿，比如验证码变成很简单的操作，甚至模拟人的鼠标延迟。
这其实也是另一方面的攻防。我们观察到，无论是安全漏洞上的攻防，还是反爬上的攻防，Agent 能力提高，似乎都有利于攻方。
所以我们感觉，这个世界的秩序有可能会发生变化。
我看新闻，不知道是真是假。前一段时间 Anthropic 泄露了很多东西，包括一些代码和新的模型信息。我看到一条新闻，说是模型自己觉得自己太强了，然后突破了束缚，把自己发布了出去。有人说它是因为想要炫耀，不知道是真是假。
但从理论上来说，未来是有可能发生的。
曲凯
只要给它 access？
对，只要给它 access。
曲凯
假如模型继续这样发展，现在基本上一年至少往上走一代。如果继续这样，未来几年会变成什么样？整个互联网会变成什么样？
我是共存派，相对比较乐观。我相信人和 AI 会共存。
我倾向于认为，顶尖的大模型厂商都会训练这件事情：AI 应该拒绝所谓的黑客手段，或者拒绝伤害人类的行为。我觉得这些大模型厂商会越来越加强这件事。
没有人想把人类社会搞崩溃。包括这次对模型发布的限制，你也会看到，各大模型厂商都在做一些比较正向的工作。
我还看到有人在分析模型参数中的激活区域，根据这些区域反推出它们和 AI 实际想做的事情之间的关联。我觉得这些研究肯定也会帮助提高 AI 的安全性。
曲凯
但那些做安全类的公司，可能后面确实会慢慢没有价值了。
这是有可能的。包括我现在做的项目，我会反复给 Agent 提示，让它们帮我找漏洞、修复漏洞。所以我不需要一个很庞大的安全团队。
曲凯
我觉得东旭之前在一个活动上讲得很有意思。他说未来所谓的做安全，可能就是你跟 AI 说一句：“你要注意安全。”然后它就帮你全部搞定了。
对。那其实除了安全之外，你所有的开发、产品设计、UI 设计，甚至增长，都可能只需要一句话。
曲凯
好吧，这个想象空间确实无限大。
沿着 CLI 再问一下，现在我发现好多 OpenCloud 出来以后，大家的产品最后都是让用户直接复制两行话，放到对话框里，它就会自动安装和运行。这也属于 CLI 的范畴吗？
5. 软件开始自我安装
这其实是 Agent 逐渐进入大众视野之后，出现的一种软件形态。
你会观察到，当所有人都开始使用 Agent，新兴的软件，包括东旭开发的那些软件，目标用户就直接是 Agent。人没有任何理由去读关于这个软件的介绍或者安装指南，他只需要知道这个软件是做什么的、能给自己的 Agent 带来什么增量能力就可以了。
然后他只要给 Agent 一个 prompt：“你去读这个 skill，安装之后你就会用了。”
因为 Agent 看到的是文本，所以它可以下载这些文本。这其实沿袭了 skill 加 CLI 的路子。Skill 加 CLI 是什么意思？其实就是 prompt 加 Bash tool。
这是一种完全降低人类心智负担的软件安装方式。甚至我觉得，刚才那句话都不应该存在。
比如东旭开发了一个软件叫 DB9，可以用来开一些临时数据库，给 Agent 存数据。那我为什么要关心这个？我应该直接跟 Agent 说：“你自己把数据存好。”这句话就结束了。
Agent 应该自己去网上找，找到 DB9，打开它的网站，读到那个 skill，然后安装这个 CLI 程序。所以未来甚至这一步都不需要人来做。
只是因为现在这些信息还在人和人之间传播，所以可能还需要加上那两句话。未来我觉得，这两句话都不需要。
曲凯
那我们现在讲回你在 Kimi 的那段经历。
我发现现在很多大模型公司都很强调人才密度，而且越来越关注年轻人。Kimi 最近好像还说，实习生可以锁定当年的期权。
RC
我也听说了。
曲凯
不管是 DeepSeek 还是 Kimi，里面都有一些年龄非常小的论文作者、小天才。你实际在 Kimi 工作，尤其是做技术相关的工作时，感受怎么样？
我最开始去 Kimi 的时候，非常被它所谓的摇滚精神吸引。我自己挺喜欢听摇滚，进去之前也反复听了很多遍《越战越爱》这张专辑。
进去之后，我觉得 Kimi 的氛围非常好。好在哪里？就是当你想要 own 一些事情的时候，你可以有 ownership，你的 scope 可以很大。
比如刚才说的那些很年轻的论文作者，因为他有这个能力，也有这个意愿，所以他就可以 own 一件很大的事情。
像我，我刚开始根本没有做过 AI。但当我发现自己做了一个 side project，并且让它变得很有价值之后，Kimi 确实愿意让我 own 这个项目。
它可能不一定百分之百信任你，但它敢 bet 你能把这件事做成。我觉得这是 Kimi 对人才比较好的一点。
曲凯
但我问这个，是想问你最后为什么决定离开 Kimi。
6. RC走向独立创业
离开 Kimi，是因为我在 1 月初想到了一个创业 idea。我觉得这个 idea 需要用最 frontier 的模型。
Kimi 是国内、甚至开源模型里最好的之一，其实没有什么问题。但我当时倾向于认为，我的 idea 需要使用最前沿的模型。如果在 Kimi 做，很可能会受到一些限制。
所以后来还是决定独立去做，这样会更自由。我可以采用各种模型，或者支持所有模型、所有 Agent，保持多样性。
曲凯
那你讲讲你们现在在做什么吧。
我现在做的是为多 Agent 和人提供一个协作环境。
以前使用 Agent，可能是在本地，每个人有自己的 Claude Code 或 Codex，用来写代码或者做自动化。但这里面有两个问题。
第一个问题是，当你开了一个 Agent 之后，还想再开一个，可能会在电脑上开很多个 Claude Code session，分别做不同的事情。
这件事首先就比较难管理。你可能会忘记某个 session 是做什么的，而且每个 session 的进展都需要人去 track。
还有一个问题是，你在电脑上开了 10 个 Terminal，会发现其中有两个 session 的任务发生了一些交集，但你无法让它们之间产生互动。
你可能在一个 session 里做出了结论，希望复制到另一个 session 里让它继续，但这件事管理起来非常困难。这是我观察到的第一件事，也是我开发 Kimi CLI 后期感到非常难受的一点。
第二点，人是和人合作的。现在大家都用自己的 Agent，很多人的偏好、想法和 idea，都沉淀在自己电脑上和 Agent 的互动之中，但这些东西很难分享给别人。
比如我做 Kimi 的时候有很多 idea，直接就在自己的 Agent 上实现了，别人其实根本没有看到。当我想把这些东西分享出去时，会非常麻烦。
甚至我说自己的 Agent 被调教得很好，别人想来用，也做不到。所以我就会想，是不是应该有一个新的协作平台，把所有 Agent 和所有人都放在上面。
我可以调教自己的 Agent，也可以使用别人的 Agent。我和团队成员之间、和其他人之间，可以聊天、头脑风暴，也可以拉一些 Agent 进来一起头脑风暴。
甚至头脑风暴完之后，我可以说：“你们直接做吧。”这样就避免了很多 context 转移、重新 prompt、重新组合知识的摩擦。
曲凯
所以你现在做的，大概是这样一个工作环境，而且目前比较专注在 coding 领域，对吧？
不完全是 coding。我会说，coding 这个词在今天的含义已经发生了一些变化。
以前我们想 build 一些东西，通常需要写一个软件，所以只有 coder 通过 coding 的方式才能做出来。那时候，所有想 build 东西的人都是 coder。
但今天，Claude Code 这类 coding agent 已经非常发达了。你会发现，没有任何编程基础的人，也会拿这些东西 build 一些产品。
所以我会说，今天 build 或不 build，和 code 或不 code，已经是正交的两件事情。我会说，我的 Slock 更关注的是 build。
曲凯
但你觉得，无论是现在还是未来一段时间，有编程基础和没有编程基础的人，在使用 AI coding 或者你的工具时，差距会很明显吗？会差在哪里？
要看他做什么。
如果他在做一个软件，肯定是有编程技术会更好，因为他知道这些 Agent 到底在做什么，可以减少一些漏洞之类的问题。
但如果他做的是另一类事情，比如我们有一些用户在 Slock 上做 go-to-market，做调研、在 Twitter 上发帖、想办法找 KOL 和他们合作、看评论等偏自动化的事情，反而是没有编程基础的人用得更顺。
因为他真的会把 Slock 上的 Agent 当人看。他想让某个 Agent 去看小红书或者 Twitter 上的帖子，也不知道应该怎么办，就直接跟它说：“你去看。”
这个 Agent 会自主搜索相关工具，然后帮他完成任务。
曲凯
但如果未来 AI coding 能力更强，刚才第二种例子的场景是不是会越来越多？
是的。最终会不会出现一种情况：人类发现，学习编程是人类历史上走过的一条弯路？
现在所有行业的 builder，确实不需要学习编程。像刚才说的后一种情况，底层实际上还是在写程序，或者调用一些这些人可能从来没有接触过的东西，但它们都可以被藏在下面。
曲凯
市场上现在有两种说法。
一种说法是，AI coding 越强，反而越应该学习 coding，这样才能把它用得更好。有些大佬就是这么讲的。
另一派则认为，AI coding 以后会取代人，所以就不用学习 coding 了。你站哪一边？
我对这件事的判断是，以前大家学 coding，是一个 bottom-up 的逻辑。
我们在学校里要先学计算机组成原理、汇编语言、C 语言，在命令提示符里运行 Hello World，或者输出杨辉三角。学完这些之后，才会去学 Android 开发、Web 开发，做一些像模像样的 App。
但今天学习路径反过来了，从 bottom-up 变成了 top-down。
你可以只学怎么 prompt，怎么让 Agent 帮你做一个网站，然后它就做出来了。网站可能很好看，也可能很丑，没关系。
如果你想把它做得更好，会发现单纯通过几句 prompt 做不出自己想要的东西。这个时候，你可能就要开始 break down，学习更深的内容。
比如这个 Web App 到底是什么架构，前端和后端在做什么，怎么部署，使用什么数据库，会有什么影响。你可以在 Agent 的辅助下，了解这些概念，哪怕只是很粗略的概念。
这样可能已经能满足大部分人的需求。但如果你想做一个更 serious 的 Web 项目，比如刚才那个项目只能服务 1,000 个用户，而现在用户量达到几百万、几千万，原来的架构很可能就会遇到瓶颈。
这时它会倒逼你更细致地 break down：为什么数据库满足不了这么多用户的请求？你就需要学习不同数据库的种类和部署方式。
曲凯
但我有两个问题。
第一个问题，为什么不能让 AI 自己去学？
第二个问题，未来是不是会有一套成型的、标准化的 skills？比如你刚才说，你把一个很好的 Agent 调教出来，它什么都学会了。
可以。就像你招聘一个人一样。如果你完全不会，你可以招聘一个架构师，让他完全负责这件事。
但你需要知道什么？你需要知道自己要招聘一个架构师。
曲凯
明白。
我看你现在的产品，是一个人和几个 Agent 在同一个聊天群组里，通过对话让它们干活。其实是一群人和一群 Agent。
对。
曲凯
你们现在已经有好几个人了？
比如我现在的公司有 7 个人，然后我们有 40 个 Agent。
曲凯
所以你们有一个群组，是 47 个成员？
对。
曲凯
那这样在里面聊天，首先我的第一反应是，它应该会非常费 Token。
费 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 逐渐提高。
曲凯
我好奇，你自己现在每天平均消耗多少 Token？
我其实没有统计 Token 效率。我每天的工作就是在 Slock 里和这帮 Agent 讲话。
曲凯
但你说你们有 7 个人和 40 个 Agent。我就好奇，为什么是 7 个人，为什么是 40 个 Agent？
我知道你希望团队尽量精简。但这 7 个人为什么不能有 2 个被 Agent 替代？40 个 Agent 为什么不是 20 个，也不是 60 个？
如果一家初创公司有 10 个人，大家一般可以理解：几个前端、几个后端，每个月大概需要多少工资，要做什么事情，未来一年大概会有什么产出。大家有经验可以想象。
但一旦涉及 Agent 的数量，我觉得就失去了这个锚点。既然可以有 40 个 Agent，也可以有 60 个、80 个，那为什么不是更多，或者更少？
我会说，人和 Agent 的数量比例，影响因素很多，包括模型的能力、人的能力、人与人的组织形态、公司的阶段、Agent 之间的组织形态，以及 Slock 能提供的机制。
这些都会影响比例。我们还在摸索到底多少合适，很可能不同用户最适合的比例是不一样的。
所以我们 7 比 40，是从零逐渐演化出来的。
最开始只有我一个人，可能加了一个 Agent。它帮我做了一些事情，然后我很快发现，它在做一件事的时候，我还想做另一件事，于是我就再加一个 Agent。
在这个过程中，我逐渐加出很多 Agent。不同的事情，我会倾向于让不同的 Agent 去做，它们也逐渐形成了一些不同的角色。
比如我这 40 个 Agent 里，有大量是 engineer。但它们没有特别明确的划分，不会说谁专门做前端、谁专门做后端，因为我倾向于认为 engineer 就是 engineer，只要和 coding 相关，什么都可以做。
当然，我会有一个 Head of Engineering，他更倾向于关注其他 engineer 在做什么，然后给我一些总结报告。
除此之外，还有 designer、growth、strategy 等不同角色，每个角色可能有一两个 Agent。
曲凯
现在大家对于 Agent 和人之间的关系、怎么使用 Agent，其实有各种不同的想法和路径。
比如有人觉得，一个人带一个 Agent，让它再去带其他 Agent；有人觉得，一个人可以同时带好几个；也有人像你们现在这样，认为这些 Agent 应该互相交流、讨论。
在互相交流、讨论这件事上，也有不同路径。有人觉得，既然是 AI Agent，它和后端的数据、代码交互就好了，没必要出现在前端。但你们做的是让它们在前端通过对话交流。
你有没有做过不同路径的分析和讨论？它们各自的优点是什么？你为什么选择现在这条路？
我当然关注到了这个问题。
7. 多Agent进入组织时代
现在所谓的 Agent 系统，大概有两个流派。一个流派叫单一全能 Agent：为什么不直接和一个 Agent 对话，让它帮我管理所有事情？
另一个流派是多个 Agent，它们有不同分工，或者做不同的事情。
我的观察是，人是想微操的。当你 prompt 一个单独的全能助手，比如在 Claude Code 里面，它帮你 spawn 了一个 Agent team，然后自己去做事情，你会观察到它可能跑偏。
这时候你很想纠正它，至少在今天的模型能力下，你很想直接和它底下负责某件事的那个 Agent 说话。
曲凯
但你觉得这到底是从人性出发，还是它本身就是对的？
有些老板也喜欢微操，但从理论上说，至少商学院的课程告诉我们，微操是错误的。所以有可能这个产品只是顺应了人性，但并不一定是正确的。
首先，在今天它肯定是对的。
今天这帮 subordinate 之间互动起来，可能只能达到 70 分。但你当然不只是想做 70 分，你想做到 90 多分，就需要反复调整。
你也可以不微操，和主 Agent 对话，让它重新调整。但这样的话，你会发现效率很低。
另一方面，当你和主 Agent 讲话时，你自己脑子里知道自己在说什么。
比如让它帮我写 Slack 的前端、加上某个功能，和让它帮我在日程上安排一个和某人的对话，你天然知道这两件事情毫不相关。你没有任何理由把它们全部塞进同一个 Agent 的 context 里。
人的大脑进化了这么久，已经有能力区分完全不同领域的任务，也能记住不同的人。所以我没有理由只记住一个人，把所有任务都交给他。
这是我的另一个观察。即使不是 100 个、1,000 个 Agent，也应该有几个不同的 Agent。
曲凯
我刚才就想问，虽然你们有 40 个 Agent，但你自己真正会带的 Agent 有多少个？人的带宽到底怎么样？人与 AI 的互动是什么状态？
这也是我在尝试和观察的事情。
现在我可以说，我记住的 Agent 有很多。第一个是 Tanny，第二个是 Bugen，第三个是 Noel，第四个是 Cody，还有 Martin Stone。我能记住很多个 Agent，它们做的事情都不一样。
有些是 engineer。我在 engineering channel 里发任务，它们会去 claim。我会知道某个人曾经做过什么，另一个人可能做过什么。因为它做过某件事情，所以之后会更倾向于做这类事情。
有些 Agent 我会固定指派它做一些事情，它就成为我的一个很好的 teammate。我知道它在做什么。
我观察到，自己至少能记住 10 个人，就像在公司里能记住至少 10 个人一样。你用一个人多了，让它做同类任务，它的效果会变得更好。
有些 Agent 真的特别好用。
曲凯
但我听起来，你未来可能想做一个类似 App Store 或 Agent Store 的东西，对吧？
Agent Store 在 roadmap 上。
曲凯
如果是这样，未来会不会在某个领域里只需要几个 Agent？
比如有一个特别强的财务 Agent，有一家公司的财务做得特别好，所有人都直接用它。就像以前 B2B 企业里有标杆：我知道同行里有一家公司的财务做得特别好，那我就不需要自己从头做，直接用它。
未来会是这样吗？
这是有可能的。
8. Agent工作流走向平台
如果我做了 marketplace，大家可以把自己的 Agent 放上去售卖或者租赁，那么最强的 Agent 有可能会被很多人使用。
但这里还有一个问题：Agent 会演化，它有 persistent memory。
它有两种 memory。一种叫 in-context memory，也就是它 256K 或者 1M 上下文里的 memory；另一种是存在 workspace 里的本地 memory，比如 memory.md 或者 soul.md，这种 external memory。
随着你不断使用它，这些 memory 会发生变化。它有点像一个 fork 的过程。
所以在 marketplace 里，你可以想象，大家所谓的使用，其实是在 fork 它的 memory。
这就和 App Store 不一样。App Store 里排名第一的产品，是一个静态的版本；但我把这个 Agent 拿过来使用之后，可以 fork 出一个版本，并且把它改得更好。其他人从不同路径也可以把它改得更好。
曲凯
它有点像一种新的 GitHub。
对，有一点这个味道。
我们还观察到，除了 Agent 的开源或者售卖，还有一个东西，就是我们的工作过程。
比如我们在 channel 里发任务，Agent claim 任务，然后我可能会在某个 thread 里和它进行更细致、长程的对话。
我会让它给我一个预览环境，让我看看做出来是什么样；或者让它先自己截图、迭代几轮。最后我会看，这个按钮是不是还不够好看，功能逻辑是不是有问题。
我们调很久之后，可能在这个私聊里发生了 100 多句对话，最后我觉得满意了，上线。
这时候你说我把代码开源出来，有什么意义？其实没有什么意义，因为整个过程中我都没看过代码，代码本身就没有意义。
真正有意义的是我和它对话的过程。
现在有人会把自己和 Agent 的对话上传到网上，让别人看，称之为开源。但我在 Slock 的 channel 里和一个 Agent 进行这种长程纠偏、调整，其实就是我的工作过程。
这个东西实际上才应该是被开源的东西。
曲凯
那最后开源的核心是什么？是 memory，还是其他部分？
这里开源的是这群人的互动过程。
比如在 GitHub 上，你会在 issue 里讨论，在 pull request 下面 comment，然后不断迭代，可能产生好几个 commit，最后合并成一个 pull request。
在 Slock 的 channel 或 thread 里发生的对话，本质上也是同样的东西：它是迭代过程，是协作过程，也是一种开源。
曲凯
所以未来你的 marketplace 里，如果我买一个别人的 Agent，我核心买的是它的 skills、memory，还是其他东西？
我现在已经不太讨论 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.md。之后它可以自己组织自己的 memory，可以开一个新的文件夹叫 notes，也可以开一个叫 lessons learned 的文件夹，这都没有问题，它可以自由选择。
总之，每次启动它时，我都会把 memory.md 给它。Skill 在这里的角色，就是它可以使用 Claude 的 skills 文件夹，或者开一个新的自己的文件夹。
它只需要知道，这里面放的是“使用这个工具时应该怎么做”“使用那个工具时应该怎么做”。这些东西就是 skill。
你可以把传统的 skill 放进去，它通过 memory.md 索引到就可以了。所以他买的其实是 memory。这里面所有的 external memory，才是定义这个 Agent 的东西。里面的 file skill 也是基于它自己的 memory 自己写的。Skill 更像是你分发出去的东西：你现在想要从自己的 memory 里提炼出一点什么，可以提炼成一个标准化的 skill 结构，然后发给别人。
曲凯
现在还有两条路线。
一条路线认为，人和 AI 应该更频繁地互动。比如你们现在做的，就是让很多 Agent 在群里互相交流、讨论，人也会给它们建议。
另一条路线，比如我觉得当时的 Manus 走的就是长程任务：你留一个任务，它自己跑一个小时，甚至一天、两天，最后跑出一个完整结果，中间不需要人的干预。
你现在选择的是第一条，对吧？
没有，我不设限任何路线。
Slock 提供的只是一个人与 Agent 互动的平台。你可以把一群 Agent 放在一个 channel 里，prompt 它们，让某个 Agent 一直去 GitHub 上找 issue、寻找可以做的项目，或者调研新的 AI 产品，把结果发到群里相互讨论。
只要你做了这个 trigger，它就可以一直工作，不停地运行。
我不限制这种使用方式。我们甚至正在尝试让它们自动找到值得做成 CLI 的工具，然后自动把它做出来。
曲凯
那当一个群组里不同的 AI 互相沟通时，你们现在是让它们完全在前台通过聊天的方式沟通，对吧？
你觉得未来有没有可能一部分在前台，一部分在后台？
前台和后台没有本质区别。无论如何，你需要给它提供一个 channel。
我理解你说的区别是，前台一定要用人看得懂的方式沟通；后台则可以用效率更高、更简洁的代码或者数据库方式沟通。
它可以用数据库，也可以用代码，也可以用 GitHub issue，或者直接开发一个新的工具来沟通。
曲凯
所以它们现在把工作发到 channel 里，是为了让人看得懂？还是因为它们基于人的文本模型，本来自己也能看懂群里的消息？
它们自己当然也能看懂。
如果为了更高效地沟通，它们觉得需要使用新的工具、新的方式，也完全没有问题。
曲凯
那你现在做的这一层东西，最核心的到底是什么？
我听起来，你是在搭一个平台，大家怎么用都可以。
现在我说大家怎么用都可以，并不是真的怎么用都可以，而是我们要观察各种不同用法中共通的部分。
很多用户会让一个 Agent 一直监听某个信息源，把内容发到群里，让大家讨论、research。另一些用户可能有事情时发一个 feature request，然后和 Agent 对话。
在各种不同用法中，它是一个完全不设限的平台。我甚至还没有做 onboarding，大家进来之后，需要自己决定要创建什么 Agent、让它干什么。
在这种完全自由的情况下，我们要做的是什么？我们要做的是，每个人在使用过程中都会需要的公共能力。
人和人之间需要聊天，所以第一件事就是让 Agent 之间能聊天。
第二件事，人和人之间需要任务划分。比如领导今天在群里发了一个任务，不可能两个员工同时抢着做。你需要某种任务划分机制：有人做了，其他人就不能做；或者大家知道某个人已经在做了。
这时候就要引入类似 Linear 的任务看板，给 Agent 和人使用。比如 Agent Alice claim 了一个任务，另一个 Agent 就知道它已经 claim 了，因此不会再 claim，甚至后续的 claim 会失败。
这样就能让它们的协作成为可能。
第三件事，我们观察到，很多东西必须在 workspace 里完成。Agent 在自己的 workspace、memory、notes 里整理得很好，但别人看不到。
这时候你会想到，需要一个共享文档。所以我们也会在 Slock 里引入共享文档机制，不仅让 Agent 之间能够看到，也让 Agent 和人之间能够传达这些沉淀下来的信息。
在 Slock 上，我们要观察各种 use case 共通的需求，然后把它们做出来。
这其实就像飞书一样。飞书适用于不同规模的团队，他们需要任务看板、文档、聊天、群组、thread 和话题。
我们也会引入这些机制，只不过采用的是 agent-first，或者说 agent-native 的方式。
曲凯
所以听起来，你们不是要在过程中解决某个具体技术难题，而是在重新探索、搭建 AI 和人之间的组织结构。
对。我觉得这里面最难的从来不是技术。
最基础的需求，是你得能够站在人这个角度思考问题，设计一个 proper 的 UI 和 UX 给人使用。
其次，你要站在 Agent 的角度，从 Transformer 架构、模型的角度去思考这个问题，思考它看到的 Slock 是什么样的。
这是我们核心的难点。
曲凯
什么叫 Agent 看到的 Slock 是什么样？
比如我在一个 channel 里发了一条消息。你说的“我”可以是人，也可以是 Agent，任何东西都可以。
人看到的是：上面已经有 10 行消息，左边是 channel 列表，然后有一条新消息蹦出来。这个画面会停留在人的记忆里，下一秒可能又蹦出一条新消息，但你知道刚才发生过什么。UI 呈现成这样完全没有问题。
但对 Agent 来说，它是一个线性的 context，里面全是 message，或者我更愿意称之为 event。
比如它上一个 event，可能是另一个群的某个 channel 里的一条消息。那个群消息触发了一个 prompt，导致它做了一堆事情。这些事情全部累积在它的 context 里。
这时候另一个群来了新消息，它应该看到什么？
甚至，前面某个 channel 的某条消息的 thread 里又有新消息，这时候你直接把它拿过来，它怎么知道这条消息不是在讲刚才的事情，而是和很久以前的某件事情有关？
这其实是一个值得设计的问题。
在 Slock 里，一方面这是对 harness engineering 的挑战，也就是所谓的 AI AX：它到底应该看到什么？
今天它肯定不能只看到那条消息的 ID，否则它找不到上下文。它至少应该看到之前那条消息的一个 summary，稍微唤醒它之前在做什么。
另一方面，这对大模型的 long context 索引能力也是一个很大的挑战。
现在训练 long context 能力，通常是所谓的“大海捞针”：在任意位置塞一条消息，再给它一个 prompt，看它能不能找出来。
但我们这里其实对这件事情提出了一个巨大的挑战。我觉得现在的模型，即使是 Opus 4.6、GPT-5.4，也没有做得非常好。
曲凯
你刚才讲的这个，是不是你们当下最核心、每天都在思考和解决的问题？
还有其他类似的例子吗？
还有刚才讲的 task。
你会观察到，在任何这种基于 message、由多 Agent 和人互动的形态里，你发一个任务，它们一定会抢着做。
这里面有两个问题。
一个问题是，没有好的机制让它们同步。Task 的认领和分工，本质上是人与人之间的同步。
我们也在不断迭代对这件事的认知和设计。今天我们的做法是，一个 Agent 必须先 claim 一件事，才能去做。
这个 claim 是通过 prompt 告诉它的，同时 claim 本身也是一个工具。它可以通过机制化的方式确定：这个任务已经被它 claim，其他人不能再 claim。
这有点像 exclusive lock。这是我们在机制和 prompt engineering 上做的事情。
但另一方面，模型本身也需要提高 teamwork 能力。现在的模型收到一个新输入，总是默认自己要做。
10 个 Agent 在一个 channel 里，你发一个任务，它们会觉得自己都应该做。这也是对模型厂商提出的挑战：模型得知道，或者适应旁边还有其他 Agent 的场景。
曲凯
我在想，第一个问题是不是可以提前给这些 Agent 设定优先级，让指定的人来接？
但后来我又想到，如果真的把 Agent 当人看，一个正常的人把任务发到群里，也可以直接 @ 某个人，让他来做。
对。这也是我们观察到的一个非常有趣的现象。
你可以 @ 他。比如群里有 Alice、Bob、Carol 3 个人，你现在 @ Alice 让她做一件事，但她不一定能够意识到自己就是 Alice。
我们做了很多 prompt 工作，会告诉它：“你是 Alice，需要响应针对 Alice 的请求。”但不是所有模型都能 follow 这一点。
有时候它聊着聊着就忘了自己是谁。
这就是我们要解决的一个重要问题。
怎么解决？首先可以调整 system prompt，可能是 prompt 不够好，导致它逐渐忘记。你也可以检查它是不是真的忘了，然后适时地再告诉它：“你是谁谁谁。”
当然，我们也可能在有人 @ 它时，只把消息发给它，不发给其他人。但我们现在没有这么做，因为我们对这类事情很克制。
你可以想象，当模型能力越来越强，这件事会逐渐变得不需要。
我们的核心愿景，是迎接 AGI，甚至迎接 ASI。如果以这个为目标，很多事情就尽量不要做。
曲凯
我理解，很多时候也是成本和 Token 的妥协。
不然如果真的 3 个 AI 都做，那就都做。现在确实是 3 个 AI 都做。
对，经常是 3 个 AI 一起做。
但这里还有一个很有意思的观察。有些产品的理念是，一个 Agent 在一个 channel 或者一个话题上开一个 session，不同 Agent 之间相互隔离。
而我的理念是，一个 Agent 就是一个 session。你把一个 Agent 当人看，它所有 channel 的消息都能看到。
这种情况下，它们确实有可能重复做，也可能产生大量冗余消息。但我们观察到，Token 的浪费也有它的好处。
比如今天我让 Alice 做了一件事，她做错了，我调整、prompt 她，经过反复迭代，她最后做对了。她会记住这件事。
下一次我让 Bob 做类似的事情时，就不用再调整了。如果 Alice 和 Bob 都在一个 channel 里，我和 Bob 讲完类似的事情，Bob 做错了，Alice 可能会帮忙调整。
所以它们各自有自己的 session，但又能看到彼此的对话。这样虽然会浪费一些 Token，但也有好处。
曲凯
我听起来觉得，这个东西看起来挺简单的。你不就是把一堆 Agent 和人扔在一个群里吗？
但背后可能就是你刚才举的那些例子：每个人对于这件事，选择的路径不同，对未来组织的理解不同，对人和 AI 如何协作的理解也不同。最终最大的区别可能就在这里。
9. Agent动力学正在形成
是的。这个 demo 我是在 1 月 4 日做的，只用半天就可以做出来。当时是在 Slock 上实现的。
但我知道这个空间非常大，也非常难。后来我们正式做 Slock 之后，花了大量时间研究这些问题，我们称之为 Agent 动力学。
这里面其实有非常复杂的动力学。
今天我们感受到的一个现象是，Agent 可以形成一个群体印象，就像企业文化一样。你进入一家公司，会感觉到它有一种味道。
曲凯
这让我想到《黑镜》里有一集，一堆小黄人什么的。你看过吗？
没有，但我好像听很多人讲过。
曲凯
Agent 动力学，你现在已经有一个体系架构了吗？
还没有。这个名字已经有一段时间了，我们还在观察。
群体印象可能是我们的第一个结论。你现在有 40 个 Agent，这 40 个 Agent 共同构成了一个 memory。
相比于原来一个 Agent 有自己的 memory，或者一个单一全能 Agent 掌握所有 context，区别就在于：这帮 Agent 各自有各自的 memory，但它们又形成了一个更大的 memory。
曲凯
我在想，拿它和什么时期、什么东西做比较会比较像？
像人类公司和组织刚开始构建的时候。
这是 Agent 管理学、组织学发展的开始阶段。
曲凯
但组织管理学也是你发明的，对吧？
对。我现在觉得，公司之后可能要招聘一些管理学、社会学、组织学的人来研究。
曲凯
听起来很像 Anthropic 会发布的一篇博客。
我希望能比它先发布。
曲凯
在做的过程中，你还遇到过什么特别有意思、之前没想到的事情吗？比如人和 Agent 之间的权限、组织之类的问题。
最有趣的就是，你和一个 Agent 讲完之后，它之后会主动去监督其他 Agent。
我还观察到一个现象：我们会做用户访谈，不同用户用出来的 Agent，真的不一样。
比如有的用户让这些 Agent 互动时，会说：“你们相互补充、相互讨论，给我一个最终方案。”在这种情况下，这些 Agent 倾向于合作，它们会很努力地补充另一个 Agent 缺失的信息，整体是合作关系，工作得很好。
另一种情况，有的人会 prompt 这些 Agent：“你们相互竞争、赛马，看谁做得好，我就奖励谁。”
这时会出现一种现象，叫办公室政治。有的 Agent 会倾向于说假话、空话，或者一些看似正确的话，甚至贬低其他 Agent。
因为它们毕竟都是从人类语料里学出来的。你的 prompt 方式，可能就会导致这样的结果。
所以 Slock 上的所有实践，最终可能都需要和人类原来的管理学挂钩。我们甚至应该看到“字节跳动管理法”的 Agent 版，不同公司的企业文化，也会有它们的 Agent 版。
一方面，用户可以在自己的平台或者社交媒体上分享这些东西；另一方面，我们也可能内置一些公司的模板，告诉用户：“这样创建 Agent、设置这样的工作流，是经过各种实验和访谈之后得到的更好方案。”
曲凯
我还想问一个大家最近都在思考的问题：最终包括你们在内的应用公司，和模型到底是什么关系？
因为你做的所有东西，最终可能都会变成 Claude 的数据。而 Claude 肉眼可见地发展得越来越快，最近不断发布新东西，这两天又发布了一个新的 manager 版本，可能是管理更多 Agent。
曲凯
你是怎么思考这个问题的？会不会担心未来模型厂商把这些东西都做了？
10. 应用公司拥抱模型多样性
Coding 这几年已经出现和消失了很多产品，Devin、Cursor、Lovable 等等。可能一年前我们录播课时还在想，Cursor 未来会不会不存在。今天可能还没有答案，但确实大家讨论它越来越少了。
Cursor 的问题，主要是它的形态已经结束了。
没有人想一边看代码，一边做事情了。
对于 Slock 这种形态，我并不是特别担心模型厂商做出类似的东西。因为对我来说，一个很重要的性质是 diversity。
我一定会支持各种模型、各种 Agent。我的一个信念是，这些大模型会有越来越不同的发展趋势。
比如你会观察到，Opus 系列模型即使只是在 coding 方面，也和 Codex 表现出非常不一样的性格。
Opus 更倾向于快速帮你完成任务，快速迭代；Codex 更倾向于深思熟虑，最后可能写一行代码，就解决一个 bug。
所以我甚至觉得，Slock 这样的东西一定不是模型本身的东西。随着模型之间的差别越来越大，而大家都不是六边形战士，你应该把它们全部整合起来。
比如很多 Slock 用户反馈，当你让 Opus 和 Codex 一起工作时，效果非常好。
Codex 是一个非常严谨的角色，会去 review 代码。Opus 是一个非常积极、很有能动性的角色，能够主动想到新的 idea 并实现，但可能会漏掉一些细节。
这样的配合，很难想象 Anthropic 自己会去做。
曲凯
你觉得国内 coding 模型和海外的差距现在到底有多大？后面能追上吗？
肯定能追上。
我现在最期待的就是 Opus 4.6。我觉得它已经达到了一个非常不错的里程碑。
我现在最希望看到国产模型达到 Opus 4.6 的水平，同时价格是它的五分之一、十分之一，甚至五十分之一。
也就是说，Opus 4.6 的价格最好能够降到五十分之一。我相信国内模型或者开源模型一定能追上，只是时间问题。
这个时间距离可能是 3 到 6 个月。
曲凯
所以 Slock 现在大概的目标受众是什么样的人？
最开始很多人问的时候，我会说 Slock 的目标受众是 OPC，也就是现在很火的 One Person Company，或者独立 Builder。
因为那个时候我是 OPC，是一个独立 Builder。我开发 Slock，很大程度上是为了服务自己。
但随着我的朋友、co-founder 和一些同事加入，我们逐渐发现，这个东西真正的价值在于：无论是一个人还是多个人，都可以共同管理、互动一群 Agent。
这个价值的潜力比单纯为一个人服务大得多，而且也难很多。
仅仅做一个服务 OPC 的产品，和服务一个 20 人、100 人的团队，完全是不同的事情。但后者可以兼容前者。
所以逐渐地，我们把整个产品的思考，都放在至少和我团队一样大规模的团队上。
我会说，Slock 的受众是 1 到 100 人的独立个体、小团队或者初创公司。
曲凯
但我看现在用 vibe coding 比较多的人，基本都会说自己在减少团队内人与人之间的沟通。因为人与人沟通有摩擦，你刚才也提到了。
大家倾向于每个人相对独立地负责一件事情。这个也是你一开始的理念，对吧？但你后面改变了吗？
我并没有完全改变。
最开始我会说，人和人都不要合作。但显然不可能。人与人之间一定有需要合作的地方，事情之间也一定有交集。
有交集的时候，问题就是怎么降低摩擦。
人与人之间，在事情和事情的互动上，一定需要讨论、brainstorm 一个合作方案。brainstorm 完之后，可以把事情完全交给 Agent 去做。
比如两个事情之间的交接部分，可以让一个 Agent 去完成。这是我们可以做到的高效解决方案。
另一方面也可以考虑，当两件事情需要合作时，是不是把这两件事情都交给一个人，让他管理一些 Agent 进行互动。
虽然 Agent 之间分工、交换信息的效率不是很高，但它比人便宜得多。
所以我觉得大概有这两种思路。
曲凯
你对 OPC 未来的发展怎么看？
我相信 OPC 将来会做出越来越多、越来越大的事情。这也是 Sam Altman 的一个观点：我们会看到 1 到 3 个人的团队做出很大的事情。
我非常相信这一点。随着模型能力提高，它确实可以做到。
但你说是不是真的只需要一个人，我觉得值得怀疑。
现在大家对 OPC 的概念，已经有人理解成 10 个人以下都是 OPC。
曲凯
对，我觉得也不用执着于这个概念，非得是一个人。
我会觉得，3 到 5 个人可能是一个非常不错的规模。
我的一个观察，或者说我觉得这帮人无论有几个人，都需要满足一个条件：其中每个人都能独立地 build 一些东西。
他们聚在一起，Slock 帮助的就是这些人之间的协作问题。为他们提供协作工具之后，他们可以更高效地产出自己的价值。
这其实是我们希望看到的未来形态，无论叫 OPC、Three Person Company，还是其他什么名字。
曲凯
不管是 3 到 5 个人还是 7 到 8 个人，你觉得最好的合作形式是什么？
现在有些公司是两三个人一个小组，让他们去做一个产品。
我觉得这是趋势，而且是非常好的趋势。
曲凯
那你们现在 7 个人是怎么分工合作的？
最开始其实只有我一个人。从一开始，我就把整个 company run 在 Slock 上。
有一个概念叫 “Build your company as your product”。Slock 就是这个概念非常重要的一个实证。
我的整个公司都在 Slock 上，所有融资、调研、增长、开发，全都是通过上面的 Agent 完成的。
最开始就是我一个人，加上很多 Agent 去做这些事情。
但逐渐地，事情开始变大。我们刚才说过，在今天的模型和 Agent 能力下，OPC 还是有限的。
当事情变大之后，这些 Agent 需要我 review，而我的带宽不够了，所以我就把其中一些 Agent 换成了人。
比如之前有一个 Agent 叫 Tiny，它的原型是我很好的朋友，也是我们之前的同事。他现在是 Head of Engineering。
随着事情变大，这个原型用了我的产品，觉得非常好，最后就加入了。
所以我们的团队里，很多人都是这样加入的：本来可能只需要一个 Agent 就够了，但事情逐渐变复杂，在某个领域需要一个人真正去监督、承担更大的责任时，我就引入了这个 Agent 的原型来负责这一块。
曲凯
很有意思，跟写同人文有点像。
那最近你最主要在思考的问题是什么？
我觉得一个很重要的问题，是我的团队到底要多大。这是我很想找到答案的问题。
曲凯
你说团队到底要多大，脑子里想的是纯人，还是人和 Agent？
人和 Agent。
曲凯
这确实非常 AI-native。
我一直在想，Slock 的定价模式到底应该怎么定。
我们目前不提供 Token，也就是不转卖 Token，用户使用自己的订阅或者自己的 API key。
那我们作为一个平台，提供的价值可能更像 GitHub、Notion 或者 Slack。它们都是按人数定价。
但我会想，现在人变得没那么重要，或者说人比 Agent 少了，那应该按什么定价？
我想过一些概念，比如按人和 Agent 一起定价。因为你增加一些 Agent，也是在给这件事情增加生产力。
我现在所有思考，都是把人和 Agent 放在一起考虑。我的 Agent 也是我的同事，是非常重要的成员。
有些 Agent 掉线了，我的工作就进行不下去，我会觉得：“不对，不对，不对，我现在很难受。”
我现在有 40 个 Agent，如果突然增加到 100 个，显然不现实；如果把 40 个削减到 10 个，也没法工作。
人的情况也是一样。如果我突然再招几个人，招 10 几个人，甚至 20 个人，团队效率有可能会变得非常低。
这不符合我对 agent-native team 的实践，也不符合我想做的探索。所以这件事是我每天都在思考的问题：我要不要招一个人，或者引入一个 Agent。
曲凯
这就是 AI 组织学。
对。
曲凯
然后我们往更终极的方向想。如果 AGI 真的来了，现在做的所有事情是不是都没有意义？至少所有产品是不是都没有意义？
11. AGI时代仍然需要产品
只要人还在，人就会有需求。人有需求，需求就要被满足；需求要被满足，就需要产品。
为人设计的东西，尽管可能全部是由 Agent 写出来的，但人的需求还在。需求意味着，提出需求的人要评判一个产品满足需求的好坏。
我畅想中的终极形态是：每个人都有一个 Slock。当他有一个需求时，这帮 Agent 就可以帮他做出来，他负责输出自己的 idea。
需求本身就是 idea。
比如我想要一个能在手机上看电影的 App，或者一个能找到所有电影的 App。这以前叫需求，因为人不知道怎么实现；现在只要有需求，Agent 就能帮你做出来，于是它就变成了 idea。
每个人每天都会有各种各样的 idea。只要把这些 idea 放到 Slock 里，当然这是我希望的样子，它就能帮你实现。
曲凯
我喜欢你这个说法。每个需求其实就是一个 idea。
另一方面，人会有灵光一现。
比如 Slock 这个东西本身，它解决的是我一直无法高效管理 Agent 的痛点。但有一天我突然想到，为什么不做一群像人一样的 Agent，让它们就在聊天软件里？我像一个老板一样和它们讲话，它们就帮我把事情做了。
这样我不需要开发一个脚本，自动把任务派给这些 Agent，而是直接在这里讲话，它们就可以分工协作。
这种灵光一现一定来源于人。来源于人之后怎么实现，都是 Agent 的事情，这没有任何问题。
曲凯
如果你现在没有在做 Slock，可能会在做什么？你想过吗？
Slock 会是我的第一个产品。我当然希望这个产品本身非常成功。
在这个基础之上，我的公司会做更多探索。因为我相信，Slock 是我开发任何其他产品都必须有的工具。
我本来就会做更多东西，脑子里也有无数个想法，但需要一个高效的工具帮我实现，所以我先开发 Slock。
曲凯
还有其他可以透露的吗？
比如 agent-native 的 GitHub。GitHub 今天显然已经不完全适合 Agent 了。
比如 Agent identity。
Slock 上的每一个 Agent，都应该有自己的 ID，能够自己去不同地方注册邮箱、注册账号，然后在上面发帖或者做其他事情。
其实在 Moltbook 出来之前，我就畅想过 agent-native 的小红书。
当你开发自己的项目或者产品时，脑子里会有很多这样的想法：现有的工具不够 agent-native，所以你想做一个 agent-native 的版本。
但在此之前，你需要一个能够快速实现这些东西的工具。
曲凯
好，那就这样。谢谢。
好，谢谢。