Resend 如何让编码 Agent 选用其 API
内容以 Resend 为例，探讨面向答案引擎的优化与 Agent 使用体验之间的边界。讨论涵盖帮助 Claude Code 选择邮件 API 的文档，以及 Agent 实际发送邮件所用的工具。
AI 深度解读
Agent 为什么总推荐 Resend，即使开发者已经在用 Cloudflare？Latent Space 这次访谈给出的解释，不只关乎模型听说过谁。Resend 把入口铺到了 React 邮件模板、机器可读的价格页和 MCP 工具，再把邮件送达、域名信誉这些麻烦事接起来。
对做开发者工具的团队，这是一条值得拆解的获客路径；对前端和全栈开发者，它也提醒我们：Agent 的首选供应商有形成原因，但首选不等于最适合你的项目。
Agent 的第一推荐，究竟有多大价值
原文引用的一项 AEO 研究，从 Claude Code 的回答中提取出 102 次邮件服务推荐，Resend 有 64 次排第一。SendGrid 只有 7 次居首，却有 55 次出现在备选里。
差别在于开发流程：如果开发者让 Agent 实现邮件功能，接受补丁后就继续开发，第二名可能根本没有进入实际比较。
但这个结果不能直接理解为 Resend 已经稳定领先。Latent Space 随后提到，他们更新、更全面的研究竞争更激烈，Postmark 在多数模型中居首。原文没有展开两次研究的完整方法，也没有提供推荐最终转化为付费的对照数据。
Resend 联合创始人兼 CEO Zeno Rocha 从 2024 年开始讨论 AEO，从 2025 年 2 月开始讨论 Agent Experience。前者关心产品怎样被 AI 答案推荐，后者关心 Agent 能否顺畅理解和操作产品。被推荐只是入口，能完成任务才有机会留下来。
录制时，Zeno 称 Resend 有 430 万用户、12 万付费客户。这能说明业务规模，不能证明增长主要来自 AEO。
在模型推荐之前，先进入开发者的仓库
Resend 最早有效的分发入口，是 React Email。
他们团队开发邮件发送 API 时，反复听到开发者抱怨邮件样式难做，于是先发布模板工具。开发者可以用 React Email 写模板，再通过 SendGrid 发送，团队还专门提供了对应文档。
这一步降低了采用门槛：不用先更换供应商，也能解决眼前的问题。等开发者需要其他邮件服务时，Resend 相关代码已经进入仓库。对前端读者来说，这比单纯投放品牌信息更容易理解：先让一个组件或工具参与日常开发，再争取后续服务选择。
面向 Agent，价格页采用了类似思路。人可以拖动滑块查看不同用量的价格，Agent 却未必容易读懂这种交互。Resend 允许在价格页 URL 后添加 .md，一次请求就能拿到表格。
这里真正可以借鉴的，不是给网页统一加个后缀，而是检查机器能否直接拿到决策依据。价格、额度和限制如果只藏在交互里，即使模型知道产品名字，也可能无法可靠回答用户的问题。
MCP 工具多，不代表任务就好完成
录制时，Resend 的 MCP server 已从上线时约 20 个或更少的工具，扩展到 80 多个。目标是让聊天客户端里的用户，也能完成控制台中的操作。
发送邮件只是开头。邀请成员、查询用量、管理账单，才会把产品带进持续使用的工作流。
原文同时给出另一种设计：Cloudflare 的 Code Mode server 通过 search() 和 execute() 两个工具暴露 API。两条路线放在一起，恰好说明工具数量不能单独作为体验指标。
Zeno 会展开自己会话中折叠的工具调用，检查 Agent 实际拿到了什么。有一次，返回结果大到无法装进上下文。减少工具数量，并不会自动缩小这次调用的返回值。
设计 MCP 时，工具怎么选和结果怎么返回，需要分别处理。
而工具调用成功之后，邮件服务还得处理真实投递风险。例如，共享点击追踪域名会把不同客户的链接放到同一域名下；一个客户用它钓鱼并导致域名被封，其他客户的正常邮件也可能受影响。Resend 因此引入自定义追踪域名。原文还提到其 300 万美元安全承诺，但没有展开资金使用和效果数据。
Zeno 希望保留免费层，同时承认垃圾邮件发送者也能注册。低门槛获客与反滥用成本，需要一起承担。
我的判断
我认可这套路径里最具体的部分：React Email 先解决模板问题，价格页提供机器可读内容，MCP 延伸到日常管理操作。这些改动都有明确的任务对象，团队可以逐项验证。
但把它们直接归因为「赢得模型推荐的秘诀」，证据还不够。原文没有给出改造前后的推荐变化，也没有隔离品牌知名度、文档覆盖和模型差异的影响。目前更适合把它当作有参考价值的产品经验。
一般团队也未必需要复制 80 多个 MCP 工具。对已有 SDK、CLI 的产品，应先确认用户需要在聊天中完成哪些操作，再决定工具边界。原文没有提供这几种入口的效率对照，不能据此宣布 MCP 更优。
Resend 的经历还提醒我们，推荐优势不能替代供应商评估。尤其是邮件服务，接入顺手与投递可靠，是两道都要过的关。
能拿来做什么
- 给前端或 Node 项目接入邮件时，让 Agent 同时列出首选和备选的价格、用量限制及域名配置要求，并核对依据，再接受接入补丁。
- 如果你维护开发者工具，检查价格和额度是否能脱离滑块等交互直接读取；优先补上结构清晰、可被机器获取的信息。
- 如果你在开发 MCP server，展开一次常用调用的完整返回值，逐项确认哪些字段服务于当前任务，先处理无用数据占据上下文的问题。
- 使用点击追踪前，确认链接经过哪个域名、是否支持自定义追踪域名，以及共享域名信誉受损时会影响哪些邮件。