加载失败
这篇讨论围绕一篇工程博客：团队在工单/问题排查流程里，用 Anthropic（Claude 系列模型的厂商）的 Haiku（较便宜的小模型）先做 triage，再把少量复杂 case 升级到 Opus（更强但更贵的 frontier model）。文章标题强调“升级到 frontier model 反而降本”，但评论者发现真正省钱的关键是分流机制，而不是单纯把所有请求都交给更强模型。这里还牵涉到 RAG（Retrieval-Augmented Generation，检索增强生成）、embedding model（向量表示模型）以及 32K context 这类基础设施选择：要不要先检索、要不要本地推理、要不要把整张 ticket 直接塞给模型。很多人也把这个流程类比成客服里的 L1/L2 support（一级/二级支持），并争论其中哪些步骤其实应该由普通代码、规则或函数调用完成，而不是 agent。
很多评论认为文章和原始标题都在夸大 Opus 的作用。真正起作用的其实是一个很便宜的 Haiku triager 先判断工单是否已经被跟踪，只有没命中的少数才升级到 Opus。有人直接把整篇内容压缩成一句：让便宜 agent 决定是否需要昂贵 agent，并指出这比把功劳全算到 frontier model 更诚实。也有人补充，文章标题和页面标题本身就不一致，因此更像 clickbait。
另一派讨论把重点放在两阶段路由本身，而不是标题争议。Haiku 只做很窄的 triage：判断问题是否已经存在，若已存在就停在这里；若没有，再交给 Opus 做完整调查。评论里提到这种方法能让 4/5 的失败请求根本不进入 Opus，triager 匹配的成本约为完整调查的 25 倍更低。有人把它类比成 L1/L2 support，也有人说自己会用更便宜的 planner agent 先产出计划和任务，再按任务选择模型，必要时再升级。
也有评论质疑这里把太多本来可以用普通代码解决的事情交给了模型。像“write to clickhouse”“have we seen this before”这类判断，完全可能写成函数调用、规则分支或正则匹配，而不必让 agent 进入 critical path。评论者认为即使 Haiku 很便宜，`re.match()` 仍然更便宜、可控且更容易验证。这个观点的核心不是反对 LLM，而是反对把确定性逻辑包装成不必要的推理调用。
还有人把讨论引向本地小模型和检索方案。有人质疑 RAG 是否已经过时，并认为像 llama-embed-nemotron-8b 这样的本地 SOTA embedding model 可能就足以完成 triage，而且比远程 Haiku 层更便宜。因为工单有 32K context，理论上可以直接把整票 ticket 一次性喂给模型，不必先做额外路由。还有人表示会自托管 qwen3.6 27b 来承担这类分流工作，说明大家在成本、隐私和可控性上仍有替代路线可选。
triager pattern: 先用低成本模型做判断/路由，只有命中条件才升级到高成本模型的设计。
planner agent: 先规划任务、再按任务选择合适模型或步骤的 agent。
RAG（Retrieval-Augmented Generation）: 先从外部知识库检索相关内容，再让模型基于检索结果生成答案。