OpenRouter 平台功能

消息变换

1 分钟阅读

消息转换

转换提示词消息

为帮助处理超出模型最大上下文长度的提示词，OpenRouter 支持按请求启用上下文压缩插件：

{
  plugins: [{ id: "context-compression" }], // 压缩超出上下文长度的提示词。
  messages: [...],
  model // 适用于任何模型
}

这在不要求完美回忆的场景中很有用。该插件会从提示词中部删除或截断消息，直到提示词适配模型的上下文窗口。

有时问题不在 Token 上下文长度，而在消息条数本身。该插件也会处理这种情况：例如，Anthropic 的 Claude 模型最多允许 1000 条消息。启用上下文压缩后，若超过此限制，插件会保留对话开头一半和末尾一半的消息。

启用上下文压缩后，OpenRouter 会首先尝试寻找上下文长度至少达到你所需 Token 总量（输入 + 补全）一半的模型。例如，若提示词总共需要 10,000 Token，则会考虑上下文长度至少为 5,000 的模型。如果没有模型满足该条件，OpenRouter 会回退到使用可用上下文长度最大的模型。

随后，压缩会通过从提示词中部删除或截断内容，尝试将你的内容适配到所选模型的上下文窗口内。如果未启用上下文压缩，且 Token 总量超出模型的上下文长度，请求会失败，并提示你缩短长度或启用上下文压缩。

所有 OpenRouter 端点中上下文长度为 8k（8,192 Token）或更短的端点默认启用上下文压缩。若要关闭，请在请求体中传入 plugins: [{"id": "context-compression", "enabled": false}]。

对于仅输出图像（不输出文本）的图像生成模型，会自动跳过上下文压缩。这样可以保留图生图请求中的参考图像。否则压缩会截断多部分消息内容，并丢弃输入中的 image_url 部分。同时输出文本和图像的多模态模型（例如 Gemini、gpt-image）仍会使用压缩，因为它们具有真正的文本上下文窗口。

压缩提示词中部是因为 LLM 对序列中部的注意力更低。