AREX Feed Article
上海人工智能实验室开源 Atria Dawn Preview：744B 参数 MoE 底座、256K 上下文
9 月 14 日 13:30 UTC，X 账号 宣布 Atria Dawn Preview 上线，称它是「为长程任务构建的 agentic 基础模型」，帮研究者与工程师把开放式问题变成可执行、可验证、可复现的结果，并给出官网、GitHub、Hugging Face、ModelScope 与 API 入口。31 分钟后，用同一批 GitHub、Hugging Face、官网与 API 地址宣告它上线；该账号简介写着 OpenBMB（Open Lab for Big Model Base）的目标是构建面向 AGI 的基础模型与系统。
按 与 的说明，Atria Dawn Preview 由上海人工智能实验室开发，建在 744B 参数的 MoE 底座 GLM-5.2 上，支持 256K 上下文，代码与权重以 MIT 许可发布。新的是公告，文件更早就位：GitHub 的仓库接口显示该仓库创建于 2026-09-12 10:32 UTC，创建于同一天 07:14 UTC，都比公告早两天。
发布账号与文件日期
发帖的 @AtriaASI 创建于 2026-09-08 07:41 UTC，账号页面未填写简介，检索时关注者 3,492 人、关注 5 个账号，带蓝标认证。它的发布帖在 9 月 15 日检索时显示约 283 万次浏览、2,257 次点赞；OpenBMB 的帖子当天浏览 74,209 次。
仓库里除中英双语 README 外，还有一份 23 页的，PDF 元数据显示生成于 2026-09-14 15:28 UTC；Hugging Face 模型卡的页面元数据日期是 2026-09-13。GitHub 仓库在公告之后的 9 月 15 日仍有新的推送。
公告发出后，官方账号当天 18:26 UTC 发了一批，覆盖研究、创作、交付与网络安全；23:43 UTC 的 讲解它做深度研究的方式：拆解研究目标、检索并评估来源、跨来源追踪证据，输出可引用、可验证的结论。9 月 15 日 11:36 UTC 又发了 。这些演示视频均由发布方自己提供。
两个可下载版本、四类任务，以及一个纯文本限制
模型卡把 Atria Dawn Preview 描述为上海人工智能实验室「新一代 agentic 模型的预览版」，面向需要持续环境理解、工具使用与多步任务完成的科研和工程场景。技术报告在写明这个 744B 参数的 MoE 底座时，引用的是 Z.ai，并给训练方法起名 Verifiable Experience Pipeline。仓库列出两个可下载版本：Atria-Dawn-Preview 与 FP8 量化的 Atria-Dawn-Preview-FP8，上下文都是 256K；ModelScope 的元数据把架构记为 GlmMoeDsaForCausalLM，许可字段是 mit。
能力被分成四块：Discovery 负责检索与整理证据、做深度研究、把研究问题变成可执行的实验方案；Creation 负责软件、交互应用、游戏、数据可视化与机器学习系统；Delivery 把文档、数据和设计需求变成报告、演示文稿等结构化交付物；Cybersecurity 在授权环境中分析安全问题、验证漏洞、修复并复验。
这个模型只接受文本输入。模型卡专门提醒，默认情况下 Codex 会按多模态模型处理，把图片附件一并发出，端点会返回 400，提示「Atria-Dawn-Preview is not a multimodal model」，因此要单独写一份模型目录文件声明模态，让客户端在本地剥掉图片；文档还附了一段 PreToolUse 钩子脚本，用来在 Claude Code 里拦截 PDF 与图片的读取。
接入有两条路：与 在线可用，代码和权重也能下载后本地部署。写明 API 支持 Chat Completions、Messages 与 Responses 三种形式，用 Google 账号登录控制台创建 API Key，并给出 Claude Code、Codex 等客户端的接入步骤。
自报分数：16 项里 5 项最高，写代码和交付落后
模型卡与技术报告里的表格覆盖 16 项基准。报告的表格注明这些成绩来自官方发布页面，即发布方自行组织、刊登在官方发布页面上的评测，并称 Atria Dawn Preview 在其中 5 项上取得最高分、另 3 项为第二高。
拿最高分的五项是 AutomationBench 53.8、CyberGym 86.5、BrowseComp 92.5、DeepSearchQA 96.0 与 BFCL v4 77.0。按报告自己的口径，AutomationBench 领先第二名 Qwen 3.8 Max 4.1 分，CyberGym 比 GLM 5.3（84.5）高 2.0 分，BFCL v4 比 GLM 5.3（74.1）高 2.9 分。三个差距较小的第二名是 SkillsBench（66.4，差 0.3 分）、Workspace-Bench（65.0，差 0.8 分）和 Workspace-Bench-Lite（68.2，差 1.9 分）。
同一张表里，编码与交付类基准落后于该行最高值：SWE-bench Pro 59.6，对 Claude Opus 5 的 74.7；Terminal-Bench 2.1 为 78.3，对 90.2；GDPval 是 1,583 对 1,768；JobBench 是 50.3 对 68.0；τ³-Bench Banking 为 41.2，低于 Qwen 3.8 Max 的 55.2，也低于 Claude Opus 5 的 48.7。报告自己写，GDPval 与 JobBench 这类把通用 agent 能力迁移到长程专业工作的场景「仍有最明显的空间」。
表格里的短横线表示该项没有报告成绩，报告声明不把缺项当作 0 分。附录列出每项基准的执行细节，包括 harness、时限和裁判模型：DeepResearch Bench II 用 GPT-5.5 作裁判，每个结果取三次独立打分的平均；GDPval 用 glm-5.3 做两两比较；JobBench 用 Grok-4.3；SkillsBench 跑的是排除多模态任务后的 79 题子集，分数取三次运行平均；Terminal-Bench 2.1 每个模型跑四次取平均，报告写明对比中的 Claude Opus 5 配置在一部分任务上回退到 Opus 4.8，GPT 模型有一部分任务因其内置安全策略被拒答。
表内分数目前只能回溯到发布方：模型卡、GitHub 仓库与技术报告引用的是同一个官方发布页面。本文 9 月 15 日检索到的第三方内容以单任务演示为主，没有对表内数字的独立复测。
案例数字里，厂商自己标注的保留
报告用一节列出选定案例，并逐个标注哪些数字不能当成绩读。
天气预报案例从数据处理走到训练：在关闭网页搜索的条件下处理 100 GB 以上气象数据，实现一个 4 亿参数以上的视觉 Transformer，训练 45,000 步，建模 69 个气象变量。报告同时注明，配图里的预报界面「不报告预报准确率」。
Gated Delta Network（GDN）解码优化案例里，模型先做实现改动再看性能测量，识别出启动开销后把实现从 Triton 换成原生 CUDA，再针对测得的速度回退调整配置。开发测量给出 1.46 倍的延迟比（七个代表性批量上基线之和与候选实现之和）；到公布的轨迹结束时，54 个正式负载过了 52 个，没有完整的正式均值。报告因此写明，这 1.46 倍是开发中的比例，不是最终基准分数。
MiniOS 案例从空工作区开始，约 20 分钟搭出带串口 shell、磁盘访问、持久化文件系统和解释器的系统，并在两次 QEMU 会话之间检查持久化状态与自动运行。CAD 演示包括四缸发动机、人形机器人、机械关节与火箭的装配模型，报告注明这些视图「不是机械或制造验证」。报告在小节开头写明，这些是挑出来的演示，不是对平均任务成功率的估计。
上线之后：转述、上手试用与分数的出处
9 月 15 日，中文 X 上出现一批介绍 Atria Dawn Preview 的帖子，其中不少共用同一组说法。较完整的一篇是 ，它复述了四个能力方向、256K 上下文、纯文本限制与「模型 + Harness（负责上下文、权限与错误恢复的运行层）+ 环境」的分工，并给出团队构成的说法：96 名主要成员中 65 名在校生，另有 31 名正式员工。这个数字没有出现在模型卡、GitHub 仓库说明或技术报告里：报告按姓氏字母排列贡献者名单，未附单位，通讯邮箱使用复旦大学域名。
上手类帖子多为单任务演示。称他把模型接入 Codex 做了两项测试：用两张 CSV 在 8 分 54 秒内生成核对工具与报告，11 项测试全部通过；另一个任务产出 12 页 PPT，含两张统计图。称他在 Claude Code 里用一个真实研究任务测试，结论是「结果有希望，但仍是早期预览」。称他给模型出了一道「雨夜书房」的题，并把过程与项目开源；的帖文写明，是朋友请他帮忙测评该模型的长程任务能力。
同一个账号 在 9 月 15 日上午 8:48 和 10:57 开头与措辞高度相似的帖文，点赞数分别为 2 和 1。可核对的采用信号仍然有限：同日 GitHub 仓库有 244 个 star、9 次 fork、1 个未关闭 issue，ModelScope 显示 211 次下载。
随模型一起发表的研发记录：769 条任务、56 名参与者
技术报告除模型之外，还交出一份关于自己怎么被造出来的记录。它统计了 769 条任务记录和 56 名参与者的 agent 日志：739 条对是否使用 AI 有明确回答的任务里，713 条（96.5%）用到了 AI。
在 455 条完成的 AI 辅助任务中，151 条（33.2%）被参与者判断为在同等任务范围与资源约束下没有 AI 就不可能完成，这些任务来自 56 人中的 27 人。决策层面，567 条有记录的方法与决策里 AI 提出 64.6%，人类最终拍板 85.5%；目标与范围类的决定中人类最终决定占 93.4%，验收标准占 81.9%，AI 自己最终决定的比例在 6.1%～9.2% 之间。
报告还统计了困难出现后的推进方式：在 588 条记录了最棘手困难的任务里，76.0% 靠人的介入推进，23.0% 由 agent 自行恢复，1.0% 始终没有解决；人的介入里，补充上下文或澄清需求占 35.2%，诊断问题或更换方法占 34.7%，直接改稿 3.2%，接管 0.7%。
另一组数字关于监督能力：8 月 7 日到 9 月 4 日，同一批 22 名参与者每天「agent 动作数 ÷ 人工提示数」的中位数从 11.0 升到 28.5，同期四分位距扩大，说明这一变化在参与者之间并不均匀。这些记录与分析都来自项目组自己，不是外部审计。报告引用他人的研究写道，当研究者连 AI 工作的最终结果都无法评估时，监督就变得不可能；它把「决定权留在人手里，但每个决定背后是更长的、单个人难以逐条检查的工作链」列为待解的问题。