企业官网建设流程全解析

Gas Town Gate Bead 指令模板解析：基于mol-decompose-with-gates的自动化验证门机制

【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown

Gate bead 是 Gas Town 多 Agent 工作区（multi-agent workspace manager）中负责"验收"的验证型工作项：当一个 plan/epic 下的所有实现任务完成之后，一个独立的 gate polecat（验收 Agent）会依据模板生成的门指令对实现结果逐条执行审查，发现问题则走修复循环，全部通过则关闭门并通知人类复核。本文将逐段解读 gate-bead-instructions.md 这份模板的完整内容，包括占位符系统、Review Steps 渲染机制、Retry Loop Protocol 与 Clean Pass Signal，并结合仓库中 formula 嵌入机制、Deacon 巡逻的 gate-evaluation 步骤与 Witness 的 timer gate 检查，说明这条验证链路的底层工作原理。

一、模板的定位：一份被 formula 消费的"门说明书"

gate-bead-instructions.md的第一段就写明了它的角色：

This file defines the prose template embedded in every gate bead's description. Themol-decompose-with-gatesformula reads this template, populates the placeholders, and passes it as the--descriptiontobd create.

也就是说，这份 Markdown 并非给人直接阅读的手册，而是一份被程序化消费的模板资产。核心链路为：

1. mol-decompose-with-gatesformula 在将 plan 拆解为任务时，额外创建一枚 gate bead；
2. formula 运行时读取本模板，把占位符替换为真实的 plan 信息与审查步骤；
3. 渲染完成的文本通过bd create --description写入 gate bead 的描述字段；
4. 之后被调度的 gate polecat 读取描述，即可获得全部审查指令，无需依赖任何外部记忆。

这一点与整个仓库"模板驱动 Agent"的设计一致：internal/formula/embed.go中通过//go:embed formulas/*.formula.toml将所有 formula 嵌入二进制，安装时由ProvisionFormulas下发到工作区的.beads/formulas/目录，运行期再按 "rig > town > embedded" 三级优先级解析（见 internal/formula/embed.go 中ResolveFormulaContent的实现注释）。mol-decompose-with-gates本身也应落在该目录中，模板文件与 formula 同仓存放，保证消费方与模板版本永远一致。

二、占位符系统：运行时如何填充模板

模板依赖五个占位符，文档给出了它们的来源与含义：

从占位符来源可以看出分工：plan 的标识信息（标题、ID）由 formula 运行时注入，审查步骤内容由.gates.toml配置解析而来，而{{gate_id}}是创建后回填的"身份"——修复循环中所有 fix bead 都要以它为锚点挂依赖。这种设计让模板与具体 plan 完全解耦：同一份模板可以服务任意数量的 plan，每次创建时只是一次字符串替换。

三、Context 段：gate polecat 的职责声明

---分隔线之后是模板字面正文，其中## Context段先给 gate polecat 立规矩：

• 这是对 plan{{plan_title}}（{{plan_bead}}）的一次验证门；
• gate polecat对实现没有任何记忆——所需的一切都在描述文本与当前分支代码里，这保证了"无状态验收"，任何一台空闲 rig 都能接手；
• 门被该 plan 下的所有实现任务阻塞，接到门即代表实现全部完成；
• 依次执行每条审查步骤：全部通过则关闭门（信号：plan 就绪）；任一步骤发现问题则进入底部协议的重试循环。

**Configured review steps:** {{step_names}}这一行让 Agent 一上来就清楚本次要执行哪些检查，避免遗漏。

四、Review Steps：审查步骤如何被渲染

{{review_steps}}是整份模板里信息量最大的占位符。模板内嵌的注释揭示了渲染规则：

<!-- Each review step is rendered from .gates.toml as: ### <step.name> <step.description> **Instructions:** <step.instructions> -->

即.gates.toml中的每个审查步骤都会被渲染为一个标准小节，包含：

• ### <step.name>—— 步骤标题（三级标题）；
• <step.description>—— 该步骤要检查什么；
• **Instructions:**—— 具体怎么检查的指令。

这意味着审查步骤本身是配置化的：想增加一道检查（例如"验证测试覆盖率达到阈值"），只需在.gates.toml中新增一个 step，而无需改动模板文件。渲染后的多个小节拼接进{{review_steps}}，最终形成门描述中的## Review Steps区块。{{step_names}}则是同名配置项的摘要列表，供 Context 段与关闭前核对使用。

五、Retry Loop Protocol：发现问题时的修复循环

模板的## Retry Loop Protocol段定义了"发现问题 → 派发修复 → 重新审查"的完整闭环，共四步：

1. 为每个问题各建一个 fix bead：

bd create "Fix: <concise issue description>" \ --type=task \ --description="## Context Found during gate review of {{plan_title}} ({{plan_bead}}). Gate bead: {{gate_id}} Review step: <which step found this> ## Issue <detailed description of what's wrong> ## Location <file paths, line numbers, function names> ## Expected Fix <what the fix should accomplish> ## Acceptance Criteria - <how to verify the fix is correct>"

模板刻意要求 fix bead 的描述自带Context / Issue / Location / Expected Fix / Acceptance Criteria五段结构，目的是让修复 polecat无需与 gate polecat 对话即可精确执行——位置写文件路径、行号、函数名，验收标准写可验证的判定方式。

2. 将每个 fix bead 挂为本门的阻塞依赖：

bd dep add {{gate_id}} <fix-bead-id>

这使门重新进入 blocked 状态，直到所有修复 bead 关闭。

3. 将修复派发给可用的 polecat：

gt sling <fix-bead-id> <rig>

gt sling是 Gas Town 向指定 rig 派发工作项的调度命令，修复任务由此进入队列。

4. 退出，绝不等待修复：

门 polecat 清空分配并结束会话，剩余流程由系统接管：

• 各修复 polecat 独立工作；
• 修复 bead 逐个关闭，其对门的阻塞依赖逐条满足；
• 全部修复关闭后，门重新解除阻塞；
• stranded-bead 扫描在解除阻塞后30 秒内将门重新派发给一个新 gate polecat；
• 新 polecat 从头重跑全部审查步骤。

模板特别强调了一条纪律：gate polecat 的职责是审查而非实现，禁止自己动手修问题，只负责产出无歧义的 fix bead。这个"审查与实现分离"的约束保证了修复工作的可并行性与质量可控。

六、Clean Pass Signal：全绿时的收尾

当所有步骤都干净通过时，gate polecat 执行：

bd close {{gate_id}} --reason="Gate passed: all review steps clean"

关闭门即向系统广播"该 plan 的实现已通过验证，可交人工复核"。关闭前模板要求核查三点：

• 是否执行了每一个已配置的审查步骤（{{step_names}}）；
• 是否没有任何步骤发现问题；
• 是否没有因困惑或失误跳过某一步。

模板还给出了一个实用容错原则：拿不准算不算问题时，宁可多建一个 fix bead——误报造成的浪费远小于漏掉缺陷。这个默认偏向谨慎的取向，与整个仓库强调的验证文化一致：文档中gate-evaluation巡逻步骤（见下节）也遵循"宁可记录、不可放过"的判定风格。

七、源码印证：gate 机制在系统层的实现

模板描述的是"Agent 如何行为"，而系统层的 gate 协调机制散落在仓库的多个实现中：

1. gate 是一种异步协调原语

internal/constants/constants.go 中的注释把 bead 类别里的gate定义为 "Async coordination (bd gate wait, park/resume)"，说明 gate bead 是支持等待/唤醒语义的异步同步点——这正是"实现任务阻塞门、修复关闭解除阻塞"的底层能力。

2. Deacon 巡逻中的 gate-evaluation 与门派发

mol-deacon-patrol.formula.toml 是市长后台 Deacon 的巡逻配方，其中gate-evaluation步骤专门处理"挂起中的异步门"：

• Timer gates（await_type: timer）：用bd gate list --json列出所有打开的门，检查CreatedAt + Timeout < Now是否到期，到期则bd gate close <id> --reason "Timer elapsed"；
• GitHub gates（await_type: gh:run, gh:pr）由独立步骤处理；
• Human/Mail gates需要外部输入，巡逻跳过；
• 门关闭后，会向 Waiters 字段中的邮箱地址发送通知。

紧随其后的dispatch-gated-molecules步骤则完成异步恢复闭环：用bd ready --gated --json找出"阻塞在已关闭门上的 in_progress molecule"，再用gt sling派发到对应 rig 的 polecat 池。可见"门阻塞 → 条件满足 → 门关闭 → 重新派发"这一模式在 molecule 调度层同样成立，与 gate bead 的阻塞依赖语义互为印证。

3. Witness 的 timer gate 超时巡检

mol-witness-patrol.formula.toml 中 Witness 巡逻会运行bd gate check --type=timer --escalate：找出所有await_type=timer且已过created_at + timeout的打开门，以 HIGH 严重级别升级给监督者，防止定时门因无人值守而永久悬挂。

4. formula 模板的托管与下发

如前所述，internal/formula/embed.go 中的go:embed、ProvisionFormulas、UpdateFormulas与CheckFormulaHealth构成了 formula（含本模板所在目录）的生命周期管理：用户可修改.beads/formulas/下的副本做定制，系统通过 SHA-256 记录区分 "outdated / modified / missing"，升级时跳过用户改动过的文件。这意味着mol-decompose-with-gates与gate-bead-instructions.md都可以被团队按需定制后继续消费。

八、实战观察建议

把模板与系统行为串起来，可以形成一套可操作的验证链路检查清单：

1. 创建侧：确认 plan 拆解时mol-decompose-with-gates被触发，生成的 gate bead 描述中包含五个占位符均已正确替换（{{gate_id}}应为实际 ID 而非字面量）；
2. 配置侧：审查步骤清单维护在.gates.toml中，新增/调整检查无需改模板；渲染后每个步骤应呈现### 名称 + 描述 + Instructions三段结构；
3. 执行侧：gate polecat 只做审查，问题一律以结构化的 fix bead 形式产出，并bd dep add挂到门上、gt sling派发；
4. 恢复侧：修复完成后门会在约 30 秒内被 stranded-bead 扫描重新派发并重跑全量步骤；
5. 系统侧：可用bd gate list --json观察门状态，Deacon 巡逻的gate-evaluation与 Witness 的bd gate check --type=timer --escalate分别兜底了定时门与悬挂门。

这套"模板描述 Agent 行为 + 配置驱动步骤清单 + 系统级原语兜底"的组合，让大规模多 Agent 协作下的验收环节既无状态、可审计，又能在出现缺陷时自动进入修复-重审闭环，是理解 Gas Town 如何保证产出质量的一条关键路径。

【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown