Operator as Plugin：借鉴 DeepSeek Harness 设计数据平台插件体系

Published on Sep 6, 2026 Updated on Oct 11, 2026 数据平台数据平台, 插件架构, Operator, DeepSeek Harness, 数据飞轮, 向量检索 9 minutes

Contents

世界模型数据平台往往沿着“接入 → 清洗 → 加工与镜头切分 → 打标 → 向量化与索引 → 检索挖掘 → 标注”逐步扩展。如果每增加一种算法都要修改主服务、增加专用接口、重新部署整个系统，平台很快会成为难以维护的算法集合。

Operator as Plugin 是可行方向：算法作者贡献能力，平台负责让能力可调用、可组合、可追踪地运行。 但插件注册只解决了扩展入口，长任务恢复、数据语义、GPU 执行和结果发布还需要独立设计。

本文延续 Data Flywheel 的技术设计讨论，并参考 DeepSeek 官方 Harness 文档。资料核对日期为 2026-09-06；以下数据平台协议、示例清单与架构均为本文提出的方案，不是 DeepSeek Harness 已有的数据处理 API，也不是 Data Flywheel 已经实现的插件系统。

1. DeepSeek Harness 值得借鉴什么

DeepSeek Harness 是基于 Cordis 的 Agent Harness，官方用 Everything is a Plugin 描述其架构，README 同时说明项目处于开发者预览阶段。它不是本文讨论的批量数据调度平台。参见 DeepSeek 官方仓库。

根据官方架构文档，插件向共享上下文提供服务、类型化事件和可撤销的注册效果；模型适配、工具注册、会话记录与 Agent 循环都能通过插件组合。卸载插件时，相关注册随生命周期清理；服务定义、提供者和消费者通过能力接口协作。

对数据平台最有价值的借鉴是：

Harness 思想	数据平台中的对应设计
通过扩展点增加能力	新算子注册后可被调度，无需增加一套专用业务接口
接口与提供者分开	同一个 Embedding 接口可接不同模型实现
通过配置组合插件	Pipeline 显式引用算子版本、参数和依赖
注册有生命周期	禁用版本后停止接收新任务，已有任务有明确收尾规则

这里有一条重要边界：撤销注册不能撤销已经写出的文件、发送的外部请求或完成的人工标注。 数据平台必须管理持久化副作用，不能把进程内生命周期清理当作业务事务回滚。

也不需要为了借鉴这个理念，将现有 FastAPI 后端改写为 Cordis。扩展接口的思想可以独立于实现语言与框架存在。

2. 哪些环节适合成为插件

环节	插件能力	输入与输出示例	平台统一的语义
数据接入	数据源连接器、格式解析器	外部数据源 → 原始资产清单	来源、检查点、去重、资产身份
清洗质检	模糊、黑屏、损坏、重复检测	资产 → 质量分数与原因	质量规则、保留记录、版本
加工切分	转码、抽帧、镜头切分	视频 → 帧、片段、派生文件	时间基准、区间和父子关系
打标描述	分类、检测、字幕、视频描述	片段 → 标签、目标、描述	粒度、标签字典、来源和置信度
向量化	图像、文本、视频编码器	资产或片段 → 向量记录	模型修订、预处理、向量空间
索引	向量库与全文检索适配器	向量与元数据 → 可查询索引	索引版本、完整性、可用状态
检索挖掘	召回、重排、聚类、难例采样	查询与快照 → 候选结果集	权限、排序语义、快照和可追溯性
标注	工具连接器、预标注、审核面板	样本任务 → 经审核标注	分配、审核、驳回、回流版本

“打标”和“标注”可以共享标签体系，但此处区分自动预测与人工确认。自动打标输出模型来源、版本和置信度；人工结果额外保存标注规范、操作者、审核结论与修订历史。未经审核的预测不能静默覆盖人工真值。

清洗插件通常应输出分数和排除建议，数据选择策略再决定是否进入训练集。让一个模糊检测算子直接删除原始视频，会使结果难以复核，也破坏算法替换能力。

3. 插件包、算子、任务与工作流分开建模

概念	生命周期	例子
Plugin Package	分发与安装	包含两个质量算子的镜像与声明文件
Operator	能力定义	`quality.blur-score` 的输入输出及配置
Run	某次执行	固定样本快照、参数、算子版本和输出
Pipeline	编排定义及其版本	清洗后切分，再并行打标与向量化
Connector	对外部服务的适配能力	对象存储、标注系统、索引服务
UI Extension	页面扩展	参数编辑器、结果查看器、时间轴面板

一个插件包可以提供多个算子，也可以只提供连接器。一个算子可能使用长驻 GPU worker，不必对应一个临时进程。Pipeline 应显式表达依赖，避免插件之间任意调用形成隐藏工作流。

人工标注更不能强行套成同步 run(input) -> output：它可能持续数天，需要等待、重新分配、审核和外部回调。统一的是任务身份与事件协议，具体生命周期应按能力类型区分。

4. 最关键的契约是数据含义

两个插件都返回 JSON，不代表可以互换。

4.1 视频片段必须固定时间语义

建议片段契约至少记录：源资产及其修订、时间基准、起止边界、区间约定、切分版本与派生关系。可变帧率视频不能简单地用帧号除以一个固定 FPS 推算全部时间点。

例如，统一规定源视频时间轴上的毫秒和半开区间 [start_ms, end_ms)；如果转码改变时间轴，就必须记录映射。新切分版本可能产生新的片段身份，旧标签不能仅因时间接近就自动迁移。

4.2 标签必须有粒度与字典版本

“雨天”是视频级、镜头级还是帧级判断？“车辆”属于哪个目标？confidence=0.9 是哪种模型的分数，是否经过校准？这些需要进入 Schema，而不是依赖插件作者的默认理解。

跨模型比较时，不直接把相同数值当成相同可信度。标签字典改名、合并类别和调整定义都应保留版本映射。

4.3 向量维度相同不等于空间相同

向量空间标识建议覆盖模型权重修订、输入预处理、池化、归一化和维度。查询编码器必须与索引向量空间匹配，距离度量也要符合该模型的使用方式。

索引还要记录来源快照、构建配置、数据水位和状态，例如 building → validating → ready → retired。只有校验完成的版本进入查询路由；升级和撤回时成对处理编码器与索引。

5. 一份可以讨论的插件声明

以下 YAML 仅为协议草案，镜像摘要和模型标识是占位值；不是直接可执行配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
api_version: data-platform/v1alpha1
plugin:
  name: scene-tools
  version: 0.3.0
  image: "registry.example.com/scene-tools@sha256:<digest>"
  sdk_compatibility: ">=0.1,<0.2"
operators:
  - name: video.embed
    kind: batch
    input_schema: clip-ref/v1
    output_schema: embedding-record/v1
    config_schema: schemas/video-embed.json
    granularity: clip
    resources:
      cpu: 4
      memory_gib: 16
      gpu: 1
    capabilities:
      - asset.read
      - artifact.stage
    execution:
      supports_checkpoint: true
      retryable_errors: [temporary_storage_error, worker_lost]
    model_revision: "<immutable-model-revision>"
    vector_space_id: video-encoder-r17-preprocess-v2

声明不是安全证明。平台仍要检查能力是否被允许、镜像是否被批准、输入对象是否获授权、资源是否有配额、Schema 是否兼容。

输入输出尽量传资产引用和结果清单，不在控制 API 中传整段视频或海量向量。插件通过平台提供的受限客户端读取获授权数据、写任务暂存区，并返回结构化指标与错误。

版本兼容也不只看包版本：SDK、输入 Schema、输出 Schema、模型与外部服务协议都可能变化。兼容性测试应使用固定样本验证语义，不能只检查字段名是否存在。

6. 控制服务、执行服务与结果提交

FastAPI 管注册、权限、提交与查询；计算 worker 管视频处理、批量推理和 Embedding。不同 CUDA、PyTorch、FFmpeg 依赖应在适当的执行环境隔离，不全部装入 API 进程。

生产运行固定插件版本，新版本供新任务选择。卸载应先停止接收新任务，再等待已有任务完成、在检查点暂停或按约定取消；不能假定 UI 上关闭插件就能安全终止整个分布式运行。

调度底座应复用现有能力，再适配插件协议。批量依赖、事件驱动、GPU 分布式执行与长期人工等待的需求不同，可以通过执行适配层组合；不要让“支持插件”变成重写一套通用调度系统的理由。

关于算子如何映射到 CPU/GPU Job、如何关联 Run 与集群状态，以及数据算子与 Kubernetes Operator 的区别，见 Kubernetes 架构与执行方案。

7. 失败恢复：至少一次执行，幂等提交结果

实际网络和 worker 都会故障。更务实的目标是允许任务重试，并让同一逻辑输出只被发布一次，而不是未经证明地宣称端到端 exactly-once。

可以采用如下提交协议：

平台冻结 run 的输入快照、插件摘要、模型、参数和逻辑分片。
每次 attempt 写独立暂存路径，避免相互覆盖。
worker 返回 manifest，列出产物、校验和、数量、Schema 与指标。
平台验证后，在元数据事务中使用唯一键或条件更新确认获胜提交。
查询只读取已提交结果；失败 attempt 的暂存文件后续回收。

幂等键应包含租户、逻辑运行、算子步骤和分片；跨运行缓存键还要覆盖输入、配置、模型和环境依赖，并尊重权限边界。非确定性算子需要记录随机种子或明确结果不可复用，不能仅凭函数名命中旧结果。

对象存储与数据库通常不能直接合成一个事务。若 worker 写完文件后失联，重试可以重新校验或提交；若元数据已提交而应答丢失，客户端应查询既有提交。清理器只删除明确未引用且超过保留窗口的暂存物。

这种“任务输出应完整、重试应保持一致”的思路也可参考 Airflow 任务最佳实践。具体提交协议仍需由数据平台实现。

外部标注订单、消息发送和第三方 API 需要单独的幂等标识、回调去重与对账。取消本地任务不代表外部系统已取消，UI 应呈现真实的最终状态。

8. 吞吐、权限和 UI 扩展各有边界

性能方面，逻辑算子可组合，不意味着每个片段都启动一个容器。使用长驻 worker、批推理、合适分片与解码复用，避免中间产物重复搬运。算子融合可以优化运行，但血缘仍应保留逻辑步骤与版本。

权限方面，插件只获得本次任务所需的资产读取、暂存写入和受限网络能力。注册时审批、调用时授权、执行时隔离、发布时校验都需要覆盖；容器只是隔离机制的一部分，不能自动证明任意代码可信。

检索插件返回的数据也要受权限约束。Milvus 等引擎提供元数据过滤检索能力，但可信过滤表达式的构建、租户范围与撤权一致性仍是平台责任。参见 Milvus Filtered Search。

UI 方面，先开放操作入口、参数表单和结果面板三类插槽。简单参数用 Schema 生成表单，视频时间轴和标注画布使用领域组件。受信任内置扩展可以共享组件；不受信任的 UI 代码需要隔离和有限通信，不能任意注入主页面获得全部会话能力。

9. 如何证明这套方案值得继续做

第一阶段只选少量能力：数据源连接器、镜头切分、质量评分、Embedding，其中至少一种提供两个可替换实现。

验证项	需要观察的结果
扩展成本	新作者按文档注册运行，无需修改主服务源码
可替换性	两个实现遵守同一语义契约，结果可对比
版本共存	旧 run 可追溯，新 run 可选择新版本
故障恢复	杀死 worker、重复投递后不出现重复发布或半成品
数据一致性	索引与模型配对，切分与标签保留来源关系
运行开销	测量解码、搬运、模型加载和调度成本的占比
权限隔离	越权输入、超额资源与未授权网络请求被阻止

如果目前只有几个固定脚本、单一负责人、很少替换算法，可以先做模块化接口和统一运行记录，延后动态加载与插件市场。真正推动插件化的应是独立贡献、依赖冲突、能力复用和版本共存需求。

Data Flywheel 已有前后端、权限与需求管理基础，适合从注册表、强契约和统一 run 记录起步。完整路线应与技术框架选型、发布环境和 UI 规范一起约束：插件作者专注算法，平台承担可靠执行和结果治理。