OpenHuman 日常开发实战从 dev-agent 看 React 组件、Tauri 命令与插件接入规范【免费下载链接】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 仓库在 .claude/agents/dev-agent.md 中定义了一个面向日常开发的子 Agentdev-agent它把创建 React 组件、编写 Tauri 命令、添加插件、配置开发环境这四类高频任务固化成了可复制的模板与命令。读懂这份文档再对照仓库中 app/src-tauri/src/lib.rs 的真实命令实现与 app/src/utils/tauriCommands/core.ts 的前端调用约定你就能完整掌握在这个 Tauri React Rust 代码库里新增功能的标准路径声明命令、注册 handler、前端 invoke、跑测试与 lint。dev-agent 是什么一份固化的开发 SOPdev-agent 是 Claude Code 的 subagent 定义文件采用 YAML frontmatter Markdown 正文的结构--- name: dev-agent description: Assists with day-to-day development tasks, code generation, and feature implementation model: model-sonnet color: teal ---frontmatter 中的name用于在.claude/agents/目录下标识该 Agentdescription描述其职责边界model指定使用的模型。它的定位是日常开发任务、代码生成、功能实现核心能力被明确限定为四项生成 React 组件Generate React components创建 Tauri 命令Create Tauri commands安装配置插件Set up plugins配置开发环境Configure development environment从源码结构看这个目录还并列存放了 test-agent、pr-reviewer、mobile-agent 等按职责拆分的子 Agentdev-agent 是其中专注写功能的一个。以下各节按文档的四大能力展开并用仓库真实代码印证每一步。创建新的 React 组件文档给出的模板dev-agent 文档中Create New Component一节给出两步操作# Create component file touch src/components/MyComponent.tsx然后套入如下函数式组件模板import { FC } from react; import ./MyComponent.css; interface MyComponentProps { title: string; } export const MyComponent: FCMyComponentProps ({ title }) { return ( div classNamemy-component h2{title}/h2 /div ); };模板体现了文档Code Style / TypeScript一节的四条规范函数式组件 hooks、所有 props 和 state 必须有类型interface MyComponentProps、通过invoke调用 Tauri 命令、错误处理用 try/catch。在本仓库中的落点需要注意仓库目录布局前端代码位于app/工作区下因此文档中的相对路径在本仓库对应app/src/components/该目录下有数百个.tsx组件。命令实际在app/目录执行时写作touch app/src/components/MyComponent.tsx组件创建完成后验证手段在 app/package.json 中已经就绪pnpm lintESLint、pnpm compiletsc --noEmit类型检查、pnpm testVitest。仓库还配有knip做未使用代码检测新增组件若未被引用会被这类工具捕获。创建 Tauri 命令声明、注册、调用三步走这是 dev-agent 文档中技术含量最高的部分对应仓库中前端 ⇄ Rust 内核通信的核心机制。文档给出的三步流程如下。第一步在 lib.rs 中声明命令文档要求在src-tauri/src/lib.rs中添加#[tauri::command] fn my_command(arg: String) - ResultString, String { Ok(format!(Received: {}, arg)) }在真实仓库中该文件是 app/src-tauri/src/lib.rs约 3700 行是整个桌面 shell 的命令层。一个真实的同步 异步混合命令例子是core_rpc_url/// Tauri command: where the renderer should send core JSON-RPC. #[tauri::command] async fn core_rpc_url( desktop: tauri::State_, core_process::CoreProcessHandle, ) - ResultString, String { Ok(active_rpc_endpoint(desktop.inner()).await.0) }见 app/src-tauri/src/lib.rs#L113-L124对照文档Code Style / Rust一节的四条规则这段真实代码恰好全部命中命令用#[tauri::command]宏标注可失败操作返回ResultT, E共享状态通过StateCoreProcessHandle注入Tauri 的依赖注入点由 builder 在启动时manage涉及 I/O 的命令这里要查询 active gateway声明为async。第二步在 builder 中注册 handler文档要求把命令加入 builder.invoke_handler(tauri::generate_handler![my_command])在 app/src-tauri/src/lib.rs#L3369 可以看到真实的注册点tauri::generate_handler![...]宏内是一个显式清单.invoke_handler(tauri::generate_handler![ core_rpc_url, core_rpc_token, core_rpc_endpoint, // ... check_core_update, apply_core_update, check_app_update, apply_app_update, restart_core_process, recover_port_conflict, force_quit_port_owner, start_core_process, // ... ])值得注意的工程细节清单里部分命令带条件编译例如 gateway 相关命令写作#[cfg(feature gateways)] gateway::commands::gateway_list。注释解释了设计意图——feature 关闭时命令absent, not stubbed干脆不注册而不是注册一个运行时才报错的桩函数让前端可以做特性探测。新增命令时若依赖某个 cargo feature应照此模式处理。第三步前端 invoke文档给出的前端调用import { invoke } from tauri-apps/api/core; const result await invokestring(my_command, { arg: test });仓库中前端对invoke做了集中封装位于 app/src/utils/tauriCommands/core.tsrestartCoreProcess展示了比文档模板更完整的防御式写法export async function restartCoreProcess(): Promisevoid { if (!isTauri()) { console.debug([core] restartCoreProcess: skipped — not running in Tauri); return; } console.debug([core] restartCoreProcess: invoking restart_core_process); await invokevoid(restart_core_process); clearCoreRpcTokenCache(); console.debug([core] restartCoreProcess: done); }两个约定超出文档模板但属于本仓库的硬性实践isTauri()前置守卫——同一套 React 代码也运行在纯 Web 模式pnpm dev的 vite 开发模式下此时tauri-apps/api的invoke不可用所有命令封装都要在入口处判断并优雅降级类型参数显式化——invokevoid/invokestring的泛型保证返回值在编译期就是前端预期的类型。命令名与 Rust 函数名一一对应restart_core_process参数名同样保持 snake_case 与 Rust 侧签名一致这是invoke序列化匹配的前提。插件安装与开发服务器插件文档给出的插件安装命令# Add plugin via CLI npm run tauri add plugin-name # Common plugins: npm run tauri add fs npm run tauri add dialog npm run tauri add http npm run tauri add notification npm run tauri add store在本仓库中app/package.json 已定义tauri: tauri脚本且依赖锁定在 pnpm 工作区packageManager字段与 gitbooks/developing/getting-set-up.md 要求pnpm10.10.0因此实际执行时建议写作pnpm tauri add fs仓库当前已在依赖中使用了多个官方插件如tauri-apps/plugin-opener、tauri-apps/plugin-os、tauri-apps/plugin-deep-link、tauri-apps/plugin-barcode-scanner见 app/package.json 的 dependencies 段可作为常用插件清单的实证参考。开发服务器文档列出的三条命令# Start with hot reload npm run tauri dev # Frontend only npm run dev # Check for issues npm run tauri info对照 app/package.json 的实际 scripts本仓库的对应关系是文档命令仓库实际脚本说明npm run devpnpm dev纯前端 Vite 开发服务器适合快速迭代 UInpm run tauri devpnpm dev:app完整桌面端热重载开发内部调用scripts/run-dev-macos.sh等平台脚本npm run tauri infopnpm tauri info打印工具链诊断信息开发环境的前置条件以 gitbooks/developing/getting-set-up.md 与 rust-toolchain.toml 为准Node.js 24app/package.json的engines字段要求24.0.0pnpm 10.10.0Rust 1.93.0经 rustup 安装含rustfmt与clippyCMake原生 Rust 依赖需要app/src-tauri/vendor/下的 git submodulevendored CEF 版 Tauri CLI首次克隆后按该指南初始化git submodule update --init --recursive pnpm install代码风格规范TypeScript 与 Rust 双侧约定文档Code Style一节是两侧语言的硬性约定汇总可作为 Code Review 的检查清单。TypeScript 侧函数式组件 hooks不写类组件所有 props 和 state 必须有类型调用 Tauri 命令统一走invoke在仓库实践中即走app/src/utils/tauriCommands/下的封装函数而非散落各组件的直接 invoke错误处理用 try/catch。Rust 侧命令一律用#[tauri::command]标注可失败操作返回ResultT, E禁止在命令体内unwrap导致进程级 panic共享状态用State注入做 I/O 的命令保持 async。仓库为这些风格配备了可执行的守门脚本见 app/package.jsonpnpm lintESLint 9、pnpm rust:clippycargo clippy -- -D warnings警告即失败、pnpm rust:format:checkcargo fmt --check、pnpm format:checkprettier 校验。新增代码提交前跑一遍pnpm format:check pnpm lint是低成本的一致性保障。测试前后端双栈验证文档Testing一节给出两条命令# Frontend tests npm test # Rust tests cd src-tauri cargo test在本仓库中对应注意 shell 工程位于app/下cd app pnpm test # vitest run --config test/vitest.config.ts cd src-tauri cargo test # Rust 侧单元测试仓库实际测试面比文档更宽前端单测/组件测试pnpm test、pnpm test:coveragev8 覆盖率测试入口配置在 app/test/vitest.config.ts桌面 shell 的 Rust 测试除cargo test外还有pnpm test:rust即scripts/test-rust-with-mock.sh带 mock 服务端到端pnpm test:e2ePlaywright含 web 与 mega-flow 两条线一键全量pnpm test:all 前端覆盖率 Rust 测试 E2E。以 dev-agent 的产出物视角最小验证回路是改前端组件 →pnpm test新增/修改 Tauri 命令 →cd src-tauri cargo test 前端侧对应tauriCommands单测如 app/src/utils/tauriCommands/core.test.ts。小结一张日常开发命令速查表场景命令在app/目录依据纯前端开发pnpm devapp/package.json桌面端热重载开发pnpm dev:app同上安装 Tauri 插件pnpm tauri add namedev-agent 文档类型检查pnpm compileapp/package.json前端测试pnpm test同上Rust 测试cd src-tauri cargo testdev-agent 文档Rust 静态检查pnpm rust:clippyapp/package.json全量测试pnpm test:all同上dev-agent 文档的价值在于把组件模板 → 命令三步走 → 插件 → 环境 → 测试压缩成一条可执行 SOP而仓库中的真实代码app/src-tauri/src/lib.rs 的命令声明与 L3369 的generate_handler!注册表、app/src/utils/tauriCommands/core.ts 的isTauri守卫与类型化 invoke则补齐了模板之外的工程细节条件编译注册、跨 Web/Tauri 双模式的降级、以及可执行的 lint/test 守门。按此路径开发新增功能的每一步都有对应源码与测试可验证。【免费下载链接】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 日常开发实战：从 dev-agent 看 React 组件、Tauri 命令与插件接入规范
OpenHuman 日常开发实战从 dev-agent 看 React 组件、Tauri 命令与插件接入规范【免费下载链接】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 仓库在 .claude/agents/dev-agent.md 中定义了一个面向日常开发的子 Agentdev-agent它把创建 React 组件、编写 Tauri 命令、添加插件、配置开发环境这四类高频任务固化成了可复制的模板与命令。读懂这份文档再对照仓库中 app/src-tauri/src/lib.rs 的真实命令实现与 app/src/utils/tauriCommands/core.ts 的前端调用约定你就能完整掌握在这个 Tauri React Rust 代码库里新增功能的标准路径声明命令、注册 handler、前端 invoke、跑测试与 lint。dev-agent 是什么一份固化的开发 SOPdev-agent 是 Claude Code 的 subagent 定义文件采用 YAML frontmatter Markdown 正文的结构--- name: dev-agent description: Assists with day-to-day development tasks, code generation, and feature implementation model: model-sonnet color: teal ---frontmatter 中的name用于在.claude/agents/目录下标识该 Agentdescription描述其职责边界model指定使用的模型。它的定位是日常开发任务、代码生成、功能实现核心能力被明确限定为四项生成 React 组件Generate React components创建 Tauri 命令Create Tauri commands安装配置插件Set up plugins配置开发环境Configure development environment从源码结构看这个目录还并列存放了 test-agent、pr-reviewer、mobile-agent 等按职责拆分的子 Agentdev-agent 是其中专注写功能的一个。以下各节按文档的四大能力展开并用仓库真实代码印证每一步。创建新的 React 组件文档给出的模板dev-agent 文档中Create New Component一节给出两步操作# Create component file touch src/components/MyComponent.tsx然后套入如下函数式组件模板import { FC } from react; import ./MyComponent.css; interface MyComponentProps { title: string; } export const MyComponent: FCMyComponentProps ({ title }) { return ( div classNamemy-component h2{title}/h2 /div ); };模板体现了文档Code Style / TypeScript一节的四条规范函数式组件 hooks、所有 props 和 state 必须有类型interface MyComponentProps、通过invoke调用 Tauri 命令、错误处理用 try/catch。在本仓库中的落点需要注意仓库目录布局前端代码位于app/工作区下因此文档中的相对路径在本仓库对应app/src/components/该目录下有数百个.tsx组件。命令实际在app/目录执行时写作touch app/src/components/MyComponent.tsx组件创建完成后验证手段在 app/package.json 中已经就绪pnpm lintESLint、pnpm compiletsc --noEmit类型检查、pnpm testVitest。仓库还配有knip做未使用代码检测新增组件若未被引用会被这类工具捕获。创建 Tauri 命令声明、注册、调用三步走这是 dev-agent 文档中技术含量最高的部分对应仓库中前端 ⇄ Rust 内核通信的核心机制。文档给出的三步流程如下。第一步在 lib.rs 中声明命令文档要求在src-tauri/src/lib.rs中添加#[tauri::command] fn my_command(arg: String) - ResultString, String { Ok(format!(Received: {}, arg)) }在真实仓库中该文件是 app/src-tauri/src/lib.rs约 3700 行是整个桌面 shell 的命令层。一个真实的同步 异步混合命令例子是core_rpc_url/// Tauri command: where the renderer should send core JSON-RPC. #[tauri::command] async fn core_rpc_url( desktop: tauri::State_, core_process::CoreProcessHandle, ) - ResultString, String { Ok(active_rpc_endpoint(desktop.inner()).await.0) }见 app/src-tauri/src/lib.rs#L113-L124对照文档Code Style / Rust一节的四条规则这段真实代码恰好全部命中命令用#[tauri::command]宏标注可失败操作返回ResultT, E共享状态通过StateCoreProcessHandle注入Tauri 的依赖注入点由 builder 在启动时manage涉及 I/O 的命令这里要查询 active gateway声明为async。第二步在 builder 中注册 handler文档要求把命令加入 builder.invoke_handler(tauri::generate_handler![my_command])在 app/src-tauri/src/lib.rs#L3369 可以看到真实的注册点tauri::generate_handler![...]宏内是一个显式清单.invoke_handler(tauri::generate_handler![ core_rpc_url, core_rpc_token, core_rpc_endpoint, // ... check_core_update, apply_core_update, check_app_update, apply_app_update, restart_core_process, recover_port_conflict, force_quit_port_owner, start_core_process, // ... ])值得注意的工程细节清单里部分命令带条件编译例如 gateway 相关命令写作#[cfg(feature gateways)] gateway::commands::gateway_list。注释解释了设计意图——feature 关闭时命令absent, not stubbed干脆不注册而不是注册一个运行时才报错的桩函数让前端可以做特性探测。新增命令时若依赖某个 cargo feature应照此模式处理。第三步前端 invoke文档给出的前端调用import { invoke } from tauri-apps/api/core; const result await invokestring(my_command, { arg: test });仓库中前端对invoke做了集中封装位于 app/src/utils/tauriCommands/core.tsrestartCoreProcess展示了比文档模板更完整的防御式写法export async function restartCoreProcess(): Promisevoid { if (!isTauri()) { console.debug([core] restartCoreProcess: skipped — not running in Tauri); return; } console.debug([core] restartCoreProcess: invoking restart_core_process); await invokevoid(restart_core_process); clearCoreRpcTokenCache(); console.debug([core] restartCoreProcess: done); }两个约定超出文档模板但属于本仓库的硬性实践isTauri()前置守卫——同一套 React 代码也运行在纯 Web 模式pnpm dev的 vite 开发模式下此时tauri-apps/api的invoke不可用所有命令封装都要在入口处判断并优雅降级类型参数显式化——invokevoid/invokestring的泛型保证返回值在编译期就是前端预期的类型。命令名与 Rust 函数名一一对应restart_core_process参数名同样保持 snake_case 与 Rust 侧签名一致这是invoke序列化匹配的前提。插件安装与开发服务器插件文档给出的插件安装命令# Add plugin via CLI npm run tauri add plugin-name # Common plugins: npm run tauri add fs npm run tauri add dialog npm run tauri add http npm run tauri add notification npm run tauri add store在本仓库中app/package.json 已定义tauri: tauri脚本且依赖锁定在 pnpm 工作区packageManager字段与 gitbooks/developing/getting-set-up.md 要求pnpm10.10.0因此实际执行时建议写作pnpm tauri add fs仓库当前已在依赖中使用了多个官方插件如tauri-apps/plugin-opener、tauri-apps/plugin-os、tauri-apps/plugin-deep-link、tauri-apps/plugin-barcode-scanner见 app/package.json 的 dependencies 段可作为常用插件清单的实证参考。开发服务器文档列出的三条命令# Start with hot reload npm run tauri dev # Frontend only npm run dev # Check for issues npm run tauri info对照 app/package.json 的实际 scripts本仓库的对应关系是文档命令仓库实际脚本说明npm run devpnpm dev纯前端 Vite 开发服务器适合快速迭代 UInpm run tauri devpnpm dev:app完整桌面端热重载开发内部调用scripts/run-dev-macos.sh等平台脚本npm run tauri infopnpm tauri info打印工具链诊断信息开发环境的前置条件以 gitbooks/developing/getting-set-up.md 与 rust-toolchain.toml 为准Node.js 24app/package.json的engines字段要求24.0.0pnpm 10.10.0Rust 1.93.0经 rustup 安装含rustfmt与clippyCMake原生 Rust 依赖需要app/src-tauri/vendor/下的 git submodulevendored CEF 版 Tauri CLI首次克隆后按该指南初始化git submodule update --init --recursive pnpm install代码风格规范TypeScript 与 Rust 双侧约定文档Code Style一节是两侧语言的硬性约定汇总可作为 Code Review 的检查清单。TypeScript 侧函数式组件 hooks不写类组件所有 props 和 state 必须有类型调用 Tauri 命令统一走invoke在仓库实践中即走app/src/utils/tauriCommands/下的封装函数而非散落各组件的直接 invoke错误处理用 try/catch。Rust 侧命令一律用#[tauri::command]标注可失败操作返回ResultT, E禁止在命令体内unwrap导致进程级 panic共享状态用State注入做 I/O 的命令保持 async。仓库为这些风格配备了可执行的守门脚本见 app/package.jsonpnpm lintESLint 9、pnpm rust:clippycargo clippy -- -D warnings警告即失败、pnpm rust:format:checkcargo fmt --check、pnpm format:checkprettier 校验。新增代码提交前跑一遍pnpm format:check pnpm lint是低成本的一致性保障。测试前后端双栈验证文档Testing一节给出两条命令# Frontend tests npm test # Rust tests cd src-tauri cargo test在本仓库中对应注意 shell 工程位于app/下cd app pnpm test # vitest run --config test/vitest.config.ts cd src-tauri cargo test # Rust 侧单元测试仓库实际测试面比文档更宽前端单测/组件测试pnpm test、pnpm test:coveragev8 覆盖率测试入口配置在 app/test/vitest.config.ts桌面 shell 的 Rust 测试除cargo test外还有pnpm test:rust即scripts/test-rust-with-mock.sh带 mock 服务端到端pnpm test:e2ePlaywright含 web 与 mega-flow 两条线一键全量pnpm test:all 前端覆盖率 Rust 测试 E2E。以 dev-agent 的产出物视角最小验证回路是改前端组件 →pnpm test新增/修改 Tauri 命令 →cd src-tauri cargo test 前端侧对应tauriCommands单测如 app/src/utils/tauriCommands/core.test.ts。小结一张日常开发命令速查表场景命令在app/目录依据纯前端开发pnpm devapp/package.json桌面端热重载开发pnpm dev:app同上安装 Tauri 插件pnpm tauri add namedev-agent 文档类型检查pnpm compileapp/package.json前端测试pnpm test同上Rust 测试cd src-tauri cargo testdev-agent 文档Rust 静态检查pnpm rust:clippyapp/package.json全量测试pnpm test:all同上dev-agent 文档的价值在于把组件模板 → 命令三步走 → 插件 → 环境 → 测试压缩成一条可执行 SOP而仓库中的真实代码app/src-tauri/src/lib.rs 的命令声明与 L3369 的generate_handler!注册表、app/src/utils/tauriCommands/core.ts 的isTauri守卫与类型化 invoke则补齐了模板之外的工程细节条件编译注册、跨 Web/Tauri 双模式的降级、以及可执行的 lint/test 守门。按此路径开发新增功能的每一步都有对应源码与测试可验证。【免费下载链接】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），仅供参考