oh-my-openagent 团队消息 Steer-Only 投递从投递语义到证据链的完整验证【免费下载链接】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本文以仓库中的交付证据文档 20260726-team-steer-only README 为主体解析 oh-my-openagent 中团队team消息投递统一为 steer-only转向式注入的设计变更团队消息如何被注入收件人正在运行的回合、非团队task_send为何保留followUp默认值以及该变更如何通过单元回归、类型检查、构建验证与隔离沙箱 Live E2E 形成完整的证据链。读完后你能掌握这套投递模型的语义边界steer / followUp / no_active_turn 错误处理、team_wait移除后的协作范式以及一条可复现的交付验证流程。1. 变更范围所有团队消息投递路径 steer 到运行中回合证据文档开宗明义地定义了本次变更的范围This change makes every team-message delivery path steer into the recipients running turn. Generic non-teamtask_sendretains itsfollowUpdefault.即两条投递语义被明确区分投递场景默认行为语义团队内消息lead ↔ member、shutdown 通知、存活状态注入等所有团队消息投递路径steer把消息注入收件人当前正在运行的回合running turn收件人无需等待回合结束通用非团队task_sendfollowUp保留原有的 follow-up 默认值不随本次变更改变这一设计的核心动机是消除团队协作者之间的回合栅栏成员收到 lead 的指令后不必等当前回合跑完再处理消息直接进入运行中回合。相应地旧的阻塞式同步手段team_wait被移除协作节奏由 steer 通知 task_send取代。1.1team_wait移除后的协作提示从源码看工具层的提示字符串直接体现了新范式。在 task 工具入口 中team_wait相关的提示被替换为team_wait was removed - team messages arrive as steered notifications; send updates with task_send and end your turn.同样的提示也出现在 task 组件测试 中被断言说明这不是临时文案而是被测试固化的对外行为契约。使用指引文件 usage-guidance 进一步把路由规则写死为task_send always steers a message into the addressed child, while task_cancel ends it.也就是说task_send一律 steer 到被指向的子代理task_cancel负责终止两者构成新的团队消息控制面。2. 底层投递语义steer / follow_up 在 thread mailbox 中的实现团队消息最终落到线程邮箱thread mailbox上统一投递。在 mailbox 实现 中投递模式是一个三值联合类型// packages/omo-senpi/src/components/thread/mailbox.ts#L11 type DeliveryMode auto | steer | follow_upsteer 的关键约束在投递循环里得到体现mailbox.ts 投递逻辑无活跃回合则失败并给出可操作建议。当delivery steer而目标线程没有活跃快照时投递被置为错误no_active_turn提示语为Thread {target} has no active turn to steer. Use delivery auto or follow_up, or retry while the target turn is active. 即 steer 是尽力注入运行中回合的语义目标空闲时不静默排队而是明确报错并指路改用 auto/follow_up或等回合活跃后重试。auto模式自适应。delivery steer || (delivery auto snapshot.active)—— auto 在目标活跃时走 steer 路径这正是团队消息总能在成员运行期间送达的底层机制。乐观并发校验。steer 投递需要expected_turn_id参数校验Steer delivery needs expected_turn_id.调用方必须先读取活跃回合 id 再发起 steer防止消息注入到已被替换的回合上。校验通过后调用port.steer(message, expectedTurnId, operationId, steer)成功结果记为{ kind: ok, delivery: steered, turn_id }。这套机制解释了证据文档中断言精确的 steering-engine 结果delivered: steer的可行性投递结果是一等可观测值测试可以直接断言steered交付状态。3. 具体投递生产者的单元回归shutdown 消息器与成员扩展证据文档将回归测试覆盖范围拆成五类成员扩展入站注入member-extension inbound injection、关闭消息器投递shutdown messenger delivery、成员范围与 lead 的task_send路由member-scoped and leadtask_sendrouting、scoped-schema 移除、以及 scoped TUI 渲染器。其中 shutdown 消息器的回归最具代表性。在 team-service-support 测试 中用例名称本身就是三段式验收标准test(#given a mapped running member #when a shutdown notice is sent #then the notice steers into the running turn, ...) // 断言 expect(handle.steerCalls).toEqual([[team shutdown_request] finish current work]) expect(handle.followUpCalls).toEqual([])两个断言合起来精确刻画了 steer-only 的契约正向shutdown 通知经过handle.steer注入成员正在运行的回合steerCalls恰好包含该通知文本负向handle.followUp从未被调用followUpCalls为空。这正是文档Why this is sufficient一节所说的针对 steer 路径测试断言的是 steering-engine 的精确结果delivered: steer并断言成员范围与显式 lead-team 发送场景下handle.followUp永不被调用成员扩展与 shutdown 消息器测试则覆盖了其余具体的入站投递生产者。4. 自动化验证四层门禁及其命令证据文档记录了四层自动化验证全部 PASS且每层都保留了日志文件作为可追溯证据4.1 单元回归bun testbun test packages/senpi-task packages/omo-senpi/src结果1240 个测试、0 失败、1 个快照、4010 项断言日志存于bun-test.log。两个被测包分别对应本文涉及的两个核心子系统senpi-task任务/回合管理与 steering 引擎侧与omo-senpiSenpi 插件侧包含 team 组件、mailbox 与 TUI 渲染器。4.2 类型检查tsgobunx tsgo --noEmit -p packages/senpi-task/tsconfig.json # PASS无输出 bunx tsgo --noEmit -p packages/omo-senpi/tsconfig.json # PASS无输出日志分别存于tsgo-senpi-task.log与tsgo-omo-senpi.log。对投递这类跨包契约变更mailbox 的DeliveryMode、handle 的 steer/followUp 调用面全量类型检查可以兜底捕获接口漂移。4.3 插件构建stagebun run build:senpi-plugin:stage结果 PASS日志build-senpi-plugin-stage.log。该步骤重建了暂存staged的 Senpi 扩展 bundle明确包含omo-member.js——即成员侧扩展产物Live E2E 中运行的正是这个构建产物而非源码直跑保证验证对象与发布对象一致。5. Live QA隔离沙箱中的 12 项端到端检查自动化层之上证据文档还跑了一次对真实构建产物的端到端 QATEAM_E2E_OUT_DIR证据目录/team-e2e-artifacts node packages/omo-senpi/scripts/qa/team-e2e.mjs驱动脚本 team-e2e.mjs 在隔离沙箱中用 mock provider 驱动完整团队流程同目录下还配有team-e2e-runtime.mjs、team-e2e-crash.mjs、team-e2e-support.mjs等协作模块。结果 PASS机器可读裁决文件 verdict.json 记录了全部 12 项检查均为true检查项含义createTwoMembersActive创建的两个成员均处于活跃状态createListsActiveMemberscreate 列表正确列出活跃成员leadToMemberEnqueuedlead → member 消息入队成功memberEnvelopeEchoed成员信封envelope被回显证明消息以完整封装注入成员回合memberToLeadInjectedmember → lead 反向注入成功leadInboxDrainedlead 收件箱被正常排空noBlockingTeamWaitCalls全程无阻塞式team_wait调用——直接印证 steer-only 语义crashHoldReached崩溃恢复流程达到预留reservation hold状态crashKilledMemberAtHold在 hold 点杀掉成员进程crashReservationUncommittedAtKill杀进程时刻预留未提交未提交状态可安全回收crashRestartExitClean重启后进程干净退出crashLivenessInjectedToLead成员崩溃的存活状态liveness信息被注入 lead除 12 项功能检查外裁决文件还记录了三项卫生指标credentialIsolationClean: true——沙箱前后凭证指纹一致驱动脚本中对应beforeCredential afterCredential的比较见 team-e2e.mjs 结果汇总leakedPids: 0——无泄漏进程wholeDirUnchanged: false——文档特别指出这是一个**非门控non-gating**字段它记录了一个发生在凭证隔离范围之外、真实的 Senpi 代理目录摘要差异但既然 Live QA 本身未失败就无需再跑 dev 基线dev-baseline QA来排除。最终result仍为PASS因为门控条件只有result PASS credentialIsolationClean leakedPids 0。此外QA 现场产物还包括 team-injection-evidence.json 等注入证据与crash-after-inject.json、crash-recovery.json等崩溃恢复快照与文档所述日志与机器可读裁决存于team-e2e.log与team-e2e-artifacts/verdict.json一一对应。6. 为什么这套证据是充分的以及有意省略了什么文档最后两节值得作为交付证据的写法范本充分性论证Why this is sufficient证据不是测试全绿的笼统声明而是把断言粒度对齐到设计意图——steer 路径断言精确的引擎结果delivered: steer并断言followUp零调用shutdown 消息器与成员扩展测试覆盖其余入站投递生产者Live QA 则在隔离沙箱中以 mock provider 驱动已构建的插件保证验证的是发布物形态。有意省略Omitted未做 dev-baseline QA 运行理由是隔离 Live QA 已 PASSwholeDirUnchanged的差异非门控且不在凭证隔离范围内除自动化渲染器与 Live E2E 覆盖外未额外跑手动交互式 TUI 会话CI synchronize 触发无功能变更no functional change。7. 可复现路径小结如果你想在自己的工作副本中复现本文证据链只读仓库中仅作查看参考通读 交付证据 README 与 verdict.json确认 12 项检查与三项卫生指标核对 mailbox 投递实现 中DeliveryMode、no_active_turn与expected_turn_id校验理解 steer 的乐观并发语义阅读 shutdown 消息器回归 与 usage-guidance确认task_send恒定 steer、team_wait已移除的契约按第 4 节命令依次跑bun test、两个tsgo --noEmit与bun run build:senpi-plugin:stage最后以TEAM_E2E_OUT_DIR指定输出目录执行 team-e2e.mjs 完成 Live QA。这一证据链给出的通用启示是对于投递语义这类跨进程、跨回合的行为变更可信度来自分层——精确断言的单元回归锁定引擎契约类型检查兜住跨包接口构建 stage 保证验证对象与发布物一致隔离 Live E2E 用崩溃注入、凭证指纹与泄漏 PID 计数把运行时卫生也纳入门控。steer-only 变更正是靠这四层证据把所有团队消息都注入运行中回合这一单句设计承诺变成了可审计、可复现的事实。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-openagent 团队消息 Steer-Only 投递：从投递语义到证据链的完整验证
oh-my-openagent 团队消息 Steer-Only 投递从投递语义到证据链的完整验证【免费下载链接】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本文以仓库中的交付证据文档 20260726-team-steer-only README 为主体解析 oh-my-openagent 中团队team消息投递统一为 steer-only转向式注入的设计变更团队消息如何被注入收件人正在运行的回合、非团队task_send为何保留followUp默认值以及该变更如何通过单元回归、类型检查、构建验证与隔离沙箱 Live E2E 形成完整的证据链。读完后你能掌握这套投递模型的语义边界steer / followUp / no_active_turn 错误处理、team_wait移除后的协作范式以及一条可复现的交付验证流程。1. 变更范围所有团队消息投递路径 steer 到运行中回合证据文档开宗明义地定义了本次变更的范围This change makes every team-message delivery path steer into the recipients running turn. Generic non-teamtask_sendretains itsfollowUpdefault.即两条投递语义被明确区分投递场景默认行为语义团队内消息lead ↔ member、shutdown 通知、存活状态注入等所有团队消息投递路径steer把消息注入收件人当前正在运行的回合running turn收件人无需等待回合结束通用非团队task_sendfollowUp保留原有的 follow-up 默认值不随本次变更改变这一设计的核心动机是消除团队协作者之间的回合栅栏成员收到 lead 的指令后不必等当前回合跑完再处理消息直接进入运行中回合。相应地旧的阻塞式同步手段team_wait被移除协作节奏由 steer 通知 task_send取代。1.1team_wait移除后的协作提示从源码看工具层的提示字符串直接体现了新范式。在 task 工具入口 中team_wait相关的提示被替换为team_wait was removed - team messages arrive as steered notifications; send updates with task_send and end your turn.同样的提示也出现在 task 组件测试 中被断言说明这不是临时文案而是被测试固化的对外行为契约。使用指引文件 usage-guidance 进一步把路由规则写死为task_send always steers a message into the addressed child, while task_cancel ends it.也就是说task_send一律 steer 到被指向的子代理task_cancel负责终止两者构成新的团队消息控制面。2. 底层投递语义steer / follow_up 在 thread mailbox 中的实现团队消息最终落到线程邮箱thread mailbox上统一投递。在 mailbox 实现 中投递模式是一个三值联合类型// packages/omo-senpi/src/components/thread/mailbox.ts#L11 type DeliveryMode auto | steer | follow_upsteer 的关键约束在投递循环里得到体现mailbox.ts 投递逻辑无活跃回合则失败并给出可操作建议。当delivery steer而目标线程没有活跃快照时投递被置为错误no_active_turn提示语为Thread {target} has no active turn to steer. Use delivery auto or follow_up, or retry while the target turn is active. 即 steer 是尽力注入运行中回合的语义目标空闲时不静默排队而是明确报错并指路改用 auto/follow_up或等回合活跃后重试。auto模式自适应。delivery steer || (delivery auto snapshot.active)—— auto 在目标活跃时走 steer 路径这正是团队消息总能在成员运行期间送达的底层机制。乐观并发校验。steer 投递需要expected_turn_id参数校验Steer delivery needs expected_turn_id.调用方必须先读取活跃回合 id 再发起 steer防止消息注入到已被替换的回合上。校验通过后调用port.steer(message, expectedTurnId, operationId, steer)成功结果记为{ kind: ok, delivery: steered, turn_id }。这套机制解释了证据文档中断言精确的 steering-engine 结果delivered: steer的可行性投递结果是一等可观测值测试可以直接断言steered交付状态。3. 具体投递生产者的单元回归shutdown 消息器与成员扩展证据文档将回归测试覆盖范围拆成五类成员扩展入站注入member-extension inbound injection、关闭消息器投递shutdown messenger delivery、成员范围与 lead 的task_send路由member-scoped and leadtask_sendrouting、scoped-schema 移除、以及 scoped TUI 渲染器。其中 shutdown 消息器的回归最具代表性。在 team-service-support 测试 中用例名称本身就是三段式验收标准test(#given a mapped running member #when a shutdown notice is sent #then the notice steers into the running turn, ...) // 断言 expect(handle.steerCalls).toEqual([[team shutdown_request] finish current work]) expect(handle.followUpCalls).toEqual([])两个断言合起来精确刻画了 steer-only 的契约正向shutdown 通知经过handle.steer注入成员正在运行的回合steerCalls恰好包含该通知文本负向handle.followUp从未被调用followUpCalls为空。这正是文档Why this is sufficient一节所说的针对 steer 路径测试断言的是 steering-engine 的精确结果delivered: steer并断言成员范围与显式 lead-team 发送场景下handle.followUp永不被调用成员扩展与 shutdown 消息器测试则覆盖了其余具体的入站投递生产者。4. 自动化验证四层门禁及其命令证据文档记录了四层自动化验证全部 PASS且每层都保留了日志文件作为可追溯证据4.1 单元回归bun testbun test packages/senpi-task packages/omo-senpi/src结果1240 个测试、0 失败、1 个快照、4010 项断言日志存于bun-test.log。两个被测包分别对应本文涉及的两个核心子系统senpi-task任务/回合管理与 steering 引擎侧与omo-senpiSenpi 插件侧包含 team 组件、mailbox 与 TUI 渲染器。4.2 类型检查tsgobunx tsgo --noEmit -p packages/senpi-task/tsconfig.json # PASS无输出 bunx tsgo --noEmit -p packages/omo-senpi/tsconfig.json # PASS无输出日志分别存于tsgo-senpi-task.log与tsgo-omo-senpi.log。对投递这类跨包契约变更mailbox 的DeliveryMode、handle 的 steer/followUp 调用面全量类型检查可以兜底捕获接口漂移。4.3 插件构建stagebun run build:senpi-plugin:stage结果 PASS日志build-senpi-plugin-stage.log。该步骤重建了暂存staged的 Senpi 扩展 bundle明确包含omo-member.js——即成员侧扩展产物Live E2E 中运行的正是这个构建产物而非源码直跑保证验证对象与发布对象一致。5. Live QA隔离沙箱中的 12 项端到端检查自动化层之上证据文档还跑了一次对真实构建产物的端到端 QATEAM_E2E_OUT_DIR证据目录/team-e2e-artifacts node packages/omo-senpi/scripts/qa/team-e2e.mjs驱动脚本 team-e2e.mjs 在隔离沙箱中用 mock provider 驱动完整团队流程同目录下还配有team-e2e-runtime.mjs、team-e2e-crash.mjs、team-e2e-support.mjs等协作模块。结果 PASS机器可读裁决文件 verdict.json 记录了全部 12 项检查均为true检查项含义createTwoMembersActive创建的两个成员均处于活跃状态createListsActiveMemberscreate 列表正确列出活跃成员leadToMemberEnqueuedlead → member 消息入队成功memberEnvelopeEchoed成员信封envelope被回显证明消息以完整封装注入成员回合memberToLeadInjectedmember → lead 反向注入成功leadInboxDrainedlead 收件箱被正常排空noBlockingTeamWaitCalls全程无阻塞式team_wait调用——直接印证 steer-only 语义crashHoldReached崩溃恢复流程达到预留reservation hold状态crashKilledMemberAtHold在 hold 点杀掉成员进程crashReservationUncommittedAtKill杀进程时刻预留未提交未提交状态可安全回收crashRestartExitClean重启后进程干净退出crashLivenessInjectedToLead成员崩溃的存活状态liveness信息被注入 lead除 12 项功能检查外裁决文件还记录了三项卫生指标credentialIsolationClean: true——沙箱前后凭证指纹一致驱动脚本中对应beforeCredential afterCredential的比较见 team-e2e.mjs 结果汇总leakedPids: 0——无泄漏进程wholeDirUnchanged: false——文档特别指出这是一个**非门控non-gating**字段它记录了一个发生在凭证隔离范围之外、真实的 Senpi 代理目录摘要差异但既然 Live QA 本身未失败就无需再跑 dev 基线dev-baseline QA来排除。最终result仍为PASS因为门控条件只有result PASS credentialIsolationClean leakedPids 0。此外QA 现场产物还包括 team-injection-evidence.json 等注入证据与crash-after-inject.json、crash-recovery.json等崩溃恢复快照与文档所述日志与机器可读裁决存于team-e2e.log与team-e2e-artifacts/verdict.json一一对应。6. 为什么这套证据是充分的以及有意省略了什么文档最后两节值得作为交付证据的写法范本充分性论证Why this is sufficient证据不是测试全绿的笼统声明而是把断言粒度对齐到设计意图——steer 路径断言精确的引擎结果delivered: steer并断言followUp零调用shutdown 消息器与成员扩展测试覆盖其余入站投递生产者Live QA 则在隔离沙箱中以 mock provider 驱动已构建的插件保证验证的是发布物形态。有意省略Omitted未做 dev-baseline QA 运行理由是隔离 Live QA 已 PASSwholeDirUnchanged的差异非门控且不在凭证隔离范围内除自动化渲染器与 Live E2E 覆盖外未额外跑手动交互式 TUI 会话CI synchronize 触发无功能变更no functional change。7. 可复现路径小结如果你想在自己的工作副本中复现本文证据链只读仓库中仅作查看参考通读 交付证据 README 与 verdict.json确认 12 项检查与三项卫生指标核对 mailbox 投递实现 中DeliveryMode、no_active_turn与expected_turn_id校验理解 steer 的乐观并发语义阅读 shutdown 消息器回归 与 usage-guidance确认task_send恒定 steer、team_wait已移除的契约按第 4 节命令依次跑bun test、两个tsgo --noEmit与bun run build:senpi-plugin:stage最后以TEAM_E2E_OUT_DIR指定输出目录执行 team-e2e.mjs 完成 Live QA。这一证据链给出的通用启示是对于投递语义这类跨进程、跨回合的行为变更可信度来自分层——精确断言的单元回归锁定引擎契约类型检查兜住跨包接口构建 stage 保证验证对象与发布物一致隔离 Live E2E 用崩溃注入、凭证指纹与泄漏 PID 计数把运行时卫生也纳入门控。steer-only 变更正是靠这四层证据把所有团队消息都注入运行中回合这一单句设计承诺变成了可审计、可复现的事实。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考