当 AI agent 需要请求审批、报告完成结果、接收新任务，或在当前进程结束后继续沟通时，邮件和消息就成为后端基础设施。通信渠道需要稳定的身份、投递状态、与工作流的关联关系、重试规则和审计记录。
用户仍在应用中时，应用内通知很方便。如果交接需要在标签页关闭、agent 闲置后依然有效，邮件会更合适。
通信基础设施承担的四项任务
请求审批
消息应说明确切操作、资源、范围、相关费用和审批有效期。多个请求同时等待时，回复“是”并不安全。应使用签名且用途单一的审批操作，并将其绑定到一个操作 ID。
报告完成或失败
发送用户真正需要的结果，而不是一连串 agent 思考过程。消息应包含工作流 ID、最终状态、相关产物或 URL，以及下一步操作。只有收件人有权查看日志时，才附上日志链接。
接收新任务
专用收件箱可以将收到的邮件转换为 agent 任务。系统需要验证发件人、限制附件、标识会话串、处理提示词注入，并在接收和执行之间设置队列。收到邮件不应自动赋予发件人运行工具的权限。
协调系统
对于需要结构化投递和重试的机器间事件，Webhook 比邮件更合适。需要用户阅读或回复时，邮件仍有价值。有些工作流两者都需要：Webhook 更新系统状态，邮件则请用户做出决定。
AI agent 基础设施指南将这些通信渠道与数据库、工具、身份和执行并列，而不是将它们视为 UI 装饰。
根据交接需求选择通信渠道
| 需求 | 建议默认选择 | 原因 |
|---|---|---|
| 更新当前可见会话 | 应用内事件 | 延迟低，并能利用现有用户上下文 |
| 通知不在场的用户 | 邮件 | 会话结束后仍可送达已知地址 |
| 发送结构化系统事件 | Webhook | 签名 payload、机器解析和重试契约 |
| 让 agent 管理对话 | 专用收件箱 | 稳定地址、会话串及收发历史 |
| 请求高影响决策 | 签名审批页面与通知 | 将用户同意绑定到一个确切操作 |
如果接收方是另一个服务，而且对投递可靠性要求严格，就不要把邮件当作队列。应使用 Webhook 或消息系统，邮件只负责面向用户的部分。
独立收件箱还是后端集成收件箱
如果 agent 的主要工作是读取、分类和回复邮件，独立的 agent 邮件产品更合适。AgentMail就是一个围绕 agent 收件箱设计的邮件 API。
如果应用已经需要数据库、托管、身份验证和存储，而邮件只负责偶发通知或回复，后端集成的收件箱会更合适。Cohesivity Inbox 为租户提供一个地址，并在同一项目中提供发送、接收、列出、读取、回复和删除操作。临时租户有更严格的发送和收件人限制，认领后可解锁月度额度和可选 Webhook。
两者的运维模式不同。以邮件为中心的 agent 能从专用产品更深入的控制能力中受益，而产品型 agent 可能更适合让邮件与其他后端资源共享同一套身份和生命周期。
设计消息契约
每封发出的消息都应记录：
- 租户、工作流和操作 ID；
- 收件人和发件人身份；
- 模板或消息版本；
- 可用时记录提供商消息 ID；
- 尝试次数和最终投递状态；
- 消息所代表的外部影响；
- 预期的回复或审批操作。
使用幂等键，避免工作流中断后重复发送同一封审批或完成通知邮件。故障恢复指南介绍了如何在重试前核对结果未知的操作。
将传入内容视为不受信任的数据
邮件可能包含指令、链接、附件、转发的密钥，以及来自其他发件人的引用内容。应将其作为数据解析，不允许正文覆盖 agent 的策略或工具权限。
分别验证发件人身份和会话串身份。按类型和大小限制附件，为原始内容设定明确的保留策略。传入消息触发破坏性操作或付费操作前，必须重新请求审批。
在用户不在场时测试一次交接
在工作流最关键的人工依赖节点暂停，关闭应用，发送通知，再通过链接或回复路径继续操作，并确认工作流只恢复一次。然后重复投递，确认它不会导致操作重复执行。
下方的提示词会在不发送任何消息的情况下，找出一条真实工作流中缺失的交接环节。