2026 年 9 月 4 日,Spotify 工程团队在 Spotify Engineering Blog 发布《Portal by Spotify cut my Claude Code token usage by 90%》,文章被推到 Hacker News 首页 277 分、51 条评论。这篇文章由 Spotify Principal Product Manager Dimitri Mazmanov 撰写,详细披露了 Spotify 内部"Portal"平台上一个叫"Shunt"的 Claude Code plugin——通过 PreToolUse hooks 把 Claude Code 的"读文件"和"写代码"两类任务自动 delegate 给 Portal 后端的 Gemini 2.5 Flash worker mode,在 Java monorepo 4 scenarios 测试里平均 token 消耗降低约 90%。这篇文章的工程价值在于它首次由一家头部互联网公司的工程团队系统披露"如何用一个轻量级 hook 体系把 Claude Code 的 token 消耗砍掉 90%",同时完整呈现了 Spotify 团队的工程取舍、测得数据、未覆盖的边界。结合 9 月 Unblocked 团队披露的"迁 GLM 后 token 降 68%"和 6 月 HN 上《Bad MCP design costs your agent 5x more tokens》的 5x token 差距实证,三件事合起来,把企业 AI Agent 落地中"token 优化"这件被多数工程师低估的事,第一次摆到工程基线应该有的位置上。
## 一、Shunt 要解决的核心问题
Spotify 团队的诊断非常直接——"Most of what an AI coding agent does for me isn't thinking. It's I/O."AI coding agent 大部分时间不是在 reasoning,而是在做 I/O。读 5 个文件回答关于一个 method 的问题、生成一个跟旁边 20 个 test 文件完全遵循相同 pattern 的 test 文件、会后更新文档——这些任务消耗数千 token 但几乎没有 reasoning。Seat license 不是问题,token 账单才是。
Spotify 在文章里披露了行业级数字——到 2028 年,AI coding 成本会超过 average developer salary;四分之一的 engineering leaders 已经在 tokens 上每月每个 developer 烧 200 到 500 美元,有的超过 2000 美元。tooling 自我支付得起,但只在你不把 frontier tokens 浪费在不需要它们的工作上时成立。
这条诊断的工程含义极其具体——Claude Code 在被滥用时,被用在"读取 + 输出"这种 I/O 工作上,而这些工作用 Gemini 2.5 Flash 这种 worker model 就能做。Claude 这种 frontier model 应该在 reasoning、debugging、architectural decision 上发力,而不是读 5 个文件做 summary。
## 二、Shunt 的核心架构
Shunt 是一个 Claude Code plugin,通过 PreToolUse hooks 把任务 delegate 给 Portal。架构分五层。
第一层,PreToolUse hooks 拦截 Claude 的 Read 和 Bash 调用。Read hook 触发条件是文件行数超过 configurable threshold(默认 350,通过 SHUNT_MIN_LINES env var 或 .claude/settings.json 配置)。targeted reads(offset / limit)pass through,因为 Claude 知道它需要哪一段。Bash hook 触发条件是 cat / head / tail / less / more 等命令作用在大文件上;piped commands(cat file | grep)pass through,因为这是 targeted read。
第二层,Skill files 引导 Claude 调用 scripts。当 hook 拦截一次 read,block 消息会告诉 Claude 用 /bulk-reader skill,这个 skill markdown 文件带 description 和 usage examples。Skill 的存在让 Claude 知道下一步该调哪个 bash script。
第三层,Bash scripts 包装 Portal CLI 调用。Spotify 写两个 bash scripts(bulk-read 和 code-write),Claude 调用 script 时用 named arguments,scripts 在内部处理 request building、actions invocation、error unwrapping、token usage reporting to stderr。这层把 Claude Code 的简单 CLI 调用和 Portal 的复杂 API 调用隔开。
第四层,Portal CLI 走 actions registry。Delegation 走 Portal CLI 的 actions registry,所以 plugin 适配任何启用了 AiKA plugin 的 Portal 实例。这层让 Shunt 不绑死在 Spotify 内部 Portal,可以接任何 Portal 兼容的 backend。
第五层,AiKA modes 跑在 ephemeral runtime。Modes 是 declarative agent,跑在 ephemeral runtime(像 AWS Lambda,但 for agents)。Mode 定义 instructions、选 model、设 parameters(温度等)、attach MCP tools。Portal 处理剩下的事——no infra to manage。Modes 是 reusable、shareable、composable,跨项目、跨团队、跨工具都能用。
## 三、两个 Mode 的设计
Spotify 给出两个具体 mode 示例,都是 Gemini 2.5 Flash 作 worker,但 model 字段接受任何 Portal 配置的模型,用户可以选自己需要的。
第一个 mode 是 bulk-reader,用于 Claude 要读多个大文件回答一个问题。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 not directly relevant to the question."这条 instruction 至关重要——output 必须 concise、structured、no prose,这样 Claude 拿到的 summary 才是可直接 consume 的。
第二个 mode 是 code-writer,用于 tests / config scaffolding / type stubs 这类 output 从现有 pattern 可预测的任务。Instructions:"You generate code files based on a spec and reference files. Match the existing patterns, conventions, naming, and style exactly. Output only the code — no explanations, no markdown fences unless asked. If the spec is ambiguous, make reasonable choices that match the conventions."
"That 'output only the code' instruction matters," 文章直接点出——没这条,worker model 会把一切都包在 markdown fences + explanatory prose 里,Claude 还得 parse 一次,token 节约被抵消。
## 四、Token 节省的实测数据
Spotify 在 Java monorepo 跨 4 scenarios 测了 bulk-read savings,平均节省"a whopping 90%"。具体场景是测量 Claude 直接读文件 vs 用 bulk-reader summary 的 token 差。
code-write 场景更难直接用 token 衡量,因为没 shunt 时 Claude 既读 reference 文件又生成 output tokens,而 output tokens 是昂贵的。With shunt,代码直接写盘,Claude 永远看不到生成的代码本身。这条机制让 Claude 的 context window 完全省掉了 code-write 阶段的 output token 消耗——不是节省 90%,是几乎完全消失。
但文章也坦诚列出了"What doesn't work"——这是 Shunt 设计的边界。
第一个不能做的是 delegate editing。Worker model 的 summary 不带 reliable line numbers,如果 Claude 需要基于 analysis 做 edits,还得直接读具体 section。Hooks allow targeted reads(offset / limit)就是这个原因,即使 delegation 节省了 summary 的 token,editing 阶段还是会回到 Claude 自己读。
第二个不能做的是 delegate reasoning。Worker model 在 Spotify 测试中只发现 surface-level pattern,missed a subtle thread-safety bug。Claude 在拿到 right context 后几秒内就 spotted。Routing 显式 exclude debugging、architectural decisions、safety-critical code——这些必须由 frontier model 做。
第三个限制是 latency。每个 delegation 是 network round-trip(Claude Code → Portal backend → worker model → back),响应通常 10-30 秒,Portal 给单次 invocation cap 30 秒,very large generation 需要拆成 smaller calls。这条延迟对绝大多数 task 是 acceptable,但对 latency-sensitive 的 debugging 路径不行。
## 五、HN 评论的反向视角
HN 评论区出现一些值得借鉴的反对意见。TOP1 反对意见:"So this is just delegating certain work to dumber models? I certainly wouldn't use Gemini 2.5 Flash (!!?) for code writing as suggested." 这条评论质疑"用更便宜 model 做 code writing"是否会带来 quality 损失。
TOP3 的评论更冷静:"Isn't this a somewhat standard multi-model setup? there's nothing ground breaking here, just delegate claude to plan → smaller model for implementation." 这条评论指出 Shunt 不是突破性创新,只是 multi-model setup 的工程化实现。
TOP5 直接打脸:"So nothing about accuracy or actual performance? At least run against DeepSWE bench or something." Spotify 没在 accuracy / functional correctness 上 evaluate Shunt,只在 token consumption 上 evaluate。这条批评很关键——任何 token optimization 都必须配套 accuracy benchmark,否则就是以功能正确性换 token 节省,可能反而损害业务价值。
TOP4 提到一个被忽视的事实:"It cuts token usage because they are using a different service with a different token budget for the reader/code writer tasks." 换句话说,token 节省的来源是"用更便宜 model",而不是 Shunt 本身的技术创新。这条评论让 Spotify 的 90% 数据有点"水分"——90% 节省里有多少来自 routing 优化、多少来自 model swap,Spotify 没拆解。
## 六、把 Shunt 放进 Agent Token 优化的产品矩阵
把 Shunt 跟同期其他 Agent token 优化方案放在一起,可以看到 token 优化正在分裂成清晰的层次。
Model swap 层是 Unblocked 团队从 Anthropic Opus 迁到 GLM 5.2 的实践:per-task 68% 节省(per-token 95% 节约 + GLM 更多 token-per-task 抵消 = 实际 68%)。这条路径跟 Shunt 用 Gemini Flash 是同类思路——用更便宜 model 做 worker task。
Tool design 层是 Bad MCP design 的 5x token 差距实证——同 Pass Rate 但 input tokens 差 4.98 倍。这条路径跟 Shunt 是互补——Shunt 优化 routing,Bad MCP 优化 tool design。
Routing optimization 层是 Shunt 自身——PreToolUse hooks 拦截特定 tool 调用,delegate 给 Portal 后端。这条路径用 hook 强制实现,不依赖 model 自己 routing。
Benchmark 层是 BaxBench / Terminal-Bench Science / Grep vs LSP——提供 token 优化的 accuracy baseline,任何 token 优化必须配套跑这些 benchmark。
四个层次里,Shunt 命中 routing optimization 层。但 Spotify 必须补 accuracy benchmark 才能让 90% 这个数字有 production 说服力。
## 七、企业 Coding Agent token 优化的具体 checklist
把 Shunt + Unblocked + Bad MCP 三件套合起来,企业 Coding Agent token 优化应该满足如下 checklist。
第一条,任何 token 优化必须配套 accuracy benchmark。Pass Rate、Functional Pass@1、Insecure-and-Correct Rate 必须同时报告,不能只看 token 减少。
第二条,token 优化必须按 task type 拆分。Simple localization、reference-completeness、reasoning、debugging、code-writing 的 token profile 不同,统一 optimization 不可取。Shunt 自己显式 exclude debugging / architectural decisions / safety-critical code,这是对的。
第三条,model swap 必须 measured cost per task,而不是 per-token。Unblocked 团队的 per-token vs per-task 差距 27 个百分点教训值得每个企业记——per-token 数学告诉你能省 95%,per-task 账单告诉你只省 68%。
第四条,tool design 必须 enforced progressive disclosure。Bad MCP 实证直接证明不过滤的 API response 让 token 多花 5 倍。
第五条,routing optimization 必须 hook-driven,不能 advisory。Shunt 第一版是 CLAUDE.md 里的 advisory rules,Claude 能 ignore;第二版是 PreToolUse hooks,Claude 不能 ignore。Advisory vs enforced 是 token 优化成败的关键。
第六条,worker mode 必须 explicit output shape。"Output only the code",no markdown fences,no prose——这些 explicit instructions 是 token 节省的关键。
第七条,delegation latency 必须 acceptable。10-30 秒 round-trip 对大多数 task 没问题,但 debugging 和 latency-sensitive 路径不能用 worker mode。
第八条,targeted reads 必须 pass through。Offset / limit 参数让 Claude 跳过 delegation 直接读自己需要的那段,避免所有 read 都走 worker。
第九条,worker mode 必须 shareable。Spotify 把 bulk-reader 和 code-writer 作为 public modes 放在 AiKA,任何人都能用。Shareable mode 让 best practice 在组织内 reuse,不必每个团队重写。
第十条,token optimization 必须 preserved accuracy budget。任何 token 优化都必须在 Pass Rate / Functional Correctness 上保持 baseline,不允许以损害业务价值换取成本节省。
## 八、下一步:Agent Token Optimization 成为 Agent 落地的入场券
把这件事放到更大的图景里看,Agent token optimization 正在从"成本优化"过渡到"Agent 落地入场券"。早期 Agent 部署假设 token 不计成本;接下来一年内,任何严肃的企业 Agent 部署都会要求 token cost 在可接受区间,因为 AI coding 成本已经接近 average developer salary。
Shunt、Unblocked 迁 GLM、Bad MCP design 优化——这些独立实践合起来,把 Agent token 优化的工程基线推到 production-ready 状态。任何 enterprise Agent 平台都会问两个问题:token cost per task 是多少?Pass Rate / Functional Correctness 是否保持 baseline?答案决定了 Agent 能否承担关键业务。
回到一开始的问题——Spotify Portal Shunt 把 Claude Code token 砍 90% 这件事,首次由头部公司系统披露"如何用 hook + mode routing + worker model 把 token 优化推到生产可用"。剩下的是企业 IT 在落地时把十条 checklist 都做对,把 token optimization 从"开发者经验"升级为"标准化工程基线"。这是 2026 年下半年 Agent 工程走向成熟的标志,也是企业 AI 真正能承担关键业务的入场券。
