为 AI 智能体设计——Zeno Rocha，ResendDesigning for Agents — Zeno Rocha, Resend

播出信息

• 日期：2026-11-10
• 时长：5152 秒（约 85 分 52 秒）
• 嘉宾：Zeno Rocha，Resend 创始人
• 音频：收听节目
• YouTube：观看视频
• Episode：节目页面
• 英文转写来源：youtube-captions；本篇依据所提供转写整理，其中一段内容缺失，相关判断见「争议与需核实」。

背景

Zeno Rocha 此前以 Dracula 配色主题等开发者作品为人熟知，后来创办邮件基础设施公司 Resend。他并非邮件系统出身，而是从前端开发者的体验切入：既有服务能发邮件，却很少让开发者觉得接入、制作模板和排查问题足够顺手。Resend 因而从 React Email、SDK、文档和发送 API 建立入口，再逐步面对邮件行业更难的部分：反滥用、域名声誉、收件箱规则与底层投递。

本集还有一层值得注意的关系：主持人开场说明自己是 Resend 的天使投资人。因此，关于产品采用率、竞争优势和未来计划的讨论兼具一手经验与利益相关者视角。

总结分析

这集的主线，是一家以「开发者体验」进入成熟市场的公司，如何发现体验最终必须由复杂基础设施兑现。Rocha 起初不愿让新用户填表、等待人工审核；规模扩大后，他承认传统邮件服务这样做并非没有原因——钓鱼邮件、异常域名和突发群发会伤害整个平台的信誉。Resend 的选择不是放弃低门槛，而是把筛查、限速、反馈监测和教育尽量放进产品内部，让正常用户少承担预防滥用的成本。

智能体改变了这套产品的入口。主持人的编程工具即使面对已有邮件配置，仍推荐接入 Resend；Rocha 则把文档、FAQ、Markdown 页面与定价说明当作机器需要读取和判断的产品界面。不过，谈话并未证明某一种 AEO 技巧能稳定带来推荐。更有说服力的例子是：当定价只藏在交互式页面里，模型曾算错；补充可读取的文字后，他在后续测试中得到正确结果。这说明「被找到」与「被准确理解」是两个不同目标。

与此同时，Resend 正从依赖 AWS SES 的上层开发者体验，向自管 IP 池和发送路径深入，以争取吞吐、可观测性与控制权。但自建底层会增加运营难度，SDK 下载超过竞品也不等于发送规模领先。节目最后把取舍落到创始人本人：Rocha 坚持设计品质，也明确不愿以失去与女儿的亲密关系换取更高收入。所谓「为智能体设计」，在本集里并非单一功能，而是对产品入口、可信基础设施和公司边界的重新安排。

节目结构 / 议程

1. 送达率不是单纯的扩容题 — 06:54 🎧 · ▶️
2. 打开率、点击率与默认信任 — 13:28 🎧 · ▶️
3. 支持规模化与 DNS 难题 — 19:43 🎧 · ▶️
4. React Email：先解决模板，再承接发送 — 23:54 🎧 · ▶️
5. SDK 下载超过竞品，意味着什么 — 27:00 🎧 · ▶️
6. 从 AWS SES 上层走向自管发送栈 — 31:57 🎧 · ▶️
7. MCP：智能体入口需要产品级设计 — 37:54 🎧 · ▶️
8. CLI 与手工打磨的 SDK — 46:28 🎧 · ▶️
9. 从入站邮件走向智能体邮箱 — 52:40 🎧 · ▶️
10. 让机器准确读懂价格与产品 — 58:27 🎧 · ▶️
11. 推荐竞争与企业销售的边界 — 65:59 🎧 · ▶️
12. 创业目标与品类命名 — 76:50 🎧 · ▶️

分节详解

1) 送达率不是单纯的扩容题 — 06:54 🎧 · ▶️

💬 他们说了什么：Rocha 说，给 10 万人发信不能把 10 万封邮件同时推向 Gmail。服务商需要分批排队、控制不同收件服务商的发送速度，并管理 IP 池与信誉。新域名、仿冒域名和短时间爆发式发送都是风险信号；他举出一次约 2 万个域名涌入平台的可疑案例。

💡 为什么重要：邮件的扩容目标不是「尽快把请求处理完」，而是在接收方持续观察发送行为的条件下，稳定获得投递机会。把高参与度收件人排在前面，是他描述的投递策略之一。

⚡ 争议点：批次排序和参与度信号的效果，会随收件服务商政策、邮件类别与收件人行为变化；访谈没有给出可独立验证的实验数据，不宜把这套做法当成通用保证。

2) 打开率、点击率与默认信任 — 13:28 🎧 · ▶️

💬 打开追踪通常依赖一张 1×1 像素的透明图片，但隐私保护和邮件预读取会削弱「图片被加载＝真人打开」的推断。点击追踪也有代价：若链接被改写到共享追踪域名，一个滥用者可能拖累其他客户。Rocha 主张新用户默认可用，再根据退信、投诉和收件服务商反馈迅速干预。

💡 这将体验问题转成了风险分配问题：减少正常用户的注册阻力，意味着平台必须更早、更准确地区分误用与恶意使用。

⚡ 默认信任并不等于没有审核；它只是把审核更多移到使用过程中。过快封禁可能伤及新手，过慢则可能损害共享基础设施。

3) 支持规模化与 DNS 难题 — 19:43 🎧 · ▶️

💬 Resend 曾要求客服回复工单前先写出可引用的文档，再把链接发给用户；首个回复可能因此花约 一个半小时，但知识可以复用。如今大量问题仍集中在 DNS：用户不会配置 CNAME、A 或 TXT 记录。Rocha 介绍了可简化域名配置的 Domain Connect，并谈到争取更多 DNS 服务商支持的困难。

💡 支持工作的效率，不只是缩短单张工单的处理时间，更是降低同类工单未来出现的频率。随着新一代建站工具带来更多非传统开发者，原本可被视为「基础知识」的 DNS 配置，成为核心接入体验。

⚡ 强制「先写文档、后回复」并非所有紧急问题都适用；Domain Connect 也受服务商覆盖和合作进度约束，不能替代全部手动排错。

4) React Email：先解决模板，再承接发送 — 23:54 🎧 · ▶️

💬 团队先做 Resend，再在用户研究中发现邮件模板制作本身很痛苦，于是推出 React Email。它让开发者用熟悉的组件和类型系统制作模板，处理邮件 HTML、内联 CSS 与 Outlook 兼容性；文档还介绍如何配合竞争对手的发送服务使用。

💡 开放工具先解决旅程前段的真实问题，随后才在「模板做好了，去哪里发送」处引出 Resend。这比把开源项目仅当作广告入口更有说服力。

⚡ 这里的 React 主要承担模板生成，而非浏览器式交互；Rocha 明确说邮件中不能发送 JavaScript。开发者不应把 React Email 理解成可在收件箱运行的交互应用。

5) SDK 下载超过竞品，意味着什么 — 27:00 🎧 · ▶️

💬 Rocha 称 Resend 的 SDK 下载量在当年超过 SendGrid，访谈时已达后者的 两倍以上；但他随即承认，SendGrid 的邮件发送量仍明显更大，因为其拥有大型企业客户。他也转述 Mailgun 创始人对抗滥用研发负担的警告。

💡 SDK 下载更接近开发者试用与采用的前置信号；发送量则更接近实际业务规模。两者同时看，才能理解新产品与成熟服务商各自的优势。

⚡ 节目未提供下载统计口径、时间窗口及排除自动化下载的方法。「超过下载量」不能直接推出收入、客户数或市场份额领先；关于竞品组织投入的说法也属于受访者转述。

6) 从 AWS SES 上层走向自管发送栈 — 31:57 🎧 · ▶️

💬 Resend 起初使用 AWS SES 承担底层发送，自己重点建设 SDK 和开发者体验。Rocha 说，SES 的标价之外，还须考虑 SNS 事件、CloudWatch 日志、SQS 队列及 Webhook 等配套。团队如今正投入数月建设更底层的发送能力，包括购买和管理 IP 段、控制面向各收件服务商的吞吐；发送路径也已从 JavaScript 转向 Go。

💡 上层封装让公司较快验证需求；达到一定规模后，底层控制权才可能转化为更好的性能、可观测性和差异化。这是一条由产品需求推动的下探路径，而非一开始就全面自建。

⚡ Rocha 谈到的进一步自建项目当时尚待公布，成效不能预先视为既定事实。自管 IP 与投递关系也会带来新的维护成本和风险。

7) MCP：智能体入口需要产品级设计 — 37:54 🎧 · ▶️

💬 官方章节将这一段标为「Designing the MCP」。在现有转写的后续部分，Rocha 与主持人把 MCP、CLI、SDK、可视化编辑器并列为不同产品界面；智能体不只是替人点击网页，也可能通过工具接口直接完成操作。

💡 当操作发起者从人扩展到智能体，「接口好用」不仅是字段和调用方式清楚，还涉及工具是否容易被发现、动作是否可理解，以及执行结果能否被检查。

⚡ 所提供转写恰在这一章节附近出现大段缺失，无法据此还原 Resend MCP 的具体工具设计、权限安排或演示结果。本节只讨论可以从章节名与后续谈话确认的产品方向。

8) CLI 与手工打磨的 SDK — 46:28 🎧 · ▶️

💬 Rocha 甚至允许求职者通过 CLI 或 API 申请职位，并把愿意完成安装、认证和操作流程的人视作值得特别留意的候选者。他说团队评估过 SDK 自动生成方案，但对生成结果不满意，因此选择为不同语言手工制作 SDK；即使某语言用户相对很少，他也希望其体验足够好。

💡 这体现了 Resend 对「开发者体验」的宽定义：用户所在的语言、终端和网络条件，都属于产品的一部分，而不只是网页版控制台的美观程度。

⚡ 手工维护多语言 SDK 的成本会随接口和语言数量上升；CLI 求职流程也可能筛出喜欢折腾工具的人，却不一定准确预测岗位表现。

9) 从入站邮件走向智能体邮箱 — 52:40 🎧 · ▶️

💬 Rocha 表示，团队正研究以编程方式创建大量邮箱，并在基础入站能力之上提供读取、已读标记、加星和标签等 API；他以「需要 100 个邮箱」说明可能的使用场景。这是访谈时正在准备的产品方向，而非已由节目证实全面上线的服务。

💡 若智能体需要分别接收、分类和处理邮件，传统「一个人打开一个邮箱」的界面就不再是唯一抽象；邮箱可能成为可创建、可授权、可编排的资源。

⚡ 大量自动创建邮箱会放大身份、滥用、访问控制和数据保留问题。功能方向明确，但具体安全边界与商业需求仍须以正式产品信息核实。

10) 让机器准确读懂价格与产品 — 58:27 🎧 · ▶️

💬 团队从长尾使用场景文档、FAQ，扩展到 llms.txt 和网页的 Markdown 版本。Rocha 曾问模型：发送 120 万封邮件时几家服务商哪家便宜？模型把 Resend 价格算错，还评价其定价不透明。他于是给价格页补上机器较易读取的文字；数天后复测，模型给出了正确数字。

💡 动态计算器对人方便，却不保证抓取和比较流程能执行它。把关键规则明确写成文本，首先改善的是信息准确性，而非必然提高推荐排名。

⚡ 这是一项受访者描述的前后测试，并未控制模型版本、抓取更新和提问差异。他也承认，页面与 Markdown 版本并存会带来内容同步负担。

11) 推荐竞争与企业销售的边界 — 65:59 🎧 · ▶️

💬 主持人称其使用的编程工具经常推荐 Resend，并提到某项观察中推荐比例超过 60%；Rocha 将较新的工具受到关注、社区自然讨论及可读文档视为可能因素，但也说团队仍在试验。谈到商业化时，他表示公司约有 50 名分布式成员，企业销售动作才刚起步；企业客户需要的不只是给价格页加上单点登录、审计日志等功能条目。

💡 模型的一次回答可能直接缩小开发者的候选名单；然而被推荐之后，企业采购仍要求另一套产品、支持与组织能力。自助采用和企业销售并非同一条漏斗的简单放大。

⚡ 推荐比例缺少测试方法和样本说明，不能推及所有模型或使用场景。Rocha 对「近期内容更容易被推荐」的观察，也不构成稳定的排名规律。

12) 创业目标与品类命名 — 76:50 🎧 · ▶️

💬 Rocha 回忆参加 YC 2023 年冬季批次时，曾被提醒过于重视设计；他仍认为设计是拥挤市场中的差异点。谈到家庭，他设想十年后宁愿拥有一家 1000 万美元 ARR、且女儿仍愿意与自己亲近的公司，也不愿以疏远关系换取 1 亿美元规模。结尾主持人进一步区分了「在现有品类中占优势」与「创造一个让人听见便理解的新类别」。

💡 这不是把野心与家庭简单对立，而是先明确成功的约束条件。同样，Resend 能成为新一代邮件工具，并不自动意味着它已发明一套新的行业语言。

⚡ 家庭与营收的对比是 Rocha 的价值选择，不是企业经营的普适公式；他也坦言，自己仍常感到难以同时做好 CEO、父亲和丈夫。品类能否真正建立，最终取决于市场是否自发采用其名称，而非公司如何自称。

人物与机构

• Zeno Rocha：Resend 创始人；以 Dracula 配色主题等开发者作品为人熟知。本集主要受访者。
• Resend：面向开发者的邮件平台。本集中讨论了发送、入站邮件、模板、SDK、CLI，以及正在探索的智能体邮箱能力。
• React Email：与 Resend 关联的开源邮件模板工具，使用开发者熟悉的组件方式生成邮件内容。
• SendGrid、Mailgun、Postmark：访谈中反复出现的成熟邮件服务商，也是 Resend 判断市场机会和比较采用情况时的参照。
• AWS SES：Resend 早期所使用的底层邮件发送服务；访谈借此讨论上层体验与底层控制权的取舍。
• Gmail、Outlook、Yahoo Mail、Apple：邮件接收侧的重要参与者；各自的规则与隐私处理会影响投递和追踪判断。
• 主持人：节目采访者；开场披露自己是 Resend 的天使投资人，并分享编程工具推荐 Resend 的个人经历。

金句

「你需要做的，恰好是滥用者不会做的事。」 —— Rocha 谈稳定发送节奏与域名信誉；据英文转写意译。

「我们默认信任你；但一发现异常，就会很快拦下并与你沟通。」 —— Rocha 谈低门槛接入与事后风控；据英文转写意译。

「我宁愿生活在一家年经常性收入一千万美元、女儿还想和我玩的公司里。」 —— Rocha 谈创业与家庭的取舍；据英文转写意译。

洞见与延伸背景

1. 「可供机器读取」应从关键事实开始。 对价格、限额、步骤和安全条件，提供明确文字比单纯增加页面格式更直接；否则智能体可能找到产品，却在关键决策上理解错误。
2. 客服知识库也是产品界面。 先沉淀答案、再回复工单的做法，实际上把重复支持成本转成了可检索资料；资料同时可能服务用户、搜索和智能体，但仍需维护时效。
3. 送达率是一种多方协调结果。 发件平台能控制队列和风险策略，却不能单方面决定 Gmail 等接收方如何分类邮件。因此，「已发送」「被接收」「进入主收件箱」应分开理解。
4. 智能体邮箱会让权限模型前移。 当邮箱可以批量创建并由程序读取时，谁能创建、谁能查看、何时撤销访问，不再是附属管理选项，而是产品设计的核心问题。

争议与需核实

• 转写缺口：所提供英文材料在约 37 分钟至 47 分钟之间出现省略；MCP 章节的具体内容不能仅凭本材料复原。若需技术实现细节，应回听对应音视频。
• 规模口径：Rocha 在开场及访谈中称 Resend 服务约 430 万用户、超过 12 万付费客户；这些属于受访者在节目中的陈述，本文未独立审计其定义与时间口径。
• 推荐率与采用比较：「推荐超过 60%」及 SDK 下载超过 SendGrid 的说法，均缺少公开于本转写中的完整测量方法；不能直接解释成整体市场领先。
• 即将推出的能力：更底层的发送基础设施和批量邮箱产品在访谈时仍被描述为开发或准备发布中，当前可用范围应以正式产品说明为准。
• 定价页实验：补充可读取文本后模型答对价格，是一个值得复现的案例；单次前后变化不足以确定是哪项改动产生作用。
• 名称与数字：英文自动字幕存在人名、品牌和金额识别错误的迹象；涉及专有名称或精确财务判断时，应优先核对音频及机构原始资料。

行动建议

• 运营邮件产品的团队：分别监测发送成功、退信、投诉和实际收件体验；不要把打开率当作唯一的送达指标。
• 设计智能体工具的团队：用真实任务测试「发现工具—理解权限—执行操作—核对结果」的完整链路，而不只测试一次 API 调用。
• 维护产品网站的团队：挑选价格、限额和接入步骤，让模型实际回答用户问题；对答错之处补充清晰文字，再重复测试并记录版本。
• 采用开源入口的团队：先解决独立成立的用户痛点，再明确它如何自然衔接付费产品；避免把工具做成只能通向自家服务的演示。
• 评估基础设施自建的团队：同时计算现有服务的配套系统成本，以及自管 IP、风控、性能和故障处理带来的新负担。

来源

• 节目页面：Designing for Agents — Zeno Rocha, Resend
• 节目音频
• YouTube 视频
• 英文转写：用户提供的 youtube-captions 文本；议程时间采用所给官方章节。