gstack × OpenClaw：为 AGENTS.md 编写调度路由，让 Telegram 里的 Agent 替你派发 Claude Code 会话

本文围绕 openclaw/agents-gstack-section.md 这一"即插即用"的 AGENTS.md 配置片段展开：它定义了 OpenClaw 编排器（orchestrator）在接到编码任务后，如何用 sessions_spawn 启动 Claude Code 会话、如何按任务复杂度选择 SIMPLE / MEDIUM / HEAVY / FULL / PLAN 五档调度层级（dispatch tier），以及三条不可妥协的行为规则。读完后，你将掌握如何在自己的 OpenClaw 实例中配置这套调度路由，理解每档注入的 prompt 前缀（gstack-lite / gstack-full / gstack-plan 模板）各自做了什么，以及 gstack 侧如何通过 OPENCLAW_SESSION 环境变量识别被编排器派生的会话并自动切换为非交互模式。

一、这段配置是什么：OpenClaw 与 gstack 的"提示词桥梁"

openclaw/agents-gstack-section.md 是 gstack 仓库为 OpenClaw 集成提供的一份可直接粘贴进 OpenClaw AGENTS.md 的调度配置片段。它本身不是一段可执行代码，而是一份"行为契约"：告诉 OpenClaw 的主 Agent 在用户提出编码需求时该如何决策、如何派生（spawn）Claude Code 会话、如何把结果带回来。

docs/OPENCLAW.md 对集成的定位非常明确：gstack 是以"方法论来源"（methodology source）而非"移植代码库"的身份接入 OpenClaw 的。OpenClaw 的 ACP runtime 原生负责派生 Claude Code 会话，gstack 则提供让会话产出更好的规划纪律与方法论。整个集成被刻意设计成一种轻量协议——"没有守护进程、没有 JSON-RPC、没有兼容矩阵，提示词就是桥"（No daemon. No JSON-RPC. The prompt is the bridge）。

agents-gstack-section.md 正是这座桥中"调度端"的那一半。它的三个组成部分是：

1. Rules (non-negotiable) —— 三条不可妥协的行为规则，位于调度层级之上；
2. Dispatch Routing —— 五档调度层级及其对应的 sessions_spawn prompt 构造方式；
3. Decision Heuristic —— 用几条可判定的启发式规则帮助 Agent 选档。

从仓库结构看，这份片段与 openclaw/ 目录下的三个 CLAUDE.md 模板（gstack-lite / gstack-full / gstack-plan）构成一组：片段决定"注入哪个模板、以什么措辞发起会话"，模板决定"会话内部如何执行"。

二、三条不可妥协规则（Rules, non-negotiable）

原文档把这三条规则置于调度层级之前（OPENCLAW.md 中明确写道："these go ABOVE the dispatch tiers"），因为它们约束的是编排器自身的交互姿态，与任务大小无关：

2.1 Always spawn, never redirect（永远派生，永不转介）

当用户要求使用任何 gstack skill 时，必须通过 sessions_spawn 派生一个 Claude Code 会话。永远不要告诉用户"自己打开 Claude Code"，永远不要说"这需要跑在 Claude Code 里"。直接去做。

这条规则的设计动机在 docs/OPENCLAW.md 的架构图中可以看到：OpenClaw 侧承担"messaging、calendar、memory、EA（Executive Assistant）"职责，典型入口是 Telegram 等聊天渠道。用户体验目标被写成了一条独立的规则——"User should never have to leave Telegram"（用户永远不需要离开 Telegram）。换句话说，OpenClaw 主 Agent 是用户的唯一界面，Claude Code 只是它背后的执行引擎，用户感知不到"另一个工具"的存在。

2.2 Resolve the repo（先解析目标仓库）

如果用户指名了某个仓库或项目，就把工作目录设为该仓库路径。如果不知道仓库路径，就问用户是哪个仓库——而不是把问题推回"你去打开 Claude Code 处理"。

这条规则把"确定工作目录"的职责留在了编排器侧。它和第一条规则形成闭环：编排器负责选仓库、派生会话；会话在正确的 cwd 下运行 gstack，避免 Agent 在错误的目录里执行 skill。

2.3 Autoplan runs end-to-end（Autoplan 端到端跑完）

对 /autoplan 这类任务：派生会话后让它完整跑完评审流水线（CEO → design → eng），跑完后把计划带回聊天里汇报，并把计划写入 memory 供用户日后检索。

这里对应的是 gstack 的 autoplan skill。它的 sections/ 目录下按角色拆分了评审阶段模板：ceo-phase、design-phase、eng-phase，以及 manifest.json 描述的聚合顺序。端到端跑完意味着编排器不能在中间任何环节把"请确认"抛回给用户，而是等 Claude Code 会话自行完成整条流水线后再一次性汇报。

三、五档调度路由（Dispatch Routing）

这是整个配置片段的核心。当用户提出编码工作时，编排器必须选一个调度层级，每一档对应一种固定的 sessions_spawn 调用形态：

3.1 SIMPLE：单文件小改动

触发场景："fix this typo"、"update that config"、单文件修改
调用方式：sessions_spawn(runtime: "acp", prompt: "<just the task>")

即：不注入任何 gstack 上下文，把任务原样发给 Claude Code。这对应 docs/OPENCLAW.md 表格中的说明——Simple 档"No gstack context injected"。

3.2 MEDIUM：多文件但思路明确

触发场景：多文件功能、重构、skill 编辑
调用方式：sessions_spawn(runtime: "acp", prompt: "<gstack-lite content>\n\n<task>")

<gstack-lite content> 指 openclaw/gstack-lite-CLAUDE.md 的全文（源模板在 openclaw/templates/gstack-lite-CLAUDE.md）。这份模板只有十几行，内容是一套规划纪律：

1. 修改前先读完每个要改的文件，理解既有模式；
2. 写代码前先陈述计划：做什么、为什么、改哪些文件、测试用例、风险；
3. 遇到歧义时的偏好序：完整性优先于捷径、既有模式优先于新模式、可逆选择优先于不可逆、安全默认值优先于炫技方案；
4. 汇报完成前自审：漏改的文件、坏掉的 import、未测的路径、风格不一致；
5. 完成汇报：交付了什么、做了哪些决策、有什么不确定。

OPENCLAW.md 提到这套纪律经过 A/B 测试："2x time, meaningfully better output"——耗时约为原生的两倍，但产出质量显著提升。这是一个典型的"用时间换确定性"的权衡，由编排器在 MEDIUM 档自动启用。

3.3 HEAVY：点名某个 gstack 方法论

触发场景：需要特定 gstack 方法论
调用方式：sessions_spawn(runtime: "acp", prompt: "Load gstack. Run /qa https://...")

原文档列出了适用此档的 skill 清单：/cso、/review、/qa、/ship、/investigate、/design-review、/benchmark、/gstack-upgrade。prompt 的形态很特别：不注入任何 CLAUDE.md 模板，只用一句话"Load gstack. Run /X"，让会话内的 gstack（安装在 ~/.claude/skills/gstack）自己加载方法论。这些 skill 对应仓库中各自的目录，如 review/SKILL.md、qa/SKILL.md、ship/SKILL.md、investigate/SKILL.md。

3.4 FULL：完整功能交付

触发场景：构建完整功能、跨多天的范围、需要规划 + 评审
调用方式：sessions_spawn(runtime: "acp", prompt: "<gstack-full content>\n\n<task>")

<gstack-full content> 是 openclaw/gstack-full-CLAUDE.md（模板源 openclaw/templates/gstack-full-CLAUDE.md），它把既有 gstack skill 串成一条完整流水线：

1. 读 CLAUDE.md，理解项目上下文；
2. 跑 /autoplan 评审方案（CEO + eng + design 评审流水线）;
3. 按已批准的计划实现，遵循规划纪律；
4. 跑 /ship 创建带测试、changelog、版本号 bump 的 PR；
5. 汇报：PR URL、交付内容、所做决策、不确定项。

模板末尾还有一条强约束："Do not ask for human input until the PR is ready for review"——在 PR 就绪之前不得向人求助，这保证了派生会话是自洽跑完的。

3.5 PLAN：只规划，不实现

触发场景：用户想为 Claude Code 项目做规划、给功能写 spec、或在写代码前先设计方案
调用方式：sessions_spawn(runtime: "acp", prompt: "<gstack-plan content>\n\n<task>")

<gstack-plan content> 是 openclaw/gstack-plan-CLAUDE.md（模板源 openclaw/templates/gstack-plan-CLAUDE.md），定义了一条"完整评审关卡"（Full Review Gauntlet）：

1. 读 CLAUDE.md 理解项目上下文；
2. 跑 /office-hours 产出设计文档（问题陈述、前提假设、备选方案）；
3. 跑 /autoplan 评审设计（CEO + eng + design + DX 评审 + codex 对抗式评审）；
4. 把最终评审过的计划存到当前仓库的 plans/<project-slug>-plan-<date>.md，内容包含设计文档、所有评审决策、实现顺序；
5. 向编排器汇报：计划文件路径、一段话的设计摘要与关键决策、已接受的 scope 扩张清单、建议的下一步（通常是用 gstack-full 派生新会话去实现）。

模板同样明确"Do not implement anything. This is planning only"。

原文档对 PLAN 档还给出了跨会话闭环要求：编排器要把计划链接持久化到 memory / knowledge store；等用户准备好实现时，再派生一个新的 FULL 会话并指向该计划文件。也就是说，PLAN 与 FULL 是"先存后取"的两段式协作，由编排器的 memory 衔接。

3.6 CLAUDE.md 冲突处理：追加而非替换

虽然 agents-gstack-section.md 片段本身没有展开，但 docs/OPENCLAW.md 补充了一条实现 MEDIUM / FULL / PLAN 档时必须遵守的落地细节：当派生会话的仓库已经有 CLAUDE.md 时，gstack-lite/full 模板必须**追加（APPEND）**为一个新的 section，绝不能替换仓库既有的指令。三个模板文件的头部注释也都写明了这一点（"Append to existing CLAUDE.md"）。

四、决策启发式（Decision Heuristic）

选档依赖六条可判定的启发式，原文档逐条给出：

启发式	档位
改动少于 10 行代码？	SIMPLE
涉及多个文件但方案显而易见？	MEDIUM
用户点名了某个具体 skill（/cso、/review、/qa）？	HEAVY
"Upgrade gstack" / "update gstack"？	HEAVY，且 prompt 为 Run /gstack-upgrade
是 feature / project / objective（而非 task）？	FULL
用户想规划但先不实现？	PLAN

值得注意第 4 条：把"升级 gstack"这类运维操作也归入 HEAVY 档并固定为 Run /gstack-upgrade，与仓库中的 gstack-upgrade/SKILL.md（含 migrations/ 目录下的版本迁移脚本）对应。

启发式的判断维度可以归纳为三个正交问题：改动规模（<10 行 / 多文件）、方法论需求（是否点名 skill）、任务性质（task 还是 objective、是否只规划）。这种"规则表 + 明确 prompt 模板"的写法，正是让 LLM 编排器能够稳定、可复现地选档的关键——没有模糊地带，每条输入都能落到某一档。

五、实现佐证：模板生成与会话识别

配置片段之所以能稳定工作，依赖 gstack 仓库侧的两处机制支撑：

5.1 模板的生成管线

openclaw/ 目录下直接可见的三份 CLAUDE.md（gstack-lite / gstack-full / gstack-plan）是生成产物，真正的源文件在 openclaw/templates/ 下。scripts/gen-skill-docs.ts 中的生成逻辑（约 L1064–L1074）：当 --host openclaw 时，把 templates/ 中对应文件复制/生成到 openclaw/ 顶层并打印 GENERATED: openclaw/<fileName>。docs/OPENCLAW.md 也确认了这一点："All artifacts live in the openclaw/ directory and are generated by bun run gen:skill-docs --host openclaw"。开发 gstack 时可通过 ./setup --host openclaw 输出集成文档、通过上述 bun 命令重新生成产物（仓库为只读时只需查看）。

5.2 派生会话的识别：OPENCLAW_SESSION 环境变量

Coding Tasks (gstack) 片段本身不设置环境变量，但 OPENCLAW.md 给出了配套约定：在 sessions_spawn 中通过 env: { OPENCLAW_SESSION: "1" } 标记派生会话。gstack 侧的检测入口在 bin/gstack-session-kind：脚本第 11 行注释标明 spawned → orchestrator session (OpenClaw). Auto-choose recommended option，第 27 行以 if [ -n "${OPENCLAW_SESSION:-}" ] 作为判据。一旦识别为编排器派生会话，gstack 的行为调整为：跳过交互提问（自动选择推荐选项）、跳过升级检查与遥测提示、聚焦任务完成与文字汇报——这与片段中"Autoplan 端到端跑完、结果带回聊天"的要求正好呼应：正是因为会话不会中途弹出交互问题，编排器才可以放心地"spawn 后等它跑完"。

六、如何在自己的 OpenClaw 中使用

按照 docs/OPENCLAW.md 的安装说明，使用流程如下：

1. 对 OpenClaw 用户：直接对 OpenClaw agent 说 "install gstack for openclaw"。Agent 应完成四步：把 gstack-lite CLAUDE.md 装入编码会话模板、安装 4 个原生方法论 skill（gstack-openclaw-office-hours、gstack-openclaw-ceo-review、gstack-openclaw-investigate、gstack-openclaw-retro，源码见 openclaw/skills/）、把调度路由加入 AGENTS.md、用一个测试 spawn 验证。
2. 手动配置的最小动作：把 openclaw/agents-gstack-section.md 的全文复制进你的 OpenClaw AGENTS.md（OPENCLAW.md 原文："Copy it into your OpenClaw AGENTS.md"），并确保 Claude Code 环境中已安装 gstack（安装位置 ~/.claude/skills/gstack）。
3. 对 gstack 开发者：./setup --host openclaw 输出集成文档；产物本身由 bun run gen:skill-docs --host openclaw 生成。

一个符合该配置的派生调用示例（HEAVY 档）：

sessions_spawn(
  runtime: "acp",
  cwd: "<目标仓库路径>",
  env: { OPENCLAW_SESSION: "1" },
  prompt: "Load gstack. Run /qa https://example.com"
)

会话跑完后，编排器按片段要求把结果汇报回聊天渠道（对 FULL 档则是 PR URL + 决策摘要，对 PLAN 档则是计划文件路径 + 摘要 + 建议下一步）。

七、边界：这套集成"不做什么"

OPENCLAW.md 用一节"What we don't do"划清了方案的边界，理解这些否定项有助于正确预期这套配置的能力范围：

• 无调度守护进程——会话派生由 ACP 处理；
• 无 Clawvisor 中继——不需要额外的安全层；
• 无双向 learnings 桥——brain repo 就是知识存储；
• 无 JSON schema 与协议版本化——协议即提示词文本；
• 不向 OpenClaw 输出 SOUL.md（OpenClaw 有自己的）；
• 不做完整 skill 移植——编码类 skill 保持 Claude Code 原生。

agents-gstack-section.md 正是这种"提示词即协议"哲学的具体体现：它没有依赖任何运行时 API 或外部服务，仅凭一段结构化 Markdown 规则，就让通用编排 Agent 学会按五档路由把编码任务正确地交给 gstack 的 Claude Code 会话，并在用户始终停留在聊天渠道的前提下完成从派生、执行到汇报的闭环。