Best Minds Board · Private-style single page · smoke token smoke-20260315-230700 · verified at 2026-03-15 23:11
deploy 群默认 /topic 调研部署链路，已经稳定命中 topic-deploy 了吗？
结论先行：这次已经用真实 Feishu 消息证实 deploy 群默认 /topic 会分发到 topic-deploy，不再落到旧的 web-ship 默认人格；2026 年 3 月 15 日 23:11 的 live 消息已在 gateway 日志中命中 agent:topic-deploy。之前会混入 web-ship，本质上是因为同一类“收到消息就部署”的旧 agent 约束仍残留、且 topic 路由边界不够强，导致非命令型或错误命中的消息被 web-ship 接管。现在把入口收紧成 /topic → topic-deploy 专属调研部署、/links|/status → 只查状态不重建、非命令消息默认静默，就是在切断这种串流。
Project · 7_AGENT/openclaw/topic-deploy
Category · workflow
Tags · deploy · topic-routing · e2e · vercel · feishu · board
1核心问题：默认 /topic 是否命中正确 agent
2主要链路：topic-deploy 与历史 web-ship 分流
10+多样 SVG 模块，覆盖链路、风险、验证、决策
200只有线上 GET 200 且 metadata 验证通过，才算成功回执
问题定义
你要验证的不是“能不能生成一个网页”，而是 deploy 群默认 /topic 请求能否稳定走到 topic-deploy 的调研型部署工作流：生成 private 风格单页、带完整研究结构、至少 8 个多样化 SVG，并且 只有链接验证可访问后才回成功。
- 输入：Feishu deploy 群里的
/topic ... 请求。
- 处理：topic 归一化、避免散 topic、生成 site/index.html、调用 ship-prod-detached。
- 产出：版本化快照、rolling latest、history、canonical URL、状态 metadata。
- 验收：metadata.status=success 且 verification.ok=true。
谁最懂这个问题
不是“页面能不能发出去”，而是“消息到底被谁接住、谁对回执负责”。
视角 1 · Routing / Agent Boundary 设计者
最关心入口条件是否互斥：/help、/links、/status、/topic、active topic thread 更新、非命令静默，是否清晰分流。
视角 2 · 部署可靠性 owner
最关心“回成功”是否晚于真实可访问性验证，而不是脚本开始跑就先报喜。
视角 3 · 事故复盘负责人
最关心为什么旧的 web-ship 还会混入：系统残余默认人格、topic 缺省策略、fallback 逻辑、历史 last_topic 污染、以及错误的“任何消息都部署”规则。
SVG 1 · 命令入口决策树
把命令入口做成互斥分流，是切断 web-ship 混入的第一步。
SVG 2 · 历史污染路径
web-ship 的“任何消息→部署”人格，天然容易与 topic-based 调度冲突。
SVG 3 · E2E 验证泳道图
关键验收点不在“开始部署”，而在“链接验证可访问后才允许回复成功”。
关键洞察
洞察 A · 这不是普通网页生成任务
用户明确要求的是“调研部署链路验证 + 原因解释 + private-style 报告交付”，所以默认应该走 best-minds-board 风格的调研页，而不是 web-ship 的通用 landing/壳页。
洞察 B · 真正的故障点常在入口边界
如果 agent 仍继承“any message → deploy”的旧约束，那么 /topic 再精细，也会被更上层的泛化规则打断或抢答。
洞察 C · 状态查询必须与生成解耦
/links 与 /status 只报状态、不重建页面，是减少误部署和错误归因的关键。
洞察 D · success 语义必须后移
只有 metadata 里的 status=success 且 verification.ok=true，才应该对群里说“已经成功”。否则只能说“这次没有确认线上可用”。
SVG 4 · 根因矩阵
最高风险象限：旧 web-ship 规则仍可接住 deploy 群消息。
SVG 5 · 取舍评分卡
最优选择不是“更聪明地猜”，而是“更严格地互斥分流”。
SVG 6 · 验证漏斗
真正留下来的只有已验证成功的那部分。
为什么之前会混入 web-ship
- 旧 agent 角色过强：web-ship 的历史定位是“任何消息→更新单页→部署”，这和 deploy 群的 topic 调研链路天然冲突。
- 入口规则未互斥：当
/topic、状态查询、普通跟进消息没有被明确定义为 mutually exclusive，泛化 agent 更容易抢先响应。
- topic fallback 污染：像
last_topic.txt、默认 topic=web-ship 这类回退路径，如果在错误场景触发，会让新的 deploy 请求被旧话题吸走。
- 成功判定过早：旧流更像“脚本跑了就回 URL”，而不是“验证 URL 可访问才回成功”，这会让串台问题被隐藏得更深。
SVG 7 · 前后对比时间线
这次改造的核心，不是更花哨，而是把成功回执从“开始时”推迟到“验证后”。
比较 / 取舍
保留 web-ship 作为 deploy 群默认
优点是实现简单；缺点是会把“调研链路”和“任意页面壳页部署”混成一类，长期一定串台。
让 topic-deploy 成为 /topic 专属入口
优点是命令语义清晰、topic 生命周期可追踪、回执标准可统一；代价是规则更严格、需要明确静默策略。
建议：对 deploy 群，保留 web-ship 仅作历史/调试遗留，不再作为默认 topic 入口；topic 类请求由 topic-deploy 独占。
SVG 8 · 行动优先级梯子
先修入口，再修状态，再修说明；不要反过来。
行动计划
- 入口互斥化：deploy 群只把
/topic 导向 topic-deploy；/help 仅返回 usage；/links|/status 仅运行 ship-links.sh。
- topic 归一化：对 topic 做 kebab-case、去掉
/ \ .. 等危险路径字符；若已有 latest.html 先读取，避免散 topic。
- 成功语义标准化：部署后必须读取
.ship-logs/reply-meta.<TOPIC>.json 或 fallback metadata，且要求 verification.ok=true。
- 失败回执人话化：不再回复抽象失败码，而是明确“这次没有确认线上可用”，再给最后可用链接。
SVG 9 · 证据图
好的回执，背后至少要有入口、状态、验证三类证据。
SVG 10 · 风险边界图
边界写清楚，系统才会稳定。
SVG 11 · topic 生命周期飞轮
topic 一旦稳定，后续跟进就能围绕同一 latest/history 累积，而不是散成多个页面。
风险 / 边界
- 如果上层仍有其他 always-on agent 能接同一条 deploy 群消息，topic-deploy 的规则再好，也可能被前置抢答。
- 如果 metadata 文件未生成或未按 topic 写入，成功/失败判断会退化到日志猜测，可靠性下降。
- 如果只做 HEAD 验证而不用 GET，可能被某些 Vercel 路由误判；验收应以 GET 200 为准。
- 如果继续依赖默认 topic=web-ship 或 last_topic fallback，topic 散乱与串台还会反复出现。
SVG 12 · Closing 系统图
最终不是靠口头说明，而是靠 metadata + verification 把成功定义成可审计事件。