Microsoft PowerToys PowerRename 深度解析:批量重命名引擎的架构、实现与调试指南
本文基于 PowerToys 仓库内 doc/devdocs/modules/powerrename.md 展开,结合
src/modules/powerrename目录下的真实源码、接口定义、单元测试与 UI 测试项目,梳理 PowerRename 作为 Windows Shell 扩展从“右键菜单触发”到“正则重命名引擎执行”的完整链路。读完你将掌握:PowerRename 的三层架构与 COM 集成方式、核心库的类职责划分、可复用的调试与测试方法,以及常见故障的排查路径。
一、PowerRename 是什么
PowerRename 是 Microsoft PowerToys 中一个面向文件管理场景的实用工具:它以 Windows 资源管理器 Shell 扩展(context menu shell extension)的形式存在,让用户可以在不打开任何独立管理器的前提下,直接在文件资源管理器中对一个或多个文件/文件夹执行基于**查找替换(search and replace)或正则表达式(regular expression)**的批量重命名操作。
按照仓库内 powerrename.md 的描述,它主要提供以下能力:
- 应用前预览:真正落盘之前即可看到每一项的“原名 → 新名”变化结果;
- 查找替换 + 正则表达式:既支持纯文本替换,也支持完整正则语义;
- 按类型过滤:可以选择只对文件或只对文件夹生效;
- 大小写敏感/不敏感匹配:可动态切换匹配策略;
- 历史模式复用:通过 MRU(Most Recently Used)机制保存并复用最近的搜索/替换模式。
从源码结构看,PowerRename 的全部代码位于 src/modules/powerrename 目录,包含两个测试项目(unittests、PowerRename.UITests.Next)、一个 Fuzzing 项目(PowerRename.FuzzingTest)、一个 MSIX 上下文菜单包工程(PowerRenameContextMenu)以及传统 shell 扩展 DLL 工程(dll)等。
二、整体架构与技术栈
2.1 组件构成
PowerRename 由三大部分组成,对应三套独立的二进制/进程:
| 组件 | 位置 | 职责 |
|---|---|---|
| Shell 扩展(上下文菜单) | dll/(经典 COM 扩展)、PowerRenameContextMenu/(Windows 11 sparse MSIX 包) |
注册右键菜单、收集选中文件列表、拉起重命名 UI 进程 |
| WinUI 3 UI 应用程序 | PowerRenameUILib/PowerRenameXAML/ |
显示搜索/替换输入框、实时预览列表与设置面板 |
| 核心重命名库 | lib/(PowerRenameLib.vcxproj) |
正则匹配、条目管理、冲突检测与最终的文件重命名 |
2.2 技术栈
按 powerrename.md 的总结,技术栈为:
- C++/WinRT:核心库与 UI 的 C++ 投影层;
- WinUI 3:现代化 UI 框架,承载
MainWindow.xaml、ExplorerItem.xaml等界面; - COM:Shell 集成所需的全部接口均以 COM 对象形式暴露。
三者协作的典型调用链如下:
- 用户在多选文件上点击“PowerRename”(经典菜单注册名为
Rename with PowerRename,见 PowerRenameExt.cpp); - Shell 扩展把选中的文件路径通过匿名管道/标准输入交给
PowerToys.PowerRename.exe(UI 进程); - UI 进程内嵌的
PowerRenameLib完成预览计算,用户点击应用后执行真正的重命名。
三、上下文菜单集成:双注册与两代 Windows 兼容
PowerRename 的右键菜单遵循 PowerToys Context Menu Handlers 中描述的 Dual Registration(双注册) 模式,即同时注册:
- 一套传统 Shell 扩展(
IContextMenu风格),用于 Windows 10 与 Windows 11 的“显示更多选项”扩展菜单; - 一套 Windows 11 sparse MSIX 包(
IExplorerCommand风格),用于 Windows 11 新式右键菜单。
双注册的取舍在 context-menus.md 中有明确说明:这种策略会在 Windows 11 新式菜单展开后出现重复条目(其中经典条目位于“显示更多选项”里),但它的收益是即使某一套注册失败,功能依然可用,避免了“右键菜单完全消失”的最坏情况。
3.1 注册流程的源码证据
模块的启用/停用入口位于模块接口 DLL dllmain.cpp 中 PowerRenameModule 类(powertoy_create() 导出,见 dllmain.cpp)。
- 启用(enable):在 Windows 11 及以上(
package::IsWin11OrGreater()),检查PowerRenameConstants::ModulePackageDisplayName对应 MSIX 包是否已以当前 PowerToys 版本注册;若未注册则调用package::RegisterSparsePackage安装PowerRenameContextMenuPackage.msix(见 dllmain.cpp)。 - 注册开关(UpdateRegistration):依据启停状态调用
PowerRenameRuntimeRegistration::EnsureRegistered()/Unregister(),该段代码受ENABLE_REGISTRATION或NDEBUG条件编译控制(见 dllmain.cpp)。
对照 context-menus.md 中的通用流程:MSIX 包由构建生成后,模块启用时用
PackageManager.AddPackageAsync/RegisterSparsePackage安装,包内引用实现真正菜单处理逻辑的 DLL;用户右键时 Explorer 加载该 DLL 并回调接口方法。注册状态可用 PowerShell 验证:Get-AppxPackage -Name *PowerToys*
3.2 COM 接口实现:经典与 Win11 两套入口
Dll 入口组件中,CPowerRenameClassFactory 以 IClassFactory 形式生产 CLSID_PowerRenameMenu 对应的 COM 对象;DllGetClassObject 向系统注册表注册的类工厂开放创建能力,DllCanUnloadNow 基于模块引用计数决定 DLL 何时可卸载。
菜单本体实现在 PowerRenameExt.cpp,它同时实现了三套接口:
IShellExtInit::Initialize:接收 Explorer 传来的IDataObject/IDList,并缓存数据对象供后续使用(见 PowerRenameExt.cpp);IContextMenu::QueryContextMenu:经典菜单分支,负责把菜单项插入系统菜单。它先做三重门禁判断——模块是否启用、选中项里是否至少有一个可重命名项、以及“仅在扩展菜单显示”选项是否命中CMF_EXTENDEDVERBS;随后依据GetShowIconOnMenu()决定是否附加图标位图(见 PowerRenameExt.cpp);IExplorerCommand(如GetTitle/GetIcon等方法,声明于 PowerRenameExt.h):供 Windows 11 MSIX 菜单分支调用。
此外 PowerRenameContextMenu 中还有面向 Windows 11 sparse 包实现的 IExplorerCommand 变体,其 Invoke 会直接调用自己的 RunPowerRename(IShellItemArray*)。
3.3 关键机制:文件列表如何传给 UI
PowerRenameExt.cpp 中的 RunPowerRename 展示了经典菜单的传参机制:
- 依据 DLL 所在目录拼接出
PowerToys.PowerRename.exe完整路径; CreatePipe创建匿名管道,把读端句柄作为子进程的hStdInput,并用CreateProcess拉起 UI 进程;- 遍历
HDropIterator提供的全部选中文件,以?(问号)作为条目分隔符把每个完整路径写入管道写端; - 当由 Windows 11 菜单触发(
IShellItemArray非空)时,则走GetItemAt+GetDisplayName(SIGDN_FILESYSPATH)的枚举分支——此时因为 MSIX 注册路径不回调IShellExtInit,m_spdo为空,必须依赖 shell item 数组获取路径。
与之对应的接收端在 UI 启动逻辑 App.xaml.cpp:OnLaunched 中先扫描命令行中是否出现 \\.\pipe\ 前缀以决定走命名管道还是标准输入;随后循环 ReadFile 读入数据,再以 ? 为分隔符用 std::getline 切分出每条文件路径存入全局 g_files,最后创建并激活 MainWindow。
这一“路径即数据、进程即通道”的设计意味着:PowerRename UI 是一个可独立接收文件列表的进程,任何调用方只要以管道或命令行方式把路径喂给它即可复用整套重命名能力——这也是下文 UI 测试与调试方案的根基。
四、代码组件地图:lib 核心库职责划分
powerrename.md 的 “Code Components” 一节给出了核心库的文件地图,以下结合源码逐条展开:
| 文件 | 职责 | 关键实现要点 |
|---|---|---|
| dllmain.cpp | DLL 入口 + 模块生命周期 | DllGetClassObject/DllCanUnloadNow;模块启停时完成 MSIX 与注册表注册的增删;powertoy_create 暴露给 PowerToys runner |
| PowerRenameExt.cpp | Shell 扩展 COM 对象 | IShellExtInit/IContextMenu/IExplorerCommand,通过匿名管道把选中文件流向 PowerToys.PowerRename.exe |
| Helpers.cpp | 通用工具函数 | 文件系统操作与字符串处理 |
| PowerRenameItem.cpp | 单个待重命名条目 | 保存原始名/新名、路径、时间戳与“是否子文件夹内容”等状态;其 CreateFileW 打开文件以读取创建/修改/访问时间(见 PowerRenameItem.cpp) |
| PowerRenameManager.cpp | 重命名会话管理 | 管理条目集合、过滤/排序、启动/停止后台正则线程并协调最终 Rename;其 FOF_DEFAULTFLAGS(FOF_ALLOWUNDO | FOFX_ADDUNDORECORD | FOFX_SHOWELEVATIONPROMPT | FOF_RENAMEONCOLLISION,见 PowerRenameManager.cpp)表明重命名本身支持撤销(写入系统撤销记录)并在权限不足时触发 UAC 提升提示 |
| PowerRenameRegEx.cpp | 正则查找替换引擎 | 封装 std::regex 与 Boost.Regex 双实现,处理替换中的枚举/随机化/元数据占位符 |
| Settings.cpp | 用户偏好持久化 | 单例 CSettingsInstance()(见 Settings.cpp)承载模块级设置 |
| trace.cpp | 遥测与日志 | ETW 事件埋点,覆盖启用、菜单点击、设置变更等场景 |
| Enumerating.cpp / Randomizer.cpp | 替换串增强语法 | 解析替换文本中 ${...} 块的“序号/随机”指令(详见 §6) |
| WICMetadataExtractor.cpp / MetadataPatternExtractor.cpp / MetadataFormatHelper.cpp | 元数据驱动的重命名 | 通过 Windows Imaging Component 读取图片 EXIF/XMP 元数据,并格式化为替换占位符 |
| MRUListHandler.cpp / PowerRenameMRU.cpp | 最近使用列表 | 记录最近搜索/替换模式,受 MRU 设置控制 |
4.1 接口契约(IDL 层面)
lib/PowerRenameInterfaces.h 定义了模块内部的核心 COM 接口,是理解数据流的最佳入口:
IPowerRenameRegEx(PowerRenameInterfaces.h):持有搜索词/替换词/标志位/文件时间/元数据模式,通过Advise/UnAdvise让 UI 订阅OnSearchTermChanged、OnFlagsChanged等事件,从而驱动实时预览刷新;IPowerRenameItem(PowerRenameInterfaces.h):单条目抽象,其RenameStatus枚举(Init/ShouldRename/ItemNameTooLong/ItemNameInvalidChar/ItemNameAlreadyExists,见 PowerRenameInterfaces.h)正是 UI 中把条目标记为“名称过长/非法字符/目标已存在”等错误状态的依据;IPowerRenameManager(PowerRenameInterfaces.h):条目集合的管理与重命名协调者,Rename(hwndParent, closeWindow)为最终执行入口;其事件接口IPowerRenameManagerEvents(PowerRenameInterfaces.h)区分了单条OnRename/OnError与整批OnRenameStarted/OnRenameCompleted两种粒度的通知。
五、重命名引擎的能力边界:标志位体系
批量重命名的行为高度由 PowerRenameFlags 位标志驱动,这与 UI 中“选项(Options)”面板的开关一一对应:
| 标志(源码名) | 位值 | 语义 |
|---|---|---|
CaseSensitive |
0x1 |
匹配大小写敏感 |
MatchAllOccurrences |
0x2 |
匹配所有出现位置(否则只替换首个匹配) |
UseRegularExpressions |
0x4 |
启用正则语义(关闭即纯文本查找) |
EnumerateItems |
0x8 |
在文件名中插入自动递增序号 |
ExcludeFiles |
0x10 |
排除文件 |
ExcludeFolders |
0x20 |
排除文件夹 |
ExcludeSubfolders |
0x40 |
排除子文件夹内容 |
NameOnly |
0x80 |
仅对文件名(不含扩展名)应用规则 |
ExtensionOnly |
0x100 |
仅对扩展名应用规则 |
Uppercase/Lowercase/Titlecase/Capitalized |
0x200~0x1000 |
大小写转换(全大写/全小写/首字母大写/逐词大写) |
RandomizeItems |
0x2000 |
生成随机内容 |
CreationTime/ModificationTime/AccessTime |
0x4000/0x8000/0x10000 |
按创建/修改/访问时间戳重命名 |
MetadataSourceEXIF/MetadataSourceXMP |
0x20000/0x40000 |
指定元数据来源(EXIF 为默认,XMP 可选) |
源码注记(非用户配置项):
PowerRenameFilters枚举(None/Selected/FlagsApplicable/ShouldRename)用于预览列表的列过滤视图,属内部筛选语义,不在设置页暴露。
5.1 正则引擎的“双实现”与 UseBoostLib
CPowerRenameRegEx 的实现代码同时引用了 <regex>(std)与 <boost/regex.hpp>(见 PowerRenameRegEx.cpp),成员 m_useBoostLib 与 _useBoostLib 控制运行时选用哪套引擎。引擎的选择发生在正则对象构造阶段——这一事实直接影响调试与测试:如果在 UI 运行期间修改 UseBoostLib 设置,需要重启一个新的 PowerRename 进程才能生效(这也是文档强调的测试约束,详见 §7)。
另一个值得注意的实现细节是 SanitizeAndNormalize(PowerRenameRegEx.cpp):所有输入搜索/替换串在存储前会把 0xA0 不间断空格规范为普通空格,并通过 Windows NormalizeString(NormalizationC, …) 做 Unicode NFC(预组合)归一化,保证对 é 这类字符的匹配不因编码形态差异而出错。
5.2 增强占位符:序号、随机与时间
当替换文本命中枚举/随机化分支时(m_flags & EnumerateItems / RandomizeItems),PowerRenameRegEx.cpp 会解析替换串中的指令块并构建枚举器(Enumerator)与随机数生成器(Randomizer)实例。
序号语法由 Enumerating.cpp 的正则给出,指令块形如 ${...},内含若干可选键:
start=N(start=(-?\d+)):起始值,允许负整数;increment=N(increment=(-?\d+)):步长;padding=N(padding=(\d+)):按最少 N 位填充对齐。
随机化块同样以 ${...} 形式书写(Randomizer.cpp 中用 randGroupRegex 匹配并解析参数)。时间戳类占位符则依赖 PutFileTime/PutMetadataPatterns 注入的 SYSTEMTIME 与元数据模式映射,由 Replace 方法统一展开。这些能力的 C++ 单元测试见 unittests(含 PowerRenameRegExTests.cpp、PowerRenameRegExBoostTests.cpp、MetadataFormatHelperTests.cpp、WICMetadataExtractorTests.cpp,测试素材含 exif/xmp/heic/avif 样例,位于 unittests/testdata)。
5.3 正则替换回填与实时刷新
CPowerRenameRegEx::PutSearchTerm/PutReplaceTerm 会先对输入做归一化,再与旧值比较;只有真正变化(或调用方传 forceRenaming = true)时才会触发 _OnSearchTermChanged 等回调,进而通知订阅的 IPowerRenameRegExEvents 重新计算整表预览(见 PowerRenameRegEx.cpp)。IPowerRenameItem 上的 ShouldRenameItem/IsItemVisible 则分别判定某条目是否应被重命名及是否命中当前过滤视图。
六、WinUI 3 UI 实现
UI 工程位于 PowerRenameUILib,其核心 XAML 页面在 PowerRenameXAML 下。按照 powerrename.md 的归纳,界面提供四大交互区域:
- 搜索(Search for)/ 替换(Replace with)输入框:通过
x:Bind绑定到SearchMRU/ReplaceMRU集合,既支持手输,也能从最近历史下拉选择; - 实时预览列表:每个条目展示原名与新名,并标记冲突/错误状态;
- 选项面板:与 §5 的标志位一一对应的开关与下拉;
- 事件驱动的预览刷新:UI 监听
SearchReplaceChanged事件,任何输入/选项变化都会触发后台线程重算可见条目的新名。
6.1 视图模型与数据源
- ExplorerItemViewModel:单行预览条目的 VM,包装
IPowerRenameItem; - ExplorerItemsSource:
ItemsSource容器,衔接 Manager 的条目集合与 XAML 列表; - ExplorerItem.xaml:行模板(原名/新名/图标);
- MainWindow.xaml:主窗口布局与全部交互逻辑所在。
6.2 启动流程与进程形态
UI 是独立可执行程序 PowerToys.PowerRename.exe。启动时序(App.xaml.cpp):
- 初始化日志器(
LogSettings::powerRenameLoggerName); - 检查 GPO:若域策略
getConfiguredPowerRenameEnabledValue()返回“强制禁用”,直接ExitProcess(0)(说明可通过组策略集中管控该模块); - 按命令行/管道方式读入文件列表(见 §3.3);
- 创建并激活
MainWindow。
七、测试体系
PowerRename 的自动化验证在仓库中分三层落地。
7.1 单元测试(C++)
unittests 项目直接针对核心库,测试文件包括 PowerRenameRegExTests.cpp、PowerRenameRegExBoostTests.cpp(共用 CommonRegExTests.h 头,用于对 std 与 Boost 两套引擎跑同一组用例)、PowerRenameManagerTests.cpp、HelpersTests.cpp、MetadataFormatHelperTests.cpp、WICMetadataExtractorTests.cpp,并提供 MockPowerRenameItem/MockPowerRenameManagerEvents 等模拟对象隔离外部依赖。
7.2 UI 测试(迁移版:PowerRename.UITests.Next)
PowerRename.UITests.Next 依据 powerrename.md 的说明,改用 Microsoft.PowerToys.UITest.Next + winappcli 框架驱动模块,测试用例覆盖经典菜单(ClassicContextMenu.cs)、文件列表(PowerRenameFileListTests.cs)、选项(PowerRenameOptionsTests.cs)、正则(PowerRenameRegExTests.cs)、设置(PowerRenameSettingsTests.cs)与完整菜单交互(PowerRenameContextMenuTests.cs)。
文档同时点出了该模块专属的四条约束,它们是编写/维护这些测试时必须牢记的前提:
- 命令行传参:PowerRename UI 是在命令行上接收选中文件的(对应
App.xaml.cpp的ParseCommandLineArgs分支)。因此测试会直接启动PowerToys.PowerRename.exe并每个路径传一个参数;runner/Settings 进程的作用范围仅限于“模块是否启用 + shell 是否已注册”,不参与传参。 - Windows 11 一级菜单测试需要签名:Tier-1 上下文菜单测试要求
PowerRenameContextMenuPackage.msix已签名且受信任;未签名的构建仍可回退测试经典菜单。 UseBoostLib读取时机:该设置只在“正则引擎构造”时读取一次,改变它必须重新启动 PowerRename 进程,否则不生效。- 设置持久化时序:Shell handler 独立读取全局/模块设置,不信任 Settings 页内存状态;测试要等待设置落盘,并在注册变更后重启 Explorer,再继续断言。
测试框架的整体构建/本地虚拟机/流水线流程见 UI tests framework。此外,仓库还保留了旧版测试工程 PowerRenameUITest(含 testItems 样例目录)与 PowerRename.FuzzingTest(OneFuzz 集成,见 OneFuzzConfig.json),用于对正则输入做模糊测试。
八、调试指南
8.1 调试上下文菜单
菜单处理器本质是 Explorer 进程加载的 COM 对象,通用调试思路请遵循 Debugging Context Menu Handlers:
- Windows 10 经典 handler:修改注册表把 COM 对象指向调试构建的 DLL → 重启 Explorer → 将调试器附加到
explorer.exe→ 在QueryContextMenu/InvokeCommand/RunPowerRename下断点 → 右键触发; - Windows 11 MSIX handler:先构建得到 MSIX → 用自签名证书签名 → 替换安装目录中的文件 → 由 PowerToys 完成包安装 → 重启 Explorer → 以管理员身份运行 Visual Studio → 断点后附加到
DllHost.exe(右键时包进程会临时宿主菜单 DLL)。
8.2 调试 UI(不依赖 Shell 注册)
powerrename.md 给出了免菜单、免注册的 UI 调试捷径:
- 手动在 App.xaml.cpp 中把需要测试的文件路径填入文件列表(该文件顶部维护了全局
g_files向量,其标准输入分支也提供了DEBUG_BENCHMARK_100K_ENTRIES宏用于 10 万级条目的压测,见 App.xaml.cpp); - 将 PowerRenameUI 工程设为启动项目;
- 直接以调试模式运行,即可用这些文件打开完整的 PowerRename 窗口进行交互验证。
由于 UI 进程支持命令行传参与 stdin 管道两种入参方式,开发者同样可以临时写一个把路径拼到 PowerToys.PowerRename.exe 参数之后的启动器(参考 testapp/ 与 PowerRenameTest.cpp 的做法)来反复启动。
8.3 常见问题排查
| 现象 | 排查建议(来自 powerrename.md) | 仓库内的佐证路径 |
|---|---|---|
| 右键菜单不出现 | 确认扩展已正确注册、Explorer 已重启 | 注册逻辑见 dllmain.cpp |
| UI 无法启动 | 打开事件查看器,检查 WinUI 3 应用激活相关错误 | UI 激活入口见 App.xaml.cpp |
| 重命名失败 | 核对文件权限、确认文件未被其他进程锁定 | 文件时间读取与状态码逻辑见 PowerRenameItem.cpp、PowerRenameInterfaces.h |
针对 Windows 11 菜单缺失,context-menus.md 还补充了两条高频成因:包在 PowerToys 更新时未被正确卸载/替换,以及注册 MSIX 需要签名——对应解法分别是卸载重装包或重启 Explorer、为本地测试创建并安装签名证书。
九、模块设置与 GPO
PowerRename 作为 PowerToys 模块,其设置以 JSON 形式暴露给 PowerToys Settings,读写两端都在 dllmain.cpp:
- 读取(get_config)(dllmain.cpp):声明下述开关及其当前值;
- 写入(set_config)(dllmain.cpp):把 JSON 反序列化后逐个写入
CSettingsInstance()并Save()。
可用设置项一览:
| JSON 键 | 界面含义 | 默认/取值 |
|---|---|---|
bool_persist_input |
是否记住上次输入的搜索内容 | 布尔 |
bool_mru_enabled |
是否自动保存最近的搜索/替换模式 | 布尔 |
int_max_mru_size |
最近模式的最大条目数 | 整数,滑块范围 0–20,步长 1 |
bool_show_icon_on_menu |
右键菜单是否显示图标 | 布尔 |
bool_show_extended_menu |
仅把菜单项放进“显示更多选项”扩展菜单 | 布尔 |
bool_use_boost_lib |
正则引擎使用 Boost.Regex 而非 std::regex | 布尔(改动需重启 PowerRename 进程生效) |
此外模块还接入 GPO:gpo_policy_enabled_configuration() 读取 getConfiguredPowerRenameEnabledValue()(dllmain.cpp),管理员可通过组策略强制启用/禁用该模块。
十、进一步阅读
- 模块入口文档:PowerRename 模块说明
- 上下文菜单双注册与调试:PowerToys Context Menu Handlers
- UI 自动化测试框架与流水线:UI tests framework
- 核心实现源码目录:src/modules/powerrename(
dll、lib、PowerRenameContextMenu、PowerRenameUILib、unittests、PowerRename.UITests.Next)
小结
PowerRename 是一个“外壳薄、内核厚”的典型 Windows 模块:Shell 层用双注册策略兼顾 Win10/Win11 两代菜单,进程边界上用管道/命令行优雅地传递文件列表;真正的价值沉淀在 lib 核心库——一套以 COM 接口为契约、位标志为行为开关、支持 std/Boost 双正则引擎并叠加序号/随机/时间戳/图片元数据等增强占位符的重命名引擎。理解这条链路后,无论是为其新增规则、编写 UI 测试还是排查“菜单不出现 / UI 起不来 / 重命名失败”三类高频问题,都能从源码层面找到确定的落点。
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0627
Hy4-previewHy4 preview 是由腾讯混元团队研发的新一代混合专家(MoE)旗舰模型。模型总参数量 770B,每个 token 激活 49B,主干共包含78层,第一层采用标准 FFN,其余 77 层均为 MoE 结构,每层包含 256 个路由专家与 1 个共享专家,每个 token 激活 top-8 路由专家及共享专家。主干之外原生内置 1 层 MTP(总参数量 10B,激活 0.7B)以支持投机解码。Python00
GLM-5.3GLM-5.3 与 GLM-5.2 使用相同的基座模型——所有提升均来自后训练。与 GLM-5.2 相比,它在复杂编程和长程任务上的表现显著提升。Jinja00
GLM-5.3-FlashGLM-5.3-Flash (320B-A18B),是GLM-5系列的首个原生多模态模型。320B总参数,能力超过GLM-5.2Jinja00
Spark-X2.5-4BSpark-X2.5-4B 旨在让强大的 AI 更实用、更高效、更易获得。在广泛日常任务中表现强劲,涵盖对话、写作、翻译、推理、编码、工具调用以及智能体工作流,并在同等规模的开源模型中取得领先成绩。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00
Spark-X2.5-1.7BSpark-X2.5-1.7B 旨在让强大的 AI 更加实用、高效且易于获取。这些模型在广泛的日常任务中表现出色,涵盖对话、写作、翻译、推理、编程、工具调用和智能体工作流,并在同等规模的开源模型中取得领先结果。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00