大多数“人工智能电子邮件”演示都是通过 OAuth 将模型指向人类的邮箱。你连接你的 Gmail，代理读取你的邮件线程，起草回复，甚至可能发送一封。当代理代表你行事时——就像坐在副驾驶座上协助你管理收件箱的 copilots（智能助手）——这没问题。
但当你希望代理成为独立的参与者时，这种模式就会崩溃。想象一下，一个入职代理在每次持续集成运行时都在软件即服务平台上注册你的测试租户；或者一个研究代理需要在数据源上拥有一个开发者账户；又或者一个质量保证机器人为每次测试注册、验证并销毁一个新账户。这些流程都会遇到同样的障碍：服务会发送一封包含验证链接或一次性代码的电子邮件，但没有人类收件箱可以接收它。为此借用你的个人 Gmail 在各个方面都是错误的——安全性、隔离性、清理工作，以及一个简单的现实：你不希望成千上万个一次性注册请求涌入你的真实收件箱。
代理真正需要的是一个它完全控制的、真实的、可一次性使用的邮箱。短暂存在。每次运行独立。在任务开始时配置，在结束时销毁。这正是Nylas 代理账户的本质，也是本文要构建的内容：一个能够自行注册服务并读取其自身验证电子邮件或一次性密码的代理，实现端到端的自动化。
我负责 Nylas 命令行界面工具的工作，因此下面的终端命令正是我常用的命令。我将为每个步骤展示两种视角——原始的 curl HTTP 调用和等效的 nylas 命令行界面命令——因为在实践中，你的代理通过应用程序接口调用服务，但你从终端进行调试。
代理账户究竟是什么
让这一切变得可行的关键在于：代理账户只是一个授权。也就是你已经用于每个通过 OAuth 连接的邮箱的同一个 grant_id 抽象概念。对于它所支持的端点，在数据平面上无需学习任何新内容——一旦你拥有了 grant_id，消息、草稿、线程、文件夹、附件、联系人、日历和事件的功能都与连接的 Gmail 或微软账户完全一致，同时还支持标准的网络钩子。
不过，它并不涵盖授权的全部功能表面，这一点在你围绕它进行设计之前值得了解。智能撰写、模板、工作流、调度器、笔记记录器和自定义元数据在代理账户授权中不受支持。这些对于自主注册来说都无关紧要——接收邮件、阅读正文和解析代码都在受支持的功能范围内——但不要仅仅因为某个端点在 OAuth 授权上有效，就假设它在代理账户上也有效。
区别在于授权是如何创建的。没有 OAuth 交互过程，没有刷新令牌，也没有用户点击“允许”。你向你在 Nylas 注册的域名上的一个电子邮件地址发送 POST 请求，然后你会获得一个由 Nylas 托管的、真实且功能齐全的 name@yourdomain.com 邮箱。对外部世界——对你正在注册的软件即服务而言——它是一个普通的电子邮件地址。它可以接收邮件，拥有真实的邮件交换记录，并且可以回复。该服务并不知道这个邮箱是由机器拥有的。
这种组合使其成为此处合适的工具：
- 无需 OAuth。你无法对背后没有人类的邮箱进行 OAuth 授权。代理账户跳过了整个同意流程。
- 真实可送达的地址。验证电子邮件确实会到达。这不是你自有域名上的通用别名或加号技巧，而是一个一流的邮箱。
- 完全控制。你的应用程序拥有该授权。你通过应用程序接口读取收件箱，无需征求任何人的许可。
-
完成后即可销毁。在运行结束时删除授权，邮箱随之消失。不会积累僵尸
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
