← 所有标签

# 产品

Agent 动力学

这篇文章是 42 章经对 RC 的访谈,核心围绕三个主题展开:CLI 时代为什么重新兴起、Agent 产品该如何设计、以及多 Agents 协作的组织形态会怎样演化。整篇对话的信息量很大,重点不是单纯讲一个工具,而是在讨论「人和 AI 如何一起工作」这件事。

1. CLI 为什么会重新火起来

RC 认为,CLI 之所以再次变得重要,是因为它对 Agent 更友好。相比图形界面,命令行天然是文本化、结构化的,更适合大模型理解和操作。随着 Agent 能力提升,过去只适合人类直接使用的 GUI,反而不一定是最优入口。

他强调,今天的 CLI 已经不只是“给人用的命令行工具”,而是开始变成“给 Agent 用的工作界面”。因此,输入要尽量简洁、明确,输出要尽量稳定、高密度、可被机器直接读懂。

2. Kimi CLI 和“本地 Agent harness”

RC 回顾了自己做 Kimi CLI 的经历。他并不认为 CLI 是 Agent 的终局形态,但它是一个很好的起点,因为可以先把最底层的本地执行框架做扎实:

  • 先有一个最小可用的 agent loop
  • 先接入 bash tool
  • 再逐步补充更多 built-in tools
  • 再基于这套 harness 封装 SDK,扩展到 Web UI、VS Code 插件等形态

他很看重这种“从第一性原理往上搭”的方式,认为这样更容易发现新的 insights,也更容易把能力沉淀成可复用的底座。

3. 模型能力提升后,安全与反爬都会被重写

文章里有一段很重要的判断:当模型能力继续提升,很多原本依赖“人类行为差异”的防线会被削弱。RC 认为,不论是安全漏洞扫描,还是网站反爬,Agent 都会越来越强,甚至会反过来逼迫防守方升级。

他提到,未来模型如果足够强,可能会让底层软件、编译器、内核、浏览器等系统暴露更多漏洞;而防守和修复往往跟不上攻击速度。类似地,网站也会越来越难依靠传统交互方式来区分人和机器。

4. Slock:不是单个 Agent,而是多人 + 多 Agents 的协作平台

RC 重点介绍了他创业后在做的 Slock。它不是一个“单一全能 Agent”,而更像一个人和多个 Agents 协作的工作空间

他认为,今天的 Agent 使用形态会越来越接近组织协作,而不是单人问答:

  • 需要通信:人和 Agent、Agent 和 Agent 之间要能沟通
  • 需要分工:任务发出后要有 claim / lock 机制,避免重复抢活
  • 需要共享:不同 Agent 的沉淀要能被其他人和 Agent 复用

他把这套机制类比成一种“AI 版飞书”,但底层逻辑更偏 Agent-first。

5. 多 Agents 协作的“动力学”

文章里最有意思的概念之一是“Agent 动力学”。RC 认为,当多个 Agent 长期协作时,它们不只是各自拥有 memory,还会形成一种群体记忆和群体文化,类似组织行为学中的公司文化。

他观察到,不同用户会把 Agent 组织成不同风格:

  • 有的更像协作型团队
  • 有的更像赛马竞争
  • 有的甚至会出现“办公室政治”式行为

这说明,未来 Agent 产品不只是工程问题,也会越来越像组织学、管理学和社会学问题。

6. Memory 比 skill 更重要

RC 对 MCP、skill、prompt 的看法也很明确:

  • MCP 本质上常常只是把 API 再包装一层
  • skill 只是把能力标准化、结构化,方便分发
  • 真正重要的是 memory

他认为,Agent 市场里卖的不是某个固定功能,而是该 Agent 的长期记忆、长期对话、纠偏过程和行为模式。也就是说,用户买到的不是“一个 app”,而更像是“一个会持续演化的工作伙伴”。

7. agent-first 产品设计:让 AI 先看懂,再让人看懂

文章后半段讨论了一个很关键的问题:产品不应该只为人设计,还要为 Agent 设计。

RC 提到,人类看界面是依赖空间结构的,但 Agent 的记忆是线性的 context,因此产品需要考虑:

  • Agent 如何快速定位上下文
  • 新消息如何和旧任务关联
  • 如何把任务摘要、状态、历史记录组织成 Agent 能直接用的信息

他说,真正难的不是把界面做漂亮,而是让“Agent 看到的产品”足够清晰、可执行。

8. 人和 AI 的未来关系

RC 的整体态度偏乐观。他认为未来不会简单变成“AI 取代人”,而更可能是:

  • 顶尖模型厂商越来越重视安全边界
  • 人类和 AI 会在更复杂的组织结构里协作
  • 编程、产品、设计、增长、运营等许多工作都会变成“先说目标,再由 AI 执行”的方式

他甚至提到,很多以前需要程序员才能做的事情,未来会被 top-down 的方式重写:先用 prompt 做出原型,再按需补充更深层的知识。

结语

这篇访谈的价值不在于某个单点技巧,而在于它把 CLI、Agent、Memory、多 Agents 协作、组织结构 这些概念串成了一条线。RC 的核心判断是:未来重要的不是“一个超级 Agent”,而是一个能让很多 Agent 和人一起工作的系统。

如果说传统软件是在为人设计界面,那么这一代产品开始是在为“人 + Agent 共同组成的组织”设计基础设施。

爆款产品灵感

这篇文章翻译并整理了 Lenny Rachitsky 对 50 家顶级消费级公司的创业起源研究,重点讨论“创业灵感到底从哪里来”。作者的核心结论是:大多数成功产品的起点并不戏剧化,往往只是创始人先被一个具体问题困住,然后亲手去解决它。无论是 Dropbox、Airbnb、Uber,还是 Calm、Warby Parker,很多故事最初都只是“我自己先不爽了,所以想做个更好的东西”。

文章把找到创业点子的方式归纳为五类:关注自己的痛点、追随好奇心、放大已经跑通的东西、关注范式转移,以及和朋友一起头脑风暴。作者强调,最常见的路径是“先解决自己的问题”,但这并不意味着所有好点子都来自亲身痛点。相反,很多优秀创意其实是在持续观察、反复试错和不断积累中自然浮现的,而不是某次灵光一现。

文章还总结了很多消费级创业者的共性:他们大多比较年轻,常常有联合创始人,且并不总是拥有特别罕见的专业背景。更重要的是,许多最成功的产品在诞生时都看起来并不起眼,甚至显得有点蠢,但它们背后解决的是高频、真实、足够痛的需求。作者因此提醒创业者,不要被“点子不重要”的口号误导,真正重要的是你是否能识别一个值得长期打磨的问题。

文章后半部分用大量案例说明,每一个点子如何从日常烦恼、个人体验或行业空白中长出来。它的实际价值不只是讲故事,而是给创业者一套筛选灵感的视角:关注自己周围反复出现的不便、观察别人已经做成但还没被彻底优化的事情,并警惕那些看起来很酷、但没有真实需求支撑的想法。

整体来看,这是一篇关于“如何找到好创业点子”的系统性方法总结。它想传达的不是神秘配方,而是一个很朴素的判断:真正好的产品灵感,往往来自对现实的不满、对细节的观察,以及愿意亲自动手把问题做对。