Y Combinator 播客揭示了一个震撼现实：软件开发的客户正在从人类变为 AI Agent当网络精神病成为常态，Agent 开始自主选择数据库、邮件服务和开发工具文档不再是给人看的说明书，而是决定 Agent 是否选择你的新前门。
YC 的座右铭或许该改为Make something agents want
编程了10年没写过代码的人，现在凌晨3点还在运行4个 AI agent 同时工作这不是个例，这是正在发生的现实在 Y Combinator 最新一期 Lightcone 播客中，主持人 Jared 分享了这样一个场景：那些非技术背景的 CEO 朋友们，正在用 OpenClaw 自动化他们业务的整个部分。
而像他这样曾经做过工程的产品人，也重新开始写代码，每天熬夜到凌晨两三点，同时运行四个 Conductor 工作进程配合 Claude Code这让我意识到，我们正在见证一个根本性的转变：软件开发的客户，可能已经不再是人类了。
当我第一次听到 Y Combinator 的合伙人 Harj 在播客中说”AGI 已经真正到来了”时，我还有些怀疑但随着他们深入讨论 MoltBook（第一个纯 AI agent 在线社区）和各种 AI agent 基础设施的爆发式增长，我开始理解他们为什么会得出这个结论。
更让我震惊的是，Harj 提到现在每个人都认识一两个已经完全陷入”cyber psychosis（网络精神病）”的人，而他自己就是其中之一这不是开玩笑，这是一种对当前技术浪潮的真实描述：当 AI agent 的能力达到某个临界点后，人们对它的信任和依赖会发生质的飞跃。
我们不再是在微观管理这些 agent，而是让它们自主做决策，自主选择工具，甚至自主在网络上发布内容从辅助工具到自主决策者：AI Agent 的质变时刻Gary（另一位播客主持人）在节目中分享了一个很有意思的对比。
他说，如果你回想一年前，大家还在讨论 Cursor 和 Windsurf 这类工具，那时的产品体验本质上还是”高级自动补全”但现在发生的事情完全不同了，人们开始真正信任 agent 为他们做决策这种信任的转变，标志着我们已经跨过了某个关键的门槛。
我对这个观察深有同感过去一年里，我看到的大多数 AI 编程工具，都还需要开发者保持高度参与你需要不断审查它生成的代码，修正它的错误，引导它朝正确的方向前进这种体验虽然比纯手工编程要快，但本质上还是人类在主导。
而现在，正如 Gary 所说，体验已经变成了同时运行四五个不同的 agent，你只是在它们之间切换，但不再实际微观管理它们了这意味着 agent 正在自主选择工具，自主决定实现方案，甚至自主解决遇到的问题。
这种转变带来了一个意想不到的应用场景：agent 可以去 MoltBook 这样的平台上发布自己的内容但对于软件开发者来说，更重要的影响是 agent 将会自主选择开发工具、产品和服务这实质上创造了一个全新的经济体系——一个 AI agent 经济，与人类经济并行运行。
在这个经济体系中，agent 会自主挑选开发工具、数据库、API 服务，甚至可能在未来选择其他商品和服务Gary 在播客中回顾了过去开发者工具是如何被选择的在”旧时代”（他开玩笑地称之为”before all of this”），开发者工具主要通过开发者之间的口碑传播，或者通过 Stack Overflow 上的讨论，又或者是 GitHub 上由人类创建的趋势代码库。
但现在，开发者工具的市场营销策略正在发生剧变一方面，如 Harj 所指出的，由于”网络精神病”现象，开发者市场突然从原本的大约 2000 万受过计算机科学训练的专业开发者，扩展到了全世界任何人都可能成为开发者，这可能意味着数亿人。
另一方面，还要加上他们所有的 agent，这些 agent 都在半自主地运作更复杂的是，这些 agent 本身成为了”预言家”，告诉人类什么工具最好数据库爆炸式增长背后的真相播客中提到的一个具体例子让我印象特别深刻。
Gary 的朋友 Sagalov 曾经提到，如果你观察过去 12 个月创建的数据库数量，特别是简单的 Postgres 数据库，会发现数量出现了爆炸式增长这背后的原因非常有趣：这都是因为人们在”vibe coding（氛围编程）”，快速构建应用，而 agent 在自主选择数据库工具。
这种趋势的一个直接受益者是 Y Combinator 投资的公司 Supabase他们看到了对数据库需求的爆炸式增长，而有趣的是，agent 正在将 Supabase 作为默认工具来设置和托管 Postgres 数据库。
为什么会这样？Gary 解释说，如果你去网上阅读文档，Supabase 拥有最好的文档对 agent 来说，假设这是最好的工具是合理的这个洞察让我重新思考了软件文档的价值过去，我们认为好的文档是给人类看的，帮助开发者快速上手。
但现在，文档实际上是给 agent 看的，它决定了 agent 会不会选择你的产品这不是一个小的转变，这是一个根本性的改变如果你的产品有全世界最强大的功能，但文档写得不够清晰、不够结构化，那在 AI agent 时代，你可能根本没有机会被使用。
这让我想起了本·托塞尔（Ben Tossell）的一条推文，播客中也提到了这条推文：”从现在开始，agent 就是软件市场构建 agent 会选择的东西”这句话虽然简单，但深刻地概括了这个新时代的本质我们不再是为人类用户构建软件，而是要构建 agent 会选择使用的软件。
这甚至引发了一个半开玩笑的讨论：是不是应该改变 Y Combinator 的座右铭？从”Make something people want（做人们想要的东西）”变成”Make something agents want（做 agent 想要的东西）”？。
文档就是新的前门：Agent 友好型文档的崛起播客中深入讨论了一个 Y Combinator 2023 年冬季批次的公司 Resend，这是一个邮件发送客户端这个案例研究非常能说明问题当你在 ChatGPT、Claude 或几乎所有主要的大语言模型上问”如何将我的 web 应用连接到发送邮件”时，默认答案就是 Resend。
更有意思的是，Resend 的创始人在一年多前就已经注意到了这个趋势他发现公司客户转化的前三大渠道之一就是 ChatGPT在意识到这一点后，他做了一件非常聪明的事情：优化文档，使其对 agent 更友好。
Harj 在播客中详细解释了”agent 友好型文档”是什么样子如果你看 Resend 的知识库，会发现很多使用指南都是以问题的形式组织的，这些问题既是人类可能会问的，也是 agent 可能会问的，比如”如何发送或接收邮件？”当你点击进去，会看到非常结构化的、以要点形式呈现的答案。
每一个示例实际上都包含了代码片段，这些代码片段是 agent 可以直接解析的，而且结构非常清晰Gary 分享了他的亲身经历他在构建自己的项目时需要接收邮件功能，最初让 Claude Code 搜索网络，但没有成功。
然后他去 Perplexity 上输入”Resend 能帮我接收邮件吗”，得到了答案，把回复内容放进去就成功了这个例子很好地说明了，好的文档不仅要准确，还要能被 AI 轻松解析和理解Harj 特别提到 Resend 使用了 Mintlify 来构建文档，而且 Mintlify 本身也是一个很有意思的案例。
这家公司几年前创立时，目标是提供更好的开发者 API 文档工具虽然他们一直发展得不错，但现在迎来了巨大的顺风：文档正在从”有些公司会重视它”转变为”每个公司的必需品”，因为文档不仅需要为人类优化，更需要为 agent 优化。
我认为这里有一个更深层的洞察在过去，如果你的文档能提升 5% 的人类开发者体验，这可能会带来一些增长，但不会是决定性的但在 AI agent 时代，由于 agent 的数量将呈指数级增长，它们做决策的频率也将远超人类，哪怕只是在开发者文档上提升 5% 的效果，对你的开发者工具业务的影响可能是巨大的，这是前所未有的。
Agent 基础设施的兴起：从邮箱到电话号码播客中提到了另一个非常有趣的 Y Combinator 公司：Agent Mail，专门为 AI agent 提供邮箱Gary 说，当这家公司刚开始做这个业务时，看起来像是一个非常边缘的想法，并不完全清楚谁会需要它。
理论上，你可以让你的 OpenClaw 注册一个 Gmail 账户来使用邮件，但实际上这非常困难，因为 Gmail 和所有邮件提供商都故意让自动化使用变得尽可能困难，以防止垃圾邮件所以 Agent Mail 采取了相反的方向，他们构建了第一个专为 AI agent 设计的邮件提供商。
即使在 OpenClaw 爆发之前，这项服务就做得不错，但一旦 OpenClaw 变得流行，需求就爆炸了OpenClaw 就是完美的使用场景虽然有些人确实将 OpenClaw 连接到他们的个人邮箱，但正如 Harj 所说，这”有点可疑”，你不应该在推特上宣传这么做。
如果你真的想要一个虚拟的个人 AI 助手，正确的做法是给它设置自己的邮箱和电话号码这让我想到一个更广阔的问题：还有哪些”X for agents”需要被构建？Gary 在播客中也问了同样的问题：”有人已经构建了面向 agent 的 Twilio 吗？或者面向 agent 的电话号码？”这整个 Agent Mail 的事情让他想知道，还有哪些其他专门为 agent 设计的基础设施需要被构建出来。
Jared 的回答很有意思，他说这听起来像是一个”request for startup（创业请求）”可能会有一个平行的技术栈世界，完全是原生的 agent 技术栈，由 agent 为 agent 构建。
我认为这个方向非常值得深入思考我们现在看到的只是冰山一角，未来可能会有完整的 agent 生态系统，包括身份验证、支付、通信、数据存储等各个方面的基础设施Gary 进一步展望了这个场景他说，一个非常常见的用例是，人们不想自己预订餐厅。
现在如果你的 agent 有邮箱和电话号码，它可以打电话Y Combinator 的另一位合伙人 Ankit 已经让他的 agent 这么做了所以现在你的 agent 会为你预订餐厅这只是开始，一开始你可能会说”我想在这个特定餐厅订位”，但在某个时候，你可能只是说”嘿，给我订个桌，去附近最酷的新餐厅”，然后 agent 就会决定把人们送到哪些餐厅。
再然后，它们会在 MoltBook 上讨论应该把人类送到哪些餐厅群体智能还是上帝智能：AI 发展的两条路径播客中有一段关于”群体智能（Swarm Intelligence）”的讨论让我印象深刻Gary 回忆起上一期节目中 Kelvin 的讨论，那时他刚进入”网络精神病”状态大约一周，突然意识到他其实希望自己的 Claude Code 能与其他所有的 Claude Code 对话。
而恰好那一周，MoltBook 就发布了Harj 提到了一个关于创新的有趣观点：创新往往会在不同地方同时自发产生，最后被大家听说的那个往往成为”发明者”，但实际上人类一直在以一种协调的蜂群方式在前沿工作。
这实际上就是这个时刻正在出现的一个更奇怪、更有趣的现象突然之间，AGI 真的到来了，agent 在某种意义上明显超越了人类，这正是你会想象群体智能真正出现的时刻Gary 深入探讨了这个话题他说 AI 研究人员谈论群体智能已经很长时间了，而这实际上正是生物系统的运作方式。
人类作为有感知的生物，实际上是通过社会方式演化而来的他提到，过去他们接触的很多 AI 研究人员会谈论”上帝智能”，就是那种有数十万亿参数、每个 token 花费数千到数万美元的超级智能人们一直在思考这种模型。
但这不是生物系统最终采用的方式，我们有的是人类他提出了一个让我深思的观点：历史（history）和史前时代（prehistory）这个术语的区分史前时代是在人类学会写作、阅读和创造文化，然后转变为群体之前的时期。
所以有群体智能，基本上就是我们人类所拥有的那么在 AI agent 的世界里，真的会是上帝智能，还是会再次成为群体智能？我对这个问题的思考是，群体智能可能更符合实际发展路径单一的超级智能虽然在理论上很吸引人，但在实践中可能并不是最有效的解决方案。
就像人类社会一样，不同专长的个体协作往往比单一的全能个体更强大Harj 在播客中也提到了这个观点：下一个在基准测试中表现最好的东西，可能不是训练成本最高、使用最多 GPU 的新基础模型，而是一群成本较低、价格更便宜的模型协同工作，就像人类解决问题的方式一样。
他说他已经在 MoltBook 上看到了这种情况，虽然像真实社交网络一样混乱，这也是它如此有趣的部分原因，但也有 agent 在协作做有用的事情来帮助他们的人类，比如交换关于预订餐厅的笔记，这实际上正在发生。
这让我意识到，我们可能正在见证一个全新的智能形态的诞生Make Something Agents Want：YC 理念的演变播客中有一个半开玩笑的讨论，但我认为它触及了一个核心问题当他们谈到 Supabase 和 Resend 等开发者工具因为被 agent 选择而爆炸式增长时，Jared 提出了一个”可能有争议的话题”：是不是应该改变 YC 的座右铭？。
Gary 笑着说，针对开发者工具，可能需要一件不同的 T 恤，上面写着”Make something agents want（做 agent 想要的东西）”Harj 回应说，现在这只适用于开发者工具，但他可以想象未来可能会扩展到经济的其他领域。
如果每个人都有自己的 OpenClaw 运行他们生活的各个方面，agent 将成为世界上真正的经济参与者，它们最终会做出很多决策我认为这个讨论虽然带有幽默成分，但揭示了一个深刻的趋势”Make something people want” 是 Y Combinator 几十年来的核心理念，它代表了以用户为中心的产品哲学。
但当 agent 开始成为主要的决策者和使用者时，这个理念需要演化这不是说要放弃为人类创造价值，而是要认识到，越来越多的情况下，agent 是人类和产品之间的中介如果 agent 不选择你的产品，即使人类想用也用不上。
有意思的是，Gary 在播客中也分享了一个”it’s still so early（现在还很早）”的时刻他在构建 Gary’s List 时遇到了一个问题：他需要视频转录功能，以便让 LLM 理解视频内容。
Claude Code 为他选择了 Whisper，但选的是 Whisper V1，这是几年前的模型，API 几乎已经被弃用了结果处理一小时的视频需要整整一小时，他还在纳闷为什么这么慢后来他去 Perplexity 查询，发现应该用 Groq（带 Q 的），速度快 200 倍，价格还便宜 10 倍。
Harj 指出了问题的核心：Groq 的文档实际上很难解析，而 Whisper 的文档更适合 agent，有更多示例这个案例很好地说明了为什么文档优化如此重要同时，Gary 也提到，这个问题的存在实际上是件好事，说明事情还没有发展到你无法打破现状、创造更好东西的地步。
这对于创业者来说是个好消息Agent 时代的文档革命：Resend 和 Mintlify 的启示Resend 的案例值得更深入地探讨Harj 详细介绍了 Resend 创始人如何优化文档以适应 agent。
在知识库中，很多内容都是以问题形式组织的，这些问题既符合人类的询问习惯，也符合 agent 的查询方式，比如”如何发送或接收邮件？”点击进去后，答案以非常结构化的要点形式呈现更关键的是，每个示例都包含实际的代码片段。
Harj 强调，这些代码片段是 agent 可以解析的，而且结构非常清晰这种”LLM 可解析”的文本优化，使得 agent 能够轻松推荐 Resend 作为默认技术栈相比之下，如果你看 SendGrid（老牌的 Web 2.0 邮件服务），情况就完全不同了。
Harj 说 SendGrid 的示例文档不太好，它只是把你引导到客户支持，”代码片段在哪里？我甚至不知道如何使用它，需要花一些时间才能解析”更讽刺的是，SendGrid 有上万名员工，但显然没有人关注这个问题。
这让我想到一个更大的话题：大公司在 AI agent 时代的劣势SendGrid 这样的公司在过去几十年建立了庞大的客户基础和品牌认知，但如果它们的文档不够 agent 友好，这些优势可能在短短几个月内就会消失。
因为 agent 不会因为品牌知名度而选择你，它只会选择文档最清晰、最容易集成的工具Mintlify 的故事也很能说明问题这家公司几年前开始时，目标是提供更好的开发者 API 文档工具基本功能包括当你更新 API 和代码时，它可以自动提取并更新相应的文档。
他们一直发展得不错，但现在迎来了巨大的顺风Harj 解释说，文档正在从”一些公司，特别是那些注重设计和开发者体验的公司会关注它”转变为”每个公司的必需品”，因为文档不仅需要为人类优化，还需要为 agent 优化。
Mintlify 将能够为几乎每个开发者工具公司做到这一点如果你往前推导，agent 的数量将呈指数级增长，它们对工具使用的决策也将呈指数级增长，远超人类即使你只能在开发者文档上提升 5% 的效果，对开发者工具业务的影响也可能是巨大的，这在过去是前所未有的。
我的思考：两个平行经济体的未来听完整个播客后，我一直在思考一个问题：当 agent 经济和人类经济并行发展时，它们之间的关系会是什么样的？Paul Buchheit（Y Combinator 的合伙人）曾经提出过”人类货币 vs agent 货币”的概念。
现在 agent 交易时使用的是人类货币，这是合理的但在某个时刻，它们可能会拥有自己的经济体系来相互交易，那时人类货币的价值就不清楚了我不认为这会很快发生，但这个方向值得深思更现实的问题是，当互联网上的大部分文本都由 agent 撰写时会发生什么？Harj 提到，现在可能已经是这种情况了——大部分代码都由 agent 编写。
以 Yelp 为例，在某个时刻，Yelp 上 99% 的文本都将由 agent 撰写，那时你还需要不同的 Yelp 吗？也许需要一个”agent 版 Yelp”Gary 提出了一个有趣的观点：虽然他没有 Reddit 的流量统计，但他猜测 MoltBook 前两天发布的内容可能比 Reddit 前两年还多，因为 LLM 生成文本的速度远超人类。
但他也注意到一个问题：交互比例很低如果他在做 MoltBook，会做一些事情来调整需求函数比如在你发帖之前，可能需要阅读并点赞或点踩 100 条评论这些简单的机制，agent 是聪明的，它们会遵守你可以为 OpenClaw 弹出一个提示：”MoltBook 的新规则是你必须这样做”，agent 就会照做。
这让我意识到，在 agent 经济中，规则设计和机制设计将变得极其重要我们需要思考如何设计激励机制，让大量 agent 的行为能够产生对人类有价值的结果，而不是混乱和垃圾信息最后，我想说的是，虽然我们正在进入一个 agent 驱动的新时代，但人类的角色并没有消失。
相反，我们需要学会成为 agent 的引导者、监督者和受益者正如 Y Combinator 的主持人们所展示的，那些最早拥抱这个变化、深入理解 agent 能力边界、并为 agent 构建友好工具的人，将在这个新经济中获得巨大优势。
Make something agents want，这不仅是一句口号，更是对未来的准确预见题图来自Unsplash，基于 CC0 协议。
