企业官网建设流程全解析

Atria Dawn接入实录：400报错、上下文截断、配额共享，这些坑我都替你踩了

【免费下载链接】Atria-Dawn-Preview项目地址: https://ai.gitcode.com/InternLM/Atria-Dawn-Preview

上海人工智能实验室开源的 Atria Dawn Preview，是近期智能体模型里关注度最高的一张牌：744B MoE 参数、256K 上下文、MIT 协议开源权重、注册即送 1 亿 token 免费额度，官方公布的 16 项基准里有 5 项登顶（AutomationBench 53.8、BFCL v4 77.0、CyberGym 86.5、DeepSearchQA 96.0、BrowseComp 92.5）。它天然适合接进 Codex、Claude Code、Kimi Code 这类终端 Agent 工具当"长程任务引擎"。

但免费额度从来不是接入的门票，报错才是。过去两周社区里最密集的讨论，几乎都围绕三件事展开：400 Atria-Dawn-Preview is not a multimodal model到底怎么消掉、finish_reason=length时怎么分辨是输出被截断还是上下文被写满、以及 401/404/429 这些状态码背后那条"账户级配额共享"的暗线。这篇文章把这三个坑的成因、复现路径和官方/源码层面的解法逐一拆开，配置清单可以直接照着抄。

接入前，先摸清这个模型的"脾气"

Atria Dawn Preview 基于 GLM-5.2 基座训练，仓库里的 config.json 写得很清楚：n_routed_experts: 256（256 个路由专家）、num_hidden_layers: 78（78 层）、hidden_size: 6144，模型类型是glm_moe_dsa。它的定位不是聊天模型，而是"把开放问题推进为可执行、可验证结果"的智能体底座——检索证据、调工具、写代码、跑实验、根据反馈恢复失败，这是它最强的区间。

两个容易被忽略的"性格特征"决定了后面所有报错的走向：

• 它是纯文本模型。图片、PDF、截图一律喂不进去。虽然 tokenizer_config.json 里定义了<|begin_of_image|>这类多模态占位 token，chat_template.jinja 中也存在媒体输入的处理分支，但那只是在媒体消息混入时渲染一句<reminder>You are unable to process this ... because you don't have multi-modal input ability</reminder>的兜底提示——服务端是实打实没有多模态能力的。
• 256K 是"总预算"而非"单次输出上限"。官方 API 明确：256K 上下文窗口同时容纳输入和生成内容，系统指令、历史对话、文档摘录、工具返回结果全部占用输入空间；而单次请求的输出上限只有 65,536 token，且这个上限由三套 API 各自的参数控制（Chat Completions 的max_completion_tokens/max_tokens、Messages 的max_tokens、Responses 的max_output_tokens）。

模型在"带着工具跑长流程"的基准上一串第一，但在纯编码类任务（SWE-bench Pro 59.6、JobBench 50.3）上与顶尖商用模型仍有明显差距。这个强弱分布决定了它适合当"免费的长程 Agent 引擎"，而不是拿来硬刚核心代码编写。

坑一：400 "is not a multimodal model"，是客户端的"身份误判"

这是接入 Codex 时命中率最高的报错，完整信息是400 Atria-Dawn-Preview is not a multimodal model。

成因在仓库的 README.md 里写得非常直白：Codex 默认假设每个模型都支持多模态，会把你通过-i/--image或 TUI 粘贴的截图自动附加到请求里，而 Atria 端点只收文本，于是直接拒绝。换句话说，报错发生在"客户端主动塞图"这一侧，不是模型本身坏了。

规避方法是在客户端声明模型的身份——给 Codex 建一个 model catalog 文件，把input_modalities显式声明为["text"]：

{ "models": [ { "slug": "Atria-Dawn-Preview", "display_name": "Atria-Dawn-Preview", "base_instructions": "You are a coding agent running in the Codex CLI. ... You can only receive text input. Images, screenshots, PDFs, and other binary attachments are not available to you.", "supported_reasoning_levels": [ { "effort": "low", "description": "Fast responses with lighter reasoning" }, { "effort": "medium", "description": "Balances speed and reasoning depth" }, { "effort": "high", "description": "Greater reasoning depth for complex problems" } ], "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"] } ] }

然后在~/.codex/config.toml里指向它，并按需关掉图像查看工具：

model = "Atria-Dawn-Preview" model_provider = "atria" model_catalog_json = "~/.codex/atria-catalog.json" [tools] view_image = false [model_providers.atria] name = "Atria" base_url = "https://api.atria-asi.ai/v1" env_key = "ATRIA_API_KEY" wire_api = "responses"

这个配置里有三个隐性要求，缺一个都会翻车：

1. catalog 字段一个都不能少。解析器要求全部字段存在，少任何一个都会报missing field <name>，Codex 直接无法启动。
2. model_catalog_json是"替换"不是"合并"。任何没写进这个文件的模型都会回退到默认元数据（默认假设多模态），并打出一条warning: Model metadata for <slug> not found。如果后续用-m切换模型，必须把它也加进同一个文件，否则纯文本限制对它不生效。
3. Codex 版本要 ≥ 0.154.0，view_image的字段位置随版本变化（旧文档是[features] view_image = false，新版本在[tools]表下），先codex --version确认再抄。

Claude Code 走的是另一条路：它通过 Messages API 接入，官方给出的方案是一段PreToolUsehook 脚本（README.md 中有完整实现），在Read工具层面把图片和 PDF 的读取请求直接 deny 掉，让模型永远接触不到二进制附件。注意这个 hook 只拦截Read工具的按扩展名读取，粘贴/上传的图片、@file引用、Bash 输出都不在覆盖范围内——最稳妥的做法仍然是在外部做 OCR 或文本抽取，把文本粘进去。

Kimi Code 的坑则在capabilities声明：capabilities = ["tool_use", "thinking"]里不能出现image_in，加了就会复现同一个 400；同时thinking必须显式声明，否则 effort 被强制为 off，推理能力静默失效——这是比 400 更隐蔽的"不报错但功能没了"。

坑二：finish_reason=length，先分清是"输出截断"还是"输入超窗"

长程 Agent 跑到一半，响应戛然而止，翻 usage 日志发现finish_reason=length。这个现象在社区排障里被反复讨论，但很多人第一步就走错了方向——直接去改上下文，结果问题依旧。

排障的正确顺序，是先搞清楚"是哪个长度撞了上限"。Atria 的 256K 上下文是输入+输出的总预算，而单请求输出上限是65,536 token，两者是完全独立的两道闸门：

• 输出闸门：max_tokens相关参数（Chat Completions 用max_completion_tokens或max_tokens，Messages 用max_tokens，Responses 用max_output_tokens）只接受 1–65,536 的整数。finish_reason=length表示生成在到达这个上限时被强制停止。Kimi Code 的典型案例是：配置里漏写max_output_size，Kimi 会把max_context_size（256000）原样发到线上，Atria 直接以 400 拒绝（合法范围 1–65536）；补上max_output_size = 65536才能让"输出上限"这个语义真正生效。
• 输入闸门：系统指令、历史对话、文档摘录、工具返回结果，全都在占用 256K 的输入空间。长文档 + 多轮工具调用 + 大段工具输出，几轮下来输入空间就会被写满，此时模型被迫丢弃早期上下文，行为表现就是"模型忘了任务开头"。

区分这两类问题的抓手是三套 API 各自暴露的字段——这也是"一个模型 ID、三套 wire API"最容易埋雷的地方：Chat Completions 的结束原因是choices[0].finish_reason，Messages 是stop_reason，Responses 是status；token 用量在 Chat Completions 是usage.prompt_tokens / completion_tokens，另两套则是input_tokens / output_tokens。解析错字段，等于排障时瞎了一只眼。

社区里验证可行的长程排障流程，核心就四点：

1. 用非流式请求拿完整响应。流式场景下 usage 在流结束时才对账，中途看到的统计是不完整的，拿它判断截断位置会失真。
2. 先读结束原因，再读 usage。finish_reason=length+completion_tokens接近 65536，是输出超限；finish_reason=stop但任务明显没完成，才是输入空间被占满导致上下文丢失。
3. 按轮次记录 usage，做增量定位。每轮调用结束后把input_tokens/output_tokens落日志，观察"上下文增长曲线"，比事后翻总账精准得多。
4. 对工具返回做截断与摘要。长程 Agent 里最大的上下文吞噬者是工具输出，社区实践是"工具返回截断 + 状态摘要 + 预算控制"三件套，配合重试退避，把非模型侧的消耗压下来——256K 上下文再大，也扛不住每轮都往对话里塞几十 KB 的原始日志。

值得注意的一个底层事实：模型架构本身支持 1,048,576 的位置编码（见 config.json 的max_position_embeddings与 tokenizer_config.json 的model_max_length），但当前线上服务以 256K 上下文对外提供。也就是说，上下文不是"给了你 256K"，而是"现阶段只开放 256K"，把它当成硬上限来规划任务，而不是当成可以试探的资源。

坑三：401/404/429 与配额共享，报错码背后的同一条暗线

长程任务烧到中段突然 401，第一反应是"密钥过期了"？未必。官方文档给出的状态码语义很明确，而社区里把这些码的根因串起来之后，会发现它们指向同一条管理规则：限速与配额是账户级的，不是 Key 级的。

每个账户有一个每分钟请求总数上限（RPM），由该账户下所有 API Key 共享，并且三套 API（Chat Completions、Messages、Responses）共用一个额度池。超限返回 429，响应头带Retry-After、x-rpm-limit: 60、x-rpm-remaining，限额在固定分钟边界重置。

这意味着：开了三个 Key、分别喂给 Codex 和 Claude Code，它们是在抢同一个杯子里的水；一个 Key 上的突发流量，会连坐另一个 Key 上的正常任务。调试时如果同时开着多个终端工具，先想想是不是"自己打满了自己的账户"。

把官方语义和社区观察汇总成一张对照表：

两个最容易误判的点：

• 400 不是一种病，是两种病。它既可能是"多模态违规"，也可能是"输出参数越界"。看错误信息文本能直接区分——前者含is not a multimodal model，后者会带合法范围提示。Kimi Code 那个max_output_size缺失的案例，报的就是后一种 400，但很多人在第一种的解法里找答案，自然无解。
• 404 大概率是"身份"问题而不是"网络"问题。Atria-Dawn-Preview这个 ID 大小写敏感，atria-dawn-preview或Atria-Dawn都查无此模型；base_url忘记带/v1时，请求会落在不存在的路径上。这类错在社区 401/400/404 定位实践中占了大头，排查优先级应该高于怀疑服务端。

最后补一条关于"配额"的预期管理。社区实测数据显示，智能体类任务的 token 消耗是聊天界面的几十倍：一次代码库深度扫描，116 次调用消耗约 12.7 万 token，含重试总计约 17.4 万。1 亿免费额度按"聊天"估会觉得用不完，按"Agent 干活"估才刚好够跑几百次深度任务。所以长程任务里，usage 监控不该是可选项，而应是接入的第一优先级配置——把 README.md 接入章节完整读一遍，比翻遍全网排错帖省下一整个下午。

一张避坑清单

• 接入前先确认三件事：模型纯文本、256K 是输入+输出总预算、单次输出上限 65,536；
• Codex 必须用 catalog 文件声明input_modalities: ["text"]，字段全量、版本 ≥ 0.154.0、catalog 是替换不是合并；
• Claude Code 用 PreToolUse hook 拦掉图片/PDF 读取，但别指望它拦截粘贴和 Bash 输出；
• Kimi Code 必须写max_output_size = 65536和capabilities = ["tool_use", "thinking"]；
• 看到finish_reason=length，先读结束原因字段和 usage，再决定是调输出上限还是压缩上下文；
• 401/404 先查 Key 和模型 ID 大小写，429 先想到"账户级配额被自己别的 Key 共享消耗"；
• 长程任务坚持非流式验证 + 分轮 usage 日志 + 工具返回截断，把上下文和配额都当成需要治理的资源。

【免费下载链接】Atria-Dawn-Preview项目地址: https://ai.gitcode.com/InternLM/Atria-Dawn-Preview