--- title: "Spotify shunt 评测：安装、Token 节省与限制" canonical: https://wavect.io/zh/blog/spotify-shunt-claude-code-token-routing/ language: zh description: "详解 Spotify shunt 如何为 Claude Code 分流大文件读取：Portal 前提、90% 基准的真实范围、Hook 限制、辅助模型费用，以及两周试点的验收方法。" image: "https://wavect.io/img/blog/headers/header_spotify-shunt-claude-code-token-routing.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年9月12日 最近审核 2026年9月12日 [**下一篇**](/zh/blog/smarter-token-usage-with-your-ai-coding-agent/) # Spotify shunt 评测：Claude Code Token 节省、安装与限制 要点速览 Spotify shunt 通过 Portal 的 AiKA 模式委派大文件读取和模式明确的代码生成。公布的 90% 指特定读取场景下估算的 Claude 上下文 Token 节省，不是全部费用降低。使用它需要经过认证、启用 AiKA 的 Portal 实例、可访问的模式以及已配置模型。Read Hook 控制受支持的读取，而 code-writer 仍由 Skill 引导。采用前应测量辅助模型费用、缓存、延迟和验证成本。 **如果 Claude Code 经常为了回答一个具体问题而反复读取大文件，Spotify shunt 值得试用。但它并不能证明你的 AI 编程总账单会下降 90%。** 真正需要判断的是：更便宜的辅助模型能否提供足够准确的上下文，而且不会把成本转移到审核和返工上。 [Spotify 的工程文章](https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90) 介绍了 Portal 中的两个 AiKA 模式：`bulk-reader` 根据文件回答具体问题，`code-writer` 参考现有文件生成模式明确的代码。示例使用 Gemini 2.5 Flash，温度设为 0.2。这些是可以调整的辅助模型配置，不是要求你替换负责主要编程任务的 Claude。 本篇是根据公开资料进行的分析，核查日期为 2026 年 9 月 12 日，不是 Wavect 的生产环境实测。这里的工具是 **`spotify/portal-ai-plugins` 中的 shunt**，不是其他同名项目。通用的缓存、批处理和日常成本管理，请阅读 [编码智能体 Token 成本指南](/zh/blog/smarter-token-usage-with-your-ai-coding-agent/) 。本文只解决一个更具体的问题：Spotify 的文件读写委派何时真正划算？ **独立性与商标声明:** 本页由 Wavect 发布，Wavect 自身也是服务商，因此我们对本页存在商业利益。我们与本页提及的其他公司没有关联，未获得其背书，也不是其合作伙伴；所有第三方公司名称、品牌与商标均归各自所有者所有。关于其他服务商的陈述来自公开可查的来源，主要是其自己发布的页面，以本页标注的核查日期为准，此后可能已经发生变化。做决定前请自行直接核实。本页依据我们所知的情况撰写，并力求保持客观。如果你认为其中有不准确或不公平之处，请写信告诉我们，我们会更正： [office@wavect.io](mailto:office@wavect.io) ## 所谓节省 90%，到底测量了什么？ 先看分母。公开的 [基准测试说明](https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/evals/benchmarks.json) 把目标定义为 Claude 上下文 Token 的节省，并采用**字符数除以四**估算代码 Token。这是近似值，不是模型服务商的计费记录。仓库提供的测试样例是 TypeScript 文件，也不是公布结果所用的 Java 单体仓库。因此，运行这些样例不等于精确复现原始实验。 [shunt README](https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/README.md) 公布了一个包含 162,000 行代码的 Java 仓库的测试结果： | 公布的场景 | 读取行数 | 不使用 shunt | 使用 shunt | 发布方报告的节省 | | --- | --- | --- | --- | --- | | 单个大文件 | 4,014 | 33,684 Tokens | 5,737 Tokens | 82% | | 源码与测试文件 | 7,408 | 75,990 Tokens | 4,148 Tokens | 94% | | 跨服务读取多个文件 | 1,281 | 16,221 Tokens | 821 Tokens | 94% | README 将平均节省描述为 90%。独立的代码生成场景记录了 833 行代码直接写入磁盘，却没有给出可比较的节省百分比。**这张表并未证明 Claude、辅助模型、平台和工程人力的合计成本降低了 90%。** 表中的百分比保留发布方原值，不应视为 Wavect 独立重新测量的结果。 可以用一个明确假设的例子理解区别：原来 Claude 接收 40,000 个 Token；现在辅助模型读取这 40,000 个 Token，输出 4,000 个 Token 的摘要，再由 Claude 接收摘要。Claude 的阅读上下文减少了 90%，但两个模型合计处理了 48,000 个 Token，还没有计入其他开销。由于单价不同，总费用仍可能下降。上下文减少和账单减少，是两件事。 ## 为什么 Hook 比 CLAUDE.md 中的建议更有约束力？ 仓库中的文字指令是在要求智能体采用某种行为。工具 Hook 则能在匹配的工具调用执行之前介入。Anthropic 的 [Hook 参考文档](https://code.claude.com/docs/en/hooks) 通过 `PreToolUse` 的决策控制说明了这一差别。 Spotify 的 [Read Hook 实现](https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/hooks/check-file-size) 检查目标文件的行数。默认阈值为 350 行，可通过 `SHUNT_MIN_LINES` 调整。对超过阈值文件的完整读取会被引导至 bulk-reader。显式指定偏移量或读取上限的请求仍然放行，让 Claude 能读取编辑所需的准确片段。刚好 350 行的文件不会超过默认阈值。 三层设计承担的是不同责任： | 层级 | 负责什么 | 不代表什么 | | --- | --- | --- | | Hooks | 拦截受支持的大范围读取，并要求委派 | 覆盖所有可能的工具和数据访问路径 | | 封装脚本 | 通过 Portal 发送任务和文件，处理响应 | 答案必然完整、正确 | | Skills | 告诉智能体何时以及如何调用辅助模型 | 所有代码生成都会被强制委派 | README 明确指出，**code-writer 没有对应的强制 Hook**，是否使用它仍由 Skill 引导。因此，应把 shunt 看作成本路由控制，而不是沙箱、密钥扫描器或权限边界。还要验证组织的托管 Hook 设置是否允许该插件实际运行。安装成功不等于路由行为已经得到验证。 ## bulk-reader 和 code-writer 分别适合哪些任务？ bulk-reader 适合范围明确的信息提取：列出导出的接口、枚举配置键、说明既有实现模式，或为下一步精确读取找到相关文件。要求它返回具体符号名、路径和不确定之处，而不是让它泛泛解释整个仓库。 code-writer 更适合**有可靠参考文件、输出模式明确的新文件**，例如测试骨架或配置变体。 [code-write 脚本](https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/scripts/code-write) 要求提供任务说明和参考文件。指定 `--target` 时，它会直接写入磁盘；没有指定时，则通过标准输出返回代码。因此，并非所有调用都能自动避免生成代码进入主模型上下文。 文件写好了，不等于任务通过验收。应在独立任务分支或 worktree 中生成文件，检查差异，执行相关测试，并审阅敏感片段。不要把已有文件当成可以随意覆盖的输出位置。如果测试照搬了实现中的错误假设，风格再符合相邻测试也没有用。 故障诊断、架构、并发分析以及安全相关决策，仍需要充分推理和独立验证。Spotify 报告其示例辅助模型漏掉了一个细微的线程安全问题。这是被评估工作流的局限，不是所有低价模型都无法推理的证据。修改现有代码还需要准确源码，而不是摘要中猜测出来的行号。 ## 安装：三个命令并不等于全部前提 [官方插件市场 README](https://github.com/spotify/portal-ai-plugins) 提供了以下 Claude Code 安装命令： ``` claude plugin marketplace add spotify/portal-ai-plugins claude plugin install portal@portal claude plugin install shunt@portal ``` 随后在**新的 Claude Code 会话**中执行： ``` /portal:setup ``` 此外，你需要 `jq`、已认证的 Portal CLI、启用 AiKA 的 Portal 实例，以及使用已配置模型的可访问工作模式。先确认你的实例中存在 `bulk-reader` 和 `code-writer`。某个模式被称为公开，并不代表任何部署都能匿名使用它。 下面是只读的模式查询命令： ``` npx @spotify/portal-cli actions aika:list-modes --json --input '{"search":"bulk-reader"}' ``` 再将查询词换成 `code-writer`。发送公司代码之前，检查实际模型和指令。仓库采用 Apache-2.0 许可证，但 Portal 运行、模型推理和集成工作不会因此免费。这里的前提也不是一个 Spotify 音乐订阅。 ## 简短发布帖没有说明的当前限制 排查问题时，核查过的 [传输层实现](https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/scripts/lib/aika.sh) 比旧截图更有参考价值： | 情况 | 当前源码行为 | 合理处理方式 | | --- | --- | --- | | 请求过大 | JSON 通过命令行参数传递；Linux 默认上限为 120,000 字节，其他系统为 400,000 字节 | 减少文件或收窄问题，不要盲目提高上限 | | 调用耗时过长 | 客户端 `SHUNT_TIMEOUT_SECONDS` 默认值为 180 | 分别核查客户端和后端限制，必要时拆分任务 | | 模式名称存在歧义 | 名称解析优先选择个人、群组和公开模式，也可指定 ID | 核查实际选中的模式、模型和指令 | | 指定模式没有生效 | 响应未包含已应用模式名时，封装脚本会拒绝结果 | 修复配置，不要接受脱离模式的通用回答 | Spotify 的发布文章描述了典型 10 至 30 秒的往返时间，并提到 30 秒的调用上限。当前客户端默认 180 秒，**不保证**每个 Portal 后端都允许相同持续时间。记录安装的插件版本，并验证自己实例的行为。 每次传输调用都是独立的。追问时，选定文件会再次发送给辅助模型。文件不进入 Claude 上下文，并不意味着辅助模型的输入不计费。对客户仓库，应先审核新增的数据处理路径、保留条款、获批模型供应商以及临时请求文件的处理方式。 ## 如何判断 shunt 是否降低真实成本？ 比较已完成的任务，而不只是单次摘要。Anthropic 的 [Claude Code 成本文档](https://code.claude.com/docs/en/costs) 区分使用量、模型选择和上下文管理。缓存输入与普通输入不能按相同单价估算。固定订阅的可用额度、按量 API 费用和新增辅助模型账单，也不是可以直接混在一起的指标。 使用自己的测量值套入这条决策公式： ``` 每项已验收任务的净收益 = 避免的 Claude 有效成本 - 辅助模型输入与输出成本 - 分摊的 Portal 增量成本 - 额外重试与验证工作 ``` 如果固定订阅账单没有变化，最先得到的可能是更多可用容量，而不是现金节省。已有缓存如果让重复读取十分便宜，新增网络往返可能不值得。如果摘要漏掉关键条件，迫使 Claude 最后仍然打开整个文件，表面上的节省也可能消失。 应根据团队实际文件大小分布与延迟容忍度设定 `SHUNT_MIN_LINES`。350 只是默认值，不是普遍最优值。一个充满重复声明的大型生成文件，与一个较短但每行都影响正确性的事务处理函数，是不同的工作负载。 ## shunt、原生子智能体与仓库上下文工具怎么选？ Anthropic 的 [子智能体文档](https://code.claude.com/docs/en/sub-agents) 已经支持独立上下文窗口、向主智能体返回摘要以及显式指定模型。把探索过程移出主上下文并不是 shunt 独有的能力。它的区别在于 Portal 工作模式集成，以及 Spotify 的文件读取路由 Hook。 | 当前问题 | 优先评估的方式 | | --- | --- | | 已经知道符号或具体片段 | 确定性搜索或定向读取，无需新增模型调用 | | 需要独立探索，但没有使用 Portal | 明确选择模型并限定工具的原生子智能体 | | 已在运营 Portal，且经常摄入大文件 | 受控试用 shunt bulk-reader | | 需要更小、更贴合任务的仓库地图 | 结构化上下文层，而不是代码生成辅助模型 | 我们的 [Ripwire 仓库上下文评测](/zh/blog/ripwire-ai-repo-context-review-2026/) 讨论确定性的结构信息。 [Codag 成本控制](/zh/blog/codag-cost-control/) 讨论工具输出压缩。 [多模型编码智能体选型指南](/zh/blog/multi-model-ai-coding-agent-stack-2026/) 则处理更广泛的团队架构问题。不要把 shunt 当成这些不同层级工具的统一替代品。 ## 两周 shunt 试点如何验收？ **从一个仓库和二十项代表性任务开始。** 包括大文件查询、小范围精确读取、源码与测试对照，以及少量按照现有模式创建的新文件。困难的调试任务用于检验排除边界，不是为了让便宜模型强行解决。 第一周先记录不使用 shunt 时的任务完成时间、有效模型成本、缓存情况与人工审核分钟数。再使用插件重复同类任务，尽量保持提示词、模型选择与验收标准一致。将辅助模型用量与 Claude 用量分开，并区分冷缓存和热缓存运行。 第二周检查边界：超过阈值的完整读取、允许的片段读取、Portal 不可用、模式缺失或有歧义、批次过大，以及事实不完整的辅助模型回答。使用原始文件核对代码和摘要。一次读取被拦截后陷入无限重试，是试点失败，不是成本优化。 提前约定上线条件：已验收任务的质量不能下降，总成本降低或容量收益有证据，慢请求的尾部延迟可以接受，并且有人负责模式配置。公布完整结果分布，包括退步的案例。最好的演示不能变成全公司节省相同比例的承诺。 ## 什么时候值得部署，什么时候应维持现状？ 合适的团队已经使用 Portal，能证明大文件上下文存在浪费，并能为提示词、数据访问和评估指定负责人。不合适的团队主要执行小而精确的修改，尚未批准新的模型处理路径，或者无法可靠检查简短答案。 Wavect 的 [AI 咨询与实施服务](/zh/services/artificial-intelligence/) 可以先界定可测量的编码智能体成本评估，再决定是否增加平台。 [Twinsoft AI 案例](/zh/case-studies/twinsoft-ai/) 提供相关 AI 项目交付背景，不是 Wavect 在该客户部署 shunt 的证明。 [定制软件与现成方案指南](/zh/software-development-guide/custom-software-vs-off-the-shelf/) 有助于区分一次小型集成与长期平台投入。 [规划编码智能体 Token 路由试点](/zh/contact/) 时，请准备当前用量拆分、一个代表性仓库，以及变更必须通过的验收检查。交付物应是一项有依据的路由决策，而不是预先承诺的节省比例。 **结论：** 值得复制的是委派边界，不是标题中的百分比。只有在经验证的收益超过辅助模型费用、延迟和返工时，才委派范围明确的读取和重复代码生成。准确编辑与重要判断，仍应留在能够证明正确性的工作流中。 ## 常见问题 ### Spotify shunt 能把 Claude Code 总账单降低 90% 吗？ 公开数字针对特定大文件读取场景中估算的 Claude 上下文 Token。实际总收益还取决于辅助模型用量、Portal 成本、缓存、重试和验证工作。 ### 没有 Portal 能使用 Spotify shunt 吗？ 官方插件通过 Portal CLI 调用 AiKA 模式，需要经过认证且启用 AiKA 的 Portal 实例。原生子智能体可以实现另一种委派流程，但并不是同一套安装。 ### shunt 会强制把所有代码生成交给便宜模型吗？ 不会。README 明确说明 code-writer 没有强制 Hook，是否使用仍由 Skill 引导。受支持的大范围读取才是 Hook 控制的部分。 ### 350 行是不是始终最好的阈值？ 不是。它只是可调整的默认值，应根据真实文件大小分布、辅助模型延迟、缓存情况和已验收任务结果设定。 ### Spotify shunt 能充当安全边界吗？ 不能。成本路由 Hook 不是沙箱或权限系统。代码处理目标、凭据、插件权限以及生成的文件，都需要另外审核。 智能体工程 ## 继续浏览此集群 编程智能体、MCP、上下文系统、评估与可靠自动化控制。 [从核心文章开始**AI 智能体的图工程：知识图谱什么时候值得做？**](/zh/blog/graph-engineering-ai-agents/) - [OpenBot 评测：自托管 AI 同事的成本与权限](/zh/blog/openbot-self-hosted-ai-coworkers-review/) - [Ramp Inspect 架构 2026：如何扩展后台编码 Agent](/zh/blog/ramp-inspect-background-coding-agent-infrastructure-2026/) - [Model Hardware Standard 企业指南：MHS 与实体 AI](/zh/blog/model-hardware-standard-enterprise-guide/) - [Fonio AI 2026 评估：价格、API、GDPR 与自建对比](/zh/blog/fonio-ai-review-build-vs-buy-2026/) - [Mosaic（YC S26）评测：团队编码 Agent 的共享记忆](/zh/blog/mosaic-yc-s26-shared-agent-sessions-review/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年9月12日 最近审核 2026年9月12日 [**下一篇**](/zh/blog/smarter-token-usage-with-your-ai-coding-agent/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/spotify-shunt-claude-code-token-routing/#webpage", "@type": "WebPage", "dateModified": "2026-09-12", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-12", "url": "https://wavect.io/zh/blog/spotify-shunt-claude-code-token-routing/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Spotify shunt 通过 Portal 的 AiKA 模式委派大文件读取和模式明确的代码生成。公布的 90% 指特定读取场景下估算的 Claude 上下文 Token 节省，不是全部费用降低。使用它需要经过认证、启用 AiKA 的 Portal 实例、可访问的模式以及已配置模型。Read Hook 控制受支持的读取，而 code-writer 仍由 Skill 引导。采用前应测量辅助模型费用、缓存、延迟和验证成本。", "articleBody": " 博客概览/AI 与智能体/智能体工程 Spotify shunt 评测：Claude Code Token 节省、安装与限制 要点速览 Spotify shunt 通过 Portal 的 AiKA 模式委派大文件读取和模式明确的代码生成。公布的 90% 指特定读取场景下估算的 Claude 上下文 Token 节省，不是全部费用降低。使用它需要经过认证、启用 AiKA 的 Portal 实例、可访问的模式以及已配置模型。Read Hook 控制受支持的读取，而 code-writer 仍由 Skill 引导。采用前应测量辅助模型费用、缓存、延迟和验证成本。 如果 Claude Code 经常为了回答一个具体问题而反复读取大文件，Spotify shunt 值得试用。但它并不能证明你的 AI 编程总账单会下降 90%。 真正需要判断的是：更便宜的辅助模型能否提供足够准确的上下文，而且不会把成本转移到审核和返工上。 Spotify 的工程文章介绍了 Portal 中的两个 AiKA 模式：bulk-reader 根据文件回答具体问题，code-writer 参考现有文件生成模式明确的代码。示例使用 Gemini 2.5 Flash，温度设为 0.2。这些是可以调整的辅助模型配置，不是要求你替换负责主要编程任务的 Claude。 本篇是根据公开资料进行的分析，核查日期为 2026 年 9 月 12 日，不是 Wavect 的生产环境实测。这里的工具是 spotify/portal-ai-plugins 中的 shunt，不是其他同名项目。通用的缓存、批处理和日常成本管理，请阅读编码智能体 Token 成本指南。本文只解决一个更具体的问题：Spotify 的文件读写委派何时真正划算？ 独立性与商标声明: 本页由 Wavect 发布，Wavect 自身也是服务商，因此我们对本页存在商业利益。我们与本页提及的其他公司没有关联，未获得其背书，也不是其合作伙伴；所有第三方公司名称、品牌与商标均归各自所有者所有。关于其他服务商的陈述来自公开可查的来源，主要是其自己发布的页面，以本页标注的核查日期为准，此后可能已经发生变化。做决定前请自行直接核实。本页依据我们所知的情况撰写，并力求保持客观。如果你认为其中有不准确或不公平之处，请写信告诉我们，我们会更正： office@wavect.io 所谓节省 90%，到底测量了什么？ 先看分母。公开的基准测试说明把目标定义为 Claude 上下文 Token 的节省，并采用字符数除以四估算代码 Token。这是近似值，不是模型服务商的计费记录。仓库提供的测试样例是 TypeScript 文件，也不是公布结果所用的 Java 单体仓库。因此，运行这些样例不等于精确复现原始实验。 shunt README公布了一个包含 162,000 行代码的 Java 仓库的测试结果： 公布的场景 读取行数 不使用 shunt 使用 shunt 发布方报告的节省 单个大文件 4,014 33,684 Tokens 5,737 Tokens 82% 源码与测试文件 7,408 75,990 Tokens 4,148 Tokens 94% 跨服务读取多个文件 1,281 16,221 Tokens 821 Tokens 94% README 将平均节省描述为 90%。独立的代码生成场景记录了 833 行代码直接写入磁盘，却没有给出可比较的节省百分比。这张表并未证明 Claude、辅助模型、平台和工程人力的合计成本降低了 90%。 表中的百分比保留发布方原值，不应视为 Wavect 独立重新测量的结果。 可以用一个明确假设的例子理解区别：原来 Claude 接收 40,000 个 Token；现在辅助模型读取这 40,000 个 Token，输出 4,000 个 Token 的摘要，再由 Claude 接收摘要。Claude 的阅读上下文减少了 90%，但两个模型合计处理了 48,000 个 Token，还没有计入其他开销。由于单价不同，总费用仍可能下降。上下文减少和账单减少，是两件事。 为什么 Hook 比 CLAUDE.md 中的建议更有约束力？ 仓库中的文字指令是在要求智能体采用某种行为。工具 Hook 则能在匹配的工具调用执行之前介入。Anthropic 的 Hook 参考文档通过 PreToolUse 的决策控制说明了这一差别。 Spotify 的 Read Hook 实现检查目标文件的行数。默认阈值为 350 行，可通过 SHUNT_MIN_LINES 调整。对超过阈值文件的完整读取会被引导至 bulk-reader。显式指定偏移量或读取上限的请求仍然放行，让 Claude 能读取编辑所需的准确片段。刚好 350 行的文件不会超过默认阈值。 三层设计承担的是不同责任： 层级 负责什么 不代表什么 Hooks 拦截受支持的大范围读取，并要求委派 覆盖所有可能的工具和数据访问路径 封装脚本 通过 Portal 发送任务和文件，处理响应 答案必然完整、正确 Skills 告诉智能体何时以及如何调用辅助模型 所有代码生成都会被强制委派 README 明确指出，code-writer 没有对应的强制 Hook，是否使用它仍由 Skill 引导。因此，应把 shunt 看作成本路由控制，而不是沙箱、密钥扫描器或权限边界。还要验证组织的托管 Hook 设置是否允许该插件实际运行。安装成功不等于路由行为已经得到验证。 bulk-reader 和 code-writer 分别适合哪些任务？ bulk-reader 适合范围明确的信息提取：列出导出的接口、枚举配置键、说明既有实现模式，或为下一步精确读取找到相关文件。要求它返回具体符号名、路径和不确定之处，而不是让它泛泛解释整个仓库。 code-writer 更适合有可靠参考文件、输出模式明确的新文件，例如测试骨架或配置变体。code-write 脚本要求提供任务说明和参考文件。指定 --target 时，它会直接写入磁盘；没有指定时，则通过标准输出返回代码。因此，并非所有调用都能自动避免生成代码进入主模型上下文。 文件写好了，不等于任务通过验收。应在独立任务分支或 worktree 中生成文件，检查差异，执行相关测试，并审阅敏感片段。不要把已有文件当成可以随意覆盖的输出位置。如果测试照搬了实现中的错误假设，风格再符合相邻测试也没有用。 故障诊断、架构、并发分析以及安全相关决策，仍需要充分推理和独立验证。Spotify 报告其示例辅助模型漏掉了一个细微的线程安全问题。这是被评估工作流的局限，不是所有低价模型都无法推理的证据。修改现有代码还需要准确源码，而不是摘要中猜测出来的行号。 安装：三个命令并不等于全部前提 官方插件市场 README提供了以下 Claude Code 安装命令： claude plugin marketplace add spotify/portal-ai-plugins claude plugin install portal@portal claude plugin install shunt@portal 随后在新的 Claude Code 会话中执行： /portal:setup 此外，你需要 jq、已认证的 Portal CLI、启用 AiKA 的 Portal 实例，以及使用已配置模型的可访问工作模式。先确认你的实例中存在 bulk-reader 和 code-writer。某个模式被称为公开，并不代表任何部署都能匿名使用它。 下面是只读的模式查询命令： npx @spotify/portal-cli actions aika:list-modes --json --input '{\"search\":\"bulk-reader\"}' 再将查询词换成 code-writer。发送公司代码之前，检查实际模型和指令。仓库采用 Apache-2.0 许可证，但 Portal 运行、模型推理和集成工作不会因此免费。这里的前提也不是一个 Spotify 音乐订阅。 简短发布帖没有说明的当前限制 排查问题时，核查过的传输层实现比旧截图更有参考价值： 情况 当前源码行为 合理处理方式 请求过大 JSON 通过命令行参数传递；Linux 默认上限为 120,000 字节，其他系统为 400,000 字节 减少文件或收窄问题，不要盲目提高上限 调用耗时过长 客户端 SHUNT_TIMEOUT_SECONDS 默认值为 180 分别核查客户端和后端限制，必要时拆分任务 模式名称存在歧义 名称解析优先选择个人、群组和公开模式，也可指定 ID 核查实际选中的模式、模型和指令 指定模式没有生效 响应未包含已应用模式名时，封装脚本会拒绝结果 修复配置，不要接受脱离模式的通用回答 Spotify 的发布文章描述了典型 10 至 30 秒的往返时间，并提到 30 秒的调用上限。当前客户端默认 180 秒，不保证每个 Portal 后端都允许相同持续时间。记录安装的插件版本，并验证自己实例的行为。 每次传输调用都是独立的。追问时，选定文件会再次发送给辅助模型。文件不进入 Claude 上下文，并不意味着辅助模型的输入不计费。对客户仓库，应先审核新增的数据处理路径、保留条款、获批模型供应商以及临时请求文件的处理方式。 如何判断 shunt 是否降低真实成本？ 比较已完成的任务，而不只是单次摘要。Anthropic 的 Claude Code 成本文档区分使用量、模型选择和上下文管理。缓存输入与普通输入不能按相同单价估算。固定订阅的可用额度、按量 API 费用和新增辅助模型账单，也不是可以直接混在一起的指标。 使用自己的测量值套入这条决策公式： 每项已验收任务的净收益 = 避免的 Claude 有效成本 - 辅助模型输入与输出成本 - 分摊的 Portal 增量成本 - 额外重试与验证工作 如果固定订阅账单没有变化，最先得到的可能是更多可用容量，而不是现金节省。已有缓存如果让重复读取十分便宜，新增网络往返可能不值得。如果摘要漏掉关键条件，迫使 Claude 最后仍然打开整个文件，表面上的节省也可能消失。 应根据团队实际文件大小分布与延迟容忍度设定 SHUNT_MIN_LINES。350 只是默认值，不是普遍最优值。一个充满重复声明的大型生成文件，与一个较短但每行都影响正确性的事务处理函数，是不同的工作负载。 shunt、原生子智能体与仓库上下文工具怎么选？ Anthropic 的子智能体文档已经支持独立上下文窗口、向主智能体返回摘要以及显式指定模型。把探索过程移出主上下文并不是 shunt 独有的能力。它的区别在于 Portal 工作模式集成，以及 Spotify 的文件读取路由 Hook。 当前问题 优先评估的方式 已经知道符号或具体片段 确定性搜索或定向读取，无需新增模型调用 需要独立探索，但没有使用 Portal 明确选择模型并限定工具的原生子智能体 已在运营 Portal，且经常摄入大文件 受控试用 shunt bulk-reader 需要更小、更贴合任务的仓库地图 结构化上下文层，而不是代码生成辅助模型 我们的 Ripwire 仓库上下文评测讨论确定性的结构信息。Codag 成本控制讨论工具输出压缩。多模型编码智能体选型指南则处理更广泛的团队架构问题。不要把 shunt 当成这些不同层级工具的统一替代品。 两周 shunt 试点如何验收？ 从一个仓库和二十项代表性任务开始。 包括大文件查询、小范围精确读取、源码与测试对照，以及少量按照现有模式创建的新文件。困难的调试任务用于检验排除边界，不是为了让便宜模型强行解决。 第一周先记录不使用 shunt 时的任务完成时间、有效模型成本、缓存情况与人工审核分钟数。再使用插件重复同类任务，尽量保持提示词、模型选择与验收标准一致。将辅助模型用量与 Claude 用量分开，并区分冷缓存和热缓存运行。 第二周检查边界：超过阈值的完整读", "articleSection": "工程", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Spotify 的工程文章", "url": "https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90" }, { "@type": "WebPage", "name": "基准测试说明", "url": "https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/evals/benchmarks.json" }, { "@type": "WebPage", "name": "shunt README", "url": "https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/README.md" }, { "@type": "WebPage", "name": "Hook 参考文档", "url": "https://code.claude.com/docs/en/hooks" }, { "@type": "WebPage", "name": "Read Hook 实现", "url": "https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/hooks/check-file-size" }, { "@type": "WebPage", "name": "code-write 脚本", "url": "https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/scripts/code-write" }, { "@type": "WebPage", "name": "官方插件市场 README", "url": "https://github.com/spotify/portal-ai-plugins" }, { "@type": "WebPage", "name": "传输层实现", "url": "https://github.com/spotify/portal-ai-plugins/blob/main/plugins/shunt/scripts/lib/aika.sh" }, { "@type": "WebPage", "name": "Claude Code 成本文档", "url": "https://code.claude.com/docs/en/costs" }, { "@type": "WebPage", "name": "子智能体文档", "url": "https://code.claude.com/docs/en/sub-agents" } ], "dateModified": "2026-09-12", "datePublished": "2026-09-12", "description": "Spotify shunt 通过 Portal 的 AiKA 模式委派大文件读取和模式明确的代码生成。公布的 90% 指特定读取场景下估算的 Claude 上下文 Token 节省，不是全部费用降低。使用它需要经过认证、启用 AiKA 的 Portal 实例、可访问的模式以及已配置模型。Read Hook 控制受支持的读取，而 code-writer 仍由 Skill 引导。采用前应测量辅助模型费用、缓存、延迟和验证成本。", "headline": "Spotify shunt 评测：安装、Token 节省与限制", "image": "https://wavect.io/img/blog/headers/header_spotify-shunt-claude-code-token-routing.png", "inLanguage": "zh", "keywords": "Claude Code, Token 路由", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/spotify-shunt-claude-code-token-routing/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/spotify-shunt-claude-code-token-routing/", "wordCount": 528 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/agent-engineering/", "name": "智能体工程", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/spotify-shunt-claude-code-token-routing/", "name": "Spotify shunt 评测：安装、Token 节省与限制", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "公开数字针对特定大文件读取场景中估算的 Claude 上下文 Token。实际总收益还取决于辅助模型用量、Portal 成本、缓存、重试和验证工作。" }, "name": "Spotify shunt 能把 Claude Code 总账单降低 90% 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "官方插件通过 Portal CLI 调用 AiKA 模式，需要经过认证且启用 AiKA 的 Portal 实例。原生子智能体可以实现另一种委派流程，但并不是同一套安装。" }, "name": "没有 Portal 能使用 Spotify shunt 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不会。README 明确说明 code-writer 没有强制 Hook，是否使用仍由 Skill 引导。受支持的大范围读取才是 Hook 控制的部分。" }, "name": "shunt 会强制把所有代码生成交给便宜模型吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不是。它只是可调整的默认值，应根据真实文件大小分布、辅助模型延迟、缓存情况和已验收任务结果设定。" }, "name": "350 行是不是始终最好的阈值？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不能。成本路由 Hook 不是沙箱或权限系统。代码处理目标、凭据、插件权限以及生成的文件，都需要另外审核。" }, "name": "Spotify shunt 能充当安全边界吗？" } ] } ```