OpenHuman 是一个开源的个人 AI 桌面助手，GitHub 获星 11.7k，采用 Rust 69% + TypeScript 26% 的技术栈，基于 Tauri v2 + CEF 构建跨平台桌面应用。本文从源码层面系统剖析其六层架构、记忆树知识库、TokenJuice 压缩引擎、118+ 集成通道、Agent 运行时及 JSON-RPC 调度体系，覆盖 70 个 Rust 领域模块的完整代码结构，适合对 AI Agent 工程化落地方案感兴趣的后端架构师和全栈开发者。

目录

1. 概述  1.1 项目背景  1.2 技术栈概览
2. 核心架构  2.1 六层架构总览  2.2 Rust 核心层模块地图  2.3 JSON-RPC 调度体系  2.4 前端 Provider Chain 与应用壳
3. 源码分析  3.1 入口与启动流程  3.2 Agent 运行时：Harness、Dispatcher 与 Sub-Agent  3.3 记忆树：分块、评分与层级摘要  3.4 集成通道：118+ OAuth 与自动拉取  3.5 TokenJuice：终端输出压缩引擎  3.6 推理与模型路由
4. 功能详解  4.1 桌面体验与 Tauri-CEF 壳  4.2 事件总线与域间通信  4.3 安全机制：令牌认证与密钥擦除  4.4 技能系统与可扩展运行时
5. 技术亮点  5.1 Unix 风格的模块设计哲学  5.2 本地优先的数据主权  5.3 全栈测试金字塔
6. 实践指南  6.1 快速开始  6.2 开发工作流  6.3 配置要点
7. 总结参考文献

1. 概述

1.1 项目背景

OpenHuman 由 tinyhumansai 团队开发，定位为"你的个人 AI 超级智能"，核心理念是将 AI 助手从对话工具升级为具备持久记忆、主动感知和深度第三方集成的日常协作者。项目采用 GNU GPL-3.0 许可证，截至 2026 年 5 月已发布 34 个版本（最新 v0.53.43），累计 1,956 次提交，处于早期 Beta 阶段。

与 Claude Cowork、OpenClaw、Hermes Agent 等同类项目相比，OpenHuman 的核心差异化在于三点：记忆系统采用本地优先的记忆树 + Obsidian 兼容仓库而非局限于对话范围；集成数量达 118+ 且支持每 20 分钟自动拉取数据；内置 TokenJuice 压缩层在工具输出进入 LLM 上下文前即完成压缩。

1.2 技术栈概览

仓库语言分布反映了项目的系统编程 + 前端混合架构：

• Rust 69.2%：核心业务逻辑、RPC 服务器、记忆系统、集成通道、工具执行、加密安全
• TypeScript 26.0%：React 19 前端 UI、Redux 状态管理、Vite 8 构建
• JavaScript 2.6%、Shell 1.8%、CSS 0.2%：辅助脚本与样式

核心依赖链：Rust 侧以 Tokio 异步运行时为底座，Axum 提供 HTTP/RPC 服务，Rusqlite 管理本地知识库，Reqwest 驱动 HTTP 客户端；前端以 React 19 + Redux Toolkit + React Router 构建 SPA，通过 Tauri API 与原生层交互。桌面壳采用 Tauri v2 配 CEF（Chromium Embedded Framework）而非系统 WebView，确保跨平台一致的渲染和扩展能力。

2. 核心架构

2.1 六层架构总览

OpenHuman 的分层架构从上到下可概括为六层：

• 表示层：React 19 SPA，通过 HTTP JSON-RPC 与核心通信
• 桌面壳层：Tauri v2 + CEF，管理窗口生命周期和系统 IPC
• 传输层：Axum HTTP 服务器 + Socket.IO 桥接 + SSE 事件流
• 领域层：70 个 Rust 模块覆盖 Agent、Memory、Channels、Skills、Inference 等全部业务能力
• 基础设施层：事件总线、CLI 调度、控制器注册表、安全沙箱、可观测性
• 持久层：本地 SQLite（主存储） + Obsidian 兼容 Markdown 仓库 + 可选 PostgreSQL

流程执行说明：

• 步骤 1-2：用户在 React 界面输入，经 Tauri IPC 转换为 HTTP 请求，附加每次启动时生成的 Bearer Token
• 步骤 3-4：Axum 中间件链依次执行 CORS 处理、Bearer Token 验证、请求日志记录，然后 /rpc 端点接收 POST 请求，调用 invoke_method 进行方法调度
• 步骤 5-6：调度器先在已注册控制器中精确匹配，失败后回退到动态 dispatch 分发；领域处理器执行实际业务逻辑
• 步骤 7-8：结果封装为 RpcOutcome<T>（含可选日志行），序列化为 JSON-RPC 2.0 格式返回前端

2.2 Rust 核心层模块地图

src/openhuman/mod.rs 声明了 70 个公开子模块，覆盖 AI Agent 的全部领域关注点。按职责分组如下：

每个模块遵循 mod.rs 为导出门面、ops.rs 为核心逻辑、types.rs 为数据结构、schemas.rs 为控制器注册的约定布局。

2.3 JSON-RPC 调度体系

核心 RPC 层定义了两个关键抽象：ControllerSchema 和 RpcOutcome<T>。

ControllerSchema 将每个领域功能描述为可注册的控制器函数，包含命名空间（如 memory）、函数名（如 doc_put）、输入/输出字段模式。方法名采用 命名空间.函数名 的加点格式（如 memory.doc_put），与 JSON-RPC 线格式中的下划线命名（如 openhuman.memory_doc_put）刻意区分以防止混淆。

RpcOutcome<T> 封装成功响应：当无日志时直接返回裸 JSON 值，有日志时包装为 {"result": value, "logs": [...]} 结构。

调度流程分两阶段：

• Phase 1：精确匹配 —— 通过 all::schema_for_rpc_method 查找注册的控制器模式，验证参数后调用 try_invoke_registered_rpc
• Phase 2：动态回退 —— 若 phase 1 未匹配到处理器（存在模式但无注册实现），回退到 core::dispatch::dispatch 进行动态分发

HTTP 路由表提供了以下端点：

• GET / — 服务信息（名称、API 地址、端点列表）
• GET /health — 健康检查
• GET /schema — 所有已注册方法的完整模式转储
• POST /rpc — JSON-RPC 2.0 方法调用入口
• GET /events — SSE 事件流（客户端订阅）
• GET /events/webhooks — Webhook 调试事件
• GET /ws/dictation — 语音听写 WebSocket
• GET /auth/telegram — Telegram OAuth 回调
• /v1/chat/completions — OpenAI 兼容推理端点

2.4 前端 Provider Chain 与应用壳

前端采用 React 19 + Redux Toolkit 架构，应用包装链（Provider Chain）的结构为：

Sentry → Redux Store → PersistGate → CoreStateProvider → SocketProvider → ChatRuntimeProvider → HashRouter → AppShell

关键设计：

• Redux PersistGate 确保状态在桌面应用重启后恢复
• SocketProvider 管理 Socket.IO 连接到 Rust 核心的事件桥接
• ChatRuntimeProvider 封装 Agent 会话的运行时状态
• HashRouter 使用 URL hash 管理路由，适配桌面应用无服务端路由的场景

Tauri 壳被明确定义为"交付载体（窗口管理、进程生命周期、IPC）"，产品逻辑全部驻留在 TypeScript/React 层。CLAUDE.md 中明确禁止在 CEF 子 WebView 中新增 JavaScript 注入 —— 所有抓取操作通过原生 CDP 执行。

3. 源码分析

3.1 入口与启动流程

应用启动从 src/main.rs 的 main() 函数开始，执行以下关键初始化序列：

• 环境加载：调用 dotenvy::dotenv() 加载 .env 文件（优先使用 OPENHUMAN_DOTENV_PATH 指定的路径）
• Sentry 初始化：构建 ClientOptions，配置 DSN 解析链（依次检查 OPENHUMAN_CORE_SENTRY_DSN → 旧版 OPENHUMAN_SENTRY_DSN → 编译时环境变量）、Release 标签（格式 openhuman@版本号[+短SHA]）、环境标识（development 或 production）
• 事件过滤器：before_send 回调丢弃瞬时性 Provider HTTP 故障、预算耗尽 400 错误、工具迭代上限事件、会话过期 401 事件等低信号事件，并对异常消息值执行密钥擦除
• CLI 分发：收集命令行参数，调用 openhuman_core::run_core_from_args

run_core_from_args 先调用 service::apply_startup_restart_delay_from_env() 处理重启延迟，然后委托给 core::cli::run_from_cli_args 进行命令分发。CLI 支持的命令包括：

• run / serve：启动 HTTP 服务器（默认 127.0.0.1:7788）
• mcp / mcp-server：启动 MCP 标准输入/输出服务
• call：单次 JSON-RPC 调用（--method + --params）
• agent：直接 Agent 交互
• memory：记忆系统命令行操作
• screen-intelligence、text-input、tree-summarizer、voice：专项功能入口

3.2 Agent 运行时：Harness、Dispatcher 与 Sub-Agent

Agent 运行时是 OpenHuman 的"大脑"，定义在 openhuman::agent 模块下。核心组件包括：

Harness（harness::session::Agent）管理"向 Provider 发送提示并执行返回的工具调用"的循环。AgentBuilder 提供构造器模式，允许配置 Provider、系统提示、可用工具集和调度策略。

Dispatcher（dispatcher 子模块）定义工具调用如何在提示中格式化以及如何从响应中解析。支持三种格式：

• XML 格式：工具调用以 XML 标签包裹，兼容多数通用 LLM
• JSON 格式：结构化 JSON 工具调用，适用于原生支持 function calling 的模型
• P-Format：项目自定义的精简格式，减少 Token 消耗

Sub-Agent Runner（harness::subagent_runner）支持从父 Agent 的工具循环中派生子 Agent，实现层级化任务委托。内置的专用 Agent 定义在 agents 子模块中，包括 Orchestrator（任务编排）、Code Executor（代码执行）和 Researcher（信息检索）。

Triage 管道（triage 子模块）高性能分类管道，使用小型本地模型对 Webhook 和 Cron 作业等外部触发器进行分类和响应，避免每次触发都调用大型云端模型。

Agent 与记忆系统的交互通过 memory_loader 和 tree_loader 两个加载器实现：前者在会话启动时加载相关记忆上下文，后者将记忆树中与当前任务相关的摘要节点注入系统提示。

3.3 记忆树：分块、评分与层级摘要

记忆系统由 13 个子模块构成，是 OpenHuman 最核心的差异化能力：

• 数据摄入（ingestion）：定义 IngestionJob、IngestionQueue 和 ExtractionMode，管理从集成通道流入的数据如何进入知识库
• 文档分块（chunker）：将长文本切分为不超过约 3,000 Token 的 Markdown 片段，保持语义完整性
• 评分与检索（store）：MemoryClient 提供统一存储接口，NamespaceQueryResult 封装检索结果及其 RetrievalScoreBreakdown
• 层级摘要（tree）：tree_summarizer 将相关片段折叠为层级化摘要树，上层节点聚合下层内容，形成从细节到概括的金字塔结构

记忆以两种形态持久化：

• SQLite：结构化存储，管理片段元数据、评分、关系图
• Obsidian 仓库：同一份数据以 .md 文件落地，用户可直接用 Obsidian 浏览和编辑

tool_memory 子模块提供工具记忆规则系统：ToolMemoryRule 定义特定工具的上下文保留策略，ToolMemoryStore 管理工具输出到记忆命名空间的自动捕获。

流程执行说明：

• 步骤 1：自动拉取系统每 20 分钟遍历活跃连接，将新数据推入摄入队列
• 步骤 2-3：Chunker 将原始文本规范化为 Markdown 片段，限制每块不超过约 3,000 Token；评分器根据相关性、新鲜度和去重结果打分
• 步骤 4-5：TreeSummarizer 将评分后的片段插入层级摘要树，父节点聚合子节点内容生成摘要；最终同步写入 SQLite 和 Obsidian 兼容仓库

3.4 集成通道：118+ OAuth 与自动拉取

channels 模块管理 16+ 种消息通道的实现，每个通道对应一个独立的 Rust 子模块：

无条件编译的通道（14 个）：DingTalk、Discord、Email、iMessage、IRC、Lark（飞书）、Linq、Mattermost、QQ、Signal、Slack、Telegram、Web、Cli

特性门控通道（2 个）：Matrix（channel-matrix 特性）、WhatsApp Web（whatsapp-web 特性）

所有通道实现 Channel trait 和 SendMessage trait，通过 start_channels 统一启动。controllers 子模块定义了 ChannelDefinition 和 ChannelAuthMode，支持 OAuth 一键授权连接 Gmail、Notion、GitHub、Slack、Stripe、Calendar、Drive、Linear、Jira 等服务。每个连接以类型化工具的形式暴露给 Agent，使 LLM 可以直接调用。

runtime 子模块协调通道的启动编排，proactive 子模块支持主动消息推送（如定时摘要、事件通知）。

与竞品的核心差异在于自动拉取（Auto-Fetch）：OPENHUMAN_DISABLE_CHANNEL_LISTENERS 环境变量控制通道监听器的启停；运行时，一个后台 Tokio 任务每约 5 秒轮询 Cron 调度器，每 20 分钟通过 periodic_sync 遍历活跃连接并拉取增量数据。

3.5 TokenJuice：终端输出压缩引擎

TokenJuice 是内嵌在 openhuman::tokenjuice 中的 Rust 库，移植自 vincentkoc/tokenjuice^[1]。它的设计目标是在 git、npm、cargo、docker 等工具的输出进入 LLM 上下文之前进行压缩。

规则系统按优先级从低到高三层叠加：

• 内置规则：编译时通过 include_str! 嵌入的 JSON 规则文件
• 用户规则：从 ~/.config/tokenjuice/rules/ 加载
• 项目规则：从当前工作目录的 .tokenjuice/rules/ 加载

核心 API 是 reduce_execution_with_rules，接收 ToolExecutionInput（包含工具名、参数向量、标准输出），返回 CompactResult。示例效果：将 git status 的详细输出压缩为简洁的 "M: src/lib.rs" 格式。

compact_tool_output 函数是面向调用方的高级封装，返回 CompactionStats 用于监控压缩效果。模块文档明确声明其为"纯库"，无 JSON-RPC 面、无 CLI、无存储制品 —— 所有外部集成由调用方自行构建。

3.6 推理与模型路由

inference 模块管理多模型路由和设备配置。子模块职责：

• provider：云端 + 本地 Provider trait、路由策略、可靠性处理（重试、超时、故障转移）
• local：管理 Ollama / LM Studio / Whisper / Piper 的本地运行时生命周期
• http：暴露 /v1/chat/completions 的 OpenAI 兼容端点
• device：硬件配置文件（DeviceProfile），检测 GPU、内存等设备能力
• presets：模型预设（ModelPreset），预定义推理型、快速型和视觉型三类模型的配置
• voice：语音合成配置

模型路由基于 ModelTier 将任务分配到合适的模型：推理密集型任务（代码生成、架构设计）路由到推理型模型，简单分类和格式化路由到快速型模型，图像分析路由到视觉型模型。所有路由在同一订阅下完成，消除了多供应商 API 管理带来的复杂性。

本地 AI 支持通过 LocalAiStatus 系列类型暴露，包括 LocalAiDownloadProgressItem（模型下载进度）、LocalAiTtsResult（文本转语音结果）、LocalAiSpeechResult（语音识别结果）和 LocalAiEmbeddingResult（嵌入向量）。

4. 功能详解

4.1 桌面体验与 Tauri-CEF 壳

Tauri 壳被明确界定为"交付载体"，职责严格限定在窗口管理、进程生命周期和 IPC 通信。CLAUDE.md 中明确规定："产品逻辑驻留在 TypeScript/React 层"。

CEF 模式是 OpenHuman 相对于标准 Tauri（使用系统 WebView）的关键技术选择。通过 tauri-runtime-cef（从 vendor/tauri-cef/ 构建），应用获得：

• 跨平台一致的渲染行为（不受系统 WebView 版本差异影响）
• 完整的 Chromium DevTools 支持（开发阶段）
• 原生的 CDP（Chrome DevTools Protocol）访问能力，用于网页抓取而非 JavaScript 注入

Tauri 插件配置包括：deep-link（深度链接）、global-shortcut（全局快捷键）、notification（系统通知）、opener（外部链接打开）、single-instance（单实例锁）和 updater（自动更新）。其中 single-instance 插件在 tauri::Builder 初始化之前即获取进程级标识锁。

4.2 事件总线与域间通信

事件总线（Event Bus）是连接各领域模块的核心基础设施。域事件类型包括：agent、memory、channel、cron、skill、tool、webhook、system 八类。

在服务器启动的 bootstrap_core_runtime 阶段注册以下订阅器：

• WebhookRequestSubscriber：处理来自集成的 Webhook 回调
• ChannelInboundSubscriber：处理通道入站消息
• SessionExpiredSubscriber：会话过期时清除存储令牌并设置调度门控的登出状态
• 健康检查、通知、对话持久化、Composio 触发历史、定期同步、调度门控
• Agent 处理器：restart、shutdown、proactive_message 等生命周期事件

订阅器通过模块级函数实现单例请求/响应模式，内部通信零序列化开销。外部通信通过 Socket.IO 桥接将事件推送到 Web 前端。

4.3 安全机制：令牌认证与密钥擦除

安全体系包含三层防护：

传输层认证每次启动时在 {workspace_dir}/core.token 生成一次性 Bearer Token。前端所有 HTTP 请求携带此 Token，由 rpc_auth_middleware 中间件验证。Token 仅存在于进程内存中，进程退出即失效。

密钥擦除SECRET_PATTERNS 静态变量定义四组正则表达式替换规则：

• Bearer Token：匹配 bearer  后跟非空白字符，替换为 [REDACTED]
• API Key：匹配 api-key: 或 api_key= 模式
• 通用 Token：匹配 token: 或 token= 模式
• OpenAI 风格 Key：匹配 sk- 后跟 20 个以上字母数字字符

scrub_secrets 函数在 Sentry 事件上报前对所有异常消息值执行这些替换，确保敏感凭据不会出现在错误追踪系统中。

Sentry 事件过滤before_send 回调实现精细的事件丢弃策略：

• 丢弃瞬时性 Provider HTTP 故障（引用历史问题 ID OPENHUMAN-TAURI-2E）
• 丢弃预算耗尽的 400 错误
• 丢弃工具迭代上限事件
• 丢弃瞬时后端 API、集成和更新器故障
• 丢弃会话过期的 401 事件（仅记录 Debug 日志）
• 剥离 server_name 字段（防止主机名泄露）
• 仅附加账户 UID 到 event.user，明确不包含 email、name 或 IP

4.4 技能系统与可扩展运行时

skills 模块提供可扩展的技能运行时，包含 10 个子模块：

• ops_create、ops_install、ops_discover、ops_parse：技能的全生命周期管理
• ops_types：技能类型定义
• inject：技能提示注入，将已安装技能的说明注入系统提示
• schemas：注册技能相关的 JSON-RPC 控制器
• bus：技能总线（当前为无操作桩，处于从旧事件总线基础设施迁移的过程中）

技能系统与 MCP（Model Context Protocol）深度集成：mcp_client 模块提供 MCP 客户端能力，mcp_server 模块支持以 openhuman mcp 命令启动 MCP 标准输入/输出服务，使 OpenHuman 可作为 MCP 服务器嵌入其他 AI 工具（Claude Code、Cursor、Codex 等）。

5. 技术亮点

5.1 Unix 风格的模块设计哲学

CLAUDE.md 明确规定了模块设计原则："Unix-style modules: small, sharp-responsibility units composed through clear boundaries."这种设计体现在：

• 每个领域功能驻留在独立的 openhuman/<domain>/mod.rs 子目录中
• mod.rs 仅包含导出声明，核心逻辑放在 ops.rs，类型定义放在 types.rs，数据访问放在 store.rs
• 禁止在 core/cli.rs 和 core/jsonrpc.rs 中添加领域分支 —— 所有功能通过控制器注册表暴露
• 文件大小建议不超过约 500 行
• 新增或变更流程必须包含调试日志，使用稳定的 grep 友好前缀

这种模块化使得 70 个领域模块可以独立开发、测试和审查，避免了单体 Agent 代码库常见的"上帝类"问题。

5.2 本地优先的数据主权

OpenHuman 的数据架构坚持本地优先原则：

• 工作流数据保留在用户设备上，本地加密存储
• 记忆树使用本地 SQLite 而非云数据库
• 知识库以标准 Markdown 文件落地，用户完全拥有数据
• 可选的 agentmemory 后端用于与 Claude Code、Cursor 等工具共享持久化存储
• TokenJuice 压缩全部在本地完成，无数据外泄风险

这种设计与 Karpathy 提倡的 obsidian-wiki 工作流一脉相承 —— 将 LLM 的知识库建立在用户自己的文件系统上，而非锁定在某个云端服务的私有格式中。

5.3 全栈测试金字塔

测试策略覆盖从单元到端到端的四个层次：

• Rust 单元测试：通过共享 Mock 后端隔离依赖
• TypeScript 单元测试：Vitest + jsdom，测试文件与源码同目录
• Rust 集成测试：CI 配置 opt-level=1、codegen-units=16 以加速编译
• E2E 测试：WebdriverIO 9.24，双平台支持（Linux CI 用 tauri-driver，macOS 用 Appium Mac2 XCUITest），覆盖登录、认证、服务连接、技能注册、技能执行、Cron 作业和完整会话流程

PR 要求变更行覆盖率不低于 80%，由 CI 强制执行。E2E 场景必须覆盖正常路径、失败模式、认证门控和回归测试。

6. 实践指南

6.1 快速开始

预构建安装（推荐）

从 tinyhumans.ai/openhuman^[2] 下载 DMG（macOS）或 EXE（Windows）安装包。

命令行安装

macOS / Linux x64：

curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash

Windows：

irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex

6.2 开发工作流

环境要求

• Git、Node.js 24+、pnpm 10.10.0
• Rust 1.93.0（含 rustfmt 和 clippy）
• CMake、Ninja、ripgrep
• 平台桌面构建工具链（macOS: Xcode CLI；Windows: VS Build Tools；Linux: webkit2gtk 等）

初始设置

git clone https://github.com/tinyhumansai/openhuman.gitcd openhumangit submodule update --init --recursive  # 拉取 vendored Tauri/CEF 源码pnpm install

开发命令

PR 前置检查清单

• 代码通过 pnpm typecheck、pnpm format:check、cargo check
• 变更行测试覆盖率不低于 80%
• E2E 场景覆盖正常路径和失败模式
• 新增/变更的流程包含调试日志

6.3 配置要点

Rust 核心配置

• 监听地址：OPENHUMAN_CORE_HOST（默认 127.0.0.1）
• 监听端口：OPENHUMAN_CORE_PORT（默认 7788）
• 日志级别：启动时传 -v 或设置 RUST_LOG=debug
• 禁用通道监听器：OPENHUMAN_DISABLE_CHANNEL_LISTENERS=1
• 环境文件路径：OPENHUMAN_DOTENV_PATH

记忆后端切换

在 config.toml 中设置 memory.backend = "agentmemory" 可将记忆后端切换为与 Claude Code、Cursor 等工具共享的持久化存储。

本地 AI 配置

通过推理模块的 ModelPreset 配置本地 Ollama 实例，支持嵌入、文本生成、语音识别和语音合成本地运行。

7. 总结

OpenHuman 代表了 AI Agent 从"对话机器人"向"持久化协作者"演进的技术路标，其架构设计中有几个值得关注的方向：

• 记忆系统从对话上下文扩展到结构化知识库，通过本地优先的 SQLite + Markdown 双模存储实现数据主权与可用性的平衡，这一模式可能成为个人 AI 助手的事实标准
• TokenJuice 压缩引擎将成本控制前置到 LLM 调用之前，通过规则化压缩而非模型蒸馏来减少 Token 消耗，实现路径务实且对各类模型通用
• Unix 风格的模块化设计使得 70 个领域模块可以独立演进，避免了 Agent 代码库常见的一体化耦合问题，但也对开发者的模块边界判断力提出了要求
• 118+ 集成 + 自动拉取实现了"零提示词上下文感知"的愿景，但依赖第三方 API 的稳定性和 OAuth 授权的持续性，在长期运行中需要完善的故障隔离和降级策略
• 作为早期 Beta 项目，迭代速度很快（34 个版本），适合技术评估和原型验证，生产环境部署建议关注其稳定版发布路线

对于需要深入集成工作流、重视数据本地化和长期记忆能力的开发者，OpenHuman 提供了一个值得深入研究的开源参考实现。

参考文献

[1] OpenHuman GitHub 仓库：https://github.com/tinyhumansai/openhuman

[2] OpenHuman 官方网站：https://tinyhumans.ai/openhuman

[3] OpenHuman 中文 README：https://github.com/tinyhumansai/openhuman/blob/main/README.zh-CN.md

[4] TokenJuice 原始项目：https://github.com/vincentkoc/tokenjuice

[5] OpenHuman GitBook 文档：https://tinyhumans.gitbook.io/openhuman

[6] Tauri v2 官方文档：https://v2.tauri.app

[7] Andrej Karpathy obsidian-wiki 工作流：https://github.com/karpathy/obsidian-wiki

1. https://github.com/vincentkoc/tokenjuice ↩
2. https://tinyhumans.ai/openhuman ↩