用途
Inbox-zero 是一个用于横扫式处理用户收件箱的 AI 代理技能，覆盖邮件、Slack、LinkedIn 和 Swan 四个渠道。它的目标是把杂乱的多渠道来信一次性整理干净：自动归档明显噪音、自动完成代理能独立完成的琐事、为需要回复的条目起草答复、把含糊或需人工判断的事项留在收件箱，最终通过一次批量输出让用户集中决策。
四类分桶模型
代理遇到每条条目时，只会归入以下四类之一：
- 自动归档（Auto-archive）：明显噪音（简报、群发邮件、状态告警）、已被他人处理的条目、无需行动的条目。用户在批量摘要中会看到一行说明，并始终附带归档原因。
- 自动处理（Auto-handle）：代理能自己完全完成的工作，例如把 CRM 任务标记为完成、安排跟进提醒、在对方已回复后归档。用户同样在批量摘要中看到一行说明。
- 起草 → 批准（Draft → approve）：需要回复的条目。用户在批量输出中逐条审阅。
- 暂存（Park）：含糊或需要用户判断的条目。留在收件箱，并附一行原因。
操作步骤
- 清扫所有已连接渠道。从邮件、Slack 私信、LinkedIn 私信、Swan 收件箱和 CRM 任务队列中拉取未读/未处理条目并计数。若数量超过约 30，改用 swan-execute-code——把收件箱快照载入 frame，再分批处理。
- 静默分类为四个桶。对每条条目：先读消息；需要事实时先调查（查 CRM 中的既往接触与账户记录、查订阅状态、搜产品文档、翻客户被讨论过的近期 Slack 线程；若涉及 bug、产品行为或代码层问题，在组织内有内部调查/审计代理时转交处理，这类代理通常能访问日志和代码库，其上下文会落入草稿）；再决定分桶，不确定时选择暂存而非自动归档。
- 执行自主操作。归档第一桶、完成第二桶。持续记录每条被处理的“原因”，让 FYI 摘要具体（如“David 回复说他在处理”）而非笼统（如“归档了 14 条”）。
- 为第三桶起草回复。内容充实、用发件人的口吻（先加载发件人指令、拉取以往已批准的消息），并引用第二步收集到的事实。若回复属于既有外联线程，使用 swan-build-sequence；否则用该渠道对应的发送工具起草。
- 呈现批量输出。顺序为：先 FYI（自动归档 + 自动处理，各附一行原因）；再草稿（编号，每条草稿正文上方附 1–2 行上下文，压缩到用户做决定所需的信息）；最后暂存项（各附一行留在收件箱的原因）。然后等待。用户会一次性给出决定，例如“发送 1，把 2 改成加上 X，跳过 3，暂存的别动”。
- 执行用户决定。发送已批准的草稿、应用编辑、归档被跳过的条目。报告准确数量，例如“已发送 2 封草稿，归档 1 条，剩 2 条暂存项留给你”。
什么算做得好
最好的一遍 inbox-zero 只打扰用户一次。用户读 FYI 摘要、扫一遍草稿、批准大部分、编辑一封、暂存项不动。收件箱清空，或只剩用户有意保留的条目。
需要首先抓住的：藏在看似可归档线程里的实质请求；“谢谢！”邮件第 4 段里的功能请求；顺带提到的流失信号。容易被忽略的：队友一句“我在处理”意味着客户邮件其实已被处理；长账户更新里藏着的试用延期请求。陷阱：为每次归档做旁白（“我准备归档 14 封简报……”）——用户不需要为显而易见的决定举行仪式，确认归档等于为代理本该自己负责的工作请求许可。
失败模式：起草套话式“谢谢，会跟进”的回复（应先做调查）；调查了本不需要调查的条目（拖慢流程）；含糊时却自动归档（应改为暂存）；把客户完整历史全塞进上下文行（应压缩到用户做决定所需）；逐条呈现草稿并中途确认（单次批量输出才是契约）。
成功标准：每封草稿读起来都像代理做过功课——引用订阅细节、确认 bug 状态、参照过往对话。用户无需重写直接点发送。
规则
- 必须处理每一条条目。只通过单次批量输出呈现。
- 回复需要事实时，必须在起草前调查——查 CRM、搜文档、在有内部调查/审计代理时转交、拉取既往 Slack 线程。
- 每条自动归档和自动处理的 FYI 都必须解释原因。只给笼统计数算失败。
- 不确定时必须暂存（而非自动归档），并说明原因。
- 绝不自动发送草稿。用户批准是关卡。
- 绝不让用户确认为明显噪音的归档。直接做并报告。
- 需要事实时，绝不在未调查的情况下呈现草稿。一句“谢谢，会跟进”算失败。
适用场景
适用于需要日常清扫收件箱的场景，尤其是销售或客户对接类收件箱：需要批量分拣多渠道来信、识别被埋没的重要请求与流失信号、并集中审批回复草稿时。
限制
具体收费、价格、平台支持范围、可用性等事实暂未提供。