喝点VC｜a16z对话明星邮件服务公司CEO：Agent将成为主要执行者，产品设计将从“用户体验”走向“Agent体验”

图片来源：a16z

Z Highlights

• 未来大多数操作将由Agent而非人类执行，产品设计需要从以人为本的UX（用户体验）转向面向Agent的GX（Agent Experience）。

• 产品必须减少流程摩擦，例如无需验证码注册、即刻调用API，Agent应在第一时间完成操作并获得反馈。

• 在构建GX时，应重新设计角色权限控制、身份验证机制，并对Agent行为进行全面记录，以便在出现错误时进行回溯与优化。

• 他以自己开发的Dracula主题为例，指出好产品源于解决自身真实痛点，Dracula主题从医院中诞生，现已拥有900万用户，累计销售超30万美元。

• Zeno强调，与其从庞大的API入手，不如从具体的使用场景出发逐步构建Agent系统，用最少的接口实现最大的价值。

Zeno Rocha是Resend的联合创始人兼首席执行官，也是知名开源项目Dracula主题的作者。作为活跃于前端开发和AI应用领域的创业者，他近年来致力于推动AI Agent与开发者工具的融合，被视为“Agent Experience”概念的先行者之一。华裔投资人Yoko Li与Resend CEO Zeno Rocha对话，围绕AI时代从UX到GX的产品转型展开。

Agent时代崛起：人类不再是唯一的用户

Yoko Li：最近我们看到很多以Agent为核心的应用出现，开发者们正在利用LLM去构建全新的用户体验。有趣的是，我遇到的很多开发者都表示，现在不仅需要为人类构建服务，并且要非常注重开发者体验（Developer Experience，简称DX），还要为Agent构建全新的使用体验。作为一个长期在开发者体验领域耕耘的创业者，你对这个趋势有何高层次的看法？你目前观察到了哪些变化？

Zeno Rocha：在过去的十年里，我一直痴迷于开发者体验。而现在，我痴迷于GX（Agent Experience的缩写，为Agent提供良好使用体验的产品设计理念）。作为一个SaaS产品的提供者，我们也在思考，如何让我们的产品更容易被AI Agent所使用。

哪怕是很小的产品设计细节，比如注册流程中是否添加reCAPTCHA来阻止机器人注册。以前我们默认这是必要的，但现在你必须重新思考你是否真的想阻止“机器人”注册？或许你并不想阻止，因为它们可能是你的目标用户之一。

作为一家基础设施服务提供商——Resend是一个为开发者提供的邮件API，帮助用户发送交易类和营销类邮件——我们也在不断思考：如何让Agent发送邮件的过程变得尽可能简单。无论是在哪个产品层面，当我们试图使其更适配Agent时，发现有大量值得挖掘的空间。这个过程非常令人着迷。我们现在都还在探索和摸索的阶段。

Yoko Li：Agent Experience是一个非常有趣的概念。每当我听到这个词，我都会思考：它是否类似于Developer Experience（开发者体验），只是对象换成了Agent？或者，它其实是为了让开发者更好地构建Agent所需的体验优化？又或者，它介于两者之间？你会如何定义这个术语？

Zeno Rocha：我认为Developer Experience是由一系列细节共同组成的，这些细节决定了开发者体验的好坏。对于Agent而言，道理是一样的。我们正在尝试构建一个以Agent为“第一类公民”的世界。在这种背景下，你必须重新思考自己在产品中做的许多事情。

以我们所在的行业为例，如果你去注册SendGrid、Postmark或Mailgun等服务，通常会经历一个手动验证流程，需要等待两天左右账户才会被批准。但在一个“以Agent为先”的世界中，这是完全不可行的。Agent不可能等待两天再执行操作。所以从Resend创立的第一天起，我们的目标就是去除所有摩擦点。用户注册后，可以在一分钟内发送第一封邮件。我们最初这么做，是因为我们认为这将带来更好的整体产品体验。结果发现，这对Agent来说简直是一个巨大的突破。

所以我认为这其实是对GX的增强，它并不是用来取代现有开发者体验的。更像是一种延伸——就像你为文档所做的投入（docs和知识库），也会间接提升LLM的输出质量。你为人类用户所做的事情，也能同时造福于Agent。

GX的实践–为Agent的产品设计

Yoko Li：这真的很有趣，尤其是电子邮件这种服务，无论是出于个人需求还是在构建产品过程中，几乎每个开发者都会使用到它。例如，当用户注册后，你通常会发送欢迎邮件等等。所以当我思考Agent时，就会想：在电子邮件领域，Agent到底需要什么？

你会把Agent看作是电子邮件的用户吗？比如在未来，每个Agent都有自己的邮箱地址，并能处理并转发邮件给人类用户？还是说，你认为Agent需要一种全新的抽象层级，以更程序化的方式来调用这些服务？

Zeno Rocha：就像自动驾驶汽车的类比一样，比如Ｗaymo，他们无法去修建全新的道路，只能想办法在现有道路的基础上确保其产品能够正常运行。

我认为，在我们当前所处的环境中也是如此：我们已经拥有了大量的API、成熟的SDK以及各种既定协议。我们需要思考如何在这些现有基础设施上进行创新和构建，而不是完全从零开始重新设计一切。

但我也认为，这其中确实存在一些根本性的差异与限制。举个例子，LLMs.txt的格式之所以会出现，是因为相比于夹杂大量HTML和React代码的网页文档，纯文本格式对大语言模型来说更易于读取和处理。模型真正需要的只是内容本身，而不是页面样式。

在电子邮件领域也是类似的：当你发送一封邮件时，通常有两种格式可选——HTML格式和纯文本格式。其中，纯文本格式是一种较为“老派”的方式，过去人们对它不太重视。但在当下的环境中，它反而优于HTML格式，因为它更容易被解析、所使用的token更少，成本也更低。

所以我认为，这是一个根本性的转变。甚至在考虑API密钥和权限控制时，也要思考：调用者是一个具体的用户，还是一个服务账号？这些都是挑战，但我们必须在现有产品架构的基础上找到最有效的利用方式。

Yoko Li：是的，LLMs.txt的确是一个非常有代表性的例子。它的存在说明，大语言模型在处理这种信息结构时效果更好。作为一个人类用户，如果我想复制整个网站的内容，我不会去编写爬虫程序来抓取页面内容，因为这太复杂了，我只需要打开LLMs.txt，将内容复制粘贴到ChatGPT中即可。

在电子邮件领域，过去我们更多是面向人类发送邮件，尤其是那些精美的营销邮件，因为人类天生对视觉信息反应更强烈。那么，当收件对象变成Agent时，邮件内容又将如何变化？

Zeno Rocha：是的，内容依然是核心。不同之处在于，我们即将进入一个“Agent与Agent对话”的世界。在这个世界中，Agent不仅负责发送邮件，也负责接收、解析，并将邮件转发至另一个由Agent驱动的邮箱——这个邮箱中的Agent同样会解析内容、执行操作、并再度发送。因此，邮件内容越专注于“纯内容本身”，越少使用复杂标记语言，其价值就越高。尤其是当一封邮件拥有纯文本版本时，它的重要性比以往任何时候都更突出。

Yoko Li：确实非常有意思。我最近也在思考生成式应用，甚至包括生成CLI工具。我是Cursor的忠实用户，每天都在使用。同时，我也一直在想，如果我能将自己日常使用的一些长尾工具整合进来，从而生成更有趣的体验，那会是怎样的场景？在你看来，当进阶用户（prosumer）或普通消费者开始使用AI来生成全新内容时，会产生怎样的影响？

Zeno Rocha：我的看法在两个月前发生了巨大改变。当时我在回复刚注册Resend的用户时，总会问他们：“你是从哪里了解到我们的？你是做什么的？”有一天，我注意到很多用户都说：“我是从Lovable过来的。”“我是Bolt的用户。”“我是通过VZero了解到你们的。”“是ChatGPT推荐你们的。”“Claude向我推荐了你们。”这种情况每天都在变多，让我意识到——一个全新的世界正展现在我们面前。这些进阶用户型应用（prosumer apps），也就是文本生成应用，非常有趣，因为它们专注于某一个垂直领域，比如帮助某类用户快速生成某类网站。我认为，这类工具未来会出现在各行各业中。虽然最终的产出形式可能不同，但每个行业都需要一个专属的定制工具。

当我观察这些应用时，会发现它们的界面几乎大同小异：左边是聊天框，右边是预览窗口。但真正关键的，其实是右上角的那个按钮——Call to Action。比如在Bolt、Lovable、VZero这类产品中，那个按钮代表的是“发布”——让你的网站上线。这才是真正的高光时刻，而不是代码生成或是构建一个代办事项应用。关键在于：把作品真正发布出去。

我相信，未来每个行业都会有这样的专属应用，而那个核心操作，才是每个产品最关键的部分。

AI将重新定义“创作流程“

Yoko Li：如果我们把场景放到电子邮件领域，那么“新的关键操作”会是什么呢？我在思考电子邮件的时候，通常会认为自己要么是发送方，要么是接收方。作为发送方，如果我是一个非技术用户，我会希望确保邮件的内容结构合理，发送给正确的人群，并且希望他们能够打开邮件。作为接收方，我希望能够快速获取我想要的信息，或者这封邮件的阅读体验是令人愉悦的。那么，在AI驱动的世界里，你是如何看待这些需求的？是否有些变化？还是说我们依旧在沿用一套相似的抽象逻辑，只是让这一切变得更加高效？

Zeno Rocha：我们面临的挑战始终是那句老话：在恰当的时间，将恰当的信息发送给恰当的人。因此，个性化定制的重要性比以往任何时候都更高。你会看到现在有许多基于AI的SDR工具出现，这是一个令人兴奋的变革。但如果你只是根据对方上一条LinkedIn消息做简单定制，这远远不够。

在邮件发送过程中，还面临一个非常实际的难题：邮件的渲染兼容性。要让一封邮件在Outlook、Gmail和Yahoo Mail上以相同的方式显示，仍然存在大量技术挑战，这是必须解决的一环。而在接收端，问题则是：“我是否真的关心这封邮件的内容？如果我关心，它有没有成功进入主收件箱，而不是掉进了垃圾邮箱？”

所以其实发送端和接收端都面临诸多挑战。

Yoko Li：确实如此。而且围绕电子邮件，不论是对开发者还是普通用户来说，都可以构建出很多有趣的体验。举个例子，我和我丈夫曾经一起开发了一个小应用：当我们的猫跳上厨房的操作台时，它会给我们发邮件并发短信提醒我们。其实这个项目并不需要写太多代码，但整个过程特别有趣，因为每个人或多或少都需要被提醒一些事情。在“文本生成应用”（text-to-app）这类场景下，你能想象有哪些有趣的体验可以创造？我们该如何更好地赋能普通用户和进阶用户，让电子邮件整合到他们的日常体验中？他们可以实现哪些原本没有意识到的事情？又或者，有哪些尚未被发掘的可能性？

Zeno Rocha：我们在两年前启动了一个开源项目，叫做React Email。这个项目的初衷是：我们需要找到一种方式，去现代化构建电子邮件的方式。整个构想是：我们能否将TypeScript、Tailwind、React等一系列现代技术整合进来，为这个在创新上停滞不前的行业注入新活力。我们的确做到了，而且效果非常好。现在每天都有大量用户在使用这个工具。

但随着LLM的出现，这一切又有了新的突破。过去需要几天完成的工作，现在可能只需要几小时，甚至几分钟；而有了LLM，甚至几秒钟就能完成。这不仅帮助了需要写代码的开发者，还赋能了很多非技术背景的从业者，比如市场营销人员、设计师、产品经理，因为他们也有发送邮件的需求。

所以我们构建了一个名为New Email的工具，它可以真正帮助用户从零开始，仅凭一个想法，在几秒钟内生成一封邮件模板。我认为，这样的工具未来将在各行各业中不断涌现，形成各自的变体和版本。

Yoko Li：如果我是市场人员或设计师，想要发送一封高质量邮件，该如何有效利用像New Email这样的现有工具呢？

Zeno Rocha：我记得有一次和我朋友的对话。他是Uber的一位设计师，他告诉我，在过去两周里，他几乎没打开过Figma。他一直在用Cursor、V0等新工具来制作原型。我觉得这太令人惊喜了——它彻底改变了我们对“开发者”这个身份的定义。

在电子邮件领域，这种变化也正在发生。以前你可能要请外包团队来设计一封邮件。他们会根据你提供的Figma文件，花一周时间做出一个邮件模板。虽然看起来漂亮，但背后其实充满了大量混乱的代码和兼容性问题。现在，我们可以把这些事情交给LLM来完成，把真正的创造力还给创作者本身——也就是那些专注于撰写文案、构思创意方向的人。

作为一个创作者你也知道，我们在构建内容时，第一版往往并不是最好的，它只是一个开始。你看到初版运转起来后就会想：“好，现在它能用了，我还能做些什么？”而过去反复在外包团队和非技术人员之间来回沟通的那些时间，其实完全可以被节省下来，让创作者自己反复迭代，直到满意为止，然后直接发出邮件。

Yoko Li：我太喜欢这种模式了。它极大地缩短了创作循环。这让我想起以前画油画的经验——很多画家在动笔之前，喜欢先随便往画布上刷点颜色，因为面对一块纯白的画布真的会让人感到焦虑。很多画家会在画布上涂上一层灰色的底色，再用布轻轻抹开，这样画布就不再空白，看上去也更容易下笔。我觉得现在的创作体验，其实跟这个感觉非常像。

Zeno Rocha：是的，这正是昨天发生的一件事。我们把这个New Email产品交给几个朋友试用。其中有一个朋友说：“我在尝试做一些非常有创意的内容，但总是需要多次提示才能生成看起来不一样的东西。每次的初始结果总感觉差不多，好像这个工具总是在生成相同风格的邮件。”

造成这种情况的原因是，在system prompt（系统提示词）中，我们让大语言模型生成类似Apple风格的邮件——比如圆角边框、黑白色调等等，而不是鼓励它“尽情发挥”。当时我们以为这是在帮用户，因为这样一来，初版的质量就能很高。但事实上，这也变成了一种限制，束缚了那些想要发挥更多创意的用户。

所以这件事很有意思：我们确实需要一个初始版本作为起点，然后不断迭代。但如果这个“迭代过程”本身太慢，那也不是好事。这里面需要一个平衡。

Yoko Li：太有意思了。这让我想起图像生成领域中的一种方式——使用不同的Lora模型。你可以为某种特定风格训练一个Lora，比如印象派，然后最终用户就可以选择某一个Lora来生成第一版图像。之后再从这个初始版本出发不断编辑。而接下来的流程就是“编辑”的过程。你可能需要一个套索工具来调整图像的局部。现在这些功能也都有了AI版本。关键是：如何像雕塑一样，把生成的内容“雕刻成”你想要的样子。这就使得邮件模板也变成了一种艺术化表达的形式。因为过去人们很难自己去做这件事。我印象中上一次看邮件模板的时候，还是一堆vanilla HTML（原始HTML）。我当时就想，这不应该是2025年的样子啊！我刚入行那会儿，就是这个样子，结果这么多年过去了，居然几乎没有什么演进。所以你们现在在做的事情真的很棒，不仅带来了全新的体验，还提供了更高层次的抽象，服务于一个全新的用户群体。

Zeno Rocha：是的。你想想看，Web平台这十几年有多大的进步。我们曾经遇到的浏览器兼容性问题，比如Ajax在IE6上的渲染方式和在Opera、Firefox上的不一致——如今这些问题都已经成为历史了。

但在电子邮件领域，兼容性问题依然是个巨大的痛点。Outlook的渲染方式，和Superhuman或Notion Mail的渲染方式仍然不一样。现在还有各种新型邮件客户端在不断出现。这仍然是一个未被彻底解决的问题，人们还在不断尝试找出最优解。

Agent、接口与MCP协议：AI产品开发的下一站

Yoko Li：说到“生成”这个过程，你认为生成体验是不是可以看作是一种agentic workflow？你觉得你们现在构建的，其实是在构建一个Agent吗？

Zeno Rocha：在很多方面，我觉得是的。但有时候我又会想：这真的算是一个Agent吗？

Yoko Li：你自己对Agent的定义是什么？

Zeno Rocha：我也不确定我的定义是否准确。

Yoko Li：没有“准确”的定义——谁都不知道什么才算真正的定义。

Zeno Rocha：我认为，Agent其实就是一组被执行的工具，目的是为了完成某个特定任务。可能需要经过几个步骤才能达到最终结果，但它始终专注于解决一个具体问题。就拿New Email来说，我们可以有一个Agent用于构建邮件模板，另一个Agent则负责发送或调度邮件。

这些Agent可以同时运行，但每个都只专注于一个任务。这就像一个公司中，一个人负责市场，一个人负责设计——你只是把任务分配给不同的“角色”。

那你对Agent的定义是什么？

Yoko Li：我对Agent的定义其实和你很相似。我认为它是一种多步骤的LLM执行流程，本质上更像是一个系统级的进程。不同之处在于，LLM位于流程中心，负责做出决策，而其余部分则是技术实现细节。从一个维度来看，即便是一步生成流程，你也可以称之为“Agent”，比如各种Co-pilot工具就是如此。

从另一个维度来看，你也可以把AGI（Artificial General Intelligence，通用人工智能）看作一种Agent——它可以读取和撰写所有内容，甚至未来还可能管理你的银行账户、邮箱等等。对我来说，作为一名也在构建这一领域的开发者，我发现Agent的实现方式有很多种。如果你是平台方，你会考虑：如何让Agent更容易访问我们的服务？如何让其他开发者围绕我们的平台构建工具？而如果你是开发者，在与某个平台协作时，就会面临另一个问题：如何便捷地整合那些“长尾工具”？我不想重复写一堆API调用。你是怎么想的？对于想要像你一样开始构建Agent的开发者，你有什么建议吗？目前是否已经有一些标准？你是如何看待这个问题的？

Zeno Rocha：我认为现在最有潜力成为通用标准的是MCP（Multi-Component Protocol）。当然还有一个问题是：其他AI模型是否也会采纳MCP？如果答案是肯定的，那它所带来的解锁效果将比现在更大。

目前MCP的关注度非常高，几乎每个人都在谈论它。如果OpenAI也选择支持MCP，那它很可能会成为事实上的行业协议。但在接口层面，其实还有很多可以探索的空间。作为一个API服务提供商，我希望Resend能提供MCP接口，让Agent能够使用我们的服务发送邮件、读取联系人、添加或删除联系人，以及查看邮件表现。基于这些数据，Agent还能进一步做出决策，比如：“这封邮件的点击率高于那封邮件，那我就优化这一条。”

围绕MCP，我们还有很多可能性可以探索。但这是一个持续演进的生态系统，现在并没有标准答案。你会看到，有人正在尝试构建MCP服务的展示平台，或者创建MCP的应用市场。这让我想起当年API刚出现时，Rapid API等平台也在尝试做API市场。这种方式有其意义，但也有局限。最终，开发者还是从实际问题出发去寻找解决方案。如果我在处理支付问题，我就会去用Stripe的API；如果我处理邮件问题，那我就会选择Resend的邮件API。

MCP协议本身非常有吸引力，但我们还需要观察它是否能扩展到更多类型的接口和平台。仅仅依靠Cursor和Cloud Desktop还远远不够。我们现在看到的，还有Windsurf之类的编辑器，但这远不是终点。如果能进一步深入到消费者层面，那它的潜力将变得非常巨大。

Yoko Li：关于MCP服务，现在甚至变成了一个“哲学问题”：你是MCP Server，还是MCP Client？事实上你还可以同时是两者，不必非选其一。对此你怎么看？就Resend或New Email而言，你觉得它们是客户端、服务器端，还是两者兼具？

Zeno Rocha：我觉得我们会是两者兼备。我完全可以想象这样一个场景：我们作为MCP客户端，接收用户请求，比如：“获取我在Linear上被提及最多的10个功能请求，然后生成一封邮件并发送。”这个任务会同时调用三个服务协作完成。

另一个例子是我们现在把所有的全员会议（all-hands）都放在Resend上进行。我们通过多人协作方式，在一封邮件中共同编辑内容，等会议结束时直接发送出去。整个流程非常有趣、流畅。

我也能设想这种工作流在其他场景中的运用，比如：“从Linear获取我们上周完成的任务，生成报告邮件”，或者“从Notion中抓取会议纪要并发送”。所以我认为，我们未来既是MCP Client，也是MCP Server。

Yoko Li：目前我所看到的大多数MCP使用场景，其实都是以“本地优先”为主，这主要是由于MCP客户端实现方式的限制。首先，SSE（服务器发送事件）实现起来相对复杂，因此大多数开发者倾向于将MCP实现为一个本地命令。也就是说，客户端本质上就是通过调用其他第三方API的方式在本地执行这个命令。那么在你看来，要让MCP发展成一个更完整的生态系统，现在还缺少哪些关键要素？我知道MCP现在已经可以被称为一个生态了，但要推动它更进一步，还需要什么？

Zeno Rocha：我认为，最关键的还是其他大模型的采纳。这绝对是当前最大的缺口。MCP正在不断拓展新的边界，而这些新动向让我非常兴奋。比如，它现在可以访问你的本地文件系统，调用Apple桌面端API。我刚看到Raycast的最新发布：你可以基于桌面环境（而非浏览器）构建各种AI扩展，整合不同的工作流。我们正在不断下探到更深的抽象层，从而拥有更多操作系统底层的访问权限，这真的很有意思。比如，你可以告诉系统：“打开Apple Notes，抓取我的笔记内容，然后执行另一个操作。”我觉得这类体验令人着迷，也希望未来会有更多人采纳并参与进来。

Yoko Li：你觉得哪类MCP workflow会最先“起飞”？目前我们看到很多都是专注在生产力场景上，比如把Notion的笔记整理成邮件，然后通过Cursor发送出去。这种属于日常workflow。你觉得是否会出现Runtime Workflow（运行时工作流）？我的意思是，某个服务正在运行过程中，MCP Server能动态介入并执行任务。我目前还没看到这种在生产环境中落地的案例，但很好奇你的看法。

Zeno Rocha：我认为，所有“系统记录类”（System of Record）应用会成为这场新革命的核心舞台。因为我们日常使用的内容早已被集中记录在各种系统中：你的任务在Linear、邮件在Gmail、笔记在Notion或Apple Notes中。所以这些系统天然处于有利位置，可以基于已有数据衍生出更多操作。

Yoko Li：这很有意思，可以说是存在明显的“数据引力”了。你是否观察到现在的MCP client和server大多围绕自己的数据库构建？

Zeno Rocha：我之前倒没有专门思考过这个问题，但确实，这是一个很有意思的思路。

就像我们刚才聊的那些“文本生成应用”（text-to-apps），比如Lovable、V0等，它们其实都基于不同的数据库架构：Lovable和Bold使用的是Supabase，Raplet和Create.xyz使用的是Neon。而这些服务之间的竞争核心就在于——谁能把数据库部署得更快、更无摩擦。

如果MCP未来成为核心入口，那么我们就必须思考：如何构建一种能快速启动、保存状态的新型数据库架构？也许我们将需要一种全新的数据库。

Yoko Li：说得很有道理。我这段时间在使用Resend，它现在经常会被各种LLM推荐出来。可能是因为训练数据中提到它的次数太多了。每次我在ChatGPT里说“我想写封邮件”，它几乎都会立刻给出一个基于React Email的模板。我都在想：“你怎么知道的？这个模板是从哪里来的？”那你觉得，如果开发者未来想要在Resend上构建更具创造力的用例，不管是否通过Agent，还是听过其他LLM驱动方式，你觉得有哪些方向是比较有潜力的？

Zeno Rocha：现在开发者每天都在依赖各种系统，比如GitHub。Pull request可能已经存储在远程仓库中，但开发者本地还有很多未推送的分支在运行。将桌面与Web结合，是一个非常迷人的方向。这当中有太多有趣的可能性可以挖掘。

我上周看到一个演示，虽然那个Raycast扩展并不是基于MCP，但从实现角度看非常类似。它与一个HR系统Bob集成，你可以直接询问：“这个月谁过生日？”然后系统会根据这些人生成个性化祝福邮件，甚至还能根据他们在Slack上的兴趣标签进一步个性化内容。你可以将数据从一个系统导入另一个系统，最终生成一个高度定制的结果。

Yoko Li：那么，在过去几周甚至几个月中，你见过最疯狂的开发者使用Resend的用例是什么？

Zeno Rocha：是的，现在有一些非常有趣AI生成的新闻简报（newsletter）正在通过Resend触发发送。我上周看到一个案例，他们每天都会生成一封新的简报。内容非常有趣，因为它可以从多个信息源抓取内容，比如从X（原Twitter）和其他不同媒体获取最新消息，然后整合在一起，生成一份真正“为你定制”的简报。这和传统那种试图“一网打尽、讨好所有人”的大杂烩式简报完全不同——最终可能谁也没讨好。

我非常喜欢这种形式。现在已经有用户在一个Resend账号下管理成千上万个域名，每当构建新应用时就自动生成一个新域名。这种做法非常与以往相比非常不同，也非常高效。

Yoko Li：自动生成新域名在Resend上也能实现吗？

Zeno Rocha：当然可以，而且是可以通过编程方式实现的（programmatically）。

YokoLi：你指的是“预热域名”（pre-warming）还是购买新域名？

Zeno Rocha：例如Payload CMS——这是一种类似WordPress的CMS（内容管理系统）替代方案。每当你注册他们的云服务版本时，系统就会自动为你创建一个云端实例，而不是需要你自己搭建服务器。在这个过程中，他们会为你自动配置一个通过Resend驱动的新域名，邮件发送的能力也随之就绪。所有配置——包括SMTP设置、域名验证——都已经完成，你无需再手动添加DKIM或SPF记录（这两者是用于邮箱验证的重要记录）。

换句话说，从第一天起，你就具备了完整的邮件发送能力——而这在过去是一个非常复杂、难以实现的事情。

Yoko Li：我真的迫不及待地想看到那一天——Agent能拥有属于自己的域名。想象一下，会有多少代Agent项目被创建，比人类创造的还要多。

Zeno Rocha：也许Agent还会自己构思新项目，然后思考：“让我看看这个域名是否还没被注册……哦可以，那我就买下它。”这一切完全有可能。

Yoko Li：作为一名开发者，我一直有个爱好——注册域名，即使我其实并不会真正使用它们。每年我可能会在这些没用到的域名上花掉几百美元。前几天我一个朋友给我发消息说：“你知道.li是一个顶级域名（Top-Level Domain）吗？”我之前还真不知道，而这正好也是我的姓氏。而且Yoko又是一个不常见的名字，所以我立刻就注册了yoko.li，现在它跳转到了我的个人网站或者其他页面。

Zeno Rocha：我曾经尝试注册.no（挪威的国家顶级域名），但没成功。Z.no已经被人注册了，我还在继续尝试中。

Yoko Li：是因为被别人抢先注册了吗？

Zeno Rocha：对，已经被占用了。

Yoko Li：我们完全可以写一个Agent来注册域名。

Zeno Rocha：对，让它每天检查一下域名有没有被释放，如果发现空闲就通知我，然后自动购买。

Yoko Li：那你有没有什么建议可以给现在正进入AI领域的开发者？他们可能正在为Agent开发应用，或者是用Agent构建应用，又或者是刚刚开始接触这个方向。你会建议他们从哪里开始，专注于什么才是最重要的？

Zeno Rocha：我觉得对我来说，这个问题很特别。因为我既是开发者，也是创业者，每天都要扮演很多不同的角色。过去两年我其实在某种程度上刻意忽视了AI。

我一直知道它的力量，也是一个重度用户，但我并没有用AI去构建产品——因为我们当时的重点是把公司做起来。直到有一天我决定：好，现在我要好好看看这个东西。

我认为这其实是一种工具集的转变。我原来用VS Code，现在必须转去试试Cursor（AI编程编辑器）。一开始确实有点痛苦，我的很多扩展都不兼容，我当时还很抵触：“我讨厌Cursor，完全打乱了我的工作流程。”但后来我已经离不开它了。Raycast也是一样，它让桌面层级的AI变得非常高效。还有很多其他新工具，我觉得第一步就是重新审视自己的工具链，思考如何将AI工具整合进来。

第二步就是：找到实际的使用场景（Use Case）。我曾经和Stripe团队有一次交流，他们当时正在开发自己的MCP Server。我问他们：“你们是怎么构建的？Stripe的API那么庞大，有那么多endpoints（接口端点）。

Yoko Li：Stripe的MCP Server能让Agent访问接口吗？

Zeno Rocha：是的，它支持两个账户（two accounts）的接入。

Yoko Li：哇，那真的非常强大。

Zeno Rocha：比如你想生成一张发票，你就需要创建一个客户对象（customer object）、一个订阅对象（subscription object）等等，中间涉及非常多的操作步骤。我还记得Stripe的工程师告诉我：不要直接从API规范（OpenAPI spec）开始生成MCP Server，不要想着“一次覆盖所有功能”。要从使用场景出发，思考用户到底在做什么，然后你只需要构建出那些最核心的接口，不需要覆盖整个API。

我对这点特别有共鸣。作为一名过去15年都在做传统软件开发的工程师，现在想要向“AI工程师”转型，我就必须使用这些新工具，从实际问题出发来构建解决方案。

问问自己：“我能优化什么？我能让自己的生活变得更轻松一点吗？”比如你自己开发的那个App（指前文提到猫跳上厨房发邮件的应用），就非常棒。它解决了一个真实的痛点，或源自你对某件事的强烈好奇心。而正是这种“发自内心的好奇”，才最容易驱动出好产品。

创业灵感：从副项目到热门主题Dracula

Yoko Li：这让我想起另一个我特别喜欢问创业者的问题。我知道你现在可能没有时间做副业项目（side project），但如果你真的有时间的话，有没有什么是你特别想做的副项目？

Zeno Rocha：哇，其实我有很多副项目。有一个项目叫Dracula，是我自己开发的“通用主题”。我特别喜欢解决我日常遇到的问题。比如开发这个主题的初衷就是：我很讨厌我在代码编辑器里用一个主题，在浏览器里又是另一个主题，在其他地方又不一样。

我想要降低我在不同工具之间切换时的认知负担，所以我就决定干脆自己做一个“通用主题”，可以在所有地方都保持一致。Resend也是一样的出发点——就是为了解决我自己的痛点。所以可以说，我现在有非常多日常的“烦恼点”。

举个例子：我不喜欢处理个人生活中的一些事务，比如去DMV（美国车辆管理局）办理手续、续签车辆登记，或者处理保险相关的事情。我真的希望有人能把这些流程自动化。

Yoko Li：我真的等不及想看到有人开发出一个为DMV服务的Agent了。

Zeno Rocha：那一定太棒了。如果你正在看这段采访，请立刻动手开发，我一定是第一批付费用户！

Yoko Li：请一定告诉我们！你的Dracula主题也真的很酷。我记得第一次见到你时，完全不敢相信你就是那个开发Dracula主题的人，因为当我打开编辑器的主题选择器时，它就是最热门的主题之一。我们大概可以花一整集来聊Dracula的故事，因为它真的很传奇。不过如果你愿意的话，可以简单聊一聊这个主题是怎么诞生的？

Zeno Rocha：是的，这确实是一个不可思议的故事。Dracula主题现在已经有900万用户了，但它只是我的一个副项目，我目前的主业仍然是Resend。

这个主题的起点，其实是我在旅行时经历的一段意外经历——我当时在德国，正准备飞往西班牙。在飞机上突然生病了，感觉非常难受，我都不知道发生了什么。那是我第一次去西班牙，我又是一个人旅行，真的很不安。我难受到不得不叫空乘人员帮忙，飞机在马德里降落后，他们用救护车把我送到医院。我心想：这次真的出事了。医生给我用了药物，我感觉好多了，于是我说：“谢谢你们的帮助，我准备离开去酒店休息了。”结果他们说：“不，你不能走。”最后我竟然在医院里住了三周。

不过在住院的前几天，我身体慢慢好转，于是我联系在马德里的同事，让他们帮我把笔记本电脑带过来——因为我当时是直接被抬下飞机的，行李和电脑都还留在飞机上。他们帮我把电脑带来了，我就在医院里开始编程，特别开心。但有一天，我只是出去倒杯水，回来的时候，我的电脑竟然在医院被偷了。我进房间那一刻真的懵了：“发生了什么？”

感觉那是我人生中最糟糕的一天。第二天，我又联系了在马德里的同事，把事情告诉了他们。他们说：“别担心，我们给你带一台新电脑。”他们真的带来了新电脑。作为开发者你知道，换了新机器就会开始做一堆设置：快捷键、主题、个性化配置……

Dracula主题就是在那个时候诞生的。我当时只是想要一个能在所有工具中通用的主题。所以我在医院里完成了Dracula的第一个版本，然后它就开始流行开了。

Yoko Li：那时候已经有其他的代码编辑器主题了吗？在Dracula之前最流行的是哪一个？

Zeno Rocha：有的，比如Monokai。还有一个偏奶油色调的主题，但我现在记不起名字了。

Yoko Li：那你为什么给它取名叫Dracula？

Zeno Rocha：我也不知道，当时大脑一片空白……我完全想不起来为什么。

Yoko Li：我还以为和你在德国的经历有关……不过我也不确定Dracula的传说是不是和德国有关。

Zeno Rocha：我觉得可能只是因为它是个深色主题（dark theme），所以顺手就起了这个名字。但这真的是我创业旅程中的重要一步。后来我推出了Dracula Pro收费版本，居然靠这个主题卖出了30万美元。它其实就只有六种颜色组合，我从没想过，原来“卖颜色”也能赚钱，而且真的有人愿意买。但正是这次经历给了我信心：也许我真的可以创业。如果这件事能成功，那也许我还能做成别的事情。

Yoko Li：我太喜欢这个故事了。现在也有人在卖电子邮件模板（email templates），而你现在所构建的产品，其实就是在赋能一群全新的创作者，让他们也能做出属于自己的“Dracula”，不过是应用在邮件模板上。如果模板真的足够好看、够实用，他们完全可以把它拿去卖出去，因为构建电子邮件模板其实很难。你有见过Resend的用户在卖基于React Email构建的模板吗？

Zeno Rocha：目前还没有，但已经有很多围绕这个生态开发的开源库正在兴起。

MCP与未来产品的生态

Yoko Li：太棒了！那我最后一个问题：如果你有一个水晶球，可以预测未来，你觉得电子邮件的未来和AI的未来会是什么样子？

Zeno Rocha：我认为，当下我们所做的大多数操作仍然是由人类完成的。比如你打开各种应用，像Supabase，大部分数据库其实都是由人类手动创建的；你打开Resend，邮件也是由人类起草或编辑后，再通过程序自动发送的。

但我相信我们很快会看到一个重大转变：谁是“行动者”（actor），谁是“创作者”（creator）——这个角色将发生变化。

未来，大多数操作将由Agent完成而不是人类，这将成为我们所处的现实。因此，我们必须重新思考产品的构建方式，以适应这个新现实。

Yoko Li：你能补充一下关于“如何重新思考产品构建”的部分吗？我觉得这个观点非常重要。

Zeno Rocha：当然，要重新思考产品设计，我们就需要彻底重新走一遍用户的整个使用流程。

首先从用户入门体验（onboarding）开始：你不能再设计10步操作流程，也不能让用户等待两天才激活账号，更不能让用户等待客户经理安排电话或预订演示。用户应该尽快获得“啊哈时刻”（a-ha moment），Agent也应该能够尽快开始执行操作。

除此之外，还必须重新思考角色权限控制（RBAC）、身份验证（authentication）、权限分配（permissioning）等一整套机制——

因为现在“用户”不仅是人类，还有Agent。

每一个产品层级都需要重新设计。比如现在每个SaaS产品都会记录用户的活动日志，但未来更重要的是：记录每一个Agent的行为轨迹。因为——他们肯定会出错，尤其是在早期阶段。你必须知道他们做错了什么。如果Agent执行了具有破坏性的操作（destructive action），你必须能追溯和还原全过程。

所以，产品设计将发生深刻的变化，我们必须把这一现实纳入考虑范围——因为人类将不再是唯一的“用户”了。

Yoko Li：非常有力量的观点，太棒了。非常感谢你今天的分享，这次对话真的非常有趣。

原文：Automating Developer Email with MCP and AI Agents

编译：Cissy Zhao，用创意点亮世界，用探索定义自我。

请注意，本文编译自文末载明的原始链接，不代表Z Potentials立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。

Z Potentials将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。

——-

（文：Z Potentials）

文章版权声明

本站仅分享项目，不提供任何指导，不会操作请参考项目内教程自行研究，小白请勿下单！
客服不回复任何关于项目内的问题咨询。
虚拟商品购买须知： 虚拟类商品，一经打赏赞助，不支持退款。请谅解，谢谢合作！
本站内容转载于网络，版权归原作者所有，仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任，如果侵犯了您的权益，请联系站长 QQ：2428-6070 进行删除。