AgentMail Identity：员工 AI 邮件数字分身方案

0. 结论摘要

本方案在上一版“AgentMail 面向 AI Agent 的邮件操作系统”基础上进一步收敛：Iemail 不应只做 Agent 向外发信的控制面，而应升级为 AgentMail Identity —— 给企业中的每个员工/Agent 一个可被组织管理、可收发邮件、可自动回复、可主动协作、可调用工具、可审计追责的邮件身份。

AgentMail Identity Phase 1：员工 AI 邮件数字分身。员工拥有一个透明标识的 Agent 邮箱身份，例如 Jack's Agent <jack-agent@company.com>。它可以自动处理低风险邮件协作，完成问答解释、催办跟进、会议协调、摘要分派；也可以在内部人员和员工自管白名单外部联系人范围内自主判断主动发信。合同财务、权限越界、陌生外部/可疑对象、群发/邮件循环等高风险由管理员配置矩阵进行阻断、降级或审批。

一句话定位：

让每位员工拥有一个可治理的 AI 邮件分身。

本方案建议把 Iemail 的新方向从“邮件发送系统”转为“企业 Agent 邮件身份与协作平台”：

1. 产品心智：从“Agent 帮你发邮件”升级为“你可以给员工的 Agent 发邮件”。
2. 首个 MVP：先做内部员工数字分身，不先做泛客服、外部开发者邮箱 API 或业务系统邮箱入口。
3. 核心能力：邮箱身份、双域地址、收发线程、自动答复+建议、主动发信、白名单、知识检索、风险矩阵、审计追责。
4. 差异化：借鉴 ClawEmail 的“邮箱即 Agent 入口”，但比 Claw 更强调企业组织、员工身份、权限治理、白名单、风险阻断和审计。
5. 落地原则：低风险自动，高风险按类型处理；Agent 可以自主，但必须透明、可控、可审计、可接管。

1. 需求概述

1.1 客户原始需求

用户原话和多轮澄清要点如下：

现在的思路是向外发的，我还有个项目，是给每一个 Agent 一个身份（比如说就是 agent email），这样的话，Iemail 是更宽泛的发送和收取的 AgentAI 的能力。你帮我从这个角度，和我反复沟通下，形成方案。类似这个：https://claw.163.com/

多轮沟通后已确认：

1.2 核心诉求提炼

上一版 AgentMail 方案的重点仍偏“Agent 如何安全规模化向外发邮件”。本次新方向要求把 Iemail 的产品叙事改成：

• 每个 Agent / 员工数字分身有明确邮件身份；
• 邮箱是调用 Agent 的低门槛入口；
• Agent 不仅能发信，也能收信、理解线程、引用知识、给出建议、主动跟进；
• 企业能治理它代表谁、能联系谁、能调用什么工具、何时阻断、如何审计；
• Iemail 从“邮件通道产品”升级成“AgentAI 邮件身份与企业协作底座”。

核心不是“自动回复器”，而是：

Identity 身份
  + Mailbox 收发
  + Conversation 会话
  + Knowledge 知识
  + Tool 工具
  + Policy 策略
  + Risk 风控
  + Audit 审计

1.3 验收标准

本方案完成后，应满足以下评审标准：

1. 能清晰说明 AgentMail Identity 与上一版 outbound AgentMail 的差异。
2. 能说明为什么先做“员工数字分身”，而不是泛客服、开发者 API 或业务系统邮箱入口。
3. 能对标 ClawEmail、Gmail/Workspace MCP、Front、HubSpot、Microsoft 365 Copilot、Superhuman 等产品并总结借鉴点。
4. 能画出员工、收件人、管理员三类用户的核心操作路径，且核心任务 ≤ 3 步。
5. 能给出 Phase 1 的默认值、空状态、批量/撤销/接管策略。
6. 能给出字段级数据模型。
7. 能给出 REST API、Webhook、MCP Tool 的接口设计。
8. 能明确高风险矩阵、主动发信边界、白名单治理、审计追责策略。
9. 能给出工作量评估、分阶段路线和 MVP 成功指标。
10. 质量自检得分 ≥ 20 / 26。

2. 竞品方案调研

2.1 竞品实现对比

2.2 行业最佳实践总结

1. 邮箱正在成为 Agent 的通用入口：ClawEmail 的核心启发是“发邮件即可调用 Agent”，这比要求用户进入聊天窗口、App 或 API 更低门槛。
2. Agent 邮箱身份必须透明：员工数字分身不应冒充员工本人，应明确显示“员工 + Agent”。
3. 默认自动能力必须配风控矩阵：自动回复和主动发信越强，越需要高风险拦截、白名单、频控、审批和审计。
4. 员工场景需要组织和知识 grounding：仅有邮箱正文不够，需要组织架构、企业知识库、业务系统和历史邮件上下文。
5. 邮件线程要升级为 conversation：邮件只是入口，真正的工作对象是会话、任务、建议、工具调用、审计证据。
6. 人机协作要可接管：Front、HubSpot 都证明 handoff 是企业级 AI 邮件产品的基础能力。
7. 开发者接口不能缺位：即使 Phase 1 面向员工，也应预留 API、Webhook、MCP Tool，便于后续外部客户和业务系统接入。

2.3 DMTX / Iemail 差异化策略

AgentMail Identity 不应只做 ClawEmail 的国内复刻。Claw 的心智是“给 Agent 一个邮箱”，AgentMail Identity 应进一步做：

给企业员工一个可治理的 AI 邮件分身。

差异化重点：

• 企业组织身份：Agent 绑定员工、部门、角色、白名单和权限，而不是孤立邮箱。
• 员工数字分身：不是泛客服 Agent，而是能代表某员工处理邮件协作。
• 自动回复 + 主动协作：默认自动答复、催办、会议协调、摘要分派，形成工作闭环。
• 管理员可配置风险矩阵：合同财务、越权、陌生外部、群发循环等按类型处理。
• 发送基础设施复用：底层继续复用 Iemail / MA 的收发信、域名、追踪、队列、送达能力。
• 审计追责：每封自动回复、主动发信、知识引用、风险判断、白名单操作都可追踪。

3. 用户体验设计

3.1 用户操作流程

员工开通自己的 AgentMail Identity

步骤 1：选择身份
  → 选择平台域名或客户自有域名，确认显示名：Jack's Agent
步骤 2：授权能力
  → 开启普通回复、催办提醒、会议协调、摘要分派；配置白名单外部联系人
步骤 3：试运行
  → 用历史邮件模拟自动回复与主动跟进，确认风险矩阵后启用

完成核心任务所需最少步骤数：3 步。

收件人给员工 Agent 发邮件

步骤 1：给 Jack's Agent 发邮件
  → jack-agent@company.com
步骤 2：Agent 自动理解并回复
  → 基于上下文、组织架构、知识库、业务系统给出答复+建议
步骤 3：必要时继续协作
  → Agent 催办、协调会议、总结分派或提示已转人工

完成核心任务所需最少步骤数：收件人只需 1 步：发邮件。

管理员配置组织级治理

步骤 1：配置身份模板
  → 域名、显示名、签名、默认能力、试点部门
步骤 2：配置风险矩阵
  → 合同财务、越权、陌生外部、群发循环的默认处置
步骤 3：查看运行与审计
  → 自动回复率、主动发信、阻断、人工接管、员工满意度

完成核心任务所需最少步骤数：3 步。

3.2 交互细节

入口位置

• 员工端：AgentMail Identity / 我的邮件分身。
• 管理员端：AgentMail Identity 管理 / 身份模板 / 风险矩阵 / 审计。
• 邮件入口：员工数字分身邮箱地址，例如 jack-agent@company.com。
• 后续开发者入口：API / Webhook / MCP 管理。

关键决策点与默认值

反馈机制

• 自动回复前：显示“Agent 正在处理”状态（控制台可见）。
• 自动回复后：线程中展示回复内容、引用依据、风险等级、动作类型。
• 高风险命中：展示命中原因、处置方式、是否需要员工/管理员处理。
• 主动发信：展示触发原因、收件人范围、白名单校验结果、发送时间。
• 员工接管：支持一键暂停 Agent、接管线程、撤回后续计划。

空状态 / 首次使用

3.3 便捷性自检

4. 技术方案

4.1 方案概述

AgentMail Identity 建议采用六层架构：

与现有 Iemail / MA 的关系：

• 现有 Iemail / MA 继续承担底层收发、域名、追踪、队列、退信、送达能力。
• AgentMail Identity 新增员工身份绑定、会话理解、知识检索、自动回复、主动发信、风险矩阵、白名单、审计追责。
• Phase 1 先以内部员工数字分身为核心，不改造所有营销邮件链路。

4.2 能力分层

4.3 数据模型变更

4.3.1 员工与 Agent 身份

4.3.2 地址与域名

4.3.3 会话、消息与动作

4.3.4 白名单、风险矩阵、知识授权与审计

审批状态流转：

pending
  → approved → action.executed
  → rejected → action.cancelled
  → changes_requested → employee edits draft/policy → resubmitted → pending
  → expired → action.cancelled or escalated

规则：退回修改不新建独立审批链，默认复用原 ami_approval_task.id，但每次 changes_requested 和 resubmitted 都必须写入 ami_audit_log；重新提交后重新计算风险矩阵，若风险类型变化则追加新的审批说明。

4.4 接口设计

4.4.1 REST API

创建员工 Agent 身份请求示例：

POST /v1/identities
{
  "employeeId": "emp_001",
  "displayName": "Jack's Agent",
  "identityType": "employee_twin",
  "addressMode": "customer_domain",
  "address": "jack-agent@company.com",
  "capabilities": {
    "autoReply": true,
    "proactiveSend": true,
    "qa": true,
    "followUp": true,
    "meetingCoordination": true,
    "summaryDelegation": true
  },
  "replyPolicy": {
    "depth": "answer_with_suggestions",
    "meetingWriteMode": "email_only",
    "delegationWriteMode": "email_only"
  }
}

响应示例：

{
  "success": true,
  "data": {
    "identityId": "ami_001",
    "employeeId": "emp_001",
    "displayName": "Jack's Agent",
    "address": "jack-agent@company.com",
    "status": "draft",
    "nextStep": "run_simulation"
  },
  "error": null
}

4.4.2 Webhook 事件

Webhook 用于向员工系统、管理后台或后续第三方 Agent runtime 推送事件。所有 Webhook 必须签名、可重试、可去重、可重放，避免企业集成时出现静默丢事件。

Webhook 签名头建议：

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

投递规则：

关键事件：

• identity.created
• identity.paused
• message.received
• conversation.classified
• agent.auto_replied
• agent.proactive_send_planned
• agent.proactive_sent
• risk.blocked
• risk.escalated
• approval.created
• approval.decided
• approval.changes_requested
• approval.resubmitted
• whitelist.added
• human.takeover

事件示例：

{
  "id": "evt_001",
  "type": "agent.auto_replied",
  "createdAt": "2026-06-04T12:00:00Z",
  "data": {
    "identityId": "ami_001",
    "employeeId": "emp_001",
    "conversationId": "conv_001",
    "messageId": "msg_001",
    "actionId": "act_001",
    "riskLevel": "low",
    "replyDepth": "answer_with_suggestions",
    "knowledgeSources": ["email_context", "knowledge_base"],
    "sentTo": ["colleague@company.com"]
  }
}

4.4.3 MCP Tool 设计

4.5 前端实现

4.6 后端实现

5. 风险控制与边界情况

5.1 高风险处置矩阵

系统提供默认矩阵，管理员可按企业、部门、员工调整。

5.2 主动发信控制

5.3 边界情况

6. 工作量评估

6.1 Phase 1 MVP 工作量

6.2 阶段路线

6.3 MVP 试点指标

7. 方案对比

8. 不做事项

1. 不冒充员工本人发信，必须显示员工 + Agent。
2. 不对非白名单外部联系人自主主动发信。
3. 不自动确认合同、报价、付款、退款、法律承诺。
4. 不直接写入日历、任务、项目系统；会议协调和摘要分派先在邮件内完成。
5. 不一次性开放全部员工，先从管理层助理小范围试点。
6. 不把所有业务系统一次性接入，优先邮件上下文、通讯录/组织架构、企业知识库，再逐步接业务系统。
7. 不绕过管理员风险矩阵。

9. 质量自检

10. 参考资料

• ClawEmail: https://claw.163.com/
• 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
• Front Autopilot Playbooks: https://help.front.com/en/articles/3749568
• Front AI Topics: https://help.front.com/en/articles/3329344
• Front Rules: https://help.front.com/en/articles/2105
• HubSpot Understand Customer Agent: https://knowledge.hubspot.com/customer-agent/understand-the-customer-agent
• HubSpot Deploy Customer Agent to channels: https://knowledge.hubspot.com/customer-agent/deploy-the-customer-agent-to-channels
• HubSpot Customer Agent channel settings: https://knowledge.hubspot.com/customer-agent/manage-the-customer-agents-channel-settings
• Microsoft 365 Copilot architecture: https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-architecture
• Microsoft Copilot in Outlook draft email: https://support.microsoft.com/office/draft-an-email-message-with-copilot-in-outlook-3eb1d053-89b8-491c-8a6e-746015238d9b
• Superhuman Auto Reminders & Auto Drafts: https://help.superhuman.com/hc/en-us/articles/46005658551053-Auto-Reminders-Auto-Drafts
• Superhuman Follow Up Faster: https://help.superhuman.com/hc/en-us/articles/46005792082445-Follow-Up-Faster
• Superhuman Auto Drafts for Scheduling: https://blog.superhuman.com/auto-drafts-for-scheduling/