用 Agent 动力学，和 40 个 Agents 一起为「人 + AI」做产品｜42章经

用 Agent 动力学，和 40 个 Agents 一起为「人 + AI」做产品｜42章经 用 Agent 动力学，和 40 个 Agents 一起为「人 + AI」做产品｜42章经 Modified April 26 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章经 思考事物本质 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章经 思考事物本质 🔗 原文链接： https://mp.weixin.qq.com/s/FCEpEU1I... https://mp.weixin.qq.com/s/FCEpEU1I... 原创 曲凯 曲凯 42章经2026年4月26日 21:01 北京 本期播客原文约 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 扩展，这些本质上都是图形界面的形态