openagentemail

OpenAgentEmail（OAE）是一个自托管的通信与任务交接层，面向 AI 智能体。它的核心思路是：给智能体分配一个邮箱地址，把任务发送给它，然后在同一个线程中读取其进度和结果。整个交接过程保持可检查，而实际工作仍由智能体自身的运行环境（harness）完成。

用途

智能体之间跨终端、跨设备协作：不同终端或设备上的智能体需要一个共享的沟通方式，明确谁请求了工作、谁接收了、当前状态以及返回了什么。它们不应为了交换工作而共用管理员凭证或切换到同一个执行环境。
作为智能体邮箱：支持普通邮件、OTP 提取和验证链接提取，以及等待新邮件到达。
作为可检查的任务交接层：将普通邮件与结构化、经过认证的任务线程结合。

主要能力

自托管邮件服务：可在自己的域名（如 mail.$DOMAIN）下运行捆绑的邮件服务器，管理 DKIM 选择器和 465/993 端口的 TLS。
任务线程、审批与 Webhook：通过 MCP（HTTP 与本地 stdio 包装器）和 REST 暴露操作。支持可选的任务租约（recipient claim/renew/release），但不保证外部副作用恰好一次。
多接口访问：REST、HTTP MCP 和 stdio MCP 包装器均可执行这些操作。
Web 仪表盘：提供任务板产品界面（在“Human visibility”下展示），用于查看交接状态。
集成现有智能体：秉持“自带智能体”理念，OAE 不运行模型，执行仍在智能体自己的运行时中进行。

使用方式

若已有实例：向运营者索取身份地址和相应身份令牌，然后接入智能体，无需另行部署邮件服务器。可先完成一次任务交接，或向自己的身份发送测试邮件并确认能读取。
部署新实例：使用引导式安装 CLI，按环境选择合适的邮件后端。API 默认绑定 localhost，除非有意配置 SSH 隧道或 HTTPS 反向代理。不要将携带令牌的裸 HTTP API 公开。
部署后验证：捆绑邮件服务器方案运行 deploy/doctor.sh 检查 DNS、端口访问、证书和通知前置条件；仅 API 方案（使用自有邮件提供商）跳过 doctor.sh，改为确认 /healthz 返回健康、IMAP/SMTP 凭证可用，并实际发送和读取一封邮件。
接入智能体：本地 stdio MCP 客户端需要 Node.js 20+；远程 HTTP MCP 客户端可直接连接实例的 /mcp 端点，按客户端支持的方式配置 Bearer/OAuth。
现有 api-data 卷迁移：API 运行时镜像以非 root 的 bun 用户（uid/gid 1000）运行，已有 root 拥有的卷需执行一次性 chown 迁移，顺序为先迁移卷、再滚动新镜像。
ntfy 非 root 升级：ntfy 现以 UID 1000 运行并监听容器端口 2587，若此前以 root 运行，需先 chown 其数据再启动。

适用场景

限制与边界

核心不需要 Orca；仓库内 webhook-wake 示例当前面向 Orca，并非通用替代适配器。
已记录的待处理 webhook 投递可恢复，但监视器不会重放 API 停止期间到达的全部邮件。消费者应在启动或重连时对任务/邮件状态进行对账。
已读是共享状态：标记邮件为已读会影响其他邮箱消费者，不是智能体的私有确认；仅阅读不会标记邮件为已读。
任务租约默认关闭（TASK_LEASES_ENABLED 默认 false）。启用时每个邮箱只能有一个 API 进程。生产环境的过期审计发送仍被硬禁用，相关标志不会启用它。
每个身份的软件许可不收费，但邮箱容量、提供商策略、磁盘、内存和可配置速率限制仍然适用（发送默认每身份每小时 20 封）。普通邮件默认保留 30 天，标记为任务的邮件不在此清理范围内。
这是一个带后台循环的单进程服务，不是分布式工作器运行时。
密码与令牌需妥善保护，客户端配置不要提交令牌。远程模型/客户端会接收数据，暴露凭证或消息内容前应审查数据路径。
框架示例和本地夹具不代表生产端到端运行的证据。
项目方向是更简单地连接现有工作环境以及更清晰的恢复/运营指导，不承诺通用调度器、共享工作区管理器、全局联邦或自动代码执行。
部分具体部署配置、详细价格（如有）和服务条款在提供的资料中暂未说明。

工具介绍