RedNote 开放 dots3 note Preview，但其 Agent 能力仍需证明

RedNote 发布了 dots3 note Preview，总参数规模为 2800 亿，但每个 token 仅激活 160 亿参数。这一组合构成了这款开放权重模型的核心张力：其架构看起来相对经济，但其宣称的使命却覆盖了 AI 领域最棘手的一些问题。

该模型可接受文本、图像、视频和音频输入，并输出文本。RedNote 还宣称其上下文窗口可达 512,000 个 token。更重要的是，该公司将模型定位为面向长程 Agent 工作流，要求其具备工具使用、探索、记忆更新和适应能力。

这一雄心使 dots3 note 面临的不只是普通聊天模型的竞争。它挑战的是围绕大规模激活参数、独立感知模块和封闭式 Agent 平台构建的系统。不过，该版本仍被标记为 Preview，且大多数引人注目的性能数据均来自 RedNote 自身评估。

该模型是 dots3 系列首个开放权重成员。RedNote 称其为该系列中最轻量的选项，尽管下载和部署 2800 亿参数仍意味着可观的基础设施投入。

因此，真正的看点并不在于 RedNote 又发布了一款大模型，而在于稀疏激活、原生多模态输入和长上下文训练，能否打造出一个在数百步之后依然可靠的 Agent。

dots3 note 通过稀疏激活承载大模型

RedNote 正利用稀疏激活，将模型储存的知识容量与处理每个 token 所需的计算量分离开来。

根据官方模型卡，dots3 note Preview 是一款混合专家模型，通常简称为 MoE。MoE 模型包含许多专门化的参数组，但每个 token 只会被路由至其中一部分。

其语言组件总计包含 2800 亿参数，推理时激活其中 160 亿。这意味着，在处理任一给定 token 时，参与运算的语言参数不足 6%。其余参数仍被存储，并可供路由系统调用。

这一设计并不会让检查点变小。运营方仍须下载、分发并加载一组极为庞大的权重。稀疏激活主要减少的是每个生成 token 所执行的计算量，而非完整的内存和存储占用。

RedNote 还列出了一套拥有 70 亿参数的 MoE 视觉编码器，其中每次激活 12 亿参数。视觉编码器会将图像或视频帧中的像素转换为语言模型能够处理的表示形式。

这一组合之所以重要，是因为多模态系统通常只在语言模型内部部署最昂贵的路由逻辑。RedNote 则将专家路由同时应用于语言和视觉处理。该设计或许能为文档、图表、自然图像或界面截图分配不同的视觉专家。

该模型也支持音频，不过现有发布信息对这一输入路径提供的架构细节较少。它生成的是文本，而非图像、音频或视频。因此，“多模态”应理解为广泛的输入理解能力，而不是广泛的媒体生成能力。

RedNote 表示，该模型最多支持 512,000 个 token 的上下文。上下文窗口是指在一次模型会话中可供使用的输入和生成内容量。按这一规模，一次会话理论上可以容纳冗长的代码库、文档集合、转录文本或扩展的 Agent 历史记录。

最大上下文规格并不保证模型能在整个窗口内保持同等准确度。模型可以接受很长的序列，却仍可能忽略证据、混淆事件顺序，或遗忘埋藏在中段的指令。

同样的区别也适用于激活参数。与稠密的 2800 亿参数模型相比，160 亿激活参数能够减少算术计算量，但并不自动意味着它具备传统 160 亿参数检查点的延迟表现。

专家路由会带来处理器之间的通信成本。大规模模型权重也会对内存带宽提出要求，尤其是在专家分布于多个加速器时。部署效率将取决于软件支持、量化、批处理以及模型的路由模式。

RedNote 已通过 Hugging Face 发布权重，因此从技术上说可以进行独立测试。不过，“开放权重”并不必然意味着开发过程的每一部分都是开放的。

这些权重让研究人员能够检查输出、运行评估并构建推理集成，但它们并不提供完整训练数据集、所有过滤决策、后训练记录或每一条内部评估提示词。

对于 Preview 版本而言，这一区别尤为重要。开发者可以测试眼前的产物，但尚无法仅凭公开材料重建完整的开发过程。

RedNote 早期的公开工作提供了一些背景。其 dots.llm1 repository 记录了更早的语言模型系列，并强调经过精心处理的非合成预训练数据。该团队也在 dots3 之前发布过专用视觉和文档模型。

这些项目表明，dots3 note 并非一夜之间出自某个不知名实验室。不过，先前的发布不能验证这款模型关于 Agent、推理或长上下文能力的新主张。

眼下的变化很直接：RedNote 已将一款规模极大、采用稀疏激活的多模态模型交到公众手中。更艰难的工作如今将从发布宣传转向可复现的部署与评估。

512K 窗口本质上是一次 Agent 押注

512K 上下文上限之所以重要，是因为 RedNote 将 dots3 note 设计为在扩展任务中保留工作状态，而不只是总结大型文件。

长上下文已成为醒目的模型规格，但它的价值取决于模型如何使用这些 token。更大的窗口可以容纳更多信息，却仍可能做出薄弱的决策。

RedNote 表示，dots3 note 的目标是工具使用和多步骤 Agent 工作流。Agent 工作流让模型能够选择行动、检查结果、修订计划，并持续朝目标推进。

这一循环带来的负载不同于普通问答。一次聊天回复或许只需遍历一轮提示词；而一个 Agent 可能会累积数百条观察结果、工具输出、失败尝试和中间决策。

模型必须判断哪些早期事件仍然重要，也必须将可信指令与工具返回的不可信内容区分开来。更多上下文或许有帮助，但也扩大了错误和恶意指令能够隐藏的空间。

RedNote 特别强调涉及探索、记忆更新和适应的交互式任务。这些表述表明，其重点可能是那些在起点并无法看清正确计划的环境。

例如，一个编程 Agent 可能会检查代码库、复现故障、修改多个文件并运行测试。一个研究 Agent 则可能搜索文档、比较主张、追踪分歧，并修订自己的阶段性结论。

计算机使用 Agent 可以检查截图、阅读界面文本、聆听录制的指令，并通过工具执行操作。原生视觉和音频输入将减少对独立转录或图像描述服务的依赖。

这些场景解释了多模态架构与上下文上限为何属于同一产品叙事。Agent 会以多种格式接触信息，且它们的历史会随着每一次行动而增长。

但长历史会带来一项基本权衡：保留全部信息可以避免信息丢失，但也可能让决定性的观察结果淹没在无关细节中。

模型必须维持有用的内部层级。最新工具结果、最初的用户要求、安全边界和已确认事实，并不应获得同等对待。

在这里，512K 的规格不再只是一个简单的容量数字，而成为关于注意力分配、状态管理和指令稳定性的主张。

RedNote 的定位也给当前由多个专用服务组装 Agent 的开发者带来了压力。常见技术栈可能结合语言模型、OCR 系统、语音识别器、视觉模型、向量数据库和编排框架。

统一模型可以减少这些组件之间的交接。它可以直接针对原始图像或录音进行推理，而不是完全依赖有损的文本转换。

这种更简单的架构在真实负载下得到验证前，仍只是一种假设。专用组件可能更易于检查、替换或优化；在定义狭窄的任务上，它们也可能优于通用模型。

对于企业工作而言，答案的来源与上下文大小同样重要。处理大型内部档案的模型必须将结论关联到精确文档，并保留访问控制。

个人工作流也面临相似问题。收集文档很容易，真正困难的是在恰当时刻检索出正确证据。组织良好的AI knowledge base可以在模型的临时上下文之外提供持久检索能力。

即使拥有 512K token，这种外部记忆仍然有用。上下文窗口会随会话结束而失效，而持久知识系统能够保留来源、权限和可复用的结构。

因此，最强的 Agent 设计或许会结合两种方法。大窗口可以支持围绕当前活跃任务的即时推理；外部记忆则可保存经过验证的信息，并只检索下一步决策所需的材料。

RedNote 的押注是，一款能力广泛的模型能够以更少的脆弱边界协调这一过程。如果 dots3 note 能在长轨迹中保持目标，它或许能让 Agent 开发不再如此依赖激进的历史压缩。

如果它无法跟住指令，扩展窗口就会成为一个混乱流程的昂贵存储空间。独立的轨迹测试将决定哪种解读更准确。

稀疏专家挑战稠密模型路线

主要竞争并非 RedNote 与某一家公司的对抗，而是稀疏多模态模型与那些在每个 token 上投入更多计算的系统之间的较量。

稠密模型会为每个 token 激活几乎全部参数。它们的执行在概念上更简单，且在标准硬件上的表现可能更可预测。

MoE 系统在不激活整个网络的情况下扩展总参数容量。这可以增强专门化能力，同时将每 token 的计算量控制在总参数规模所暗示的水平之下。

对于 dots3 note 而言，最醒目的对比是 2800 亿储存语言参数与 160 亿激活参数。RedNote 实际上是在主张，广泛能力不需要在每一步都付出完整的计算成本。

这一论点对 Agent 尤为重要。单次回复可能包含数千个生成 token；而一个长时间运行的 Agent 在观察、规划、行动和修订时，能够生成和处理远多于此的内容。

这类轨迹中，微小的效率差异会不断累积。只要路由和内存开销仍受控制，每 token 更低的算术计算量就能降低重复推理的成本。

然而，稀疏模型并不会消除硬件要求。如此规模的全精度检查点超出了普通消费级系统的承载能力。即使是压缩版本也需要大量内存，而量化可能会改变输出质量。

最初的实际用户群将包括云服务商、研究团队以及拥有多加速器服务器的开发者。社区转换版本可能会扩大可用性，但这些转换版本需要单独验证。

此次发布也进入了一个其他开放权重开发者已采用稀疏激活的领域。DeepSeek 和多家中国模型实验室已经证明，庞大的总容量可以与较低的活跃计算量并存。

与此同时，闭源服务商可以围绕专有硬件、推测解码、缓存和模型路由优化完整的服务栈。即使客户无法查看底层权重，它们仍可能实现低延迟。

开放权重改变了竞争格局。开发者可以在自己的安全边界内托管模型，调整推理软件，并审查模型行为，而无需将每一条提示词发送到第三方 API。

这些优势也伴随着运营责任。团队必须管理模型文件、推理引擎、加速器分配、更新、监控和滥用控制。

闭源 API 隐藏了其中大部分复杂性。它也可以在不让客户访问底层检查点的情况下，改变行为、限制或可用性。

RedNote 提供的是另一种平衡。dots3 note 权重在部署层面提升了控制力和可审计性，而模型规模也提高了行使这种控制的成本。

其多模态设计带来了另一层竞争压力。许多智能体系统仍将截图交给一个模型、语音交给另一个模型、最终规划交给第三个模型。

一个能够理解这三者的单一模型，或许能在感知与规划之间保留更多信息。它可能发现那些在每种输入都被转化为独立摘要时消失的关联。

相反的观点是模块化。专用语音系统可以提供时间戳和置信度分数。文档解析器可以保留页面几何信息。视觉检测器可以返回精确坐标。

通用多模态模型可能生成流畅文本，却遗漏这些结构化信号。开发者应比较完整任务的结果，而不是只计算被移除的组件数量。

公开发布也让评估更加去中心化。研究人员可以测试陌生语言、特殊文档、长视频和私有领域的编程任务。

这种广度很有价值，因为基准平均分可能掩盖不均衡的表现。MoE 路由器可能将某些领域或语言分配给训练较少的专家。

因此，稀疏激活既可能带来专业化，也可能带来不一致性。两个表面相似的提示词可能会到达不同专家，并呈现不同的失败模式。

服务系统还必须在硬件之间高效部署专家。当被频繁选择的专家位于不同处理器上时，通信开销可能抵消一部分算力节省。

批处理又带来另一项复杂性。真实服务会同时处理许多用户的请求。它们的 token 可能选择不同专家，造成工作负载不均衡和容量闲置。

这些问题并不否定 RedNote 的方法。它们说明，“16B active”应被视为一个架构事实，而不是直接的低延迟保证。

竞争结果将取决于单位硬件资源所实现的性能。这包括首 token 延迟、生成速度、最大并发量、内存使用量，以及长会话中的可靠性。

如果 dots3 note 在这些指标上表现良好，它将强化面向多模态智能体的稀疏模型路线。如果部署仍然困难，即使 token 路由高效，总参数规模也会限制其采用。

基准测试缺口是最重要的细节

RedNote 发布了一款雄心勃勃的模型，但其最引人注目的推理和智能体主张仍需要独立复现。

模型卡是有用的披露材料，但它们仍是由模型开发者撰写的文档。它们可以描述评估设置，却不能替代中立测试。

这一问题在抽象推理领域尤其明显。社区讨论聚焦于 dots3 note 在 ARC-AGI-2 上报告的 81.4 分。

ARC-AGI-2 测试系统能否从少量视觉示例中推断变换规则，并将其应用于陌生任务。其设计者希望它能够抵抗记忆化知识，并奖励灵活推理能力。

配套的基准论文描述了一组扩展任务：人类可以完成，但 AI 系统难以应对。这使得高分格外值得注意，尤其是对于开放权重模型。

然而，截至发布时，官方 ARC 排行榜尚未提供经过独立验证的 dots3 note 条目。该排行榜还警告称，预览结果可能未经官方确认，或基于不完整测试。

这一缺口并不能证明 RedNote 的结果有误。它说明读者目前还不能将开发者报告的数字与经过验证的排行榜结果视为等价。

评估细节可能显著改变分数。提示词构造、采样预算、重试次数、工具访问权限、测试时计算量和答案选择都很重要。

对于面向智能体的模型，测试框架更为关键。基础模型在被封装进提供规划提示、外部记忆、代码执行或自我修正的系统后，表现可能不同。

RedNote 应发布足够的信息，让外部评估者能够复现其主要结果。这包括提示词、推理设置、工具权限、停止规则，以及每项任务允许的尝试次数。

长上下文主张也需要类似审视。能够接受 512,000 个 token 只是第一项测试。

评估者应测量跨不同位置的检索能力、远距离指令之间的冲突、排序准确性，以及上下文包含干扰信息时的表现。他们还应报告不同序列长度下的延迟和内存使用情况。

多模态评估不能只依赖图像问答基准。开发者需要知道模型能否跨格式连接证据。

一项现实测试可以将需求放在音频录音中，将错误放在截图中，并将相关实现置于代码仓库中。模型必须结合这三者，同时不能虚构缺失细节。

视频引入了时间推理。抽取少量帧可能会错过短暂事件，而密集采样可能迅速耗尽上下文窗口。

音频还涉及说话人分离、口音、背景噪声和精确引述等问题。模型可能理解大致主题，却听错决定正确行动的细节。

智能体测试则更为困难。传统基准通常只评估最终答案，但部署中的智能体可能在得出答案前就造成损害。

它可能覆盖文件、将信息发送到错误服务、遵从嵌入网页中的指令，或重复执行昂贵操作。仅凭成功率无法捕捉这些失败。

模型应接受提示词注入测试，即不可信内容试图重定向智能体的情况。长上下文和广泛的工具访问会增加此类指令可能出现的位置。

RedNote 的开放权重使安全研究人员能够在不依赖 API 访问的情况下进行这些测试。这是一项有意义的优势，但测试工作才刚刚开始。

软件工程提供了另一个有用的测试领域，因为任务具有可观察的结果。SWE-bench 框架从真实 GitHub 问题中提取任务，并检查生成的更改是否能解决这些问题。

即便如此，标题分数也需要结合背景理解。不同的智能体脚手架、代码仓库工具、计算预算和基准子集都可能产生不同结果。

最具参考价值的 dots3 note 评估，将在相同智能体框架下比较多个模型。这种设置能够从周边软件中分离出更多模型本身的贡献。

部署测量应与质量测试一同进行。一个能解决更多任务、却需要更多内存或时间的模型，未必能改善智能体服务的经济性。

Preview 标签给了 RedNote 迭代空间。它也提醒买家和开发者，不要将当前检查点误认为一个成熟的生产平台。

正确的态度既不是否定，也不是照单全收。该架构值得认真测试，因为它在一个公开模型中结合了多个相关理念。

这些主张值得谨慎对待，因为最重要的证据仍来自寻求采用的组织。可复现的评估将决定 dots3 note 是可信的智能体基础，还是一张等待确认的出色模型卡。

dots3 note 发布后值得关注的事项

三个信号将决定 dots3 note 是否成为重要的智能体模型：经过验证的评估、实用的服务支持，以及来自长期生产轨迹的证据。

第一个信号是独立复现基准测试结果。ARC-AGI-2 是最显眼的起点，因为社区讨论已经质疑 RedNote 报告结果的状态。

一份披露推理条件的经验证提交，将强化稀疏激活保留了高推理能力这一主张。若在中立测试下出现大幅下降，则会削弱这一结论。

ARC 不应孤立存在。独立团队应测试编程、工具使用、长上下文检索、视觉推理、音频理解和多语言表现。

他们应公布汇总分数和失败案例。智能体开发者需要了解模型如何失败，而不仅仅是它成功的频率。

第二个信号是主流推理系统的服务支持。当推理引擎能够高效路由专家、可预测地分配权重，并提供稳定的多模态 API 时，大型开放权重模型会更有用。

开发者应关注官方部署方案、量化检查点、硬件配置文件和可复现的吞吐量测量。如果输出质量在没有文档说明的情况下发生变化，社区格式本身并不够。

有价值的报告会区分总存储需求与活跃计算量。它们应说明加速器类型、精度、批次大小、上下文长度、首 token 延迟，以及每秒生成 token 数。

针对短提示词的测试不应被当作 512K 效率的证明。即使专家激活仍然稀疏，随着会话变长，注意力和缓存成本也会增长。

第三个信号是在完整智能体轨迹上的持续表现。这是最重要、也最难的测试。

一个令人信服的演示应展示模型完成许多真实任务，同时保持目标、遵守权限、从错误中恢复，并节约地使用工具。

一个经过精心打磨的示例价值有限，因为团队可以从多次尝试中挑选一次成功运行。评估者需要看到重复试验中的成功率分布。

他们还需要干预数据。人需要多频繁地纠正计划、批准高风险行动、重述指令，或恢复丢失的上下文？

记忆行为值得单独报告。一个有用的长期运行智能体应记住已确认的事实和已完成的行动，同时丢弃过时的假设。

仅仅重放完整记录并不够。系统必须区分持久知识、临时推理和不可信的工具内容。

评估 dots3 note 的团队应从受控任务开始。只读研究、代码仓库分析和文档比较能够提供有用证据，同时不会授予模型广泛权限。

随后，他们便可引入可逆操作、明确的审批关卡和详细日志。在系统展现出稳定行为之前，高影响力的外部操作应继续受到限制。

对开发者而言，此次发布带来了一个具体的评估机会。这些权重使人们能够研究一款原生多模态 MoE 模型，而不必完全依赖由供应商控制的端点。

对企业采购方而言，关键问题不在于 2800 亿这个数字是否足够庞大，而在于 160 亿活跃参数能否带来质量、延迟、可控性与运营成本之间的理想组合。

对知识工作者而言，实际问题在于：该模型能否在不丢失溯源信息的前提下，跨越冗长会议、文档、录音和任务历史关联信息。

更广泛的启示并不止于 RedNote。上下文容量、多模态输入和稀疏激活只是组成要素，并不能保证可靠的自主能力。

可靠的智能体还需要受约束的工具、持久记忆、来源追踪、权限边界，以及针对长序列行动的评估。

dots3 note Preview 将这些要素整合进了一个野心颇大的开放权重方案中。现在，它需要证明该方案能在 RedNote 自身的测试环境之外发挥作用。

未来三个月，请关注经验证的 ARC 结果、可复现的推理配置，以及大规模轨迹评估。这些信号要么将支持 RedNote 的效率论点，要么会揭示基准能力与可靠自主能力之间的差距。

开发者下载该模型时应制定明确的测试计划。将其与成熟基线进行比较，记录硬件使用情况，保留每一条操作轨迹，并对失败与成功同等评分。

dots3 note 的发布让 RedNote 的主张变得可检验。下一项重要公告不会是又一个参数规模，而应是独立证据，证明这款稀疏多模态模型能够在不偏离任务主线的情况下完成长期任务。