我们为每个智能体提供了真实的电子邮件地址。以下是所有出现问题的细节。

我们在 Truespar 构建智能体工具，这源于我们自己的产品。今天我们将整个项目开源了，所以我显然不是中立的。仓库名称在底部，由于子版块过滤链接，本帖中没有链接，其余部分是问题描述。可送达性是最昂贵的问题。阅读邮件的智能体很容易，但回复邮件的智能体则是一个邮件服务器问题，而邮件服务器会因与你代码无关的事情惩罚你。反向 DNS 必须匹配，并且只有你的托管提供商才能设置 PTR 记录。在 AWS、GCP、Azure 和 Hetzner 上，出站端口 25 默认是阻止的。而且回复必须由声称的域名进行 DKIM 签名，否则 DMARC 会失败，一个完美编写的回复会落入垃圾邮件。这里的模型从不重要。你最好的回答会进入垃圾邮件，因为 PTR 记录指向一个 2019 年的主机名。线程处理就是一个头部问题，基本上每个人都搞错了。如果你不将 In-Reply-To 设置为入站 Message-ID，Gmail 会为每个回复开启一个新对话，客户会看到来自机器人的五封独立邮件，而不是一个线程。两个机器人绝对会永远互相交谈。一个外出自动回复器回复了你的智能体，你的智能体很乐于助人并回复回去，这会一直持续直到有人注意到。防护措施已经在头部中，如 Auto-Submitted、List-Id 和 Precedence。在允许智能体回复任何内容之前，请检查它们。真正让我害怕的是地址重用。我们假设一旦智能体被删除，slug 就会再次可用。然后有人回复了一个四个月前的线程，邮件到达了一个现在属于不同客户的地址。我们在暂存环境中发现了它，没有人受到伤害，但现在地址对我们来说是只追加的。当智能体停止时，你退役它的 slug 并保留其退役状态。公开发布是第一天，但服务器不是，我们去年用自己的电子邮件基础设施替换了它，并且自那以后一直在生产环境中运行我们的邮件。版本是 0.1.4，两天内四次发布修复的大部分内容是我们自己的安装说明在干净的机器上失败的问题。它在 GitHub 上 truespar 下，仓库名为 sentio，如果你想试试的话。Rust 编写，双重 MIT 和 Apache-2.0 许可证，自托管，需要 Postgres 18、Redis、NATS 和 S3。我主要好奇地址重用的问题是否也困扰过其他人，或者我们是否对此特别聪明。