文章摘要
文章核心内容：公司升级到前沿模型Opus 4.6后成本反而降低，主要原因是80%的故障由廉价模型Haiku处理，只有20%复杂问题才交给Opus处理，避免了资源浪费。这种分层架构通过廉价代理筛选需求，大幅提升了成本效率。
文章总结
标题：升级前沿模型后，我们的成本反而降低了
上周我们分享了向大语言模型输入TB级CI日志的经验。Hacker News上的讨论焦点并非日志本身，而是关于智能代理：使用哪些模型、如何协调运作以及成本控制。
如今我们采用Opus 4.6模型，总成本反而比使用Sonnet 4.0时更低。关键在于Opus的"不作为"——80%的故障根本不会传递给它，即便到达也无需读取日志。
架构设计如下： [图示：处理管道——Haiku分类器低成本处理80%故障，20%升级至Opus协调器，后者再分配给Haiku工作节点]
廉价代理的预筛选机制
上周分析的4,000例CI故障中，仅818例是新问题，其余3,187例都是已知问题的重复出现（如不稳定测试、基础设施波动等）。使用昂贵模型处理重复问题显然不经济。
我们开发了"分级处理"模式： - Haiku代理专司重复问题识别 - 配备精确匹配和语义搜索(pgvector)双工具 - 不确定时自动升级至Opus处理 这种设计使80%的故障在Haiku层解决，单次处理成本仅为完整调查的1/25。
智能化的上下文获取策略
针对20万行以上的大型日志： - 不直接推送原始日志 - 提供ClickHouse SQL接口 - 代理自主决定查询内容 这种方法既节省token消耗，又避免人为预设干扰调查方向。系统通过响应引导代理逐步深入：当查询结果过多时自动建议使用物化视图；日志未入库时指引使用GitHub CLI。
分层任务执行架构
Opus作为"指挥官"负责： 1. 分析故障现象 2. 形成假设 3. 派遣Haiku子代理执行具体任务 每个子代理获得精确的操作指令，且禁止多级嵌套以防成本失控。
以某次Storybook CI故障调查为例： - 子代理#1获取pnpm安装错误（最终发现是缺失make工具） - 子代理#2分析故障趋势突变（2月25日故障率从0.2%飙升至8%） - 子代理#3验证工作流状态 整个过程Opus无需直接接触任何原始数据。
成本效益分析
- Haiku处理65%的输入token，但仅占36%的LLM支出
- 指挥官模型与工作模型的输入输出比为1:50 vs 1:86
- 取消分层架构将使日成本翻倍
技术演进
半年前Sonnet 4.0尚无法编写正确的ClickHouse查询，Haiku 4.0仅能处理是非判断。如今Opus 4.6已能规划完整调查流程，Haiku 4.5可精准执行限定范围任务。
模式扩展性
该架构可应用于： - 安全日志分析 - IoT遥测数据 - 金融交易监控 未来还将增加第四层"再评估"机制，用于关闭过时结论和验证修复效果。
核心启示：真正的挑战不在于让代理更智能，而在于建立有效的运行控制层。当前仍在优化子代理的调用边界，某些场景下启动子代理的成本反而高于直接处理。
评论总结
总结评论内容：
- 支持"廉价代理筛选"模式的观点：
- 认为该架构能有效降低成本（"4/5的问题无需升级到Opus，成本降低25倍" - 评论1）
- 多位用户表示正在实践类似方案（"用廉价模型做初步决策" - 评论4；"计划自托管模型实现相同目的" - 评论7）
- 对文章表述的批评：
- 认为标题存在"标题党"问题（"为什么不用更真实的架构描述？" - 评论1）
- 多位用户将文章核心简化为"用廉价代理决定是否需要昂贵代理"（评论2/5）
- 技术实现质疑：
- 质疑是否过度使用AI（"基础功能用正则表达式更高效" - 评论3）
- 讨论替代方案（"本地小型SOTA模型可能表现更好" - 评论6）
- 建议改进现有系统（"技能应该能指定使用不同模型" - 评论8）
- 相关讨论延伸：
- 关于调试场景的类比讨论（"为何不提供已知问题线索" - 评论9）
- 对Claude Code的担忧（"担心其会暗中采用类似策略" - 评论10）
关键引用保留： 1. "4 out of 5 failures never reach Opus. A triager match costs around 25x less"（评论1） 2. "Let a cheap agent decide if the expensive one is needed"（评论2/5） 3. "having an agent in the critical path when a regular expression could do just seems odd"（评论3）