让智能体读懂并用好 API 的产品实践

被 Claude Code 推荐，只是开发者工具进入项目的第一步。Resend 的案例讨论了后面的路：智能体能否读懂价格、找到合适的工具、处理调用结果，最终让邮件可靠送达。任何一环卡住，推荐都可能变成一次失败的集成。

对前端和全栈开发者，这篇值得看的地方，是它把「面向智能体设计产品」拆成了可以检查的具体问题。但推荐次数能否代表产品优势、工具越多是否越好，原文都没有给出足够证据，需要分开判断。

被模型推荐，离进入代码库还有多远

原文引用的一项研究提取了 102 次 Claude Code 邮件服务推荐：Resend 有 64 次位列首选，SendGrid 位列首选 7 次，作为备选出现 55 次。

首选位置可能影响 SDK 的采用。如果开发者直接接受智能体生成的代码，备选服务可能根本不会进入评估流程。但原文没有提供实际安装量或迁移数据，不能把推荐次数直接当成采用率。

另一项覆盖更多模型的答案引擎优化（AEO）研究中，Postmark 在多数模型里领先。两项研究呈现不同结果，说明推荐表现依赖具体模型与场景，不能据此宣布某个服务全面胜出。

Resend 的另一个切入口更具体：先用 React Email 解决邮件模板难写的问题。开发者可以继续通过 SendGrid 发信，团队还提供了相关文档。

这条路径降低了首次接触产品的门槛：开发者不用先迁移服务，就能把团队的工具用进项目。至于它带来了多少后续转化，原文没有给出数据。

智能体需要读得懂的信息，也需要装得下的结果

Resend 的定价页允许人拖动滑块，查看不同发送量对应的价格。智能体获取这类信息时，交互控件可能增加读取成本。

团队为页面提供了 .md 版本，把价格整理成表格，让智能体一次请求就能读取。它解决的是明确的信息访问问题，不能保证模型因此更愿意推荐 Resend。

工具设计也有类似区别。访谈录制时，Resend 的 MCP 服务器已从上线初期约 20 个或更少的工具，扩展到 80 多个。Zeno 希望用户在聊天客户端里完成控制台中的操作，包括发信、邀请成员、检查用量和管理账单。

Cloudflare 的 Code Mode 则提供另一种入口：通过 search() 和 execute() 两个工具暴露 API 能力。

哪种更好？原文没有对照数据。它提供了一个更值得检查的现象：Zeno 展开会话中折叠的工具调用时，发现一次返回结果太大，无法装入上下文窗口。

工具数量与返回内容大小，是两个需要分别检查的问题。

把 80 多个工具压缩成两个，并不会自动让返回结果变小。评估 MCP 时，除了看工具列表，还要读一次真实调用的输出，确认智能体究竟拿到了什么。

调用成功以后，底层服务仍然决定体验

邮件服务返回成功，不代表用户已经顺利完成任务。投递是否正常、收件人能否安全访问链接，仍然取决于服务本身。

原文以点击追踪为例：服务商可以把邮件链接改写到共享追踪域名，统计点击行为。如果某个客户利用该域名实施钓鱼，域名被拦截，其他客户的合法链接也可能受到影响。

Zeno 解释了 Resend 引入自定义追踪域名的考虑，也表示即使免费套餐可能被垃圾邮件发送者滥用，仍希望保留免费层。不过，原文没有展开其反滥用机制，也没有给出自定义域名改善投递或访问成功率的数据。

这部分提醒开发者：智能体选对 SDK、调用对 API，仍然需要可靠的服务承接结果。

我的判断

我认同这篇把关注点从推荐排名移到任务完成过程。相比只追问模型是否提到产品，检查价格是否可读、工具输出是否可处理，更容易发现具体问题，也更容易验证修改是否有效。

但 Resend 的做法还不能直接当作通用答案。React Email 的入口适合有明确模板痛点的邮件场景；80 多个工具承载的是覆盖控制台的目标；免费层则涉及增长与滥用治理的取舍。一般团队未必需要同样的覆盖范围。

search()、execute() 与大量专用工具如何选择，也不能只比数量。原文没有提供任务成功率、延迟或上下文消耗的对照，这部分应当视为实践思路，而非已经验证的优劣结论。

能拿来做什么

• 在前端或 Node 项目接入邮件服务前，把智能体的推荐当作候选起点，继续核对价格、模板适配和追踪域名需求，不要仅凭首选位置决定 SDK。
• 如果你维护开发者工具，可以检查价格页和文档是否依赖交互才能获取关键信息，再考虑提供结构清楚的 Markdown 或表格版本。
• 调试 MCP 时，展开一次真实工具调用，同时检查工具选择与返回内容大小。遇到上下文装不下的问题，先定位具体输出，再决定是否调整工具入口。
• 用 AI 实现邮件功能后，继续检查实际投递和链接访问。API 调用成功，只能证明流程完成了其中一步。