这个插件用一句话就能说明白是什么，简单说，他是 opencode 上目前最新先进（可能也是所有 agents 最先进）的上下文压缩插件，他支持：
- 超长会话：实测最低支持 5 亿 token 级别上下文不丢关键信息，持续工作数日不换窗口。
- 极省 token：20w 上下文足够，按需使用上下文，绝大多数情况下上下文都维持在 10w 左右，对于 100w 上下文模型，长期工作实测省 5 倍 token 。
好，接下来详细介绍这个插件如何实现以上能力的。
压缩哲学
- 模型在任何时候不能知道总上下文大小。（模型不再懒于压缩）
- 一些压缩都服务于当前上下文任务。（模型有权拒绝压缩，或者少量压缩）
- 只有可压缩的内容出现才提示模型压缩。（防止过度压缩）
- 最近 N 条消息永远保留。（防止模型漂移）
- 分段压缩，N 级蒸馏压缩。（蒸馏自己过去自己的记忆，逐渐遗忘而不是断崖式忘却）。
- 上下文永远不删除，只隐藏。（日后模型可以找回记忆）
工作原理
不同于传统上下文压缩插件，等会话满了（比如 80%）再着手压缩。ACP 会基于一个增长节点触发上下文压缩，对于 100w 上下文模型这个数值是 5w token 。然后模型会收到一个注入（用户不可见），告诉模型应该压缩，如何压缩。
注意，ACP 不会让模型压缩所有内容，而是：
- 压缩过去一段时间增长的，现在大概率不再使用，尤其是工具调用，大量日志，冗余文件。
- 小范围压缩，而不是过去所有内容全部压缩。
不会压缩：
- 最近在使用的 5 条消息
- 最后 1 条用户消息。
防止模型压缩后漂移。
模型可以选择压缩还是拒绝压缩。实际测试 90%情况模型会选择压缩，10%左右会延后压缩。模型为了上下文工作质量和节省上下文会做自主出这个选择。
长久工作后，上下文大概长这个样子：
压缩块 b1 1000token 000001 ～ 000030 扫描代码，理解用户需求...
压缩块 b2 1200token 000031 ～ 000080 分析问题，定位 bug 原因...
压缩块 b3 2100token 000081 ～ 000150 问题已经修复，修复方案...
...
010000 ～ 010200 未压缩，可能使用中
010201 ～ 010400 未压缩，当前会话，使用中
压缩块具体内容我有一个冗长的约束，经过俩月调试这个约束确认给出来的质量非常高。参考How To Compress .
三级压缩
压缩块永远保留，上下文会逐级增长，虽然增长缓慢。根据经验测试，压缩消息比例：平均58：1。也就是原始消息 5w token,压缩后 900 token 左右。
这样经过长久迭代，会话达到数亿 token 后，比如 5 亿 token 后，压缩块可能也满 5w token 了。
为了防止这种泄漏，会触发t2 压缩。
t2 压缩后，5w token 会降低到 5000 到 1w token 左右。
久而久之，t2 也满 5w 了，就会触发 t3 压缩。
经过测算，
stateDiagram-v2
Raw --> Tier1 : compress （约每 7 轮）
Tier1 --> Tier2 : distill （约每 250 轮）
Tier2 --> Tier3 : condense （约每 2500 轮）
Tier1 --> Raw : decompress
Tier2 --> Raw : decompress （递归）
Tier3 --> Raw : decompress （递归）
Tier1 --> GC_Truncated : GC （ 100% 上下文）
会话容量 — 一个会话从空 → T1 → T2 → T3 → 上下文极限，总共可以处理多少 token （真实校准：500 次 API 调用/天，~9.6K 新 token/调用，T1=45x/T2=10x/T3=3x ）：
| 上下文上限 | 1 个月 | 3 个月 | 到极限 | 极限时间 |
|---|---|---|---|---|
| 1M | 19 亿 tok | 105 亿 tok | 689 亿 tok | 第 259 天（~8.6 月） |
| 400K | 19 亿 tok | 103 亿 tok | 103 亿 tok | 第 89 天（~3 月） |
| 400K （ 200 调用/天） | 5.6 亿 tok | 25 亿 tok | 95 亿 tok | 第 212 天（~7 月） |
Token 节省 — 无 ACP 时上下文无限增长，约 100 次 API 调用后崩溃（~0.2 天）。有 ACP 时上下文被压缩在有界范围：
| 指标 | 无 ACP | 有 ACP （ 1M 模型） |
|---|---|---|
| 会话寿命 | ~0.2 天 | 259 天（长 1295 倍） |
| 总 token 产出 | ~5200 万 | 689 亿（多 1325 倍） |
核心价值：ACP 不是减少每次调用的 token 成本，而是让一个会话能处理 1000 倍以上的工作量。
PS：当然额外带来的好处是，100w 上下文省 5 倍 token 。
如何找回记忆？
插件提供了两种方式恢复记忆：search_context 和 decompress。
模型可以搜索自己的上下文，然后找到相关的块直接解压。也可以回忆上下文，直接解压。瞬间恢复所有上下文细节。
实战测试
真实工程中的上下文情况。
在 6 个活跃工程会话（ 11,000+ 次 API 调用）中，上下文 p90 稳定在 15 万–19 万（ 15–19%），p95 在 16 万–21 万（ 16–21%）—— 聚合缓存命中率达 91%。（注意这是平均缓存命中率，不是单会话命中率——后面对 Prompt 缓存的影响会解释，这实际上比传统压缩算法大幅度节省了 token 。）
| 会话 | 时长 | 消息数 | API 调用 | 累计 token | 缓存命中率 | 上下文 p50 | 上下文 p90 | 上下文 p95 |
|---|---|---|---|---|---|---|---|---|
| 0b89319b | 230h (9.5d) | 3,344 | 2,796 | 3.39 亿 | 93% | 10.8 万(11%) | 16.7 万(17%) | 21.0 万(21%) |
| 0a3be0cd | 130h (5.4d) | 3,183 | 2,499 | 2.76 亿 | 91% | 10.4 万(10%) | 14.5 万(15%) | 15.3 万(15%) |
| 0b2cd5a7 | 131h (5.4d) | 2,560 | 2,181 | 3.14 亿 | 91% | 14.2 万(14%) | 19.1 万(19%) | 19.7 万(20%) |
| 08f2d501 | 37h (1.5d) | 1,985 | 1,888 | 1.96 亿 | 95% | 10.0 万(10%) | 15.6 万(16%) | 16.8 万(17%) |
| 1410c791† | 865h (36d) | 1,279 | 1,100 | 2.18 亿 | 87% | 13.2 万(13%) | 40.7 万(41%) | 42.7 万(43%) |
| 096cf8c4 | 72h (3d) | 1,041 | 918 | 0.91 亿 | 89% | 9.2 万(9%) | 14.8 万(15%) | 16.1 万(16%) |
† Bug 测试会话，p95 异常偏高。排除该会话后，其余会话 p95 均 ≤ 21 万。
（上下文百分比均以 1M 窗口计。）
问题
1.缓存命中率如何？
实测大部分时间缓存命中率在 98%到 99%之间。
2.缓存在什么时候失效？失效比例？
在触发压缩的时候，一般失效最近 5w token,但是这 5w token 会被删除导致的失效，而不是破坏。
实际上每次调用省了这 5w token 。
3.真的能省 5 倍 token 吗？
100w 上下文场景能省 5 倍 token,省的原因是，上下文总是保持在 20w 以下，每次调用都是按照上下文 token 计费的，只要保持上下文尽可能低，就会省 token 。
4.相比一些其他插件哪个更省 token ？
ACP 更省 token,其他插件大部分原理是减少工具输入，减少模型输出等方式，这种治标不治本。
因为 ACP 直接删掉了工具输入和模型输出，治本。
5.你在多大的项目测试过？
我的项目总代码是 100w 行，我经常在这个量级跑。
PS：上下文是按需动态的，原则是需要多少用多少。
6.你这个插件适合执行大任务不适合执行小任务？
这是误区，实际上，ACP 同时适合执行大任务和小任务。只要你上下文大于 5w,用 ACP 一定是节省的，并且可以长久工作。
7.上下文保持在 10w 以下必要吗？是不是很极端？
首先说明，不是我要求必须保持上下文 10w 以下的，ACP 的原则是，按需使用 token ，大多数情况下，确实 10w 上下文足够了，这个是实测自然结果。不是强制压缩到这个范围。
8.压缩质量如何？
个人体验，压缩质量超级好（当然也取决于你的模型是否聪明）。这个你自己实践了才是最好的。
9.模型会不会失忆？
在很长的会话里面，比如连续独立工作 1 天的任务，模型基本不会失忆，这是因为 T1 压缩质量足够好，大概率还没有触发 T2 压缩。
即使触发了 T2,模型会有模糊不精确的记忆，模型可以通过解压工具找回精确记忆。
10.一个会话你一般工作几天？
一般我会按照主题搞很多会话，把一个会话当作数字员工。 一个会话我一般不关。工作数十天。目前最长会话 10 亿 token 上下文，工作了半个月。还能接单。
11.ACP 和 DCP 是什么关系？
opencode-acp 最原始的代码 fork 自opencode-dynamic-context-pruning ，经过了大量优化后，现在已经完全脱骨于 dcp 了。ACP 的压缩理念已经发生了翻天覆地变化。
虽然 ACP 目前还是用 DCP 的框架，但是实际上其核心压缩算法已经完全不同于 DCP 。ACP 已经不是 DCP 的增强版本和 bug 修复版，而是一个新的独立的上下文压缩版本。其实际效果要远远领先 DCP 。
12.其他 agent 支持 ACP 主动上下文压缩吗？
pi 也支持 pai-acp，而且效果更好。在 pi 中，上下文可以控制到 15w 以下。大部分时间上下文在 8w 以下。超级超级省 token,而且可以连续工作好多天。
放一个开发 pai 自己的会话
pai-acp 会话统计
会话 ID: 019fbb41-8c70-701f-9403-9b17c118c173
项目: pai-acp(~/projects/pai-acp)
统计时间: 2026-08-02
会话时长: 自 2026-08-01 02:57 起(约 1.8 天)
pi 统计(累计)
| 指标 | 数值 |
|---|---|
| 消息总数(jsonl 行) | 5,906 |
| assistant 轮次 | 2,909 |
| API 请求数 | 2,909 |
| 累计输入 token(求和) | 327,552,040 |
| 最大单次请求 token | 258,780 |
| 最小单次请求 token | 0 |
| 平均单次请求 token | 112,599 |
| 最近 5 次请求 token | 81,983 / 82,456 / 83,376 / 83,901 / 84,696 |
ACP 压缩统计
| 指标 | 数值 |
|---|---|
| 当前上下文用量 | ~85K(约 8.5% / 1M 窗口) |
| 活跃压缩块 | 53 个 |
| 块摘要总量 | 32.1K |
| 原始内容总量(压缩前) | 957.8K |
| 整体压缩比 | 957.8K → 32.1K(~30×) |
上下文构成(breakdown)
| 类别 | token | 占比 |
|---|---|---|
| tool | 63.0K | 64% |
| summaries | 32.1K | 32% |
| text | 4.0K | 4% |
分层使用
| 层级 | token |
|---|---|
| T1(捕获) | 29.9K |
| T2(蒸馏) | 2.2K |
效果小结
- 上下文长期稳定在 ~85K(1M 窗口的 8.5%),即使累计已处理 3.27 亿 token 。
- 53 个压缩块把 957.8K 原始内容压到 32.1K(30×),且这些是可搜索、可解压的。
- 单次请求 token 峰值 258K,均值 112K,远低于无压缩时的线性增长(5,906 条消息无压缩会远超 1M)。
- T2 蒸馏已开始工作(2.2K),说明多级架构正在按预期逐层精炼。
PS：我已经准备全面切 pi 了。
13.codex 和 claude 支持这个插件吗？
说实话，我也想支持，不过二者都不开放完全接管上下文的接口。所以无法支持。
其他 agents 如果你需要可以告诉我，我去看看是否支持上下文接管接口，只要支持就可以迁移过去。
14.项目地址在哪里？如何安装
https://github.com/ranxianglei/opencode-acp
opencode plugin opencode-acp@latest --global
# 或者稳定版本
opencode plugin opencode-acp@stable --global
https://github.com/ranxianglei/pai-acp
pi install npm:pai-acp
15.老用户遇到很多问题怎么解决？
建议升级最新版本，过去一个月频繁更新，基本解决了大部分问题。如果求稳定可以安装 opencode-acp@stable版本。
16.其他问题？
如果有 bug 或者问题麻烦直接到 github 上提哈，更多在 github 那边。
Select Language