资讯详情

把 Atria Dawn 塞进 Codex CLI:config.toml 怎么写、400 报错怎么解,别再卡在 “not multimodal“

📅 2026/10/10 19:04:27 | 华诺云谱 👁 阅读
把 Atria Dawn 塞进 Codex CLI:config.toml 怎么写、400 报错怎么解,别再卡在 “not multimodal“
把 Atria Dawn 塞进 Codex CLIconfig.toml 怎么写、400 报错怎么解别再卡在 not multimodal【免费下载链接】Atria-Dawn-Preview项目地址: https://ai.gitcode.com/InternLM/Atria-Dawn-PreviewAtria Dawn Preview 发布后很多人的第一反应不是去看论文而是把它接进自己天天在用的编码 Agent——Codex CLI。理由很直接这是一款面向持续理解环境、调用工具、完成多步任务设计的智能体模型744B MoE 参数、256K 上下文正好是终端编程代理最缺的那种长程干活能力。但真上手时不少人卡在了同一个地方模型配置好了、Key 也填了一运行就弹400 Atria-Dawn-Preview is not a multimodal model。这篇教程结合官方仓库 README_CN.md 中的 Codex 章节把 config.toml、catalog.json 和 256K 上下文配置一次讲透附上可复现的完整配置帮你绕过这个坑。为什么 Codex CLI 会把纯文本模型误判成多模态先搞清楚 400 报错的根因否则你换再多的 base_url 都没用。Atria Dawn Preview 是一个纯文本输入模型。这一点在仓库里有多重证据模型架构 config.json 中没有任何视觉编码器配置只有标准的GlmMoeDsaForCausalLM文本解码器结构对话模板 chat_template.jinja 里甚至内置了兜底逻辑——当消息里出现image、video_url、audio等类型内容时模板会直接渲染成一句reminderYou are unable to process this image because you dont have multi-modal input ability./reminder也就是说模型侧对图片输入是礼貌拒绝而非理解处理。问题出在 Codex CLI 一侧Codex 默认假设每一个模型都支持多模态输入会把你通过-i/--image参数或 TUI 粘贴的图片附加进请求。纯文本端点收到图片后自然返回 400。所以正确的解法不是改 API而是在客户端声明模型的输入模态让 Codex 在发请求前就把图片剔除。第一步config.toml 自定义 providerCodex 的自定义模型接入点在~/.codex/config.toml。官方文档明确说明Codex 使用 Responses API 与 Atria 通信不是 OpenAI 的 Chat Completions所以wire_api必须显式声明为responses。model Atria-Dawn-Preview model_provider atria [model_providers.atria] name Atria base_url https://api.atria-asi.ai/v1 env_key ATRIA_API_KEY wire_api responses四个字段各司其职nameprovider 的显示名只影响 Codex 界面展示。base_urlAPI 根地址。国内地区对应discovery.intern-ai.org.cn的 Token 计划端点海外对应https://api.atria-asi.ai/v1。注意末尾的/v1不能省——Codex 会在其后拼接 Responses API 路径。env_keyAPI Key 的环境变量名。这里填的是变量名而不是密钥本身Codex 运行时从环境中读取。设置方式export ATRIA_API_KEYatr_xxxx国内 Token 计划的 Key 前缀是atr_在控制台创建时只会完整显示一次务必及时保存。wire_api responses协议声明写错会导致 Codex 用错误的路径发请求。第二步catalog.json 声明 text-only绕开 400保存下面内容为~/.codex/atria-catalog.json核心就是input_modalities: [text]{ models: [ { slug: Atria-Dawn-Preview, display_name: Atria-Dawn-Preview, base_instructions: 你是运行在 Codex CLI 中的编程代理。你将在共享工作区中与用户协作完成软件工程目标。\n\n你只能接收文本输入。你无法获取图片、截图、PDF 或其他二进制附件。如果用户提到你无法查看的附件请直接说明这一点并要求用户粘贴相关文本。, supported_reasoning_levels: [ { effort: low, description: 快速响应使用较轻量的推理 }, { effort: medium, description: 在速度和推理深度之间保持平衡 }, { effort: high, description: 为复杂问题提供更深入的推理 } ], shell_type: unified_exec, visibility: list, supported_in_api: true, priority: 1, support_verbosity: false, truncation_policy: { mode: tokens, limit: 10000 }, experimental_supported_tools: [], context_window: 256000, max_context_window: 256000, input_modalities: [text] } ] }三个关键点对应社区里流传最广的几个坑1.input_modalities是开关本体。声明[text]之后Codex 会在客户端直接移除图片输入请求根本不会带图400 自然消失。2. 其他字段一个都不能少。catalog 文件的解析器要求所有字段必须存在缺任何一个都会报missing field name并导致 Codex 无法启动。社区教程里最常见的翻车点就是把 catalog 精简成只有slug和input_modalities两三个字段——精简版必然启动失败。3.model_catalog_json是替换不是合并。官方文档特别强调这个文件会替换整个模型目录未列在其中的模型会回退到默认元数据即假设支持多模态并打印warning: Model metadata for slug not found。如果你用-m切换模型新模型也必须写进同一个文件否则纯文本限制不会生效。第三步context_window256000 与可复现的完整配置把context_window/max_context_window设为 256000 不是拍脑袋——这正是该模型的真实上下文上限仓库 README_CN.md 的模型表中明确标注 256K。Codex 会基于这两个值做两件事规划提示词预算和判断何时自动压缩上下文。如果不设置Codex 回退到保守默认值白白浪费可用的上下文空间——对一款主打长程 Agent 任务的模型来说这等于自废武功。最终的可复现配置如下对应 README_CN.md 中的 Codex 完整示例model Atria-Dawn-Preview model_provider atria model_catalog_json ~/.codex/atria-catalog.json [features] view_image false [model_providers.atria] name Atria base_url https://api.atria-asi.ai/v1 env_key ATRIA_API_KEY wire_api responses其中features.view_image false是可选但强烈推荐的它会移除图像查看工具避免模型尝试调用一个注定被拒绝的工具从工具层面彻底堵死多模态路径。版本硬性要求Codex CLI ≥ 0.154.0。低于此版本不支持model_catalog_json与模态声明机制配置会静默失效或直接报错。先跑codex --version确认再继续配置。排障速查从 400 到 401/404把常见报错和对应动作列成清单方便对照症状根因动作400 ... is not a multimodal modelCodex 默认附加图片输入catalog.json 声明input_modalities: [text]missing field namecatalog.json 字段不完整补齐全部必填字段不要精简Model metadata for ... not found切换了 catalog 中未列出的模型把所有在用模型都加进同一文件401 鉴权失败ATRIA_API_KEY未导出或名字不匹配核对env_key与 shell 环境变量名一致404 路径错误base_url缺少/v1或wire_api写错补全/v1确认wire_api responses上下文很快被截断context_window未设置设为 256000补充这些配置为什么和模型本体对得上整篇配置不是玄学仓库里的模型文件把每个数字都钉死了。context_window对应 README_CN.md 模型表中的 256K模型的 744B MoE 结构在 config.json 里清清楚楚——78 层、256 个路由专家n_routed_experts: 256、每 token 激活 8 个专家num_experts_per_tok: 8、位置编码上限max_position_embeddings: 10485761M服务端按 256K 开放权重文件 model.safetensors.index.json 记录了 353 个分片、约 1.5TB 的 BF16 全量参数。生成参数方面generation_config.json 采用temperature: 1.0、top_p: 0.95单次输出上限 65,536 token——这也是 README_CN.md 中 Kimi Code 示例把max_output_size设为 65536 的原因。如果你后续还要把 Atria Dawn 接到 Claude Code 或 Kimi Code思路完全一致Claude Code 用 PreToolUse 钩子拦截 Read 工具的图片/PDF 读取Kimi Code 用capabilities [tool_use, thinking]显式声明能力并禁用image_in。它们的共同点只有一个纯文本模型必须由客户端主动声明模态而不是指望服务端宽容处理。把 config.toml、catalog.json 和 256K 上下文这三件套配齐Atria Dawn 就能在 Codex CLI 里稳定地长程干活了。【免费下载链接】Atria-Dawn-Preview项目地址: https://ai.gitcode.com/InternLM/Atria-Dawn-Preview创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑