这里的每条限制都是永久的、设计使然。没有一条是 bug，早知道它们，会改变你搭建它的方 式。
如果是某一封邮件没被回复，那是诊断而不是限制： AI 为什么没有回复一封邮件。
从连接那刻开始。没有历史。
连接一个邮箱，开始的是对新邮件的监视。连接之前的任何东西都不会被导入，之后你做 什么也补不回来。
实际推论：在你希望覆盖的时段之前连接邮箱。周五才连上的邮箱对周四一无所知，想给它 更早的背景，知识库是唯一的办法。
它只认从它这里发出去的回复
平台记录的是它自己发出的邮件。同事在 Gmail 或 Outlook 里敲出的回复，是给真实客户的真 实回答，但在这里不被计数 —— 所以会话仍可能显示为等待中。
两家服务商的失败方式不同，把一个说成另一个都不安全。Gmail 上监视布防在收件箱，他们 的回复根本到不了我们这里。Outlook 上已发送订阅确实会把消息送来，而会话依然不会被标 记为已回复。
所以这边的“没有回复”始终意味着我看得见的最后一条是对方发的 —— 永远不意味着你欠 这个人一封回复。
在 Gmail 上，它只看得见收件箱
监视就布防在 INBOX 上。绕过收件箱的邮件 —— 直接被过滤进某个标签，或一到就归档 ——
是看不见的。如果你的过滤规则很激进，你最想被处理的邮件，可能正是永远到不了的那封。
指令属于智能体，不属于邮箱
没有按渠道的指令。你告诉智能体的话，在它回答的每个地方都生效。你可以把指令措辞成自 带范围的 —— “在 support@ 上回邮件时……” —— 但那是对模型的请求，不是有东西在执行的 设置。
真的需要不同行为的两个邮箱，需要不同的智能体。
指令拦不住草稿被写出来
这是大家最先试的一招，而它不像看上去那样起作用。告诉智能体*“不要回营销邮件”*，改变 的是回复的措辞，而不是回复存不存在。让提示词产不出草稿的唯一办法，是模型一个字 都不吐，而被要求闭嘴的模型，通常写的会是一封客气的拒绝 —— 然后它成了草稿。
真正拦住回复的东西是确定性的，住在代码里，跑在模型前面：自认自动发送的邮件会被丢弃
，来自 no-reply 地址的邮件只展示、永不起草。那些是过滤器，不是指令，而且不按邮箱
开放配置。
草稿不是到处都有
在大多数邮箱上，待批的回复也会写进服务商的草稿文件夹。在 Microsoft 365 群组上不会 —— Graph 没有 针对群组会话的草稿 API，所以那些草稿只活在仪表板上。
也没有按草稿的置信分。一封草稿要么被分诊标记，要么没有；没有任何东西给模型的把握程 度打分，任何暗示相反的界面都是在凭空捏造。
没设的回复模式等于自主
如果存下的模式哪天丢失或无法识别，回退是自主 —— AI 会发。这是对哪种失败更糟的刻 意取舍，也意味着显式设好默认，好过以为空着的字段就是“什么都不做”。
送达不归我们管
如果一封回复从这里发出、却始终没有到达，那是 SPF、DKIM、你域名的信誉，或者收件方的 垃圾邮件过滤器。它们归你的邮件服务商和你的 DNS 管。这个产品不管理、不监视、也不报告 它们，这里没有任何东西会告诉你某封邮件被标成了垃圾邮件。