DeepSeek Harness 长会话上下文折叠插件：按任务压缩 prompt，token 消耗降低 63.5%

1. 长会话的上下文膨胀问题到底出在哪

做过 AI 应用开发的人都有一个共同体会：单轮对话的体验很容易做好，一旦把会话拉长到几十轮甚至上百轮，成本和响应质量就会同时崩掉。我最近在做一个基于 DeepSeek Harness 的代码辅助工具，用户平均单次会话会持续 40 到 80 轮，中间夹杂着代码片段、报错日志、需求变更说明，上下文长度很快就顶到模型窗口的上限。最直观的感受就是账单涨得比功能迭代还快，而且模型在长上下文里的表现反而变差——它会开始"忘事"，把早期确认过的约束条件丢掉，或者把不同任务的上下文串在一起。

这个问题的本质不是模型不行，而是我们把所有历史消息无差别地塞进了 prompt。从 token 计费的角度看，每一轮请求都要把之前所有轮次的内容重新发一遍，第 N 轮的输入 token 大致是前 N-1 轮内容的总和。假设每轮平均产生 300 token 的对话内容，到第 50 轮时，单次请求的输入就已经累积到 15000 token 左右，而其中真正和当前问题相关的可能只有最后几轮。这就是典型的"上下文冗余"——历史信息里大量内容对当前任务毫无价值，却每一轮都在付费。

我写这个按任务折叠上下文的插件，核心目标就一个：让 prompt 里只保留和当前任务真正相关的上下文，把已经完结的任务压缩成摘要，把无关的闲聊和中间过程直接折叠掉。实测下来，在保持回答质量基本不变的前提下，prompt token 消耗降低了 63.5%。这个数字不是理论估算，是我在真实会话日志上跑出来的平均值，后面会讲具体怎么测的。

这篇文章适合几类人看：一是正在用 DeepSeek Harness 或类似框架做 AI 应用的开发者，二是被长会话成本困扰的产品负责人，三是对 prompt 工程和上下文管理感兴趣的技术同学。我会把设计思路、核心实现、参数选择、踩过的坑都讲清楚，代码层面的关键逻辑也会给出来，你可以直接参考复现。

2. 整体设计思路与方案选型

2.1 为什么选择"按任务折叠"而不是简单截断

处理长上下文最粗暴的办法是滑动窗口截断，只保留最近 N 轮。这个方案实现简单，但问题很明显：如果当前任务依赖 20 轮之前确认的一个接口定义，截断之后就丢了，模型会重新问你或者给出错误答案。另一个常见方案是做向量检索，把历史消息存进向量库，每轮根据当前问题召回相关片段。这个方案更智能，但引入了额外的检索延迟和 embedding 成本，而且召回质量不稳定，有时候该召回的历史没召回，不该召回的噪声反而进来了。

我最终选择的是"按任务折叠"这条路线。核心假设是：长会话本质上是由一个个独立任务串起来的，比如"改登录逻辑"是一个任务，"修支付回调的 bug"是另一个任务。任务内部的消息需要保持完整上下文，任务之间的消息大部分可以折叠。具体做法是给会话维护一个任务栈，当前活跃任务的消息全量保留，已完成任务的消息压缩成一段结构化摘要，与当前任务无关的闲聊和中间调试过程直接丢弃。

这个方案的好处是逻辑清晰、可解释性强，而且折叠后的摘要仍然保留了任务的关键结论，不会像截断那样直接丢失信息。代价是需要一套任务边界识别机制，这部分是难点，后面细讲。

2.2 插件在 DeepSeek Harness 里的挂载位置

DeepSeek Harness 的插件机制允许在请求发出前拦截并修改 messages 数组，这正好是上下文折叠的切入点。我的插件挂在 pre-request 钩子上，拿到完整的 messages 列表后，先做任务切分，再做折叠压缩，最后把处理过的 messages 交给框架发出去。这样对上层业务代码完全透明，不需要改任何调用逻辑。

选这个挂载点还有一个考虑：折叠逻辑只影响发出去的 prompt，不影响本地保存的完整会话记录。用户回看历史时看到的还是完整对话，只是每次请求时动态决定发多少。这样既省了 token，又不损失可追溯性。如果直接把折叠结果写回存储，用户会发现历史记录"缺了一块"，体验很差。

2.3 折叠策略的分层设计

我把折叠分成三个层次，按激进程度递增：

• 第一层：去重与合并。同一任务内重复出现的系统提示、工具返回的相同结果、连续多轮的确认性回复（"好的""收到""继续"），这些直接合并或删除，几乎不损失信息。
• 第二层：任务内摘要。当前任务如果本身就很长（超过阈值），把任务早期的消息压缩成摘要，只保留最近若干轮原文。这一层需要调用一次轻量模型做摘要，有额外成本，但只在必要时触发。
• 第三层：跨任务折叠。已完成任务整体压缩成一段结构化摘要，格式固定为"任务目标 + 关键结论 + 涉及的文件/接口 + 遗留问题"。这一层是省 token 的主力。

三层策略可以独立开关，默认全开。实测中第三层贡献了大部分节省，第一层几乎零成本就能拿到 15% 左右的收益，性价比最高。

3. 核心细节解析与实操要点

3.1 任务边界怎么识别

这是整个插件最核心也最难的部分。任务边界识别错了，要么把不该折叠的折了导致模型失忆，要么该折的没折省不下 token。我试过几种方案，最后落地的是一个混合策略。

第一种信号是显式标记。在系统提示里约定，当用户开启新任务时，消息里会带一个特殊标记（比如以特定前缀开头的消息）。这个最可靠，但依赖用户配合，实际使用中只有一部分用户会这么做。

第二种信号是语义漂移检测。计算相邻两轮用户消息的语义相似度，如果连续几轮相似度都低于阈值，就认为发生了任务切换。相似度用轻量 embedding 算，阈值我调到了 0.35 左右。这个方案能覆盖大部分自然切换的场景，但有个坑：用户在一个任务里突然插入一句无关的闲聊，会被误判为任务切换。我的处理是要求"连续两轮"低相似度才触发切换，单轮异常不触发。

第三种信号是工具调用模式变化。如果当前任务一直在调用文件读写工具，突然开始调用网络请求工具，很可能换了任务。这个信号作为辅助，不单独使用。

实际落地时，三种信号按优先级组合：显式标记最高，语义漂移次之，工具模式变化作为语义漂移的加权项。这样误判率能压到比较低的水平。

3.2 摘要生成的质量控制

跨任务折叠时要把一个任务压缩成摘要，摘要质量直接决定折叠后模型还能不能正确理解上下文。我踩过的坑是：早期用通用摘要提示词，生成的结果太"文学化"，把关键的技术细节（比如具体的函数名、参数值）都概括没了，导致后续任务引用时模型一脸茫然。

后来我把摘要提示词改成强结构化输出，要求必须包含四个字段：

任务目标: [一句话描述这个任务要解决什么] 关键结论: [最终确定的方案、修复方式、决策结果] 涉及实体: [文件路径、函数名、接口名、变量名等具体标识] 遗留问题: [未解决的部分、待确认的事项]

这个格式的好处是信息密度高，而且模型在后续任务里引用时能直接定位到具体实体。摘要长度控制在 150 到 250 token 之间，太短丢信息，太长省不下 token。生成摘要用的是一个便宜的小模型，单次成本可以忽略。

注意：摘要生成一定要用和主对话不同的模型调用，不要复用主对话的上下文，否则摘要本身就会带上冗余信息。

3.3 折叠触发时机的选择

不是每一轮都要做折叠。如果每轮都重新计算任务边界和摘要，计算开销会很大，而且摘要会反复生成导致不稳定。我的策略是事件驱动：

• 检测到任务切换时，立即对刚结束的任务做折叠
• 当前任务消息数超过阈值（默认 20 轮）时，对任务内早期消息做摘要
• 总 token 数超过模型窗口的 70% 时，强制触发一次全量折叠

这样大部分轮次是零开销的，只在关键节点做重计算。实测下来，平均每 8 到 10 轮才触发一次折叠，性能影响可以忽略。

3.4 参数配置与调优建议

插件暴露了一组配置项，我列一下默认值和调优方向：

这些参数没有万能值，得根据你的实际会话特征调。我的建议是先跑一周日志，统计平均任务长度和切换频率，再定参数。

4. 实操过程与核心环节实现

4.1 环境准备与插件安装

插件基于 DeepSeek Harness 的插件规范开发，安装方式和普通插件一致。先把插件包放到 Harness 的插件目录下，然后在配置文件里启用。我用的是 Linux 环境，Windows 和 macOS 流程基本一样，只是路径不同。

# 进入 Harness 插件目录 cd /path/to/deepseek-harness/plugins # 克隆插件（这里用本地包举例） cp -r taskfold-plugin ./taskfold # 确认插件结构 ls taskfold # 应该看到 manifest.json main.py config.yaml README.md

manifest.json 里声明了插件的挂载点和权限，关键是 pre-request 钩子的注册：

{ "name": "taskfold", "version": "1.0.0", "hooks": ["pre_request"], "entry": "main.py", "config": "config.yaml" }

然后在 Harness 的主配置里启用：

plugins: enabled: - taskfold taskfold: similarity_threshold: 0.35 task_msg_limit: 20 summary_max_tokens: 250

重启 Harness 服务后，插件就生效了。验证方法是发一条测试消息，看日志里有没有 taskfold 的处理记录。

4.2 任务切分逻辑的实现

核心的切分函数接收完整的 messages 列表，输出一个任务列表，每个任务包含消息索引范围和状态。我简化一下关键逻辑：

def split_tasks(messages, config): tasks = [] current = {"start": 0, "end": 0, "status": "active"} for i in range(1, len(messages)): prev = messages[i-1] curr = messages[i] # 显式标记优先 if is_explicit_new_task(curr): current["end"] = i - 1 current["status"] = "done" tasks.append(current) current = {"start": i, "end": i, "status": "active"} continue # 语义漂移检测 sim = compute_similarity(prev, curr) if sim < config["similarity_threshold"]: # 需要连续两轮低相似度才确认切换 if i + 1 < len(messages): next_sim = compute_similarity(curr, messages[i+1]) if next_sim < config["similarity_threshold"]: current["end"] = i - 1 current["status"] = "done" tasks.append(current) current = {"start": i, "end": i, "status": "active"} continue current["end"] = i tasks.append(current) return tasks

这里有个细节：相似度计算用的是轻量 embedding，不要用主模型，否则每轮都算一次成本太高。我用的是一