MetaCaster：元学习与Agent驱动的少样本时间序列预测实践

时间序列预测里最让人头疼的问题，往往不是模型不够强，而是数据不够多。

你拿到一个刚上线两周的业务序列，翻来覆去只有几百个点，却要预测未来七天的走势。试了 Transformer，过拟合；试了 ARIMA，趋势都抓不住；试了手工调参，调来调去还是那两条线。这时候你可能会想：如果可训练样本这么少，能不能把“预测流程本身”变成可以被学习、被自动优化的对象？

MetaCaster 这个研究方向，就是在回答这个问题。从论文标题拆开看，它做的是三件事的组合：用元学习（Meta-Learning）解决少样本（Few-Shot）问题，用 Agent 和 Harness 解决流程自动化问题，用轻量预测器解决部署成本问题。整体目标是端到端地训练一个轻量级时间序列预测器，让它在目标数据很少的情况下也能快速适配。

这篇文章不打算复述原文的每一个公式，而是从工程和算法两个角度拆解：MetaCaster 到底优化了什么，和传统 Few-Shot / AutoML 有什么区别，如果你想在自己的小样本时间序列项目里复现类似思路，应该从哪里下手。读完之后，你能理解元学习、Agent、Harness 几个概念在时间序列场景下的真实作用，也能拿到一套可以修改运行的 PyTorch 最小实现骨架。

1. 这篇文章真正要解决的问题

先明确几个现实场景。

第一类场景是“冷启动预测”。新业务线、新店铺、新设备，只有几天或几周的历史数据，但业务方要求你给出未来一个周期的预测。传统监督学习在这里基本失效，因为样本量太少，模型的方差会非常大。

第二类场景是“多任务长尾预测”。系统里可能有几千个预测对象，大部分对象的历史数据都很短，只有少部分对象有足够长的数据。如果给每个对象单独训练一个模型，训练成本高，而且短序列模型很容易过拟合；如果只训练一个统一模型，又很难照顾到不同对象之间的差异。

第三类场景是“持续适配”。今天预测的是 A 商品销量，明天换成了 B 商品；今天数据分布还正常，明天促销活动改变了数据形态。模型必须快速吸收新信息，同时不丢失过去学到的通用规律。

MetaCaster 这类方案的核心假设是：与其为每一个新任务从头训练模型，不如在大量历史任务上学习一个“如何快速适配”的通用策略。学习到的不是单一模型，而是一组元知识，包括模型初始化、算法超参、学习率，甚至 Agent 的决策策略。当新任务出现时，只需要少量样本、少量梯度更新，就能得到一个可用的预测器。

这里有一个容易误解的地方。很多人看到 Few-Shot Learning，会以为它的目标是让模型在“极少量样本”上直接拟合出很高精度。实际上，Few-Shot 的目标是在“数据少”的前提下，通过元学习的任务分布和先验知识，把模型从过拟合边缘拉回来。它不保证预测绝对准确，但保证适配过程稳定、收敛快、不崩坏。

所以，这篇论文真正要解决的问题，可以概括成三句话：

• 样本少：目标域只有很少的时序样本，无法独立训练复杂模型。
• 流程碎：传统预测流程里特征工程、模型选择、超参搜索、验证评估是割裂的，难以统一优化。
• 部署重：复杂的 Transformer 大模型在小数据场景容易过拟合，且推理成本高，需要轻量模型来处理。

2. 核心概念拆解：从 Few-Shot、Meta-Learning 到 Meta-Harness 与 Agent

在进入代码之前，先把几个概念讲清楚。这些术语在标题里压在一起，很容易让人头晕，但它们各自承担的任务其实很清晰。

2.1 时间序列预测的基础设定

时间序列预测最常见的形式是：给定过去一段窗口的历史观测值，预测未来一段窗口的目标值。

历史窗口 lookback = [x_1, x_2, ..., x_T] 预测窗口 horizon = [y_1, y_2, ..., y_H]

在 Few-Shot 场景下，我们不是一次性拥有很长的历史序列，而是只有很短的一段序列，或者只有很少几条完整序列。传统模型在这个设定下很难训练，因为模型需要从有限的输入输出对中学习映射关系。

2.2 元学习：学习“如何学习”

元学习的核心单位不是单个样本，而是“任务”。每个任务由两部分组成：

• 支持集（Support Set）：用于快速适配的小样本数据。
• 查询集（Query Set）：用于评估适配效果的验证数据。

在训练阶段，算法会不断从任务分布中采样任务。对每个任务，模型先用支持集做几步梯度更新，再用查询集计算损失，最后根据查询损失更新模型的元参数。这个“在任务内更新 + 跨任务更新”的双层结构，是元学习的本质。

常见的元学习算法有 MAML、Reptile、ProtoNet 等。对于时间序列预测，因为输出是连续值，所以 MAML 和 Reptile 这类基于优化的方法更常见。Reptile 的实现更简单，适合工程落地。

2.3 什么是 Harness

Harness 在 Agent 类系统里通常指“执行框架”。它负责管理 Agent 的循环：观察环境、调用工具、执行动作、收集反馈。你可以把它理解成 Agent 和底层环境之间的一层“调度层”。

MetaCaster 标题里的 Meta-Harness-Optimized，强调的不是对单个 Harness 配置做手工调参，而是把 Harness 的执行策略也放到元学习目标里一起优化。这是它区别于普通 AutoML 的关键点。

2.4 Agent 在时间序列预测里扮演什么角色

Agent 在这里，你可以理解为“自动建模决策器”。它每一步观察当前数据特征和模型状态，选择一个动作，比如：

• 选择历史窗口长度；
• 选择预测模型结构；
• 选择学习率或训练步数；
• 决定是否需要更换特征。

Agent 的目标是最大化最终验证指标，比如最小化预测误差。它的策略可以是强化学习学出来的，也可以通过元学习框架学出来。

2.5 轻量预测器

轻量预测器是指参数量小、推理速度快、适合部署到 CPU 或边缘设备的模型。常见选择包括线性模型、MLP、小型 TCN（时序卷积网络）、小型 LSTM，以及经过裁剪的 PatchTST 变体。MetaCaster 强调轻量级，是因为元学习框架要反复执行内循环更新，如果基础模型太大，训练和推理成本都会翻倍。

下表总结这几个概念在本文语境里的含义：

术语	传统理解	在 MetaCaster 语境下的含义
Few-Shot Learning	样本量很少的分类/回归任务	用极少量时序样本完成预测模型适配
Meta-Learning	跨任务学习共享知识	学习通用初始化、通用超参策略和 Agent 决策策略
Harness	Agent 的执行框架	被元学习优化的端到端建模流程框架
Agent	自主决策的智能程序	负责选择模型、窗口、超参等动作的决策器
Lightweight Forecaster	参数量小的轻量模型	支持快速内循环更新、易部署的时序预测器

3. MetaCaster 的运行逻辑：Meta-Harness-Optimized 到底优化了什么

从设计意图来看，MetaCaster 的整体流程可以分成四个阶段。

3.1 第一阶段：元训练

系统在大量历史任务上训练。每个任务来自不同的时间序列或不同的时间段。元训练阶段的目标是学到一个良好的初始参数和一套 Agent 策略。这个阶段的计算量最大，但可以在离线完成。

3.2 第二阶段：Harness 搜索与优化

传统 AutoML 会把超参搜索当作独立环节，搜索目标直接就是验证集误差。MetaCaster 的做法更“元”一层：它把 Agent 的决策动作、执行框架的调度规则，也作为可微分的元学习目标。换句话说，它不只找一组超参，而是在学“如何找超参”的策略。

3.3 第三阶段：Few-Shot 适配

当一个新的、数据很少的时间序列出现时，系统不再从头训练。它用元训练得到的初始参数作为起点，用新任务的支持集做少量梯度更新，再借助 Agent 选择合适动作，快速完成适配。

3.4 第四阶段：端到端预测

适配完成后，模型进入标准预测模式。因为基础模型是轻量预测器，整个过程可以在较低成本下完成推理。

这四段流程，放在没有元学习的传统场景里，会是什么样子？

传统方案通常需要人工完成数据清洗、特征工程、模型选择、超参搜索、离线验证、上线回测。每一步都可能出错，而且步骤之间无法统一优化。MetaCaster 的思路是尽量把流程收敛到一个可以被优化的计算图里。虽然实际工程里不可能做到完全端到端，但相比传统流程，它至少把“建模策略”纳入到了优化目标中。

这里值得说一个判断：MetaCaster 这类方案的真正价值，不是发明了一个新的预测模型，而是把模型选择、训练策略、适配策略这些“流程决策”变成了可学习的对象。对于时间序列这种非平稳、任务边界模糊的数据，这种“元层面”的优化是比单纯换模型更重要的变化。

4. 环境准备与前置条件

下面进入可操作部分。我们用 PyTorch 搭一个最小实现骨架。版本方面，本文给出的是通用实现思路，具体版本以你的环境为准。推荐使用 Python 3.9 或更高版本，PyTorch 2.x。

需要安装的依赖：

pip install torch numpy pandas scikit-learn

代码文件结构可以这样组织：

metacaster_demo/ ├── tasks.py # 任务采样器 ├── model.py # 轻量预测器 ├── meta_train.py # 元训练循环 ├── agent.py # Agent 与 Harness 简化实现 ├── evaluate.py # 评估脚本 └── data/ └── synthetic.csv # 合成时序数据

如果没有真实数据，可以用合成数据先跑通流程。重点是理解框架，而不是一开始就追求业务精度。

5. 核心流程拆解与最小实现

我们按四个模块来写代码，每个模块对应前面说的一个阶段。

5.1 任务采样器

任务采样器负责从序列中构建“任务”。对每个任务，我们从一条序列中切出支持窗口和查询窗口。

# tasks.py import numpy as np import torch def make_windows(values, lookback=48, horizon=12): xs, ys = [], [] for i in range(len(values) - lookback - horizon + 1): xs.append(values[i:i + lookback]) ys.append(values[i + lookback:i + lookback + horizon]) return np.stack(xs), np.stack(ys) class TSTaskSampler: def __init__(self, series_list, lookback=48, horizon=12, support_ratio=0.5, device="cpu"): self.series_list = [ torch.as_tensor(s, dtype=torch.float32).view(1, -1) for s in series_list ] self.lookback = lookback self.horizon = horizon self.support_ratio = support_ratio self.device = device def sample_task(self): """ 从一个随机序列中切分出支持集和查询集。 返回值为字典。 """ series = self.series_list[np.random.randint(len(self.series_list))] values = series.flatten().numpy() if len(values) < self.lookback + self.horizon + 1: raise ValueError("序列长度不足以构造任务窗口") x, y = make_windows(values, self.lookback, self.horizon) split = int(len(x) * self.support_ratio) support_x, support_y = x[:split], y[:split] query_x, query_y = x[split:], y[split:] return { "support_x": torch.as_tensor(support_x, dtype=torch.float32).to(self.device), "support_y": torch.as_tensor(support_y, dtype=torch.float32).to(self.device), "query_x": torch.as_tensor(query_x, dtype=torch.float32).to(self.device), "query_y": torch.as_tensor(query_y, dtype=torch.float32).to(self.device), }

解释一下关键逻辑。make_windows负责把一维序列滑动切成若干输入输出对。sample_task每次随机选一条序列，从中取前半段窗口作为支持集，后半段窗口作为查询集。这样设计是为了模拟“训练任务”和“新任务”之间的分布差异。

实际项目中，你不需要把所有数据一次性加载进内存，可以用 DataLoader 按需读取。这里的实现只是为了演示元学习的核心结构。

5.2 轻量预测器

我们选一个小型 TCN 作为基础预测器。之所以选 TCN，是因为它结构简单、前向计算快、对序列长度比较友好，比 Transformer 更适合在元学习里反复更新。

# model.py import torch import torch.nn as nn import torch.nn.functional as F class CausalConv1d(nn.Module): """因果卷积：保证 t 时刻的输出只依赖 t 时刻及之前的信息。""" def __init__(self, in_channels, out_channels, kernel_size=3, dilation=1): super().__init__() self.padding = (kernel_size - 1) * dilation self.conv = nn.Conv1d( in_channels, out_channels, kernel_size, dilation=dilation, padding=self.padding, ) def forward(self, x): # 剪掉右侧多余填充，保持因果性 out = self.conv(x) if self.padding > 0: out = out[..., :-self.padding] return out class LightTCN(nn.Module): def __init__(self, in_channels=1, hidden_channels=16, out_channels=1, kernel_size=3, num_layers=2): super().__init__() self.encoder = nn.Conv1d(in_channels, hidden_channels, 1) self.blocks = nn.ModuleList() for i in range(num_layers): self.blocks.append(nn.Sequential( CausalConv1d(hidden_channels, hidden_channels, kernel_size, dilation=2 ** i), nn.ReLU(), nn.BatchNorm1d(hidden_channels), )) self.decoder = nn.Conv1d(hidden_channels, out_channels, 1) def forward(self, x): # x 的形状: (batch, in_channels, lookback) h = self.encoder(x) for block in self.blocks: h = h + block(h) out = self.decoder(h) # (batch, out_channels, lookback) return out[:, :, -1] # 只需要最后一个时间步的输出

这里的关键设计是因果卷积。预测未来时，我们不能让当前时刻的信息泄漏到历史状态里。普通一维卷积会看到完整上下文，破坏时序因果关系。因果卷积通过左侧补零、裁剪右侧的方式，保证每个时刻只利用过去信息。

LightTCN的参数量非常小，适合在元学习内循环里被反复微调。如果你后续要做更复杂的实验，可以替换成 Mini-LSTM 或轻量 PatchTST，但核心流程不变。

5.3 元训练循环

元训练是整个框架的核心。这里我们采用 Reptile 风格，因为它的实现比完整二阶 MAML 简单，且对时间序列任务足够稳定。

# meta_train.py import copy import torch import torch.nn as nn from model import LightTCN from tasks import TSTaskSampler def inner_update(model, support_x, support_y, inner_lr=0.01, inner_steps=3): """在单个任务上做几步梯度更新，返回适配后的模型。""" fast_model = copy.deepcopy(model) optimizer = torch.optim.SGD(fast_model.parameters(), lr=inner_lr) for _ in range(inner_steps): pred = fast_model(support_x) loss = nn.functional.mse_loss(pred, support_y) optimizer.zero_grad() loss.backward() optimizer.step() return fast_model def meta_train(model, sampler: TSTaskSampler, meta_lr=0.1, outer_steps=200, batch_tasks=4, device="cpu"): model.to(device) model.train() for step in range(outer_steps): diff_dict = {} for _ in range(batch_tasks): task = sampler.sample_task() support_x = task["support_x"] support_y = task["support_y"] query_x = task["query_x"] query_y = task["query_y"] fast_model = inner_update(model, support_x, support_y) # 计算适配后模型与初始模型的参数差 for name, p in model.named_parameters(): delta = fast_model.state_dict()[name] - p.data if name not in diff_dict: diff_dict[name] = torch.zeros_like(p.data) diff_dict[name] += delta # 将平均参数差累加到初始模型上 with torch.no_grad(): for name, p in model.named_parameters(): p.data += meta_lr / batch_tasks * diff_dict[name] if (step + 1) % 20 == 0: # 打印当前适配后的验证损失 task = sampler.sample_task() fast_model = inner_update(model, task["support_x"], task["support_y"]) loss = nn.functional.mse_loss( fast_model(task["query_x"]), task["query_y"]) print(f"step {step + 1}/{outer_steps}, meta loss: {loss.item():.6f}") return model

Reptile 的逻辑很直观：我们在每个任务上从同一个初始模型出发，经过几步内循环更新，得到一个适配后的模型。然后计算适配后模型和初始模型之间的差，把所有任务的差值平均，再往初始模型方向移动一小步。

这样做的效果是：模型会在所有任务之间找到一个“平均意义上容易适配”的初始位置。新任务出现时，从这一位置出发做几步梯度更新，就能快速收敛。

如果想改成 MAML 风格，需要记录内循环中的梯度路径，并计算二阶梯度。工程实现相对复杂，而且很容易出现梯度爆炸。对于时间序列预测，Reptile 和 FOMAML 通常是更稳妥的起点。

6. Agent 与 Harness 的简化实现思路

现在来看标题里最有辨识度的部分：Agent 和 Meta-Harness。

在完整方案中，Agent 的状态空间可以包括：

• 当前支持集样本数量；
• 数据方差、趋势强度、季节性强度；
• 模型当前验证误差；
• 已经尝试过的超参组合。

Agent 的动作空间可以包括：

• 历史窗口长度；
• 预测模型类型；
• 内循环学习率；
• 内循环步数。

因为完整的强化学习训练比较复杂，这里给出一个简化的随机搜索 Agent 示范。它的核心价值是展示 Harness 的“循环结构”：观察状态、选择动作、执行建模、计算奖励、更新策略。

# agent.py import copy import random import torch import torch.nn as nn from model import LightTCN class RandomSearchAgent: """简化版 Agent：用随机搜索来演示 Harness 的动作循环。""" def __init__(self, model_factory, device="cpu"): self.model_factory = model_factory self.device = device self.best_score = float("inf") self.best_config = None def choose_action(self, observation): # 根据观察状态，选择一个动作 # 这里简化为随机选择历史窗口和内循环步数 lookback = random.choice([24, 48, 72]) inner_steps = random.choice([1, 3, 5]) inner_lr = random.choice([0.005, 0.01, 0.02]) return { "lookback": lookback, "inner_steps": inner_steps, "inner_lr": inner_lr, } def run_harness(self, support_x, support_y, query_x, query_y, iterations=20): """ Harness 循环：观察 -> 动作 -> 适配 -> 评估 -> 更新策略 """ for i in range(iterations): observation = { "support_size": support_x.shape[0], "support_mean": support_x.mean().item(), "support_std": support_x.std().item(), } config = self.choose_action(observation) model = self.model_factory().to(self.device) optimizer = torch.optim.SGD( model.parameters(), lr=config["inner_lr"]) for _ in range(config["inner_steps"]): pred = model(support_x) loss = nn.functional.mse_loss(pred, support_y) optimizer.zero_grad() loss.backward() optimizer.step() q_pred = model(query_x) score = nn.functional.mse_loss(q_pred, query_y).item() print(f"[iter {i + 1}] config={config}, score={score:.6f}") if score < self.best_score: self.best_score = score self.best_config = config self.best_model = copy.deepcopy(model) return self.best_model, self.best_config, self.best_score

需要注意，这里的 Agent 只是一个简化示意，并不是完整论文方案。真实场景里，Agent 的动作选择策略本身也是被元学习优化的一部分，而不是随机搜索。

Harness 在这里的作用是统一“动作执行”和“结果收集”。所有动作都通过同一个 Harness 循环执行，这样才能保证 Agent 观察到的状态是可比的，也才能为后续的元学习优化提供一致的训练信号。这也是 Meta-Harness 与普通 for 循环代码的本质区别：Harness 有状态、有反馈、有策略更新入口，而不是简单的顺序执行。

7. 运行结果与效果验证

跑通上面的代码后，典型的输出大致如下：

step 20/200, meta loss: 0.043211 step 40/200, meta loss: 0.031878 step 60/200, meta loss: 0.028540 ... step 200/200, meta loss: 0.021934

从输出里可以判断：

• 元训练损失是否下降。如果损失波动大或根本不下降，说明任务采样有问题。
• 在验证阶段，应该从训练好的元模型出发，在“新任务”的支持集上做少量更新，然后在查询集上评估。这个评估流程不能和元训练任务重叠，否则会高估效果。

评估脚本可以这样写：

# evaluate.py import torch import torch.nn as nn from model import LightTCN from meta_train import inner_update def smape(pred, target, eps=1e-6): """对称平均绝对百分比误差。""" diff = torch.abs(pred - target) denom = (torch.abs(pred) + torch.abs(target)) / 2.0 + eps return (diff / denom).mean().item() def evaluate(meta_model, support_x, support_y, query_x, query_y, inner_lr=0.01, inner_steps=5): fast_model = inner_update( meta_model, support_x, support_y, inner_lr=inner_lr, inner_steps=inner_steps, ) pred = fast_model(query_x) mse = nn.functional.mse_loss(pred, query_y).item() s = smape(pred, query_y) return mse, s

在真正的效果验证里，要从以下三个维度看：

1. 与“从零训练”对比。同样只在支持集上训练，元初始化模型和随机初始化模型的误差差距是否明显。
2. 与“长序列训练再迁移”对比。用长历史序列预训练后直接在新序列上微调，和元学习方式的效果差异。
3. 与“大模型 Few-Shot 微调”对比。用一个轻量 TCN 做 Few-Shot，和一个大 Transformer 做 Few-Shot，对比精度和推理耗时。

如果只跑通了代码但发现效果不理想，也不用急着怀疑方法。小样本时间序列预测的评估方差很大，一次任务的结果不能说明问题，至少要跑几十个任务取平均。

8. 常见问题与排查方法

MetaCaster 这类元学习框架，在实现和训练时有不少隐蔽的坑。下面是我认为最值得关注的几个。

问题现象	可能原因	排查方式	解决方案
元训练损失不下降	任务采样分布不合理，任务之间差异过大	打印多个任务的输入输出分布	对序列做归一化，或按业务类型分组采样
训练损失下降，但验证效果差	元训练任务与目标任务分布不一致	检查新任务的统计特征	增大任务采样的覆盖范围，加入更多相似任务
内循环更新不稳定	学习率太大	查看内循环 Loss 曲线	降低 inner lr，或改用 Adam 做内循环优化
模型在新任务上过拟合	支持集窗口过少	检查支持集窗口数量	增加窗口滑动的重叠度
Agent 搜索效率低	动作空间太大或奖励信号太稀疏	查看每次迭代分数变化	缩小动作空间，引入启发式规则作为先验
数据泄漏	支持集和查询集来自同一时间段	检查时间戳划分	确保支持集和查询集按时间先后切分，不做随机抽样

这里重点强调数据泄漏问题。在普通机器学习里，随机划分训练集和测试集通常没问题。但在时间序列场景里，未来的数据不能参与训练，否则模型会“偷看”到未来信息。Few-Shot 任务里同样存在这个问题，支持集和查询集必须在时间上严格分开，或者来自不同的时间段。

另一个容易被忽略的坑是 BatchNorm 在 Few-Shot 版本中的表现。因为支持集窗口数量很少，BatchNorm 的统计量会很不稳定。如果发现小样本适配效果差，可以试试去掉 BatchNorm，或者用 LayerNorm 替代。

9. 工程化落地与最佳实践

从论文研究到生产落地，中间还有一段距离。这里给出几个实际项目里用得上的建议。

9.1 基础模型一定要轻

元学习需要反复执行内循环更新，如果基础模型太大，训练成本会翻很多倍。建议从参数最小的模型开始试，比如线性模型、三层 MLP 或小型 TCN。等框架效果稳定后，再考虑增加模型容量。

9.2 任务采样要充分

Few-Shot 学习的效果高度依赖任务分布的质量。如果所有任务都来自同一条趋势序列，元模型学到的只是“在一个形态下快速适配”，换一个业务场景就会失效。建议按照业务类型、时间窗口、数据频率等多个维度构造任务池。

9.3 内循环参数要保守

内循环学习率、步数是少数几个对效果影响极大的超参。一般建议从较小的学习率开始，比如 0.005 到 0.01，内循环步数从 1 到 3 步开始。大幅增加步数不一定会提升精度，反而会增加过拟合风险。

9.4 上线前必须回测

在时间序列项目里，离线指标和在线指标经常不一致。上线前至少要做滚动回测，模拟“训练期-验证期-上线期”的时间结构。如果回测阶段就出现效果衰减，不要盲目上线。

9.5 关于数据安全与权限

在实际业务中，涉及用户数据的时间序列预测，一定要遵守数据最小化原则。先确认数据来源合法、用途明确，再开始建模。模型训练和数据访问权限也要分离，避免非授权人员接触敏感数据。在共享数据集或生产环境变量时，记得脱敏处理。

9.6 Agent 自动化不是完全没人

Agent 负责的是流程自动化，但最终上线依然需要人工把关。建议给 Agent 设定明确的动作边界，比如不允许自动调整回滚阈值、不允许访问未授权的数据源。这一点在 Agent 类系统里尤其重要，自动化程度越高，越需要设计安全护栏。

10. 总结与下一步学习方向

MetaCaster 的设计思路，值得关注的其实不是某一个模型的精度，而是它把“预测流程”整体纳入优化目标的方式。它会主动学习如何为新的小样本任务选择模型、选择超参、选择适配策略，最终得到轻量且可部署的预测器。如果你正在做冷启动预测、多任务时序建模或 AutoML 类系统，这个方向会很有参考价值。

下一步可以按这个路径深入：

1. 先把第 5 节的代码跑通，理解任务采样和元训练循环。
2. 再用你自己的业务数据构造任务池，对比元初始化和随机初始化的效果差异。
3. 接着尝试把 Agent 从随机搜索替换成更聪明的策略，比如基于强化学习的策略，或者基于规则的启发式策略。
4. 最后考虑把 Harness 做成通用组件，让它能适配不同模型、不同任务类型。

代码骨架已经给出，剩下的实验空间很大。希望你读完这篇文章后，能少踩几个坑，把小样本时间序列预测这件事真正落地到项目里。