AesCode 32B 与 Muse Code：海报引擎与海报智能体并非竞争对手

AesCode 32B 和 Muse Code之所以被拿来比较，是因为这两个名字都含有“code”一词，而这几乎是它们唯一的共同点。AesCode 32B 是微软用于生成可编辑 HTML 和 CSS 的研究检查点——幻灯片、海报、仪表盘、报告——以 Apache 2.0 许可发布在 Hugging Face 上，其仓库创建于 2026 年 9 月 29 日，带有“Release AesCode-32B”名称的提交日期为 2026 年 10 月 7 日。微软没有对此发布任何消息：没有发布博文，没有新闻稿，模型卡本身也未说明发布日期。Muse Code 根本不是模型。它是 Meta 的终端编码代理，自 2026 年 8 月初起处于测试阶段，时间都花在针对仓库运行 shell 命令上。其中一个会生成你在浏览器中打开的文件。另一个则不断运行命令，直到测试通过。在它们之间做选择并不是一个模型决策，而本页能做的有用之事，就是阻止你把它当作模型决策来做。

每个到底是用来做什么的？

AesCode 32B 以 Qwen3-VL-32B-Instruct 为基础，根据其模型卡，先通过冷启动监督微调在 3,000 条演示上进行训练，随后采用 GDPO 强化学习，覆盖七个奖励通道——执行、文本、边界、表格/图表、布局、空白和设计。其中六个通道是确定性验证器；第七个是视觉语言评判器，它依据与目标页面“设计图”相关联的每样本评分标准进行评判。每个候选输出都在沙盒化的 Playwright 浏览器中渲染，并阻止外部请求，然后根据 DOM、计算样式、边界框和屏幕截图进行评分。模型卡明确列出了预期输出：可编辑幻灯片、海报、仪表板和报告，以及多模态代码生成研究。该模型输出完整的 HTML 文档，并被训练使用真实的 HTML 表格结构和 ECharts 规格，以使其输出保持可检查。

Muse Code 在结构上与众不同。它是面向 macOS 和 Linux 的原生二进制程序，带有一个主智能体循环、会在整个会话过程中持续收集上下文的异步后台智能体、让子智能体互不冲突的隔离 Git 工作树，以及一个本地事件日志，使崩溃的会话能够被重放或恢复。根据 Meta 自己的报告，它会在以小时计的时间段内发起数千次工具调用。所出售的是这个循环，而非产物。

把两者并排放在一起，动词却对不上。AesCode 32B 渲染。Muse Code 执行。如果你的问题是“我们的季度演示文稿要设计师花三天时间”，那么 Muse Code 毫不相关，而 AesCode 32B 正是冲它而来。如果你的问题是“没人愿意花一个周末升级这棵依赖树”，AesCode 32B 无话可说，而 Muse Code 才是那个工具。

每一方的证据并非同一类证据。

这正是每个对比页面都会搞错的部分，所以值得慢慢来。

AesCode 32B 的数据来自一项 300 样本的信息图评估，每个提示生成三次且不做筛选；就其自身标准而言，这些数据相当亮眼：总体得分为 85.89，而 GPT-5.5 为 81.28，Claude Opus 4.8 为 80.39，后两者的测量均使用相同的参考图像设置，并由微软自家的测试框架完成。该卡片还报告称，严重的画布边界失败在 4.3% 的样本上反复出现，而 GPT-5.5 为 34.7%；此外，AesCode 32B 在其自身的 Qwen3-VL-32B 骨干模型基础上，在视觉维度上高出 22.4 分，在总体得分上高出 24.8 分。

把这一切都视为厂商自报且未经复现。该基准、训练该模型所用的奖励通道，以及给它打分的指标，都出自同一家实验室，而那 300 个样本则来自 Microsoft。这并不是否定这一结果的理由——这次评估异常透明，验证器栈是开放的，而且模型卡公布了一个没有任何模型能超过 60 分的维度（“style”，其中没有任何模型得分高于 55.99），这比大多数厂商表格所体现的诚实还要多。这倒是一个理由：不要把 85.89 与另一个实验室在另一项任务上得出的数字并列，然后假装进行过比较。

Muse Code 的数字是在另一种意义上由 Meta 报告的：它们衡量的是模型与测试框架的组合。Meta 报告 Muse Code 在 Term-Bench 2.1 上达到 92.9%？等等，是 82.9%，仅次于搭配 Claude Code 的 Claude Opus 5 的 86.7%，此外在 DeepSWE 1.1 上为 59.3%，在一个内部编程基准上为 70.6%。由于那张表中不同的模型搭配了不同的测试框架，你无法从系统得分中读出模型本身的贡献。而且 Muse Code 的评测内容与 AesCode 32B 的评测内容完全没有重叠——前者评测的是终端任务和软件工程，后者评测的是信息图文本是否清晰可读、其布局是否溢出。

一个"32B 检查点"隐藏了什么

部署正是两个产品分歧最大的环节，而简短版本用项目符号列表就能说清。

• 它是什么——AesCode 32B：一个可供下载的 33B 参数模型检查点。Muse Code：一款可安装的终端智能体产品。

• 许可证 — AesCode 32B：Apache 2.0，包含权重。Muse Code：专有；其背后的模型是闭源的。

• 你需要提供的 —— AesCode 32B：一块 GPU 和一套服务栈。Muse Code：一个 API 密钥或一份订阅。

• 硬件门槛 — AesCode 32B：模型卡建议仅为 bf16 参数就规划约 65 GB 加速器内存，而其自身的服务示例使用四路张量并行。Muse Code：一台笔记本电脑。

• 上下文 — AesCode 32B：在报告的配置中为 24,576 个 token，RL 训练期间提示和响应上限为 8,192 个 token。Muse Code：通过其底层的 Muse Spark 模型提供 100 万 token 的窗口。

● 价格——AesCode 32B：权重免费，成本在于硬件。Muse Code：按 token 计费，或通过月度套餐。

• 证据 — AesCode 32B：由供应商在自己的 300 个样本上运行、且已公开评测框架的评估。Muse Code：Meta 报告的、针对耦合的智能体+模型技术栈的系统级基准测试。

那个“硬件下限”一行正是人们会跳过的。bf16 下的 32B 检查点可不是能在笔记本上跑的模型，而 AesCode 32B 在此基础上还是一个视觉语言模型，所以服务路径还要处理图像输入。Muse Code 则是一个花一下午就能装好的二进制程序。

在它们真正重叠的地方

确切地说，只有一处真正的重叠，而且范围很窄：二者都可以被指向一个与设计相邻的产物，并被要求产出某种需要由人进一步打磨的东西。如果你的团队正在以代码方式生成内部仪表盘，同时还想要一个能针对该仪表盘仓库发起拉取请求的智能体，那么这两款产品都会触及这一工作流。

即使在那里，分工也很清晰。AesCode 32B 生成产物。Muse Code 产生变更。一条同时完成这两件事的流水线会调用 AesCode 32B 进行渲染，然后把生成的文件交给一个智能体去放置、接线并测试——而这两个产品本身都没有任何东西会阻止这一点，因为它们从来就不是在争夺同一个位置。

这场对决中，你今天就能预判的那一半

这里有一个值得直说的实际不对称。AesCode 32B 没有被任何推理服务提供商部署。Hugging Face 模型卡上没有列出任何托管端点、任何合作方，也没有 API；如果你想使用它，就得下载 65 GB 的权重，并自己搭建服务路径。这对研究发布来说是一种正常状态，同时也是横亘在模型与所有没有八块 GPU 的人之间的最大障碍。

Muse Code 的底层模型没有这个问题。Muse Spark 系列以纯 API 模型的形式提供服务，Muse Spark 1.2 已收录在 OrcaRouter 目录中，按 Meta 的标价计费：每百万输入 token 1.25 美元，每百万输出 token 4.25 美元——供应商标价原样透传，我们这边不加价，因此 Meta 一旦调价，这里当天就会同步。一个密钥即可将它与其他 200 多个模型一并调用，供应商出现波动时还能自动故障转移，这正是“我们可以试试”与“我们可以把它放到生产路径上”之间的差别。如果你真正想从这一页得到的，是一种无需采用 Muse Code 产品就能用上 Muse Code 内部智能的方式，那这就是那条路，而且它确实存在。如果你想要的是 AesCode 32B，那途径就是下载。

该选哪个

如果交付物本身才是重点，就选 AesCode 32B。你正在大批量制作演示文稿、报告、海报或仪表盘，你有硬件，或者愿意租用硬件，而一个能输出结构化、可编辑 HTML 的模型——表格就是表格，图表是 ECharts 规格，一切都能在 Git 中做差异对比——其吸引力值得你采用研究级的推理服务配置。要接受这一点：你是一个未公开宣布、下载量很小的模型的早期采用者，没有任何独立实验室复现过它的分数，而且它的 24K 上下文对长文档来说是一个实实在在的限制。

如果过程本身就是重点，就选 Muse Code。你想要的是一个在终端中运行、能在会话中途崩溃后存活下来、并且能在相互隔离的工作树中同时承载多条工作流的智能体，而且你愿意为此按 token 或按月付费。

如果真正想要的是一个靠 API 密钥驱动、能力出众的推理模型，而终端测试框架从来就不是你想要的部分，那就两个都别选，直接接入 Muse Spark 1.2。

什么会改变这个页面

三件事。如果某个推理提供商采用 AesCode 32B——或者 Microsoft 发布托管端点——部署这一栏就会塌缩，模型也会变成你用一个下午就能评估的东西，这会让问题对以设计为主的团队来说接近得多。如果独立评估复现了 85.89 的总体得分和 4.3% 的边界失败率，证据不对称就会显著缩小。而如果 Meta 开放 Muse Spark 权重，“你可以下载其中一个，却下载不了另一个”的说法就会彻底消失。在其中任何一件事发生之前，诚实的总结是：这两个产品共用一个词，而不是同一项工作。