从邮件投递到代理入口：Resend 如何扩展产品能力

一、嘉宾背景

Zeno Rocha 是 Resend 创始人、Dracula 主题创建者，也是开源开发者。在 Latent Space 这场约86分钟的访谈中，主持人 Alessio Fanelli 与 Shawn swyx Wang 和他讨论了从前端开发进入邮件基础设施、再扩展到代理入口的产品路径。Rocha 自述，创办 Resend 前使用过多种邮件服务，却没有搭建邮件流水线的经验。他从成熟市场中看到了改善开发者体验的机会，最初的构想是做“邮件领域的 Stripe”。

他对免费层和多语言 SDK 的投入，也与个人经历有关。Rocha 说，自己在巴西使用过性能较差的电脑和网络，因此不愿只服务拥有好设备、好连接的开发者。团队对 SDK 生成方案不满意后，选择人工编写多个语言版本。这些选择体现了他对不同使用条件的关注，但访谈没有给出各项投入的商业回报。

创业的持续性是他谈及的另一个变化。参加 YC Winter 2023 时，Rocha 的女儿约一岁。他起初想争当批次第一，后来逐渐把重点转向如何持续创业。他用未来亲子关系和公司规模的假设表达个人优先级，同时承认父亲、丈夫与 CEO 的角色仍存在冲突。这些取舍解释了他的判断背景，工作与家庭之间的矛盾并未因此消失。

二、本期主要内容

当用户从代理入口开始工作，邮件平台需要提供哪些能力？这个问题贯穿了访谈。Rocha 称，录制当天 Resend 服务约430万用户，客户包括独立开发者、Warner Brothers 和 HBO。这些规模与客户信息来自他的口述，也构成了讨论简单接入、大规模发送和企业需求的背景。

React Email 的出现晚于 Resend。Resend 启动后的用户研究暴露了模板制作的痛点，团队才据此开发这款开源工具。Rocha 主动为 SendGrid、Mailchimp、Mailgun 编写集成文档，让用户即使不使用 Resend，也能先解决模板问题，再连接后续的发送需求。React Email 主要通过 JSX 模板与编译处理表格布局、内联 CSS 和 Outlook 兼容，并支持 TypeScript 与 Tailwind tokens。访谈明确，它没有把 React 状态或 JavaScript 交互带进邮件。

基础设施则从现成服务逐步向底层延伸。Resend 初期使用 AWS SES，优先投入 SDK 和开发者体验；随着域名组织、configuration sets 等限制显现，团队开始建设更底层的能力。Rocha 指出，SES 之外还需要事件、日志、队列和 webhook 配套。他描述了团队正在自建的 IP 池、按邮箱服务商控制吞吐的机制，以及与服务商关系的维护。发送路径也已从 JavaScript 改用 Go，重点优化 p99。访谈没有量化这些改动最终带来的改善，不能据此比较改造前后的投递表现或延迟。

Rocha 用“formless”描述多入口产品的目标：用户应能从不同地方调用产品能力。他称 MCP 后期每月至少翻倍，所述8月约有120万次调用。这些数字反映使用量，并非任务成功率。代理入口之外，可视化编辑仍承担着协作需求：营销人员可以维护模板，工程侧传入模板 ID 和变量；团队也可以把模板纳入源码管理。他还提到，约20人曾共同编辑一封全员会邮件。不同入口对应着不同的工作方式。

企业销售与接收邮件是另外两条扩展方向。主持人描述 Resend 约有50名全球远程员工，Rocha 则说企业销售刚刚起步。他强调，企业客户需要不同的产品，仅增加 SSO、SCIM 和审计日志不足以完成企业化。他还透露了可编程收件箱的计划，包括创建、读取、已读、星标和标签等 API。这项产品在访谈时仍待推出，尚不能视为现有能力。

三、核心观点：推理、例子与边界

邮件平台的责任并不止于接收发送请求。Gmail、Outlook、Yahoo Mail 各有规则，大批邮件需要排队、分批，并按服务商调整发送速度。Rocha 说，早期收件人的打开、归档或删除行为会影响后续接收，因此可以优先向互动更积极的受众发送。加上 IP 历史检查与池管理，平台能力便不能只用服务器吞吐量衡量。这是 Rocha 对实际运营的解释，访谈没有独立验证各家邮箱的判断机制。

低摩擦注册把一部分复杂性留给了平台。Resend 默认信任注册用户，发现退信率、投诉率或服务商反馈异常后迅速阻断，再通过沟通区分误用与恶意滥用。Rocha 提到一个使用约2万个域名的日本团伙，并列出新域名、网站状态、仿冒域名和突发群发等风险信号。开放接入因此需要持续检测，但这些信号本身并不能证明恶意。他称多数情况属于误用，阻断之后的解释与恢复也就成了产品责任的一部分。

远程 MCP 将类似的问题带到了代理接口。最早的本地版本由 a16z 的 Yoko 构建；推出正式远程版本时，Resend 需要补建 OAuth、重新审查用户对资源的访问权限、配置监控，并争取官方市场分发。平台必须明确代理代表谁、能访问哪些资源，以及如何发现运行中的问题。主持人主张用 headless 后端服务多个客户端。Rocha 则回顾了现有架构的负担：Next.js API 曾因费用压力迁移至 Node，私有和公共 API 又需要重复维护；monorepo 改善了代码复用，却没有消除两套接口的维护成本。新入口能复用多少能力，仍取决于后端实际共享到了哪一层。

工具数量也无法代替任务完成度。Rocha 说，MCP 工具从约20个或更少增至80多个后，团队更关注返回数据过大，以及账单、邀请、账户创建和删除等长尾操作。他自己用 MCP 编写投资者更新，但这个使用实例不能代表系统性的任务成功率。其他增长指标也有各自的边界：他称 Resend SDK 的 npm 下载量超过 SendGrid 两倍，同时承认 SendGrid 的实际发送量更大；主持人提到 Claude Code 推荐 Resend 的比例超过60%，却没有提供样本或方法。下载量、推荐比例和调用量分别反映不同环节，不能单独证明市场份额或工作质量。

AEO 的讨论同样需要区分信息可读性、回答准确性与推荐效果。Resend 建设框架长尾文档、FAQ、llms.txt 和 Markdown 页面，并把 JavaScript 图表中的数据写成文本，首先解决的是模型能否直接读取信息。Rocha 说，模型曾算错发送120万封邮件的费用，团队补充定价页 Markdown 后，数日后再次提问得到了正确答案。这是一次回答改善的经验，尚不能证明推荐增加，也无法排除其他变化。主持人质疑这些工作的分发效果，网页与 Markdown 的一致性维护也仍有成本。这三个结果需要分别验证。

设计差异化与发送速度也应按各自的证据判断。Rocha 承认融资材料可能过度打磨，但仍坚持产品身份与设计差异化；访谈没有证明这些选择直接带来了增长。主持人则认为，下一代或“AI 原生 SendGrid”仍以既有产品为参照，尚不等于创造了新品类。发送速度受另一组条件约束：营销邮件需要批次、间隔、动态调速和按域名限速。Rocha 说，向所述430万用户发送邮件需要超过一天；“10万封十分钟”是主持人的假设，两者不能拼成性能标准。他也认为，快速增长的客户会给联系人计费带来问题。定价单位、发送量与调度能力之间存在联系，却不能相互替代。

四、学习与应用

开发者工具团队可以从完整任务入手检查代理能力。参照 Resend 遇到的长尾问题，沿着读取用量、处理账单、邀请成员或结束账户等真实流程，逐步检查授权、返回数据和失败处理。如果关键步骤仍需要用户返回仪表盘，就应明确这一边界。打通高价值任务比追求工具总数更能反映产品进展；增加可执行能力时，也需要同步处理资源权限。

支持工作既可以积累可复用的答案，也可以推动产品消除反复出现的问题。Resend 要求支持答复附上文档或知识库链接，缺少文章就先补写。Rocha 举例说，首次处理可能因此耗时约1.5小时，之后便可复用。这种做法适合重复出现、答案相对稳定的问题，代价是首次响应更慢。DNS 是他所说的主要支持问题：用户需要理解记录并找到正确的粘贴位置，Domain Connect 则可以通过登录授权减少手动配置。不过，供应商接入、协议维护和收费仍有阻力，不受支持的用户依然需要清晰的配置路径。文档能承接问题，也应帮助团队识别哪些操作值得直接改进。

评估邮件服务时，需要同时考虑发送能力、信誉管理和测量方式。Rocha 所述的内置检查与自动纯文本生成，可以作为产品默认值的候选；他声称纯文本有助于投递，却没有量化效果，采用后仍需观察实际结果。打开追踪依赖透明像素，隐私保护和预读会削弱打开率的可信度，因此打开率不能直接等同于真实阅读。共享追踪域名还可能受到其他客户滥用的影响，也应纳入供应商评估。事务邮件与营销邮件可以参考访谈中的做法，用子域和邮件流区分；另购相似域名却可能看起来像钓鱼，不能把换域名当作通用修复方式。

内容团队可以先收集实际问题，检查模型能否正确读取定价规则、比较条件与图表数据，再评估推荐效果。将内容转成便于模型读取的文本时，也要安排网页与 Markdown 的一致性维护。一次复问得到正确答案，只能支持这次回答有所改善的结论。主持人介绍的 Latent Space 与 AIE 的 CMO agent 实验，则提供了一套组织后续行动的流程：接入数据和代码，保留历史记录，提出假设，由人审批并设定实验窗口，再执行、监控和反馈。这能让建议进入可检验的实验，但对话没有证明任何具体营销措施已经有效。

降低接入门槛还需要考虑失败会影响谁。Rocha 对匿名使用、provisioning 和 claims 仍有滥用顾虑，因为邮件滥用可能波及其他发送者。团队可以先界定适合开放的有限任务，以及所需的身份或额度约束，再评估后续开放范围。AEO 工具也需要接受类似的行动检验：Rocha 说，团队订阅了四款此类工具，最缺的仍是行动建议；主持人认为这些工具偏重报告，同时承认自己不是专家。报告可以帮助提出问题，具体行动是否值得执行，仍需结合成本与结果判断。

来源

• 原始节目：Designing for Agents — Zeno Rocha, Resend