收件箱自动打标签

自动标签读取每封入站邮件，将其归入工作区标签，再评估它值得你投入多少注意力。这是可选功能，默认关闭，只有运维人员开启后才运行。

分类会把邮件内容发送到 TypeSafe，因此需要两次明确启用：运维人员先提供密钥，再单独打开功能。两者都未配置的实例绝不会调用 TypeSafe，行为与以前完全相同。其他可选 AI 功能也可能向各自配置的提供商发送内容；参见数据控制。

它为每封入站邮件写入标签和相关性分数，将非人工撰写的邮件，例如登录验证码、收据、通知、退信和自动回复，从收件箱移到自动邮件视图。需要你采取行动的自动邮件，例如付款失败或账户被停用，会留在收件箱并标记为需要处理。这部分只需开启功能，无需其他操作。

它还可以根据有把握的判定采取行动：暂缓表示“现在不合适”的联系人，停止已拒绝的联系人，为要求通话的人创建任务，以及将要求移除的发件人加入禁止发送名单。每项操作在设置 > 发送 > 已分类回复中都有独立开关。三项可逆操作从一开始就开启；禁止发送默认关闭，需主动启用，因为这是系统无法自行撤销的一项。参见根据判定采取行动。

完整标签集会在创建工作区时建立；如果实例稍后才开启功能，则由跟进扫描在一小时内补齐。因此，即使尚无人提出退订，收件箱也已经可以按退订筛选。收件箱侧栏中的预设视图，包括需要处理、热门潜客、需要回复、跟进、已拒绝和自动邮件，都基于这些标签构建，并随邮件分类逐渐填充；参见统一收件箱。每个标签都有悬停说明，无需先学习一整套分类体系。

标签使用直白词语，团队任何成员都能理解，无需先学习分类术语。它们是普通工作区标签，收件箱可像筛选你自行创建的标签一样使用。如果工作区已有同名标签，会保留原标签，自动分类也使用它。

邮件是什么。 最多一个：退信、休假、自动回复、通知或推销。人工回复不会仅因为是回复就获得一个标签，因为几乎每个会话都属于回复。需要你处理的通知还会带上需要处理；参见需要你处理的邮件。

回复想表达什么。 只适用于人工回复：

分类器回答的问题比这些更多，例如发件人是否为决策者、是否提及竞争对手、是否带有敌意等十余项。这些答案参与相关性评分，但不生成标签，因为一个会话挂十五个标签并不会比两个更易读。无法明确理解意图的回复不会获得意图标签，以免贴错。

需要审阅表示分类器没有把握，详见下文。

登录与验证代码、常规安全/账户/账单通知、收据、新闻简报、退信和自动回复，都不是需要人工回答的邮件。当判定为非人工撰写时，其会话会离开收件箱、未读、各邮箱和标签视图，也不计入未读标记，改为列在自动邮件视图。全部邮件仍显示所有内容。

只有有把握的判定才会移动会话：分类器不确定的邮件继续留在收件箱。只有会话中每封非你自己发送的邮件都被判定为自动邮件时，整个会话才算自动会话；因此人工回复一到达，甚至尚未分类，就会将会话带回收件箱。邮箱本身不会移动任何邮件，服务商文件夹保持不变。

常见发件人和邮件头特征，例如 no-reply 地址、群发邮件、休假主题和投递失败，会在本地判定。其余内容由模型判断。

只用于营销活动的邮箱也会收到必须由人处理的邮件：邮箱订阅付款失败、账户停用或受限、可疑登录、服务商的发送限额或政策通知、域名或服务即将到期。通常没有人逐个登录这些邮箱，因此若这些邮件与收据一起进入自动邮件视图，就可能永远没人看到。

所以，每条通知还会回答一个问题：它是否告知收件人，其自己的账户、付款、域名或服务出现了必须处理的问题？答案为是时：

• 会话留在收件箱、未读列表和未读标记中，不移入自动邮件
• 除通知外，还标记为需要处理；侧栏的需要处理视图列出这些会话及其未读数量
• 收件箱按相关性排序时，它会与今日应回复的会话排在一起
• 同时拥有管理邮箱和使用收件箱权限的成员会收到需要处理的邮件通知，默认也发邮件，除非已关闭。通知指明邮箱并链接到会话，但绝不引用邮件正文，因为声称账户被停用的邮件也可能是网络钓鱼。通知与邮件绑定，阅读邮件也会将通知标记为已读

常规通知不受影响：登录验证码、收据、新闻简报或“设置已修改”确认仍进入自动邮件。处理完问题后，可归档会话。该标签是普通标签：移除它会使会话退出需要处理视图，但仍留在收件箱中。

仅凭发件人在本地识别出的通知，只为这一个问题进行一次小型调用，不询问其他问题；由模型判定的通知，则将该问题放在同一次调用中。如果调用失败，通知仍按这项检查推出之前的方式归入自动邮件，之后可使用下文的 --recheck-notifications 重新判断。

每个工作区默认开启此行为。要关闭，请在设置 > 发送 > 自动邮件中取消将需要处理的邮件保留在收件箱；此后通知恢复进入自动邮件，也不再为它们发起这项调用。若想按自己的方式处理其他自动邮件，也可对通知提出自定义问题。

以下三个标签回答销售推进真正关心的问题：哪些事情被遗漏，需要你补上跟进。

你最近才发信的会话不带这些标签：目前还没有需要做的事，而且等待回复范围已经列出它。

沉默已久刻意与跟进分开。停滞的商机与无人回答的冷邮件，需要你采取不同处理；已经表示过同意的人，比从未回答的人值得更多耐心，所以等待时间更长。

扫描不会额外调用模型。 开启自动标签时，它复用已存储分类，因此退信、自动回复和平台通知不会被当作人工回复。

已经拒绝的会话绝不继续催促。 判定为不感兴趣、退订、找错人或暂时不需要的回复，绝不会获得跟进标签。催促已经拒绝的人很失礼；催促要求移除的人更是合规问题，而非错过的商机。自动邮件也会跳过，因为另一端没有需要跟进的人。

这些标签随时间变化，因此每小时重新计算，并且替换而非叠加。同一会话不会同时带着跟进和需要回复，标签代表当前状态，而非历史。收到回复后，跟进标签会在一小时内清除。

最近 90 天有过活动的每个会话都会被检查，不论数量多少。大型工作区按页检查：每次小时扫描最多运行几分钟，并从上次停止的位置继续，重启后也一样。因此，较旧会话到达对应日期后，会在工作区完成一轮完整扫描时获得标签；多数工作区一轮即可，极大的工作区可能需要数轮。每次扫描会优先检查自上轮以来收到邮件或完成回复分类的所有会话，不受邮件自身日期限制，因此较晚才同步的回复也会在下一轮清除标签。

要按需重新计算，可运行以下命令。它会一次检查所有会话，不改变每小时扫描的当前位置：

warmblyctl inbox-tag follow-ups --org [email protected]

每封邮件获得 0 至 100 的分数，以及 now、today、whenever 或 ignore 优先级。收件箱按相关性排序时，已表示同意的人排在仍在考虑的人前面，后者又排在退信前面。

分数由 Warmbly 根据各项答案进行算术计算，不直接向模型询问。单独问“这封邮件有多相关”，会将四项独立判断藏进一个问题，模型会正确地拒绝这种提问，返回零置信度的均匀分布。

共有四项操作，在设置 > 发送 > 已分类回复中各有独立开关。暂缓、停止和创建任务默认开启，禁止发送默认关闭。只有有把握的人工回复才能触发操作；标记为需要审阅的判定、退信、自动回复或冷推销，无论其他信号如何，都不会触发。意图必须达到与标签相同的 0.70 阈值，因为对连标签都不信任的意图采取行动，无异于猜测。

禁止发送遵循与“unsubscribe”回复相同的规则：只对回复了你营销活动会话的人，或主动来信的已有联系人执行，绝不对发送到邮件列表的邮件执行。这是唯一不可逆操作，因此使用独立的是非问题“发件人要求被移除”，并采用较高阈值，而不依赖八选一的意图分类。一旦执行，就不再执行其他操作，因为被禁止发送的地址已没有需要暂停或跟进的序列。已分类回复设置的暂停绝不覆盖成员手动设置的暂停，也不会缩短已有的更长自动暂停。通话请求只创建一个任务，无论是自动标签开关还是回复跟进设置原本会创建它。

自定义问题也可以触发操作；参见自定义问题。

每个操作都会记录在判定结果上，因此审阅页面会在触发它的答案旁显示执行内容，顶部的已采取操作计数展示各开关触发频率。操作只对实时到达邮件执行；回填历史只添加标签，绝不采取这些行动。

内置标签回答每个工作区普遍需要了解的问题。针对自己业务的特殊问题，可以在设置 > 发送 > 标签语言与问题中自定义。例如：“发件人表示目前没有合适职位，但之后会再联系”，标记为以后可能有机会，并暂停联系人 60 天。

问题分为两类：

• 是或否。 对邮件提出一条简单陈述。答案为是时，会话获得该问题的标签。
• 选择一项。 提供二至八个选项，每项有自己的标签，以及一句说明适用情况的描述。会话获得分类器选中项的标签。如果回复不符合任何一项，则不添加标签，因此无需设置包罗一切的兜底选项。

请按分类器逐字理解的方式编写问题：每个问题只包含一个判断，不使用双重否定或“除非”。标签与内置标签一样使用普通词语：支持任意文字系统的字母和数字，中间可用单个空格或连字符，最多 40 个字符。不能以任何大小写形式重复使用内置名称。

每个标签或选项也可以执行操作，与上面的开关使用相同基本动作：暂缓联系人序列 1 至 365 天，停止一年，或为邮箱所有者创建任务。这些操作不受内置开关影响，但遵循相同规则：只对有把握的人工回复执行，绝不对需要审阅的判定执行，且禁止发送会终止其他所有操作。是非问题在 60% 时添加标签、80% 时采取行动；选项问题的标签和操作都使用 70% 阈值。如果两个暂停同时适用，采用较长者。

也可以对自动通知提出问题：在该问题上勾选同时询问自动通知。默认不对通知询问自定义问题，因为它们通常针对人工表达。匹配问题的通知会获得标签，并像需要处理的邮件一样留在收件箱，而非自动邮件视图。它绝不会暂停、停止或创建任务，这些操作仍只适用于回复。通过发件人在本地识别的通知，只会在一次小型调用中回答这些问题和需要处理检查。

自定义问题与内置问题放在同一次调用中，因此会增加每封被分类邮件的输入 token，但不会增加第二次请求。每个工作区最多 10 个问题。它们只向判定添加标签，不改变其他结果：邮件类型、意图和相关性分数只依据内置问题校准，不受自定义问题影响。标签在首次适用时创建，或由每小时扫描在一小时内补齐。问题属于工作区设置，会随工作区导出迁移。

自动标签默认支持英语、德语、法语、西班牙语、意大利语和荷兰语回复。如果还收到其他语言的邮件，可以在设置 > 发送 > 标签语言与问题中添加。只有工作区添加某种语言后，才会使用该语言的处理规则；团队无人使用的语言只会增加可能误读邮件的模式，因此应保持关闭。此设置只影响收件箱标签，营销活动的回复处理不受影响。

添加语言会带来两项变化：

• 随每封邮件告知分类器该语言，使其了解预期语言。这只是提示，不是翻译：邮件和问题的内容都不改变，内置问题仍为英文。可指定以下 44 种语言：阿拉伯语、孟加拉语、保加利亚语、加泰罗尼亚语、中文、克罗地亚语、捷克语、丹麦语、荷兰语、英语、爱沙尼亚语、菲律宾语、芬兰语、法语、德语、希腊语、希伯来语、印地语、匈牙利语、印度尼西亚语、意大利语、日语、韩语、拉脱维亚语、立陶宛语、马来语、挪威语、波斯语、波兰语、葡萄牙语、罗马尼亚语、俄语、塞尔维亚语、斯洛伐克语、斯洛文尼亚语、西班牙语、斯瓦希里语、瑞典语、泰米尔语、泰语、土耳其语、乌克兰语、乌尔都语和越南语。
• 在任何模型调用之前的本地解析中启用该语言，上述每种语言都支持。英语始终解析。

调用之前的本地解析覆盖：

• 引用历史。 从回复中截去引用，让分类器读取对方新写的内容，而非下方引用的你的原邮件。识别内容包括各客户端生成的回复行，例如“Den ... skrev”“W dniu ... pisze:”和“于 ... 写道：”；该语言的 Outlook From: / Sent: 引用块，例如 Von: / Gesendet:、De : / Envoyé :、差出人: / 送信日時:；以及带分隔线的“Original message”和“Forwarded message”等原始/转发邮件标记。
• 休假回复。 根据邮件服务商生成的主题识别，例如 Автоматический ответ、自動応答、자동 회신、رد تلقائي 等，完全无需模型调用。
• 未投递通知。 根据 Exchange 使用西班牙语、意大利语、荷兰语和葡萄牙语生成的主题识别。携带投递状态报告的通知，无论什么语言都可识别，不依赖此设置。

标签语言属于工作区设置，会随工作区导出迁移。

另外三项功能复用已存储判定，避免为第二次判断付费：

• 营销活动回复处理。 驱动 stop_on_reply 和回复分支的分类器，会在已有判定时读取存储的类型和意图，因此感兴趣的回复按积极路由，拒绝按消极路由，并使用分类器的真实置信度。意图本身也存储在联系人进度中，序列可使用 reply_intent 条件分支，参见营销活动。没有自动标签时，分类器改为向 TypeSafe 提出一个三选一问题；没有密钥时，则与以前一样回退到平台 LLM。
• 回复自动化和 Webhook。 campaign.reply_received 事件以 ai_labels、ai_intent、ai_intent_confidence、ai_kind、ai_relevance 和 ai_needs_review 携带判定，采用与标签相同的置信度阈值，因此自动化流程可以针对感兴趣或会议回复通知你，参见自动化流程。
• 收件箱代理。 判定显示已结束的回复，包括不感兴趣、退订、找错人和暂时不需要，以及一句话确认、法律威胁或需要人工阅读的邮件，都不会起草回复，避免为回答它们消耗积分。

休假回复暂停潜在客户时，恢复日期由规则从休假邮件中提取。规则有时会误选提示词附近的日期：ab dem 4.9. nicht im Büro 指的是离开的第一天，而非最后一天。因此，开启自动标签和休假暂停时，如果规则读出了日期，还会对这封休假邮件提出一个额外的是非问题：日期所在的短语，例如 ab dem 4.9.、bis KW 41 或 until 12 September，是否说明发件人何时返回。

问题针对短语原文，绝不针对 Warmbly 推算后的日期。把 bis einschließlich 18.9. 转为“19 日返回”，或将某个日历周转换为该周星期一，仍由规则完成，因为日期运算是模型最不擅长的部分。

答案低于 0.40 时，暂停改用工作区的后备时长，而非该日期。这与信号通常需要的 0.60 阈值相对应：规则已经得出了这个日期，因此不确定的答案不足以反驳它，只有模型较有把握认为日期不对，才覆盖规则。不确定或调用失败时，会像此问题引入之前一样保留原日期。该答案绝不会改变标签。

本地识别的休假邮件只需一次小型调用，携带邮件和短语；而且只有规则找到了日期、工作区又开启休假暂停时才调用。如果邮件类型由模型判断，该问题会放在同一次调用中。历史回填从不询问它，因为回填只添加历史标签，不暂停任何人。审阅页面会在判定旁显示日期和答案；若暂停使用了后备值，日期会加删除线。

每次分类都带有置信度。邮件类型低于 0.70 时，会话标记为需要审阅，不应用其他标签，并留在收件箱。如果类型可靠但意图低于 0.70，则保留可信的类型和相关性，省略不确定的意图标签，并添加需要审阅。

这个阈值并非单纯为了保守。低置信答案不仅不确定，还不可复现：同一封含糊邮件运行三次，每次胜出的标签都不同，而置信度始终接近 0.2。一个重新问一次就可能改变的标签，不适合用来整理邮件。

Warmbly 已知的信息都由代码确定，不会作为问题发送：邮件方向、所属邮箱、回复了哪个营销活动，以及发件人是否已被禁止发送。

营销活动关联用于区分“回复你的触达”与“别人向你推销”，因此会利用邮箱中的所有事实解析：回复引用的 Message-ID、会话中你发送的副本，以及 Gmail 上原发送进入的会话。Gmail 可能用自己的 Message-ID 替换原发送 ID，因此会话关联仍能把 Gmail 回复连回营销活动。

这一点比看起来更重要。仅提供正文时，模型曾以 0.94 置信度，将我们自己的一封出站邮件判为人工回复。对于给出的问题，答案并非不合理；问题本身就不应被提出。所有自己的发送都会在询问模型之前排除。

常见休假主题前缀和自动发件地址会在本地检查。能够明确判断时，不再询问邮件类型；只有通知仍需回答是否需要你处理，休假邮件仍需确认其返回日期是否真的表示发件人返回之日。审阅页面会显示哪些判定来自本地规则，哪些来自模型。

没有 TYPESAFE_API_KEY 时，Warmbly 仍可根据已发送邮件日期，在本地计算跟进标签，不发起外部调用。需要回复和沉默已久还需要可信的已存储分类，避免把自动邮件当作人，把弱意图当作感兴趣；没有分类时，也不会把任何邮件作为自动邮件移出收件箱。

密钥和开关共同启用邮件分类。两者均未设置时，自动收件箱标签不会向 TypeSafe 发送任何邮件内容。其他可选 AI 功能使用各自单独配置的提供商；参见数据控制。

设置两个环境变量：

TYPESAFE_API_KEY=...        # from typesafe.ai
INBOX_TAGGING_ENABLED=true  # off by default even when a key is present

随后，设置 > 收件箱标签会展示每次判断，包括标签、相关性、置信度、判定来源及执行的操作。建议观察一周，再在设置 > 发送 > 已分类回复中启用禁止发送；可逆操作已经开启，每一项都可在潜在客户标签页或任务页面查看。

只处理新到邮件的分类器，在开启当天无法整理已经积压的收件箱。可以对历史运行回填：

# See what it would cover, and what it would cost. Calls nothing, writes nothing.
warmblyctl inbox-tag backfill --org [email protected] --days 30 --dry-run

# Then do it.
warmblyctl inbox-tag backfill --org [email protected] --days 30 --limit 200

回填有明确边界，并可恢复。每封邮件以 Message-ID 保证幂等，因此达到限额、按 Ctrl-C 或运行两遍，都会保留已完成工作，下次从上次停止的位置继续。不会对同一邮件重复分类。

只处理入站邮件。你自己的发送会排除，从一个已连接邮箱发往另一个已连接邮箱的邮件也会排除；即使它进入第二个邮箱的收件箱，仍属于你自己的邮件。

回填会从已发送邮件中补齐各会话的上一封消息，让“好的，就这么办”之类回复，能够结合其同意的具体事项判断。

如果回复在找到所属营销活动之前就完成分类，可能被标记为推销，而非按回复理解。要让分类器这次带着营销活动上下文重新判断，可运行：

warmblyctl inbox-tag backfill --org [email protected] --days 30 --recheck-cold-inbound

只有原本存为推销，且所在会话包含某封营销活动发送的邮件会被重新询问；其他内容不会发送。旧判定添加、新判定不再需要的自动标签会从会话移除，除非同一会话的其他邮件仍带有该标签。队友手动添加的标签绝不会移除。如果分类器在看到营销活动后仍判为推销，会保留该判定；再次运行命令时仍会重新询问。与所有回填一样，它只添加或调整标签，不采取行动。

在“需要处理”检查推出之前分类的通知，可能尚未经过询问，就留在自动邮件中。要现在检查它们，让其中的付款失败等通知回到收件箱，可运行：

warmblyctl inbox-tag backfill --org [email protected] --days 30 --recheck-notifications

仅处理被存为通知、且原判定从未询问过需要处理检查的邮件，每封都会重新判断；需要处理的通知回到收件箱，并标记为需要处理。如果关闭了将需要处理的邮件保留在收件箱，命令会拒绝运行。没有可读文字的通知会跳过。调用失败的邮件会在下一次运行或普通回填中重试。与所有回填一样，它可以调整标签和移动视图，但绝不发送通知。

一次调用包含某封邮件的全部问题，在当前记录的测试样本集上约使用 1,300 个输入 token。本地识别的通知使用一次更小的调用，检查是否需要处理及你为通知设置的问题；两者均未开启时，不调用。本地识别的休假邮件，仅在检查返回日期时产生一次小型调用，否则不调用。TypeSafe 并行评估各问题，但每个问题仍会贡献 token，因此大规模回填前请查看其当前价格。输出 token 不计费。

同一个已配置 API 密钥还用于回复分类、营销文案检查、生成预热内容的审阅、表单分类、退信分类和导入辅助。这些都计入该密钥的 TypeSafe 账户，而非只有收件箱标签。自托管实例配置后使用自己的密钥和计费账户；默认不提供共享托管密钥。

运维人员可以按 event=typesafe_usage 筛选后端和消费者日志。每次请求尝试都记录功能、问题数量和 HTTP 状态；未收到可用 API 响应时，状态为零。成功响应还记录模型和输入 token，若有工作区标识也会附上。汇总成功响应的 input_tokens 可比较各功能消耗；失败尝试没有服务端报告的 token 用量。日志不包含邮件内容、问题文字、凭据或 API 密钥。仅靠已保存的收件箱和文案判定，并不能构成全账户账本：某些功能不持久化用量，余额和费用仍以 TypeSafe 控制台为准。

如果 TypeSafe 返回计费错误 HTTP 402，付费判断会暂停五分钟。此后下一条符合条件的请求成为唯一的恢复探测；成功则恢复请求，失败则再次暂停。后端和消费者通过现有 Redis 连接，按同一个 API 密钥协调。如果 Redis 不可用，各进程保留各自有时限的暂停。这可防止重复失败请求，但不会补充积分，也不会降低成功判断的价格。

暂停期间，入站邮件仍正常保存。本地规则和已有判定继续可用，不会编造无法获得的模型答案。补充积分后，普通回填可分类之前跳过的历史邮件，--recheck-notifications 可检查未获得需要处理答案就被归档到相应视图的通知。恢复探测按需发生，不通过发送付费的模拟健康检查实现。

没有 Message-ID 的邮件会跳过。数据库占用记录可防止同一 Message-ID 的并发投递重复调用；被遗弃的占用记录在 15 分钟后重新允许重试。