Gas Town Mountain-Eater 设计解析基于 Convoy 的自主史诗研磨与卡死自愈机制【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown本文聚焦 Gas Townmulti-agent workspace manager中用于大型史诗自主执行的设计文档 mountain-eater.md。该文档提出了在机械式 ConvoyManager 之上叠加判断层Mountain-Eater的完整方案用mountain标签作为选入机制由 Witness 跟踪 polecat 失败并自动跳过、Deacon Dog 周期性审计进度并派发调查、Mayor 负责人工级升级通知。读完本文你将掌握四层研磨架构的工作原理、gt mountain命令族的完整用法、失败跳过与恢复的语义以及哪些部分已在仓库中落地internal/cmd/mountain.go、internal/witness/mountain.go哪些仍处于设计阶段。1. 背景与问题为什么大型史诗会卡死Gas Town 已经拥有自主史诗执行的几乎所有机械零件已有能力说明ConvoyManager 事件驱动喂给阻塞依赖关闭时事件驱动喂入下一个就绪 issue5 秒轮询滞留扫描stranded scan周期性兜底防止喂给被遗漏30 秒stage-launch校验 DAG 并计算波次基于 Kahn 算法Polecat执行单个 issueWitness / Refinery监控 polecat、合并变更然而用户报告大型史诗卡住创建一座任务山mountain of beads、启动 convoy、离开数小时回来发现 convoy 停在 40% 且没有任何原因提示。根因ConvoyManager 是机械式的。它只会在某个 issue 关闭时喂入下一个就绪 issue无法推理失败模式、无法做跳过决策、无法智能升级。当一个 polecat 在同一个 issue 上反复失败时机械系统会无限次地重新 sling 它当依赖图之外存在微妙的阻塞条件时没有任何组件会发现。Mountain-Eater 在机械喂给之上增加了一层判断层judgment layer——由 Agent 驱动的停滞检测、失败 N 次后跳过、智能升级和完成通知。2. 核心设计原则没有任何 Agent 持有主线单协调者方案失败的根源是滞后hysteresis任何维持我在驱动这个史诗循环的 Agent 都会在压缩compaction时丢失主线。即使史诗被挂钩重新 prime 的 Agent 也不会记得协调上下文。Mountain-Eater 完全绕开了这个问题史诗本身就是主线The epic IS the thread——beads 就是状态没有 Agent 需要记住任何东西——每次检查都从状态中全新发现Dog 每次带来全新上下文——从构造上杜绝 hysteresis标签触发巡逻行为——不需要持久的协调者。这与 Gas Town 的核心原则一脉相承ZFCZero Formal CoordinationAgent 做决策Go 负责传输。ConvoyManager 是传输层Dog 做判断。NDINo Designated Identity任何 Dog 都能检查任何一座山。不同 Agent相同结果。Discover, Dont Trackbd ready --epicX与 convoy 状态都从 beads 推导而非追踪。Float over Integer卡住的 issue 不会让整座山停摆——工作会绕过它继续流动。3. 架构总览四层研磨Four-Layer GrindingLayer 0: CONVOY MANAGER (mechanical, Go daemon —— 已构建) 事件驱动喂给 滞留扫描 处理快乐路径issue 关闭 → 喂入下一个就绪 issue Layer 1: WITNESS (reactive, per-rig —— 增强) mountain convoy issue 的 polecat 失败跟踪 同一 issue 失败 3 次及以上 → 标记 blocked、跳过、喂下一个 Layer 2: DEACON DOG (periodic, cross-rig —— 新增) 自上次检查以来这座山有进展吗 全新 Dog 在完整上下文下调查停滞 做出判断跳过、重构、升级 停滞与完成时通知 Mayor Layer 3: MAYOR (strategic, user-facing —— 增强) 接收来自 Layer 2 的停滞升级 跨 rig 判断 完成或不可恢复停滞时通知用户Layer 0已存在处理约 80% 的 convoy 执行。Layer 1-2就是 Mountain-Eater——处理那 20% 卡住的部分。Layer 3是约 2% 需要人工判断时的升级路径。为什么要四层冗余监控本身就是韧性redundant monitoring is resilience如果 Witness 漏掉一次完成崩溃、压缩ConvoyManager 会在 5 秒事件轮询中补上如果 ConvoyManager 反复喂入坏 issueWitness 会抓住失败模式如果两者都漏掉停滞Deacon Dog 会在下一个巡逻周期补上。每一层都独立运作并从 beads 中发现状态不存在单点故障。这与 convoy 规范文档 中冗余观察redundant observation的要求一致——该规范指出多个 Agent 都能检测完成确保没有单一失败会阻断循环。4.mountain标签选入机制与命令入口一座 mountain 就是带有mountain标签的 convoy。不需要新的实体类型不需要新的数据库 schema。标签本身就是 Layer 1-2 的选入opt-in开关。# 在史诗上激活 Mountain-Eater gt mountain epic-id # 内部执行序列 # 1. gt convoy stage epic-id ← 校验 DAG、计算波次 # 2. bd update convoy --add-label mountain ← 触发判断层 # 3. gt convoy launch convoy-id ← 派发 Wave 1ConvoyManager 接管 # 查看进度 gt mountain status [epic-id|convoy-id] # 暂停/恢复保留标签停止/恢复派发 gt mountain pause epic-id|convoy-id gt mountain resume epic-id|convoy-id # 取消移除标签留下 convoy 供手动管理 gt mountain cancel epic-id|convoy-id普通 convoy无mountain标签的行为与今天完全一致。mountain标签把 convoy 选入增强的停滞检测、失败 N 次后跳过、以及主动进度监控。何时用 Mountain何时用普通 Convoy场景选择批量 sling 3-5 个任务普通 convoyConvoyManager 足够10 任务且带 DAG 依赖的大型史诗Mountain跨 rig 史诗Mountain需要 Dog 的跨 rig 可见性去吃午饭然后回来发现它已完成Mountain快速并行任务、无依赖普通 convoy源码视角gt mountain的真实实现该 CLI 已在仓库中落地核心逻辑位于 internal/cmd/mountain.go。runMountain的流程与设计文档完全对应校验输入是史诗调用bdShow(epicID)若非epic类型则报错mountains require an epicmountain.goStagecollectBeads收集 beads、buildConvoyDAG构建 DAG、detectErrors/detectWarnings做结构校验、computeWaves计算波次mountain.go创建 staged convoy标题自动加前缀Mountain: title : Mountain: result.Title加标签通过bdAddLabelTown(convoyID, mountain)在 town beads 库执行bd update convoy --add-labelmountainLaunchtransitionConvoyToOpen转换状态并dispatchWave1派发第一波。命令还支持--force带警告继续启动与--json机器可读输出两个 flagmountain.go。暂停/恢复通过mountain:paused标签实现pause加标签、resume移除标签cancel则移除mountain标签并尽力移除mountain:pausedmountain.go。resolveMountainID同时接受 epic-id 或 convoy-id 作为输入mountain.go。5. Layer 1Witness 失败跟踪已实现问题当一个 polecat 在 mountain issue 上失败时ConvoyManager 的滞留扫描会重新 sling 它。如果 issue 有根本性问题描述糟糕、任务不可能完成、缺少上下文就会形成无限 sling-失败循环。增强Witness 已经在监控 polecat 完成情况。增强点对属于 mountain convoy 的 issue 增加失败跟踪WITNESS PATROL — mountain failure tracking: For each polecat that exited without completing its issue: issue polecats hooked bead convoy tracking convoy for this issue (if any) if convoy has mountain label: increment failure count for this issue (stored as issue note or label) if failure_count 3: bd update issue --statusblocked --add-label mountain:skipped bd update issue --notes Skipped by Mountain-Eater after 3 polecat failures log: Mountain: skipped issue after 3 failures # ConvoyManagers next feed will skip this issue (blocked status) # and feed the next ready issue instead失败计数存储使用形如mountain:failures:3的标签挂在 issue 上。标签廉价、可查询、在bd show中可见。无需新 schema。为什么是 Witness 而不是 ConvoyManagerWitness 已经观察 polecat 生命周期它知道 polecat 是成功完成还是崩溃了。ConvoyManager 只看到 issue 状态变化——它无法区分polecat 失败了和polecat 还在工作。源码证据internal/witness/mountain.goLayer 1 已在仓库中完整实现位于 internal/witness/mountain.go阈值常量MountainMaxFailures 3且被导出供测试使用mountain.gotrackConvoyFailures由 zombie 检测DetectZombiePolecats在所有 zombie 收集完成后调用只对有活跃工作且未完成的 zombie 计数zombie.HookBead || !zombieImpliesActiveFailure(*zombie)时跳过ZombieBeadClosedStillRunning与ZombieSubmittedStillRunning这两种不构成活跃失败mountain.goTrackConvoyFailure通过bd dep list issue --directionup --typetracks --json找到跟踪该 issue 的 convoy再检查 convoy 是否带mountain标签mountain 走trackMountainFailure普通 convoy 只记录警告mountain.gotrackMountainFailure从 issue 标签中解析当前mountain:failures:NupdateMountainFailureCount先移除旧计数标签再加新计数标签mountain.go达到 3 次后skipMountainIssue执行bd update issue --statusblocked --add-label mountain:skipped --notes Skipped by Mountain-Eater after N polecat failuresmountain.go。对应的单元测试在 internal/witness/mountain_test.goTestGetMountainFailureCount覆盖无标签、无失败标签、mountain:failures:1、mountain:failures:3、非法计数mountain:failures:abc与空计数等六种情形TestHasLabel验证标签精确匹配语义mountain:failures:1不等于mountain。跳过语义Skip Semantics被跳过的 issue带mountain:skipped标签、blocked状态具有如下性质从就绪队列排除blocked 状态在gt mountain status输出中可见由 Layer 2Deacon Dog升级给 Mayor可恢复bd update issue --statusopen --remove-label mountain:skipped。Mountain 会继续绕着被跳过的 issue 研磨。如果被跳过的 issue 在 DAG 中阻塞了其他工作那些依赖项仍保持 blocked——Dog 会在停滞诊断中报告这一点。6. Layer 2Deacon Dog 山岳审计设计中注意截至当前仓库状态Layer 2 的巡逻公式与mol-mountain-dog.formula.toml属于设计提案设计文档状态标注为Design在internal/formula目录中尚未出现对应实现。以下内容忠实还原设计文档作为实现蓝图解读。核心循环Deacon 的巡逻公式增加一个mountain-audit步骤DEACON PATROL — mountain-audit step: mountains bd list --label mountain --statusopen --typeconvoy for each mountain: dog_needed false # Progress check (compare against last audit) current_closed count of closed issues in this convoy last_closed read from mountain:audit:convoy-id label on deacon bead if current_closed last_closed: # Making progress — update audit mark, continue update mountain:audit:convoy-id current_closed else if current_closed total_issues: # Complete — dispatch Dog for cleanup notification dog_needed true dog_task complete else: # No progress since last check — dispatch Dog to investigate dog_needed true dog_task stall if dog_needed: sling mountain-dog formula to a Dog with convoy-id and task typeMountain Dog 公式mol-mountain-dog.formula.toml—— 一个短命的 Dog 公式用于调查 mountain 进度[formula] name mountain-dog description Investigate mountain convoy progress type worker [formula.variables] convoy_id { required true } task { required true } # stall or complete [[formula.steps]] name investigate description You are a Mountain Dog investigating a mountain convoy. Convoy: {{convoy_id}} Task: {{task}} If task is stall: 1. Run: gt convoy status {{convoy_id}} 2. Identify why no progress: - Are there skipped issues (mountain:skipped label)? - Are all remaining issues blocked? By what? - Are polecats active but slow? - Is the refinery backed up? 3. If there are ready issues with no polecats: sling them 4. If all remaining issues are skipped/blocked: Mail Mayor: Mountain {{convoy_id}} stalled: N skipped, M blocked. Remaining DAG cannot progress without intervention. 5. If polecats are active: this is fine, no action needed If task is complete: 1. Run: gt convoy status {{convoy_id}} 2. Verify all tracked issues are closed 3. If any skipped issues remain: Mail Mayor: Mountain {{convoy_id}} finished with N skipped issues. Review skipped work: [list issue IDs] 4. If all clean: Mail Mayor: Mountain {{convoy_id}} complete. N issues closed in Xh Ym. 5. Run: gt convoy close {{convoy_id}} 让这套机制成立的 Dog 特性全新上下文Fresh contextDog 从零状态开始从头读取 convoy 与 beads无前序会话的 hysteresis窄范围Narrow scope一个 convoy、一个问题卡住了或完成了吗轻松装进单个上下文窗口短命Ephemeral做完工作、汇报、消亡无长期协调跨 rig 可见性Cross-rig visibilityDog 拥有通向多个 rig 的 worktree可以跨 rig 检查 beads 状态这对跨 rig convoy 至关重要。审计频率Deacon 巡逻周期决定山的审计频率。当前 Deacon 巡逻运行在 feed 驱动 heartbeat 模型上。对 mountain 而言关键问题是一座山卡住多久才会有人注意到目标10-15 分钟内检测到停滞机制Deacon 的 heartbeat 间隔守护进程根据活动每 5-10 分钟 poke Deacon 一次。每次 heartbeat 运行包含 mountain-audit 步骤的巡逻公式成本每个巡逻周期一次bd list --label mountain查询廉价外加每个卡住的山一次 Dog spawn仅在需要时。7. Layer 3Mayor 通知设计中Mayor 从 Dog 收到两类 mountain 邮件停滞通知Subject: Mountain stalled: convoy-title Body: Convoy: hq-cv-abc Rebuild auth system Progress: 23/35 closed (65%) Stalled for: 15 minutes Skipped issues (polecat failure): gt-xyz Migrate session store (failed 3 times) gt-abc Update JWT validation (failed 3 times) Blocked issues (DAG): gt-def Integration tests (blocked by gt-xyz) gt-ghi E2E tests (blocked by gt-def) Active polecats: 0 Ready issues: 0 Action needed: Review skipped issues. Possible fixes: bd update gt-xyz --statusopen --remove-label mountain:skipped (retry) bd close gt-xyz --reasonDescoped (skip permanently, unblocks dependents)完成通知Subject: Mountain complete: convoy-title Body: Convoy: hq-cv-abc Rebuild auth system Result: 33/35 closed, 2 skipped Elapsed: 3h 42m Skipped issues: gt-xyz Migrate session store (failed 3 times — needs manual review) gt-abc Update JWT validation (failed 3 times — needs manual review)Mayor 的角色Mayor不是研磨循环的一部分。它接收通知并可以采取行动但 mountain 在无 Mayor 介入的情况下自主研磨。Mayor 的行动包括重试被跳过 issuebd update id --statusopen --remove-label mountain:skipped永久跳过bd close id --reasonDescoped解除依赖项的阻塞通知用户转发停滞/完成通知重构 DAG移除或添加依赖绕过阻塞点。8. 用户体验启动一座 Mountain$ gt mountain gt-epic-auth-rebuild Validating epic structure... Epic: gt-epic-auth-rebuild Rebuild auth system Tasks: 35 (31 slingable, 4 epics) Waves: 6 (computed from blocking deps) Max parallelism: 4 Warnings: gt-migrate-sessions has no description (may cause polecat confusion) Errors: none Creating convoy... Convoy: hq-cv-m7x Mountain: Rebuild auth system Label: mountain Launching Wave 1 (4 tasks)... Slung gt-foundation-types → gastown Slung gt-config-schema → gastown Slung gt-test-fixtures → gastown Slung gt-error-types → gastown Mountain active. ConvoyManager will feed subsequent waves. Deacon will audit progress every ~10 minutes. Check status: gt mountain status hq-cv-m7x对照源码这段输出的每个数字都来自真实计算Tasks/Waves/Max parallelism分别由len(dag.Nodes)、len(waves)与最大波次大小给出无描述等 warning 来自detectWarnings的 findings存在 warning 且未带--force时会拒绝启动convoyStatusStagedWarnings分支见 mountain.go。查看状态$ gt mountain status Active Mountains: hq-cv-m7x Rebuild auth system Progress: ████████████░░░░░░░░ 23/35 (65%) Active: 3 polecats working Ready: 1 issue waiting for polecat Blocked: 6 issues (DAG deps) Skipped: 2 issues (polecat failures) Elapsed: 1h 47m hq-cv-n9y Migrate database layer Progress: ██████████████████░░ 18/20 (90%) Active: 2 polecats working Elapsed: 52m源码中showAllMountainStatus遍历所有带mountain标签的 open convoy用renderProgressBar渲染 20 格 Unicode 进度条█/░并支持--json输出mountain.go。详细状态$ gt mountain status hq-cv-m7x Mountain: hq-cv-m7x Rebuild auth system Epic: gt-epic-auth-rebuild Progress: 23/35 closed (65%) Elapsed: 1h 47m Wave: 4 of 6 Completed (23): ✓ gt-foundation-types, gt-config-schema, gt-test-fixtures, ... Active (3): ⟳ gt-session-handler (polecat: gastown/nux, 12m) ⟳ gt-middleware-chain (polecat: gastown/furiosa, 8m) ⟳ gt-rate-limiter (polecat: gastown/max, 3m) Ready (1): ○ gt-cache-layer (unblocked, waiting for polecat) Skipped (2): ⊘ gt-migrate-sessions (failed 3 times — no description) ⊘ gt-jwt-validation (failed 3 times — test dependency missing) Blocked (6): ◌ gt-auth-integration (needs: gt-session-handler, gt-jwt-validation⊘) ◌ gt-e2e-auth-tests (needs: gt-auth-integration) ... Stall risk: gt-jwt-validation⊘ blocks 4 downstream issues. Fix: bd update gt-jwt-validation --statusopen --remove-label mountain:skipped Or: bd close gt-jwt-validation --reasonDescopedshowMountainDetail在源码中实现了完整分类逻辑closed→ completed、in_progress/hooked→ active、带mountain:skipped标签 → skipped其余按 DAG 中是否有未关闭 blocker 分为 blocked / readymountain.go。9. 全局改进惠及所有 ConvoysMountain-Eater 的设计揭示了不只惠及 mountain、而是惠及所有 convoy的改进点应当全局应用9.1 Polecat 失败跟踪即使非 mountain convoy 也受益于这个 issue 已失败 3 次的信息。Witness 应当跟踪所有convoy-tracked issue 的失败次数而不仅是 mountain 的。区别在于mountain 在 3 次失败后自动跳过普通 convoy 只记录警告。这一差异化逻辑已在TrackConvoyFailure中实现——普通 convoy 返回Warning: polecat failure on convoy-tracked issue ...mountain.go。9.2 滞留扫描中的停滞检测ConvoyManager 的滞留扫描目前只喂入第一个就绪 issue。增强如果同一 issue 已被 sling 3 次以上且不断以滞留状态出现停止重新 sling 并记录警告。这能防止所有 convoy 的无限 sling-失败循环。9.3 进度可见性gt convoy status应展示与gt mountain status同样丰富的信息——活跃 polecat、就绪前沿、阻塞 issue、跳过 issue。这对所有 convoy 都有用。10. 与 Swarm 架构的关系设计文档引用了一份 swarm 架构设计swarm 是持久化 molecule、由专职 Agent 协调。Mountain-Eater 通过不同机制达成同样结果Swarm 架构Mountain-Eater专职协调者 Agent无协调者——巡逻步骤 DogsSwarm molecule 追踪状态标签触发巡逻行为协调者通过 molecule 存活Dogs 带来全新上下文无需存活Ready Front 由协调者计算Ready Front 由 ConvoyManager Dogs 计算通过 molecule 恢复通过 beads 状态发现恢复Mountain-Eater 是 swarm 架构目标的实现路径swarm 文档中的ready front模型、gate issues、batch management概念直接适用区别在于机制——巡逻驱动研磨patrol-driven grinding而非协调者驱动研磨coordinator-driven grinding。说明设计文档中的 swarm 架构链接指向docs/swarm-architecture.md在当前仓库目录树中该文件未出现属于悬空链接读者应以本设计文档 convoy 规范 为准理解其概念关系。11. 实现计划与当前落地状态按 roadmap.md 的 Milestone 5Mountain-Eater依赖 Milestone 2 的 stage-launch 管线变更清单如下组件变更规模仓库落地状态gt mountainCLI新命令stage label launch~200 行✅ 已实现internal/cmd/mountain.gogt mountain status新命令查询 格式化~300 行✅ 已实现含--jsongt mountain pause/resume/cancel标签管理~100 行✅ 已实现mountain:paused标签Witness 巡逻公式convoy issue 失败跟踪公式步骤✅ 已实现internal/witness/mountain.goDeacon 巡逻公式Mountain 审计步骤公式步骤⏳ 设计中无源码mol-mountain-dog.formula.toml停滞调查的 Dog 公式新公式⏳ 设计中internal/formula下未找到ConvoyManager 滞留扫描N 次失败后跳过全局~30 行⏳ 待实现gt convoy status增强输出active/ready/blocked~100 行⏳ 待实现什么不会改变What Does NOT ChangeConvoy 数据模型仍是hq-cv-*beads 带tracks依赖ConvoyManager 事件轮询仍 5 秒、仍在关闭时喂给ConvoyManager 滞留扫描仍 30 秒、增强跳过逻辑Stage-launch 工作流mountain 直接使用它Polecat 生命周期不变Refinery不变。Layer 0 的既有事实基础Layer 0 的机械行为已由 convoy 规范 固化并通过测试验证是 Mountain-Eater 的承载基础值得单独强调事件轮询 goroutineGetAllEventsSince每 5 秒轮询所有 rig 存储 hq检测EventClosed/EventStatusChanged(closed)调用共享观察函数convoy.CheckConvoysForIssue滞留扫描 goroutine每 30 秒调用gt convoy stranded --json对有就绪工作的 convoy 通过gt sling id rig --no-boot喂入第一个就绪 issue对空 convoy 调用gt convoy check自动关闭关键设计决策SDK 轮询而非 CLI 流式简化重启语义高水位标记atomic int64单调推进防重复处理每次扫描每个 convoy 只喂一个 issue防批量溢出滞留扫描作为安全网崩溃恢复beads 存储为 nil 时仅禁用事件轮询滞留扫描在降级模式下仍工作。12. 开放问题gt mountain是否应自动取消 docked rig如果史诗的 issue 路由到 docked rigmountain 是否应自动将其 undock当前倾向否——要求 rig 处于活跃状态。Mountain 只研磨活跃 rig。每座山最大并发 polecat 数。Mountain 是否应有可配置的并发上限ConvoyManager 在每个关闭事件时喂一个 issue。对 mountain波次切换时可能希望一次派发多个就绪 issue例如 wave 1 完成、wave 2 有 8 个就绪 issue——一次派发全部 8 个而非逐个。山与山之间的依赖。一座山能否依赖另一座初始可能不需要——跨山依赖本质上就是 DAG 中的跨 issue 依赖。通知渠道。Mayor 邮件是当前通知路径。Mountain 是否也应支持 webhook/Slack 通知用户留待未来工作。13. 进一步阅读源码与文档导览核心实现已落地internal/cmd/mountain.gogt mountain命令族完整实现activate / status / pause / resume / cancel含--force与--jsoninternal/witness/mountain.goLayer 1 失败跟踪MountainMaxFailures 3、mountain:failures:N计数、mountain:skipped自动跳过internal/witness/mountain_test.go失败计数解析、标签匹配等单元测试。设计文档骨架与规范mountain-eater.md本文主体设计文档问题陈述、四层架构、标签语义、各层细节、UX、开放问题roadmap.mdMilestone 0-5 分阶段路线图Milestone 5 即 Mountain-Eater 的落地计划spec.mdConvoyManager 规范Layer 0 的事件轮询、滞留扫描、共享观察函数、不变量与测试矩阵。需要强调的是本文所述 Mountain-Eater 是一套机械层已就绪、判断层逐步落地的设计Layer 0ConvoyManager与 Layer 1Witness 失败跟踪已在源码中可用gt mountain命令可直接上手Layer 2Deacon 审计与 Layer 3Mayor 升级仍是设计蓝图其价值在于定义了无协调者、以 beads 为状态、以标签触发行为的自主研磨范式——这正是大型史诗从卡在 40%走向去吃午饭回来就完成了的关键路径。【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考