ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

OpenHuman 潜意识工厂 Phase 3 深度解析:把 tiny.place 编排审查重构为一等公民 Subconscious 实例

OpenHuman 潜意识工厂 Phase 3 深度解析:把 tiny.place 编排审查重构为一等公民 Subconscious 实例 OpenHuman 潜意识工厂 Phase 3 深度解析把 tiny.place 编排审查重构为一等公民 Subconscious 实例【免费下载链接】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导读本文围绕 OpenHuman 仓库中 docs/plans/subconscious-factory/phase-3-tinyplace-profile.md 展开讲解“潜意识工厂Subconscious Factory”重构的第三阶段如何把目前内联在 memory 潜意识 tick 里的 tiny.place 编排审查orchestration review抽取为一个独立的TinyPlaceProfile让“memory 世界”与“tinyplace 世界”以彼此独立的锁、节拍cadence、熔断器、失败计数与状态行运行。读完本文你将掌握该阶段的设计动机、observe / prepare_context / reflect / commit / origin五个 profile 方法的精确契约、orchestration::ops的拆分方式、新增配置项orchestration.review_interval_minutes的语义以及配套的隔离不变量与测试矩阵并了解它与整个工厂架构trait、通用 runner、registry、heartbeat 扇出、tinyagents 图的衔接关系。1. 背景一个反射引擎两个世界在 subconscious-factory 计划 README 中OpenHuman 将潜意识定义为Deep Reflection Layer深度反射层一个离线的、由 cron 驱动的闭环消费某个“世界world”压缩后的变化视图并产出短小而密集的输出去**引导steer**系统其余部分。计划依据的 split-brain 规格Autonomous Closed-Loop LangGraph Harness要求系统同时维护两个世界世界领域观察observe反射reflectmemoryOpenHuman 内部高层世界用户连接的记忆源Gmail / Slack / Notion / 文件夹相对基线检查点的memory_diff精简决策 Agent待办、目标、notify_user、委派tinyplacetiny.place 编排世界harness 会话交互流经orchestration领域20:1 压缩后的执行历史 累积世界状态差异无工具tool-free的 steering 综合产出STEERING_DIRECTIVE供推理核心消费当前的问题集中在subconscious/engine.rs的tick_inner它是一个硬编码的复合体——stage 0 调用orchestration::ops::run_orchestration_review即 tiny.place 世界然后 stage 1–3 运行 memory 世界memory_diff → context scout → 决策 Agent。两个互不相关的世界共享一把 tick 锁、一个熔断器、一个状态对象、一个基线存储因此任何一个世界都无法拥有自己的节拍、provider 签名、暂停状态或状态行想加入第三个世界例如 per-team 世界、channels 世界只能继续把复合体做大。phase-3 的目标正是让 tiny.place 成为一个一等公民的潜意识实例并从 runner 中删除 stage-0 shim。phase-3 完成之后两个世界独立 tick各自独立的锁、节拍、熔断器、失败计数器与状态行。说明本计划描述的src/openhuman/subconscious/是重构后的目标目录布局当前仓库中编排领域实际位于 src/openhuman/agent/orchestration/潜意识相关配置位于 src/openhuman/config/schema/subconscious.rsturn 来源taint枚举位于 src/openhuman/agent/turn_origin.rs。2. 3.1profiles/tinyplace.rs包装编排领域的 profilephase-3 的核心交付物是profiles/tinyplace.rs——它包装orchestration/中已存在的机制把调度与策略从领域实现中剥离出来。下面按SubconsciousProfiletrait 的五个方法逐一展开。trait 契约本身定义在 phase-1phase-1-profile-and-engine.mdid() / cadence() / observe() / prepare_context() / reflect() / commit() / origin()外加Observationrendered、has_changes、has_external_content、commit_token与ReflectionActed/Steered/Idle两个类型。2.1id()→tinyplace稳定的实例 ID同时用作存储键命名空间、日志前缀与 RPC 名称。与 memory profile 的memory形成两个世界各自的命名空间见第 6 节存储迁移。2.2cadence自己的节拍旋钮节拍是 tinyplace 自己的独立旋钮详见第 4 节配置默认值 心跳间隔heartbeat interval这样合并后的行为与今天一致——当前“review 每次 memory tick 运行一次”默认值保持该语义不变。2.3observerun_orchestration_review的“加载半边”observe承担编排审查的读取/加载部分核心调用链为review_cursor → list_unreviewed_compressed(REVIEW_BATCH) // 游标之后的未审查压缩行 → list_recent_world_mutations(REVIEW_BATCH) // 最近的累积世界状态变更 → current_cycle_counter // 当前周期计数关键判定与产出has_changes !compressed.is_empty()—— 这就是今天的空闲门idle gate压缩历史为空即无事可做rendered build_steering_prompt(summaries, mutations)—— 把摘要与变更渲染成 steering 提示词交给reflect消费commit_token newest reviewed created_at—— 最新一条已审查记录的created_at作为不透明 token 由commit用于推进游标has_external_content true恒为 true—— harness 的 DM 属于第三方内容因此每次反射都必须按“被污染tainted”处理。2.4prepare_context默认空实现tinyplace 刻意保持无工具tool-free没有 scout不收集额外上下文。trait 的默认实现返回空字符串profile 直接跳过该阶段——这与 memory profile需要 context scout 收集扎根上下文形成对照。2.5reflectsynthesize_steering综合半边reflect是反射/综合synth半边内部流程synthesize_steering发起一次无工具的create_chat_provider(subconscious)chat 调用origin 标记为SubconsciousTainted契约违规contract violation时重试一次持久化insert_steering_directive—— 写入新的 steering directive并取代supersede先前的那条record_subconscious_directive—— 记入本地 Subconscious 窗口window发布事件event publish返回值Steered { directive_id }—— 成功产出 directiveIdle—— 模型干净地返回NONE选择了不做任何事或连续两次失败twice-failed。这里有一个刻意的设计决策对于干净的NONE与连续两次失败今天的行为都是“继续推进游标”——为保持行为一致profile 对这两种情况返回Idle而不是Err让 runner 沿“空闲路径”走从而避免把领域错误误判为运行时故障。2.6commitset_review_cursor(commit_token)这是 phase-3 的“收益兑现点”。今天游标的推进纠缠在run_orchestration_review的三个退出路径里拆分 observe / reflect / commit 之后runner 可以统一强制“仅当本次 tick 未被 supersede 时才推进游标”——游标推进只发生在成功路径上或空闲 tick 的基线刷新路径上被取代superseded的 tick 丢弃其结果、不推进游标。2.7origin恒为SubconsciousTaintedorigin()返回 turn 来源的 taint 标记。在 src/openhuman/agent/turn_origin.rs 中TrustedAutomationSource枚举定义了Subconscious仅内部 memory 上下文与SubconsciousTainted上下文包含来自外部同步源的块按不可信处理外部效果工具面被阻断两个子类。tinyplace profile 因为永远消费 harness 的第三方内容origin恒为SubconsciousTainted。这个标记会被 安全策略 与审批门approval gate读取AgentTurnOrigin::TrustedAutomation { source }经由AGENT_TURN_ORIGINtask-local 传播SubconsciousTainted意味着反射路径不获得任何外部效果工具面——与 3.4 的隔离不变量相互印证。3. 3.2 重构orchestration::ops从单体入口到 store-facing 拆分run_orchestration_review目前是潜意识引擎调用的公开入口。phase-3 将其拆分为store-facing的两个部分仍然留在orchestration::ops中——编排领域继续拥有自己的存储结构与 steering 契约潜意识 profile 只是围绕它们的调度器 策略新函数签名职责load_review_windowload_review_window(config) - ReviewWindow从编排存储加载审查窗口对应 profile 的observe半边synthesize_and_persistsynthesize_and_persist(config, window, tick_id) - Optioni64综合 steering 并持久化 directive对应 profile 的reflect半边返回Optioni64directive id同时保留一个薄薄的run_orchestration_review包装器用于维持现有两个测试实现者也可选择把测试移植为直接驱动 profile——但被断言的不变量必须存活emit-then-inject-next-cycle发出后注入下一周期幂等的重复 tickidempotent re-tick恰好一条 directiveexactly-one-directive。删除潜意识 runner 中的 stage-0 shimphase-2 留下的// phase-3 removes this标记处。phase-2 中该 shim 位于 runner 顶部形如if profile.id() memory { run_orchestration_review(...) }是有意为之的丑陋中间态phase-3 将其彻底移除。从拆分后的职责看orchestration::ops是“领域存储 steering 契约”的拥有者而TinyPlaceProfile只是决定“何时跑、跑完如何推进游标”的调度策略——领域与调度彻底解耦。4. 3.3 配置orchestration.enabled主闸 review_interval_minutes独立节拍orchestration.enabled继续作为 tinyplace 实例的主闸门当被禁用时profile 的observe安静返回与今天早退的Ok(false)行为一致。新增orchestration.review_interval_minutes: Optionu32None默认→ 使用心跳间隔作为节拍保持与今天“每次 memory tick 跑一次 review”的合并行为一致Some(n)→ tinyplace 世界按自己的n分钟节拍独立运行不再受 memory 世界 tick 频率影响。配套改动链Schema 变更在config/schema/orchestration.rs增加字段注意当前仓库中编排配置 schema 属于 src/openhuman/config/schema/ 体系实施时按计划落位到编排 schema环境变量覆盖在load.rs增加 env override示例更新在.env.example中补充说明。节拍由cadence()消费由 heartbeat 的 fan-out 逻辑判断“该实例的cadence自其last_tick_at以来是否已过期”来决定是否 tick见第 6 节。5. 3.4 隔离不变量反射路径永不触碰 Agent 与工具phase-3 把 phase-1 确立的隔离不变量落实为可按实例测试的约束tinyplace 反射路径不构造任何 Agent、不构造任何工具集——它只是一次 provider chat。为了在编译期就守住这条边界计划增加一个编译级守卫镜像现有的 agent-toml 测试profile 模块不得 importtinyplace::agent_tools或任何send_message族符号。实现方式是源码扫描测试source-scan test与现有orchestration_logs_never_reference_message_bodies同类。这与 memory profile 一侧“agent toolset 无 channel / 无外部效果工具”的subconscious_agent_tool_surface_has_no_channel_or_effect_tools测试形成双保险。steering directive 保持“带外写入者out-of-band writer”地位它由下一次唤醒时的apply_cycle_steering读取永不进入编排唤醒图内部。也就是说steering 只影响下一周期的行为输入不直接改写执行图——这条边界在重构后原样保留并通过回归测试持续验证见第 7 节。6. 更广的工厂上下文trait、通用 runner、registry 与 heartbeat 扇出phase-3 是七阶段工厂计划README 中的 Phase 表的一环理解它需要把它放进整条链里6.1 phase-1SubconsciousProfiletrait 与通用实例 runnerSubconsciousInstance的 tick 不是手写控制流而是一个tinyagentsCompiledGraph与编排唤醒路径同一运行时拓扑为START ─► observe ─┬─(quiet)──────────────────────────► commit ─► END └─(changed)─► prepare_context ─► reflect ─► commit ─► END节点处理器 1:1 委托给SubconsciousProfile方法——profile trait 本身就是被注入的运行时不再引入第二层抽象SqliteCheckpointerworkspace/subconscious/graph_checkpoints.db保证被中断的 tick 可恢复或干净地被 supersede而不是丢失窗口调度器关注点tick 锁 5s 获取超时、TICK_TIMEOUT30 分钟墙钟、provider 门、rate-cap 熔断、supersede 代数计数、状态读取留在 runner 中不进入图。这些通用机制一次实现、每个世界免费获得——tinyplace profile 因此自动获得与 memory 世界完全一致的 tick 锁、代数计数、超时与熔断语义只是签名带上了实例 id 前缀memory|cloud保证一个世界的熔断不会静默另一个世界。6.2 phase-1 存储实例命名空间 KV 迁移subconscious_stateREAL KVlast_tick_at与subconscious_state_textTEXT KVbaseline_checkpoint_id的访问器改为带实例 id 前缀memory:last_tick_at、tinyplace:last_tick_at、…。一次性迁移放在 DDL 块中且幂等UPDATE subconscious_state SET key memory: || key WHERE key IN (last_tick_at) AND NOT EXISTS (SELECT 1 FROM subconscious_state WHERE key memory:last_tick_at); UPDATE subconscious_state_text SET key memory: || key WHERE key IN (baseline_checkpoint_id) AND NOT EXISTS (SELECT 1 FROM subconscious_state_text WHERE key memory:baseline_checkpoint_id);注意tinyplace profile 的 review 游标留在编排存储里今天就在那里由 profile 通过commit拥有——不搬进潜意识 KV。6.3 phase-4工厂、registry 与 heartbeat 扇出factory.rs定义SubconsciousKind { Memory, TinyPlace }与make_subconscious(kind, config)是唯一构造 profile 的地方enabled_kinds(config)依据heartbeat.enabledmemory与orchestration.enabledtinyplace决定引导集registry.rs由global.rs成长而来用HashMapSubconsciousKind, ArcSubconsciousInstance管理多实例生命周期用户切换时整表清空重建heartbeat fan-out每次心跳迭代 registry对cadence已到期的实例并发 ticktokio::spawn每个实例——一次慢的 memory tick 不会延迟 tinyplace review一个世界的 rate-cap 暂停也不会闸住另一个世界phase-3 的 runner 级测试专门覆盖这一点。6.4 phase-6tinyagents 图复用与上游差距通用 runner 构建在tinyagents::graph之上。phase-6 在 phase-6-tinyagents-reuse.md 中核对了三项候选上游改动结论值得注意整图墙钟 deadline当前 vendored pin 只有 per-node timeout无整次运行的 deadline——差距确认作为独立上游 PR外部取消 / supersede tokenharness::cancel::CancellationToken原语已存在但主图 superstep 循环未检查——差距确认是“接线”而非“新原语”Checkpoint GC / 保留Checkpointer已暴露prune(thread_id, keep_last)与delete_thread(thread_id)无需上游 PR——SubconsciousInstance::run_graph在运行返回后调用delete_thread删除本次 tick 的线程使graph_checkpoints.db有界配套测试completed_ticks_leave_no_checkpoint_threads。这些都不阻塞 phase-1–5phase-1 先沿用外层tokio::time::timeout(TICK_TIMEOUT, …)与 tick 结束时的 supersede 检查上游原语落地后以小 PR 逐个替换脚手架。7. 3.5 测试矩阵三层验证phase-3 的测试按三个层次设计完整矩阵见 phase-5-tests-and-docs.md7.1 Profile 级tinyplace profile播种编排存储 →observe返回has_changes脚本化 provider复用现有test_provider_override→reflect返回Steered游标经 runner 的commit推进再次 tick → 空闲re-tick idle。7.2 Runner 级跨实例并发tinyplace 与 memory 两个实例在同一个 workspace 上并发 tick两者之间无锁竞争各自独立的tick_locklast_tick_at键彼此独立命名空间 KV 的直接收益一个实例的 rate-cap 熔断暂停不会闸住另一个实例熔断签名带实例 id 前缀的验证。7.3 回归全周期编排图全周期编排图测试持续通过——steering 注入路径未被改动这是“带外写入者”边界的运行期保障。配合 phase-2 移植的engine_tests.rsrate-cap 熔断生命周期、provider 路由/签名、origin 升级、tool-capability 检测以及 phase-1 的FakeProfile生命周期测试quiet / fail / rate-cap-halt / superseded构成从 trait 到实例再到跨实例的完整覆盖。每个 phase 是独立可编译、可提交的切片要求≥80% 的 diff 覆盖率phase-2/3 这类纯抽取切片的大部分覆盖率由移植测试继承。8. 行为差异与 rollout 要点phase-5 明确列出了重构后有意的行为差异是 PR 系列中必须显式标注的编排 review 不再搭 memory tick 的便车它按自己的节拍运行因此 memory 世界空闲时 review 照常执行——今天如果 memory provider 故障steering 会被静默饿死phase-3 之后不会一个世界的 rate-cap 熔断不再暂停另一个世界subconscious.status新增字段仅追加向后兼容RPC 层面subconscious.status的顶层字段继续由 memory 实例填充新增instances: [SubconsciousStatus]每实例一行并带instance: memory | tinyplacesubconscious.trigger增加可选kind参数默认memory。明确的非目标non-goals同样重要不改编排唤醒图、压缩比、context-guard 阈值或 steering 契约不新增除两个之外的新世界工厂让team世界、channels世界变得廉价但那是后续前端只做 phase-7 的增量Subconscious 标签页的实例卡片 Orchestration 标签页的 steering 头部不新增页面/路由/Redux slice事件驱动触发器管线subconscious_triggersLongLivedSession保持现状。数据面风险为零唯一迁移是subconscious.db内部的 KV 键重命名phase-1.3设计为旧版本容错编排存储完全不动。9. 小结phase-3 的验收标准一句话概括 phase-3 的完成判据run_orchestration_review的内联调用从 runner 中消失TinyPlaceProfile成为与MemoryProfile平起平坐的一等公民实例两个世界在同一个 workspace 上以独立的锁、节拍、熔断器、失败计数与状态行并行运行且全部隔离不变量无 Agent/无工具集、恒SubconsciousTainted、steering 带外写入、游标仅在未 supersede 时推进都有测试背书。对开发者而言这条计划的启发性在于一种可复制的重构姿势先把共享运行时抽象成 trait 通用图 runnerphase-1再逐个抽取世界为 profilephase-2/3最后用工厂/registry/心跳扇出把多实例生命周期补全phase-4——每个切片行为等价、可独立合入而“新增一个世界 一个 profile 文件 一个 match 分支 一行 enabled_kinds”的扩展成本正是这套架构的最终回报。后续想深入了解可以从 subconscious-factory 计划根目录 按阶段顺序阅读并对照 turn_origin.rs 的 taint 语义与 config/schema/subconscious.rs 的引擎选择逻辑进行代码印证。【免费下载链接】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),仅供参考
返回列表