OpenRouter 上架后把 N2.5-mini 调成会干活的 Agent 调参实录【免费下载链接】Nex-N2.5-mini项目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2.5-mini自 Nex-N2.5 系列发布以来社区讨论最多的不是它又刷了多少分而是这套开源权重到底怎么接到自己的 Agent 流程里。2026 年 9 月初Nex-N2.5-mini 与 Pro 正式出现在 OpenRouter 的模型列表中让开发者不必自备两张 H100 就能调用这个 350 亿参数级别的多模态 Agent 模型。但能调用和会干活之间隔着一整套参数翻译与工作流适配。本文结合 OpenRouter 官方 API 能力清单与本仓库的 config.json、chat_template.jinja、README.md 源码从接入、Agent 化改造到成本控制给出可直接落地的调参方案。一、OpenRouter 接入模型 ID、端点与参数速览OpenRouter 为 Nex-N2.5-mini 提供了与 OpenAI 兼容的 Chat Completions 接口接入本身只有三件事Base URL、模型 ID 和鉴权头。端点与鉴权POST https://openrouter.ai/api/v1/chat/completions Authorization: Bearer $OPENROUTER_API_KEY Content-Type: application/json模型 ID 为nex-agi/nex-n2.5-mini。一个最小可用的请求如下curl -X POST https://openrouter.ai/api/v1/chat/completions \ -H Authorization: Bearer $OPENROUTER_API_KEY \ -H Content-Type: application/json \ -d { model: nex-agi/nex-n2.5-mini, messages: [ {role: user, content: 解释一下二分查找的工作原理} ] }从 OpenRouter 的模型元数据看这个模型的关键能力边界如下维度数值上下文长度262,144 tokens与仓库config.json中max_position_embeddings一致最大输出235,929 tokens输入模态文本 图像textimage - text词元器Qwen3思考档位high/medium/none官方默认high采样默认值temperature 0.7、top_p 0.95、top_k 40注意最后一行OpenRouter 侧的默认采样参数与 README.md 中官方推荐的temperature: 0.7 / top_p: 0.95 / top_k: 40完全一致说明 OpenRouter 的网关配置忠实还原了官方推理配置接入后无需担心平台侧偷偷改了采样。如果你更习惯自托管仓库给出了等价方案单节点2 × H100使用定制镜像nexagi/sglang:v0.5.18-nex-patch并指定--tool-call-parser qwen3_coder与--reasoning-parser qwen3两个关键启动参数。这两组参数是理解下文所有调参逻辑的钥匙。二、从聊天模型到 Agent函数调用与思考模式配置很多人在 OpenRouter 上把 N2.5-mini 当普通聊天模型用然后抱怨它不像个 Agent。问题不在模型而在调用协议。先看仓库里两个事实。架构事实config.json 显示该模型基于Qwen3_5MoeForConditionalGeneration架构256 个专家、每 token 激活 8 个40 层采用线性注意力与全注意力交替排布每 4 层插入一层 full attention并带一个 27 层的视觉编码器。这套混合注意力 稀疏 MoE的设计目标非常明确在 262K 长上下文下把 KV 开销压下来让 Agent 能长时间跑在真实环境里而不爆显存。它不是为单轮问答调教的而是为多轮工具调用 环境反馈调教的。协议事实chat_template.jinja 定义了这套模型的工具调用协议——模型产出的不是 OpenAI 风格的 JSON function call而是 XML 风格的tool_call块tool_call functionexample_function_name parameterexample_parameter_1 value_1 /parameter /function /tool_call模板中同时写明工具描述以tools列表形式注入 system 消息且函数调用必须遵循tool_call包裹function的嵌套结构参数必须完整给出。这意味着你在拼 prompt 时不需要额外教模型怎么调用工具只要把工具 schema 放进 system 消息模型天然按该协议输出。这里有一个 OpenRouter 上容易被忽略的差异点mini 模型的能力清单中没有声明tools/tool_choice参数对比同系列的 Pro 则支持。也就是说在 OpenRouter 上直接传 OpenAI 风格的tools数组可能被网关以 400 拒绝。稳妥的接入方式是把工具描述以 JSON 形式拼进 system 消息chat_template.jinja中tools块的渲染逻辑正是为此设计模型输出tool_call文本后由你的 Agent 框架解析执行再把执行结果以 tool 角色回合回填。底层 SGLang 的--tool-call-parser qwen3_coder会把模型输出的 XML 翻译成 OpenAI 兼容的tool_calls消息本地部署时你可以直接享受原生体验。思考模式的语义是第二个关键差异点。reasoning_effort控制三档行为其底层实现直接写在 chat_template.jinja 末尾reasoning_effort模式模板实际行为none非思考输出think\n\n/think\n\n跳过推理直接作答medium官方推荐默认自适应思考输出think由模型决定是否及思考多久high强制思考输出think\n强制开启推理模板逻辑显示只要不传reasoning_effort模型默认进入思考模式。而 OpenRouter 侧该模型的思考档位默认值是high——也就是说在 OpenRouter 上不显式传参等价于给每个请求强制开启深度思考。对聊天场景这或许无妨但在 Agent 循环里每个工具调用回合都走深度思考会显著放大延迟和成本。调参的第一个动作就是把reasoning_effort从不传变成显式传。下面是一个同时启用工具协议与自适应思考的完整请求骨架{ model: nex-agi/nex-n2.5-mini, reasoning_effort: medium, temperature: 0.7, top_p: 0.95, top_k: 40, messages: [ {role: system, content: # Tools\n\nYou have access to the following functions:\n\ntools[{\name\:\run_shell\,\parameters\:{\type\:\object\,\properties\:{\cmd\:{\type\:\string\}}}}]/tools\n\nIf you choose to call a function ONLY reply in the following format with NO suffix: tool_call...}, {role: user, content: 运行 pytest 并汇总失败的用例} ] }这套模型在 Agent 类基准上的表现印证了它为干活而生的定位Toolathlon Verified 54.6、BrowseComp 83.4、Terminal-Bench 2.1 73.4多模态侧的 OSWorld-Verified 71.2数据见 README.md。它强在工具调用稳定性与真实环境的长程执行而不是单轮问答的华丽程度——这也是社区测评反复强调的观点评估它要用 Agent 基准而不是通用问答榜。三、生产环境调参清单与 API 成本控制接入之后真正拉开差距的是参数策略。下面是基于官方能力清单整理的生产调参清单。1. 按任务类型分配思考档位简单问答 / 信息抽取reasoning_effort: none配max_tokens: 512。空思考直接作答延迟与成本最低。工具调用回合reasoning_effort: medium配max_tokens: 1024。工具调用回合的输出其实只有一段tool_callXML给长 token 预算纯属浪费。复杂推理 / 代码生成 / 长程执行reasoning_effort: high配max_tokens: 8192以上。2. 注意能力清单中没有的参数mini 模型未声明frequency_penalty/presence_penalty。如果你在网关层统一给所有模型加了这两个参数必须对 mini 去掉否则会收到 400该参数不被模型支持。同样地stream是独立于模型能力的通用控制项Agent 场景建议开启流式以降低首字节延迟。3. 让前缀缓存帮你省钱OpenRouter 为 mini 提供了输入前缀缓存价input_cache_read仅为每百万 token $0.0025是普通输入的十分之一。Agent 场景里 system 消息 工具定义是每个回合都重复的固定前缀把这两块放在消息数组最前面并保持逐字节稳定就能命中缓存。一次长程任务几百个回合跑下来这部分节省相当可观。4. 算清楚思考的账定价对比OpenRouter 公开价目项Nex-N2.5-miniNex-N2.5-Pro输入per 1M tokens$0.025$0.075输出per 1M tokens$0.1$0.25缓存输入per 1M tokens$0.0025$0.015一个典型工具回合2,000 输入 300 输出 token成本约 2000×$0.025/1M 300×$0.1/1M $0.00008。但如果默认档位是high模型在作答前先输出约 2,000 token 思考内容这些思考 token 全部按输出价 $0.1/1M 计费单回合成本暴涨到$0.00028约 3.5 倍。换算到每日数万次调用的 Agent 服务这就是默认参数和显式调参之间的月度账单差距。把思考档位显式设为none或medium是成本控制的第一杠杆。5. 错误码速查OpenRouter 网关对 mini 的错误语义400 为参数不被模型支持检查是否传了 penalty 或 tools401/402/403 为鉴权与额度问题404 为模型 ID 错误429 需退避重试502 为上游失败且不扣费——Agent 框架遇到 502 可以直接重试不用计入成本。收尾从能调用到会干活回到开头的问题为什么同一个模型有人觉得只是又一个聊天机器人有人却跑出了能稳定修 bug、跑终端、操作浏览器的 Agent差异全部藏在调用协议里。Nex-N2.5-mini 的chat_template.jinja已经把工具协议和思考开关写死在模板层你要做的只是显式声明reasoning_effort、把工具 schema 放进 system 前缀、按回合收紧max_tokens、让固定前缀命中缓存。做完这四件事OpenRouter 上的 N2.5-mini 才真正开始干活。【免费下载链接】Nex-N2.5-mini项目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2.5-mini创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考