人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载本篇技术指南以 oh-my-openagent 仓库中 memory-v2 主动学习active learning特性的真实端到端 QA 复跑报告F3-rerun为骨架完整还原一次真机、真会话、真提交的 memory-v2 全功能验收从插件构建、隔离初始化、nudge 记忆提醒、facts 事实抽取、soul 人格编辑通知到/dream反思与/people人物卡查询每一步都以源码与证据文件为锚点。读完你不仅能复现这套验证流程还能理解 memory-v2 各功能模块nudge / facts / dream / people / soul在 packages/omo-senpi/src/components/memory 中的真实实现链路。一、验证背景一次重跑的验收结论F3-rerun 是 memory-v2 功能面F3的复跑验证最终结论为F3: PASS。原始验证记录位于 .omo/evidence/omo-senpi-adapter/memory-v2/F3-rerun/qa.md其关键上下文如下项目值判定结果F3: PASS验证日期2026-08-10分支feat/memory-v2-active-learning构建时 HEADf801a00c58d009ac3a2db84e34867a774908b01c被测表面worktree 本地 Senpi2026.8.11加载打包后的 packages/omo-senpi/plugin 扩展隔离范围全新的一次性HOME、XDG_CONFIG_HOME、SENPI_CODING_AGENT_DIR、session 目录、项目目录与OMO_MEMORY_HOMEF3 指 memory-v2 的功能验收面该目录下同时存在 A1/F1/F2/F4 等验证面与多次 rerun/rewrite 记录见 .omo/evidence/omo-senpi-adapter/memory-v2。所谓 rerun是指对既有验收流程的重跑——目的在于证明结果可复现且打包产物扩展 bundle在重跑后保持一致。二、验证方法学四条纪律F3-rerun 的方法学可以提炼为四条可复用的验收纪律全部落实在驱动脚本 qa-driver.mjs 中1. 官方构建命令 产物哨兵sentinel校验先用仓库要求的命令构建扩展 bundlenode packages/omo-senpi/plugin/scripts/build-extension.mjs构建成功后对生成的omo.js做字符串哨兵校验——grep 当前版本的提示文案holds local paths of memory projections。这一步的意义在于确认 bundle 中确实携带的是 memory-v2 的新实现而不是陈旧的 v1 提醒文案同时确认没有出现memory.reflection/memory-v2 配置校验错误。2. 全新隔离环境杜绝环境串扰驱动脚本通过mkdtempSync创建一次性临时根目录并为每个涉及路径的变量单独建目录qa-driver.mjsconst root mkdtempSync(join(tmpdir(), omo-memory-f3-rerun-)) const project join(root, project) const home join(root, home) const agentDir join(root, senpi-agent) const sessionDir join(agentDir, sessions) const xdgConfigHome join(root, xdg) const memoryHome join(root, memory)这些路径随后被整体注入子进程环境isolatedEnvHOME、XDG_CONFIG_HOME、SENPI_CODING_AGENT_DIR、OMO_MEMORY_HOME全部指向临时根并附加OMO_SENPI_QA1、OMO_SENPI_DISABLE_POSTHOG1、PI_OFFLINE1等 QA/离线开关。这意味着每次验证都是从零记忆开始的纯净首跑任何外部状态都不会泄漏进被测会话。3. 事件驱动等待禁止固定 sleep驱动对 facts 触发和 dream 触发都使用了预置的递归fs.watch观察器waitForFile等待目标文件如final.json出现所有等待都有界超时。脚本注释与系统提示词中的测试纪律一致禁止固定 sleep 与 wait-for-time 轮询必须订阅精确的事件或状态变化。这不仅让验证更快也消除了时序类偶发失败。4. 确定性、可解析的快速模型facts 抽取与 dream 子进程使用omo-mock/mock-1——一个确定性、真实可解析的快速模型。它让抽取结果可预期脚本能精确断言抽取出的文本内容同时避免等待真实 LLM 带来的延迟与不确定性若需要降级模型则意味着测试环境异常。三、八个场景的逐步验收场景 1构建与 bundle 哨兵 —— PASS构建以退出码 0 结束生成的omo.js包含当前提醒文案holds local paths of memory projections旧版 v1 提醒未被使用未出现 memory-v2 配置校验错误。此场景的全部输出落在证据文件 build.txt 与 run.txt 中。场景 2全新首跑的种子初始化 —— PASS第一次真实senpi -p运行在隔离仓库内完成初始化。种子提交d1b2281chore: initialize local memory包含system/persona.md与system/human.md——这正是 memory 组件 AGENTS.md 中声明的默认种子是仅有的首跑内容。随后的 memory-tool 提交为704f178携带Omo-Writer: memory-tool、Omo-Session、Omo-Turn等 trailer见 memory-git-log.txt。git 历史成为 memory 行为最直接的持久化证据。场景 3nudge 提醒与自清除 —— PASS这是对save nudge保存提醒功能的精确行为验证初次保存后的第一个不保存轮次无nudge 注入第二个不保存轮次系统提示词中出现恰好2 user turns since your last memory save配置为every_user_turns: 2下一次 memory 工具保存提交1a887f6后再下一轮 nudge 消失自清除。nudge 的实现位于 prompt.ts常量MEMORY_NUDGE_METADATA_TOKEN user turns since your last memory saveL14由renderMemoryNotice渲染进memory_notice块L106-L124。计数依据是距上次 memory 写入以来的已接受用户轮数写入检测依赖 commit trailerOmo-Writer/Omo-Session/Omo-Turn而非 git author 身份。注入后的系统提示词样本可在 system-prompts.txt 中看到其中memory_metadata块还包含AGENT_ID、CONVERSATION_ID与重编译时间戳。场景 4facts 队列与快速抽取器 —— PASSfacts 是 memory-v2 的 omo 独有扩展非 letta-code 对等项settle 时入队、防抖后由进程内子代理执行抽取。验证要点预置 watcher 观察到 facts 运行产物final.jsonoutcome: committedSHA026dcd5抽取器创建了people/mina-kim/card.md与 observations提交3574f0c同时携带Generated-By: facts-extractor与Omo-Writer: facts-extractortrailer快速模型omo-mock/mock-1在线可用未发生降级。在 memory-git-log.txt 中可看到连续的 facts 提交链每条都带Generated-By: facts-extractor、Omo-Writer: facts-extractor、Omo-Facts-Batchtrailer且只改动people/mina-kim/observations.md——证明抽取是父进程加锁应用整批提交、子进程从不触碰 git的架构见 AGENTS.md。机器可读结果 results.json 中记录该 run 的完整final.json内容含runId、finishedAt、sha字段。场景 5soul 编辑通知 —— PASS通过 memory 工具的str_replace修改system/persona.md提交0f82863后工具结果包含纪律性文案This was a soul edit: announce it to the user in your reply.会话 JSONL 中持久化了一条customType:omo-memory:soul-updated条目真实 TUI 渲染出memory soul updated 0f82863: F3 soul edit notice与system/persona.md。soul 通知的实现位于 soul-notice.ts常量SOUL_UPDATED_ENTRY_TYPE omo-memory:soul-updatedL16渲染器把提交 SHA截取 7 位与受影响的 soul 路径SOUL_PATHS中的system/persona.md、system/identity.md、system/boundaries.md呈现为 accent 色调的 notice 条目发射由memory.soul.edit_notice配置门控而工具结果中的纪律性文案是无条件的、由 memory-core 生成。这正是编辑自己的灵魂文件必须告知用户的可见性设计。场景 6/dream --recent 1—— PASS通过 Senpi 文档化的实时 RPCprompt表面调用/dream --recent 1RPC 直接分发注册的扩展斜杠命令并返回真实的extension_ui_request通知通知dream run reflection-run-1 reserved证明手动 dream 命令预留了一次反思运行预置 watcher 依次观察到outcome.json与final.json调和后的最终 outcome 为成功的no_changes子进程退出码 0、stderr 为空。dream反思通道是 memory-v2 新增的触发类型origin: manual|idle|shutdown|pressure走与 reflection 相同的 worker 管线run supervisor 持有运行身份握手与outcome.json哨兵见 AGENTS.md。no_changes是 dream 的合法成功终态之一另一个是merged表示审视了所选对话无需整合变更。场景 7/people—— PASS同样通过 RPC 调用/people Mina实时斜杠分发渲染出# Mina Kim (mina-kim)并给出抽取到的观察Mina Kim is the release manager and prefers concise release checklists.。来自 results.json 的 RPC 输出还揭示了 person 卡片的渲染结构kind: person | aliases: Mina、state: committed、path: people/mina-kim/card.md以及带日期的显式观察条目(n5)——说明同一条观察被 facts 批处理去重合并累计了 5 次。people 卡片kind/aliasesfrontmatter、max_entries/max_entry_chars上限是 memory-core 中 omo 扩展的格式化能力。场景 8证据收集与 teardown —— PASSresults.json汇总30 项检查、0 失败完整 transcript、提示词转储、会话 JSONL、隔离 git 日志全部落盘无 F3 进程、tmux server 或omo-memory-f3-rerun-*根目录残留bundle 通过git checkout恢复后提交的omo.js为 974,066 字节且仍包含当前提醒文案。四、关键 harness 细节dream 子进程的 QA provider一个值得注意的实现细节dream 子进程继承了 QA provider但其系统提示词转储在SENPI_MEMORY_REFLECTION1时被有意禁用。原因是反思沙箱reflection sandbox会正确地拒绝向父运行的外部提示词日志路径写入。这一禁用只影响 QA 日志记录并不绕过配置、模型解析、命令分发、worker 监督或 finalization移除该非产品日志副作用后真实的 dream 子进程以退出码 0 完成并 finalize 为no_changes。这体现了一条 QA 纪律harness 的改动必须只影响观测绝不改变被测行为本身。五、证据索引一份可审计的验证档案F3-rerun 目录完整保留了 10 个证据文件均在 .omo/evidence/omo-senpi-adapter/memory-v2/F3-rerun 下文件内容build.txt构建命令、生成 bundle 的哈希/体积、提醒文案 grep 结果qa-driver.mjs确定性隔离 live-surface 驱动脚本约 630 行run.txt完整最终进程/TUI/RPC transcripttranscript.txt驱动脚本组装的完整最终场景 transcriptresults.json机器可读最终结果PASS、30 项检查、0 失败含逐项明细system-prompts.txt注入的系统提示词含 nudge 的有/无对比session.jsonl.txt完整隔离 Senpi 会话 JSONLsession-files.txt隔离会话文件清单memory-git-log.txt隔离 memory 仓库历史含 trailer 与变更路径teardown.txtbundle 恢复、进程/根目录/tmux 审计、体积、哈希与最终回执这套证据结构本身即是工程实践每个断言都有机器可读结果results.json与原始痕迹transcript、git log、session JSONL双重背书验证可复现、可审计。六、Teardown 回执摘要与隔离纪律F3 子进程无残留F3 tmux server无残留F3 隔离根目录无残留打包扩展状态git checkout -- packages/omo-senpi/plugin/extensions/后恢复干净恢复的提交版omo.js974,066 字节SHA-2561a042a88aa1077be5a12128b34e73a233b981cc4a93120807c45348078f4d003并发测试工作中产生的无关memory-run-supervisor-ic8-*fixture 进程被观察到并刻意保持不动。最后一条尤其体现了隔离纪律的边界只清理自己创建的资源绝不误伤并发环境中的他人进程。七、从 F3-rerun 提炼的可复用 QA 方法论对照 memory 组件架构文档 与驱动脚本源码可以把这套端到端验证抽象为五条可直接复用的原则哨兵先行构建后立刻对产物做字符串/哈希校验确保测的是新代码而非陈旧缓存全量隔离HOME、配置目录、session、memory 根目录全部指向一次性临时根首跑即零记忆状态事件驱动而非时间驱动fs.watch 订阅目标产物final.json、outcome.json出现配上有界超时杜绝 flaky确定性模型用可解析的 mock 模型驱动子代理让断言精确到文本级证据即交付结果 JSON、transcript、git log、会话 JSONL 四件套齐全任何一步失败都可通过证据文件回溯定位。这套方法不只适用于 memory-v2任何扩展 宿主会话 后台子代理架构的验收都可以参照 F3-rerun 的结构来设计隔离、触发、观察与清理四阶段的自动化验证。赞分享人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载相关推荐oh-my-openagent 开发失败修复实录omo-senpi 测试环境隔离、Agent 目录解析与 QA 隔离治理oh my openagent 开发失败修复实录omo senpi 测试环境隔离、Agent 目录解析与 QA 隔离治理 导读 本文基于 oh my open人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排OmO Native Telemetry 真实表面 QA用真实 Senpi CLI 端到端验证匿名遥测管线OmO Native Telemetry 真实表面 QA用真实 Senpi CLI 端到端验证匿名遥测管线 导读 OmO Native 是 omo senpi人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排oh-my-openagent omo-senpi 适配器回归 QA 实录从 Issue 5317 证据记录解读隔离认证驱动器oh my openagent omo senpi 适配器回归 QA 实录从 Issue 5317 证据记录解读隔离认证驱动器 在 oh my openage人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考