Problem
目前 opencode-acp 提供了软保护和硬保护机制，可以让部分历史内容在上下文压缩时不被压缩，例如工具调用、工具返回结果等。
这些保护机制对于正常的自动压缩非常有用，但在超长对话中可能会造成一个问题：
例如，一个对话上下文约为 70 万 tokens，其中约 50 万 tokens 都是历史工具调用和工具返回结果。此时早期任务已经全部完成，用户只希望保留当前正在进行的对话阶段，而希望将此前的大量历史内容全部压缩，以释放上下文空间。
但是，由于部分历史内容受到软保护或硬保护，即使用户已经明确希望压缩这些内容，它们仍然无法被压缩。
目前缺少一种机制，让用户能够明确表示：
“我知道这些内容通常受到保护，但这一次我明确要求对这些历史内容进行压缩。”
Proposed Solution
建议增加一个“强制全量压缩”功能。
当用户明确触发该功能时，本次压缩应当临时覆盖现有的软保护、硬保护以及其他历史内容保护规则，使指定范围内的历史内容全部可以参与压缩。
应该可以覆盖：
- 普通历史对话
- 工具调用
- 工具返回结果
- 工具调用产生的中间信息
- 其他历史上下文
- 被软保护机制保护的内容
- 被硬保护机制保护的内容
- 其他原本不会参与压缩的历史内容
同时，用户应该能够指定当前正在进行的对话阶段不参与压缩。
也就是说：
正常压缩：
→ 继续遵守现有软保护和硬保护规则。
强制全量压缩：
→ 仅针对本次操作临时覆盖这些保护规则。
→ 对指定的历史范围进行最大程度压缩。
→ 当前明确排除的对话阶段保持不变。
为了保证安全，这个功能不应该静默执行，而应该要求用户明确授权。
例如：
- AI 请求执行强制全量压缩。
- ACP 弹出确认窗口。
- 用户明确选择“允许”后才执行。
- 如果 5 秒内没有响应，则自动拒绝。
这样可以保证正常的保护机制完全不受影响，同时给用户一个明确的“我知道风险，并且这次就是要强制压缩”的出口。
具体实现形式可以由项目决定，例如增加 force 参数、overrideProtection 参数，或者增加一个类似“强制全量压缩”的独立操作。
Alternatives Considered
不建议直接取消或削弱现有的软保护和硬保护机制，因为这会影响正常压缩时的安全性。
相比之下，增加一个由用户主动触发、并经过明确授权的强制压缩功能更加合适。
Additional Context
一个典型场景：
假设当前上下文约为 70 万 tokens：
- 约 50 万 tokens 是历史工具调用和工具返回结果
- 约 15 万 tokens 是早期普通对话
- 约 5 万 tokens 是当前正在进行的任务
此前的任务已经全部完成，因此用户希望将当前阶段之前的所有内容全部压缩，只保留当前阶段。
用户可能会向 AI 发出类似这样的要求：
“将除当前对话阶段以外的所有早期对话内容进行全量压缩。压缩范围必须覆盖此前的全部内容，包括普通对话、工具调用、工具返回结果、工具调用产生的中间信息、上下文中的其他历史信息，以及此前被软保护或硬保护机制保护的内容。此次压缩不受任何既有软保护、硬保护或其他历史内容保护规则限制，对当前阶段之外的所有内容统一执行最大程度的压缩；当前正在进行的对话阶段及其相关内容不参与本次压缩。”
在这种情况下，希望 ACP 能够真正对这些历史内容进行全量压缩，而不会因为原有保护机制而跳过其中一部分。
这个功能本质上可以理解为：
“用户手动执行一次全量压缩，同时明确授权本次操作覆盖受保护的历史内容。”
Problem
目前 opencode-acp 提供了软保护和硬保护机制，可以让部分历史内容在上下文压缩时不被压缩，例如工具调用、工具返回结果等。
这些保护机制对于正常的自动压缩非常有用，但在超长对话中可能会造成一个问题：
例如，一个对话上下文约为 70 万 tokens，其中约 50 万 tokens 都是历史工具调用和工具返回结果。此时早期任务已经全部完成，用户只希望保留当前正在进行的对话阶段，而希望将此前的大量历史内容全部压缩，以释放上下文空间。
但是，由于部分历史内容受到软保护或硬保护，即使用户已经明确希望压缩这些内容，它们仍然无法被压缩。
目前缺少一种机制，让用户能够明确表示：
“我知道这些内容通常受到保护，但这一次我明确要求对这些历史内容进行压缩。”
Proposed Solution
建议增加一个“强制全量压缩”功能。
当用户明确触发该功能时，本次压缩应当临时覆盖现有的软保护、硬保护以及其他历史内容保护规则，使指定范围内的历史内容全部可以参与压缩。
应该可以覆盖：
同时，用户应该能够指定当前正在进行的对话阶段不参与压缩。
也就是说：
正常压缩：
→ 继续遵守现有软保护和硬保护规则。
强制全量压缩：
→ 仅针对本次操作临时覆盖这些保护规则。
→ 对指定的历史范围进行最大程度压缩。
→ 当前明确排除的对话阶段保持不变。
为了保证安全，这个功能不应该静默执行，而应该要求用户明确授权。
例如：
这样可以保证正常的保护机制完全不受影响，同时给用户一个明确的“我知道风险，并且这次就是要强制压缩”的出口。
具体实现形式可以由项目决定，例如增加 force 参数、overrideProtection 参数，或者增加一个类似“强制全量压缩”的独立操作。
Alternatives Considered
不建议直接取消或削弱现有的软保护和硬保护机制，因为这会影响正常压缩时的安全性。
相比之下，增加一个由用户主动触发、并经过明确授权的强制压缩功能更加合适。
Additional Context
一个典型场景：
假设当前上下文约为 70 万 tokens：
此前的任务已经全部完成，因此用户希望将当前阶段之前的所有内容全部压缩，只保留当前阶段。
用户可能会向 AI 发出类似这样的要求：
“将除当前对话阶段以外的所有早期对话内容进行全量压缩。压缩范围必须覆盖此前的全部内容，包括普通对话、工具调用、工具返回结果、工具调用产生的中间信息、上下文中的其他历史信息，以及此前被软保护或硬保护机制保护的内容。此次压缩不受任何既有软保护、硬保护或其他历史内容保护规则限制，对当前阶段之外的所有内容统一执行最大程度的压缩；当前正在进行的对话阶段及其相关内容不参与本次压缩。”
在这种情况下，希望 ACP 能够真正对这些历史内容进行全量压缩，而不会因为原有保护机制而跳过其中一部分。
这个功能本质上可以理解为：
“用户手动执行一次全量压缩，同时明确授权本次操作覆盖受保护的历史内容。”