2026 年 9 月初,Spotify 首席产品经理 Dimitri Mazmanov 在公司工程博客上抛出一篇复盘文章:他用一个叫 Portal 的内部 Agent 平台,把 Claude Code 的 Token 用量砍掉了大约 90%。这个数字之所以值得拆开看,是因为它不是靠压缩模型、靠换更便宜的版本号、靠堆订阅优惠换来的——而是用模型路由把"贵且该用贵的"和"便宜且该用便宜的"两类工作切成两条线,让 Claude 只做需要它的工作,把 I/O 类、模板类、阅读类的体力活外包给一个更便宜的子 Agent。
这个思路的工业级样本价值在于,它不是某位独立开发者在本地 CLI 里自己拼凑的优化,而是一整套部署在工程团队内、可被任何工程师复制、且有可量化基准的结构化方案。它公开了具体的 plugin 代码、Prompt 模板、Hook 配置,以及在 Java monorepo 上跨四种场景的实测数据。对于正在把 AI 编程助手落地到生产链路的企业而言,这篇博客给出的不是单点技巧,而是一套可移植的成本治理范式。
现状:Agent 的开销不是模型推理,而是 I/O
Mazmanov 在文章开头给出了一个看似反常识、其实工程师每天都在承受的事实:Agent 帮我做的大部分事情不是"思考",而是 I/O。为了回答一个方法的问题去读五个文件,为了写一个跟旁边二十个测试长得一模一样的测试文件,为了在开完会之后更新文档——这些动作消耗数千个 Token,几乎没有真正的推理。订阅授权费不是痛点,Token 才是。而这些 Token 全部喂给了一个"严重过配"的前沿模型。
这个观察背后有一组行业级数字作为背景:到 2028 年,AI 编程开销预计会超过一位普通工程师的薪资;四分之一的工程负责人已经在每位工程师身上每月烧掉 200 到 500 美元的 Token 费,部分团队超过 2000 美元。工具的投入是值得的,但前提是停止把前沿 Token 浪费在不需要它们的工作上。这正是 Spotify Portal 这篇文章给出的核心命题:你并不需要一个全新的平台团队或者一笔新的订阅费,你需要的是一套"两模式"的工程化设计,把能外包的外包出去,把必须保留的留下来。
两模式:把问题从"系统工程"压回"配置"
Spotify Portal 的核心抽象叫 AiKA Mode。一个 Mode 是一个声明式的 Agent,跑在临时运行时上——想象一下 AWS Lambda,但是给 Agent 用的。用户声明指令、选模型、设置温度等参数、挂上 MCP 工具,Portal 接管其余的事:不需要管理基础设施,不需要 API key,不需要长连接服务器。Mode 可以从 Portal CLI 或者 API 调用,可以是公开(全公司共享)或私有。
Mazmanov 为这套优化方案创建了两个 Mode,都用 Gemini 2.5 Flash 作为工作模型,但 model 字段接受 Portal 中任何已配置的模型。第一个叫 bulk-reader,专门处理"Claude 会读多个大文件只为一个问题"的场景:它是一个精确的代码分析师,读取提供的文件后给出简洁答案,只输出结构化 bullet,不要寒暄、不要解释、不要前言,每条 bullet 都以准确的名字、类型或行号开头,嵌套 bullet 表示细节。第二个叫 code-writer,负责测试、配置脚手架、类型桩等"输出是可预测的"场景:基于规范和参考文件生成代码,严格匹配现有模式、约定、命名、风格,只输出代码不要解释,不要 markdown 围栏,除非明确要求——如果规范有歧义,就按参考文件的模式做合理推断。
注意 code-writer 模式里那句"只输出代码"的指令至关重要。没有它,模型会把所有内容包进 markdown 围栏和解释性 prose 里,然后 Claude 还得再把这些包装解析一遍。指令本身就是成本治理的一部分——不是模型选择,而是输出形状治理。
三层路由:Hooks、Scripts、Skills 各自承担一件事
第一版路由只是 CLAUDE.md 里的一坨路由规则。它部分能用:Claude 会读这些指令然后自路由到 Portal。但问题很多——规则是建议性的,不是强制性的,Claude 可以忽略它;每个项目都需要一份自己的副本。Spotify 的当前版本是把它做成一个 Claude Code plugin,叫 shunt。委派走 Portal CLI 的 actions 注册中心,所以 plugin 在任何启用了 AiKA plugin 的 Portal 实例上都能工作。
第一层是 Hooks。Claude Code hooks 在每次工具调用前触发。Shunt 注册两个 PreToolUse hook。check-file-size 在每次 Read 调用时触发:如果文件超过可配置的行数阈值(默认 350 行),hook 就阻断这次读取,告诉 Claude 改用 /bulk-reader skill。Targeted read——Claude 已经知道它需要哪一段——会放行。check-bash-read 抓 cat、head、tail、less、more 对大文件的使用。管道命令(cat file | grep)放行,因为它们是 targeted read。阈值通过 SHUNT_MIN_LINES 环境变量配置,可写在 shell profile 或 .claude/settings.json 里。
第二层是 Scripts。两个 bash 脚本封装 Portal CLI 调用。Claude 用具名参数调用脚本,脚本在内部处理请求构造、actions 调用、错误解包,并把 Token 用量回报到 stderr。Mode 按名字寻址,由 Portal 解析——大小写不敏感,优先自己的 Mode,然后团队的,然后公开的。把公开的 bulk-reader fork 成自定义版本,你的版本会自动优先,不需要额外配置。bulk-read 用 XML 标签包住每个文件,清晰划界,然后连同问题一起发给 bulk-reader 模式。bulk-read 的调用示例是 bulk-read --question "What does this service do?" --paths src/Service.java src/Handler.java,跟随问题时再次传同样的 paths——每次委派都是单次调用,调用是临时的(服务端不存任何东西),重发文件在关键意义上是免费的,因为语料进入工作模型,从不进入 Claude 的上下文。code-write 把规范和参考文件发给 code-writer 模式,从输出里剥掉 markdown 围栏,可以直接写盘。Claude 永远不会看到生成的代码。参考文件是必需的:没有可匹配模式的文件,工作模型会生成脱离项目的上下文无关代码。
第三层是 Skills。两个 skill 文件告诉 Claude 何时以及如何调用脚本。Skill 是带描述和使用示例的 markdown 文件。当 hook 阻断读取时,阻断消息指引 Claude 到 /bulk-reader skill,skill 给出准确的调用语法。这种分层让系统优雅降级:即使 Claude 不读 skill 描述,hook 也会阻断贵读取;skill 只是让重定向更顺滑。
实测:Java monorepo 上四个场景、约 90% 节省
基准测试在 Java monorepo 上跑了四个场景,对比 Claude 直接读取文件 vs 通过 bulk-reader 拿总结 vs 通过 code-writer 生成代码时消耗的 Token。平均 bulk-read 节省大约 90%。code-write 场景在 Token 上更难测:没有 shunt 时,Claude 既要读参考文件,又要把输出当作贵的输出 Token 生成;有了 shunt,代码直接写盘,Claude 永远不会看到它。
这个数字要小心解读——它不是 Claude Code 整体 Token 减少 90%,而是"在适合批量读取的场景下、用 bulk-read 替代直接读取"这一窄动作节省的比例。90% 这个量级在工业级场景里依然成立,因为大多数 Agent 编程助手的工作量里,大批量文件读取和重复模板生成占了很大比例,这部分就是 Mode 真正能接管的部分。
不能委派什么:三类硬边界
Mazmanov 明确列出了三件不能外包的事。第一,不能委派编辑:工作模型的总结不含可靠行号,如果 Claude 要基于分析做编辑,它还是得直接读对应段落。Hook 允许 targeted read(offset/limit)就是这个原因——委派节省的是"理解"的 Token,不是"编辑"的 Token。第二,不能委派推理:工作模型只能找到表层模式,会漏掉细微的线程安全 bug;Claude 在拿到正确上下文后几秒就能识别。路由明确排除了调试、架构决策、安全关键代码。第三,延迟会累积:每次委派都是网络往返——Claude Code 到 Portal 后端到工作模型再回来。响应通常 10 到 30 秒,Portal 把单次调用上限设为 30 秒,所以非常大的生成任务需要拆成更小的调用。这对大读取是可接受的,对小读取反而得不偿失。行数阈值的存在就是因为这个——低于阈值时,委派的开销超过节省。
企业级启示:Mode 把模型路由从工程问题压回配置问题
这套思路对企业的最大启示,是它把模型路由从"系统工程问题"压回了"配置问题"。Mode 是可复用的——同一个 bulk-reader 和 code-writer 在每个项目和每个能 shell 到 Portal CLI 的工具上都能工作。Mode 是可共享的——两个 Mode 都在 AiKA 里公开,任何人今天就能用,不需要创建自己的。Mode 是可组合的——你可以为文档写一个 doc-writer mode,为代码评审摘要写一个 reviewer mode,为 i18n 写一个 translator mode,每个 Mode 都是几次点击的距离。Mode 解耦了路由决策和工作执行——plugin 决定何时委派,Mode 决定如何响应。换 Gemini Flash 为更便宜的模型、换 system prompt、加 MCP 工具,plugin 都不需要变。
这是 AiKA Mode 真正的力量:它把模型路由从 systems engineering 变成 configuration。你不需要构建基础设施,你只需要描述你想要什么、给它命名。这件事对所有正在考虑自建 Agent 平台的企业是关键信号——你不必从零搭一个执行层,你可以从一个声明式的 Mode 注册中心开始,让"用什么模型做什么事"变成可以像路由表一样编辑的东西。
社区的不同声音:实测不一定都到 90%
值得注意的是,HN 上有开发者拿自己的 Claude Code 全量 LLM 请求/响应数据集做过类似测量,得到的结果是 token 节省 5% 到 7%,而且 bulk-read 操作实际触发的条件比较苛刻——在他的工作负载里,只有 5.9% 的 unique read 符合 bulk-read 的条件,58% 的读取本来就是 targeted 的。也有评论认为这种优化更适合"已经订阅高价位档、订阅费是固定支出"的用户,而不是按 Token 付费的开发者——订阅档下节省的是速率限制的压力,而不是直接的现金账单。
还有开发者分享了 cursor 的对比观察:同样使用 Opus 系列时,在 cursor 里跑自动化测试,Claude Code 会重复观察任务和上下文然后才开始测试,这个问题在 cursor 里不出现。这说明 Agent harness 本身的设计选择——何时观察、何时动手、是否复盘——对 Token 消耗的影响可能跟模型选择同等重要。这呼应了 Spotify 这篇博客隐含的判断:成本治理不能只靠换模型,必须在 harness 层做工程化的路由和分流。
可移植的工作流:三层架构是落地的最小可复用单元
把 Spotify 这套思路提炼成一个可移植的最小工作流,关键不是 portal 这个具体产品,而是三层架构本身:Hooks 强制执行、Scripts 封装调用、Skills 描述调用方式。任何企业的 Claude Code 部署都可以引入这套分层——Hooks 把"是否走捷径"的决定从 Claude 手上拿过来变成强制规则,Scripts 把"具体怎么调用子 Agent"封装成确定性的命令,Skills 把"何时使用"翻译成 Claude 能读懂的说明。三层叠加,才能实现"优雅降级":即使 Claude 没读 Skill 描述,Hook 也会阻断贵读取;Skill 只是让重定向更顺滑。
这套工作流在企业落地时的另一个价值,是它把优化责任明确归到基础设施层:不再依赖每位工程师自律地使用某种模式,而是由 plugin 强制把不该走主模型的请求转走。这对管理数十位甚至上百位工程师的 AI 工具使用、把 Token 预算作为部门级 KPI 来考核的团队尤其关键——单纯发"使用建议"是无用的,只有把建议变成代码里的强制规则,才能保证预算不被无声的 I/O 耗光。
工业级 vs 个人玩具:可被复用的门槛
把这篇 Spotify 博客和散见于 HN 上的个人优化尝试放在一起看,工业级样本和个人玩具之间的差距不在于想法是否聪明,而在于四件事。第一,声明式抽象——Mode 让"用什么模型做什么事"成为可配置项,而不是写死在代码里;第二,强制执行层——Hooks 把决策从模型移到基础设施,消除了"模型会不会遵守"的赌博;第三,统一注册中心——公开 Mode 让团队里任何人都能复用,不必每个人都重建;第四,可量化基准——在 Java monorepo 上跨四个场景的实测给出了可对照的数字,而个人尝试通常只报一个节省百分比。
这四条对正在考虑"我们部门怎么管 AI 编程工具成本"的负责人是直接的清单:你是否有一个声明式的 Agent 注册中心?你是否有强制执行的 Hook 而不是建议文档?你的优化能力是否能被团队复用而不是各自重建?你是否能在标准场景下给出可对照的基准?四个问题的回答状况,决定了你的 Agent 治理是工业级还是手工艺级。
