OpenHuman Harness 实时审计指南基于 JSON-RPC 的异步子代理编排验证方案【免费下载链接】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导读scripts/debug/harness-live-audit-cases.md是 OpenHuman 仓库中一组面向真实运行环境的调试审计用例说明它通过 JSON-RPC 协议驱动真实 Harnessagent harness执行异步子代理subagent编排场景并使用真实模型凭据验证spawn_subagent、spawn_parallel_agents、wait_subagent与openhuman.subagent_steer等核心调用链的可用性与正确性。阅读本文后你将掌握如何用一条命令在隔离临时工作区中拉起openhuman-core、跑通三大审计场景异步转向、并行研究/编码、跨轮会话复用以及如何解读其输出的 token 用量与成本报表。什么是 Harness Live AuditHarness Live Audit 是 OpenHuman 面向托管后端行为的调试审计debug audit而非 CI 测试。它与普通单元测试的关键区别在于直连真实 Harness审计脚本通过 JSON-RPC 调用openhuman.agent_chat让编排器orchestrator真实执行子代理工具调用而不是 mock 掉 agent 调度层使用真实模型凭据默认走openhuman-backend托管后端需要JWT_TOKEN可选direct-openai直连 OpenAI需要OPENAI_API_KEY或OPENAI_KEY隐私约束严格脚本刻意避免打印 prompt 正文、响应正文、token 明细和 transcript 内容仅输出会话状态、耗时与用量汇总见 scripts/debug/harness-subagent-rpc-audit.mjs 开头的说明。审计的核心价值在于在不依赖正在运行的桌面 core 的前提下用隔离的临时工作区 新拉起的 core 进程验证托管 OpenHuman 后端的子代理编排行为跑完自动清理不留环境残留。快速开始一条命令跑完全部场景文档给出的全量命令如下node scripts/debug/harness-subagent-rpc-audit.mjs --spawn-core --isolated-workspace --model agentic-v1 --scenario all这条命令的含义参数作用--spawn-core审计脚本自己拉起一个openhuman-core进程cargo run --bin openhuman-core -- run --jsonrpc-only而不是连接已有 core--isolated-workspace在系统临时目录创建独立工作区写入审计专用的 agent 定义与 provider 配置--model agentic-v1作为model_override传给openhuman.agent_chat指定托管后端模型--scenario all依次执行async-steer、parallel-research-code、reuse-parent-comm三个场景共享同一个拉起的 core执行前置条件仓库根目录下需要可用cargoRust 工具链Node.js 环境用于运行.mjs脚本并准备好对应 provider 模式的真实凭据见下一节。隔离工作区的两种 provider 模式--isolated-workspace默认采用--provider-mode openhuman-backend流程如下对应 harness-subagent-rpc-audit.mjs 中writeIsolatedOpenHumanBackendConfig、writeIsolatedAppSessionAuth的实现通过mkdtemp创建openhuman-harness-subagent-rpc-audit-*临时目录写入临时后端配置config.tomlapi_url指向托管后端、chat_provider/reasoning_provider/agentic_provider/coding_provider均为openhuman、memory_provider openhuman、embedding_provider none从环境变量JWT_TOKEN读取令牌写入临时auth-profiles.jsonschema_version 1包含app-session:defaulttoken 型 profile作为临时鉴权存储启动openhuman-core并在结束时默认删除整个临时工作区。注意--provider-mode openhuman-backend模式下JWT_TOKEN是必需的。脚本会提示从scripts/load-dotenv.sh或 shell 环境加载缺少时会直接报错。另一条控制路径是--provider-mode direct-openai它会写入一份直连 provider 的临时配置writeIsolatedDirectProviderConfigapi_key OPENAI_API_KEY 或 OPENAI_KEY inference_url https://api.openai.com/v1 default_model gpt-4.1-mini chat_provider openai:gpt-4.1-mini reasoning_provider openai:gpt-4.1-mini agentic_provider openai:gpt-4.1-mini coding_provider openai:gpt-4.1-mini memory_provider openhuman embedding_provider none同时写入[[cloud_providers]]块定义audit_openai云 provider。无论哪种模式配置文件都以0o600权限写入仅当前用户可读避免密钥泄露。--keep-workspace的警告默认情况下临时工作区会被自动删除只有需要本地检查产物如生成的config.toml、auth-profiles.json、session 文件时才应传入--keep-workspace。脚本自身的帮助文本明确提示这可能会留下一个带有真实 API 密钥的临时配置需要妥善处置。拉起的 core 如何工作当传入--spawn-core时脚本会若未显式指定--core-url先通过net.createServer探测一个空闲端口构造http://127.0.0.1:port/rpc生成随机审计 tokenaudit-hex并注入OPENHUMAN_CORE_TOKEN环境变量设置OPENHUMAN_CORE_PORT、OPENHUMAN_CORE_RPC_URL隔离模式下还会设置OPENHUMAN_AGENTBOX_MODE1以cargo run --quiet --bin openhuman-core -- run --host 127.0.0.1 --port port --jsonrpc-only启动子进程--jsonrpc-only表示只暴露 JSON-RPC 服务循环调用core.ping做就绪探测默认最多等待 120 秒每 750ms 重试一次见waitForCore进程提前退出会直接报错审计结束后用SIGTERM优雅关闭 core5 秒内未退出再补SIGKILL。所有 JSON-RPC 请求统一经由rpc()辅助函数发出jsonrpc: 2.0协议、Authorization: Bearer token头、默认超时 600 秒由--rpc-timeout-ms控制并对 HTTP 非 2xx、非 JSON 响应、body.error三种情况做显式报错。CLI 参数速查以下参数来自 harness-subagent-rpc-audit.mjs 的parseArgs默认值均已标注参数说明默认值--scenario nameasync-steer/parallel-research-code/reuse-parent-comm/allasync-steer--core-url urlJSON-RPC 端点OPENHUMAN_CORE_RPC_URL或http://127.0.0.1:7788/rpc--token tokenRPC BearerOPENHUMAN_CORE_TOKEN或workspace/core.token--workspace path包含.openhuman/subagent_sessions.json的工作区OPENHUMAN_WORKSPACE或按active_user.toml推导的用户 workspace--task-key key持久任务键audit-subagent-rpc-timestampbase36--agent-id id请求的子代理 idresearcher隔离模式下未显式指定则为async_audit_worker--model modelopenhuman.agent_chat的model_override空隔离模式下backend 为agentic-v1direct-openai 为gpt-4.1-mini--provider-mode modeopenhuman-backend/direct-openaiopenhuman-backend--rpc-timeout-ms n父 turnagent_chat超时600000--spawn-wait-ms n等待 durable session 进入 running 状态120000--settle-wait-ms n父 turn 返回后等待最终会话状态60000--spawn-core为本审计拉起openhuman-core run --jsonrpc-only关--isolated-workspace配合--spawn-core使用临时工作区与自定义 agent 定义关--keep-workspace不删除隔离临时工作区注意可能残留含密钥的配置关--verbose打印响应字符数与拉起的 core 日志关注意两个约束校验--scenario只接受上述四个枚举值--provider-mode只接受direct-openai与openhuman-backend否则脚本直接抛出参数错误。另外--isolated-workspace必须搭配--spawn-core使用。三大审计场景深度解析场景一async-steer—— 运行中转向该场景验证**异步子代理的持久化 运行中转向steer**链路向编排器发送 prompt要求其恰好调用一次spawn_subagent参数为agent_id取指定 id、task_key取审计标记、blockingfalse、freshfalse且不要调用wait_subagent见spawnPrompt脚本轮询workspace/.openhuman/subagent_sessions.json等待出现currentTaskId非空且status running的会话waitForRunningSession200ms 间隔一旦发现运行中的会话立即调用openhuman.subagent_steer参数为{ taskId, message, mode: steer }在 30 秒内期望返回steered: true等待父 turn 完成再等待会话进入非 running 状态settle-wait-ms输出会话列表。openhuman.subagent_steer的底层实现在 src/openhuman/agent/orchestration/subagent_control.rs它以 namespacesubagent、functionsteer注册 controller输入为必填taskIdsub-…前缀的 spawn 任务 id、必填message、可选modesteer默认或collect输出{ steered, taskId, mode }。注释说明它是受信任的 RPC 控制面与 agent 工具steer_subagent行为一致消息入队后立即返回。同文件还注册了姊妹 controllersubagent_cancel{ cancelled, taskId }对应前端后台任务抽屉的取消能力。该场景的失败判据汇总于脚本尾部未观察到 running 子代理任务、steer 未被接受、task key 对应超过一个 durable 会话、审计后无残留 durable 会话任一命中即整体FAIL并以退出码 1 结束。场景二parallel-research-code—— 并行研究与编码该场景验证编排器的**并行扇出parallel fan-out**能力promptparallelPrompt要求恰好调用一次spawn_parallel_agents包含两个任务worker 1agent_id researcher研究https://example.com并返回包含页面标题或域名用途的简短事实性笔记worker 2agent_id code_executor编写一个小型 Python 函数normalize_title(title: str) - str去除首尾空白、折叠内部空白、标题大小写并附带一个微型 assert 示例只返回代码块、不修改文件审计前后分别对workspace/session_raw/下所有.jsonl转录文件做快照记录文件 size 与 mtime见transcriptSnapshot父 turn 完成后通过changedTranscriptFiles找出 size/mtime 变化的转录再用subagentTranscriptFiles过滤出文件名包含__的子代理转录判据父响应非空且至少两个子代理转录发生变化证明两个并行 worker 都真实执行了。场景三reuse-parent-comm—— 跨轮会话复用与用量统计该场景验证durable 子代理的跨轮复用以及token 用量统计是信息量最大的场景Turn 1编排器恰好调用两次spawn_subagent均blockingfalse、freshfalsetask key 分别为taskKey-reuse-alpha和taskKey-reuse-beta两个 worker 各自向父会话发送状态更新随后调用两次wait_subagent收集最终更新Turn 2使用完全相同的 task key再次 spawn 两个 workerprompt 要求继续之前的工作并提及各自记住的话题复用判据两次 turn 结束后从 session 存储中提取subagentSessionId集合若 Turn 1 与 Turn 2 的 durable 会话 id 集合不一致则判为复用失败durable subagent sessions were not reused across turns。每个 turn 的用量报表来自session_raw/*.jsonl每条转录首行_meta字段usageSnapshotinput_tokens输入 token 数cached_input_tokens缓存命中输入 token 数output_tokens输出 token 数charged_amount_usd计费美元金额脚本在前后快照之间做差diffUsageSnapshots按父/子代理分别输出并汇总打印[harness-subagent-rpc-audit] usage reuse-parent-comm turn1 total in... cache... out... cost$... cache_rate...% sessions... subagents...其中cache_rate即cached/total input的百分比。该场景的判据包括每个 turn 父响应非空、存在 transcript 用量元数据、至少两个子代理用量增量、恰好两个 durable 会话、且跨轮会话 id 完全复用。延伸阅读仓库中还有姊妹工具 scripts/debug/harness-cache-audit.mjs专门用--min-hit-rate与--max-turns-without-cache对多轮 turn 的缓存命中率做阈值断言可与reuse-parent-comm的 cache 指标配合使用。场景四all--scenario all会依次执行以上三个场景内部映射为[async-steer, parallel-research-code, reuse-parent-comm]并自动为每个子场景追加后缀生成独立 task key如audit-subagent-rpc-ts-async-steer避免跨场景的 task key 冲突。聚焦审计运行文档给出的聚焦命令适合逐步排查单个环节# 仅验证运行中转向 node scripts/debug/harness-subagent-rpc-audit.mjs --spawn-core --isolated-workspace --model agentic-v1 --scenario async-steer # 仅验证并行研究/编码 node scripts/debug/harness-subagent-rpc-audit.mjs --spawn-core --isolated-workspace --model agentic-v1 --scenario parallel-research-code # 仅验证跨轮会话复用 node scripts/debug/harness-subagent-rpc-audit.mjs --spawn-core --isolated-workspace --model agentic-v1 --scenario reuse-parent-comm # 直连 OpenAI 验证会话复用改用 gpt-4.1-mini node scripts/debug/harness-subagent-rpc-audit.mjs --spawn-core --isolated-workspace --provider-mode direct-openai --model gpt-4.1-mini --scenario reuse-parent-comm注意第三条命令在--provider-mode direct-openai下需要先设置OPENAI_API_KEY或OPENAI_KEY前三条在openhuman-backend模式下需要JWT_TOKEN。底层数据结构与源码佐证durable 会话存储审计轮询的会话存储位于工作区.openhuman/subagent_sessions.jsonsessionStorePath脚本按taskKey过滤并读取以下字段见readSessions的映射subagentSessionId、parentSession、workerThreadId、agentId、taskKey、currentTaskId、status如running、reusable、updatedAt、lastUsedAt。存储实现在 src/openhuman/agent/orchestration/subagent_sessions/store.rs与运行中子代理注册表running_subagents、后台投递background_delivery共同构成 OpenHuman 的异步子代理编排骨架。spawn_subagent的 task_key 与 fresh 语义从 src/openhuman/agent/orchestration/tools/spawn_async_subagent.rs 的 tool schema 可以确认task_key可选确定性身份键用于可复用委托未提供时默认取规范化的task_title/promptfresh为true时绕过可复用子代理匹配强制创建全新的 durable workertask_title持久化后台 worker 线程的可选短标题toolkit当agent_id integrations_agent时必填的 Composio toolkit slug。审计 prompt 中固定使用freshfalse正是为了触发可复用匹配路径从而验证reuse-parent-comm的跨轮复用语义。隔离审计用 agent 定义隔离工作区会写入两个 TOML 定义writeAuditDefinitionsorchestrator.tomltemperature 0.0、max_iterations 4、sandbox_mode none、agent_tier chat且omit_identity/omit_memory_context/omit_safety_preamble/omit_profile/omit_memory_md全部为 true消除记忆与身份上下文对审计的干扰工具白名单仅含spawn_subagent、spawn_parallel_agents、wait_subagent三个async_audit_worker.tomlagent_tier worker、max_iterations 2、工具列表为空仅用于确认收到转向指令并简短回应。常见问题与排障提示--isolated-workspace必须配--spawn-core脚本会显式抛出错误防止只改工作区不拉新 core 的误用凭据缺失backend 模式缺JWT_TOKEN、direct 模式缺OPENAI_API_KEY/OPENAI_KEY都会直接报错并提示正确的来源scripts/load-dotenv.sh可加载仓库环境变量见 scripts/load-dotenv.sh父 turn 提前结束如果agent_chat在 durable 会话进入 running 之前就返回waitForRunningSession会报 parent agent_chat completed before a running subagent session appeared——通常意味着模型没有按 prompt 约束发起非阻塞 spawn可检查 provider/模型配置超时参数模型响应慢时可调大--rpc-timeout-ms、--spawn-wait-ms日志量诊断可加--verbose会打印响应字符数与 core stderr但不会打印 prompt/响应/token 明细隐私边界不变审计结果脚本以[harness-subagent-rpc-audit] PASS或FAIL附失败清单、退出码 1收尾--keep-workspace模式下会打印保留的临时工作区路径需手动清理含密钥的配置。如果需要将审计输出归档为日志还可以借助 scripts/debug/README.md 描述的pnpm debug包装层输出 tee 到target/debug-logs/--verbose可流式输出原始结果让长时审计既保持 stdout 精简、又能事后回溯完整日志。【免费下载链接】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），仅供参考