We decreased our LLM costs with Opus

远不会到达它，而当它们到达时，它也不会读取日志行。该架构如下所示：让一个便宜的代理决定是否需要昂贵的代理上周我们分析了大约 4,000 个 CI 故障。

核心内容

818 是新问题。另外 3,187 个是再次出现的已知问题：不稳定的测试、基础设施故障、我们已经检测到的网络故障。当 80% 的情况下答案是“它是重复的”时，唤醒昂贵的模型是没有意义的。不幸的是，我们无法确定性地检测重复项：同一个作业可能会由于完全不同的原因多次失败，因此您需要实际查看日志以了解您以前是否见过这种情况。我们最初使用 Sonnet 来平衡成本和性能。它确实有效，但它是两全其美的最糟糕的：仍然昂贵，而且结果不如前沿模型。我们切换到“分类器”模式：一个俳句代理，其工作非常具体和狭窄。这个问题是否已经被追踪？如果是的话，就停在那里。如果没有，请升级到 Opus。事实证明，用俳句检测重复项有点具有挑战性。我们需要使这项工作尽可能简单，因此我们将错误消息附加到以前的失败中，并为 Haiku 提供了两种搜索工具：已知错误片段的精确匹配，以及针对相似但不相同的错误的语义搜索 (pgvector)。

RAG 已经死了，但语义搜索非常简洁。运算符不存在 bigint 字符变化和 Installation_id 上的迁移类型不匹配是不同的字符串，但根本原因相同，语义搜索表明了这一点。

Haiku 代理读取日志、搜索错误消息、尝试匹配已知故障并进行调用。当有疑问时，事情就会升级。误报会花费一点钱；假阴性意味着我们错过了一些真实的东西。五分之四的失败永远不会到达 Opus。分类匹配的成本比全面调查低 25 倍左右。让代理拉取上下文，而不是推送它 有几个人问我们如何处理超过 200K 行的日志。我们不会将他们推入提示。我们为代理提供了 ClickHouse 的 SQL 接口，并让它询问需要什么。原因不仅仅是代币成本。如果您向代理提供一组特定的日志行，那么您在知道问题实际是什么之前就已经对相关内容做出了判断。代理会锚定您所提供的内容。如果真正的原因在其他地方，你就更难找到它了。

这与您不想通过说“我认为问题出在这个文件中”来引导调试会话的原因相同：您在调查开始之前就已经产生了偏见。上周我们详细介绍了 SQL 设置，但简短的版本是：有一个包含原始数据的表（github_logs，每个日志行一行）和一组包含预聚合数据的物化视图：按工作流划分的失败率、作业计时、结果计数。大多数调查都是从物化视图开始，以缩小原因范围，然后在需要时深入研究原始日志。我们不告诉代理要查询哪个表。相反，我们使用响应本身来逐步指导它。如果查询返回太多行，我们会截断并建议更具体的物化视图。如果日志尚未提取，我们会将其指向 GitHub CLI。智能体可以计算出它需要什么，而我们不必提前预测每条路径。昂贵的代理计划，廉价的代理完成工作 Opus 会查看失败的内容，形成假设，并产生 Haiku 子代理来进行实际的挖掘。每个子代理都会收到来自 Opus 的提示：确切地搜索什么、如何搜索、返回什么。子代理的深度上限为一层；他们不能产生自己的子代理。无限制的扇出是导致成本失控的原因。几周前，三个 Storybook CI 作业在同一次提交中失败，全部在 pnpm install 处崩溃。

Opus 首先要求子代理从失败的 pnpm 安装步骤中获取错误消息。

ClickHouse 还没有日志，因此子代理退回到 GitHub CLI。子代理 #1 提示：获取本次运行的 CI 日志。返回 pnpm install 步骤中的确切错误消息、完整错误输出，尤其是最后 50-100 行。结果：gyp 错误！未找到：制作 .

re2@1.23.0 无法编译，因为 make 不在运行程序上。

Opus 搜索了现有见解（没有匹配），然后向 ClickHouse 查询 14 天内的故障趋势： 2 月 23 日：0.2% 故障率 2 月 24 日：1.1% 2 月 25 日：8.0% <- 拐点 2 月 25 日发生了明显变化。Opus 催生了子代理#2：调查 2 月 24 日至 25 日左右发生的变化。故障率从 0.2% 降至 8%。错误是gyp ERR！未找到：制作 .在该窗口的工作流文件和 package.json 上运行 git log。构建依赖项已在不相关的迁移期间被删除。对于该迁移来说是正确的，但 re2 仍然需要 make 来进行本机编译。

Opus 生成了子代理 #3 来验证当前工作流程状态，然后创建包含根本原因和修复的见解。编排器从不读取一行日志、git 历史记录或代码本身。有几点值得注意： 成本。

Haiku 处理约 65% 的输入代币，但仅占我们 LLM 支出的约 36%。昂贵的模型认为；廉价型号读取。如果没有模型层次结构，每日账单将增加一倍以上。

Opus 计划按计划进行。它从一个假设开始，但每个子代理的结果决定下一步。在这次调查中，它得到了错误，搜索历史记录，然后询问发生了什么变化。每一轮都会通知下一轮。我们超过三分之一的调查是多轮的，新问题需要的调查深度大约是已知问题的两倍。环境卫生。编排器的上下文保持干净：来自子代理的结构化摘要，而不是原始日志输出。每个子代理都从一个干净的状态开始，完成后其上下文将被丢弃。工具调用输出会快速累积，而会话早期的陈旧上下文会降低以后的决策质量。定向搜索。

“从 pnpm 安装步骤返回确切的错误消息”与“分析这些日志”是一个非常不同的提示。

Opus 决定寻找什么；俳句找到了。

Haiku 的输入/输出比为 86:1（大量阅读，返回重点摘录），而协调器约为 50:1（综合和决定）。

Haiku 吸收了数据，因此 Opus 不需要这样做。这在 6 个月前是不可能的。