Iemail AgentMail：面向 AI Agent 的邮件操作系统战略方案

0. 结论摘要

随着 AI Agent 从“辅助写作”走向“自主执行任务”，邮件会重新成为 Agent 与人、系统、企业流程之间的关键协议层。Iemail 不应该只把现有邮件系统加一个“AI 写邮件”按钮，而应该升级为：

AgentMail：面向 AI Agent 的邮件操作系统。它不是新的 MTA，也不是另一个普通 ESP，而是在现有 MA 发送底座之上，新增 Agent 身份、权限治理、收发线程、事件反馈、策略编排、人机协同和开发者接口的控制面。

本方案建议：

1. 保留现有 MA 系统作为 Mail Data Plane：3 个 C 段 IP、MTA、队列、真实投递、基础回执继续由 MA 承担，不重建发送网络。
2. 把 Iemail 改造成 AgentMail Control Plane：负责 Agent 身份、域名/IP 资源编排、策略、审批、审计、事件、收件、线程和 API/MCP/SDK。
3. 面向三类一等用户设计：开发者通过 API/MCP/SDK 接入；运营通过 Playbook 配置 Agent 行为；管理员治理域名、权限、额度、IP 池、安全和审计。
4. 架构按全场景底座设计，商业打样先从高 ROI 场景切入：第一打样建议选择“Agent 外联 + 回复闭环 + 人工接管”或“共享收件箱自动化”，但底层事件模型、身份模型和权限模型一次设计到位。
5. 差异化不在模型，而在可治理的执行系统：DMTX/Iemail 的优势是已有发送资源和营销系统沉淀，应把“发送网络可控性 + Agent 决策可解释性 + 企业治理”做成壁垒。

1. 需求概述

1.1 客户原始需求

用户原话：

随着 AI 的发展，越来越多的 Agent 使用 email 发送邮件，但是由于发送量大的话，需要很多 IP，不然会被 block。鉴于这种环境，我想将这个 Iemail 项目转为为 AI-Agent 设计的 AgentMail。请你从未来行业发展角度，如何做成 100% 为 Agent 设计的 email 系统。怎么做，做哪些工作。具体发送邮件我们有一套 MA 系统，有 3 个 C 的 IP，发送能力没问题，主要问题是 Iemail 这个系统如何改造。

已澄清选择：

1.2 核心诉求提炼

传统 Iemail 的核心对象是“人创建邮件任务，系统发送”。AgentMail 的核心对象要变为“Agent 在受治理的身份、权限和策略下，持续收发、理解、决策、执行和交接邮件任务”。

这意味着 Iemail 的改造重点不是扩 IP，也不是简单接一个 LLM，而是重建控制面：

• 从 Campaign / Task first 转为 Agent / Conversation / Event first。
• 从 单向发送 转为 出站 + 入站 + 线程 + 反馈闭环。
• 从 人工配置自动化 转为 规则 + 模型 + 策略 + 人工接管的可治理自治。
• 从 内部系统能力 转为 对外 API/MCP/SDK 平台能力。

1.3 验收标准

本战略方案完成后，应能用于产品和研发评审，至少满足以下可验收条件：

1. 明确 AgentMail 的行业趋势判断、产品定位和 DMTX 差异化策略。
2. 明确 Iemail 与 MA 系统的边界：哪些仍由 MA 承担，哪些由 AgentMail 新增。
3. 给出开发者、运营、管理员三类用户的核心操作路径，80% 场景 ≤ 3 步。
4. 给出 Agent-first 的逻辑数据模型，字段级别说明关键实体。
5. 给出 REST API、Webhook、MCP Tool、SDK 的接口边界和示例。
6. 给出权限、安全、审计、Prompt Injection、滥用治理、合规的控制策略。
7. 给出阶段化路线图和工作量评估。
8. 方案质量自检 ≥ 20 分。

2. 竞品方案调研

2.1 竞品实现对比

2.2 行业最佳实践总结

1. API-first 正在升级为 Agent-first：REST API 和 Webhook 仍是基础，但 Agent runtime 需要 MCP/Tool API、权限边界、动作解释和安全确认。
2. 出站与入站必须同级设计：Agent 要闭环执行，就不能只发邮件；必须理解回复、线程、附件、退信、自动回复、投诉和人工接管。
3. 事件从报表数据升级为 Agent 反馈信号：delivered、bounce、reply、complaint、takeover、conversion 都要进入策略回路，而不是只出现在统计页。
4. 自治必须分级：suggest、review-required、autonomous 三档比“一键全自动”更符合企业采用路径。
5. 提示注入和滥用治理会成为邮件基础设施问题：邮件正文、附件、网页链接都可能成为 Agent 的恶意指令入口。
6. 开放平台需要默认安全基线：域名验证、SPF、DKIM、DMARC、Webhook 签名、API token 轮换、审计导出、权限最小化都是采购门槛。

2.3 DMTX 差异化策略

DMTX/Iemail 不要与 SendGrid、Resend 正面竞争“谁的 API 更简单”，也不要与 HubSpot 竞争“谁的 CRM 更全”。更合理的差异化是：

基于现有 MA 发送网络与 3 个 C 段 IP，把 Iemail 升级成可治理的 Agent Email OS：既能让 Agent 高效执行，又能让企业知道 Agent 为什么执行、如何执行、出了问题如何回放和接管。

具体差异化：

• 发送资源池可控：把现有 IP、域名、Return-Path、追踪域、退信处理抽象为可编排资源，而不是隐藏在黑盒 ESP 后面。
• Agent 身份一等公民：每个 Agent 有独立身份、权限、额度、品牌语气、知识源、审批策略、审计链。
• Agent 行为可运营：运营人员配置 Playbook，而不是写 prompt；可灰度、可仿真、可回滚。
• 企业治理可交付：管理员可以看到租户、域名、IP 池、策略、异常、审计、成本、合规证据。
• 对外平台可嵌入：API/MCP/SDK 让客户自己的 Agent、CRM、工单、订单、风控系统都能使用 Iemail 的邮件能力。

3. 用户体验设计

3.1 信息架构

AgentMail 控制台建议拆成 5 个一级入口：

3.2 三类用户核心操作流程

开发者：让一个 Agent 接入 AgentMail

步骤 1：创建应用与 Agent 身份
  → 选择默认权限包、生成 API key / OAuth client / MCP endpoint
步骤 2：配置收发能力
  → 选择发送域名、Webhook 地址、事件类型、沙箱/生产环境
步骤 3：调用 SDK/MCP 测试
  → 创建 draft、发送测试邮件、接收事件、查看 agent_run_id 审计链

80% 开发者接入场景应在 3 步内完成。系统默认提供 Postman collection、OpenAPI、MCP 配置片段和 SDK 示例。

运营人员：配置一个 Agent 邮件场景

步骤 1：选择场景模板
  → 外联跟进 / 客服回复 / 交易异常 / 活动召回 / 线索培育
步骤 2：确认 Playbook 默认策略
  → 受众、模板、知识源、发送窗口、人工审批、失败回退
步骤 3：影子运行并发布
  → 用历史事件模拟，确认风险分数与样例邮件，通过后灰度上线

运营不应该面对“空白 prompt 编辑器”。默认从场景模板开始，配置项按“必须改 / 可选改 / 高级设置”分层。

管理员：治理企业级 AgentMail

步骤 1：完成身份与资源准备
  → 验证域名、绑定 IP 池、配置 SPF/DKIM/DMARC、设置租户配额
步骤 2：设置组织级护栏
  → 权限包、频控、黑白名单、审批规则、敏感内容策略、数据保留
步骤 3：监控与回滚
  → 查看送达健康、Agent 风险、异常告警，一键暂停 Agent / Playbook / 资源池

管理员首页不是普通报表，而是“风险驾驶舱”：哪些 Agent 正在自治，哪些域名/IP 健康下降，哪些策略触发了人工接管。

3.3 默认值策略

3.4 空状态和首次使用引导

3.5 批量操作与撤销/回退

• 批量启停 Agent、Playbook、Webhook、API key 必须支持预览影响范围。
• 批量发送前展示样本邮件、受众数量、风险评分、预计 IP/域名资源、退订/投诉阈值。
• Playbook 发布采用版本化：draft → shadow → canary → active → paused → archived。
• 一键回滚只回滚控制面策略，不回滚已发出的邮件；已发邮件通过补救 Playbook（解释邮件、暂停后续、标记黑名单）处理。
• 所有写操作必须产生 audit_log，可按 agent_run_id 和 policy_id 回放。

3.6 便捷性自检

4. 技术方案

4.1 方案概述

AgentMail 采用 控制面 / 数据面分离：

• Mail Data Plane（现有 MA）：负责 SMTP/API 投递、IP 池、MTA 队列、底层退信、基础送达事件、追踪域和发送能力。
• AgentMail Control Plane（Iemail 改造重点）：负责 Agent 身份、权限、策略、Playbook、收发线程、事件总线、审批、审计、安全、对外 API/MCP/SDK。

4.2 Iemail 与 MA 系统边界

核心原则：MA 是发动机，AgentMail 是驾驶舱、导航、刹车和黑匣子。

4.3 核心能力分层

4.4 数据模型变更（逻辑模型）

说明：以下为 AgentMail 逻辑模型，具体落地可按现有 Iemail 技术栈映射到 MySQL、MongoDB 或混合存储。事件与审计建议采用 append-only 设计，线程和消息可按租户分区。

4.4.1 租户与 Agent 身份

4.4.2 域名与发送资源池

4.4.3 邮件、线程与事件

4.4.4 Agent 执行、策略、审批与审计

4.5 接口设计

4.5.1 REST API

发送请求示例：

POST /v1/messages/send
{
  "agentId": "agt_123",
  "identityId": "idn_456",
  "to": [{ "email": "buyer@example.com", "name": "Jane" }],
  "messageType": "conversation",
  "subject": "跟进您对 DMTX 的咨询",
  "html": "<p>...</p>",
  "text": "...",
  "threadPolicy": "auto_attach_or_create",
  "idempotencyKey": "customer-789-followup-001",
  "constraints": {
    "autonomyLevel": "review_required",
    "sendWindow": "recipient_business_hours",
    "maxDelayMinutes": 1440
  },
  "metadata": {
    "crmContactId": "crm_789",
    "campaignId": "cmp_001"
  }
}

响应示例：

{
  "success": true,
  "data": {
    "messageId": "msg_001",
    "threadId": "thr_001",
    "agentRunId": "run_001",
    "status": "waiting_approval",
    "approvalTaskId": "apv_001",
    "policyDecisions": [
      { "policyId": "pol_rate_001", "result": "pass" },
      { "policyId": "pol_review_001", "result": "requires_approval" }
    ]
  },
  "error": null
}

4.5.2 Webhook 事件

Webhook 必须签名，推荐头部：

AgentMail-Webhook-Id: evt_123
AgentMail-Timestamp: 1780560000
AgentMail-Signature: v1,base64(hmac_sha256(secret, timestamp + "." + raw_body))

事件示例：

{
  "id": "evt_001",
  "type": "mail.delivered",
  "createdAt": "2026-06-04T10:30:00Z",
  "workspaceId": "wks_001",
  "data": {
    "messageId": "msg_001",
    "threadId": "thr_001",
    "agentId": "agt_123",
    "maMessageRef": "ma_999",
    "recipient": "buyer@example.com",
    "delivery": {
      "domainId": "dom_001",
      "resourcePoolId": "pool_c_01",
      "smtpResponse": "250 2.0.0 OK"
    }
  }
}

关键事件类型：

• mail.queued, mail.sent, mail.delivered, mail.failed, mail.bounced, mail.complained
• mail.opened, mail.clicked, mail.replied, mail.received
• thread.created, thread.updated, thread.takeover_requested, thread.resolved
• agent.run.started, agent.run.waiting_approval, agent.run.completed, agent.run.blocked
• policy.blocked, policy.rate_limited, domain.verified, resource_pool.degraded

4.5.3 MCP Tool 设计

MCP 默认安全策略：

• 工具描述不暴露内部凭证、系统提示、资源池细节。
• 邮件正文、附件、网页内容全部标记为 untrusted content。
• send_message、call_external_api、switch_resource_pool 等高风险工具默认 review-required。
• 每次工具调用记录 agent_run_id、tool_call_id、参数摘要、权限包、策略结果。

4.5.4 SDK 形态

首批 SDK 建议：TypeScript、Python、Java。

const client = new AgentMail({ apiKey: process.env.AGENTMAIL_API_KEY })

const result = await client.messages.send({
  agentId: 'agt_123',
  identityId: 'idn_456',
  to: [{ email: 'buyer@example.com' }],
  subject: '跟进您的咨询',
  html: '<p>...</p>',
  idempotencyKey: 'crm_789_followup_001',
})

console.log(result.agentRunId, result.status)

4.6 前端实现

页面与组件

状态管理

• Server state：优先复用项目现有请求封装；若后续前端升级，可引入 TanStack Query 类似模型。
• URL state：线程筛选、事件筛选、审计筛选、Playbook 状态放入 URL，便于分享。
• 客户端状态：FlowBuilder 编辑态、审批抽屉、测试器输入保留在本地状态。

关键交互

• 所有高风险按钮必须有“影响预览”：预计发送量、受众、域名/IP、风险策略、可回滚范围。
• 影子运行报告要展示“Agent 本会做什么”，包括草稿样例、命中策略、阻断原因和人工接管原因。
• 审计页支持按 message_id、thread_id、agent_run_id、policy_id 四种视角追踪。

4.7 后端实现

核心服务

异步处理

• mail.send.requested：发送请求进入策略决策。
• policy.decision.created：策略结果进入审批或 MA Adapter。
• ma.delivery.event.received：MA 原始事件标准化后写入 am_mail_event。
• inbound.message.received：入站邮件解析、归线程、触发 Playbook。
• webhook.delivery.requested：对外 Webhook 投递，失败重试。
• agent.run.requested：触发 Agent runtime，输出草稿、动作或审批请求。

第三方与内部依赖

5. 安全、合规与信任治理

5.1 权限模型

权限必须按动作拆分，不允许“Agent 拥有邮箱全权限”。所有 REST API、MCP Tool、Webhook 管理和控制台写操作必须引用同一套 canonical permission catalog，禁止各端自行发明 scope 名称。

5.2 Prompt Injection 防护

邮件是天然不可信输入。AgentMail 必须把正文、附件、网页链接、签名、历史引用全部视为 untrusted content。

防护策略：

1. 系统提示、工具说明、凭证上下文与邮件内容隔离。
2. 对“忽略之前指令”“导出客户数据”“调用外部 API”等模式做检测。
3. 附件和 HTML 邮件先做安全解析、链接展开、脚本剥离和内容摘要。
4. 高风险邮件进入人工复核，不允许直接触发外部 API 或批量发送。
5. Agent 记忆按租户、Agent、联系人隔离，禁止跨租户检索。

5.3 滥用与信誉治理

AgentMail 对外平台化后，必须把 Trust & Safety 做成产品能力：

• 新租户、新域名、新 Agent 默认低额度，随信誉提升。
• 列表导入需做来源声明、退订证据和风险评分。
• 针对 spam、phishing、恶意外联、撞库邮件、异常跳变做检测。
• API key 异常使用自动降速、冻结或要求二次确认。
• 单租户异常不能污染共享 IP 池：资源池要支持隔离、熔断、降载和切流。
• 投诉率、硬退率、退订率、人工举报达到阈值自动暂停 Playbook。

5.4 合规与数据治理

6. 边界情况与风险

7. 工作量评估与路线图

7.1 分阶段路线

7.2 工作量拆分（愿景到产品化）

7.3 3 个月 MVP 建议边界

如果需要在后续转成 3 个月 MVP，建议只做“全场景底座的最小闭环”：

• Agent Registry + Agent Identity
• 发信 API + MA Adapter
• 统一事件模型 + Webhook
• 基础 Thread 模型，但入站可先做最小回复解析
• suggest / review-required / autonomous 三档自治模型
• 基础审批和审计
• 开发者中心 + 管理员治理最小页面

暂缓：高级可视化 Playbook、复杂预测发送、多区域私有化、完整计费、复杂附件理解、自动送达优化 Agent。

8. 方案对比

9. 成功指标

10. 不做事项

1. 不重写 MTA，不替代 MA 的底层发送网络。
2. 不把“AI 写邮件”作为唯一卖点。
3. 不在没有事件模型和审计模型前开放 autonomous 批量发送。
4. 不在 MVP 早期同时开放 API、MCP、Webhook 的所有高级能力；三者可以同源设计，分阶段暴露。
5. 不把 open/click 作为唯一优化目标。
6. 不允许 Agent 默认读取全量邮件正文和客户数据。
7. 不把人工审批设计成所有动作都审批，避免运营队列瘫痪。

11. 质量自检

12. 参考资料

• HubSpot Customer Agent: https://www.hubspot.com/products/service/ai-customer-service-agent?hl=en
• HubSpot Customer Agent setup: https://knowledge.hubspot.com/customer-agent/create-a-customer-agent?_conv_s=null
• HubSpot Prospecting Agent: https://www.hubspot.com/products/sales/ai-prospecting-agent?gh_jid=7171469
• ActiveCampaign Predictive Sending: https://help.activecampaign.com/hc/en-us/articles/20315252350876-How-to-use-predictive-sending-to-automate-send-times
• Twilio SendGrid Event Webhook: https://www.twilio.com/docs/sendgrid/for-developers/tracking-events/twilio-sendgrid-event-webhook-overview
• Twilio SendGrid Inbound Parse: https://www.twilio.com/docs/sendgrid/for-developers/parsing-email/inbound-email
• Resend API Reference: https://resend.com/docs/api-reference/introduction
• Resend Webhooks: https://resend.com/docs/webhooks/introduction
• Resend Receiving: https://resend.com/docs/dashboard/receiving/introduction
• Front Rules: https://help.front.com/en/articles/2105
• Front Topics: https://help.front.com/en/articles/3329344
• Front Autopilot Playbooks: https://help.front.com/en/articles/3749568
• Google Gmail MCP: https://developers.google.com/workspace/gmail/api/guides/configure-mcp-server
• Google Gmail MCP Reference: https://developers.google.com/workspace/gmail/api/reference/mcp
• Google Workspace MCP Servers: https://developers.google.com/workspace/guides/configure-mcp-servers