从 Token 看本地插件:上下文外的零成本处理

一、本地插件是什么，解决了什么问题

本地插件是 Agent 的"本地处理器"——在数据进入模型上下文之前，先在本地完成压缩、过滤、转换，只把精简后的结论喂给模型。

和 MCP、Skills 的本质区别在于：

MCP 把外部工具的完整定义塞进上下文，让模型"亲自去仓库搬货"
Skills 把知识规则塞进上下文，让模型"按手册操作"
本地插件 在本地消化数据，只把结论塞进上下文，让模型"看摘要做决策"

OpenCode 的插件架构提供了丰富的 hooks：

Hook	作用	Token 影响
`tool.execute.before`	拦截工具执行前，修改参数	零注入，可压缩输出
`tool.execute.after`	拦截工具执行后，修改结果	零注入，可过滤结果
`experimental.chat.system.transform`	修改 system prompt	可注入，也可精简
`chat.params`	修改 LLM 调用参数	零注入

但这里有一个关键区分：不是所有本地插件都是零开销的。

二、本地插件的两类 Token 行为

本地插件按设计方式分为两类，Token 开销截然不同：

第一类：纯拦截型——零 overhead

这类插件只通过 hooks 拦截或修改已有工具的执行流程，不添加新的工具定义。

插件	机制	Baseline 开销	节省效果
RTK	`tool.execute.before` 拦截 bash，本地压缩输出	0 tokens	shell 输出 60-90%
OpenSlimedit	修改现有工具描述 + 精简 read 输出	0 tokens	综合 11-45%

为什么能做到零开销？ 因为它们不调用 tool() API，不在 system prompt 里注册新工具。它们只是"在数据流经管道时做处理"，管道本身没有变粗。

第二类：工具增强型——少量 but 有 overhead

这类插件通过 tool() API 添加自定义工具，会注入工具定义到 system prompt。

插件	注入内容	Token 开销	目的
opencode-triage	`triage({ query })` 工具	59 tokens	替换 1,226 tokens 的 skill XML 列表，净节省 95%
opencode-memelord	`memory_start_task` 等 4 个工具	未公开测量	提供持久化记忆功能
hashline（实验方案）	自定义 read 工具 + system prompt 注入	+14~50% token 增长	用 hash 标记行号，结果反而更费 token

关键洞察：工具增强型的开销通常很小（几十 tokens），而且设计目的是用少量开销替换更大的原生开销（如 opencode-triage 用 59 tokens 替换 1,226 tokens）。但如果设计不当（如 hashline），反而会让 token 增长 14~50%。

三、纯拦截型的代表：RTK

RTK（Rust Token Killer）通过 tool.execute.before hook 透明拦截 Bash 命令，重写为 rtk 等价命令。

Token 行为：

Baseline 开销：0 tokens（不注入 system prompt，不添加工具定义）
触发后开销：0 tokens（只压缩输出，不增加额外内容）
节省效果：shell 输出 tokens 减少 60-90%

实测数据（一周追踪）：

指标	安装前	安装后	节省
平均 tokens/会话	45,000	12,000	73%
Shell 输出 tokens	18,000	2,100	88%
日均成本	$3.20	$0.85	73%

四、纯拦截型的代表：OpenSlimedit

OpenSlimedit 通过三个机制工作：

压缩工具描述：把 OpenCode 内置工具的冗长 description 替换成极简版本
精简 read 输出：去掉绝对路径、type tags、footer boilerplate
行范围编辑扩展：允许 "55-64" 行范围，避免模型在上下文中重复大段代码

Token 行为：

Baseline 开销：0 tokens（不添加新工具，只修改现有工具描述）
节省效果：综合 11-45%

多模型实测：

模型	Baseline	OpenSlimedit	节省
GPT 5.3 Codex	77,494	42,509	-45.1%
Claude Sonnet 4.5	120,884	81,471	-32.6%
Claude Opus 4.6	60,841	47,590	-21.8%
GPT 5.2 Codex	39,185	28,713	-26.7%
Minimax M2.5 Free	28,031	21,073	-24.8%

关键洞察：工具描述压缩是最大的收益来源。因为工具 schema 是每次 API 调用都发送的，压缩它们的效果会复利累积。

五、工具增强型的代表：opencode-triage

opencode-triage 是一个典型的"用少量开销换大量节省"的工具增强型插件。

它发现 OpenCode 的 Skill 索引机制有一个问题：即使 Skill body 是懒加载的，name + description 的 XML 列表仍然每轮都注入。

解决方案：

隐藏全部 skill 的 XML 列表
暴露一个 triage({ query }) 工具定义（59 tokens）
通过关键词匹配 + IDF 权重 + 拼写纠正做路由
只把匹配到的 skill 注入 prompt

实测数据（19 个 skill）：

模式	每轮 Token 开销
原生 OpenCode	1,226 tokens
+ opencode-triage	59 tokens
净节省	1,167 tokens（95%）

结论：opencode-triage 确实注入了 59 tokens 的工具定义，但它用这 59 tokens 替换了 1,226 tokens 的原生开销。净效果仍然是节省。

六、工具增强型的反面教材：hashline

hashline 是一个实验性方案，试图用 hash 标记行号来优化代码编辑。

它通过 tool() API 添加自定义 read 工具，并在 system prompt 中注入指令。结果：

Token 开销增长 +14~50%
因为自定义工具 schema + system prompt 注入的 per-step overhead 超过了节省

OpenSlimedit 明确排除了 hashline 的对比："hashline 的自定义工具 schema 和 system prompt 注入增加了每步开销，抵消了所有节省。"

教训：工具增强型插件必须确保"注入的开销 < 替换的原生开销"，否则得不偿失。

七、实操建议

1. 优先使用纯拦截型插件

纯拦截型插件（RTK、OpenSlimedit）是性价比最高的选择：零 baseline 开销，装上就省钱。

2. 工具增强型插件要算净账

如果要用工具增强型插件，先算一笔账：

它注入了多少 tokens？（通常几十到几百）
它替换了多少 tokens？（通常是几千到几万）
净节省 = 替换的 - 注入的

opencode-triage 的 59 → 1,226 是正面案例。hashline 的 +14~50% 是反面案例。

3. 多插件叠加使用

RTK、OpenSlimedit 两者互补，不冲突：

插件	类型	解决什么问题	节省
RTK	纯拦截型	Bash 输出膨胀	60-90%
OpenSlimedit	纯拦截型	工具描述膨胀	11-45%
opencode-triage	工具增强型	Skill 索引膨胀	净 95%

4. 自己写插件时，优先用 hooks 而非 tool()

如果你要写自定义插件，优先通过 hooks 拦截已有工具，而不是通过 tool() 添加新工具。

八、结语

本地插件不是天然的"零开销"，它的 Token 效率取决于设计选择：

纯拦截型（RTK、OpenSlimedit）：不添加工具定义，不占用 system prompt，baseline 为零。这是"装上后只省钱不花钱"的选择。
工具增强型（opencode-triage、memelord）：会注入少量工具定义，但设计目的是用少量开销替换更大的原生开销。净效果通常是节省，但需要算清账。

MCP 给你能力，Skills 给你纪律，本地插件给你控制权。三者不是替代关系，而是分层协作：

MCP：只接跨系统工具（GitHub、数据库、外部 API）
Skills：只装高频使用的工程规范
本地插件：优先用纯拦截型处理所有高频本地数据转换和压缩

Token 效率 = 可用上下文 / 总上下文。 纯拦截型本地插件不增加分母，只减少分子中的噪音。这是唯一一种"装上后只省钱不花钱"的扩展方式——前提是你选对了类型。