Spotify Portal 把 Claude Code token 砍 90%:CLI Agent 平台层优化与企业的 Claude Code 落地成本工程 2026 年 9 月初,Spotify 工程团队通过其工程博客发表了一篇文章,介绍了他们内部开发的工具 Portal 如何在 Claude Code 的日常使用中把 token 消耗砍掉 90%。这件事单独看是 Spotify 自己的内部优
Spotify Portal 把 Claude Code token 砍 90%:CLI Agent 平台层优化与企业的 Claude Code 落地成本工程
2026 年 9 月初,Spotify 工程团队通过其工程博客发表了一篇文章,介绍了他们内部开发的工具 Portal 如何在 Claude Code 的日常使用中把 token 消耗砍掉 90%。这件事单独看是 Spotify 自己的内部优化,但放进 2026 年下半年 AI 编程 Agent 进入企业生产链路的整体图景里,它指向一个被低估的事实:Claude Code 这类 CLI Agent 的"成本",并不只是底层模型 API 调用的费用,它还包含 prompt 上下文构造、tool call 编排、agent loop 控制、对话状态管理等一整套 harness 层的开销。harness 设计的好坏,可以让同一模型、同一任务,在不同企业里产生几倍甚至几十倍的成本差异。本文以 Spotify 的 Portal 与 The New Stack 在 2026 年 9 月初发表的另一篇跨 harness benchmark 为底本,把"CLI Agent 的平台层优化"这一被低估的工程方向讲清楚,并讨论它在企业落地 Claude Code 时的实际意义。
一、Spotify Portal 的基本形态:一个 Claude Code 的 Web 门户
Spotify 工程团队在 2026 年 9 月 4 日发表的《Portal by Spotify cut my Claude Code token usage by 90%》一文中,介绍了他们开源的 Portal 工具。这个工具的核心定位,是给 Claude Code 提供一个统一的 Web 门户,让多个开发者可以在浏览器里同时跑多个 Claude Code 会话,并且在会话之间共享状态、复用上下文、做集中化的成本与 token 监控。
从工程实现上看,Portal 的关键优化点并不神秘,但足够具体。第一,它把多个 Claude Code 会话里高度重复的上下文(项目说明、CI 脚本、测试框架定义、依赖列表)做了一层公共缓存,避免每次新建会话时都把这些内容重复塞进 prompt。第二,它对 prompt 的拼接顺序与分段策略做了精细调整,把"模型最容易跑偏的开头几段说明"与"实际任务描述"做了清晰的物理隔离,让模型不会因为上下文结构混乱而触发额外的冗长思考链。第三,它实现了一个 token 预算控制器,在每个会话进入下一轮迭代前,会先估算当前会话已消耗的 token、剩余任务复杂度、可用预算,如果判定本轮不值得继续,就主动结束会话,而不是让模型在低边际收益的循环里空转。
文章里给出的最直接数字是,在 Spotify 内部把 Claude Code 的 token 消耗降低了 90%。这个数字背后的含义是,在不更换底层模型、不降低任务质量、不减少任务覆盖面的前提下,Spotify 通过 Portal 这一层平台优化,把 Claude Code 在企业内部的使用成本压到了原来的十分之一。
这件事为什么重要,需要放进两个更大尺度的背景里看。第一个背景是,Claude Code 这类编程 Agent 在 2026 年下半年已经大规模进入企业内部,但很多企业的财务与 IT 团队对它的成本理解,还停留在"按 token 计费"的模型 API 费用上,忽略了 harness 层的额外开销;Spotify 的工作是把这一层开销显式量化了。第二个背景是,跨 harness 的 token 消耗差异,远大于"同一模型不同厂商 API"之间的差异,The New Stack 的实测给出了一个 70 倍的对比数字(下文详述),这意味着企业选型 AI 编程 Agent 时,不应该只看模型本身的报价,更应该看 harness 层的工程实现质量。
二、跨 harness 的横向 benchmark:同一模型,token 消耗差异可达 70 倍
The New Stack 在 2026 年 9 月 1 日发表了一篇实测报道《Hermes, Claude Code, and Codex ran an identical model. Token use varied 70-fold》。这篇文章的核心方法,是让 Hermes、Claude Code、Codex 三个不同的 AI 编程 Agent harness 在完全相同的模型、完全相同的任务上完成同一组编程任务,然后比较它们各自的 token 消耗差异。
这里的"完全相同的模型"是一个关键约束——三者并不一定都默认调用同一个底层模型,但在这项测试里,作者强制让它们都跑同一个模型变体,从而把变量收窄到"harness 实现差异"这一个维度。在这个维度上,三者呈现出来的差异是 70 倍——即同一个任务,token 消耗最高的那个 harness,比最低的多花了 70 倍的 token。
这个 70 倍的差异,来源是 harness 设计的多个工程选择,包括:上下文窗口的填充策略(是否每次都把全部历史塞回去,还是做了语义压缩);tool call 的接口设计(模型是否需要为每一个子步骤输出结构化参数,这些参数本身消耗多少 token);错误恢复路径的设计(模型输出格式不对时,harness 是直接报错让模型重做,还是给了模型一个低成本的"自我修正"提示);对话状态的管理方式(中间过程是否进入 prompt,还是被摘要后只在最终结果里出现)。每一个单独的工程选择,可能只会带来 10% 到 30% 的 token 差异,但多个选择叠加之后,差异就会被放大到数量级。
把 Spotify 的 90% 削减与 The New Stack 的 70 倍差异放在一起,可以形成一个非常清晰的判断:在 AI 编程 Agent 的企业落地里,harness 层的优化空间,远远大于"选择更便宜的模型"或"换更便宜的计划"。一个工程实现良好的 harness,可以让企业用相同的预算完成十倍以上的实际工作量;而一个工程实现粗糙的 harness,即便底层模型再便宜,也会在 harness 层把成本放大回去。
三、CLI Agent 平台层优化的具体维度
把 Spotify Portal 的优化点抽象出来,可以归纳出 CLI Agent 平台层优化的几个具体维度,这些维度在企业自建 Claude Code 类 Agent 平台时,都值得被显式纳入设计。
第一个维度是上下文缓存。Claude Code 这类 Agent 在每次新建会话或每次进入新任务时,都需要把项目背景信息注入 prompt。注入的方式,如果是最简单的"每次完整塞入",那么跨多个会话、多个任务时,token 消耗会迅速放大。Portal 的做法是把高度共享的上下文抽出来,作为跨会话的公共缓存,只在 prompt 中放一个引用 ID,让模型在需要时按 ID 加载。这种做法的工程实现并不复杂,核心是一个简单的 KV 存储加上一个 prompt 模板里的引用机制,但带来的 token 节省可以非常显著。
第二个维度是 prompt 结构治理。Prompt 的物理顺序、段落切分、强调标记使用,都会影响模型的实际推理路径与输出长度。一个细节上的设计选择,比如"是否在 prompt 开头放一段长篇说明",可能会让模型在每次响应时多输出几百甚至几千 token 的"思考过程",这些 token 既增加成本又延迟响应。Portal 对 prompt 的拼接顺序做了精细调整,这是 harness 工程里最容易被低估的优化点,因为它要求工程团队对模型行为有非常具体的经验积累。
第三个维度是 token 预算控制。Agent loop 的一个常见反模式,是让模型在没有明确预算约束的情况下反复迭代,直到它自己判定"任务完成"为止。这种模式下,如果模型在某次迭代里陷入了一个局部最优但不是全局最优的循环,它可能会花费大量 token 来反复尝试无意义的微调。Portal 引入的 token 预算控制器,本质上是一个轻量的强化学习信号——它告诉模型"你还有多少预算",让模型在预算不足时倾向于收敛到一个合理答案,而不是追求完美。
第四个维度是会话状态管理。Claude Code 这类 Agent 通常会把对话的全部历史保留下来,作为下一轮 prompt 的前缀。这种设计在长任务下会带来"上下文爆炸"——历史越长,下一轮的 prompt 越长,模型的响应成本越高,响应延迟也越大。Portal 对会话状态做了结构化摘要,把中间过程压缩成一个固定大小的"状态块",而不是把所有历史一字不漏地保留。这种做法在牺牲一定上下文精度的前提下,显著压低了 token 消耗。
第五个维度是并发与多用户协作。Spotify 内部的工程师会同时开多个 Claude Code 会话,处理不同的任务或同一个任务的不同子问题。Portal 通过共享这些会话的部分上下文,让一个会话里发现的有效信息可以被另一个会话复用,避免每个会话都从头构造同样的上下文。这种协作层面的优化,在单用户场景下没有价值,但在大型团队场景下的 token 节省非常可观。
四、对企业 IT 与工程团队的具体启示
把 Spotify 的 90% 与 The New Stack 的 70 倍结合起来,有几个对企业 IT 与工程团队具有实际意义的启示。
第一个启示是关于选型评估。任何准备大规模采购或自建 Claude Code 类 AI 编程 Agent 的企业,都不应该只评估"模型本身的 API 报价",还应该把 harness 层的工程实现质量作为独立的评估维度。具体来说,需要在评估阶段做几件事:让候选 harness 在一组真实企业内部任务上完成对比测试,记录 token 消耗差异;让多个开发者并行使用候选 harness,记录在多会话、并发、长任务下的 token 与延迟表现;对候选 harness 的 prompt 结构、会话状态管理、上下文缓存机制做技术审查,看它是否存在明显的设计短板。
第二个启示是关于平台层抽象。Spotify 选择自建 Portal,本质上是把 Claude Code 的使用从"每个开发者单独跑一个 CLI"升级为"团队通过一个统一的 Web 平台访问 Agent"。这种升级带来的好处,不只是 token 节省,还包括集中化的成本监控、统一的安全策略、可审计的会话日志、更方便的知识沉淀。对于任何准备在企业里大规模推广 AI 编程 Agent 的团队,平台层抽象都是必经之路——没有平台层抽象,Agent 使用就是散落在每个开发者本地的混乱状态,既难以治理也难以优化。
第三个启示是关于上下文工程。harness 层的优化,大部分最终都要落到"上下文工程"这一具体能力上——什么是项目级共享上下文,什么是会话级私有上下文,什么是任务级临时上下文,这些不同生命周期的上下文如何被注入到 prompt,注入顺序如何设计,引用机制如何实现。Spotify Portal 的 90% 削减,本质上是把这一套上下文工程做到了工程级别;而 The New Stack 的 70 倍差异,则说明大多数 harness 在上下文工程上还有显著差距。
第四个启示是关于成本可视化。Token 消耗是 AI 编程 Agent 企业落地里最难向财务与业务方解释的成本项之一,因为它不像"软件许可证"那样有一个明确的金额。Portal 的 token 预算控制器,以及配套的成本可视化界面,让每一笔 token 消耗都能被归因到具体的任务、具体的开发者、具体的项目。这件事的工程价值,远超过 token 节省本身——它让 AI 编程 Agent 的使用成本,变成一项可被预算、被审计、被优化的标准运营开销。
五、对未来的判断
把 Spotify 的工作与 The New Stack 的工作放在一起,可以对未来做出几个相对确定的判断。
第一,围绕"AI 编程 Agent harness 优化"会在 2026 年下半年到 2027 年成为独立的产品方向。Spotify 选择开源 Portal,而不是把它作为内部独占工具,已经预示了这一方向的市场潜力。后续还会有更多企业发布各自的 harness 优化工具,围绕上下文缓存、prompt 结构、token 预算控制、会话状态管理等具体维度展开竞争。
第二,跨 harness 的 token 消耗差异,会让企业选型 AI 编程 Agent 时,把"harness 工程实现质量"作为一个独立于"模型本身"的评估维度。这意味着,Claude Code、Codex、Cursor、Aider 这些 harness,在企业市场里会逐步分化,而不是简单地被模型 API 报价所决定。
第三,平台层抽象会成为大型企业落地 AI 编程 Agent 的标配。Spotify Portal、Anthropic 自家的企业级控制台、其他大厂正在开发的类似工具,都会围绕"团队级协作 + 集中化成本治理 + 统一安全策略 + 跨会话上下文共享"这几个维度展开。这一层抽象一旦建立起来,直接跑在 CLI 上的个人使用,会逐步被边缘化,就像过去十年里直接跑在终端上的个人数据库,被集中化的数据库平台取代一样。
第四,token 消耗的工程优化,会从"经验积累"走向"形式化方法"。Spotify 的 Portal 优化点,目前还是基于工程团队的实践经验;随着跨 harness benchmark 数据集的成熟,以及学术界对 harness 工程优化的关注,这些优化点会逐步被形式化、自动化、工具化,最终让任何企业在部署 Claude Code 类 Agent 时,都能自动获得接近最优的 harness 配置。
回到企业 IT 与工程团队的视角,Spotify 的 90% 与 The New Stack 的 70 倍,共同传递了一个非常清晰的信号:在 AI 编程 Agent 的企业落地里,真正决定成本的不是模型 API 报价,而是 harness 层的工程实现质量。一个工程实现良好的 harness,可以让企业用同样的预算完成十倍以上的实际工作量;一个工程实现粗糙的 harness,即便底层模型再便宜,也会在 harness 层把成本放大回去。这意味着,在评估、选型、自建 AI 编程 Agent 的每一步里,工程团队都需要把 harness 层的优化作为一等公民的设计目标,而不是把它当作"事后调优"的次要事项。
