<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Operator - Naifan Li's Blog</title><link>https://blog.omagiclee.com/tags/operator/</link><description>Operator - Naifan Li's Blog</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><lastBuildDate>Sun, 06 Sep 2026 00:04:00 +0800</lastBuildDate><atom:link href="https://blog.omagiclee.com/tags/operator/index.xml" rel="self" type="application/rss+xml"/><item><title>Operator as Plugin：借鉴 DeepSeek Harness 设计数据平台插件体系</title><link>https://blog.omagiclee.com/posts/ai-data/data-platform/operator-as-plugin/</link><pubDate>Sun, 06 Sep 2026 00:04:00 +0800</pubDate><guid>https://blog.omagiclee.com/posts/ai-data/data-platform/operator-as-plugin/</guid><description><![CDATA[<p>世界模型数据平台往往沿着“接入 → 清洗 → 加工与镜头切分 → 打标 → 向量化与索引 → 检索挖掘 → 标注”逐步扩展。如果每增加一种算法都要修改主服务、增加专用接口、重新部署整个系统，平台很快会成为难以维护的算法集合。</p>
<p><strong>Operator as Plugin 是可行方向：算法作者贡献能力，平台负责让能力可调用、可组合、可追踪地运行。</strong> 但插件注册只解决了扩展入口，长任务恢复、数据语义、GPU 执行和结果发布还需要独立设计。</p>
<p>本文延续 Data Flywheel 的技术设计讨论，并参考 DeepSeek 官方 Harness 文档。资料核对日期为 2026-09-06；以下数据平台协议、示例清单与架构均为本文提出的方案，<strong>不是 DeepSeek Harness 已有的数据处理 API，也不是 Data Flywheel 已经实现的插件系统</strong>。</p>]]></description></item></channel></rss>