2026/9/11 11:17:00
FEATURED · 精选文章 
OpenHuman 开发者指南从源码构建、测试到发布的完整工作流【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhumanOpenHuman 是一个面向 Mac、Windows、Linux 的开源个人 AI 桌面应用React Tauri v2 前端 Rust 核心GPLv3 协议。本篇技术指南以仓库中的开发者文档 gitbooks/developing/README.md 为主线系统梳理从零开始克隆仓库、搭建工具链、构建桌面应用与 Rust 核心、分层编写测试到走完发布流程的完整开发闭环。读完本文你将掌握 OpenHuman 仓库的目录组织、精确的构建命令、测试分层决策方法以及main/release双分支发布模型下的实际发布操作。仓库布局四块核心区域OpenHuman 是一个 monorepo所有代码按职责集中在四个顶层目录中。理解这张表是阅读任何源码的前提路径内容app/pnpm workspaceopenhuman-appVite React 前端app/src/与 Tauri 桌面宿主app/src-tauri/src/Rust crateopenhuman_core与openhuman-coreCLI 二进制领域逻辑、JSON-RPC、MCP 路由gitbooks/面向公众的文档站本文所在目录docs/尚未迁移到 GitBook 的深度参考文档记忆管线图、Agent 流程等根目录的 CLAUDE.md 是 AI Agent 在该代码库上工作的事实来源source of truth同样的规则也适用于人类贡献者。它明确指出了逻辑所在的分界Rust 核心src/承载全部业务逻辑、执行、领域、RPC、持久化与 CLITauri Reactapp/只负责 UX、界面、导航与桥接是展示与编排层而非特性所在层。值得注意的细节CLAUDE.md 说明核心以 in-process 方式运行——Tauri 宿主通过core_process::CoreProcessHandle将 Rust 核心作为 tokio 任务内嵌sidecar 模式已在 PR #1061 移除前端 RPC 走http://127.0.0.1:port/rpc携带每次启动随机生成的 hex bearer token。OPENHUMAN_CORE_TOKEN对 CLI / docker / cloud 场景仍然生效。从哪里开始推荐的阅读路线文档为首次拉取仓库的开发者规划了明确的阅读顺序依次覆盖能跑起来 → 能编译核心 → 能理解架构 → 能写测试构建与安装Getting Set Up工具链、依赖、vendor 的 Tauri CLI、sidecar staging——让pnpm dev真正启动起来所需的一切构建 Rust 核心Building the Rust Core仅针对仓库根 Rust crate 的全新机器搭建固定的工具链版本、操作系统包、精确的cargo命令架构Architecture桌面应用、Rust 核心 sidecar、JSON-RPC 桥接、双 socket 如何拼合——做任何非平凡修改前先读它前端Frontend 与 Tauri ShellReact 应用与其外的桌面宿主MCP Server可选的 stdio MCP 模式用于向本地客户端暴露只读的 OpenHuman 记忆工具。从仓库根 package.json 可以看到 workspace 的管理方式根包是私有包openhuman-repopackageManager固定为pnpm10.10.0sha512...并通过patchedDependencies对assistant-ui/react-lexical0.2.10应用了 app/patches/ 下的补丁。这种根仓库只做编排、openhuman-app承载应用的结构贯穿所有 npm script。环境准备与工具链必需的软件版本依赖版本要求依据Node.js24 或更新app/package.jsonpnpm10.10.0根 package.json 的packageManager字段Rust1.93.0rustup 安装含rustfmt、clippyrust-toolchain.tomlCMake最新稳定版原生 Rust 依赖编译所需Git 子模块app/src-tauri/vendor/vendor 的 CEF-aware Tauri CLI 需要平台构建工具macOSXcode Command Line ToolsLinuxTauri 的 GTK/WebKit/AppIndicator 包组见下文macOSHomebrew快速开始brew install node24 pnpm rustup-init cmake rustup toolchain install 1.93.0 --profile minimal rustup component add rustfmt clippy --toolchain 1.93.0Arch Linux 快速开始sudo pacman -S --needed nodejs npm rustup cmake base-devel clang openssl \ alsa-lib xdotool libxtst libxi libevdev gtk3 webkit2gtk-4.1 \ libayatana-appindicator librsvg patchelf nss nspr at-spi2-core \ libcups libdrm libxkbcommon libxcomposite libxdamage libxfixes \ libxrandr mesa pango cairo libxshmfence npm install -g pnpm10.10.0 rustup toolchain install 1.93.0 --profile minimal rustup component add rustfmt clippy --toolchain 1.93.0子模块与 vendor 体系OpenHuman 的核心子系统大量运行在发布为独立 crate 的tiny*家族上tinyagents、tinyflows、tinychannels、tinymemory、tinybus等它们以 git 子模块形式 vendor 在vendor/下以便在发布前于本仓库内直接测试 crate 变更。从根 Cargo.toml 的依赖注释可以看出这套体系的分工原则例如Agent 引擎基于tinyagents每一轮 agent turn 都经由src/openhuman/agent/tinyagents/的适配接缝穿过 harness记忆引擎基于tinycortex通过tinymemory的 vendor 副本访问OpenHuman 保留 RPC、工具、调度、凭据、安全策略等宿主侧逻辑推理基于 crate 原生的ModelRouter/OpenAiModel做工作负载分层路由。克隆仓库后务必执行git submodule update --init --recursive构建桌面壳时需要而纯核心开发则不需要子模块。相关依赖声明如tinyhumans-sdk、tinymcp都在注释里标注了对应的初始化命令例如git submodule update --init vendor/tinymcp。构建桌面应用本地编译从仓库根执行以下命令即可完成一次完整的源码构建# 1) 克隆并进入仓库 git clone https://github.com/tinyhumansai/openhuman.git cd openhuman # 2) 拉取 vendor 的 Tauri/CEF 源码 git submodule update --init --recursive # 3) 安装 JS 依赖workspace 级 pnpm install # 4) 构建桌面应用产物 pnpm build本地开发而非生产构建时# 仅 Web UI 开发Vite dev server pnpm dev # 桌面应用开发使用 vendor 的 Tauri/CEF CLI须在 workspace 根执行 pnpm --filter openhuman-app dev:app根 package.json 提供了配套的完整脚本矩阵pnpm typecheck即tsc --noEmit/compile、pnpm lintESLint --cache、pnpm format:checkPrettier cargo fmt --check、pnpm test:rust调用 scripts/test-rust-with-mock.sh等均可从仓库根直接运行。通过官方安装脚本安装稳定版macOS / Linux x64 的常规安装curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash安装脚本行为解析当前平台的最新稳定版、在可用时校验产物摘要、默认本地安装无需 sudomacOS 安装OpenHuman.app到~/ApplicationsLinux x64 将 AppImage 安装为~/.local/bin/openhuman并写入桌面条目。可用--dry-run预览动作而不落盘curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash -s -- --dry-runWindows 使用 PowerShellirm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex仓库还附带 packages/arch/openhuman-bin/ 的 AUR 配方以官方 x86_64 AppImage 为二进制源makepkg时解包应用树、安装桌面条目并暴露/usr/bin/openhuman。发布前可本地构建cd packages/arch/openhuman-bin makepkg --syncdeps --install。ARM Linuxaarch64构建ARM 构建因 CEF 与 GTK 依赖需要特殊处理。先安装 Xvfb 用于无头构建/测试然后cd app pnpm tauri build --target aarch64-unknown-linux-gnu运行 ARM 二进制需要设置 CEF 库路径REL_DIRapp/src-tauri/target/aarch64-unknown-linux-gnu/release CEF_DIR$(ls -d $REL_DIR/build/cef-dll-sys-*/out/cef_linux_aarch64 2/dev/null | head -n1) export LD_LIBRARY_PATH$CEF_DIR:$REL_DIR/deps:$REL_DIR${LD_LIBRARY_PATH::$LD_LIBRARY_PATH} $REL_DIR/OpenHuman --no-sandbox或用包装脚本封装上述逻辑推荐。DEB 安装DEB_FILE$(ls app/src-tauri/target/aarch64-unknown-linux-gnu/release/bundle/deb/OpenHuman_*_arm64.deb | head -n1) sudo dpkg -i $DEB_FILE注意ARM 构建要求 GTK 在 Tauri 创建系统托盘前初始化该修复位于vendor/tauri-cef/crates/tauri-runtime-cef/src/lib.rsgtk::init().ok()。若出现 GTK has not been initialized 说明该修复未就位需重新构建。常见故障排查macOSpnpm dev:app报 CEF cache is held by another OpenHuman instanceCEF 通过~/Library/Caches/com.openhuman.app/cef下的SingletonLock符号链接独占其用户数据目录。安装版.app与开发二进制共用同一 bundle idcom.openhuman.app无法并行运行。退出另一实例后重跑pkill -f OpenHuman.app/Contents pkill -f openhuman-core pnpm dev:app若锁由崩溃进程残留PID 已不存在preflight 会自动清理过期SingletonLock并继续启动。已知限制dev 与 release 构建仍共享com.openhuman.app缓存标识隔离需要修改 vendor 的tauri-runtime-cef跟踪自 #864。核心端口上的陈旧openhumanRPC 进程core_process::ensure_running会在启动时探测OPENHUMAN_CORE_PORT默认 7788若GET /识别出是 OpenHuman coreJSON 响应含name: openhuman判定为陈旧进程并主动终止Unix 下 SIGTERM 后 750ms SIGKILLWindows 下taskkill /F /T /PID随后宿主拉起全新内嵌核心若端口被其他服务占用则大声报错而非静默挂接。设置OPENHUMAN_CORE_REUSE_EXISTING1可回到旧的挂接任意进程行为用于手动调试 harness。手动清理依然有效pkill -f OpenHuman.app/Contents pkill -f openhuman-core仅构建 Rust 核心core-only 工作流如果你只关心仓库根 Rust crate不需要桌面壳使用 Building the Rust Core 的流程Cargo 包名openhuman可运行二进制openhuman-core入口 src/main.rs库openhuman_coreCargo.toml 的[lib]段crate-type [rlib]。# 快速依赖 类型检查 cargo check --manifest-path Cargo.toml # 调试构建 CLI / RPC 二进制 cargo build --manifest-path Cargo.toml --bin openhuman-core # Release 构建 cargo build --manifest-path Cargo.toml --release --bin openhuman-core # Rust 测试 cargo test --manifest-path Cargo.toml产物落在target/debug/openhuman-core或target/release/openhuman-core。若偏好面向包的命令如打包脚本用-p openhuman。加速本地链接可选openhuman核心 crate 链接的是单个巨型 rlib编辑 →cargo check/cargo test的内循环经常受链接瓶颈约束。用 moldLinux或 lldmacOS可显著缩短增量重链时间。仓库提供幂等的配置脚本它把检测结果写入$CARGO_HOME/config.toml绝不改动仓库内跟踪的.cargo/config.toml属于每台机器的可选开启scripts/dev-setup-linker.sh # 安装 mold/lld 检测 scripts/dev-setup-linker.sh --dry-run # 先预览变更需先安装链接器apt install mold/brew install llvm脚本检测不到会打印指引并退出。CI 的 Linux Rust 任务直接通过RUSTFLAGS启用同一标志。各平台系统包前置条件macOSxcode-select --install。whisper-rs在构建期间编译原生代码macOS 上该 crate 以metalfeature 构建需要 Apple 工具链与 SDK 头文件。Ubuntu / Debiancore-only 最小集sudo apt-get update sudo apt-get install -y \ build-essential cmake pkg-config clang libssl-dev libclang-dev \ libasound2-dev libxi-dev libxtst-dev libxdo-dev libudev-dev \ libstdc-14-devArchcore-onlysudo pacman -S --needed base-devel cmake pkgconf clang openssl \ alsa-lib libxi libxtst xdotool libevdevWindowsrustup Visual Studio Build Tools 2022Desktop development with C 工作负载MSVC 目标x86_64-pc-windows-msvc。注意用 MSVC 而非 MinGW——仓库给whisper-rs-sys打了补丁以强制静态 MSVC CRT规避LNK2038/LNK1169错误。一个典型的坑whisper-rs-sys在 clang 下可能报fatal error: array file not found这正是文档点名libstdc-14-dev的原因clang 可能选中 Ubuntu runner 上的 GCC 14 C 头文件。若仍无法解析libstdc.so可用 AGENTS.md 中记录的软链方案按实际 GCC 版本调整。构建桌面壳而非 core-only时需使用更宽的依赖集GTK/WebKit/AppIndicator 等详见 building-rust-core.md 第 5 节两套清单都镜像自 .github/workflows/build-desktop.yml。三层测试体系你的改动该写在哪里OpenHuman 对测试分层有非常明确的约定。核心原则把测试压到尽可能低的层级Rust unit Rust integration Vitest WDIO低层更快、更确定、更便宜WDIO 只用于真正跨越 UI ⇄ Tauri ⇄ sidecar ⇄ JSON-RPC 的行为。五个测试层级总览层级位置测试内容驱动方式Rust 单元#[cfg(test)] mod tests同文件或tests.rs或领域下tests/子目录如src/openhuman/channels/tests/纯领域逻辑、schema、RPC handler 形状、内存状态机cargo testRust 集成仓库根tests/*.rs真实 Tokio 运行时下的完整领域接线、mock 外部服务、JSON-RPC 端到端如 tests/json_rpc_e2e.rs、领域 × 领域交互pnpm test:rust即bash scripts/test-rust-with-mock.shVitest 单元app/src/**下与源码同目录的*.test.ts(x)或app/src/**/__tests__/React 组件、hooks、store slices、纯工具、服务层适配器pnpm test:unitWDIO E2Eapp/test/e2e/specs/*.spec.ts完整桌面流UI → Tauri → in-process 核心 → JSON-RPC用户可见行为全平台走 Appium Chromium driver端口 4723面向 CEF 运行时手动冒烟docs/RELEASE-MANUAL-SMOKE.md驱动无法断言的 OS 级表面TCC 权限弹窗、Gatekeeper、代码签名、DMG 安装、OS 原生 toast发布切版时人工执行并在 release PR 签署决策树测试放哪层改动在 JSON-RPC 边界之后src/ 内 ├─ YES - 跨领域或与外部队话 │ ├─ YES → Rust 集成tests/*.rs │ └─ NO → Rust 单元源码旁 └─ NO - 改动在 app/ 内 ├─ 是纯函数 / hook / slice / 独立组件 │ └─ YES → Vitest 单元*.test.tsx 同目录 └─ 用户可见 且 跨越 UI ⇄ Tauri ⇄ sidecar ⇄ JSON-RPC ├─ YES → WDIO E2Eapp/test/e2e/specs/*.spec.ts └─ 属于 OS 级TCC、Gatekeeper、安装、OS toast └─ YES → 手动冒烟清单如果一个改动涉及多个层级每一层都要写对应的测试不能用一层替代另一层。关键质量门槛失败路径要求覆盖矩阵中每个特性叶子除 happy path 外必须有至少一条失败/边界断言。例如文件写入工具happy 写入了字节failure 路径限制拒绝。只断言 happy path 的 spec 是不完整的。覆盖率门槛PR 必须通过改动行 ≥ 80% 覆盖率的PR CI Gate检查。为新增行为补测试而不只是 happy path。Cargo.toml 中还专门用build.rs把 tests/raw_coverage/ 下约 76 个独立tests/*.rs目标折叠进单一raw_coverage_all集成目标省去约 75 次整 crate 重链。Mock 策略单元/集成/E2E 一律不得访问真实网络。统一使用共享 mock 后端scripts/mock-api-core.mjs、scripts/mock-api-server.mjs、app/test/e2e/mock-server.ts管理端点包括GET /__admin/health、POST /__admin/reset、POST /__admin/behavior、GET /__admin/requests。Telegram、Slack、Gmail、Notion、Ollama、OpenAI 等外部服务都在 mock 层打桩测试通过getRequestLog()断言请求形状。确定性规则不用墙钟等待用waitForApp/waitForWebView等辅助每个 E2E spec 运行在隔离的OPENHUMAN_WORKSPACE中spec 不得依赖执行顺序避免绝对坐标与动画时序优先用browser.execute(...)合成键盘输入。合并前的本地检查清单# Rust core cargo fmt --check cargo check --manifest-path Cargo.toml cargo clippy --manifest-path Cargo.toml -- -D warnings cargo test --manifest-path Cargo.toml # Tauri shell cargo check --manifest-path app/src-tauri/Cargo.toml # Frontend pnpm typecheck pnpm lint pnpm format:check pnpm test:unit # Rust integration with mock backend pnpm test:rust # E2E慢仅当行为有用户可见变化时 pnpm test:e2e:build bash app/scripts/e2e-run-spec.sh test/e2e/specs/your-spec.spec.ts idE2E 快速上手桌面 E2E 用 WebDriverIO 通过 Appium 驱动 Tauri 应用Linux 与 macOS 均使用Appium Chromium driver端口 4723CEF 运行时CSS/DOM 选择器。# 一次性安装 Appium Chromium driver npm install -g appium3 appium driver install --sourcenpm appium-chromium-driver # 构建 E2E 应用 pnpm --filter openhuman-app test:e2e:build # 运行全部 flows pnpm --filter openhuman-app test:e2e:all:flows # 运行单个 spec bash app/scripts/e2e-run-spec.sh test/e2e/specs/smoke.spec.ts smoke无头 Linux 下 harness 跑在 Xvfb 虚拟显示上macOS 用户可通过 Docker 复用同一 Linux harnessdocker compose -f e2e/docker-compose.yml run --rm e2e要求 Docker Desktop 或 Colima仓库以 bind mount 方式挂载构建产物在多次运行间保留。E2E 仓库中已有大量现成 spec 可作范式参考app/test/e2e/specs/ 下共 90 个.spec.ts如chat-harness-send-stream.spec.ts、auth-access-control.spec.ts、notifications.spec.ts。编写跨平台 spec 的要点一律使用 element-helpers.ts 的辅助函数clickNativeButton、hasAppChrome、waitForWebView等绝不裸用XCUIElementType*选择器优先使用稳定的data-testid钩子命名规范surface-element-id?如cron-job-toggle-jobId、thread-row-threadId文本选择器只用于用户可见文案断言。失败时wdio.conf.ts的afterTest钩子会把failure-*.png与failure-*.source.xml写入运行目录若要完整的可审计运行截图 页面源码 mock 请求日志落盘运行bash app/scripts/e2e-agent-review.sh产物落在app/test/e2e/artifacts/timestamp-agent-review/。Agent 可观测性Agent Observability 描述的是 artifact-capture 层它让 E2E 与 Agent 运行在事后可调试。这是测试体系的横向能力配合测试矩阵作为契约使用——docs/TEST-COVERAGE-MATRIX.md 中每个特性叶子要么映射到测试路径要么给出带理由的加手动冒烟条目增删改特性时必须在同一 PR 内更新矩阵行。发布流程与 OAuth 版本门槛分发渠道GitHub Releases 是桌面构建的主分发源Tauri updater 端点见 scripts/prepareTauriConfig.js应指向当前发布产物退役旧稳定版时需同步清理移除/隐藏 GitHub Release 上的过时安装器、更新网站/CDN 下载链接、刷新 updater manifest如 scripts/fixtures/latest.json并抽查旧直链是否已重定向/404/410。最小应用版本门槛OAuth 防护生产 Web 构建在构建期内嵌一个最低支持应用 semver使 OAuth 深链无法在过时二进制上完成——这尤其保护 Gmail 等 OAuth 流程。相关变量变量作用VITE_MINIMUM_SUPPORTED_APP_VERSION例如0.51.0——桌面应用必须 ≥ 该版本才能完成openhuman://oauth/successVITE_LATEST_APP_DOWNLOAD_URL可选默认指向releases/latest。门槛拦截 OAuth 时打开二者配置为 GitHub Actions variables且必须同时出现在 .github/workflows/build-desktop.yml 的独立pnpm build步骤与tauri-apps/tauri-action步骤 env 中该复用矩阵由release-production.yml/release-staging.yml调用确保随安装包分发的 Vite bundle 包含该门槛。本地开发请保持VITE_MINIMUM_SUPPORTED_APP_VERSION未设置门槛禁用。实现位于 app/src/utils/oauthAppVersionGate.ts 与desktopDeepLinkListener.ts。分支模型与 CI 车道两条长期分支、两条 CI 车道main——所有特性/修复 PR 的落点。每个 PR及对 main 的 push运行CI Lite.github/workflows/ci-lite.yml按变更区域做质量检查 限定到变更文件的单元测试由PR CI Gate把关 ≥ 80% diff 覆盖率。release——维护者从main提升的快照发布从它切出。面向release的 PR 与每次 push 运行CI Full.github/workflows/ci-full.yml完整单元套件、Rust mock-backend E2E、Playwright web E2E以及 Linux/macOS/Windows 全量桌面 E2E 矩阵。CI Full Gate聚合除 Playwright spec 运行外的所有车道Playwright 因 CI 争用下的不稳定性暂为continue-on-error的非阻塞信号切版前需人工查看该车道结果。循环过程promote-main-to-release.yml把 main 以 merge commit 推入 release无 PR→ CI Full 在提升 push 上运行 → 通过后以release-production.yml切生产。从release切出的版本会通过 scripts/release/merge-release-into-main.sh 把 release 回并到 main尽可能 fast-forward否则生成chore(release): merge release vX.Y.Z back into main这样的版本化合并提交。版本号 bump 提交携带[skip ci]。staging 与 production 两套工作流工作流分支版本号打的 tag并发组何时使用release-staging.ymlmain或release仅patchvversion-stagingrelease-staging为 QA 从所选分支切 staging 构建release-production.ymlreleasepatch/minor/majorrelease_type输入vversionrelease-production从验证过的 release HEAD或固定commit_sha发布生产版本没有独立的staging分支——staging 切版与生产发布都活在release上仅以 tag 后缀-staging与否和工作流来源区分。staging tag 用 SemVer 预发布后缀-staging如v1.2.4-staging在排序上先于匹配的生产 tag。失败自动回滚构建矩阵失败会删除 draft Release 与对应 tag生产/ 仅删除-stagingtagstagingbump 提交保留下次从新 patch 号继续。发布 App token 的审批门与季度轮换release-production.yml用 GitHub App tokenXGITHUB_APP_ID/XGITHUB_APP_PRIVATE_KEY完成 bump、向release提交、回并main并推送提交 tag——该 token绕过分支保护因此泄露风险被两道控制约束人工审批门review-approvaljob 在prepare-build之前运行将每个生产 run 停在Release-ApprovalGitHub environment 上必须先有人工审批才会发生任何 push。季度密钥轮换每季度3/6/9/12 月末及任何疑似泄露时立即轮换XGITHUB_APP_PRIVATE_KEY——在 App settings 生成新私钥 → 更新仓库 secret → 用低风险的Release (Staging)验证 token 步骤 → 删除旧私钥 → 记录轮换日期。深入理解核心子系统Agent Harnesstinyagents 驱动Agent Harness 讲解基于 tinyagents 的 turn loop检查点checkpointing、熔断器circuit breakers、子 Agent 交还sub-agent handback、journals/replay以及如何扩展工具表面。如根 Cargo.toml 所述tinyagents 已被拆分为一组聚焦 crateOpenHuman 直接依赖tinyagents-harnessagent loop / tools / middleware、tinyagents-graph持久状态图、tinyagents-language.rag、tinyagents-registry与tinyagents-session——26 个领域消费 tinyagents是 agent 引擎与编排的地基。Workflowstinyflows 支撑Workflows 介绍flows领域触发器、信任源trust origins、审批门控运行approval-gated runs与flows_*RPC 表面。tinyflows 是宿主无关的工作流引擎类型化节点图 → 校验 → 编译 → 在 tinyagents 上运行其mockfeature 提供的确定性内存能力包让dry_run_workflowagent 工具可以在零副作用下自校验草稿图。Chromium Embedded FrameworkCEFcef.md 说明内嵌 provider webview 的工作方式为什么它们不运行注入的 JS以及 per-provider scanner 取而代之做什么。这也是为什么 Tauri shell 使用 vendor 的tauri-runtime-cef以及为什么 macOS 会出现 CEF 缓存锁冲突。对于仍在构建中的特性Subconscious Loop 页面覆盖后台任务评估系统的端到端设计。贡献规范在 upstreamtinyhumansai/openhuman开 issue 与 PRPR 目标是main。推送到自己的 fork而非 upstream遵循 CONTRIBUTING.md 与 issue/PR 模板保持改动聚焦修 bug 不需要附带周边清理一次性操作不需要抽 helper。仓库还有 AGENTS.md、CONTRIBUTING-BEGINNERS.md 等面向不同读者的协作文档。正如 README 末尾所说向构建 AGI 迈进不一定意味着提交内核——bug 修复、文档、集成与测试同样在推动进度条。一句话总结本文的技术闭环先按 getting-set-up.md 搭好 pnpm Rust 1.93.0 vendor 子模块环境用pnpm dev/cargo build --bin openhuman-core跑起桌面应用或纯核心写代码时按 testing-strategy.md 的决策树把测试放进 Rust unit / Rust integration / Vitest / WDIO 四层之一保证改动行 ≥ 80% 覆盖率并通过PR CI Gate合并进main后由维护者经 promote-main-to-release.yml 提升到releaseCI Full 全绿后走 release-production.yml 完成带 OAuth 版本门槛的正式发布。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenHuman 开发者指南：从源码构建、测试到发布的完整工作流
OpenHuman 开发者指南从源码构建、测试到发布的完整工作流【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhumanOpenHuman 是一个面向 Mac、Windows、Linux 的开源个人 AI 桌面应用React Tauri v2 前端 Rust 核心GPLv3 协议。本篇技术指南以仓库中的开发者文档 gitbooks/developing/README.md 为主线系统梳理从零开始克隆仓库、搭建工具链、构建桌面应用与 Rust 核心、分层编写测试到走完发布流程的完整开发闭环。读完本文你将掌握 OpenHuman 仓库的目录组织、精确的构建命令、测试分层决策方法以及main/release双分支发布模型下的实际发布操作。仓库布局四块核心区域OpenHuman 是一个 monorepo所有代码按职责集中在四个顶层目录中。理解这张表是阅读任何源码的前提路径内容app/pnpm workspaceopenhuman-appVite React 前端app/src/与 Tauri 桌面宿主app/src-tauri/src/Rust crateopenhuman_core与openhuman-coreCLI 二进制领域逻辑、JSON-RPC、MCP 路由gitbooks/面向公众的文档站本文所在目录docs/尚未迁移到 GitBook 的深度参考文档记忆管线图、Agent 流程等根目录的 CLAUDE.md 是 AI Agent 在该代码库上工作的事实来源source of truth同样的规则也适用于人类贡献者。它明确指出了逻辑所在的分界Rust 核心src/承载全部业务逻辑、执行、领域、RPC、持久化与 CLITauri Reactapp/只负责 UX、界面、导航与桥接是展示与编排层而非特性所在层。值得注意的细节CLAUDE.md 说明核心以 in-process 方式运行——Tauri 宿主通过core_process::CoreProcessHandle将 Rust 核心作为 tokio 任务内嵌sidecar 模式已在 PR #1061 移除前端 RPC 走http://127.0.0.1:port/rpc携带每次启动随机生成的 hex bearer token。OPENHUMAN_CORE_TOKEN对 CLI / docker / cloud 场景仍然生效。从哪里开始推荐的阅读路线文档为首次拉取仓库的开发者规划了明确的阅读顺序依次覆盖能跑起来 → 能编译核心 → 能理解架构 → 能写测试构建与安装Getting Set Up工具链、依赖、vendor 的 Tauri CLI、sidecar staging——让pnpm dev真正启动起来所需的一切构建 Rust 核心Building the Rust Core仅针对仓库根 Rust crate 的全新机器搭建固定的工具链版本、操作系统包、精确的cargo命令架构Architecture桌面应用、Rust 核心 sidecar、JSON-RPC 桥接、双 socket 如何拼合——做任何非平凡修改前先读它前端Frontend 与 Tauri ShellReact 应用与其外的桌面宿主MCP Server可选的 stdio MCP 模式用于向本地客户端暴露只读的 OpenHuman 记忆工具。从仓库根 package.json 可以看到 workspace 的管理方式根包是私有包openhuman-repopackageManager固定为pnpm10.10.0sha512...并通过patchedDependencies对assistant-ui/react-lexical0.2.10应用了 app/patches/ 下的补丁。这种根仓库只做编排、openhuman-app承载应用的结构贯穿所有 npm script。环境准备与工具链必需的软件版本依赖版本要求依据Node.js24 或更新app/package.jsonpnpm10.10.0根 package.json 的packageManager字段Rust1.93.0rustup 安装含rustfmt、clippyrust-toolchain.tomlCMake最新稳定版原生 Rust 依赖编译所需Git 子模块app/src-tauri/vendor/vendor 的 CEF-aware Tauri CLI 需要平台构建工具macOSXcode Command Line ToolsLinuxTauri 的 GTK/WebKit/AppIndicator 包组见下文macOSHomebrew快速开始brew install node24 pnpm rustup-init cmake rustup toolchain install 1.93.0 --profile minimal rustup component add rustfmt clippy --toolchain 1.93.0Arch Linux 快速开始sudo pacman -S --needed nodejs npm rustup cmake base-devel clang openssl \ alsa-lib xdotool libxtst libxi libevdev gtk3 webkit2gtk-4.1 \ libayatana-appindicator librsvg patchelf nss nspr at-spi2-core \ libcups libdrm libxkbcommon libxcomposite libxdamage libxfixes \ libxrandr mesa pango cairo libxshmfence npm install -g pnpm10.10.0 rustup toolchain install 1.93.0 --profile minimal rustup component add rustfmt clippy --toolchain 1.93.0子模块与 vendor 体系OpenHuman 的核心子系统大量运行在发布为独立 crate 的tiny*家族上tinyagents、tinyflows、tinychannels、tinymemory、tinybus等它们以 git 子模块形式 vendor 在vendor/下以便在发布前于本仓库内直接测试 crate 变更。从根 Cargo.toml 的依赖注释可以看出这套体系的分工原则例如Agent 引擎基于tinyagents每一轮 agent turn 都经由src/openhuman/agent/tinyagents/的适配接缝穿过 harness记忆引擎基于tinycortex通过tinymemory的 vendor 副本访问OpenHuman 保留 RPC、工具、调度、凭据、安全策略等宿主侧逻辑推理基于 crate 原生的ModelRouter/OpenAiModel做工作负载分层路由。克隆仓库后务必执行git submodule update --init --recursive构建桌面壳时需要而纯核心开发则不需要子模块。相关依赖声明如tinyhumans-sdk、tinymcp都在注释里标注了对应的初始化命令例如git submodule update --init vendor/tinymcp。构建桌面应用本地编译从仓库根执行以下命令即可完成一次完整的源码构建# 1) 克隆并进入仓库 git clone https://github.com/tinyhumansai/openhuman.git cd openhuman # 2) 拉取 vendor 的 Tauri/CEF 源码 git submodule update --init --recursive # 3) 安装 JS 依赖workspace 级 pnpm install # 4) 构建桌面应用产物 pnpm build本地开发而非生产构建时# 仅 Web UI 开发Vite dev server pnpm dev # 桌面应用开发使用 vendor 的 Tauri/CEF CLI须在 workspace 根执行 pnpm --filter openhuman-app dev:app根 package.json 提供了配套的完整脚本矩阵pnpm typecheck即tsc --noEmit/compile、pnpm lintESLint --cache、pnpm format:checkPrettier cargo fmt --check、pnpm test:rust调用 scripts/test-rust-with-mock.sh等均可从仓库根直接运行。通过官方安装脚本安装稳定版macOS / Linux x64 的常规安装curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash安装脚本行为解析当前平台的最新稳定版、在可用时校验产物摘要、默认本地安装无需 sudomacOS 安装OpenHuman.app到~/ApplicationsLinux x64 将 AppImage 安装为~/.local/bin/openhuman并写入桌面条目。可用--dry-run预览动作而不落盘curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash -s -- --dry-runWindows 使用 PowerShellirm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex仓库还附带 packages/arch/openhuman-bin/ 的 AUR 配方以官方 x86_64 AppImage 为二进制源makepkg时解包应用树、安装桌面条目并暴露/usr/bin/openhuman。发布前可本地构建cd packages/arch/openhuman-bin makepkg --syncdeps --install。ARM Linuxaarch64构建ARM 构建因 CEF 与 GTK 依赖需要特殊处理。先安装 Xvfb 用于无头构建/测试然后cd app pnpm tauri build --target aarch64-unknown-linux-gnu运行 ARM 二进制需要设置 CEF 库路径REL_DIRapp/src-tauri/target/aarch64-unknown-linux-gnu/release CEF_DIR$(ls -d $REL_DIR/build/cef-dll-sys-*/out/cef_linux_aarch64 2/dev/null | head -n1) export LD_LIBRARY_PATH$CEF_DIR:$REL_DIR/deps:$REL_DIR${LD_LIBRARY_PATH::$LD_LIBRARY_PATH} $REL_DIR/OpenHuman --no-sandbox或用包装脚本封装上述逻辑推荐。DEB 安装DEB_FILE$(ls app/src-tauri/target/aarch64-unknown-linux-gnu/release/bundle/deb/OpenHuman_*_arm64.deb | head -n1) sudo dpkg -i $DEB_FILE注意ARM 构建要求 GTK 在 Tauri 创建系统托盘前初始化该修复位于vendor/tauri-cef/crates/tauri-runtime-cef/src/lib.rsgtk::init().ok()。若出现 GTK has not been initialized 说明该修复未就位需重新构建。常见故障排查macOSpnpm dev:app报 CEF cache is held by another OpenHuman instanceCEF 通过~/Library/Caches/com.openhuman.app/cef下的SingletonLock符号链接独占其用户数据目录。安装版.app与开发二进制共用同一 bundle idcom.openhuman.app无法并行运行。退出另一实例后重跑pkill -f OpenHuman.app/Contents pkill -f openhuman-core pnpm dev:app若锁由崩溃进程残留PID 已不存在preflight 会自动清理过期SingletonLock并继续启动。已知限制dev 与 release 构建仍共享com.openhuman.app缓存标识隔离需要修改 vendor 的tauri-runtime-cef跟踪自 #864。核心端口上的陈旧openhumanRPC 进程core_process::ensure_running会在启动时探测OPENHUMAN_CORE_PORT默认 7788若GET /识别出是 OpenHuman coreJSON 响应含name: openhuman判定为陈旧进程并主动终止Unix 下 SIGTERM 后 750ms SIGKILLWindows 下taskkill /F /T /PID随后宿主拉起全新内嵌核心若端口被其他服务占用则大声报错而非静默挂接。设置OPENHUMAN_CORE_REUSE_EXISTING1可回到旧的挂接任意进程行为用于手动调试 harness。手动清理依然有效pkill -f OpenHuman.app/Contents pkill -f openhuman-core仅构建 Rust 核心core-only 工作流如果你只关心仓库根 Rust crate不需要桌面壳使用 Building the Rust Core 的流程Cargo 包名openhuman可运行二进制openhuman-core入口 src/main.rs库openhuman_coreCargo.toml 的[lib]段crate-type [rlib]。# 快速依赖 类型检查 cargo check --manifest-path Cargo.toml # 调试构建 CLI / RPC 二进制 cargo build --manifest-path Cargo.toml --bin openhuman-core # Release 构建 cargo build --manifest-path Cargo.toml --release --bin openhuman-core # Rust 测试 cargo test --manifest-path Cargo.toml产物落在target/debug/openhuman-core或target/release/openhuman-core。若偏好面向包的命令如打包脚本用-p openhuman。加速本地链接可选openhuman核心 crate 链接的是单个巨型 rlib编辑 →cargo check/cargo test的内循环经常受链接瓶颈约束。用 moldLinux或 lldmacOS可显著缩短增量重链时间。仓库提供幂等的配置脚本它把检测结果写入$CARGO_HOME/config.toml绝不改动仓库内跟踪的.cargo/config.toml属于每台机器的可选开启scripts/dev-setup-linker.sh # 安装 mold/lld 检测 scripts/dev-setup-linker.sh --dry-run # 先预览变更需先安装链接器apt install mold/brew install llvm脚本检测不到会打印指引并退出。CI 的 Linux Rust 任务直接通过RUSTFLAGS启用同一标志。各平台系统包前置条件macOSxcode-select --install。whisper-rs在构建期间编译原生代码macOS 上该 crate 以metalfeature 构建需要 Apple 工具链与 SDK 头文件。Ubuntu / Debiancore-only 最小集sudo apt-get update sudo apt-get install -y \ build-essential cmake pkg-config clang libssl-dev libclang-dev \ libasound2-dev libxi-dev libxtst-dev libxdo-dev libudev-dev \ libstdc-14-devArchcore-onlysudo pacman -S --needed base-devel cmake pkgconf clang openssl \ alsa-lib libxi libxtst xdotool libevdevWindowsrustup Visual Studio Build Tools 2022Desktop development with C 工作负载MSVC 目标x86_64-pc-windows-msvc。注意用 MSVC 而非 MinGW——仓库给whisper-rs-sys打了补丁以强制静态 MSVC CRT规避LNK2038/LNK1169错误。一个典型的坑whisper-rs-sys在 clang 下可能报fatal error: array file not found这正是文档点名libstdc-14-dev的原因clang 可能选中 Ubuntu runner 上的 GCC 14 C 头文件。若仍无法解析libstdc.so可用 AGENTS.md 中记录的软链方案按实际 GCC 版本调整。构建桌面壳而非 core-only时需使用更宽的依赖集GTK/WebKit/AppIndicator 等详见 building-rust-core.md 第 5 节两套清单都镜像自 .github/workflows/build-desktop.yml。三层测试体系你的改动该写在哪里OpenHuman 对测试分层有非常明确的约定。核心原则把测试压到尽可能低的层级Rust unit Rust integration Vitest WDIO低层更快、更确定、更便宜WDIO 只用于真正跨越 UI ⇄ Tauri ⇄ sidecar ⇄ JSON-RPC 的行为。五个测试层级总览层级位置测试内容驱动方式Rust 单元#[cfg(test)] mod tests同文件或tests.rs或领域下tests/子目录如src/openhuman/channels/tests/纯领域逻辑、schema、RPC handler 形状、内存状态机cargo testRust 集成仓库根tests/*.rs真实 Tokio 运行时下的完整领域接线、mock 外部服务、JSON-RPC 端到端如 tests/json_rpc_e2e.rs、领域 × 领域交互pnpm test:rust即bash scripts/test-rust-with-mock.shVitest 单元app/src/**下与源码同目录的*.test.ts(x)或app/src/**/__tests__/React 组件、hooks、store slices、纯工具、服务层适配器pnpm test:unitWDIO E2Eapp/test/e2e/specs/*.spec.ts完整桌面流UI → Tauri → in-process 核心 → JSON-RPC用户可见行为全平台走 Appium Chromium driver端口 4723面向 CEF 运行时手动冒烟docs/RELEASE-MANUAL-SMOKE.md驱动无法断言的 OS 级表面TCC 权限弹窗、Gatekeeper、代码签名、DMG 安装、OS 原生 toast发布切版时人工执行并在 release PR 签署决策树测试放哪层改动在 JSON-RPC 边界之后src/ 内 ├─ YES - 跨领域或与外部队话 │ ├─ YES → Rust 集成tests/*.rs │ └─ NO → Rust 单元源码旁 └─ NO - 改动在 app/ 内 ├─ 是纯函数 / hook / slice / 独立组件 │ └─ YES → Vitest 单元*.test.tsx 同目录 └─ 用户可见 且 跨越 UI ⇄ Tauri ⇄ sidecar ⇄ JSON-RPC ├─ YES → WDIO E2Eapp/test/e2e/specs/*.spec.ts └─ 属于 OS 级TCC、Gatekeeper、安装、OS toast └─ YES → 手动冒烟清单如果一个改动涉及多个层级每一层都要写对应的测试不能用一层替代另一层。关键质量门槛失败路径要求覆盖矩阵中每个特性叶子除 happy path 外必须有至少一条失败/边界断言。例如文件写入工具happy 写入了字节failure 路径限制拒绝。只断言 happy path 的 spec 是不完整的。覆盖率门槛PR 必须通过改动行 ≥ 80% 覆盖率的PR CI Gate检查。为新增行为补测试而不只是 happy path。Cargo.toml 中还专门用build.rs把 tests/raw_coverage/ 下约 76 个独立tests/*.rs目标折叠进单一raw_coverage_all集成目标省去约 75 次整 crate 重链。Mock 策略单元/集成/E2E 一律不得访问真实网络。统一使用共享 mock 后端scripts/mock-api-core.mjs、scripts/mock-api-server.mjs、app/test/e2e/mock-server.ts管理端点包括GET /__admin/health、POST /__admin/reset、POST /__admin/behavior、GET /__admin/requests。Telegram、Slack、Gmail、Notion、Ollama、OpenAI 等外部服务都在 mock 层打桩测试通过getRequestLog()断言请求形状。确定性规则不用墙钟等待用waitForApp/waitForWebView等辅助每个 E2E spec 运行在隔离的OPENHUMAN_WORKSPACE中spec 不得依赖执行顺序避免绝对坐标与动画时序优先用browser.execute(...)合成键盘输入。合并前的本地检查清单# Rust core cargo fmt --check cargo check --manifest-path Cargo.toml cargo clippy --manifest-path Cargo.toml -- -D warnings cargo test --manifest-path Cargo.toml # Tauri shell cargo check --manifest-path app/src-tauri/Cargo.toml # Frontend pnpm typecheck pnpm lint pnpm format:check pnpm test:unit # Rust integration with mock backend pnpm test:rust # E2E慢仅当行为有用户可见变化时 pnpm test:e2e:build bash app/scripts/e2e-run-spec.sh test/e2e/specs/your-spec.spec.ts idE2E 快速上手桌面 E2E 用 WebDriverIO 通过 Appium 驱动 Tauri 应用Linux 与 macOS 均使用Appium Chromium driver端口 4723CEF 运行时CSS/DOM 选择器。# 一次性安装 Appium Chromium driver npm install -g appium3 appium driver install --sourcenpm appium-chromium-driver # 构建 E2E 应用 pnpm --filter openhuman-app test:e2e:build # 运行全部 flows pnpm --filter openhuman-app test:e2e:all:flows # 运行单个 spec bash app/scripts/e2e-run-spec.sh test/e2e/specs/smoke.spec.ts smoke无头 Linux 下 harness 跑在 Xvfb 虚拟显示上macOS 用户可通过 Docker 复用同一 Linux harnessdocker compose -f e2e/docker-compose.yml run --rm e2e要求 Docker Desktop 或 Colima仓库以 bind mount 方式挂载构建产物在多次运行间保留。E2E 仓库中已有大量现成 spec 可作范式参考app/test/e2e/specs/ 下共 90 个.spec.ts如chat-harness-send-stream.spec.ts、auth-access-control.spec.ts、notifications.spec.ts。编写跨平台 spec 的要点一律使用 element-helpers.ts 的辅助函数clickNativeButton、hasAppChrome、waitForWebView等绝不裸用XCUIElementType*选择器优先使用稳定的data-testid钩子命名规范surface-element-id?如cron-job-toggle-jobId、thread-row-threadId文本选择器只用于用户可见文案断言。失败时wdio.conf.ts的afterTest钩子会把failure-*.png与failure-*.source.xml写入运行目录若要完整的可审计运行截图 页面源码 mock 请求日志落盘运行bash app/scripts/e2e-agent-review.sh产物落在app/test/e2e/artifacts/timestamp-agent-review/。Agent 可观测性Agent Observability 描述的是 artifact-capture 层它让 E2E 与 Agent 运行在事后可调试。这是测试体系的横向能力配合测试矩阵作为契约使用——docs/TEST-COVERAGE-MATRIX.md 中每个特性叶子要么映射到测试路径要么给出带理由的加手动冒烟条目增删改特性时必须在同一 PR 内更新矩阵行。发布流程与 OAuth 版本门槛分发渠道GitHub Releases 是桌面构建的主分发源Tauri updater 端点见 scripts/prepareTauriConfig.js应指向当前发布产物退役旧稳定版时需同步清理移除/隐藏 GitHub Release 上的过时安装器、更新网站/CDN 下载链接、刷新 updater manifest如 scripts/fixtures/latest.json并抽查旧直链是否已重定向/404/410。最小应用版本门槛OAuth 防护生产 Web 构建在构建期内嵌一个最低支持应用 semver使 OAuth 深链无法在过时二进制上完成——这尤其保护 Gmail 等 OAuth 流程。相关变量变量作用VITE_MINIMUM_SUPPORTED_APP_VERSION例如0.51.0——桌面应用必须 ≥ 该版本才能完成openhuman://oauth/successVITE_LATEST_APP_DOWNLOAD_URL可选默认指向releases/latest。门槛拦截 OAuth 时打开二者配置为 GitHub Actions variables且必须同时出现在 .github/workflows/build-desktop.yml 的独立pnpm build步骤与tauri-apps/tauri-action步骤 env 中该复用矩阵由release-production.yml/release-staging.yml调用确保随安装包分发的 Vite bundle 包含该门槛。本地开发请保持VITE_MINIMUM_SUPPORTED_APP_VERSION未设置门槛禁用。实现位于 app/src/utils/oauthAppVersionGate.ts 与desktopDeepLinkListener.ts。分支模型与 CI 车道两条长期分支、两条 CI 车道main——所有特性/修复 PR 的落点。每个 PR及对 main 的 push运行CI Lite.github/workflows/ci-lite.yml按变更区域做质量检查 限定到变更文件的单元测试由PR CI Gate把关 ≥ 80% diff 覆盖率。release——维护者从main提升的快照发布从它切出。面向release的 PR 与每次 push 运行CI Full.github/workflows/ci-full.yml完整单元套件、Rust mock-backend E2E、Playwright web E2E以及 Linux/macOS/Windows 全量桌面 E2E 矩阵。CI Full Gate聚合除 Playwright spec 运行外的所有车道Playwright 因 CI 争用下的不稳定性暂为continue-on-error的非阻塞信号切版前需人工查看该车道结果。循环过程promote-main-to-release.yml把 main 以 merge commit 推入 release无 PR→ CI Full 在提升 push 上运行 → 通过后以release-production.yml切生产。从release切出的版本会通过 scripts/release/merge-release-into-main.sh 把 release 回并到 main尽可能 fast-forward否则生成chore(release): merge release vX.Y.Z back into main这样的版本化合并提交。版本号 bump 提交携带[skip ci]。staging 与 production 两套工作流工作流分支版本号打的 tag并发组何时使用release-staging.ymlmain或release仅patchvversion-stagingrelease-staging为 QA 从所选分支切 staging 构建release-production.ymlreleasepatch/minor/majorrelease_type输入vversionrelease-production从验证过的 release HEAD或固定commit_sha发布生产版本没有独立的staging分支——staging 切版与生产发布都活在release上仅以 tag 后缀-staging与否和工作流来源区分。staging tag 用 SemVer 预发布后缀-staging如v1.2.4-staging在排序上先于匹配的生产 tag。失败自动回滚构建矩阵失败会删除 draft Release 与对应 tag生产/ 仅删除-stagingtagstagingbump 提交保留下次从新 patch 号继续。发布 App token 的审批门与季度轮换release-production.yml用 GitHub App tokenXGITHUB_APP_ID/XGITHUB_APP_PRIVATE_KEY完成 bump、向release提交、回并main并推送提交 tag——该 token绕过分支保护因此泄露风险被两道控制约束人工审批门review-approvaljob 在prepare-build之前运行将每个生产 run 停在Release-ApprovalGitHub environment 上必须先有人工审批才会发生任何 push。季度密钥轮换每季度3/6/9/12 月末及任何疑似泄露时立即轮换XGITHUB_APP_PRIVATE_KEY——在 App settings 生成新私钥 → 更新仓库 secret → 用低风险的Release (Staging)验证 token 步骤 → 删除旧私钥 → 记录轮换日期。深入理解核心子系统Agent Harnesstinyagents 驱动Agent Harness 讲解基于 tinyagents 的 turn loop检查点checkpointing、熔断器circuit breakers、子 Agent 交还sub-agent handback、journals/replay以及如何扩展工具表面。如根 Cargo.toml 所述tinyagents 已被拆分为一组聚焦 crateOpenHuman 直接依赖tinyagents-harnessagent loop / tools / middleware、tinyagents-graph持久状态图、tinyagents-language.rag、tinyagents-registry与tinyagents-session——26 个领域消费 tinyagents是 agent 引擎与编排的地基。Workflowstinyflows 支撑Workflows 介绍flows领域触发器、信任源trust origins、审批门控运行approval-gated runs与flows_*RPC 表面。tinyflows 是宿主无关的工作流引擎类型化节点图 → 校验 → 编译 → 在 tinyagents 上运行其mockfeature 提供的确定性内存能力包让dry_run_workflowagent 工具可以在零副作用下自校验草稿图。Chromium Embedded FrameworkCEFcef.md 说明内嵌 provider webview 的工作方式为什么它们不运行注入的 JS以及 per-provider scanner 取而代之做什么。这也是为什么 Tauri shell 使用 vendor 的tauri-runtime-cef以及为什么 macOS 会出现 CEF 缓存锁冲突。对于仍在构建中的特性Subconscious Loop 页面覆盖后台任务评估系统的端到端设计。贡献规范在 upstreamtinyhumansai/openhuman开 issue 与 PRPR 目标是main。推送到自己的 fork而非 upstream遵循 CONTRIBUTING.md 与 issue/PR 模板保持改动聚焦修 bug 不需要附带周边清理一次性操作不需要抽 helper。仓库还有 AGENTS.md、CONTRIBUTING-BEGINNERS.md 等面向不同读者的协作文档。正如 README 末尾所说向构建 AGI 迈进不一定意味着提交内核——bug 修复、文档、集成与测试同样在推动进度条。一句话总结本文的技术闭环先按 getting-set-up.md 搭好 pnpm Rust 1.93.0 vendor 子模块环境用pnpm dev/cargo build --bin openhuman-core跑起桌面应用或纯核心写代码时按 testing-strategy.md 的决策树把测试放进 Rust unit / Rust integration / Vitest / WDIO 四层之一保证改动行 ≥ 80% 覆盖率并通过PR CI Gate合并进main后由维护者经 promote-main-to-release.yml 提升到releaseCI Full 全绿后走 release-production.yml 完成带 OAuth 版本门槛的正式发布。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
