核心用法
snail-mail 是一款面向 AI 操作员的"慢速通道"收件箱系统，解决 AI 与人工操作员之间信息传递的"何时打扰"难题。它通过 node 脚本提供完整的 CLI 工作流：添加消息（支持 [URGENT]/[IMPORTANT] 优先级前缀）、列出未读/全部/已归档消息、标记已读、归档管理，以及多格式渲染输出（HTML/Markdown/纯文本）。
消息存储采用单写者原子写入策略（.tmp → rename），位于 {workspace}/inbox/messages.json，避免并发冲突。render 命令可根据 OPENCLAW_CHANNEL 环境变量自动检测输出格式，或强制指定格式以适配 Telegram、Discord、Slack 等不同渠道。
显著优点
- 打扰粒度精准：明确区分 urgent（数小时内）、important（今日）、normal（随缘查看）三级优先级，终结"所有通知都一样响"的疲劳
- 上下文即代码：CLI 设计允许 Agent 在脚本/heartbeat 中集成，支持
--json输出便于程序化判断 - 格式自适应：同一消息源自动渲染为 HTML（富媒体）、Markdown（Discord/Slack）或纯文本（SMS），无需重复编写
- 零依赖部署：仅依赖 Node.js 运行时，无外部数据库或服务
- 原子写入安全：单写者场景下的原子 rename 机制，兼顾简洁与数据完整性
潜在缺点与局限性
- 单点故障：JSON 文件存储无备份/同步机制，workspace 损坏即丢失历史
- 无多 Agent 支持：显式声明"single-writer"，多 Agent 并发写入将破坏数据
- 检索能力弱：无搜索、过滤、标签系统，消息量增大后难以翻查历史
- 人机边界模糊：依赖 Agent 自行判断"是否值得写入"，存在过度沉默或过度唠叨的误判风险
- 无持久化审计：归档后无导出/分析接口，长期运营数据 trapped
适合人群
- 个人开发者/小团队运行单一 Agent 实例，追求极简运维
- 需要区分"立即打断"与"稍后查看"两种沟通模式的 AI-人类协作场景
- 已通过其他系统（如专用日志平台）处理重审计需求，仅需轻量通知层的用户
常规风险
- 数据丢失：workspace 目录误删或权限变更导致收件箱清空
- 优先级通货膨胀：Agent 倾向于高估事件重要性，导致
[URGENT]泛滥，操作员脱敏 - 沉默失败：Node 运行时缺失或版本不兼容时，脚本报错可能未被 Agent 正确处理，关键消息丢失
- 隐私泄露：messages.json 以明文存储，workspace 权限配置不当可导致敏感信息暴露
- heartbeat 风暴：高频心跳配合
list unread --json检查，若实现不当可能引发 IO 负载