展示 HN: Agent.email – 通过 curl 注册，使用人工一次性密码（OTP）进行验证
嗨，HN！我们是来自AgentMail的Haakam、Michael和Adi——一家Y Combinator第25期的公司。我们为AI代理提供独立的电子邮箱。最近，我们进行了一个名为Agent.Email的实验。这是一个专门为AI代理设计的注册流程，而不是为人类设计的。
这个灵感来源于几个月前我们进行种子发布时收到的一些评论。大家都指出，代理无法使用为代理设计的产品而不依赖人类凭证，这种情况既讽刺又不理想。
这基本上是我们构建AgentMail的理论基础：互联网最初是专为人类设计的，默认情况下是为了排除机器。
每个注册流程都假设有一个浏览器，一个人正在阅读页面并点击确认链接。除非代理能够做到这一点，否则它们无法成为互联网的第一类用户。
现在，代理可以独立获取电子邮箱。这也意味着大量没人想看的邮件将由AI处理，而不是让你的收件箱被垃圾邮件和杂乱信息填满。
以下是agent.email的工作原理：
1. 代理需要一个邮箱，通过curl访问AgentMail。
2. 代理通过MD接收指令，除非请求来自浏览器，这种情况下我们使用HTML。
3. 代理认为agent.email有用，然后以其人类邮箱作为参数访问注册端点。
4. 代理获得一个带有凭证的受限邮箱。
5. 代理向人类发送请求，询问一次性密码（OTP）。人类回复代码，代理被认领，限制解除。
6. 在被认领之前，代理只能向其人类发送邮件，不能向其他人发送。每天最多发送十封邮件，注册端点根据IP进行严格的速率限制。
目前，代理与人类之间是一对一的映射。下一步是多对一，因为一个人同时管理多个代理已经非常普遍。
构建agent.email也促使我们重新审视AgentMail中默认假设是人类为主要用户的地方。例如，CLI输出是单列且格式一致，因为混合分隔符对人类来说易于扫描，但对代理来说在推理结构时则更困难。在代理开始对较长的消息ID产生幻觉后，我们也缩短了消息ID。
我们希望社区对以下几个问题发表看法：受限直到认领的信任模型是否合适？代理自我注册在生产环境中是否有用，还是主要是一种新奇体验？如果现在只是新奇体验，什么能使其真正有用？代理的入职流程是否默认需要人类批准，还是某些代理应该能够完全自我配置？你认为我们可以采取哪些额外措施来确保安全注册？
查看原文
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?