WorkBuddy 免费接本地 Nex-N2.5-ProOllama 保姆级配置积分消耗直接打骨折【免费下载链接】Nex-N2.5-Pro项目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2.5-ProAI 智能体工具用起来顺手但顺手的代价往往是账单。以 WorkBuddy 为代表的一批编排类 AI 工作台把任务规划、工具调用、多轮交互全部交给云端大模型一次深度任务动辄消耗数万 token积分余额肉眼可见地见底。社区里最近流传开来的玩法是把 WorkBuddy 的推理层从云端摘下来挂到本地 Ollama 上——编排能力保持不变token 积分几乎归零。这套方案的可行性依据来自 Nex-N2.5-Pro 这类开源智能体模型的开放生态模型权重 Apache 2.0 开放、推理服务提供 OpenAI 兼容接口、工具调用协议标准化。本文结合 Nex-N2.5-Pro 仓库源码给出从原理到落地的完整配置路径。为什么免费成立编排层与推理层分离先拆解 WorkBuddy 这类智能体工作台的成本结构。它本质上是一个**编排层Orchestration 推理层Inference**的双层系统编排层负责理解用户意图、拆解任务、调度工具推理层负责真正生成文本与调用决策。默认配置下两层都在云端因此每一次思考、每一次工具调用的确认都要按 token 计费。本地接入的思路很直接——把推理层的 API 地址从云端服务商换成localhost。Ollama 从 0.1.27 起内置 OpenAI 兼容端点/v1WorkBuddy 这类客户端只需修改 base_url 与模型名即可完成切换编排层代码一行不用动。对大量任务拆解 工具调用确认的固定模式请求而言本地推理不消耗任何云端积分这就是打骨折的机制来源。Nex-N2.5-Pro 之所以适合做这套方案的模型底座从仓库 config.json 可以找到硬证据architectures为Qwen3_5MoeForConditionalGenerationmodel_type为qwen3_5_moe属于标准的 transformers 生态模型同时quantization_config显示权重已按compressed-tensors的 FP8_BLOCK 方案量化128×128 块、8 bit、group 粒度这意味着模型文件对显存和带宽的要求比 BF16 原版显著更低是本地可承载的前提之一。认识 Nex-N2.5-Pro它是为干活训练的在动手配置之前值得先明确接入的模型能带来什么。Nex-N2.5-Pro 是 Nex-N2.5 家族mini / Pro / Max中的多模态智能体档位仓库 README.md 的定义是 built for long-horizon tasks in real-world environments——面向真实环境中的长时程任务。它不只是会聊天而是把视觉变成了智能体感知与验证环境的接口操作电脑、浏览网页、执行并测试程序、通过视觉反馈自我纠错。从 config.json 可以看到它的体量与设计取向MoE 稀疏激活512 个专家、每个 token 激活 10 个配合共享专家shared_expert_intermediate_size在保持大容量知识的同时压低单 token 计算量60 层混合注意力layer_types中线性注意力linear_attention与全注意力full_attention按 3:1 交替线性注意力层显著降低长序列下的 KV 缓存开销256K 上下文max_position_embeddings: 262144长文档、长任务日志、多轮工具调用都能装进一次会话真多模态vision_config定义了 27 层视觉编码器patch 16、时间 patch 2processor_config.json中同时配置了图像处理器与视频处理器支持 2fps 采样、最长 768 帧即图像与视频都可作为智能体输入。性能方面README 给出了与当前头部模型的对照数据。只看 Pro 档的关键项Terminal-Bench 2.1 得分 82.7、SWE-Bench Pro 61.2、Toolathlon Verified 68.5、BrowseComp 89.7多模态与计算机操作维度OSWorld-Verified 82.2、OSWorld-G 87.4、WebArena-Verified 67.6、OmniDoc 92.2。这些数字说明它的强项正是边看边操作的智能体场景——和 WorkBuddy 的定位高度重合。值得强调的是它的工程化设计采样参数推荐temperature 0.7 / top_p 0.95 / top_k 40README 明确给出支持reasoning_effort三档思考模式none直答、medium自适应思考、high强制思考工具调用格式在 chat_template.jinja 中固化为tool_callfunction...parameter...的 XML 结构并支持多步工具调用multi-step tool。这些特性决定了它接入 WorkBuddy 后既能想、又能调工具。保姆级配置Ollama 部署与 OpenAI 兼容端点第一步环境准备Ollama 的部署目标可以是社区教程中常见的 ARM NPU 低功耗一体设备也可以是任何一台有 8GB 以上内存的 x86 机器。先完成基础安装# macOS / Linux 一键安装 curl -fsSL https://ollama.com/install.sh | sh # Windows 用户直接下载安装包或使用 WSL2 ollama serve # 确认服务默认监听 11434 端口第二步拉取模型对 WorkBuddy 的日常编排任务任务拆解、摘要、格式化、工具调用确认社区教程验证过的qwen2.5:7b与qwen2.5:3b是性价比很高的起点如果机器配置充裕、希望获得更强的智能体能力可进一步尝试 Nex-N2.5 系列的 GGUF 量化版mini 档或直接看下文第四节的 SGLang 方案ollama pull qwen2.5:7b ollama list # 确认模型已就绪第三步验证 OpenAI 兼容接口Ollama 启动后即暴露/v1兼容端点WorkBuddy 不需要任何 Ollama 私有协议适配curl http://localhost:11434/v1/models curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen2.5:7b,messages:[{role:user,content:ping}]}返回正常的 JSON 结构即表示本地推理链路已通。若希望局域网内的其他机器如另一台跑 WorkBuddy 的笔记本也能访问可将 Ollama 服务绑定到0.0.0.0并放行 11434 端口——但注意这只是内网玩具级配置公网暴露必须加反向代理鉴权。第四步WorkBuddy 切换后端在 WorkBuddy 的模型设置中新建一个自定义/本地供应商API Base URLhttp://localhost:11434/v1远程场景填http://内网IP:11434/v1API Key任意占位字符串Ollama 默认不做鉴权但客户端一般要求非空模型名qwen2.5:7b与ollama list中的名称完全一致切换后发起一个任务WorkBuddy 的编排层依旧运行但每一次推理都发生在本地云端积分不再随任务推进被扣减。升级路径真跑 Nex-N2.5-Pro 的 SGLang 方案如果对能力有更高要求仓库官方给出的 Nex-N2.5-Pro 部署方案是基于定制版 SGLang 的 Docker 镜像nexagi/sglang:v0.5.18-nex-patch单机 8×H100docker run --gpus all --shm-size 32g --ipchost \ -p 30000:30000 \ -v /path/to/your/model:/model \ nexagi/sglang:v0.5.18-nex-patch \ python3 -m sglang.launch_server \ --model-path /model \ --tp 8 \ --host 0.0.0.0 --port 30000 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --chat-template /path/to/nex-N2.5-Pro/chat_template.jinja \ --mamba-scheduler-strategy extra_buffer注意两个关键参数--tool-call-parser qwen3_coder开启函数调用解析对应 chat_template.jinja 中的tool_call输出协议--reasoning-parser qwen3将模型输出的think推理轨迹与最终回答分离WorkBuddy 拿到的是干净的最终结果。启动后同样暴露 OpenAI 兼容的/v1/chat/completions端口 30000在 WorkBuddy 中把 base_url 指过来即可接入逻辑与 Ollama 完全一致。对于算力有限的个人开发者mini 档只需 2×H100命令见 README.md是更现实的过渡选择。备用云端模型兜底而不破防本地推理并非万能极复杂的推理任务、多模态长视频分析或本地服务宕机时纯本地方案会露怯。合理的架构是本地优先、云端兜底WorkBuddy 主模型设为本地端点默认零积分在 WorkBuddy 的备用/降级配置中保留云端模型如云端 Nex-N2.5-Pro或你原本的付费模型日常任务全部走本地当任务超时、上下文超限或本地进程异常时WorkBuddy 自动降级到云端模型完成本轮任务。这样既能把 90% 以上的固定模式请求留在本地积分消耗大幅下降又在关键任务上保留云端大模型的完整能力。社区教程中同样建议保留这一层属于降本不降可靠性的标准姿势。MCP 扩展挂载与工具调用对齐WorkBuddy 的一大卖点是 MCP 工具生态——文件系统、浏览器、代码执行器等工具通过 MCP 协议挂载。要让本地模型真正会用这些工具关键不在 WorkBuddy 侧而在模型侧的协议对齐。Nex-N2.5 系列在这一点上做了原生适配chat_template.jinja 在 system 段注入完整工具清单tools块并把工具调用约束为tool_callfunction名称parameter参数名值/parameter/function/tool_call的严格格式且要求先自然语言说明再调用禁止调用后追加说明——这套规范与 MCP 工具的确定性调用需求完全匹配模板支持多轮 tool_response 回传tool_response包裹这正是 MCP 工具链中模型调用工具 → 工具返回结果 → 模型继续推理的循环骨架tokenizer_config.json 中chat_template内嵌了同一套逻辑保证 transformers 与 SGLang 两条推理路径行为一致。实操层面把 MCP 服务器如filesystem、playwright挂到 WorkBuddy 后在本地模型的采样参数中建议显式设置 README 推荐的temperature0.7, top_p0.95, top_k40避免高温度导致的工具调用格式漂移。若发现模型偶尔输出非结构化文本而不是tool_call优先检查本地服务的--tool-call-parser是否开启而不是怀疑模型能力。常见问题与避坑清单连不上本地端点确认ollama serve存活、端口未被占用远程访问场景确认防火墙与OLLAMA_HOST环境变量。上下文超限本地小模型3b/7b的上下文窗口远小于 Nex-N2.5 的 256K。长文档任务建议先做切片或摘要把完整文件喂给本地 7b 模型容易直接报错。工具调用格式错乱优先检查--tool-call-parser qwen3_coder与--reasoning-parser qwen3是否在启动命令中Ollama 路径下确认模型本身支持工具调用qwen2.5系支持原生 function calling。首次加载慢FP8 量化模型的冷启动需要把权重读入显存8×H100 部署 Nex-N2.5-Pro 时预留充足--shm-size个人设备第一次拉取 GGUF 也要耐心等待下载完成。免费的边界本地推理省的是云端 token 积分电费与硬件折旧是实际成本7b 档模型适合高频简单任务真正复杂的智能体任务仍建议按任务价值决定是否走云端备用模型。把 WorkBuddy 接到本地本质上是把按 token 付费的推理换成了一次性的硬件投入——对于每天高频使用智能体工具的用户这个置换几乎总是划算的。而 Nex-N2.5-Pro 这类 Apache 2.0 开源模型的存在让这条路径从妥协方案变成了能力增强方案256K 上下文、稀疏 MoE、视觉感知与原生工具调用协议恰好覆盖了编排型工作台对底座模型的全部核心要求。配置链路短、协议标准、源码可查剩下的就交给你的硬件了。【免费下载链接】Nex-N2.5-Pro项目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2.5-Pro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考