深入 OmO team-runtime多 Agent 团队的创建、状态监控与优雅关闭生命周期引擎【免费下载链接】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导读OmOoh-my-openagent的 team-mode 支持并行协调多个 Agent 组成团队协同工作而team-runtime正是承载这一能力生命周期的心脏——它负责team_create的成员派生、team_status的状态聚合、team_shutdown_request/team_approve_shutdown/team_reject_shutdown的关闭握手以及team_delete的整体拆除。本文以 team-runtime 的 AGENTS.md 为骨架结合其源码实现完整拆解创建 → 运行 → 状态查询 → 关闭握手 → 删除回滚的每个环节读完你可以掌握该引擎的模块划分、关键约定如 spawn-race 防护、部分失败回滚与反模式红线。一、team-runtime 在 team-mode 中的定位在 OmO 的 team-mode 架构中详见 team-mode 总览文档存在 12 个team_*工具其中生命周期类工具包括工具作用team_create根据命名或内联 TeamSpec 派生团队与成员会话team_delete拆除状态、信箱、任务列表、工作树及可选的 tmux 布局team_shutdown_request成员或 lead 请求自身关闭team_approve_shutdownlead 批准关闭team_reject_shutdownlead 附带原因拒绝关闭team-runtime就是这些工具背后的生命周期引擎。工具层位于同级目录的 tools/而team-runtime独占派生spawning、状态迁移state transitions、成员解析member resolution、布局激活layout activation与回滚rollback职责。值得注意的边界划分team-runtime的 barrel 文件 index.ts只导出resolve-member与shutdown两个模块create/delete/status则被../tools/直接消费。这意味着 shutdown 与成员解析是可复用、可重导出的公共能力而创建、删除、状态聚合是工具层专属的内部流程。从代码组织看registry、mailbox、tasklist、state、worktree、tmux-layout 等无 harness 依赖的基础原语已被抽取到packages/team-core/团队模式的适配层只保留会话派生、hooks、工具与配置集成team-runtime位于适配层内直接调用这些原语的 adapter shim如team-state-store、team-mailbox、team-worktree、team-layout-tmux。二、模块地图生命周期各环节的源码落点team-runtime目录下的文件分工明确官方文档给出的任务定位表如下路径已换算为仓库根目录相对路径任务源码位置创建一次团队运行create.tscreateTeamRun——通过 BackgroundManager 派生成员初始化信箱/任务列表/工作树激活可选的 tmux 布局状态查询status.ts关闭握手shutdown.ts shutdown-helpers.ts、shutdown-test-fixtures.ts删除与后台取消delete-team.ts、delete-team-bg-cancel.ts资源清理/回滚cleanup-team-run-resources.ts成员解析resolve-member.ts、resolve-member-dependencies.ts、unresolved-team-members.tsassertNoUnresolvedTeamMembers布局激活activate-team-layout.ts委托给../team-layout-tmux/会话级清理注册表session-team-run-registry.tsregisterTeamRunForSessionCleanup、session-cleanup.ts桶导出index.ts仅导出resolve-member与shutdown三、团队创建createTeamRun从 TeamSpec 到可运行团队的完整链路createTeamRun是team_runtime中最复杂的函数create.ts其执行流程可分为六个阶段3.1 幂等复用与存量清理创建开始前先做两件事查找已有运行findExistingRuntime遍历listActiveTeams若存在同名且状态为creating/active、leadSessionId 一致、且没有未解析成员!hasUnresolvedTeamMembers的运行直接返回避免重复创建。清理陈旧会话sweepStaleTeamSessions(activeRunIds)以 fire-and-forget 方式清除不存在的运行对应的残留 tmux 会话。随后ensureBaseDirs(baseDir)确保基础目录存在并用resolveSpecSource判定 TeamSpec 来源是project还是user作用域项目作用域优先。3.2 运行状态创建与 spawn-race 防护createRuntimeState在team-state-store中建立持久化运行状态紧接着调用registerTeamRunForSessionCleanup(teamRunId)把本次运行登记进会话级清理注册表。这是本模块最关键的约定之一会话 ID 通过轮询获得create.ts 中SESSION_ID_POLL_MS 25即每 25ms 轮询一次一旦得知 sessionId就必须同步调用registerTeamSession(sessionId, entry)注册会话防止 hooks 在 spawn 竞态窗口内查不到会话。onSessionCreated回调中同样先注册再更新运行时状态。这一 spawn-race 规则源自父级 team-mode/AGENTS.md是团队模式六大不变量之首。3.3 调用者复用 lead 会话可选当shouldReuseCallerLeadSession判定为真见 resolve-caller-team-lead.ts且 spec 指定了leadAgentId时直接复用调用方的会话作为 lead注册会话、把该成员的 sessionId 置为调用方会话并标记status: running不再为其派生新后台任务。3.4 并行派生成员worker 池核心派生逻辑采用固定 worker 池模式workerCount Math.min(config.max_parallel_members, spec.members.length)个并发 worker 通过nextMemberIndex原子取号消费成员列表直到全部派生完成或出现失败。对每个成员依次执行工作树创建若member.worktreePath存在则createMemberWorktree在项目根下递归创建支持绝对路径或相对路径。成员解析调用resolveMember详见下文第四节得到实际使用的 agent、模型、fallback 链与系统提示词。后台启动通过bgMgr.launch派生后台任务注入buildMemberPrompt拼接的提示词包含 Team 名、TeamRunId、Member 名、可选的 Worktree 路径、成员自定义 prompt 以及buildTeammateCommunicationAddendum生成的队友通信指引同时传入解析出的 model、fallbackChain、skillContent 等并以QUESTION_DENIED_SESSION_PERMISSION作为会话权限。若成员有工作树则后台任务 cwd 指向工作树。会话等待与注册waitForTaskSessionId以 25ms 为步长轮询任务 sessionId超过max_wall_clock_minutes期限或任务进入 error/cancelled/interrupt 状态即抛错拿到 sessionId 后再次registerTeamSession并把解析出的模型参数providerID、modelID、variant、reasoningEffort、temperature、top_p、maxTokens、thinking持久化进运行时状态。所有成员派生完成后assertNoUnresolvedTeamMembers校验每个成员都已绑定 sessionId否则抛错因为运行不能带着未解析成员进入 active 状态。3.5 布局激活与状态收尾activateTeamLayout(launchedRuntimeState, config, ctx.directory, tmuxMgr)在tmux_visualization开启且提供 tmux manager 时为所有非 lead 成员创建 pane 布局focus pane grid pane并把tmuxLayout、各成员的tmuxPaneId/tmuxGridPaneId写入运行时状态activate-team-layout.ts。最后通过transitionRuntimeState把状态从creating迁移到activecreateTeamRun返回最终 RuntimeState。3.6 部分失败回滚TeamRunCreateError cleanupReport整个派生过程包裹在 try/catch 中。一旦任何一步失败立即调用cleanupTeamRunResources执行回滚并抛出携带cleanupReport的TeamRunCreateErrorcreate.tsTeamRunCreateError └── cleanupReport ├── cancelledTaskIds: string[] // 已取消的后台任务 ├── removedLayout: boolean // 是否已移除 tmux 布局 ├── removedWorktrees: string[] // 已删除的工作树路径 └── errors: string[] // 回滚过程中个别步骤自身的错误回滚实现cleanup-team-run-resources.ts按逆序遍历已派生的资源取消任务skipNotification: true、递归删除工作树、移除已创建的 tmux 布局、把运行时状态迁移到failed最后注销会话与清理注册表。即使单个清理步骤出错也绝不中断——错误被收集进errors数组继续执行这正是绝不让失败的 create 半残留这一反模式红线的代码体现。四、成员解析resolveMember两种成员类型的落地差异resolveMemberresolve-member.ts根据 TeamSpec 中成员的kind走两条完全不同的解析路径kind: subagent_type直接解析为指定 agent如sisyphus通过resolveSubagentExecution确定 agentToUse、模型与 fallback 链并允许allowSisyphusJuniorDirect与allowPrimaryAgentDelegation。kind: category路由到sisyphus-junior通过resolveCategoryExecution按类别选择模型prompt为必填。这里有一个反直觉的实现细节resolve-member.ts解析前会剥离全局agents.sisyphus-junior.model覆盖withoutSisyphusJuniorOverride。注释解释了原因resolveCategoryExecution会把该全局覆盖排在类别默认值之上——对普通task(category…)这是正确的但对团队模式却是错误的会导致所有团队成员坍缩到同一个模型。依赖项集中在 resolve-member-dependencies.ts它只是从 delegate-task 工具层重导出resolveCategoryExecution、resolveSubagentExecution、buildSystemContent三个函数说明成员解析与普通 delegate-task 复用同一套模型解析与系统提示词构建机制。解析失败时抛出的TeamMemberResolutionError会携带 memberName 便于定位。五、状态聚合aggregateStatusteam_status 背后的数据拼装team_status工具的数据源是 status.ts 中的aggregateStatus它把分散在多处的运行时数据拼装成一份结构化TeamStatus字段来源与含义teamName/teamRunId/status/createdAt/leadSessionId直接来自team-state-store的 RuntimeStatemembers[]每个成员的状态、sessionId、颜色、worktreePath、tmux paneId并附带未读消息数通过listUnreadMessages统计信箱tasks{}按pending / claimed / in_progress / completed / deleted / total六档统计共享任务列表countTasksshutdownRequests运行时状态中保存的关闭请求数组concurrency{}runningOnSameModel/queuedOnSameModel基于 lead 会话的主模型键统计同模型并发以及teamRunIdSpecific该运行专属的后台任务数bounds运行时记录的执行边界来自配置的各类上限staleLocks扫描任务认领目录claims/下的.lock文件用detectStaleLock(lockPath, 300_000)检测超过 5 分钟未更新的陈旧锁值得注意未读消息数对每个成员都做了一次异步listUnreadMessages并行Promise.all而并发统计优先使用 BackgroundManager 的getConcurrencyCounts不可用时退化为按 lead 会话的后台任务 status 估算——这种优先精确、降级估算的策略保证了查询在缺少 manager 注入时依然可用。六、关闭握手shutdown_request / approve / reject 三件套关闭握手位于 shutdown.ts由三个函数构成6.1 requestShutdownOfMember发起请求校验目标成员与请求者都存在于运行时状态getRuntimeMember否则抛unknown member。去重若存在同一memberId requesterName的未决请求既未 approve 也未 reject直接返回不重复投递。通过sendMessage向目标成员投递shutdown_request类型的消息消息结构见 shutdown-helpers.tsversion: 1、messageId为 UUID、from/to/kind/body/timestamp。在transitionRuntimeState中追加一条{ memberId, requesterName, requestedAt }记录内部同样做了去重保护。6.2 approveShutdown批准按memberName找到最新的关闭请求findLatestShutdownRequestIndex从数组尾部向前扫描不存在则抛错。将目标成员状态迁移为shutdown_approved已completed/errored的成员跳过。在请求记录上写入approvedAt并向 lead 投递shutdown_approved消息。6.3 rejectShutdown拒绝找到最新请求后若已拒绝且rejectedReason与本次一致则幂等返回。向请求者shutdownRequest.requesterName投递携带拒绝原因的shutdown_rejected消息。在请求记录上写入rejectedAt与rejectedReason。三个函数全部遵循先消息、后状态的顺序且状态写入都经过transitionRuntimeState的原子迁移temp 文件 rename与 team-mode 的原子写入不变量一致。七、删除与资源清理team_delete 与后台取消deleteTeamdelete-team.ts是拆除整支团队运行的入口包含两层防护与两条路径状态门槛普通删除只允许active / shutdown_requested / deleting / deletedDELETABLE_TEAM_STATUSES并且所有非 lead 成员必须处于completed / shutdown_approved / erroredDELETABLE_MEMBER_STATUSES定义于 shutdown-helpers.ts否则抛members still active。force: true额外允许creating / orphaned状态并把pending / running / idle的成员强制标记为completed。后台任务处理通过 lead 会话找到属于本团队的后台任务按teamRunId或team-create:${teamRunId}:前缀的 parentMessageId 过滤非 force 模式下存在pending/running任务即拒绝删除force 模式下则逐个cancelTasksource 为team-mode-delete。随后deleteTeamResources依次执行迁移状态到deletingcreating/orphaned 且 force 时直接saveRuntimeState跳过 transition→ 移除 tmux 布局仅当tmux_visualization开启收集非 lead 成员的 paneId 作为清理目标force 模式下布局清理失败只记日志不中断→removeWorktrees删除全部成员工作树 → 迁移状态到deleted→ 删除运行时状态目录本身 → 注销会话与清理注册表 → 再次 sweep 陈旧 tmux 会话。与创建回滚不同删除路径还联动 delete-team-bg-cancel.ts 处理更细粒度的后台取消逻辑该文件配有独立测试 delete-team-bg-cancel.test.ts。八、关键约定CONVENTIONS与反模式ANTI-PATTERNS本模块的三条核心约定部分失败必回滚create.ts失败时抛出携带cleanupReport的TeamRunCreateErrorcancelledTaskIds、removedLayout、removedWorktrees、errors四元组必须如实反映创建过程中获取的每一个资源都必须出现在失败报告中。会话轮询注册会话 ID 以SESSION_ID_POLL_MS 25毫秒轮询直到已知随后同步调用registerTeamSession()——这是源自父级 AGENTS.md 的 spawn-race 规则。调用者 lead 复用是否复用调用方会话作为 lead由 resolve-caller-team-lead.ts 的shouldReuseCallerLeadSession决定。三条反模式红线绝不未经注册就派生成员必须在../team-session-registry.ts注册会话之后才能派生否则 hooks 会在 spawn 竞态窗口内找不到会话。绝不让失败的 create 半残留即使个别清理步骤出错回滚路径也必须执行到底错误进errors数组不中断整体回滚。不在本模块直接写持久化状态持久化状态必须经由../team-state-store/的原子锁机制写入禁止绕过。九、测试佐证与进一步阅读team-runtime的每个核心能力都有配套测试可作为行为契约阅读创建链路create.test.ts覆盖幂等复用、并行派生、失败回滚状态聚合status.test.ts关闭握手shutdown.test.ts含 shutdown-test-fixtures.ts 提供的夹具成员解析resolve-member.test.ts布局激活activate-team-layout.test.ts回滚清理cleanup-team-run-resources.test.ts会话级清理session-cleanup.test.ts想继续深入建议按以下顺序阅读团队模式总览与配置项team-mode/AGENTS.md含team_mode完整配置 schema、12 工具清单、Agent 准入三级判定、存储布局、六大不变量用户视角的实战文档docs/guide/team-mode.md无 harness 依赖的基础原语packages/team-coreregistry/mailbox/tasklist/state/worktree/tmux-layout 的通用实现生命周期工具的对外封装tools/lifecycle.ts 与 tools/query.ts。需要特别提醒的运行时前提team-mode 默认关闭需在.omo/omo.jsonc中设置team_mode.enabled: true并重启 OpenCode 才生效team-runtime的所有派生、状态迁移与布局激活行为都受该配置max_parallel_members、max_wall_clock_minutes、tmux_visualization等约束。理解这份 AGENTS.md 与源码的对应关系你就能在排查团队生命周期问题时从工具报错快速定位到引擎的哪一层。【免费下载链接】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），仅供参考
深入 OmO team-runtime多 Agent 团队的创建、状态监控与优雅关闭生命周期引擎【免费下载链接】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导读OmOoh-my-openagent的 team-mode 支持并行协调多个 Agent 组成团队协同工作而team-runtime正是承载这一能力生命周期的心脏——它负责team_create的成员派生、team_status的状态聚合、team_shutdown_request/team_approve_shutdown/team_reject_shutdown的关闭握手以及team_delete的整体拆除。本文以 team-runtime 的 AGENTS.md 为骨架结合其源码实现完整拆解创建 → 运行 → 状态查询 → 关闭握手 → 删除回滚的每个环节读完你可以掌握该引擎的模块划分、关键约定如 spawn-race 防护、部分失败回滚与反模式红线。一、team-runtime 在 team-mode 中的定位在 OmO 的 team-mode 架构中详见 team-mode 总览文档存在 12 个team_*工具其中生命周期类工具包括工具作用team_create根据命名或内联 TeamSpec 派生团队与成员会话team_delete拆除状态、信箱、任务列表、工作树及可选的 tmux 布局team_shutdown_request成员或 lead 请求自身关闭team_approve_shutdownlead 批准关闭team_reject_shutdownlead 附带原因拒绝关闭team-runtime就是这些工具背后的生命周期引擎。工具层位于同级目录的 tools/而team-runtime独占派生spawning、状态迁移state transitions、成员解析member resolution、布局激活layout activation与回滚rollback职责。值得注意的边界划分team-runtime的 barrel 文件 index.ts只导出resolve-member与shutdown两个模块create/delete/status则被../tools/直接消费。这意味着 shutdown 与成员解析是可复用、可重导出的公共能力而创建、删除、状态聚合是工具层专属的内部流程。从代码组织看registry、mailbox、tasklist、state、worktree、tmux-layout 等无 harness 依赖的基础原语已被抽取到packages/team-core/团队模式的适配层只保留会话派生、hooks、工具与配置集成team-runtime位于适配层内直接调用这些原语的 adapter shim如team-state-store、team-mailbox、team-worktree、team-layout-tmux。二、模块地图生命周期各环节的源码落点team-runtime目录下的文件分工明确官方文档给出的任务定位表如下路径已换算为仓库根目录相对路径任务源码位置创建一次团队运行create.tscreateTeamRun——通过 BackgroundManager 派生成员初始化信箱/任务列表/工作树激活可选的 tmux 布局状态查询status.ts关闭握手shutdown.ts shutdown-helpers.ts、shutdown-test-fixtures.ts删除与后台取消delete-team.ts、delete-team-bg-cancel.ts资源清理/回滚cleanup-team-run-resources.ts成员解析resolve-member.ts、resolve-member-dependencies.ts、unresolved-team-members.tsassertNoUnresolvedTeamMembers布局激活activate-team-layout.ts委托给../team-layout-tmux/会话级清理注册表session-team-run-registry.tsregisterTeamRunForSessionCleanup、session-cleanup.ts桶导出index.ts仅导出resolve-member与shutdown三、团队创建createTeamRun从 TeamSpec 到可运行团队的完整链路createTeamRun是team_runtime中最复杂的函数create.ts其执行流程可分为六个阶段3.1 幂等复用与存量清理创建开始前先做两件事查找已有运行findExistingRuntime遍历listActiveTeams若存在同名且状态为creating/active、leadSessionId 一致、且没有未解析成员!hasUnresolvedTeamMembers的运行直接返回避免重复创建。清理陈旧会话sweepStaleTeamSessions(activeRunIds)以 fire-and-forget 方式清除不存在的运行对应的残留 tmux 会话。随后ensureBaseDirs(baseDir)确保基础目录存在并用resolveSpecSource判定 TeamSpec 来源是project还是user作用域项目作用域优先。3.2 运行状态创建与 spawn-race 防护createRuntimeState在team-state-store中建立持久化运行状态紧接着调用registerTeamRunForSessionCleanup(teamRunId)把本次运行登记进会话级清理注册表。这是本模块最关键的约定之一会话 ID 通过轮询获得create.ts 中SESSION_ID_POLL_MS 25即每 25ms 轮询一次一旦得知 sessionId就必须同步调用registerTeamSession(sessionId, entry)注册会话防止 hooks 在 spawn 竞态窗口内查不到会话。onSessionCreated回调中同样先注册再更新运行时状态。这一 spawn-race 规则源自父级 team-mode/AGENTS.md是团队模式六大不变量之首。3.3 调用者复用 lead 会话可选当shouldReuseCallerLeadSession判定为真见 resolve-caller-team-lead.ts且 spec 指定了leadAgentId时直接复用调用方的会话作为 lead注册会话、把该成员的 sessionId 置为调用方会话并标记status: running不再为其派生新后台任务。3.4 并行派生成员worker 池核心派生逻辑采用固定 worker 池模式workerCount Math.min(config.max_parallel_members, spec.members.length)个并发 worker 通过nextMemberIndex原子取号消费成员列表直到全部派生完成或出现失败。对每个成员依次执行工作树创建若member.worktreePath存在则createMemberWorktree在项目根下递归创建支持绝对路径或相对路径。成员解析调用resolveMember详见下文第四节得到实际使用的 agent、模型、fallback 链与系统提示词。后台启动通过bgMgr.launch派生后台任务注入buildMemberPrompt拼接的提示词包含 Team 名、TeamRunId、Member 名、可选的 Worktree 路径、成员自定义 prompt 以及buildTeammateCommunicationAddendum生成的队友通信指引同时传入解析出的 model、fallbackChain、skillContent 等并以QUESTION_DENIED_SESSION_PERMISSION作为会话权限。若成员有工作树则后台任务 cwd 指向工作树。会话等待与注册waitForTaskSessionId以 25ms 为步长轮询任务 sessionId超过max_wall_clock_minutes期限或任务进入 error/cancelled/interrupt 状态即抛错拿到 sessionId 后再次registerTeamSession并把解析出的模型参数providerID、modelID、variant、reasoningEffort、temperature、top_p、maxTokens、thinking持久化进运行时状态。所有成员派生完成后assertNoUnresolvedTeamMembers校验每个成员都已绑定 sessionId否则抛错因为运行不能带着未解析成员进入 active 状态。3.5 布局激活与状态收尾activateTeamLayout(launchedRuntimeState, config, ctx.directory, tmuxMgr)在tmux_visualization开启且提供 tmux manager 时为所有非 lead 成员创建 pane 布局focus pane grid pane并把tmuxLayout、各成员的tmuxPaneId/tmuxGridPaneId写入运行时状态activate-team-layout.ts。最后通过transitionRuntimeState把状态从creating迁移到activecreateTeamRun返回最终 RuntimeState。3.6 部分失败回滚TeamRunCreateError cleanupReport整个派生过程包裹在 try/catch 中。一旦任何一步失败立即调用cleanupTeamRunResources执行回滚并抛出携带cleanupReport的TeamRunCreateErrorcreate.tsTeamRunCreateError └── cleanupReport ├── cancelledTaskIds: string[] // 已取消的后台任务 ├── removedLayout: boolean // 是否已移除 tmux 布局 ├── removedWorktrees: string[] // 已删除的工作树路径 └── errors: string[] // 回滚过程中个别步骤自身的错误回滚实现cleanup-team-run-resources.ts按逆序遍历已派生的资源取消任务skipNotification: true、递归删除工作树、移除已创建的 tmux 布局、把运行时状态迁移到failed最后注销会话与清理注册表。即使单个清理步骤出错也绝不中断——错误被收集进errors数组继续执行这正是绝不让失败的 create 半残留这一反模式红线的代码体现。四、成员解析resolveMember两种成员类型的落地差异resolveMemberresolve-member.ts根据 TeamSpec 中成员的kind走两条完全不同的解析路径kind: subagent_type直接解析为指定 agent如sisyphus通过resolveSubagentExecution确定 agentToUse、模型与 fallback 链并允许allowSisyphusJuniorDirect与allowPrimaryAgentDelegation。kind: category路由到sisyphus-junior通过resolveCategoryExecution按类别选择模型prompt为必填。这里有一个反直觉的实现细节resolve-member.ts解析前会剥离全局agents.sisyphus-junior.model覆盖withoutSisyphusJuniorOverride。注释解释了原因resolveCategoryExecution会把该全局覆盖排在类别默认值之上——对普通task(category…)这是正确的但对团队模式却是错误的会导致所有团队成员坍缩到同一个模型。依赖项集中在 resolve-member-dependencies.ts它只是从 delegate-task 工具层重导出resolveCategoryExecution、resolveSubagentExecution、buildSystemContent三个函数说明成员解析与普通 delegate-task 复用同一套模型解析与系统提示词构建机制。解析失败时抛出的TeamMemberResolutionError会携带 memberName 便于定位。五、状态聚合aggregateStatusteam_status 背后的数据拼装team_status工具的数据源是 status.ts 中的aggregateStatus它把分散在多处的运行时数据拼装成一份结构化TeamStatus字段来源与含义teamName/teamRunId/status/createdAt/leadSessionId直接来自team-state-store的 RuntimeStatemembers[]每个成员的状态、sessionId、颜色、worktreePath、tmux paneId并附带未读消息数通过listUnreadMessages统计信箱tasks{}按pending / claimed / in_progress / completed / deleted / total六档统计共享任务列表countTasksshutdownRequests运行时状态中保存的关闭请求数组concurrency{}runningOnSameModel/queuedOnSameModel基于 lead 会话的主模型键统计同模型并发以及teamRunIdSpecific该运行专属的后台任务数bounds运行时记录的执行边界来自配置的各类上限staleLocks扫描任务认领目录claims/下的.lock文件用detectStaleLock(lockPath, 300_000)检测超过 5 分钟未更新的陈旧锁值得注意未读消息数对每个成员都做了一次异步listUnreadMessages并行Promise.all而并发统计优先使用 BackgroundManager 的getConcurrencyCounts不可用时退化为按 lead 会话的后台任务 status 估算——这种优先精确、降级估算的策略保证了查询在缺少 manager 注入时依然可用。六、关闭握手shutdown_request / approve / reject 三件套关闭握手位于 shutdown.ts由三个函数构成6.1 requestShutdownOfMember发起请求校验目标成员与请求者都存在于运行时状态getRuntimeMember否则抛unknown member。去重若存在同一memberId requesterName的未决请求既未 approve 也未 reject直接返回不重复投递。通过sendMessage向目标成员投递shutdown_request类型的消息消息结构见 shutdown-helpers.tsversion: 1、messageId为 UUID、from/to/kind/body/timestamp。在transitionRuntimeState中追加一条{ memberId, requesterName, requestedAt }记录内部同样做了去重保护。6.2 approveShutdown批准按memberName找到最新的关闭请求findLatestShutdownRequestIndex从数组尾部向前扫描不存在则抛错。将目标成员状态迁移为shutdown_approved已completed/errored的成员跳过。在请求记录上写入approvedAt并向 lead 投递shutdown_approved消息。6.3 rejectShutdown拒绝找到最新请求后若已拒绝且rejectedReason与本次一致则幂等返回。向请求者shutdownRequest.requesterName投递携带拒绝原因的shutdown_rejected消息。在请求记录上写入rejectedAt与rejectedReason。三个函数全部遵循先消息、后状态的顺序且状态写入都经过transitionRuntimeState的原子迁移temp 文件 rename与 team-mode 的原子写入不变量一致。七、删除与资源清理team_delete 与后台取消deleteTeamdelete-team.ts是拆除整支团队运行的入口包含两层防护与两条路径状态门槛普通删除只允许active / shutdown_requested / deleting / deletedDELETABLE_TEAM_STATUSES并且所有非 lead 成员必须处于completed / shutdown_approved / erroredDELETABLE_MEMBER_STATUSES定义于 shutdown-helpers.ts否则抛members still active。force: true额外允许creating / orphaned状态并把pending / running / idle的成员强制标记为completed。后台任务处理通过 lead 会话找到属于本团队的后台任务按teamRunId或team-create:${teamRunId}:前缀的 parentMessageId 过滤非 force 模式下存在pending/running任务即拒绝删除force 模式下则逐个cancelTasksource 为team-mode-delete。随后deleteTeamResources依次执行迁移状态到deletingcreating/orphaned 且 force 时直接saveRuntimeState跳过 transition→ 移除 tmux 布局仅当tmux_visualization开启收集非 lead 成员的 paneId 作为清理目标force 模式下布局清理失败只记日志不中断→removeWorktrees删除全部成员工作树 → 迁移状态到deleted→ 删除运行时状态目录本身 → 注销会话与清理注册表 → 再次 sweep 陈旧 tmux 会话。与创建回滚不同删除路径还联动 delete-team-bg-cancel.ts 处理更细粒度的后台取消逻辑该文件配有独立测试 delete-team-bg-cancel.test.ts。八、关键约定CONVENTIONS与反模式ANTI-PATTERNS本模块的三条核心约定部分失败必回滚create.ts失败时抛出携带cleanupReport的TeamRunCreateErrorcancelledTaskIds、removedLayout、removedWorktrees、errors四元组必须如实反映创建过程中获取的每一个资源都必须出现在失败报告中。会话轮询注册会话 ID 以SESSION_ID_POLL_MS 25毫秒轮询直到已知随后同步调用registerTeamSession()——这是源自父级 AGENTS.md 的 spawn-race 规则。调用者 lead 复用是否复用调用方会话作为 lead由 resolve-caller-team-lead.ts 的shouldReuseCallerLeadSession决定。三条反模式红线绝不未经注册就派生成员必须在../team-session-registry.ts注册会话之后才能派生否则 hooks 会在 spawn 竞态窗口内找不到会话。绝不让失败的 create 半残留即使个别清理步骤出错回滚路径也必须执行到底错误进errors数组不中断整体回滚。不在本模块直接写持久化状态持久化状态必须经由../team-state-store/的原子锁机制写入禁止绕过。九、测试佐证与进一步阅读team-runtime的每个核心能力都有配套测试可作为行为契约阅读创建链路create.test.ts覆盖幂等复用、并行派生、失败回滚状态聚合status.test.ts关闭握手shutdown.test.ts含 shutdown-test-fixtures.ts 提供的夹具成员解析resolve-member.test.ts布局激活activate-team-layout.test.ts回滚清理cleanup-team-run-resources.test.ts会话级清理session-cleanup.test.ts想继续深入建议按以下顺序阅读团队模式总览与配置项team-mode/AGENTS.md含team_mode完整配置 schema、12 工具清单、Agent 准入三级判定、存储布局、六大不变量用户视角的实战文档docs/guide/team-mode.md无 harness 依赖的基础原语packages/team-coreregistry/mailbox/tasklist/state/worktree/tmux-layout 的通用实现生命周期工具的对外封装tools/lifecycle.ts 与 tools/query.ts。需要特别提醒的运行时前提team-mode 默认关闭需在.omo/omo.jsonc中设置team_mode.enabled: true并重启 OpenCode 才生效team-runtime的所有派生、状态迁移与布局激活行为都受该配置max_parallel_members、max_wall_clock_minutes、tmux_visualization等约束。理解这份 AGENTS.md 与源码的对应关系你就能在排查团队生命周期问题时从工具报错快速定位到引擎的哪一层。【免费下载链接】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），仅供参考
