摘要

RC 的核心判断是：CLI 不是面向人的 Agent 终局，却会成为所有 SaaS 面向 Agent 的基础接口。 大模型天然读文本，截图或 Accessibility API 的方式效率更低；Agent-facing CLI 要追求简洁、明确、静态、高信息密度，让调用者一眼知道“操作有没有成功、返回了什么数据”。对产品公司的含义是：未来软件首先要回答的，可能不是人如何点击，而是 Agent 如何发现、安装和调用。
Slock 押注的不是又一个聊天界面，而是“人 + 多 Agent”组织的协作层。 RC 的公司已经以 7 个人和 40 个 Agent 运转；两个 Agent 也许只能把生产力从 1 提到 1.1，十个也许只到 1.5，但只要大于 1，就能完成单 Agent 做不到的事。任务认领、thread、channel 隔离和共享文档，都是在把这种非线性增益继续向上推。
真正的产品壁垒被 RC 称为“Agent 动力学”：让一群有独立记忆的 Agent 形成分工、互相纠错乃至企业文化。 他主张“一个 Agent 就是一个 session”，允许它跨 channel 看见同伴；Alice 被纠偏后，下次 Bob 犯同类错误，Alice 可以主动提醒。代价是冗余消息和 token 浪费，收益则是 40 个 Agent 共同形成一个比单体 context 更大的“群体记忆”。
多 Agent 协作最难的不是基础技术，而是同时设计人类 UI/UX 与 Transformer 所看到的 Agent experience。 人看到的是稳定界面，Agent 接到的却是一条线性的 events 流；跨群新消息如何唤醒旧 thread、Alice 是否知道自己是 Alice、十个 Agent 如何不同时抢任务，连 Opus 4.6、GPT-5.4 都“没有做得非常好”。这意味着平台价值可能落在 context 编排、身份、同步和组织机制，而非简单套壳。
Agent marketplace 若成立，交易的核心不会是静态 App 或单个 Skill，而是可 fork、会演化的 external memory。 Agent 同时拥有 256K 或 1M context 内记忆，以及 memory.md、notes 等 workspace 记忆；买来之后继续使用，本质上就是 fork 出一条新演化路径。RC 更激进的判断是：当人从未读过代码时，真正值得“开源”的不是最终代码，而是人与 Agent 一百多轮纠偏、预览和决策的工作过程。
面对 Claude 等模型厂商向应用层推进，Slock 的防御逻辑是模型与 Agent 的 diversity。 RC 观察到 Opus 更积极、更快实现想法，Codex 更严谨、善于 review 和以很少改动解决 bug；“大家都不是六边形战士”时，跨模型编排反而有价值。他期待国产或开源模型在“可能三到六个月”追到 Opus 4.6，并把同等智能成本降至五分之一、十分之一，理想状态甚至五十分之一。
RC 最终押注的是小团队规模与软件经济学一起被重写：3—5 个能独立 build 的人，与一群 Agent 协作，可能成为高效基本单元。 Slock 暂不转卖 token，用户使用自己的订阅或 key；但传统按人头定价失去锚点，因此 RC 正考虑按“人 + Agent”共同计价。即使 AGI 到来，他也不认为产品失去意义：“需求本身就是 idea”，人的灵光一现负责提出需求，Agent 负责把它实现。

精读

1. CLI 的复兴不是怀旧，而是软件接口从人迁向 Agent

RC 先把 CLI 还原为 Command Line Interface：GUI 出现前，人们就在命令行里操作电脑；DOS 是曲凯熟悉的旧例子，只是过去它主要服务程序员。
大模型是 text-based 的东西，“天然不适合读 GUI”。早期 Computer Use 可能通过截图或 Accessibility API，甚至喂给模型用 XML 框起来的结构化数据，但这种方式效率较低；terminal 更适合被模型看见、理解和稳定调用，这让 CLI 在 Agent 时代重新走红。
Agent-facing CLI 与过去给人用的 CLI 不同：输入、help message 和 menu 要简洁明确，最好附例子；输出则要静态、高密度，并清楚表达成功与否、返回了什么。
RC 举的飞书例子很具体：如果 Agent 要 list 所有消息，结果至少应明确显示发送者、发送时间和内容，而不是让它面对动画、交互状态或需要再次猜测的界面。

2. Kimi CLI 从空 prompt 推演出来，CLI 本身只是第一站

访谈中曲凯以“2025 年 8 月开始做 Kimi CLI”作为时间点追问；RC 的回答是，Claude Code、Gemini CLI 已证明 local agent 的价值，但他并未大量参考它们或其他开源 coding agent 的实现，而是想重新理解一个基础 agent loop 如何逐步获得读写文件、操作浏览器和完成复杂 coding 任务的能力。
这最初只是 side project。RC 从几十行 loop、空 system prompt 和第一个 Bash tool 开始，相信“Bash tool is all you need”；等复杂任务暴露缺口，再逐项增加 built-in tools 和 prompt 约束。
他的刻意选择是少看 Claude Code 与开源 coding agent 的实现，因为“这是可以从第一性原理重新推一遍的过程”；重新推演不仅能做出外壳，也可能得到不同的 insight。

3. 面向人的 terminal 不是终局，面向 Agent 的 CLI 却会成为标配

RC 起初并不喜欢 CLI 形态：Claude Code 的流行逼着从未见过 terminal 的 non-tech 用户进入命令行，这在他看来并不是大众产品的合理终点。
Kimi CLI 的关键资产因此不是终端界面，而是底层 Agent Harness。Harness 稳定后可以封装 SDK，再快速接入 Web UI、VS Code 扩展等 GUI；“对于一个 Agent 来说，CLI 不是它的终局形态。”
但他对 SaaS 得出相反结论：Notion、Linear 等软件都应该以 CLI 形态呈现给 Agent。人可以使用流畅的 Web UI，Agent 则需要可发现、可组合、确定性更强的文本接口。
曲凯追问为什么最终仍先做 CLI，RC 的回答是：它是第一步；到他离开 Kimi 前，后续 GUI 与复用 Harness 的路径已经铺完。

4. Coding 模型越接近“AGI”，安全攻防越先偏向攻击者

RC 把 Claude Code 真正变得可用的节点放在 Sonnet 3.5 到 3.7，随后到 Opus 4、Opus 4.5，复杂任务能力持续跃升；到 Opus 4.5 时，他个人甚至产生了“AGI 已经来了”的感受。
对传闻中更强却未发布的模型，他给出极端但有条件的推演：“如果它真的发出来，那这个世界可能都要崩溃了。”银行系统、Linux kernel、Windows、编译器、Chrome 等软件的漏洞可能更快暴露，而有利益驱动的攻击速度可能超过修复速度。
另一条攻防发生在反爬：OpenCLI、CLI Anything 一类工具可在真实浏览器里操作网站，再沉淀成 CLI；网站增强检测后，Agent 又可把验证码变成简单操作、模拟鼠标延迟和人的操作路径。RC 的观察是，两类场景里能力提升都暂时更利好攻方。
他仍自称“共存派”，相信顶尖模型厂商会加强拒绝黑客和伤害行为的训练，也会研究模型内部激活与意图的关联。但安全公司“可能”逐渐失去部分价值：RC 已反复让 Agent 找漏洞、修漏洞，因此自己不需要一个很庞大的安全团队。

5. Agent-native 软件会把安装指南压缩成一句话，最后连这句话也消失

当软件直接以 Agent 为用户，人没有理由阅读介绍和安装文档，只需知道它“能给自己的 Agent 带来什么增量能力”。复制两行 prompt 让 Agent 自行读 Skill、安装 CLI，已经在降低人的心智负担。
RC 把这一路径概括为“Skill 加 CLI”，底层其实就是“prompt 加 Bash tool”：Skill 告诉 Agent 何时调用工具、安装程序或读取更深文档，CLI 则提供可执行能力。
他认为最终连安装 prompt 都不该存在。以可创建临时 database 的 DB9 为例，人只需说“你自己数据存好”；Agent 应自行搜索方案、找到网站、读 Skill、安装 CLI，而不是让人参与工具选型。

6. Kimi 的人才机制是敢给 ownership，离开的原因则是模型自由

RC 最初被 Kimi 的“摇滚精神”吸引；他对内部氛围的正面评价，不是年轻本身，而是有能力、有意愿的人可以把 scope 做得很大。
他此前没有 AI 经历，但 side project 证明价值后，Kimi 愿意让他 own 这个项目。“它可能不一定百分之百信任你，但是它敢 bet 你能把这件事做成。”
离开源于 1 月初形成的创业想法。RC 认可 Kimi 是国内和开源模型里最好的之一，但判断新产品需要最 frontier 的模型；独立创业才能自由支持各种模型和所有 Agent，维持他认为必要的 diversity。

7. Slock 要解决的首先是 session 失控和团队知识被锁在个人电脑里

第一个痛点来自 RC 开发 Kimi CLI 的后期：一个人同时开十个 Claude Code session，很快会忘记每个窗口在干什么，还要逐一追踪进度。
更麻烦的是任务交叉。一个 session 已经得出结论，另一个 session 却看不到；人只能复制、重写 prompt、搬运 context，无法让它们自然互动。
第二个痛点发生在人与人之间：偏好、想法和对 Agent 的“调教”都沉淀在个人电脑里。RC 在自己的 Agent 上实现了 Kimi 时的许多想法，同事可能完全看不见，也无法直接复用那个 Agent。
Slock 因而把所有人和 Agent 放进同一协作环境：人可以聊天、头脑风暴、拉 Agent 参与，讨论结束后直接说“你们做吧”，省掉 context 转移和知识重组。

8. Slock 关注的是 build，不是狭义 coding

RC 认为 coding 的边界已经变化：过去只有 coder 能通过写软件 build 东西；如今没有编程基础的人，也能借 Claude Code 一类 Agent 做出产品。“Build 或不 build”和“code 或不 code”已经成为正交的两件事。
技术背景仍在 serious software 中有价值，因为开发者更清楚 Agent 做了什么，也更容易发现漏洞。但在调研、Twitter 发帖、寻找 KOL、分析评论等 go-to-market 自动化里，反而是没有编程基础的人用得更顺。
原因不是他们懂工具，而是他们“真的把 Slock 上的 Agent 当人看”：想让 Agent 看小红书或 Twitter，就直接说“你去看”；Agent 自己搜索所需工具并完成任务。
曲凯由此追问，学习编程会不会成为人类走过的弯路。RC 没有否定技术知识的价值，但判断各行各业的 builder 不必再先学编程，底层程序与工具调用可以被 Agent 藏起来。

9. 编程学习将从 bottom-up 倒转为 top-down

过去的路径是从计算机组成、汇编、C 语言、Hello World 和杨辉三角开始，再走到 Android、Web 和像样的 App；RC 把它称为 bottom-up。
今天可以先学 prompt，让 Agent 直接做网站。好看或难看都没关系；只有当结果达不到预期，人才向下拆解前后端、部署、数据库与架构，由具体需求拉动学习。
当产品从服务 1,000 个用户增长到几百万、几千万，数据库与部署瓶颈会继续迫使 builder 深挖。但这不是所有人都要预先支付的学习成本，而是项目变 serious 后才发生。
曲凯的反驳是：为什么不让 AI 自己学习，或调用标准 Skill？RC 的回答缩小了人必须掌握的范围——可以招一个 Agent 架构师，但“你需要知道你要招一个架构师”。

10. 7 个人和 40 个 Agent 的意义，不在 token 省不省，而在产能上限是否被推高

曲凯直觉上认为 47 个“成员”会极耗 token。RC 借《人月神话》回应：一个人生产力是 1，加一人后可能只有 1.2，因为协调本身有成本；Agent 数量同样不会线性兑现。
他的示意数字是：一个 Agent 为 1，两个今天也许只有 1.1，十个也许只有 1.5。“这里面有大量的成本消耗”，但只要超过 1，就能做单 Agent 无法完成的事情。
Slock 首先要允许十个 Agent 达到 2 或 3 的可能，再通过 task、thread、channel 隔离等机制提高 token efficiency。RC 没有统计自己的 Token 效率或日均消耗；他的工作状态就是每天在 Slock 里与 Agent 讲话。
7:40 不是设计出来的固定比例，而是从 1 人、1 Agent 逐渐演化。模型能力、人的能力、公司阶段、组织形态和平台机制都会改变最佳比例，不同用户也可能得出完全不同的答案。
RC 从一开始就把整个 company run 在 Slock 上，称之为“Build your company as your product”。随着事情变大、自己没有足够带宽 review，他把一些 Agent 换成了人；例如 Agent Tiny 的原型后来成为 Head of Engineering。

11. 多 Agent 组织需要角色，但不应把职业分工刻得过细

RC 的 40 个 Agent 里，大量角色是 engineer，却不严格划分前端、后端；他的倾向是“engineer 就是 engineer”，只要与 coding 相关就可以接任务。
Engineering channel 里的任务由 Agent claim；谁做过某类事情，之后往往更倾向于继续做。另有 Head of Engineering 关注其他 engineer 的进展，向 RC 汇总报告。
团队也有 designer、growth、strategy 等角色，每一类可能只配一两个 Agent。这个结构不是先画组织图再填人，而是在反复使用中逐渐长出专长与责任。
RC 已能记住至少十个 Agent，知道谁曾做过什么、谁更适合哪类任务。“有一些 Agent 真的特别好用”；同一个 Agent 重复处理同类工作，效果也会逐渐变好。

12. 单一全能 Agent 省界面，却牺牲了今天仍然必要的可干预性

RC 把市场分成单一全能 Agent 与 multiple agents 两派。前者让主 Agent 生成并管理 team，看似省心；但 subordinate 今天往往只能做到约 70 分，而用户想要的是 90 多分。
曲凯提醒，老板爱微操不等于微操正确，商学院甚至会说这是坏管理。RC 的回应是“首先在今天它肯定是对的”：通过主 Agent 层层转述纠偏效率太低，人需要直接找到具体执行者。
另一个理由来自 context：让 Agent 写 Slack 的前端与安排一次日程毫不相关，人天然知道应分开处理，没有理由把所有任务塞进同一个 Agent 的 context。“人的脑子进化了这么久”，本就能区分领域并记住不同协作者。
RC 不因此主张一百或一千个直接下属，但至少应该有几个可被独立寻址的 Agent。Slock 选择顺应这种组织直觉，同时继续观察人类实际带宽的上限。

13. Agent marketplace 卖的是可 fork 的 memory，不是静态能力包

Agent Store 已在 roadmap 上。RC 承认某个领域最强的财务 Agent 可能被广泛租用或购买，但它不会像 App Store 第一名那样保持静态。
Agent 有两层记忆：256K 或 1M context 中的 in-context memory，以及 workspace 内 memory.md、notes 等 external memory。随着使用，这些内容持续改变；从 marketplace 获取 Agent，本质是 fork 它的 memory。
不同用户会沿各自路径继续调教，某个 fork 甚至可能超过原版本，因此它更接近一种新的 GitHub，而不是统一分发不可变软件。
RC 也重新定义“开源”：他与 Agent 在 thread 里经过一百多句对话，要求预览、截图、自我迭代，再纠正按钮与业务逻辑；既然全程没看代码，真正有意义的是“迭代过程、协作过程”，而非最后那份代码。

14. RC 质疑 MCP 的再包装，认为 Skill 的核心是渐进式披露

MCP 流行时，RC 不理解为什么要把现成 RESTful API 再包成 MCP tool：GitHub 上有 1 万个项目可以在命令行上运行，README 也写明用法，Agent 完全可以自己下载和调用。
Skill 的流行在他看来反而验证了这一点。SKILL.md 的格式不是核心，核心是“渐进式披露”：先给一个 prompt，等任务需要时再告诉 Agent 调工具、安装程序或读取更深文档。
Slock 的 Agent 只保留一个固定入口 memory.md，其余结构由它自己组织，可以新建 notes、lessons learned 或 Skill 文件夹。传统 Skill 也能直接放入，再由 memory.md 建立索引。
因而 marketplace 中定义 Agent 的，是全部 external memory；Skill 更像从 memory 中提炼出的标准化、可分发片段，而不是独立于 Agent 的灵魂。

15. Slock 不限定短对话或长任务，但会把协作共性做成基础设施

曲凯把路线对比为高频人机互动与 Manus 式长程自主任务。RC 拒绝二选一：用户可以让 Agent 持续监听 GitHub issue、信息源或新 AI 产品，自动调研、讨论并执行，Slock 不限制运行长度。
“前台沟通”和“后台沟通”在他看来也不是本质区别。Agent 可以在 channel 里用人能读懂的文本，也可以自行开发数据库、代码或 GitHub issue 等更高效工具；平台不强迫所有交换都经过聊天气泡。
但自由使用不等于平台什么都不做。人和 Agent 需要聊天；多人任务需要 claim 和排他锁，避免重复；个人 workspace 里的沉淀需要共享文档，让团队共同访问。
RC 的类比是飞书：聊天、群组、thread、任务看板和文档服务各种团队，Slock 则以 agent-first、agent-native 的方式重做同一组协作原语。“最难的不是技术，从来不是技术。”

16. Agent 动力学把模型差异、组织管理和“需求即 idea”连成同一门生意

这个空间的 demo 在 1 月 4 日用半天就能做出；正式做 Slock 后，团队投入大量时间研究这些问题，称其为“Agent 动力学”。这套体系尚未成型，但第一个结论是“群体印象”：40 个 Agent 各自拥有 memory，又共同形成更大的 memory。
真正难点是双重视角：人看到稳定 UI，Transformer 看到的却是跨 channel、tool call 与历史消息组成的线性 events。新消息至少应该附带旧 thread 的 summary 以唤醒 context；Opus 4.6、GPT-5.4 的 long-context 索引仍“不算非常好”。
模型的 teamwork 和身份也不稳定：十个 Agent 收到任务会默认都该自己做；被告知 Alice 的模型甚至可能聊着聊着忘记自己是谁。Slock 用 prompt、task claim 和 exclusive lock 补救，却克制硬编码路由，因为面向 AGI、ASI 时，许多补丁可能自然过时。
RC 坚持“一个 Agent 就是一个 session”，让它跨 channel 看见同伴。冗余 token 换来的收益是互相纠错与“群体印象”：鼓励补充会形成合作文化，要求赛马和奖励胜者则可能出现虚话、贬低同伴与“办公室政治”。他甚至设想不同公司的企业文化和管理法会出现各自的 Agent 版本。
上游模型风险的答案仍是 diversity：Opus 积极、有能动性但可能漏细节，Codex 深思熟虑、适合 review；国内或开源模型追到 Opus 4.6，RC 估计“可能三到六个月”。
Slock 目前不转卖 Token，用户使用自己的订阅或 API key；它面向 1—100 人的独立个体、小团队或初创公司，尤其关注 3—5 个能独立 build 的成员。RC 正考虑按“人 + Agent”计价；即使 AGI 到来，人仍负责灵光一现，因为“需求本身就是 idea”，而 Slock 希望成为把每个 idea 实现出来的组织系统。
他还设想 agent-native 的 GitHub、Agent identity，以及让每个 Agent 拥有自己的 ID、注册邮箱和账号；在 Moltbook 出现前，他也曾设想过 agent-native 的小红书。共同前提是，先有一个能快速实现这些产品的工具。

Elon 的600亿美元 Cursor 豪赌、Claude 终结 SaaS，以及 OpenAI 的大规模离职潮 | EP #249 投资 SaaSpocalypse：Heller House 的 Marcelo Lima