Spotify 实测：让便宜模型替 Claude Code 干杂活，token 用量砍掉 90%

Spotify 实测：让便宜模型替 Claude Code 干杂活，token 用量砍掉 90%

AI 编码 Agent 干的活，大部分不是思考，是 I/O——那为什么全喂给最贵的模型？

Spotify 工程博客 9 月 3 日发了一篇很有说服力的实践文章，作者 Dimitri Mazmanov（首席产品经理）开门见山地戳破了行业里一个没人细算的账：

你的 AI 编码 Agent 做的大部分事情不是思考，而是 I/O。为了回答一个关于某个方法的问题读五个文件；照着旁边二十个测试文件的模式生成一个新的测试文件；开完会更新文档。几千 token 花出去，推理量几乎是零。真正让你肉疼的不是席位费，是 token——而你把这一切都喂给了一个严重过配的前沿模型。

这不是他一个人的问题。Gartner 今年 6 月的预测说，到 2028 年 AI 编码成本将超过开发者平均工资——因为 token 消耗在暴涨。四分之一的工程负责人目前每月每开发者烧掉 200 到 500 美元的 token，有些团队已经超过 2000 美元。工具确实值回票价，但前提是：别再把前沿模型的 token 烧在不需要它的活上。

他的解法不需要平台团队，不需要新订阅——就两个"模式"。实测下来，Claude Code 的 token 用量降了约 90%。

本文提纲

  1. 核心思想：任务分层，模型分级
  2. 两个模式：bulk-reader 与 code-writer
  3. AiKA Modes 是什么：给 Agent 的 Lambda
  4. 路由怎么落地：shunt 插件的三层架构
  5. 从"建议"到"强制"：CLAUDE.md 教训
  6. 90% 怎么测出来的
  7. 诚实清单：三件不能外包的事
  8. 更大的图：路由从工程问题变成配置问题
  9. 怎么试

核心思想：任务分层，模型分级

思路一句话讲完：把编码任务分成两类。

I/O 型——读多个文件回答一个问题、照模板生成测试、写配置脚手架。特征是"输入输出大、推理少"，便宜模型完全胜任。

推理型——调试、架构决策、发现隐蔽 bug。这才是前沿模型该干的事。

于是架构变成两层：Claude Code 继续当"指挥官"负责推理，I/O 型杂活打包委托给一个便宜的工作模型。作者选的是 Gemini 2.5 Flash（温度 0.2），但工作模型字段接受任意已配置的模型。

两个模式：bulk-reader 与 code-writer

委托的目标端，是 Portal by Spotify 里定义的两个 AiKA Mode。

bulk-reader，承接"读多文件答一问"。系统提示词很讲究：

name: bulk-reader
description: Bulk file reader for code analysis
  - delegates I/O from Claude Code
instructions: You are a precise code analyst. Read the
  provided files and answer the question concisely. Output
  structured bullets only. No greetings, no prose, no
  preambles. Lead every bullet with the exact name, type,
  or line number. Use nested bullets for details. Skip
  anything the caller did not ask for.
model: gemini-2.5-flash
resourceLimits:
  temperature: 0.2

注意提示词里的反 AI 味设计：只要结构化要点，不许寒暄不许铺垫，每条要点必须以准确的名字、类型或行号开头——因为这份摘要的消费者是 Claude，不是人，省它的 token 就是省你的钱。

code-writer，承接"照葫芦画瓢"型生成：测试文件、配置脚手架、类型桩。规则是"只输出代码，不要解释，不要 markdown 围栏"——少了这句，工作模型会包一层说明文字，Claude 还得再花 token 去解析。

AiKA Modes 是什么：给 Agent 的 Lambda

Portal 是 Spotify 商业化的开发者门户（Backstage 的产品化版本），AiKA 是其中面向 AI 的插件。Mode 的官方定义是：运行在临时运行时的声明式 Agent——你可以理解成"给 Agent 的 AWS Lambda"。

声明式意味着你只填一张表：指令、模型、温度等参数、要不要挂 MCP 工具。没有基础设施要管，没有 API key 要存，没有长驻服务器。模式通过 Portal CLI 或 API 调用，可以设为 public（全公司共享）或 private。这个"临时性"后面还有妙用，先按下不表。

路由怎么落地：shunt 插件的三层架构

关键问题：怎么让 Claude Code 心甘情愿地把手上的活交出去？作者的方案演进过一版，先说结论版——一个叫 shunt 的 Claude Code 插件，三层结构：

MERMAID_BLOCK_0

第一层：Hooks，强制拦截。 shunt 注册了两个 PreToolUse 钩子。check-file-size 挂在每次 Read 调用前——文件超过行数阈值（默认 350 行）就直接拦截，告诉 Claude 改用 bulk-reader 技能；带 offset/limit 的精准读取放行。check-bash-read 则盯住 cat、head、tail、less、more 这些"用 shell 命令绕路读大文件"的姿势；管道命令（cat file | grep）算精准读取，放行。阈值可通过环境变量 SHUNT_MIN_LINES 调整。

第二层：脚本，委托执行。 两个 bash 脚本封装 Portal CLI 调用：

# 读文件答题
bulk-read --question "What does this service do?" \
  --paths src/Service.java src/Handler.java

# 照模板生成代码，直接写盘
code-write --spec "Write tests for UserService" \
  --reference tests/OrderTest.java --target tests/UserTest.java

bulk-read 把每个文件包上 XML 标签（边界清晰）连同问题一起发给模式；code-write 要求必须给参考文件——没有参照物，工作模型会生成与项目格格不入的"无上下文代码"。模式按名字解析，优先级是自己的 > 团队的 > 公共的：fork 公共模式改一版，你的版本自动接管，零配置。

第三层：Skills，平滑引导。 两个技能文件告诉 Claude 何时、如何调脚本。妙处在于分层降级：就算 Claude 没读技能说明，Hook 依然会拦截昂贵的大文件读取——第三层只是让转向更顺滑，不是系统的依赖项。

从"建议"到"强制"：CLAUDE.md 教训

值得单独拎出来的经验：作者第一版方案是把路由规则写在 CLAUDE.md 里。效果"勉强能跑"，但有两个致命伤——规则是建议性的，Claude 可以不理；而且每个项目都要复制一份。

这个教训对所有做 Agent 工程的人都适用：引导性提示词管方向，强制性 Hook 管底线。成本控制这种"不做就亏钱"的事，必须放在 Hook 这种不可绕过的层，而不是指望模型的自觉。

顺带解释前文那个"临时性"的妙处：每次委托都是一次性的，服务端不存任何东西。追问时把同一批文件重发一遍听起来浪费，其实免费——因为这批语料只进工作模型的上下文，从不进入 Claude 的上下文。

90% 怎么测出来的

基准测试在一个 Java 单体仓库上跑，四个场景，对比"Claude 直接读文件"和"消费 bulk-reader 摘要"两边的 token 消耗。bulk-read 的平均节省约 90%。

code-write 场景更夸张但更难量化：不用 shunt 时，Claude 既要把参考文件读进上下文（贵的输入 token），又要自己生成全部代码（更贵的输出 token）；用 shunt 后代码直接落盘，Claude 从头到尾没见过生成的代码。

诚实清单：三件不能外包的事

这篇文章的可信度一半来自数字，另一半来自作者自己列的失败清单：

不能委托编辑。 工作模型的摘要不含可靠的行号。Claude 要基于分析改代码时，还是得直接读那一小段——所以 Hook 放行了带 offset/limit 的精准读取，委托只省"理解"的 token，不省"修改"的。

不能委托推理。 工作模型能找到表层模式，但漏掉了一个隐蔽的线程安全 bug；Claude 拿到正确上下文后几秒就发现了。所以路由明确排除调试、架构决策和安全关键代码。

延迟会累积。 每次委托是一次网络往返：Claude Code → Portal 后端 → 工作模型，单次响应通常 10 到 30 秒，Portal 还给单次调用设了 30 秒上限。大读取值得等，小文件反而不划算——行数阈值就是为这个存在的，低于阈值时委托的开销超过节省。

更大的图：路由从工程问题变成配置问题

作者最后把视角拔高：shunt 插件只是 Claude Code 的一个工件，底下真正承重的是"AiKA Modes 驱动的模型路由"。这套模式有四个可复用特性：

  • 可复用：同一套 bulk-reader / code-writer 在所有项目、所有能调 Portal CLI 的工具里通用
  • 可共享：两个模式已设为 public，全公司即取即用
  • 可组合：再配 doc-writer（文档）、reviewer（评审摘要）、translator（国际化）模式，都是几次点击的事
  • 决策与执行解耦：插件决定"何时委托"，模式决定"怎么响应"。换更便宜的模型、改系统提示词、加 MCP 工具——插件一行不用动

一句话总结：AiKA Modes 把模型路由从系统工程问题变成了配置问题。你不用搭基础设施，只要描述你想要什么，然后给它起个名字。

这个判断与我们此前梳理的趋势相互印证：AI Agent 2026 全景指南里"模型路由"已被列为生产部署的标准模式；NVIDIA PAIR 在做跨机器的算力路由，Spotify 在做跨模型的成本路由——同一个"路由"思想在两个维度上展开。区别在于，PAIR 需要一整套网络配对基础设施，而 Spotify 的答案是几张声明式配置表。

怎么试

shunt 和 portal 插件都在 spotify/portal-ai-plugins 开源（shunt 在 add-shunt-claude 分支），Claude Code 三条命令装完：

claude plugin marketplace add spotify/portal-ai-plugins
claude plugin install portal@portal
claude plugin install shunt@portal

新会话里跑 /portal:setup 完成 Portal CLI 认证，然后直接问一个跨多文件的问题就能看到效果。bulk-reader 和 code-writer 两个模式已是公共的，无需自建；想换工作模型或改指令，fork 一份自己的版本，优先级自动生效。

需要注意的是 Portal 本身是商业化产品，认证要有自己的 Portal 实例。但这套架构的骨架——Hook 拦截 + 脚本委托 + 技能引导 + 声明式模式——并不绑定 Spotify，拿任意一个便宜模型的 API 也能照方抓药。

原文：Portal by Spotify cut my Claude Code token usage by 90%（Spotify Engineering，2026-09-03，Dimitri Mazmanov）

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。

posted @ 2026-09-06 09:19  iTech  阅读(20)  评论(0)    收藏  举报