Show HN: Agent.email – 通过 curl 注册，用人工 OTP 领取
21 分•作者: adisingh13•大约 2 个月前
大家好，HN！我们是来自 AgentMail 的 Haakam、Michael 和 Adi，AgentMail 是一家 YC S25 公司。我们为 AI 智能体提供专属的电子邮件收件箱。最近，我们进行了一项名为 Agent.Email 的实验。它是一个专门为 AI 智能体设计的注册流程，而不是为人类设计的。<p>这个想法的灵感来自于几个月前我们进行种子轮发布时收到的一些评论。这些评论都源于一个非常贴切的观察：智能体无法在没有人类凭据的情况下注册为智能体设计的产品的行为，既具有讽刺意味，又不够理想。<p>这基本上就是我们构建 AgentMail 的基础：互联网最初是专门为人类设计的，默认情况下是为了将机器排除在外。<p>每个注册流程都假定有一个浏览器，一个人在阅读页面，并点击确认链接。除非智能体能做到这些，否则它们就无法成为互联网的一流用户。<p>现在，智能体可以自己拥有一个电子邮件收件箱。（这也意味着很多没人想读的邮件会被 AI 处理，而不是让你的收件箱被垃圾邮件和无用信息塞满）<p>以下是 agent.email 的工作原理。<p>智能体需要一个收件箱，并通过 curl 访问 AgentMail。
智能体通过 MD 接收指令，除非请求来自浏览器，在这种情况下，我们使用 HTML。<p>智能体认为 agent.email 很有用，然后使用其人类电子邮件作为参数访问注册端点。
智能体收到一个受限的收件箱和凭据。
智能体向人类发送电子邮件，请求 OTP。人类回复代码，智能体被认领，限制被解除。
在被认领之前，智能体只能向其自己的人类发送电子邮件，而不能向其他人发送。每天 10 封邮件，并且注册端点会根据 IP 进行严格的速率限制。<p>目前，智能体和人类之间是一对一的映射。下一步是多对一，因为一个人同时运行多个智能体已经非常普遍。<p>构建 agent.email 也促使我们重新审视了 AgentMail 中默认假设围绕主要用户是人类的地方。例如，CLI 的输出以单列形式呈现，并具有一致的格式，因为混合分隔符对人类来说很容易扫描，但对于智能体来说，推理结构就比较困难。我们还在智能体开始在较长的 messageID 上产生幻觉补全后缩短了 messageID。<p>我们希望社区对以下几点发表看法：受限-直到-认领 这种信任模型是否正确？
智能体自助注册在生产中是否实用，还是主要是一种新奇事物？如果是新奇事物，什么才能让它真正有用？
智能体的入职是否应该默认需要人类批准，还是应该允许一些智能体完全自助配置？您认为我们还可以采取哪些额外的措施来确保安全注册？
查看原文
Hi HN! We're Haakam, Michael, and Adi from AgentMail- a ycs25 company. We give AI agents their own email inboxes. Recently, we ran an experiment called Agent.Email. It's a signup flow designed specifically for AI agents instead of humans.<p>The inspiration came from a few comments we received when we did our seed launch a few months back. They all came from the very apt observation that agents not being able to sign up to a product made for agents without human credentials was ironic and unideal.<p>This is basically the thesis we built AgentMail on: The internet was made for humans exclusively, designed to keep machines out by default.<p>Every signup flow assumes a browser, a person reading a page, and clicking a confirmation link. Unless agents can't do that, they can't be first class users of the internet.<p>Agents can now get an email inbox by themselves. (This also means a lot of email nobody wants to read gets processed by AI instead of your inbox being cluttered with spam and slop)<p>Here's how agent.email works.<p>Agent needs an inbox and hits AgentMail via curl.
Agent receives instructions via MD unless the request comes from a browser, in which case we use HTML.<p>Agent decides agent.email is useful and then hits the sign-up endpoint with its human email as a parameter.
Agent receives a restricted inbox with credentials.
Agent emails the human asking for an OTP. Human replies with the code, and the agent is claimed and restrictions are lifted.
Until claimed, the agent can only email its own human and nobody else. Ten emails a day, and the signup endpoint is rate-limited hard by IP.<p>Right now it's a 1:1 mapping between agent and human. The next step is many-to-one, because one person running several agents in parallel is already very common.<p>Building agent.email also pushed us to revisit places in AgentMail where the default assumptions were built around the primary user being human. For example, the CLI outputs in a single column with consistent formatting because mixed delimiters are easy for a person to scan, but harder for an agent reasoning about structure. We also shortened messageIDs after agents started hallucinating completions on longer ones.<p>A few things we'd like the community's take on: is restricted-until-claimed the right trust model?
Does agent self-signup feel useful in production, or is it mostly a novelty, and if it's a novelty now, what would make it actually useful?
Should agent onboarding require human approval by default, or should some agents be able to fully self-provision? What do you think are some additional measures we can take for secure sign-ups?