Meet OpenJarvis：一个本地优先的设备端个人AI智能体框架，支持工具、记忆与学习

斯坦福大学和 Lambda Labs 的研究人员发表了 OpenJarvis 的研究论文，这是一个完全在设备端运行推理、智能体、记忆和学习的开源框架。

通过 OpenJarvis 配置的开放权重模型平均与最佳云端模型的差距在 3.2 个百分点以内，在该研究的基准测试协议下，每次查询的边际 API 成本约低 800 倍，延迟约低 4 倍。这项研究工作建立在该团队此前 Intelligence Per Watt 研究的基础上，该研究报告称，本地模型已经能够在交互式延迟下处理 88.7% 的单轮聊天和推理查询，智能效率从 2023 年到 2025 年提升了 5.3 倍。

模型概览与获取

OpenJarvis 不是单一模型。它是一个框架，将任何受支持的模型与可配置的智能体栈组合在一起，并在来自四个模型族的 11 个本地模型上进行了评估。

架构：五个原语与一份 spec

OpenJarvis 将个人 AI 系统拆解为五个带类型的原语，并通过一个称为 spec 的单一声明式配置对象进行组合。

• 智能——模型、权重、生成参数和量化格式。
• 引擎——推理运行时（Ollama、vLLM、SGLang 等）、批处理、KV-cache 设置和硬件路径。
• 智能体——推理循环（ReAct 或 CodeAct）、系统提示词、工具使用策略和轮次限制。
• 工具与记忆——外部接口、检索后端、25+ 数据连接器和 32+ 消息通道，原生支持 MCP，并具备可互换的记忆后端。
• Learning——从轨迹中更新 spec 的优化器。这个槽位接受 LoRA、DSPy、GEPA 或 LLM 引导的 spec 搜索。

每个原语都可以独立替换，而一个 spec 会将全部五个原语序列化到一个 TOML 文件中。两个 spec 可以共享相同的智能体和工具配置，仅在模型和引擎上有所不同，因此相同的行为可以在 Mac Mini 和工作站上运行，而无需重写提示词。

LLM 引导的 spec 搜索是第二项贡献。它是一种本地—云端协作：一个前沿云端模型在搜索时充当教师，读取轨迹、诊断失败聚类，并在 Intelligence、Engine、Agents 以及 Tools & Memory 各层面提出修改建议。只有当某项修改能够改善目标失败聚类且不会在其他地方造成明显的性能回退时，才会被接受——研究团队将其称为门控（默认容差 1%）。优化后的 spec 随后在推理时完全在设备端运行，零云端调用。教师仅在搜索时使用；在每天 100 次查询的情况下，六个月内摊销后的教师成本降至每次查询低于 $0.001。

此前的工作（GEPA、DSPy、LoRA）一次只优化一个原语，而仅靠提示词优化器只能弥补云端—本地差距中约 5 个百分点。LLM 引导的 spec 搜索能弥补 13–32 个百分点，因为它跨原语联合进行修改，且优化成本比单原语基线低 7–11 倍。四原语移动空间贡献了 5.5–16.5 个百分点，而 LLM 提议器在相同移动空间下，相比进化搜索平均额外增加约 10 个百分点。

能力与性能

OpenJarvis 在涵盖 508 项任务的 8 个基准上进行了评估：工具调用（ToolCall-15）、智能体工作流（PinchBench）、编程（LiveCodeBench）、客户服务（τ-Bench V2、τ²-Bench Telecom）、通用助手（GAIA）以及深度研究（LiveResearchBench、DeepResearchBench）。

替换测试：在现有框架（OpenClaw、Hermes Agent）中，将原本使用的云端模型替换为 Qwen3.5-9B 后，准确率下降 25–39 个百分点。而在 OpenJarvis 规范下使用同一模型，残余下降幅度缩小至 5.6–16.5 个百分点——挽回了 56–77% 的可移植性损失。

准确率前沿：表现最佳的单一本地模型 Qwen3.5-122B 达到 80.3% 的平均准确率，而 Claude Opus 4.6 为 83.5%——相差 3.2 个百分点。本地规范在 8 个基准中的 4 个上达到或超过云端：ToolCall-15、PinchBench、LiveCodeBench 和 τ-Bench V2。

成本与延迟：本地配置构成了准确率–效率前沿。Qwen3.5-122B 以每次查询约千分之一美分的成本实现其 80.3% 的准确率，而 Claude Opus 4.6 为每次查询 $0.009——边际 API 成本优势约为 800×。在智能体工作负载上，端到端延迟下降约 4×，不过论文指出单次提示词场景可能更有利于云端服务。

搜索增益：LLM 引导的规格搜索将 Qwen3.5-9B 学生模型提升至 PinchBench 上的 100%、LiveCodeBench 上的 83%，以及 LiveResearchBench 上的 91%。在完整的八项基准测试套件中，每个学生模型的平均增益范围为 13.1 至 31.5 个百分点。作者报告称，这些增益在其稳健性检验（奖励权重变体、搜索种子方差和随机重启）中依然成立。

如何使用

安装只需一条命令。在 macOS、Linux 或 WSL2 上：

curl -fsSL https://open-jarvis.github.io/OpenJarvis/install.sh | bash

Windows 用户运行等效的 PowerShell 脚本（irm … | iex）。安装程序会在宽带环境下约三分钟内配置好 uv、Python 虚拟环境、Ollama 和一个入门模型。桌面 GUI 以 .dmg、.exe、.deb、.rpm 或 .AppImage 的形式从发布页面提供。

安装完成后，jarvis 会启动一个聊天会话。入门预设覆盖常见工作流：

jarvis init --preset morning-digest-mac    # daily briefing with TTS
jarvis init --preset deep-research         # multi-hop research with citations
jarvis init --preset code-assistant        # agent with code execution and shell access
jarvis init --preset scheduled-monitor     # stateful agent on a schedule

该框架内置八个智能体，涵盖三种执行模式——按需、定时和持续。它可连接 25+ 数据源（Gmail、Calendar、iMessage、Notion、Obsidian、Slack、GitHub 等），并通过 32+ 消息渠道（WhatsApp、Telegram、Discord、iMessage、Signal 等）暴露智能体。

技能可以从外部目录导入——约 150 个来自 Hermes Agent，约 13,700 个来自 OpenClaw 的社区技能——全部遵循 agentskills.io 规范。一条 jarvis optimize skills --policy dspy 命令会从本地轨迹历史中对它们进行精炼。

Marktechpost 的视觉解读

OpenJarvis · 斯坦福

斯坦福 · Hazy Research + Scaling Intelligence Lab

OpenJarvis

一个开源、本地优先的个人 AI 智能体框架，将推理、智能体、记忆和学习完全在设备端运行。

与最佳云端方案相差 3.2 个百分点以内

边际 API 成本降低约 800 倍

延迟降低约 4 倍

Apache 2.0 • arXiv:2605.17172 • 框架发布于 2026 年 3 月 12 日

它是什么

在你的硬件上运行的个人 AI

大多数“个人”AI 仍然把每一次查询都经由云端 API 路由。OpenJarvis 将本地优先设为默认，只在需要时才调用云端——这建立在团队 Intelligence Per Watt 的发现之上：本地模型已经能够处理 88.7% 的单轮查询。

代码仓库

github.com/open-jarvis/OpenJarvis

模型

11 个本地模型 · 4 个系列

Qwen3.5、Gemma4、Nemotron、Granite

引擎

Ollama、vLLM、SGLang、llama.cpp、Apple FM、Exo

架构

五个原语，一份规范

一个个人 AI 系统被分解为五个有类型的、可独立替换的原语，通过一份声明式的 spec 组合起来，并序列化为可移植的 TOML。

• Intelligence —— 模型、权重、生成参数、量化
• Engine —— 推理运行时、批处理、KV-cache、硬件路径
• 智能体——推理循环（ReAct 或 CodeAct）、提示词、工具策略
• 工具与记忆——25+ 连接器、32+ 渠道、原生 MCP
• 学习——优化器槽位：LoRA、DSPy、GEPA 或 spec search

关键方法

LLM 引导的 spec search

前沿云端模型在搜索时充当教师：它读取轨迹，诊断失败聚类，并针对各个原语提出修改建议。一个门控只接受不会导致性能退化的修改。优化后的 spec 随后完全在设备端运行——推理时零云端调用。

13–32 个百分点

的云端—本地差距被弥合

相比单原语基线，优化成本更低

四原语移动空间带来 5.5–16.5 个百分点的提升；在相同移动空间下，LLM 提议器相比进化搜索额外带来约 10 个百分点的提升。

性能

接近云端，成本低得多

3.2 个百分点

差距：Qwen3.5-122B 80.3% 对 Claude Opus 4.6 83.5%

本地模型追平或超越云端模型的基准测试

• 在 ToolCall-15、PinchBench、LiveCodeBench、τ-Bench V2 上追平/超越云端
• 边际 API 成本降低约 800 倍；延迟降低约 4 倍（论文所述协议）
• 替换测试：25–39 个百分点的下降在某种设定下缩小至 5.6–16.5 个百分点（恢复了 56–77%）

开发者体验

从零到构建一个智能体只需几分钟

一条命令即可配置 uv、一个 Python 虚拟环境、Ollama 以及一个入门模型（宽带环境下约 3 分钟）：

curl -fsSL https://open-jarvis.github.io/OpenJarvis/install.sh | bash

• 8 个内置智能体，涵盖按需、定时和持续三种模式
• 25+ 数据连接器 · 32+ 消息通道
• 通过 agentskills.io 提供的技能：约 150 个来自 Hermes Agent，约 13,700 个来自 OpenClaw

核心结论

一个研究平台，也是一个生产级基础

OpenJarvis 以大约 3.2 个百分点的准确率作为交换——这一差距主要集中在推理和研究密集型任务上——换来了成本、延迟和隐私方面的显著收益。推理、智能体状态和记忆在架构上均保留在设备端；云端教师模型是可选的，且受到约束。

注意事项：结果取每种配置 5 次运行的平均值，使用 GPT-5-mini 作为评判模型，且均在单台机器上运行。采用 Apache 2.0 许可并积极维护——用作者的话说，是"本着 PyTorch 的精神"为本地 AI 而构建。

核心要点

• OpenJarvis 将推理、智能体、记忆和学习完全运行在设备端，与最佳云端模型的差距在 3.2 个百分点以内，同时边际 API 成本降低约 800 倍，延迟降低约 4 倍。
• 一份带类型的"spec"将整个技术栈分解为五个可替换的原语——智能、引擎、智能体、工具与记忆，以及学习——并序列化为可移植的 TOML。
• LLM 引导的 spec 搜索使用前沿云端模型作为搜索时的教师，以低 7–11 倍的优化成本挽回 13–32 个百分点的云端—本地差距，随后在本地运行，零云端调用。
• 本地 spec 在 8 项基准中的 4 项（ToolCall-15、PinchBench、LiveCodeBench、τ-Bench V2）上达到或超过云端；剩余差距集中在推理和研究密集型任务上。