Spotify Portal 优化 Claude Code token 消耗

AI Coding 的钱大多花在 I/O 上：Portal by Spotify 让 Claude Code token 消耗直降 90% @SpotifyEng 团队发现：Claude Code ...

AI Coding 的钱大多花在 I/O 上：Portal by Spotify 让 Claude Code token 消耗直降 90% @SpotifyEng 团队发现：Claude Code 消耗的 token 中，大量花在了几乎不需要推理的杂活上，包括为回答一个方法的问题读五个文件、照着旁边二十个测试文件的模式再生成一个测试、开完会更新文档。这些工作用前沿大模型来做是 "严重高配"。 Spotify 工程团队找到了解法：把"体力活"路由给便宜的小模型，把前沿模型留给真正需要推理的问题。 engineering.atspotify.com/2026/9/portal-… # 实现：两个 Mode + 一个路由插件 两个声明式 Agent (AiKA Modes) Mode 是 Portal 上的声明式 agent，运行在临时 (ephemeral) 运行时上——作者类比为"给 agent 用的 AWS Lambda"。只需写一份 YAML：指令、模型、温度、MCP 工具，无需管理基础设施和 API key。作者创建了两个，都用 Gemini 2.5 Flash 作为廉价工作模型： · 批量读取器：替 Claude 读多个大文件并回答问题。指令强调只输出结构化要点、每条以确切的名称/类型/行号开头、不要寒暄和铺垫——本质是把大语料压缩成 Claude 能直接消费的摘要。 · 样板代码生成器：生成测试、配置脚手架、类型桩等"输出可以从现有模式预测"的代码。指令要求严格模仿参考文件的模式与风格，且只输出代码。这一句很关键，否则模型会包上 markdown 围栏和解释性文字，Claude 还得再花 token 去解析。 路由的三层设计 (shunt 插件) 最初把路由规则写在 CLAUDE.md 里，但那只是"建议性"的，Claude 可以无视，且每个项目都要复制一份。于是改成了名为 shunt 的 Claude Code 插件，分三层: 1. Hooks：注册 PreToolUse 钩子。文件超过行数阈值 (默认 350 行，可通过 SHUNT_MIN_LINES 配置) 的 Read 调用会被直接拦截，并提示 Claude 改用 bulk-reader；同时拦截 cat/head/tail 等命令对大文件的读取。带 offset/limit 的定向读取和管道命令 (如 cat file | grep) 则放行。 2. Scripts：两个 bash 脚本封装 Portal CLI 调用，处理请求构建、错误解包、token 用量上报。bulk-read 用 XML 标签包裹文件发给 worker；code-write 把生成的代码直接写入磁盘，Claude 全程看不到代码内容。 3. Skills：markdown 技能文件告诉 Claude 何时、如何调用脚本。 # 效果与局限 在一个 Java monorepo 上测试四个场景，bulk-read 平均节省约 90% 的 token。code-write 更难量化，但收益是双重的：省去了读参考文件的输入 token 和生成代码的昂贵输出 token。 局限是其专业性的体现: · 不能委托编辑：worker 的摘要没有可靠的行号，Claude 要改代码仍需直接读取相关段落。委托省的是"理解"的 token。 · 不能委托推理：测试中 worker 模型漏掉了一个微妙的线程安全 bug，而 Claude 拿到正确上下文后几秒就发现了。路由明确排除调试、架构决策和安全关键代码。 · 延迟成本：每次委托是一次网络往返，通常 10–30 秒，且单次调用上限 30 秒。小文件走委托得不偿失，这正是行数阈值存在的原因。 💬 2 🔄 0 ❤️ 1 👀 241 📊 2 ⚡