Workers AI 当 triage filter 用，不是当 generator
Workers AI 调用最值得花的地方是 pipeline 前端的打分过滤器，不是后端的生成器。成本、延迟、质量三个角度的论证 —— 配 Agentic Inbox 和 IRCC Monitor 的具体 pattern。
- #cloudflare
- #workers-ai
- #ai-engineering
- #cost-engineering
- #triage
第一次接触 Workers AI（或任何跑在 edge 的小模型 AI 服务）时，默认心智模型是「用它生成内容」。生成邮件回复。生成总结。生成描述。这是显然的动作——demo 演示的就是这个。
生产里真正付租金的动作是反过来的：Workers AI 作为 INGEST 端的 TRIAGE 过滤器，不是 OUTPUT 端的生成器。这套逻辑在我上线的两个系统里一致 —— Agentic Inbox 和一个内部用的 IRCC 移民情报监控 —— 值得写下来，因为它反直觉。
朴素设计：邮件到达 → 存入 → 用户打开 → 点「Draft」→ Workers AI 生成 → 用户编辑发送。AI 调用在最末端，做最贵的事（长上下文 = 多 token）、最对延迟敏感（用户在等）、最对质量敏感（一封烂回复直接毁信任）。三种失败模式叠在一次调用里。
倒过来的 pattern：邮件到达 → Workers AI 评分（重要性？分类？值得起草吗？） → 带分存入 → 用户打开排序好的 inbox → 重要邮件已经有预生成的 draft → 用户编辑发送。AI 调用在 INGEST，做更便宜的事。
三个原因：
成本不对称 —— Triage 一次 ~300 tokens；生成一次 ~600 tokens。如果 triage 后只对 30% 触发生成，平均下来 480 tokens / 邮件 vs 600 tokens / 邮件。
延迟不对称 —— 用户点「Draft」期待亚秒级响应；用户打开 inbox 看不到 triage 分数。Triage 可以多秒级，没人察觉。把生成挪到 ingest（预生成 draft）后，交互延迟问题变成后台任务延迟问题。
质量不对称 —— Triage 分类器错 5% 是 inbox 排序略不准；生成器错 5% 是发出去的回复带幻觉。小 Workers AI 模型擅长分类、不擅长生成，所以路由规则自己写出来了。
具体在用的 triage 任务：重要性打分（0..1 float）/ 分类（小集合枚举）/ 起草值得性 flag / sentiment / PII 标注 / topic embedding。共同点都是过滤器或标签，不是生成器。
完整成本数学 + 「这是 pattern 而不是规则」+「什么时候真的该用 generation」见 英文版。