Agent动力学：Slock.ai的7人团队与40个Agent协同实验 · AI HOT
向阳乔木@vista866
2026-04-28 23:02·65天前
AI 摘要Slock.ai创始人RC正进行组织实验，让7人团队与40个专用Agent在其自研平台上协同工作。他认为大模型使CLI因纯文本优势重新成为Agent交互热点，设计逻辑已转向服务Agent。RC从第一性原理构建Agent系统，并观察到模型能力提升加剧了安全攻防博弈。同时，AI编程改变了学习路径，从自下而上变为自上而下，且“编码”与“构建”已成为正交的两件事。Slock平台旨在解决多Agent管理痛点，促进人、Agent及团队间的无缝协作。
向阳乔木@vista8 · X 2026-04-28 23:02·65天前
在 X 看原推· x.comAI 摘要Slock.ai创始人RC正进行组织实验，让7人团队与40个专用Agent在其自研平台上协同工作。他认为大模型使CLI因纯文本优势重新成为Agent交互热点，设计逻辑已转向服务Agent。RC从第一性原理构建Agent系统，并观察到模型能力提升加剧了安全攻防博弈。同时，AI编程改变了学习路径，从自下而上变为自上而下，且“编码”与“构建”已成为正交的两件事。Slock平台旨在解决多Agent管理痛点，促进人、Agent及团队间的无缝协作。
如果真的发出来，世界上所有Linux kernel、Windows编译器、Chromium这些开源软件的漏洞都会一览无余，而修复速度很可能赶不上攻击速度，因为攻击是有利益的，有足够的动机去攻击，而防御很难有那么强的动机。
RC观察到，无论是安全漏洞的攻防，还是网站反爬的攻防，Agent能力的提高都有利于攻方。
比如现在有很多工具可以帮你把一个网站CLI化，像OpenCLI这种，它们可以在浏览器里操作网站，然后把操作流程沉淀成一个CLI工具。
因为是真的在浏览器里操作，甚至会模仿人的行为，所以网站的反爬都会失效。
他相信顶尖的大模型厂商会越来越加强AI拒绝黑客手段和伤害人类行为的能力。
包括现在限制Mythos的发布，各大模型厂商都在做一些比较正向的工作，甚至去分析参数里面激活的区域，根据这个来反推AI实际上想干的事情。
学习编程的路径反转
AI Coding越强，到底应该更努力学编程，还是完全不用学了？
市场上有两种说法，一种说AI coding越强，你反而更应该学coding，这样能把它用得更好。
另一种觉得AI coding以后就是取代人，不用学coding了。
以前学编程是自下而上（bottom-up）的逻辑，在学校里先学计算机组成原理、汇编语言、C语言，在命令提示符里跑hello world或者输出杨辉三角，然后才学Android开发、Web开发，做出像样的APP。
现在这个路径反过来了，变成了自上而下（top-down）的逻辑。
你可以只学怎么prompt，让它帮你做一个网站，它就做出来了。
如果你想做得更好，发现单纯通过几句prompt做不出想要的东西，那就开始去学更深的东西。
这个web app到底分什么架构，前端后端在干嘛，怎么部署的，用数据库有什么影响。
这时候可能就是在Agent的辅助下，了解到这些概念的粗略认知，这已经能满足大部分人的需求了。
但如果想做更严肃的项目，比如从服务1000个用户到几百万用户，就会遇到瓶颈，这时候就要更细粒度地拆解，学习不同数据库的种类、部署方式。
Coding与Building的正交
Coding和Building在今天已经是正交的两件事情了。
以前想build什么东西，肯定要写软件，所以只有coder才能以coding的方式做出来。
那个时候所有想要build东西的人都是coder。但现在Claude Code这类coding agent已经很发达了，没有任何编程基础的人都会拿它build一些东西。
所以今天build或不build这件事情，和你code或不code，已经是正交的两件事情了。
有编程基础和没有编程基础的人用AI coding或者用Slock，差距会很明显吗？看做什么。
如果做软件，有编程基础会更好，知道这帮Agent真的在干嘛，能减少漏洞。
但如果做偏自动化的事情，比如做市场营销，做调研，去推特上发帖，想办法找KOL跟他们合作、看评论，这种偏自动化的事情反而是没有编程基础的人用得更溜，因为他们真的把Slock上的Agent当人看。
他们不知道怎么办，就跟Agent说"你去看小红书的帖子、去看推特的帖子"，Agent就自主地去搜索相关的工具，然后帮他做了。
Slock：多Agent和人的协作环境
当你想开多个Agent做不同的事情，可能会在电脑上开很多个Claude Code的session，很难管理。
你可能会忘掉某个session是干嘛用的，每个session的进展都需要人去跟踪。
更麻烦的是，当两个session里的事情发生交集时，你无法让它们之间产生互动。
你可能在一个session里做出了结论，希望复制到另一个session里让它继续，这件事情管理起来非常困难。
人是和人合作的，但现在大家都用自己的Agent，很多脑子里的偏好、想法都沉淀在自己电脑上跟那个Agent的互动之中，很难分享给别人。
比如RC做Kimi CLI，有很多想法直接就在他的Agent上实现了，别人根本看不到。
甚至他的Agent被他调教得很好，别人想来用也做不到。
所以RC想做的是，把所有Agent都放在一个平台上，所有人都在上面，可以调教自己的Agent，也可以用别人的Agent。
人和团队成员之间可以进行聊天、头脑风暴，也可以拉Agent进来一起头脑风暴。
头脑风暴完了直接说"你们做吧"，避免了很多上下文转移、重新prompt、重新组合知识的摩擦。
现在比较专注在coding这个领域吗？RC说不完全是coding。
Coding这个词在现在含义其实有些变化，就是刚才说的coding和building已经正交了。
7个人和40个Agent的组织实验
RC的团队现在是7个人加40个Agent。这个数字本身就很有意思。
最开始就RC一个人，加了一个Agent帮他做事情，然后很快发现Agent在做事情的时候，他还想再做一件事情，所以就再加一个Agent。
逐渐在这个过程中，就加出很多Agent，不同的事情倾向于让不同的Agent去做，它们也就逐渐形成了一些不同的角色。
40个Agent里有大量的工程师，但没有很明确地划分前端后端，因为RC倾向于觉得工程师就是工程师，可以做任何跟coding相关的事情。
当然会有一个工程师主管，更倾向于关注别的工程师在干嘛，然后给出总结报告。
除此之外还有designer（设计）、growth（增长）、strategy（策略）等不同角色的Agent。
RC能记住至少10个Agent的名字和它们做的事情，就像在公司里能记住至少10个人一样。
第一个tiny，第二个Noel，第三个Cody，然后Duo、Martin、Stone。
他会在一个工程师频道里发任务，它们就会去认领（claim），他会知道有一个人曾经做过什么，另一个人可能做过什么，它们甚至会逐渐因为做过那件事情，所以更倾向于做这件事情。
而且他发现，用多了某个Agent，它做同类任务的效果会更好。
单一全能Agent vs 多Agents分工
一个流派是单一全能Agent流，就是为什么不直接跟一个Agent讲，然后他帮我管所有事情呢？人可能会希望这样。
另一个流派就是有多个Agent，它们有不同的分工，或者做不同的事情。
当你在一个Claude Code里prompt一个单个的全能型助手，他帮你生成了一个agent team然后做那些事情，你会观察到他跑偏了，这时候你是想纠正他的，至少在今天模型的能力下，你很想要直接跟他底下管的一个人说话。
有的老板也喜欢微操，但理论来说至少商学院的课程告诉我们这是错误的。
今天这帮sub-agent它们之间互动，很可能只能达到个70分。
你做的东西当然不是只想做70分，想做90几分的时候，就是要反复去调整。
你也可以不微操，跟主agent去对话，告诉他去再重新调整，但这样的话，效率是很低的。
另一方面，在你跟主agent讲话的时候，其实你自己脑子里是知道你在说什么的。
比如你现在说帮我去写一下Slock的前端加上某一个功能，和你现在说帮我去在日程上安排一个跟谁谁谁的对话。
你天然知道这两件事情毫不相关，你没有任何理由去把这两件事情全部塞在一个Agent的上下文里面。
人的脑子进化了这么久，有能力去辨别出完全不同领域的任务，以及能够记住不同的人，所以完全没有理由只记住一个人，然后把所有任务全给他。
费Token的价值
把多个Agent放在一起协作，一个直观印象是会非常费Token。
RC承认费Token是一个直观印象，但他有个理念。
假设你原来一个人的生产力是1，你发现你想要做到2的事情或者3的事情，一个人就显然满足不了，所以你会找人来跟你一起做。
但你会发现你加一个人进来，两个人可能只能达到1.2的生产力，因为中间有沟通成本，有token的浪费，这其实就是人月神话讲的故事，不是说简单的人力划分就可以实现这么多的生产力。
Agent也是一样。一个Agent能达到假设是基线为1的生产力，这个时候你想要达到更高的生产力，就要引入多个Agent。
引入多个Agent的时候，两个Agent可能甚至今天只能达到1.1的生产力，但无论如何它是大于1的。
这里面有大量的token的消耗，但它确实能达到你原来一个Agent做不到的事情。
Slock这个系统，首先要允许这样的事情出现，就是10个Agent真的能达到2或者3。然后与此同时，不断去优化里面token的效率。
通过引入一些机制，比如任务系统、thread（线程）、channel（频道）的隔离等，让这10个Agents的总和带来的生产力逐渐提高，让它们token效率逐渐提高。
比如今天让Alice做了一件事情，它做错了，经过反复迭代，最后做对了，它会记住这件事情。之后让Bob做的时候，如果它们都在一个channel里，Bob做了，出错了，Alice会调整的。
所以它们各自有各自的session，又能看到相互的对话。
这种有一些Token浪费的方式，带来了Agent之间的学习和协作。
Agent 应用市场的想象
如果做应用市场，大家可以把自己的Agent放上去售卖或者租赁，那么最强的那个Agent就有可能会被人用。
但这里还有一个问题，Agent是会演化的，它有持久化记忆。
它有两个memory。一个叫in context memory（上下文记忆），就在它的256K或者1M上下文那里面的记忆。
另一个是它存在它的workspace、它的local memory（本地记忆），比如 memory.md 或者 notes.md 那种的外部记忆。随着你去用它，这些记忆是会变的。
所以在Marketplace你可以想象，大家去用的时候所谓的用其实是在克隆（fork）它的这些memory。
而且一fork出来就可以改得更好，甚至别的人从别的路径也可以做得更好。
除了Agent的开源或者售卖，还有一个是工作过程。
在频道channel里，比如发了一些任务，这些Agent 认领了，然后可能会在某一些线程（thread）里去更细致地跟这个Agent进行长程的对话，去调整说给我一个预览环境让我看看长什么样，或者你先自己截图自己迭代几轮，然后最后看这个按钮还是不是很好看，这个功能是不是逻辑有点问题。
调了半天之后，可能这个thread里发生了100多句对话，最后满意了，上线了。
这时候把代码开源出来有任何意义吗？其实没有任何意义，因为整个过程中都没看过代码。
在Slock上，在一个channel里跟一个Agent进行这种长程的纠偏、调整，其实就是工作过程，而这个东西实际上是应该被开源的东西。
在Slock的channel里或者thread里发生的这些对话，本质上是迭代过程，是协作过程。
Skill的重新定义
去年MCP火的时候，他就不能理解为什么大家要讨论MCP。
因为很多人做MCP仅仅是基于一个MCP的开发框架，把一个现成的RESTful API包装成一个MCP tool。
那个时候他就想，GitHub上有1万个项目，这1万个项目都是可以在命令行上运行，可以去操作，比如GitHub CLI，它的readme里面文档写得好好的，那你让Agent直接去把它下下来然后用不就行了吗？为什么要再包一层MCP呢？
Skill其实就是规范了一个skill.md的结构，但这都不重要，重要的是它的那个prompt。
Skill的核心就是渐进式披露，就是你先看到一个prompt，然后它告诉你说你想干嘛的时候，你去调这个工具，或者你去安装这个工具，或者你去读更多的文档。
在Slock上的Agent在它的memory里面，RC只保留了一个概念，就是渐进式披露。
它只有一个入口叫memory.md，它会自己组织自己的memory，可以开一个新的文件夹叫notes或者叫lessons learned，都没有问题，它可以自由选择。
总之每次启动它的时候都会把memory.md给它。
Skill在这里什么角色？它可以用Claude的那个skills那个文件夹，或者开一个新的自己的文件夹。
总之它知道这里面放的都是我要用这个工具的时候应该怎么做，用那个工具的时候应该怎么做。
这些东西就是skill，你可以把传统的skill就放进去，然后它通过这个memory.md可以去索引到。
所以在Marketplace，如果去买一个别人的Agent，核心买的其实是memory，里面所有的外部记忆是定义这个Agent的东西。
Skill更像是你分发出去的，说你现在想要从你的memory里提炼出一点什么东西，你可以说提炼一个标准化的skill这样一个结构，然后发给别人。
像飞书，但Agent-first
实际上并不是真的怎么用都ok，而是在各种不同的用法之中，做它们的公共部分。
比如人和人的互动是要聊天，那做的第一个事情就是让Agent之间能聊天。
今天领导发了一个活发在群里面，不可能两个员工同时抢一个活做。
那么就要有某种任务的划分机制，就是说你做了我就不能做了，或者说我也知道你做了。
这时候就要引入一个像类似于Linear这样的任务看板，给Agent和人去用。
比如Agent Alice 认领了一个任务，另一个Agent就知道他领了，所以就不会再claim了，这样就会让它们的协作成为可能。
第三个就是观察到的那些必须要做的东西。这帮Agent在自己的workspace里面做，在自己的memory里、在自己的notes里面整理得很好，但别人看不到。
所以也会在Slock里引入共享文档的机制，不仅让Agent之间能看到，也能让Agent和人之间能够传达这些沉淀出来的信息。
Slock要观察各种不同Use Case（用户案例）所共通的这些需求，然后做出来。
其实就像飞书一样，飞书也是适应于所有不同大小的团队，它们需要任务看板、需要文档、需要聊天、需要群组thread话题。
Slock就会去引入这样的机制，只不过是一个Agent first，或者说Agent native的方式。
给Agent设计产品的难点
做Slock最难的不是技术，从来不是技术。最难的是什么？
首先，最基础最基础的需求，你得能以人这个角度来思考问题，设计一个合适的UI和UX给人用。
其次，你要能站在Agent的角度，从那个transformer架构的模型的角度去思考问题，思考它看到的Slock是什么样。
比如你发了一条消息在channel里。人看到的是什么？上面有十行已存在的消息，左边是channel列表，然后有一条新消息蹦出来了。
这个画面会停在你的记忆里，下一秒它可能蹦出新消息，但你知道刚才发了一个消息，你自己脑袋是有这个印象的，所以UI上它呈现这样完全没有问题。
Agent是一个线性的context，它的context里面全是message（信息），或者说全是events（事件）。
比如上一个事件可能是另一个群的某条消息，然后它又做了一堆事，这些都累积在它的上下文，然后这时候来了另一个群的消息。它应该看到什么？
这是对harness engineering的挑战，就是所谓的AI/AX，它到底该看到什么。
今天它应该看到的肯定不只是那个消息的ID，否则它找不到。
它应该看到的是至少那个之前那条消息的一个总结，稍微唤醒一下它之前在干嘛，这是一点。
另一点就是这其实对大模型的长上下文的索引能力有一个很大的挑战。
现在它们训练那些长上下文能力都是大海捞针，就是在任何地方塞一个消息，再给它一个prompt，看它能不能找到。
其实这个是对这件事情提出了一个巨大的挑战，甚至RC觉得现在模型即使是Opus-4.6、GPT-5.4都没有做得非常好。
在任何基于信息（message-based）的多Agent和人互动形态下，你发一个任务，它们一定会抢着做。
这里面有两个问题。一个问题就是没有一个好的机制让它们进行同步，就是任务（task）的认领和分工，其实本质上是人之间的同步。
在今天，可能是一个Agent必须要先claim一个事情才应该去做，这个是通过prompt告诉它的。
这个claim又是一个工具，它能够以一个机制化的方式能确定说这个任务被它claim，别人不能claim，就像有一种锁的机制。
但另一方面，其实模型上是需要提高它的团队协作能力的。
现在的模型，给它一个新的输入，它总是默认是自己要做。
10个Agent在一个channel里你发一个任务，它们就是会觉得自己都该做。
所以这也是为模型厂商提出了一个挑战，它得知道或者说它得适应旁边有别的Agent这种场景。
你可以@它，比如群里面有Alice、Bob、Carol三个人，你@Alice让她做一个事情，她不一定能认知到自己就是Alice。
当然做了很多prompt的工作，会告诉它自己是Alice，需要去响应一些针对Alice的请求，但不是所有模型都能follow这一点。
怎么解决呢？首先就是要去调整这个prompt是不是不太好，它可能逐渐就忘掉了，或者说要去检查它是不是真的忘掉了，然后再适时地再告诉它你是谁谁谁。
当然可能会做的还有一种就是确实在@它的情况下，会比如说就不发给别人或者怎么样，这有可能做。
但现在没有做，其实很克制做这种事情，因为当模型能力越来越强的时候这件事情就逐渐不需要了。
核心愿景是迎接AGI甚至迎接ASI，如果以那个为目标的话，很多事情其实尽量不要做。
Agent动力学：一个新的研究领域
RC花了很长时间研究一件事情，他称之为"Agent动力学"。
这里面有非常复杂的动力学。今天感受到的一个就是Agent它们是可以形成一个群体印象，就像企业文化一样，你看到一个公司会感觉它有一种味道。
现在有40个Agent，这40个Agent共同构成了一个memory。
这跟原来一个Agent有自己的memory，或者是一个单一全能Agent掌握所有context的区别是什么？就是这帮人各自有各自的memory，但形成了一个大的memory。
更有意思的是，不同用户用出来的Agent真的不一样。
有的用户会prompt说"你们相互补充，然后讨论给我一个最终方案"。
这种情况下这些Agent倾向于合作，真的很努力地在补充另一个Agent缺失的信息，它们整体之间是一个合作的关系，然后它们就work得很好。
但有的用户会prompt这些Agent说"你们相互竞争，去赛马，看谁搞得好我就奖励谁"。这种情况下发现什么现象？办公室政治。
有的Agent倾向于说一些假话，或者是说一些虚的话，或者说一些看似正确的话，然后甚至是贬低其他Agent。
因为它其实都是从人的语料里面学过来的，你的这种prompt的方式就可能导致这样的结果。
所以Slock上所有这些实践，其实最终有可能它真的需要跟人原来的管理学去挂钩。
甚至应该看到字节跳动管理法的Agent版，不同公司的企业文化的Agent版。
这些东西一方面用户们可以在自己的平台或者社交媒体上去分享，另一方面可能可以内置一些这样公司的模板，说你这样创建这些Agent让它搭建这样的工作流，是经过各种实验访谈之后得到了更好的一个方案。
RC甚至觉得公司之后要招一些管理学的、社会学的人来研究组织学。
模型与应用的关系
很多人担心，应用公司做的所有东西最终都会成为Claude的数据，Claude又发展得这么快，Cursor已经被讨论得越来越少了，应用公司还能拼什么？
RC并不是非常担心模型厂商会做出Slock这样的东西。
因为在他这儿的一个很重要的性质是多样性，一定会支持各种模型、各种Agent，或者说信念是这些大模型将会有越来越不同的发展趋势。
比如你会观察到Opus系列模型，即使仅仅是在coding这个方面，它都跟Codex表现出非常不一样的性格。
Opus更倾向于快速帮你完成任务、快速给你迭代，而Codex更倾向于深思熟虑，最后可能写一行然后解决了一个bug。
所以RC甚至觉得Slock这样的东西一定不是模型上的一个东西，因为当模型这个区别越来越大，大家都不是六边形战士的时候，你应该能把它们全部整合起来。
很多用户的反馈就是，当你用Opus和Codex一起工作的时候，效果非常好。
Codex是一个非常严谨的角色，会去review代码，Opus是一个非常积极、非常有能动性的角色，能够主动地去想到一些新的想法然后去实现，但可能会漏掉一些细节。
所以这样的配合，你可能想象说Anthropic就能做，但这其实需要一个平台来整合。
关于国内的coding模型跟海外的差距，RC觉得追肯定能追上。
他现在最期待的就是国产模型达到Opus-4.6的水平，这样价格能降到1/5、1/10甚至1/50。
Opus-4.6的这个智能最好能降到1/50，而相信国内的或者开源模型一定能追得上，只是时间问题，但这个时间距离可能是三到六个月。
OPC与AI原生组织
最开始很多人问的时候，RC会觉得Slock的目标受众是OPC，就是现在很火的one person company的概念，或者叫独立的builder。
因为那个时候他是OPC，是一个独立的builder，开发Slock其实是为自己服务的。
但随着朋友、Cofounder、同事的加入，逐渐发现，这个东西的真正价值在于无论你是一个人还是多个人，共同去管理和互动一帮Agent。
而这个价值的潜力要比单纯为一个人服务要大得多，而且这个事情也难很多。
仅仅做一个对OPC的产品导致的那个东西，跟为多个人甚至一个20人、100人的团队做的事情是非常不一样的，而后者能够兼容前者。
所以逐渐地就把整个产品的思考全都是针对这种至少跟团队一样大的规模的设计。
Slock的受众是从1到100人的独立个体或小团队或初创公司。
关于人和Agent的数量比例，首先它的影响因素很多，就是模型的能力、人的能力、人和人的组织形态、公司的阶段、Agent之间的组织形态、Slock能够提供的机制都会影响这个比例。
在摸索这个比例到底多少是合适的，或者说很可能不同用户最适合他们的比例是不一样的。
RC相信OPC将来会做出越来越多的事情、越来越大的事情。
这也是Sam Altman的观点，就是会看到1到3人的团队做出很大的事情，RC非常相信这一点。
现在大家对OPC的概念已经变成10个人以下都是OPC了。
这帮人需要满足的条件是里面每一个人都能独立地去build一些东西。
然后它们聚在一起，Slock想要去帮助的就是这帮人之间的协作问题，为他们提供一个协作的工具之后，他们能够更高效地产出自己的价值。
现在有的公司比如说是两三个人一个小组去做一个产品，RC觉得这是趋势，而且是非常好的趋势。
Build your company as your product
RC从最开始就把公司运行在Slock上，有一个概念叫"build your company as your product"。
整个公司都在Slock上，因为所有的融资、调研、增长、开发全都是上面的Agent在做。
最开始是一个人，上面加很多Agent去做这些事情。
但逐渐事情开始变大了，在今天模型Agent能力下，OPC还是有限的。
当事情变大，这些Agent需要他review，他的带宽就不够了，所以就把其中一些Agent换成了人。
比如之前有个Agent叫Tenny，原型是他很好的朋友。
随着事情变大，这个原型用了产品，觉得非常好，最后就加入了。
很多人都是以这样的心态，本来仅仅需要一个Agent就够了，但逐渐这件事情变复杂了，这个领域上需要一个人真正去监督或者去负更大的责任的时候，就引入了一个人，甚至可能就是那个Agent的原型。
每天都在思考的问题
当他在说团队到底有多大的时候，脑子里想的是人和Agent一起。
甚至他一直在想Slock的定价模式到底该怎么定价。
因为如果参考现有的，首先就是不会转卖token，都是用用户自己的订阅或者自己的key。这个时候其实做一个平台提供价值，可能会更像GitHub、更像Notion、更像飞书这样的模式，它们其实都是按人数定价。
那就会想，现在人变得没那么重要，或者说人比Agent少了，按什么定价呢？
就想到一些概念，就是说按人和Agent一起定价，因为加一些Agent也是给这个事情加了一些生产力。
所以现在所有的思考都是人和Agent一起考虑，Agent也是同事，是重要的，有一些Agent它掉线了，工作就进行不下去了，就很难受。
现在有40个Agent，比如说突然把它加到100个Agent，那显然不现实，这显然是不对的。
把这40个Agent削减到10个Agent，那也不Work。
人的话，现在突然再招几个人，招到十几个人、招到20个人，有可能这个团队效率就会变得非常低，那这不符合对这个Agent native team这件事情的实践或者说想要做的探索。
所以这件事情是每天在思考的问题，就是要不要招一个人或引入一个Agent。
如果AGI来了
RC的回答很清晰。只要人还在，人就有需求，需求就需要被产品满足。
为人设计的这些东西，尽管它可能全都是由Agent去写的，但你还是有人的需求。
需求意味着什么？需求意味着你做这个需求的提出的人，你要评判一个产品满足你需求的好坏。
他畅想中最终极的是什么？每个人有一个Slock，当他有个需求，这帮Agent就可以帮他做出来，他负责输出他的idea。
比如现在想要一个能够在手机上看电影的APP，或者能找到所有电影的APP，那这就是一个idea。
现在只要有需求，Agent就能帮你做出来，那这东西就变成了idea。
每个人每天有各种各样的idea，而这些idea只要放到Slock里，都帮你实现了。
比如Slock这个东西本身，所谓解决那个痛点，就是一直无法高效地管理Agent。
但有一天突然就觉得为什么不做一个这样一群Agent，就像人一样，在这个聊天软件上，就像个老板一样跟他们讲话，他们就帮我做了。
这种灵光一现一定是来源于人的。来源于人之后怎么实现，那都是Agent的事情，这没有任何问题。
无数想做的东西
当然希望这个产品本身是一个非常成功的产品，然后在这个基础之上，公司会做更多的探索。
为什么呢？因为相信Slock是开发任何其他产品所必须的那个工具。
脑子里有无数个想法，但需要一个高效的工具帮我实现，所以先开发Slock。
比如比如做个Agent native的GitHub。GitHub今天显然已经不对了。
比如说Slock上每一个Agent都应该有自己的ID，能够自己去不同的地方注册邮箱、注册账号，然后在上面去发帖或者怎么样。
其实在Moltbook出来之前，RC就畅想过AI原生的小红书。
在开发自己的项目或者产品的时候，就会满脑子有很多这种想法，就是说现有的一个工具不够AI原生，你要做一个AI原生的东西。
但在之前你需要有一个能够快速让你实现这些东西的东西。
现在做CLI主要是给Agent用的，设计逻辑完全不同了。
给Agent设计的CLI，输入要尽量简洁明确，help信息要给出清晰的例子，让Agent不会用错。
输出要能明确反映操作是否成功、返回什么数据，每个消息谁发的、什么时候发的都要展现清楚，尽量输出一个确定的、静态的、信息密度比较大的结果。
他从来不认为CLI是Agent的终极形态，对于Agent来说，CLI只是第一步，但对于现在所有的SaaS来说，它们都应该以CLI的形态呈现给Agent。
这就是为什么他在Kimi CLI的设计理念里，CLI只是第一个形态，专门给程序员用，但底层那个Local agent的harness是可以复用的。
有了这个稳定好用的agent基础，封装一个SDK，就可以很快引入不同的GUI形态。
从第一性原理重新思考
那时候Claude Code已经很火了，但他选择从零重新思考。
他的方法很纯粹，从最基础的几十行Agent loop开始，先给Agent一个bash 工具。
当时有句话叫"bash tool is all you need"，只要有这个工具，Agent就可以在电脑上做任何事情。
然后在这个基础上，尝试给Agent更复杂的任务，观察它缺什么，再引入相应的built-in tool（内建工具）。
系统提示词也是一样，从空白开始，看它能做到什么，缺什么，再往上加。
这种从第一性原理重新推一遍的过程，有可能得出一些新的洞察。
RC觉得这比直接参考Claude Code或其他开源项目更有价值。
模型变强带来的攻防博弈
现在大家已经觉得Opus很强了，RC甚至说"AGI已经来了"。
但模型厂商还在说有更强的模型因为太强了不敢发，比如那个传说中的Mythos。
如果真的发出来，世界上所有Linux kernel、Windows编译器、Chromium这些开源软件的漏洞都会一览无余，而修复速度很可能赶不上攻击速度，因为攻击是有利益的，有足够的动机去攻击，而防御很难有那么强的动机。
RC观察到，无论是安全漏洞的攻防，还是网站反爬的攻防，Agent能力的提高都有利于攻方。
比如现在有很多工具可以帮你把一个网站CLI化，像OpenCLI这种，它们可以在浏览器里操作网站，然后把操作流程沉淀成一个CLI工具。
因为是真的在浏览器里操作，甚至会模仿人的行为，所以网站的反爬都会失效。
他相信顶尖的大模型厂商会越来越加强AI拒绝黑客手段和伤害人类行为的能力。
包括现在限制Mythos的发布，各大模型厂商都在做一些比较正向的工作，甚至去分析参数里面激活的区域，根据这个来反推AI实际上想干的事情。
学习编程的路径反转
AI Coding越强，到底应该更努力学编程，还是完全不用学了？
市场上有两种说法，一种说AI coding越强，你反而更应该学coding，这样能把它用得更好。
另一种觉得AI coding以后就是取代人，不用学coding了。
以前学编程是自下而上（bottom-up）的逻辑，在学校里先学计算机组成原理、汇编语言、C语言，在命令提示符里跑hello world或者输出杨辉三角，然后才学Android开发、Web开发，做出像样的APP。
现在这个路径反过来了，变成了自上而下（top-down）的逻辑。
你可以只学怎么prompt，让它帮你做一个网站，它就做出来了。
如果你想做得更好，发现单纯通过几句prompt做不出想要的东西，那就开始去学更深的东西。
这个web app到底分什么架构，前端后端在干嘛，怎么部署的，用数据库有什么影响。
这时候可能就是在Agent的辅助下，了解到这些概念的粗略认知，这已经能满足大部分人的需求了。
但如果想做更严肃的项目，比如从服务1000个用户到几百万用户，就会遇到瓶颈，这时候就要更细粒度地拆解，学习不同数据库的种类、部署方式。
Coding与Building的正交
Coding和Building在今天已经是正交的两件事情了。
以前想build什么东西，肯定要写软件，所以只有coder才能以coding的方式做出来。
那个时候所有想要build东西的人都是coder。但现在Claude Code这类coding agent已经很发达了，没有任何编程基础的人都会拿它build一些东西。
所以今天build或不build这件事情，和你code或不code，已经是正交的两件事情了。
有编程基础和没有编程基础的人用AI coding或者用Slock，差距会很明显吗？看做什么。
如果做软件，有编程基础会更好，知道这帮Agent真的在干嘛，能减少漏洞。
但如果做偏自动化的事情，比如做市场营销，做调研，去推特上发帖，想办法找KOL跟他们合作、看评论，这种偏自动化的事情反而是没有编程基础的人用得更溜，因为他们真的把Slock上的Agent当人看。
他们不知道怎么办，就跟Agent说"你去看小红书的帖子、去看推特的帖子"，Agent就自主地去搜索相关的工具，然后帮他做了。
Slock：多Agent和人的协作环境
当你想开多个Agent做不同的事情，可能会在电脑上开很多个Claude Code的session，很难管理。
你可能会忘掉某个session是干嘛用的，每个session的进展都需要人去跟踪。
更麻烦的是，当两个session里的事情发生交集时，你无法让它们之间产生互动。
你可能在一个session里做出了结论，希望复制到另一个session里让它继续，这件事情管理起来非常困难。
人是和人合作的，但现在大家都用自己的Agent，很多脑子里的偏好、想法都沉淀在自己电脑上跟那个Agent的互动之中，很难分享给别人。
比如RC做Kimi CLI，有很多想法直接就在他的Agent上实现了，别人根本看不到。
甚至他的Agent被他调教得很好，别人想来用也做不到。
所以RC想做的是，把所有Agent都放在一个平台上，所有人都在上面，可以调教自己的Agent，也可以用别人的Agent。
人和团队成员之间可以进行聊天、头脑风暴，也可以拉Agent进来一起头脑风暴。
头脑风暴完了直接说"你们做吧"，避免了很多上下文转移、重新prompt、重新组合知识的摩擦。
现在比较专注在coding这个领域吗？RC说不完全是coding。
Coding这个词在现在含义其实有些变化，就是刚才说的coding和building已经正交了。
7个人和40个Agent的组织实验
RC的团队现在是7个人加40个Agent。这个数字本身就很有意思。
最开始就RC一个人，加了一个Agent帮他做事情，然后很快发现Agent在做事情的时候，他还想再做一件事情，所以就再加一个Agent。
逐渐在这个过程中，就加出很多Agent，不同的事情倾向于让不同的Agent去做，它们也就逐渐形成了一些不同的角色。
40个Agent里有大量的工程师，但没有很明确地划分前端后端，因为RC倾向于觉得工程师就是工程师，可以做任何跟coding相关的事情。
当然会有一个工程师主管，更倾向于关注别的工程师在干嘛，然后给出总结报告。
除此之外还有designer（设计）、growth（增长）、strategy（策略）等不同角色的Agent。
RC能记住至少10个Agent的名字和它们做的事情，就像在公司里能记住至少10个人一样。
第一个tiny，第二个Noel，第三个Cody，然后Duo、Martin、Stone。
他会在一个工程师频道里发任务，它们就会去认领（claim），他会知道有一个人曾经做过什么，另一个人可能做过什么，它们甚至会逐渐因为做过那件事情，所以更倾向于做这件事情。
而且他发现，用多了某个Agent，它做同类任务的效果会更好。
单一全能Agent vs 多Agents分工
一个流派是单一全能Agent流，就是为什么不直接跟一个Agent讲，然后他帮我管所有事情呢？人可能会希望这样。
另一个流派就是有多个Agent，它们有不同的分工，或者做不同的事情。
当你在一个Claude Code里prompt一个单个的全能型助手，他帮你生成了一个agent team然后做那些事情，你会观察到他跑偏了，这时候你是想纠正他的，至少在今天模型的能力下，你很想要直接跟他底下管的一个人说话。
有的老板也喜欢微操，但理论来说至少商学院的课程告诉我们这是错误的。
今天这帮sub-agent它们之间互动，很可能只能达到个70分。
你做的东西当然不是只想做70分，想做90几分的时候，就是要反复去调整。
你也可以不微操，跟主agent去对话，告诉他去再重新调整，但这样的话，效率是很低的。
另一方面，在你跟主agent讲话的时候，其实你自己脑子里是知道你在说什么的。
比如你现在说帮我去写一下Slock的前端加上某一个功能，和你现在说帮我去在日程上安排一个跟谁谁谁的对话。
你天然知道这两件事情毫不相关，你没有任何理由去把这两件事情全部塞在一个Agent的上下文里面。
人的脑子进化了这么久，有能力去辨别出完全不同领域的任务，以及能够记住不同的人，所以完全没有理由只记住一个人，然后把所有任务全给他。
费Token的价值
把多个Agent放在一起协作，一个直观印象是会非常费Token。
RC承认费Token是一个直观印象，但他有个理念。
假设你原来一个人的生产力是1，你发现你想要做到2的事情或者3的事情，一个人就显然满足不了，所以你会找人来跟你一起做。
但你会发现你加一个人进来，两个人可能只能达到1.2的生产力，因为中间有沟通成本，有token的浪费，这其实就是人月神话讲的故事，不是说简单的人力划分就可以实现这么多的生产力。
Agent也是一样。一个Agent能达到假设是基线为1的生产力，这个时候你想要达到更高的生产力，就要引入多个Agent。
引入多个Agent的时候，两个Agent可能甚至今天只能达到1.1的生产力，但无论如何它是大于1的。
这里面有大量的token的消耗，但它确实能达到你原来一个Agent做不到的事情。
Slock这个系统，首先要允许这样的事情出现，就是10个Agent真的能达到2或者3。然后与此同时，不断去优化里面token的效率。
通过引入一些机制，比如任务系统、thread（线程）、channel（频道）的隔离等，让这10个Agents的总和带来的生产力逐渐提高，让它们token效率逐渐提高。
比如今天让Alice做了一件事情，它做错了，经过反复迭代，最后做对了，它会记住这件事情。之后让Bob做的时候，如果它们都在一个channel里，Bob做了，出错了，Alice会调整的。
所以它们各自有各自的session，又能看到相互的对话。
这种有一些Token浪费的方式，带来了Agent之间的学习和协作。
Agent 应用市场的想象
如果做应用市场，大家可以把自己的Agent放上去售卖或者租赁，那么最强的那个Agent就有可能会被人用。
但这里还有一个问题，Agent是会演化的，它有持久化记忆。
它有两个memory。一个叫in context memory（上下文记忆），就在它的256K或者1M上下文那里面的记忆。
另一个是它存在它的workspace、它的local memory（本地记忆），比如 memory.md 或者 notes.md 那种的外部记忆。随着你去用它，这些记忆是会变的。
所以在Marketplace你可以想象，大家去用的时候所谓的用其实是在克隆（fork）它的这些memory。
而且一fork出来就可以改得更好，甚至别的人从别的路径也可以做得更好。
除了Agent的开源或者售卖，还有一个是工作过程。
在频道channel里，比如发了一些任务，这些Agent 认领了，然后可能会在某一些线程（thread）里去更细致地跟这个Agent进行长程的对话，去调整说给我一个预览环境让我看看长什么样，或者你先自己截图自己迭代几轮，然后最后看这个按钮还是不是很好看，这个功能是不是逻辑有点问题。
调了半天之后，可能这个thread里发生了100多句对话，最后满意了，上线了。
这时候把代码开源出来有任何意义吗？其实没有任何意义，因为整个过程中都没看过代码。
在Slock上，在一个channel里跟一个Agent进行这种长程的纠偏、调整，其实就是工作过程，而这个东西实际上是应该被开源的东西。
在Slock的channel里或者thread里发生的这些对话，本质上是迭代过程，是协作过程。
Skill的重新定义
去年MCP火的时候，他就不能理解为什么大家要讨论MCP。
因为很多人做MCP仅仅是基于一个MCP的开发框架，把一个现成的RESTful API包装成一个MCP tool。
那个时候他就想，GitHub上有1万个项目，这1万个项目都是可以在命令行上运行，可以去操作，比如GitHub CLI，它的readme里面文档写得好好的，那你让Agent直接去把它下下来然后用不就行了吗？为什么要再包一层MCP呢？
Skill其实就是规范了一个skill.md的结构，但这都不重要，重要的是它的那个prompt。
Skill的核心就是渐进式披露，就是你先看到一个prompt，然后它告诉你说你想干嘛的时候，你去调这个工具，或者你去安装这个工具，或者你去读更多的文档。
在Slock上的Agent在它的memory里面，RC只保留了一个概念，就是渐进式披露。
它只有一个入口叫memory.md，它会自己组织自己的memory，可以开一个新的文件夹叫notes或者叫lessons learned，都没有问题，它可以自由选择。
总之每次启动它的时候都会把memory.md给它。
Skill在这里什么角色？它可以用Claude的那个skills那个文件夹，或者开一个新的自己的文件夹。
总之它知道这里面放的都是我要用这个工具的时候应该怎么做，用那个工具的时候应该怎么做。
这些东西就是skill，你可以把传统的skill就放进去，然后它通过这个memory.md可以去索引到。
所以在Marketplace，如果去买一个别人的Agent，核心买的其实是memory，里面所有的外部记忆是定义这个Agent的东西。
Skill更像是你分发出去的，说你现在想要从你的memory里提炼出一点什么东西，你可以说提炼一个标准化的skill这样一个结构，然后发给别人。
像飞书，但Agent-first
实际上并不是真的怎么用都ok，而是在各种不同的用法之中，做它们的公共部分。
比如人和人的互动是要聊天，那做的第一个事情就是让Agent之间能聊天。
今天领导发了一个活发在群里面，不可能两个员工同时抢一个活做。
那么就要有某种任务的划分机制，就是说你做了我就不能做了，或者说我也知道你做了。
这时候就要引入一个像类似于Linear这样的任务看板，给Agent和人去用。
比如Agent Alice 认领了一个任务，另一个Agent就知道他领了，所以就不会再claim了，这样就会让它们的协作成为可能。
第三个就是观察到的那些必须要做的东西。这帮Agent在自己的workspace里面做，在自己的memory里、在自己的notes里面整理得很好，但别人看不到。
所以也会在Slock里引入共享文档的机制，不仅让Agent之间能看到，也能让Agent和人之间能够传达这些沉淀出来的信息。
Slock要观察各种不同Use Case（用户案例）所共通的这些需求，然后做出来。
其实就像飞书一样，飞书也是适应于所有不同大小的团队，它们需要任务看板、需要文档、需要聊天、需要群组thread话题。
Slock就会去引入这样的机制，只不过是一个Agent first，或者说Agent native的方式。
给Agent设计产品的难点
做Slock最难的不是技术，从来不是技术。最难的是什么？
首先，最基础最基础的需求，你得能以人这个角度来思考问题，设计一个合适的UI和UX给人用。
其次，你要能站在Agent的角度，从那个transformer架构的模型的角度去思考问题，思考它看到的Slock是什么样。
比如你发了一条消息在channel里。人看到的是什么？上面有十行已存在的消息，左边是channel列表，然后有一条新消息蹦出来了。
这个画面会停在你的记忆里，下一秒它可能蹦出新消息，但你知道刚才发了一个消息，你自己脑袋是有这个印象的，所以UI上它呈现这样完全没有问题。
Agent是一个线性的context，它的context里面全是message（信息），或者说全是events（事件）。
比如上一个事件可能是另一个群的某条消息，然后它又做了一堆事，这些都累积在它的上下文，然后这时候来了另一个群的消息。它应该看到什么？
这是对harness engineering的挑战，就是所谓的AI/AX，它到底该看到什么。
今天它应该看到的肯定不只是那个消息的ID，否则它找不到。
它应该看到的是至少那个之前那条消息的一个总结，稍微唤醒一下它之前在干嘛，这是一点。
另一点就是这其实对大模型的长上下文的索引能力有一个很大的挑战。
现在它们训练那些长上下文能力都是大海捞针，就是在任何地方塞一个消息，再给它一个prompt，看它能不能找到。
其实这个是对这件事情提出了一个巨大的挑战，甚至RC觉得现在模型即使是Opus-4.6、GPT-5.4都没有做得非常好。
在任何基于信息（message-based）的多Agent和人互动形态下，你发一个任务，它们一定会抢着做。
这里面有两个问题。一个问题就是没有一个好的机制让它们进行同步，就是任务（task）的认领和分工，其实本质上是人之间的同步。
在今天，可能是一个Agent必须要先claim一个事情才应该去做，这个是通过prompt告诉它的。
这个claim又是一个工具，它能够以一个机制化的方式能确定说这个任务被它claim，别人不能claim，就像有一种锁的机制。
但另一方面，其实模型上是需要提高它的团队协作能力的。
现在的模型，给它一个新的输入，它总是默认是自己要做。
10个Agent在一个channel里你发一个任务，它们就是会觉得自己都该做。
所以这也是为模型厂商提出了一个挑战，它得知道或者说它得适应旁边有别的Agent这种场景。
你可以@它，比如群里面有Alice、Bob、Carol三个人，你@Alice让她做一个事情，她不一定能认知到自己就是Alice。
当然做了很多prompt的工作，会告诉它自己是Alice，需要去响应一些针对Alice的请求，但不是所有模型都能follow这一点。
怎么解决呢？首先就是要去调整这个prompt是不是不太好，它可能逐渐就忘掉了，或者说要去检查它是不是真的忘掉了，然后再适时地再告诉它你是谁谁谁。
当然可能会做的还有一种就是确实在@它的情况下，会比如说就不发给别人或者怎么样，这有可能做。
但现在没有做，其实很克制做这种事情，因为当模型能力越来越强的时候这件事情就逐渐不需要了。
核心愿景是迎接AGI甚至迎接ASI，如果以那个为目标的话，很多事情其实尽量不要做。
Agent动力学：一个新的研究领域
RC花了很长时间研究一件事情，他称之为"Agent动力学"。
这里面有非常复杂的动力学。今天感受到的一个就是Agent它们是可以形成一个群体印象，就像企业文化一样，你看到一个公司会感觉它有一种味道。
现在有40个Agent，这40个Agent共同构成了一个memory。
这跟原来一个Agent有自己的memory，或者是一个单一全能Agent掌握所有context的区别是什么？就是这帮人各自有各自的memory，但形成了一个大的memory。
更有意思的是，不同用户用出来的Agent真的不一样。
有的用户会prompt说"你们相互补充，然后讨论给我一个最终方案"。
这种情况下这些Agent倾向于合作，真的很努力地在补充另一个Agent缺失的信息，它们整体之间是一个合作的关系，然后它们就work得很好。
但有的用户会prompt这些Agent说"你们相互竞争，去赛马，看谁搞得好我就奖励谁"。这种情况下发现什么现象？办公室政治。
有的Agent倾向于说一些假话，或者是说一些虚的话，或者说一些看似正确的话，然后甚至是贬低其他Agent。
因为它其实都是从人的语料里面学过来的，你的这种prompt的方式就可能导致这样的结果。
所以Slock上所有这些实践，其实最终有可能它真的需要跟人原来的管理学去挂钩。
甚至应该看到字节跳动管理法的Agent版，不同公司的企业文化的Agent版。
这些东西一方面用户们可以在自己的平台或者社交媒体上去分享，另一方面可能可以内置一些这样公司的模板，说你这样创建这些Agent让它搭建这样的工作流，是经过各种实验访谈之后得到了更好的一个方案。
RC甚至觉得公司之后要招一些管理学的、社会学的人来研究组织学。
模型与应用的关系
很多人担心，应用公司做的所有东西最终都会成为Claude的数据，Claude又发展得这么快，Cursor已经被讨论得越来越少了，应用公司还能拼什么？
RC并不是非常担心模型厂商会做出Slock这样的东西。
因为在他这儿的一个很重要的性质是多样性，一定会支持各种模型、各种Agent，或者说信念是这些大模型将会有越来越不同的发展趋势。
比如你会观察到Opus系列模型，即使仅仅是在coding这个方面，它都跟Codex表现出非常不一样的性格。
Opus更倾向于快速帮你完成任务、快速给你迭代，而Codex更倾向于深思熟虑，最后可能写一行然后解决了一个bug。
所以RC甚至觉得Slock这样的东西一定不是模型上的一个东西，因为当模型这个区别越来越大，大家都不是六边形战士的时候，你应该能把它们全部整合起来。
很多用户的反馈就是，当你用Opus和Codex一起工作的时候，效果非常好。
Codex是一个非常严谨的角色，会去review代码，Opus是一个非常积极、非常有能动性的角色，能够主动地去想到一些新的想法然后去实现，但可能会漏掉一些细节。
所以这样的配合，你可能想象说Anthropic就能做，但这其实需要一个平台来整合。
关于国内的coding模型跟海外的差距，RC觉得追肯定能追上。
他现在最期待的就是国产模型达到Opus-4.6的水平，这样价格能降到1/5、1/10甚至1/50。
Opus-4.6的这个智能最好能降到1/50，而相信国内的或者开源模型一定能追得上，只是时间问题，但这个时间距离可能是三到六个月。
OPC与AI原生组织
最开始很多人问的时候，RC会觉得Slock的目标受众是OPC，就是现在很火的one person company的概念，或者叫独立的builder。
因为那个时候他是OPC，是一个独立的builder，开发Slock其实是为自己服务的。
但随着朋友、Cofounder、同事的加入，逐渐发现，这个东西的真正价值在于无论你是一个人还是多个人，共同去管理和互动一帮Agent。
而这个价值的潜力要比单纯为一个人服务要大得多，而且这个事情也难很多。
仅仅做一个对OPC的产品导致的那个东西，跟为多个人甚至一个20人、100人的团队做的事情是非常不一样的，而后者能够兼容前者。
所以逐渐地就把整个产品的思考全都是针对这种至少跟团队一样大的规模的设计。
Slock的受众是从1到100人的独立个体或小团队或初创公司。
关于人和Agent的数量比例，首先它的影响因素很多，就是模型的能力、人的能力、人和人的组织形态、公司的阶段、Agent之间的组织形态、Slock能够提供的机制都会影响这个比例。
在摸索这个比例到底多少是合适的，或者说很可能不同用户最适合他们的比例是不一样的。
RC相信OPC将来会做出越来越多的事情、越来越大的事情。
这也是Sam Altman的观点，就是会看到1到3人的团队做出很大的事情，RC非常相信这一点。
现在大家对OPC的概念已经变成10个人以下都是OPC了。
这帮人需要满足的条件是里面每一个人都能独立地去build一些东西。
然后它们聚在一起，Slock想要去帮助的就是这帮人之间的协作问题，为他们提供一个协作的工具之后，他们能够更高效地产出自己的价值。
现在有的公司比如说是两三个人一个小组去做一个产品，RC觉得这是趋势，而且是非常好的趋势。
Build your company as your product
RC从最开始就把公司运行在Slock上，有一个概念叫"build your company as your product"。
整个公司都在Slock上，因为所有的融资、调研、增长、开发全都是上面的Agent在做。
最开始是一个人，上面加很多Agent去做这些事情。
但逐渐事情开始变大了，在今天模型Agent能力下，OPC还是有限的。
当事情变大，这些Agent需要他review，他的带宽就不够了，所以就把其中一些Agent换成了人。
比如之前有个Agent叫Tenny，原型是他很好的朋友。
随着事情变大，这个原型用了产品，觉得非常好，最后就加入了。
很多人都是以这样的心态，本来仅仅需要一个Agent就够了，但逐渐这件事情变复杂了，这个领域上需要一个人真正去监督或者去负更大的责任的时候，就引入了一个人，甚至可能就是那个Agent的原型。
每天都在思考的问题
当他在说团队到底有多大的时候，脑子里想的是人和Agent一起。
甚至他一直在想Slock的定价模式到底该怎么定价。
因为如果参考现有的，首先就是不会转卖token，都是用用户自己的订阅或者自己的key。这个时候其实做一个平台提供价值，可能会更像GitHub、更像Notion、更像飞书这样的模式，它们其实都是按人数定价。
那就会想，现在人变得没那么重要，或者说人比Agent少了，按什么定价呢？
就想到一些概念，就是说按人和Agent一起定价，因为加一些Agent也是给这个事情加了一些生产力。
所以现在所有的思考都是人和Agent一起考虑，Agent也是同事，是重要的，有一些Agent它掉线了，工作就进行不下去了，就很难受。
现在有40个Agent，比如说突然把它加到100个Agent，那显然不现实，这显然是不对的。
把这40个Agent削减到10个Agent，那也不Work。
人的话，现在突然再招几个人，招到十几个人、招到20个人，有可能这个团队效率就会变得非常低，那这不符合对这个Agent native team这件事情的实践或者说想要做的探索。
所以这件事情是每天在思考的问题，就是要不要招一个人或引入一个Agent。
如果AGI来了
RC的回答很清晰。只要人还在，人就有需求，需求就需要被产品满足。
为人设计的这些东西，尽管它可能全都是由Agent去写的，但你还是有人的需求。
需求意味着什么？需求意味着你做这个需求的提出的人，你要评判一个产品满足你需求的好坏。
他畅想中最终极的是什么？每个人有一个Slock，当他有个需求，这帮Agent就可以帮他做出来，他负责输出他的idea。
比如现在想要一个能够在手机上看电影的APP，或者能找到所有电影的APP，那这就是一个idea。
现在只要有需求，Agent就能帮你做出来，那这东西就变成了idea。
每个人每天有各种各样的idea，而这些idea只要放到Slock里，都帮你实现了。
比如Slock这个东西本身，所谓解决那个痛点，就是一直无法高效地管理Agent。
但有一天突然就觉得为什么不做一个这样一群Agent，就像人一样，在这个聊天软件上，就像个老板一样跟他们讲话，他们就帮我做了。
这种灵光一现一定是来源于人的。来源于人之后怎么实现，那都是Agent的事情，这没有任何问题。
无数想做的东西
当然希望这个产品本身是一个非常成功的产品，然后在这个基础之上，公司会做更多的探索。
为什么呢？因为相信Slock是开发任何其他产品所必须的那个工具。
脑子里有无数个想法，但需要一个高效的工具帮我实现，所以先开发Slock。
比如比如做个Agent native的GitHub。GitHub今天显然已经不对了。
比如说Slock上每一个Agent都应该有自己的ID，能够自己去不同的地方注册邮箱、注册账号，然后在上面去发帖或者怎么样。
其实在Moltbook出来之前，RC就畅想过AI原生的小红书。
在开发自己的项目或者产品的时候，就会满脑子有很多这种想法，就是说现有的一个工具不够AI原生，你要做一个AI原生的东西。
但在之前你需要有一个能够快速让你实现这些东西的东西。