流水线与算子插件设计评审：借鉴 Harness、ComfyUI 与数据闭环平台
有较大的改进空间，最值得投入的是流水线开发体验、统一算子契约，以及计算结果到数据集发布的连接。 当前的 React Flow、FastAPI、Dagster 和 Python SDK 可以继续使用；现有版本冻结、可靠派发、插件隔离与分批检查点应成为下一轮改进的基础。
本文延续需求文档草案。核验日期为 2026 年 10 月 7 日，代码依据为本地 data-flywheel 工作区，包括未提交改动。三个并行研究方向分别覆盖 DeepSeek Harness、ComfyUI，以及数据闭环与执行平台。第 1 至 6 节保留实施前的审阅基线与设计建议；用户确认后完成的第一阶段改动见实施记录，其余阶段仍待推进，本文不代表生产性能验收。
外部资料只采用官方文档和官方源码；文中明确区分公开机制、当前实现和本平台建议。Harness 是 Agent 应用框架，ComfyUI 是节点创作工具，Dagster 是编排底座，它们提供不同层面的参考，不能作为同类数据闭环产品直接排名。
1 先确认当前代码已经做到哪里
10 月 1 日的需求草案是历史基线。当前工作区已经出现新的执行与治理能力，实施前应按最新代码逐项验收，避免重复建设。
| 模块 | 当前可见实现 | 本轮真正需要补的部分 |
|---|---|---|
| 编排前端 | React Flow 画布、命名输入、配置表单、JSON 编辑、撤销重做、草稿保护、运行与版本页面 | 画布内调试、运行状态回标、类型化产物预览、版本语义差异与组件复用 |
| 运行控制面 | 不可变流程版本、执行快照、幂等提交、派发与对账、取消围栏、租约和安全重试 | 面向用户的执行计划解释、目标节点执行、可恢复事件订阅 |
| 内置算子 | batch-v1、有界读写、持久分区检查点、取消及租约校验 | 明确的多输入数据对齐语义；分区恢复的前端可见性 |
| 上传插件 | wheel 候选、异步验证、结构化报告、发布、项目启用、固定摘要与隔离容器 | 与内部 SDK 统一的版本化协议、能力绑定、逐环境就绪与退役管理 |
| 执行资源 | 环境、资源池、Worker 注册、健康探测、容量绑定及固定执行快照 | 节点级资源需求、实际吞吐遥测；远端 Agent 执行传输仍未实现 |
| 数据业务 | Collection、数据集版本、标注、评测、反馈等对象及数据集发布质量门禁 | 将通用流水线产物、检查结果和这些业务对象稳定关联 |
两处具体差异尤其值得关注：
- 内部
pipeline_sdk.py已有BatchContext和batch_handler；公开flywheel_sdk仍是 dataset handler。执行器也明确拒绝上传 wheel 使用batch-v1。上传插件仍受整批 JSON 的 5,000 条记录、8 MiB 等限制，不能用内部能力代替外部插件验收。 streaming_runtime.py明确采用批次序号对齐：多个输入用zip_longest配对，耗尽的端口得到空批次。这是已有 map 协议，不提供按样本 ID 的 join。两条分支经过不同过滤后，同序号批次可能包含不同样本。
当前 Dagster job 使用 in_process_executor，注释说明这是本地内存约束下的选择。资源池和 Worker 登记已经存在，但不能据此推断任意远端执行、GPU 并行或节点弹性调度已经完成。代码依据 C1–C8
2 外部设计有哪些可借鉴之处
| 参考对象 | 官方公开机制 | 对本平台的启发 | 迁移边界 |
|---|---|---|---|
| DeepSeek Harness | 插件通过服务接口与依赖注入组合；注册效果随卸载撤销；区分持久事件与实时信号 | 将算子需要的存储、连接、模型与遥测声明为能力；让生命周期和状态恢复有明确契约 | Host 插件的进程内信任模式不适合直接用于租户上传代码 |
| ComfyUI | 编辑图转换为执行输入；支持目标输出执行、输入指纹缓存和子图；V3 集中声明节点 Schema | 画布内迭代、依赖闭包、版本化组件、统一节点描述 | V3 文档仍声明 API 可能变化；本平台需要自己的稳定协议 |
| Encord | 筛选结果保存为 Collection，再创建 Dataset/Project 进入标注；Agent stage 通过命名 pathway 路由 | 固定候选集合，显式连接自动处理、人工标注与审核 | 公开文档不证明标注结果自动回写原 Collection，也不揭示商业调度内部实现 |
| FiftyOne | Operator 可解析动态输入；执行上下文可序列化并交给后台执行；Enterprise 提供分布式委托执行界面 | 根据当前数据视图和目标环境做参数预检，显示任务与分片状态 | Enterprise 能力不能当成开源版已经具备的执行接口 |
| Dagster | 资产检查、分区、回填及外部资产观察 | 让数据质量、输入变化与分区状态成为可解释对象 | 当前应用使用 op/job；采用资产理念不要求立刻全面迁移到 Assets |
| NVIDIA Curator | Stage 声明输入输出及资源；模型初始化与批处理分开；支持流式执行与阶段吞吐管理 | 描述节点资源、观测初始化和处理成本，再决定并发与模型复用 | Cosmos 云服务与开源 NeMo/Cosmos-Xenna 不视为同一部署；不据此引入第二套调度器 |
上述机制分别见官方 Harness 架构、Harness 服务依赖、ComfyUI 执行器、V3 节点接口、FiftyOne 插件开发、Enterprise 委托执行、Dagster 资产检查和 NeMo Curator Stage 抽象。以下方案是结合这些机制与本地代码提出的设计，不能理解成任何一家平台的完整内部架构。
3 六项主要改进建议
P0 表示建议优先启动的切片，P1 表示依赖前置能力的后续工作。规模 S/M/L 仅用于相对比较：S 为局部交互或接口扩展，M 为跨前后端功能，L 涉及协议、数据模型和执行路径。它们不是排期估算。
| 编号 | 改进方向 | 前端交付 | 后端交付 | 顺序与规模 |
|---|---|---|---|---|
| R1 | 可解释的小样本调试 | 运行到此、输入输出对比、缓存原因、节点状态 | 目标依赖闭包、固定样本、调试计划与副作用策略 | P0，M–L |
| R2 | 编排定义与执行计划分层 | 语义 diff、历史恢复、组件进入与返回 | 规范化图、计划摘要、节点映射、组件物化 | 基础分层 P0/M；组件 P1/L |
| R3 | 统一算子协议与能力绑定 | 上下文表单、端口约束、能力与环境预检 | 公共 SDK、版本化 Schema、分批及 ArtifactRef 协议 | 最小协议 P0/L；多输出与 join 分期 |
| R4 | 完整的插件交付与生命周期 | 验证阶段、环境就绪、升级影响、排空进度 | 制品来源、兼容检查、启用修订、停用退役 | 预检 P0/M；生命周期 P1/M–L |
| R5 | 统一运行视图与可恢复事件 | 运行画布、分区进度、日志、重连状态 | 持久事实、受保护事件流、游标与快照 | P0/M，分区重跑 P1 |
| R6 | 接上数据质量与反馈闭环 | 检查结果、问题样本、发布与反馈入口 | 产物关联数据版本、门禁、标注及评测关联 | 单条质量发布链 P0/M；完整闭环 P1/L |
R1 让用户在画布中完成一次有效迭代
当前预览以产物 JSON 和少量记录为主，运行信息与编排画布分开。建议建立统一检查面板：编辑时展示契约、有效配置和预检结果；运行时展示输入、输出、错误、指标和缓存依据。图片、视频片段、文本、向量统计使用平台提供的预览组件，原始 JSON 作为补充。
第一步提供「运行到此节点」与「小样本运行」。后端接收目标节点、样本策略和调试模式，计算完整上游依赖闭包，并固定输入版本、样本 ID 或选择规则及随机种子。对未保存修改，可以创建不可变的调试修订；调试产物保留来源与过期策略，不自动成为正式数据集。
样本上限需要逐 source 推导：已有数据集可按稳定 ID 抽样；某些外部 source 必须完整扫描才能取得样本，预检应明确显示实际工作量，不能用“小样本”承诺很小的读取成本。闭包中的外部写入节点默认拒绝调试，只有声明并验证过 dry-run 协议后才可预览。
副作用控制必须由执行环境兑现，不能只相信插件自报的 side_effects。首期隔离调试仅接收平台准备的输入，输出由平台写入临时产物区；不授予生产写入、外部连接、Secret 和网络能力。dry-run 声明不能绕过这些限制；需要访问外部系统的调试另行绑定专用测试目标。可信本地 handler 若无法受此约束，首期拒绝进入隔离调试计划。
ComfyUI 的目标输出执行和缓存指纹提供了方向，但平台还需固定数据权限、实现身份与副作用边界。当前缓存已经包含输入哈希、配置和实现摘要；下一步应补充 命中/失效原因，并将全局 processing_signature 逐步细化为算子实际依赖的模型、预处理及运行环境指纹，减少无关模型变化造成的重算。相关机制见 ComfyUI 执行源码与 V3 缓存控制。
验收： 选择一个中间节点后只执行其必要上游；同一固定样本可复查；已有副作用节点不会被意外执行；修改模型、配置或输入时能说明缓存变化；预览与下载继续执行项目鉴权。
R2 分开保存用户编排和实际执行含义
当前版本已固定图与算子快照，因此不需要另造一套版本体系。建议在其上逐步分离三种内容：
- 编辑文档： 坐标、分组、备注、折叠状态、组件界面。
- 逻辑图： 算子版本、有效配置、端口和依赖；保存时由服务端校验并生成语义摘要。
- 运行计划： 启动时绑定输入、目标闭包、执行协议、运行镜像、环境及资源策略，冻结到现有执行快照；Worker 租约等动态事实另行记录。
这样仅移动节点不会改变计算语义摘要；版本页可以把“布局变化”和“参数、依赖、算子升级”分别显示。恢复历史应创建新草稿，保留原版本。通用编排接口也可逐步经稳定服务层访问执行器，减少前端和 API 对 media_* 命名与媒体入口的直接依赖。
之后再引入 PipelineComponentVersion：固定输入输出、暴露参数及内部图，引用时固定版本，编译时展开并保存外层节点到内部 step 的映射。前端用折叠卡片、面包屑和错误回标支持复用。首期禁止递归引用及运行时任意扩图，展开后仍应用节点数量和资源限制。ComfyUI 的子图接口可供参考，其中部分 widget promotion 行为仍在演进，不能直接成为本平台兼容承诺。
验收： 移动位置不改变语义摘要；组件新版本不影响旧运行；错误能定位到组件内节点；调试计划与生产计划均可追溯到同一版本来源。
R3 统一公开 SDK、节点 Schema 与数据执行协议
这是两个模块之间最重要的结构性改进。建议由单一版本化契约生成公共 SDK、manifest 校验和前端类型，减少内部 SDK、上传声明和隔离 runner 各自演进产生的差异。
协议拆成三部分，避免把所有概念塞进配置 JSON：
| 契约部分 | 建议包含的信息 | 主要消费者 |
|---|---|---|
| 算子定义 | 身份、配置 Schema、输入输出、执行语义、重试与缓存规则、弃用状态 | 编排器、前端、静态验证 |
| 实现发布 | wheel/镜像/SDK 摘要、依赖与模型版本、兼容范围、构建来源 | 发布验证、运行计划 |
| 环境能力绑定 | 连接、受限数据读写、Secret 引用、资源与网络策略 | 预检、调度、隔离执行器 |
Harness 的服务提供者/消费者机制适合启发能力声明，例如 artifact.read、artifact.write、connection.object-storage、telemetry.emit。声明能力不等于获得权限：平台应同时检查项目授权、目标环境、执行器支持和配额，再向容器提供受限句柄或短期凭据；不能把进程内 Context 或宿主密钥直接交给插件。Harness 服务契约
首期保留 dataset-v1 的原有整批语义，另加显式版本化的隔离 batch 协议，以 ArtifactRef、schema 引用、样本身份和分区游标描述输入；执行器控制数据授权、检查点提交和对象清理。旧插件不能被静默分批：全量排序、去重或聚合不一定能够按 map 执行。
首期数据通道建议由宿主 broker 解析 ArtifactRef，校验项目、对象摘要、租约与配额，再通过有界分帧协议向容器提供批次并接收输出；容器保持禁网，不直接获得对象存储凭据。对象写入成功后仍需由平台校验产物并提交检查点，取消或失效租约的迟到输出不得提交。签名 URL 或媒体挂载是后续独立协议，需要另外定义对象范围、出口、字节限额和清理规则。
多输入需要声明 map、按序配批或 keyed_join 等明确语义。首期可以只支持 map 与现有配批，并拒绝未实现的 join；若业务确实需要按 ID 汇合，则另定重复键、缺失键、顺序、分区及 spill 规则。不能把前端“连得上”当作数据已经正确对齐。
前端 Schema 可逐步增加条件字段、可选端口、数量约束和宿主预览组件 ID；多输出属于新的跨层协议变更，需同时覆盖 SDK、图校验、存储、Dagster 输出、缓存及 UI。动态候选值通过受保护的预检 API 返回，结果固定到运行计划；若需要调用插件解析器，同样在有界隔离环境执行。FiftyOne 的动态输入与执行上下文提供交互参考。
验收： 同一份 SDK 声明能生成上传清单和表单；内部与隔离实现通过共同契约样例；超限、缺能力或语义不支持时在运行前指出具体节点；多输入过滤后不会被默认为按 ID 对齐。
R4 让插件交付可预检、可升级、可退出
现有候选验证、摘要绑定和容器边界应继续使用。优先补 SDK 命令行工作流：从源码导出 manifest，运行本地契约样例，构建 wheel，再提交同一制品进行平台验证，减少手工同步 wheel、manifest 与测试样例的成本。
「验证通过」「已发布」「某环境可运行」「项目允许使用」需要分别展示。逐环境就绪应有实际探测依据和时间：固定镜像、SDK、wheel 是否可取，Worker 是否支持协议和架构，所需能力能否绑定。不能让单一 ready 标记代表所有环境持续可用。
再增加启用修订和引用影响分析。常规退役先禁止新引用及新派发，再让已接纳运行排空，最后撤销能力；历史元数据继续保留，重跑按当前策略决定。遇到安全事故则使用独立的立即封禁操作，并明确是否取消在途运行，避免与普通退役混淆。普通批处理容器结束即释放资源，只有长驻模型服务和连接 Provider 才需要更完整的启动、排空、清理生命周期。
建议用 preparing → ready → active → draining → inactive → retired 表达部署状态，并保留失败状态与独立封禁标记。运行接纳时固定 activation revision 和 release digest；Worker 绑定前用条件更新核对修订及封禁状态，常规排空允许已接纳修订继续执行。历史重跑仍须引用原摘要、满足授权且制品可用；inactive 可通过新启用修订重新激活，retired 为终态，不再接受历史重跑。被安全封禁的版本明确拒绝，不能替换为新实现。
算子升级必须展示端口、配置、能力及行为声明差异；迁移生成新流程版本，有效配置显示字段来源。未来开放依赖构建时再补 lockfile、SBOM、签名与构建来源。可参考 Harness 的可撤销生命周期和插件管理事务，保留本平台现有容器隔离方式。
验收： 环境失联或制品缺失可解释；升级不会修改旧引用；退役前可看到受影响流程、部署和在途运行；失败构建不会覆盖已发布制品。
R5 将运行状态、日志和分区恢复放到同一工作区
当前已有任务状态、等待原因、重试及产物信息，插件验证也有结构化报告。缺口是这些信息主要依靠页面轮询汇总，画布未直接消费运行投影，运行 API 也没有统一日志流。
建议先实现「快照 + 持久事件游标 + 实时信号」，同时明确事实来源：取消、发布及应用内产物提交与应用数据库事务绑定，通过 outbox 发出；Dagster 的启动、重试等执行事件按稳定事件 ID 接入，持久化源游标和去重水位，不能假定两个系统共享事务。PipelineRun 与任务尝试状态由平台按租约、取消围栏及对账规则合并，作为面向用户的权威投影；SSE 只传播投影的单调版本，不让原始引擎事件直接覆盖终态。
高频进度和预览有单独限流及保留期限。可用 SSE 承载订阅，按部署需要采用带鉴权的流式请求；轮询保留为降级路径。日志单独处理脱敏、大小限制和项目鉴权。
前端将传输、状态合并和 React 展示分开，统一处理旧响应覆盖新状态、重复事件、乱序、断线及游标过期。可借鉴 Harness 的后端权威状态到客户端模型分层，无需把整个应用改成事件溯源系统。
分区视图先展示已有 checkpoint 的完成、失败、复用和输入范围，再设计显式重跑计划。当前同任务检查点恢复不等于任意新运行可继承全部成功分区；跨运行复用必须重新核对输入和实现身份、授权、缓存资格与副作用。部署补跑页面也应复用这一套选择及解释。
验收： 浏览器断线重连后恢复一致状态；迟到事件不覆盖取消终态；日志不能跨项目读取；恢复预览准确说明哪些分区会复用、哪些下游需重算。
R6 把流水线结果接入现有数据业务闭环
平台已经有数据集发布质量检查。建议扩展其输入与关联关系：节点可提交检查结果引用，记录 check ID、规则版本、作用对象、严重程度、指标、失败样本和判定。由平台决定 warn/block，并让画布、数据集页面和发布操作使用同一份事实。
首先补上 PipelineArtifact 到候选数据集的物化契约。首期仅接受约定 Schema 的文本记录，映射到现有 DataSample 字段，保留源样本身份与内容摘要；以项目、产物摘要、映射版本和目标数据集作为幂等身份，创建独立候选修订，不默认覆盖已有样本。重复或冲突 ID 明确拒绝，媒体资产引用留到授权与生命周期协议就绪后支持。导入分批写入暂存区，完成后原子切换为可见候选；失败留下可恢复记录并清理未引用对象。
质量结果还应绑定被检查修订/产物摘要、规则实现摘要和签发主体。发布事务内核对候选版本未变并执行平台门禁，上传插件提供的 passed 或过期报告只能作为输入证据，不能直接授权发布。这使“运行成功→质量通过→发布版本”具备可复现的数据对应关系。
这里借鉴 Dagster Asset Checks 的可追踪检查语义。官方默认失败检查不会自动阻断下游；需要 blocking=True 且失败结果为 ERROR 才会阻断同一运行的下游。本地可先复用已有质量模型实现门禁，再按需要映射到 Dagster；分区资产检查在本次核验的官方文档中仍为 Preview，不作为首期必需依赖。Dagster 检查与阻断规则
Encord 当前公开路径是筛选形成 Collection，再创建 Dataset/Project 进入标注与导出；工作流 Agent 通过命名 pathway 进入后续阶段。可借鉴的是候选集合与明确路由。下面的版本、反馈及后续运行连接是对本平台的建议，不推断 Encord 已提供同样的自动回写闭环。Encord 数据整理与标注、工作流与 Agent 路由
闭环建议以版本化业务对象连接，而非把人工等待塞进长时间占用 Worker 的 DAG：
Collection 保存候选范围及筛选依据，发布的数据集固定样本与标注修订；后续训练和评测通过 ID、版本及 correlation ID 串联。人工完成后创建后续运行，记录父运行和输入变化。评测失败先进入反馈集合；是否触发训练或模型上线仍由独立策略决定。
验收： 技术执行成功但质量不达标时，数据集发布被阻断；用户能从指标定位问题样本及产生它的算子版本；标注修订形成新输入，旧训练和评测使用的数据仍可追溯。
4 性能优化应先测什么
模型加载、批大小与阶段并发值得优化，但目前没有工作负载测量支持“更换引擎就更快”的判断。建议先记录排队、初始化、处理、写入四段耗时，以及记录数、字节数、峰值内存和模型加载次数。
再为节点声明 CPU、RAM、GPU/显存、模型版本、批次记录与字节上限、并发限制。在受信镜像或专用池中试验模型驻留与亲和性，明确租户、模型许可和内存回收边界；第三方上传插件继续隔离。ComfyUI 的模型内存管理与 NVIDIA 的视频处理架构提供了可研究的实现思路。
第一轮仍保持本地串行默认值，选一条真实媒体流程比较冷启动、热运行、不同 batch size 的吞吐和资源峰值。只有确认独立节点或慢阶段是瓶颈后，再选择生产执行器的有限并发与资源准入。后续多机方案应延续同一控制面、租约和产物协议，避免 Dagster 与另一调度器各自维护不一致的运行事实。
5 推荐如何进入下一轮需求与 AI 开发
建议先确认一个代表场景：开发者上传一个纯 CPU、无外部副作用的过滤插件，编排者固定输入版本，用小样本调试，完成正式运行，经过质量检查后发布数据集版本。 这条链能同时检验算子交付、画布体验和数据价值，范围也可控。
| 阶段 | 可评审交付 | 进入下一阶段的条件 |
|---|---|---|
| 第一阶段：可解释调试 | R2 的逻辑图基础、R1 目标闭包、固定样本、R5 快照与节点面板、R6 单条发布门禁 | 同一输入可复查；副作用受控；错误、缓存与质量问题可定位 |
| 第二阶段：真实规模插件 | R3 隔离分批协议与能力绑定、公共 SDK 样例、R4 逐环境预检 | 超过旧 JSON 上限的负载通过真实隔离运行；中断恢复和取消围栏通过验收 |
| 第三阶段：团队复用与反馈 | 固定版本组件、升级与退役、分区补跑、标注及评测反馈 | 旧版本可追溯；引用影响明确；人工阶段不占计算 Worker |
| 按测量进入：性能扩展 | 节点资源契约、模型驻留实验与有限并发 | 有真实吞吐/成本/内存基线，收益能够复测 |
各建议与原草案的关系如下，避免研究结论直接变成隐含需求：
| 建议 | 原需求关联 | 需要单独确认的新增范围 |
|---|---|---|
| R1、R2 | F02–F05、F09，A02、A04、A07 | 目标执行、小样本语义、组件版本 |
| R3、R4 | F10–F14、F18，A08、A11 | 隔离分批、能力授权、多输出、生命周期 |
| R5 | F07–F09、F16，A06、A07、A12 | 事件订阅、受保护日志、跨运行分区复用 |
| R6 | 原文将模型效果和完整闭环列为另定范围 | 通用产物到数据集门禁，以及标注/评测连接 |
因此下一步仍然是对齐需求与验收，但应针对上述场景确定范围，而不是继续扩大通用平台清单。随后用 ADR 固定执行计划、分批语义和能力边界，定义共同契约样例，再把前端、控制面、执行器拆成可并行实现的任务。AI 开发的交付依据应是可运行样例、失败恢复和版本兼容验证，而不是代码量或页面数量。
6 本地代码依据与研究限制
以下为 data-flywheel 仓库相对路径与定位符，方便在工作区复查；未提交代码不伪造为远端 commit 链接。
| 编号 | 路径与定位符 | 支持的判断 |
|---|---|---|
| C1 | apps/web/src/components/PipelineCanvas.tsx：Props、OperatorCard；apps/web/src/pages/PipelinesPage.tsx：ArtifactPanel、VersionsPanel | 画布与运行信息边界、当前产物预览和版本页 |
| C2 | apps/api/app/pipeline_sdk.py：BatchContext、OperatorDefinition；packages/flywheel-sdk/src/flywheel_sdk/__init__.py：OperatorDefinition | 内部与公共 SDK 的 batch 能力差异 |
| C3 | apps/api/app/streaming_runtime.py：execute_batches、_commit_partition | 按序配批、检查点和取消/租约围栏 |
| C4 | apps/api/app/media_dagster.py：cache_key、compile_job、in_process_executor | 缓存身份、上传 batch 限制、本地串行执行 |
| C5 | apps/api/app/pipeline_models.py：PipelineVersion；apps/api/app/pipeline_api.py：RunCreate、_run_view | 当前图快照、运行参数及节点信息 |
| C6 | apps/api/app/plugin_release_service.py：OperatorDeclaration；plugin_release_models.py；plugin_release_runner.py；infra/plugin-runtime/runner.py | 插件声明、发布模型、隔离和上传协议 |
| C7 | apps/web/src/components/PluginDevelopmentWorkspace.tsx；PipelineDeployments.tsx | 插件阶段与轮询、环境就绪展示及部署界面 |
| C8 | apps/api/app/execution_resources.py；worker_registry.py：bind_worker；execution_worker_agent.py | 资源绑定、Worker 健康和远端执行边界 |
| C9 | apps/api/app/data_platform_service.py：quality、publish；data_platform_models.py；model_execution_models.py | 已有质量门禁、数据业务与训练关联 |
本次完成的是静态代码审阅与官方资料调研。没有据此宣称应用功能已通过端到端验收，也没有把商业产品的宣传效果、未公开调度细节或吞吐数字作为架构依据。外部项目会继续演进，实施时应固定引用版本并重新核对相关接口。
7 第一阶段实施记录
2026 年 10 月 7 日，第一阶段已在本地工作区实现，由前端、调试执行后端、数据集衔接三个方向并发开发并交叉审阅。
| 方向 | 已交付范围 |
|---|---|
| 固定输入与目标调试 | 新增文本模板、内联文档源和过滤算子；服务端计算上游依赖闭包，固定样本 ID/摘要；先预检再提交，未保存草稿不能调试 |
| 计划与运行检查 | 区分语义摘要和执行计划摘要；调试使用独立 Dagster job；运行画布显示节点状态及输入输出，历史展示使用冻结算子契约 |
| 执行边界 | 保留幂等、取消围栏、权限与执行快照；调试/正式缓存隔离；拒绝外部源、副作用、文件引用及非白名单可信插件 |
| 产物交付 | 正式成功的 documents 产物可导入候选数据集；校验完整摘要、来源 ID 和权限，导入事实与样本同事务创建；同产物/映射/名称重复导入复用候选 |
| 质量与发布 | 页面读取真实质量报告；继续使用原有标注、独立审核和发布门禁，保留运行/产物/映射来源；调试产物不能发布 |
本阶段输入固定于保存的流程版本，尚未提供已发布 DataVersion 的输入选择器。小样本调试每来源最多 100 条，节点输出也有上限；同步导入候选数据集最多 1,000 条，超过上限会在写入前拒绝。公开 SDK 的隔离分批协议、通用按键汇合、持久事件订阅、版本化子流程和插件退役仍属于后续交付。
验证包含契约与接口回归、真实 Dagster executor 执行闭包、正式产物导入后经独立审核发布的完整集成链路，以及隔离无头浏览器中的文本模板、预检、草稿保护、提交和响应式布局。生产构建通过。并发发布目前在 SQLite 上验证，PostgreSQL 并发行为与远端生产执行器仍需在对应环境验收。
工程使用说明保存在 data-flywheel/docs/pipeline-workbench-phase1.md；新增数据库 schema 8 为增量表结构，生产环境启动新版本前需执行迁移。