Paritok 的巧思：把 coding agent 的上下文压缩成可回取的指针

对 coding agent 来说，最容易失控的不是某一条提示词，而是每一轮都在变长的上下文：工具定义、文件读取结果、终端输出和旧对话会不断回到请求里。上下文窗口被填满后，用户通常只有两个选择：换更大的模型，或让 agent 忘掉一部分之前发生的事。

Paritok 没有另做一个编程界面，也没有试图替换 Claude Code、Cursor 或 Codex。它把自己放在 coding agent 和上游模型 API 之间，作为一个上下文压缩网关：agent 仍然照常发送工具 schema、历史消息和文件内容，Paritok 在转发前过滤、压缩或摘要这些输入，模型的响应再原样返回。官方页面把 Claude Code、Cursor、Codex 和 OpenHands 列为可接入对象；Product Hunt 页面则把使用路径压缩成获取 API key、启动 gateway、把 agent 指向 Paritok 三步。12

Paritok 的产品价值不在「把字变短」这么简单，而在于它如何决定哪些内容默认留在上下文里，哪些内容可以暂时退到后台。

普通摘要的危险在于：一旦原文被替换，agent 之后很难知道自己缺了什么。Paritok 选择了一个更像存储系统的方案。压缩文件读取结果、工具输出和较早的历史时，会给压缩片段打上 [REF:id] 标记；需要精确内容时，agent 可以调用 read_original(ref) 取回原始字节。工具 schema 也采用同一类思路：当前任务相关的工具保留完整定义，不相关工具先变成 stub；如果之后确实需要，再用 gateway_search_tools 找回完整 schema。13

这个决定改变了「上下文压缩」的交互对象。Paritok 没有要求 agent 永远相信一份摘要，而是把上下文分成两层：默认可见的工作集，以及需要时才读取的原文。模型每一轮不必背着所有工具和旧输出前进，但关键细节仍然有一条可定位的回取路径。

官方仓库给出的示例很直观：同一个文件读取结果从 3,000 tokens 压到 780 tokens，页面标注为 26%，并说明路径、标识符和错误信息等内容会被保留；官方首页则把工具 schema 从约 29K tokens 压到约 8K/turn，旧历史在超过预算后才进入摘要流程。13

这套设计解决的是 coding agent 的一个微妙痛点：多数上下文并非每一轮都同等重要，但用户也不愿意用一次不可逆的摘要赌掉关键细节。工具定义、日志和文件内容可以先退居二线，模型仍能在发现线索不足时再把它们拉回来。

代价同样落在产品设计里。回取动作必须被模型正确发现和调用；如果压缩器漏掉了一个工具，或者模型没有意识到某个 [REF:id] 值得展开，用户看到的就不是「更短的上下文」，而是 agent 突然失去能力。Paritok 仓库的公开 issue 列表里，已经出现「静默无效果的压缩难以和没有可压缩内容区分」、非 MCP 工具被丢弃导致 Claude Code 找不到 Read/Glob/Grep 等反馈。issue 标题不能证明每个环境都会复现问题，却说明可恢复设计必须同时提供可见的压缩状态、工具发现和失败提示，不能只在后台做一层魔法。4

Paritok 的第二个选择更容易被忽略：它不要求用户迁移到一个新的 coding agent。官方示例只需要把 agent 的上游地址指向本地 gateway，例如设置 ANTHROPIC_BASE_URL=http://127.0.0.1:8080；agent 的编辑器、命令、审批和操作习惯都留在原处。Paritok 处理请求，模型响应则不被改写。1

这是一种很克制的产品入口。用户不是先学习「如何使用 Paritok」，再重新学习一套 agent；用户只是在已有工作流前面插入一个可替换的地址。对于基础设施产品，这比做一个漂亮的监控面板更重要：产品把交互成本放在接入时，把收益留在每一次原有的 agent 会话里。Product Hunt 页面把这种路径概括成「Two commands」，并同时展示本地自托管和多个 agent 的兼容性。2

API 边界也让 Paritok 可以同时处理三种不同的重复内容：工具 schema 由网关按当前意图筛选，文件与工具输出由压缩模型缩短，超出预算的旧历史则被摘要。上游 agent 不需要为每种模型重新实现一套「如何省上下文」的界面，Paritok 把这项变化放进请求转发层。官方仓库称，在默认约 40 个工具的配置下，端到端 token 节省从首轮约 25%逐步升到第 20 轮约 63%，长会话或上下文饱和时可超过 85%；这些数字是项目自己的评测口径，不是所有 coding agent 都能得到的保证。3

但「插在中间」也意味着 Paritok 必须理解不同 agent 和模型协议的边界。仓库 issue 列表中，用户反馈包括 Claude Code 缺少依赖导致接入受阻、Gemini 的 OpenAI 兼容接口拒绝某些合成 tool_calls，以及静默的外部网络依赖削弱「自托管、没有数据离开本机」的承诺。这些反馈未必代表产品的最终状态，却揭示了网关方案的固定成本：入口越隐形，协议、权限和网络行为就越需要被显式说明。4

Paritok 最有意思的地方，是把「上下文太长」从模型能力问题改成了一个可设计的工作集问题。工具、文件和历史不必每轮完整出现，也不该在摘要后永久消失；更合理的做法是让默认上下文保持轻量，同时给关键内容留下稳定、可发现、可验证的回取入口。

对于任何需要长期运行的 AI agent，这条原则都可以直接拿来检查产品：哪些信息可以暂时隐藏，隐藏后如何找回，用户能不能看见系统刚刚压缩了什么。Paritok 给出的答案不是更大的聊天框，而是一层位于 agent 与模型之间、把省上下文和可恢复性绑在一起的网关。