Paritok：本地压缩上下文省85% Token成本的开源工具

编程 Agent 的隐形成本：Token 账单

当开发者越来越依赖 AI 编程助手时，一个容易被忽视的问题浮出水面：Token 成本。Token 是大语言模型计费和处理的基本单位——它是模型将文本分词后的最小处理单元，英文中一个 Token 大约对应 4 个字符或 0.75 个单词，中文通常一个汉字对应 1-2 个 Token。现代大语言模型普遍采用 BPE（Byte Pair Encoding，字节对编码）或其变体作为分词算法——BPE 通过统计训练语料中字符对的共现频率，迭代地将高频字符对合并为新的子词单元，最终构建一个固定大小的词表（如 GPT-4 使用约 100K 大小的词表）。这意味着常见单词可能被编码为单个 Token，而罕见词或专业术语则被拆分为多个子词 Token。对于代码场景，这一特性尤为重要——变量名、函数名等标识符通常会被拆分为多个 Token（如 'getUserName' 可能被分为 'get'、'User'、'Name' 三个 Token），而常见的编程关键字和语法符号则往往对应单个 Token，这直接影响了编程 Agent 的实际成本估算。

以 GPT-4o 为例，每百万输入 Token 的价格约为 2.5-5 美元，输出 Token 更贵（通常是输入的 2-4 倍价格，因为生成过程的计算开销更大）。一个典型的编程 Agent 会话中，系统提示词、工具定义、代码文件和对话历史加在一起，单次请求动辄消耗数万甚至十万以上 Token。而 Agent 的工作模式决定了它需要多轮调用模型，每一轮都要重新发送完整上下文，这使得总消耗量远超人类手动对话的场景。

编程 Agent 的特殊之处在于其「循环调用」模式：Agent 观察环境→思考→行动→观察结果→再思考，每一轮循环都是一次完整的 API 调用，且必须携带之前所有轮次的上下文以保持连贯性。这一模式源于 ReAct（Reasoning + Acting）框架——由 Yao 等人在 2022 年提出，其核心创新在于将链式思维（Chain-of-Thought）推理与外部工具交互统一到一个交替执行的循环中：模型先生成思考（Thought）来分析当前状态，然后决定执行一个动作（Action），接收环境反馈（Observation），再基于新信息继续推理。在实现层面，每一轮循环对应一次完整的 LLM API 调用，且为了保持推理连贯性，所有历史的 Thought-Action-Observation 序列都必须作为上下文传入。这就解释了为什么一个包含 15 轮循环的 Agent 会话，第 15 轮的请求需要包含前 14 轮的全部内容加上系统提示和工具定义，形成严重的上下文膨胀。这种累积效应使得一个看似简单的「帮我重构这个模块」指令，可能在后台触发 10-20 次 API 调用，总 Token 消耗轻松突破百万。

无论是 Cursor、Claude Code 还是各类自建的编程 Agent，每一次交互都要将工具定义、文件内容、对话历史打包发送给大模型。随着会话变长，上下文膨胀，Token 消耗呈指数级增长，账单也随之水涨船高。这里的「上下文」指的是大语言模型的上下文窗口（Context Window），即模型单次处理能接收的最大 Token 数。Claude 3.5 的上下文窗口为 200K Token，GPT-4o 为 128K Token。上下文窗口的大小由模型的位置编码方式和训练时的序列长度决定——Transformer 架构中，自注意力机制的计算复杂度与序列长度的平方成正比（O(n²)），这意味着更长的上下文不仅意味着更多 Token 费用，也意味着更高的推理延迟和内存占用。

针对这一计算瓶颈，Flash Attention（由 Tri Dao 等人在 2022 年提出）提供了关键的工程优化。传统自注意力实现需要将完整的 N×N 注意力矩阵存储在 GPU 高带宽内存（HBM）中，当序列长度 N 达到 128K 时，仅注意力矩阵就需要数十 GB 显存。Flash Attention 通过分块计算（tiling）和在线 softmax 技巧，将注意力计算分解为可以在 GPU SRAM（片上高速缓存）中完成的小块，将内存复杂度从 O(n²) 降低到 O(n)，同时因减少内存访问而获得 2-4 倍的速度提升。结合 RoPE（旋转位置编码）等技术，这些优化使得 200K 上下文窗口在商用 API 中成为可能，但物理约束仍然存在——推理成本仍与序列长度成正比。

当编程 Agent 的累积上下文超过窗口限制时，系统必须截断或丢弃早期信息，这就是所谓的「爆上下文」——不仅导致模型丢失关键代码信息，还迫使开发者开启新会话，打断工作连续性。值得一提的是，2023 年 Liu 等人在论文《Lost in the Middle: How Language Models Use Long Contexts》中系统性地揭示了一个重要现象：当关键信息被放置在长上下文的中间位置时，模型的检索和利用能力显著下降。实验表明，模型对上下文开头和结尾的信息利用效率最高（呈现 U 形曲线），而中间部分的信息容易被「遗忘」。这一发现的实践意义在于：即使在窗口限制内，简单地将所有历史堆叠在上下文中并不是最优策略——智能地组织和压缩信息，确保关键内容出现在模型注意力集中的位置，可能比单纯扩大窗口更有效，进一步说明了智能压缩而非简单扩容的价值。

近期在 Product Hunt 上排名第三、获得 149 票的开源工具 Paritok 正是瞄准这一痛点。它的口号直截了当——「省下高达 85% 的成本，运行 3 倍更长的编程 Agent 会话」。

Paritok 的核心功能：压缩发送给模型的一切

Paritok 的核心思路是压缩编程 Agent 发送给大模型的内容：工具（tools）、文件（files）和历史记录（history）。这三类内容恰恰是编程 Agent 上下文中占比最大、也最容易冗余的部分。

• 工具定义压缩：一个成熟的 Agent 往往挂载了几十个工具，每个工具的 JSON Schema 描述都要占用 Token，而实际每次调用可能只用到其中一两个。在 Function Calling 机制中，每个工具需要以 JSON Schema 格式声明其名称、描述、参数类型和约束条件。Function Calling 是 OpenAI 在 2023 年引入、后被各模型厂商广泛采纳的 API 特性，开发者通过 JSON Schema（遵循 draft 2020-12 规范）向模型声明可用工具的接口规范，模型在推理时决定是否调用某个工具并生成结构化的调用参数。每个工具声明包含函数名、自然语言描述、参数的完整 Schema 定义（包括类型、枚举值、必填字段、嵌套对象结构等）。当这些定义被发送给模型时，API 层会将其转换为特殊的系统消息格式注入上下文，模型经过指令微调后学会了在适当时机生成符合 Schema 的 JSON 调用指令。值得注意的是，JSON Schema 的冗余语法结构（大量的花括号、引号、type 声明）在 BPE 分词后会产生大量低信息密度的 Token，使得实际 Token 占用往往高于开发者预期。这一机制是编程 Agent 能够执行实际操作（读写文件、运行命令、搜索代码等）的基础，但其代价是每次请求都必须携带完整的工具定义列表，因为模型是无状态的——它不会「记住」上一次请求中包含了哪些工具。一个中等复杂度的工具定义通常占 200-500 Token，而成熟的编程 Agent 如 Claude Code 可能注册了 30-50 个工具（文件读写、终端执行、搜索、Git 操作等）。这意味着仅工具定义部分就可能固定占用 6000-25000 Token，每次请求都要重复发送，即使本次调用根本用不到其中大部分工具。

• 文件内容压缩：代码文件被反复读取、重复塞进上下文，存在大量语义冗余。例如同一个文件在多轮对话中被完整传入三四次，但每次修改可能仅涉及几行代码，其余几百行都是重复信息。

• 对话历史压缩：随着会话推进，历史记录不断累积，是长会话成本失控的主因。一个持续 30 分钟的 Agent 编程会话，可能积累超过 50 轮对话，其中大量早期的工具调用结果和中间推理过程对后续任务已无直接价值。

通过对这些内容进行压缩，Paritok 声称可以将 Token 账单降低最多 85%，并让单次会话的持续时间延长至原来的 3 倍——这意味着 Agent 能在不「爆上下文」的情况下处理更复杂、更长链条的编程任务。

从技术路线来看，针对 LLM 上下文的语义压缩与传统数据压缩有本质区别。传统压缩（如 LZ77、Huffman 编码）基于信息论原理，通过消除字节序列中的统计冗余来减小数据体积，解压后可完全还原原始比特流。而 LLM 上下文压缩需要理解内容的「信息密度」，其目标不是还原原始 Token 序列，而是在减少 Token 数量的同时保持模型推理所需的信息完整性。这更接近有损压缩中的感知编码（如 JPEG 丢弃人眼不敏感的高频信息），只不过这里的「感知者」是 LLM 而非人类视觉系统。

学术界近年提出了多种方法：LLMLingua 系列通过小模型评估每个 Token 的困惑度来决定保留或删除；Gist Tokens 通过训练将长上下文压缩为少量特殊 Token 的嵌入表示；AutoCompressors 则让模型自身学会压缩历史。在工程实践中，当前业界探索的主要方法包括：基于摘要的压缩（用更短的文本概括长内容的关键信息）、基于引用的去重（对重复出现的代码片段仅保留一份完整版本，后续用指针引用）、选择性遗忘（根据任务相关性评估历史轮次的重要程度）、以及工具定义的动态加载（根据当前上下文预测可能需要的工具子集）。每种方法都有其权衡——摘要可能丢失细节，去重依赖准确的相似度检测，选择性遗忘可能误判重要性。

Paritok 的三大卖点：两条命令、无损、完全本地

官方强调了三个关键卖点：

• 两条命令接入：接入成本极低，开发者无需重构现有 Agent 工作流。这通常意味着 Paritok 以代理或中间件的形式工作——拦截 Agent 发往模型 API 的请求，对其中的内容执行压缩后再转发，对上层应用完全透明。这种「透明代理」设计在软件工程中有悠久历史：本地代理服务器监听与模型 API 相同格式的请求，对请求内容执行变换后转发至真实 API 端点，再将响应原样返回。Agent 框架以为自己在直接调用模型 API，模型 API 以为请求来自普通客户端。「两条命令接入」很可能指的是安装工具和设置代理地址（如修改环境变量中的 API base URL）这两步操作。

• 完全本地运行：压缩过程在本地完成，不需要将代码和上下文上传到第三方服务器，这对注重代码隐私和企业合规的团队尤为重要。在当前企业级 AI 采用的背景下，许多公司的安全策略严格限制代码外传，本地运行模式直接消除了这一合规障碍。

• 无损压缩：压缩不以牺牲信息完整性为代价，确保模型仍能获取完整语义信息。值得注意的是，传统无损压缩（如 gzip、zstd）作用于字节层面，而 LLM 接收的是 Token 序列。NLP 场景下的「无损压缩」通常指的是在不丢失语义信息的前提下减少 Token 数量。常见方法包括：去除重复代码片段的冗余引用、用摘要替代已确认的历史轮次、合并相似工具描述、以及利用模型已有知识省略通用说明。真正的难点在于判断哪些信息对模型的后续推理是必要的——去掉看似冗余的内容可能导致模型产生幻觉或遗漏约束条件。

为什么上下文压缩方向值得关注

上下文经济学正在成为刚需

随着 Agentic Coding（智能体编程）成为主流范式，Token 成本已经从「可忽略」变成了「必须优化」的工程问题。所谓 Agentic Coding，是指 AI 不再仅仅响应单次提问，而是自主规划任务、调用工具、迭代验证，形成完整的自动化编程工作流。

Agentic Coding 的发展经历了三个阶段：第一阶段是代码补全（如 GitHub Copilot 早期），模型被动响应光标位置的上下文，单次请求通常仅消耗数百至数千 Token；第二阶段是对话式编程（如 ChatGPT、Claude 的代码模式），开发者主动描述需求，模型生成代码片段，单次会话消耗从数千到数万 Token 不等；第三阶段即当前的 Agent 模式（如 Claude Code、Devin、Cursor Agent），AI 具备自主规划能力，能够分解复杂任务、读取项目结构、执行测试、根据错误自动修复。这一演进的关键转折点正是 ReAct 框架的提出，它将推理和行动统一在一个循环中。随着 Agent 自主性的提高，单次任务的 Token 消耗从数千级跃升至数十万甚至百万级，使得成本优化从「锦上添花」变为「生存必需」。

在这一范式下，一个复杂任务可能触发数十次模型调用，每次都携带完整上下文。长会话、多轮工具调用、大型代码库检索，这些都让上下文管理成为决定产品体验和成本结构的关键变量。

从行业趋势看，主要模型提供商正在通过扩大上下文窗口（如 Gemini 的 1M Token 窗口）来缓解这一问题，但更大的窗口意味着更高的单次调用费用。上下文压缩则从另一个方向解题：不是扩容器，而是减少水量。

Paritok 作为开源工具出现在这个赛道，本身就说明社区对「上下文压缩」这一细分需求的强烈共鸣。它不试图取代任何 Agent 框架，而是作为一个中间层，专注把「发送出去的字节」做到最精简。

本地化是差异化护城河

市面上并不缺 Token 优化方案，但大多数依赖云端处理或需要深度改造模型调用逻辑。例如，一些方案通过云端 API 对上下文进行预处理和摘要，这本身又引入了额外的网络延迟和数据安全风险。另一些方案要求开发者修改 Agent 的 prompt 模板或工具注册方式，侵入性较高。Paritok 选择「本地 + 低侵入」的路线，降低了开发者的信任门槛和迁移成本。对于将代码视为核心资产的团队而言，「不上传任何内容」是一个足够有说服力的采用理由。

理性看待：实际效果取决于使用场景

补充一点，「省 85%」和「3 倍会话时长」是产品方给出的上限值，实际效果会高度依赖具体场景：

• 如果你的 Agent 上下文本身就很精简（例如仅注册了 5-6 个工具、每次只传入单个文件片段），压缩收益自然有限
• 对于工具繁多、文件重复读取严重、会话冗长的重度使用场景，收益才可能接近宣传峰值

此外，「无损压缩」在自然语言和代码语境下的实现细节，以及压缩本身带来的本地计算开销，都值得开发者在真实项目中实测验证。压缩算法需要在每次 API 请求前执行，如果其延迟超过百毫秒级别，可能影响 Agent 的响应速度——这在快节奏的编程辅助场景中是需要权衡的因素。目前 Paritok 仅有 14 条评论，社区规模尚小，成熟度和长期维护情况仍需观察。

小结：Token 优化将成为 AI 编程的必修课

Paritok 代表了 AI 编程工具生态中一个正在快速升温的细分方向——上下文成本优化。它以开源、本地化、低接入成本的姿态切入，直击编程 Agent 用户的真实痛点。对于每月被 Token 账单困扰、或频繁遇到上下文超限的开发者来说，这类工具值得一试。

当 AI Agent 越来越强大、任务链越来越长，「如何用更少的 Token 做更多的事」将成为一门必修的工程学问。这一方向的探索不仅限于压缩——未来可能还会涌现更智能的上下文调度策略（如根据任务阶段动态调整上下文内容的优先级）、按需加载机制（仅在模型明确需要时才拉取特定文件或历史片段）、以及模型侧的稀疏注意力优化。在稀疏注意力领域，Longformer（2020）和 BigBird（2020）是代表性工作——标准 Transformer 中每个 Token 都与序列中所有其他 Token 计算注意力（全局注意力），计算量为 O(n²)，而稀疏注意力的核心思想是大部分 Token 只需要关注局部窗口内的邻居和少量全局锚点。Longformer 结合了滑动窗口注意力和全局注意力，将复杂度降至 O(n)；BigBird 在此基础上增加了随机注意力连接，证明了这种稀疏模式在理论上具有与全注意力相同的图灵完备性。这些架构允许模型在可控的计算预算下处理极长序列，但对于需要精确长距离依赖的任务（如代码中远距离的变量引用）可能存在性能损失。Paritok 正是这门课上的一个早期实践者，而整个赛道的竞争才刚刚开始。