Helicon-DGX Spark 黑客松“十日谈”
让一台 DGX Spark 成为一支本地科研视觉团队
一般的开发历程很容易被写成一份按天排列的流水账：下载模型、搭建页面、修复报错、录制视频。但真正值得记录的，并不是每天完成了多少任务，而是我们如何从一个模糊想法出发，逐步回答了四个更重要的问题：
本地模型相较云端 API，究竟应该创造什么不同的产品体验？
一台 DGX Spark 能否同时承载长上下文主模型、生图模型、多个 Agent、数据库与 Web 应用？
如何把通用 Agent 能力收敛到科研视觉这一高准确性行业场景？
如何让最终成果不止是一张 PNG，而是可以继续理解、引用和修改的视觉工程文件？
围绕这些问题，我们从零搭建了 Helicon 的本地闭环：研究材料留在设备内，主 Agent 理解目标，多个子 Agent 并行探索设计方向，本地 FLUX 生成真实概念图，用户选择后，主 Agent 再把方案实现为可编辑的 HTML/CSS/SVG 科研图稿，并通过渲染截图反复审查。
最终交付是 output/figure.html。PNG 与 SVG 是同源导出格式，而不是系统唯一的答案。
一、我们要解决的不是“如何生成一张科研风图片”
科研视觉和普通文生图有一个根本区别：图中的文字、数字、公式、箭头方向和结构关系，往往就是研究结论本身。
一张图可以非常漂亮，但如果把“促进”画成“抑制”，把实验组与对照组互换，或者把 Transformer 的残差连接接错，它就不能成为科研成果。另一方面，科研图也不能退化成只有矩形和箭头的僵硬流程图。研究者仍然需要清晰的视觉层级、叙事节奏、构图、科学插画和专业的风格语言。
真正棘手的部分往往发生在修改阶段。导师或合作者通常不会要求“整张重新生成”，而会说：
中间模块太小，请突出核心机制；
这个箭头应该是虚线；
保留上一版布局，只替换右下角的设备；
标题需要更短，但不要改变整体比例；
这一处细胞需要更接近真实形态。
如果产物只是一张扁平 PNG，任何局部修改都会退化成重新抽卡。传统设计软件当然可以编辑，但它要求研究者自己掌握图层、节点、锚点和复杂操作。
因此 Helicon 从一开始就把产物定义为“由 Agent 维护、研究者可以通过自然语言继续修改的视觉工程文件”：
文字、数字、公式、框、箭头、图表和确定关系由 HTML/SVG 绘制；
细胞、组织、设备、材料、场景和复杂图标由生成模型提供；
每个语义元素拥有稳定的 data-element-id；
用户点击元素时，前端把元素 id、局部文字和源码片段引用给 Agent；
Agent 修改真实 HTML，再重新渲染与发布。
用户不需要直接操作无限画布，也不需要理解前端代码，却获得了比 PNG 更可靠的局部修改能力。
二、产品闭环：先看真实方案，再进入高精度生产
云端生图服务通常按次收费，因此常见流程是先给用户三段文字方案，用户在看不到真实效果时选一个，然后系统只生成一张图。
在 DGX Spark 上，FLUX 是本地常驻服务，没有逐张 API 账单。我们因此重新设计了交互顺序：
论文、补充材料、参考图片与自然语言目标
→ 主 Agent 分析领域、逻辑和视觉要求
→ 写出三个叙事与构图真正不同的视觉规格
→ 动态拉起三个概念 Agent
→ 三个 Agent 并行完成设计与 FLUX prompt
→ FLUX 本地生成三张真实完整概念图
→ 主 Agent 比较结果、给出推荐
→ 用户基于真实图片选择与反馈
→ 主 Agent 用 HTML/CSS/SVG 重建所选方向
→ 生成必要的复杂视觉素材
→ RenderFigure 渲染截图并回传主模型审查
→ PublishFigure 发布 HTML/SVG/PNG
三个概念不是同一张图换颜色或 seed，而是在阅读路径、视觉 hero、panel 结构、画布比例、视觉隐喻和信息密度上真正不同。主 Agent 收齐后必须给出自己的判断，不能把全部选择责任重新丢回用户。
本地算力在这里不是简单替换了一个 API 地址，而是改变了产品的交互经济学：AI 可以更“舍得”探索，用户可以更晚作决定，设计过程从文字猜测升级为视觉比较。
三、虚拟 Workspace：把沙盒成本还给模型推理
Helicon 最容易被忽略、却最具扩展价值的设计，是它的虚拟 Workspace。
很多 Agent 产品会为每个用户或每个任务创建容器、沙盒甚至完整虚拟机。隔离很直观，但代价也很直接：启动环境、挂载目录、准备依赖、复制文件、恢复长任务，都需要额外资源。多个子 Agent 还会继续放大这笔成本。
Helicon 没有为每个 Agent 启动一套 Linux 环境，而是把 Agent 真正需要的文件能力抽象成轻量虚拟文件系统：
会话命名空间
├── input/ 用户材料
├── analysis/ 领域、逻辑、风格与视觉规格
├── concepts/ 三个概念方向及真实预览
├── production/ HTML 源稿、视觉素材与渲染结果
├── reviews/ 审查记录
├── output/ 用户可见交付物
└── MAP.md 工作区文件地图
Agent 使用 Read、Write、Edit、Glob、Grep 等接近本地编程 Agent 的工具，但它看到的是逻辑相对路径，而不是服务器绝对路径。文件字节写入 GridFS，路径、版本、说明和索引保存在 MongoDB；同一轮运行维护读后写缓存，服务重启后可以从持久化状态恢复。
这层设计让接近编程 Agent 的工作体验可以被轻量地扩展到多会话、多用户与多 Agent。新增协作者主要增加的是模型上下文和推理请求，而不是一整套操作系统副本。
DGX Spark 本身就是一台完整 Linux 服务器，这让两者相得益彰：vLLM、Diffusers、MongoDB 与 Web 服务常驻，局域网浏览器作为客户端，Agent 在逻辑 Workspace 中工作。系统终于可以把最宝贵的统一内存和计算资源用于模型，而不是用于复制环境。
四、动态多 Agent：主 Agent 决定何时需要协作者
Helicon 的多 Agent 不是写死的工作流节点。
主 Agent 与子 Agent 使用同一套本地模型客户端、工具循环、上下文管理与结果协议。每个子 Agent 拥有独立消息历史、turn budget、AbortController 与工具白名单，但直接看到同一 Workspace。
主 Agent可以：
根据任务决定是否需要子 Agent；
为每个子 Agent 动态编写完整 prompt；
指定角色 Profile、工具子集和预算；
前台等待，或在后台并行运行；
使用 SendMessage 补充要求；
单独停止某个不再需要的方向；
恢复已经关闭的命名 Agent 会话；
通过 SubmitResult 只接收摘要、发现、产物和警告。
三个概念 Agent 分别收到主 Agent 根据当前研究内容编写的任务，而不是共享一段预设概念提示。它们可以并行分析和写 prompt；FLUX 由于显存与稳定性考虑保持单并发队列，图片生成后逐张推送前端。
前端只展示公开运行状态，例如“正在分析材料”“正在生成视觉方案”“正在审查”，不暴露内部推理。主 Agent 结束任务后，对应卡片关闭；需要时可以再次恢复。
这种架构的并发上限主要由 Spark 推理服务决定。当前一个主 Agent 加三个概念 Agent 恰好对应四路 continuous batching；未来增加模型并发能力时，不需要重新设计固定 Workflow。
五、Skill：把通用运行时变成行业 Agent
通用 Agent 解决“如何工作”，却不知道“科研视觉应该怎样工作”。
我们没有把所有方法塞进不断膨胀的系统提示词，也没有为不同学科复制整个 Agent。系统提示词只描述稳定环境：身份、语言、Workspace、权限、Agent 生命周期、信任边界和工具原则。具体专业方法由 Skill 按需加载。
核心 Skill 包括：
scientific-drawing：端到端任务路由，判断当前处于分析、概念探索、用户选择、HTML 生产、局部修改还是审查阶段；
scientific-art-direction：负责叙事、动态比例、构图、视觉哲学、素材策略、反 AI slop 和 FLUX prompt；
visual-review：检查事实、视觉层级、遮挡、裁切、连接关系与渲染一致性；
biology、computer-science、economics：处理学科结构、术语、符号和错误边界。
Skill 只负责特定任务“怎么做”；工作区路径、权限和运行环境仍由系统提示词与 WorkspaceDefinition 负责。这一边界让同一个 Agent 内核未来可以继续扩展到芯片设计、工业流程、医疗解释与教育可视化，而不需要复制整个产品。
六、为什么最终产物是 HTML，而不是一张图或一大组 JSON
科研图天然需要结构化，但结构化不等于必须发明一套庞大的中间协议。
我们曾验证过由多个 JSON 文档驱动渲染的方案，但在真实长周期任务中，它会迫使模型花大量上下文维护字段、路径和版本。当一个字段格式错误时，系统会反复停在“JSON 无法解析”，而用户真正需要的图稿仍未出现。
最终我们把主链收紧为：
设计 Skill
→ 分析与概念方案
→ FLUX 生成完整概念图与局部素材
→ 直接编写 production/figure.html
→ RenderFigure 校验并生成同源 SVG/PNG
→ 多模态模型读取渲染图继续修改
→ PublishFigure 发布 output/figure.html
HTML/CSS/SVG 本身就是成熟、可渲染、可检查、可定位元素的结构化语言。最终图稿必须包含唯一的 svg#figure-root，不依赖 CDN、外部字体、外部脚本或网络图片；复杂素材使用 workspace://production/assets/... 引用，在渲染阶段校验并内联。
每个语义区域使用稳定 data-element-id。用户在浏览器中点击元素时，选择桥只把局部引用交给 Agent；修改仍由 Agent 完成，因此产品不需要演变为通用无限画布。
HTML 是用户成果；JSON 只用于少量状态与概念元数据。
七、生成式视觉与确定性图形各做擅长的部分
科研视觉不能只靠扩散模型，也不能要求代码绘制一切。
FLUX 负责：
三张完整概念图的构图与视觉语言；
细胞、组织、材料、设备与实验场景；
风格一致的图标和复杂局部视觉资产；
参考图编辑与风格延续。
HTML/SVG 负责：
标题、标签、数字、公式和真实数据；
框、箭头、连接关系、panel 和图表 geometry；
对齐、层级、顺序与最终排版；
可选中元素与稳定引用。
图标可以先由 FLUX 批量生成，再使用本地 ImageProcessor 去背景、检测区域和裁切。某个复杂对象需要修改时，只重新生成该素材；文字、颜色、位置和箭头修改则完全不调用生图模型。
这种混合生产避免了两个极端：既不让代码勉强绘制所有科学对象，也不把权威事实交给可能生成伪文字和错误关系的扩散模型。
八、模型选型：两条 NVIDIA 优化路线都真实部署和使用
DGX Spark 拥有 128GB 统一内存，但我们的目标不是让单个模型独占整台设备。主模型、生图模型、KV cache、MongoDB、Web 服务和多个并发请求必须共驻。
因此我们设置了三个硬门槛：
主模型需要 200K 级上下文；
四路并发时每路解码速度至少 30 tok/s；
主模型必须和 FLUX.2 9B-KV 稳定共驻。
第一阶段：NVIDIA Nemotron Omni
我们首先部署并使用了 nvidia/Nemotron-3-Nano-Omni-30B-A3B-Reasoning-NVFP4。
它由 NVIDIA 发布，31B 总参数、每 token 约 3B 激活，支持文本、图像、音频和视频输入，最大上下文 256K。NVFP4 版本约 20.9GB，官方明确支持 DGX Spark。它在项目中实际完成了：
OpenAI-compatible 本地服务接入；
多模态图片读取；
reasoning 与工具调用协议解析；
205K 冷启动长上下文 needle 测试；
与 FLUX 9B-KV 共驻下的四路并发测试；
第一阶段完整 Agent 与概念图闭环验证。
Nemotron 证明了 NVIDIA 原生多模态模型可以在 Spark 上承担长上下文 Agent。四路同时生成 256 token 时，最慢一路仍达到 39.196 tok/s，超过产品设定的 30 tok/s 门槛。
第二阶段：NVIDIA 优化版 Qwen3.6
随着工具数量、系统提示词和长周期修改链路增加，我们需要进一步比较模型在真实 Agent 任务中的稳定性。最终引入并实际部署了 nvidia/Qwen3.6-35B-A3B-NVFP4。
这是 NVIDIA 使用 NVIDIA Model Optimizer 对 Qwen3.6-35B-A3B 制作的预量化 NVFP4 版本，35B 总参数、每 token 约 3B 激活，支持文本、图像与视频，官方上下文上限 262K，模型权重约 23.5GB。它不是未经优化的通用权重，而是面向 NVIDIA GPU Agent、对话与 RAG 场景发布的量化模型。
在 Helicon 的实际测试中，Qwen3.6 在以下方面表现更好：
中文指令遵循更稳定；
能更准确地区分思考、用户正文和工具调用；
对复杂 JSON Schema 工具参数的遵循率更高；
能连续完成“写 HTML—渲染—看图—修改”的长链路；
在子 Agent 委派、文件路径和 Skill 使用上更少陷入无效循环。
与 FLUX 共驻时，四路并发、每路生成 512 token 的实测速度约为 48.6–52.6 tok/s；单路非思考模式 1024-token 测试约为 118 tok/s。由于测试输出长度和采样配置不同，这组结果不作为严格模型排行榜，但足以验证 Qwen3.6 满足产品的并发体验要求。
因此最终版本把 Qwen3.6 NVFP4 设为默认主模型，同时保留 Nemotron Omni 的部署脚本、适配器和验证记录。两种模型都真实部署、使用并参与了系统设计；最终选择 Qwen3.6，不是放弃 NVIDIA 技术路线，而是在 NVIDIA 优化模型栈中选择了更适合当前 Agent 工作负载的方案。
本地生图：FLUX.2 Klein 9B-KV FP8
视觉生成采用 black-forest-labs/FLUX.2-klein-9b-kv-fp8，通过本地 Diffusers/FastAPI 服务直接调用，不依赖 ComfyUI。
9B-KV 利用参考图 KV cache 加速多参考编辑，适合概念图、科学插画、设备、材料和风格一致资产的生成。512×512 实测中，新图生成服务端耗时 4.051 秒，参考图编辑耗时 2.726 秒。
九、NVIDIA SDK 与 DGX Spark 平台能力如何进入系统
Helicon 对 NVIDIA 技术栈的使用不是停留在“模型跑在显卡上”，而是贯穿部署、量化、调度和共驻：
运行时还启用了 continuous batching、chunked prefill、prefix caching 和多序列调度。主 Agent 与子 Agent 共享同一模型服务，不为每个 Agent 复制权重。
这正是 DGX Spark 的价值：它不是一张只能运行单个模型的加速卡，而是一台可以承载完整 AI 应用栈的本地 Linux 服务器。
十、真正困难的是让长周期 Agent 不失控
1. 系统提示词、Workspace 与 Skill 必须有明确边界
早期版本曾把工作区路径和运行约定塞进 Skill，导致未加载 Skill 的 Agent 不理解环境。最终我们将职责重新分层：
系统提示词：身份、中文交互、工具原则、Agent 生命周期和安全边界；
WorkspaceDefinition：真实目录语义、文件地图、读写约定和 HTML 交付契约；
Skill：科研视觉、艺术指导、领域表达与审查方法。
行为主要由提示词和工具描述引导，而不是用大量底层硬门禁替代模型判断。
2. 不同模型的思考协议不能混用
Nemotron 使用 reasoning_budget，Qwen3.6 在当前 vLLM 中实际使用 thinking_token_budget。Qwen 的模板只识别 enable_thinking 与 preserve_thinking，并不原生区分 low/high/max 五档。
最终配置为 64K 最大输出、10K 思考预算，并在多轮工具调用中保留思考上下文。协议适配放在唯一的模型传输边界中，不让业务逻辑感知模型差异。
3. 文件真实存在，不等于 Agent 和前端都看得见
虚拟 Workspace 的文件名不是白名单，任何安全相对路径都可以创建。但系统仍要明确：
Agent 使用的是逻辑路径，不是真实磁盘路径；
写入成功后必须立即对其他 Agent 可见；
前端必须从 GridFS 索引展示真实 artifact；
子 Agent 直接写主 Agent 分配的共享路径，避免多层目录映射；
最终输出目录只能由根 Agent 发布。
我们删除了不必要的私有 Agent 文件夹，让三个概念 Agent 直接写入 concepts/<id>/，显著降低了较小模型的路径理解负担。
4. “模型看到了截图”必须有真实证据
RenderFigure 会读取 production/figure.html，内联 Workspace 素材，把 HTML 内联 CSS 注入 svg#figure-root，生成同源 SVG/PNG，并把 PNG 作为多模态工具结果返回主模型。
一次验收中，渲染器只截取 SVG 而遗漏 <head><style>，导致模型看到大量黑块，却继续在错误画面上调整位置。我们通过真实会话工具记录和渲染产物定位问题，修复后让模型看到的 PNG 与浏览器中的图稿保持一致。
同一问题还暴露出前端状态不能“猜”：早期所有图片事件都被标成 GenerateImage，连 RenderFigure 截图也显示为调用了 FLUX。现在图片事件携带真实来源工具，并合并回原工具行。
5. 调度是产品体验的一部分
长上下文 prefill 会阻塞交互请求。早期压测中，8K、16K、32K 子任务同时进入 prefill 时，一个 2K 根 Agent 请求的 TTFT 升至 17.236 秒。
因此系统采用：
根 Agent 优先；
最多四路 continuous batching；
长 prefill 限流；
冷启动四路预热；
FLUX 单并发队列；
概念研究并行、图片顺序生成并逐张推送。
本地多 Agent 系统的体验上限，不只由平均 TPS 决定，也由 TTFT、KV cache、prefill 与任务调度共同决定。
十一、Helicon 最终形成的十个亮点
轻量虚拟 Workspace：用逻辑命名空间替代每任务一个容器。
通用 Agent 运行时：主 Agent 与子 Agent 共享工具循环和模型服务。
动态多 Agent：主 Agent 自己创建、补充、停止和恢复协作者。
按需 Skill 系统：通用底座不复制，专业方法按任务加载。
本地三概念工作流：直接生成真实方案，让用户基于画面作决定。
双 NVIDIA 优化主模型验证：Nemotron 与 Qwen3.6 都完成真实部署与任务测试。
生成式与确定性混合生产：FLUX 负责复杂视觉，HTML/SVG 负责权威事实。
HTML-first 交付：最终成果可离线、可引用、可继续修改。
渲染—看图—修改闭环：主模型能读取真实渲染结果继续优化。
全本地数据闭环：论文、模型、Agent、数据库、素材、渲染与导出留在 DGX Spark。
十二、结语：把一台开发机变成一支本地 AI 团队
黑客松开始前，我们对本地 AI 的理解主要是离线、隐私和不需要 API key。真正把长上下文多模态模型、三个子 Agent、9B 生图模型、数据库和 Web 应用放到同一台 DGX Spark 后，我们才意识到，本地计算会反过来改变系统架构和产品交互。
它允许模型服务常驻，允许 Agent 轻量并发，允许系统在没有逐张成本焦虑的情况下先生成三张真实设计，也允许未公开论文、实验图与所有中间产物留在设备内。
Helicon 证明的并不只是“DGX Spark 可以运行一个大模型”。更有价值的结论是：一台拥有统一内存、完整 Linux 环境和足够推理吞吐的设备，可以承载一整套本地 Agent 生产系统——模型、工具、文件、协作者、状态和用户界面在同一环境中闭环。
最后留下的产品逻辑非常清晰：
让 Agent 理解研究，让本地模型大胆探索设计，让用户围绕真实方案作决定，再让代码把选中的方向变成准确、可修改、可交付的科研视觉作品。
这就是我们对 DGX Spark 上本地行业 Agent 形态的一次完整回答。
