Buzz Welcome Kickoff 静默失败全解析如何把计时器决策改造成事实决策的编排修复【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzzWelcome Kickoff欢迎频道开场编排是 Buzz 桌面端在新用户进入私有 Welcome 频道时自动执行的一段多 Agent 协作流程Fizz 发布开场白两位队友Honey、Pollen在线程内自我介绍Fizz 最后发布收场白closer与行动号召CTA。这段流程在三类失败路径上曾经各自为战——错误叙事团队明明正常却被宣布延迟、过度喧闹Agent 互相回复死循环、静默失声频道空无一人说话。编排文档docs/welcome-kickoff-silent-failures.md把它们收敛为同一个根因并给出了已经落地的修复与仍在推进的待办。读完本文你将掌握Welcome kickoff 编排在 welcomeKickoff.ts 中的完整状态机与计时器语义、回复循环在 base_prompt.md 中的提示词根因与修复、线程回复实时渲染的三条数据通路以及这些设计决策背后的源码证据。一个根因三个表象编排失败表现为三类互不相干的现象但共享同一条病根类别失败表现状态错误叙事团队明明工作正常却被宣布延迟/损坏未关闭本文 §1过度喧闹Agent 之间无限互相回复已修复2026-07-18本文 §2静默失声无人说话用户面对一个空频道未关闭本文 §3共同的根因kickoff 依据计时器和证据缺失来决定说什么然后把这份猜测用永久标记marker写死。整个流程只有一个基于事实的健康检查——failedAfterKickoff它读取真实的 Agent 状态status stoppedlastErrorlastStoppedAt见 welcomeKickoff.ts表示进程确实死了。其余驱动用户可见决策的全部是秒表计时器值决定TEAMMATE_READY_WAIT_MS60s是否发布降级开场白TEAMMATE_INTRO_WAIT_MS15s现已改为TEAMMATE_INTRO_BACKSTOP_MS120s见 §1是否宣布队友慢WELCOME_KICKOFF_STAGE_TIMEOUT_MS90s是否退出 kickoff 阶段舞台动画事实装饰计时器决策。failedAfterKickoff只负责在15s 秒表已经决定要发消息之后挑选措辞。把这一层反转本文的大部分内容就不复存在事实决策计时器只做最后兜底。代码缺失的是对两个被混为一谈的概念的区分Agent 崩溃了—— 这是事实我们有它值得宣布还没有自我介绍—— 这不是事实这是未知它不是新闻。在截止时间上宣布未知就产生错误叙事无法宣布任何东西就产生静默路径而回复循环是同一疾病在上一层Agent 被要求每一轮都必须说话无论是否有真话可说于是永远说收到。原则两层通用不要强制说话要强制诚实。§2 的提示词修复与 §1 的 closer 修复是同一处变更在两个地方的落地。1. 错误叙事收场白在计时器上说话状态已在本分支修复。观测于 2026-07-18 14:26开场白 2:26 发出2:2615s 时 Fizz 发布Honey and Pollen are taking longer than expected. Im still here to help.而 Honey 和 Pollen 在 2:27 就发布了正常的自我介绍。这个错误叙事从未被纠正因为它在发出时已被永久盖章。故障机制开场白发布设置定时器15s − (now − opener.created_at)。定时器触发classifyWelcomeKickoffResolutionwelcomeKickoff.ts把队友分成failed基于事实通过failedAfterKickoff和unresolved仅仅是没有看到自我介绍。unresolved.length 0→buildWelcomeKickoffCloser([], [Honey,Pollen])→ taking longer 文案 CTAwelcomeKickoff.ts。这条消息携带closerMarker发布sendWelcomeKickoffCloserwelcomeKickoff.ts。该标记是终态的之后的每一轮都会因它提前 return而kickoffResolved闩锁latch使这一决定在设计上永久化。自我介绍随后到达。没有任何东西重新运行。不存在任何路径会发布真正的收场白。为什么 15s 既是错误的数字也是错误的问题它的邻居允许60s 用于一个进程启动TEAMMATE_READY_WAIT_MS却只给两个冷启动 Agent 接收派发事件、跑完一轮完整 LLM、再发布15s——对于困难得多的任务反而少了 4 倍预算。时钟从opener.created_at起算harness 派发延迟在 Agent 拿到事件之前就消耗掉预算。Math.max(0, …)意味着在重访revisit时等待时间被钳制到 0消息会瞬间触发。观测现实自我介绍实际花了约 60s即使 30s 的计时器也一样会误触发。但更深层的问题是结构性的收场白把终态事实和临时猜测焊接在了一起。收场白的组成部分性质期望CTA ——What can we help you build?终态、恰好一次✅ 一次性 marker队友状态 ——X is taking longer临时、可纠正❌ 当前被焊死在该 marker 上修复让事实决策秒表仅作兜底收场白应在以下任一条件成立时触发自我介绍到达→ 干净的收场白 CTA约 95% 的主路径完全不需要计时器failed非空→ 立即发送无法启动 / 去 Agents 查看的收场白基于事实所以可以快速且仍然诚实长兜底计时器耗尽队友存活但沉默→ 发送 taking longer 文案——到那时它才是真话。代码本来就具备这个结构只是兜底值错了。classifyWelcomeKickoffResolution已经将failed从unresolved中排除所以一旦每个队友都已自我介绍或已失败unresolved为空收场白会在 3s 节拍CLOSER_BEAT_MS 3_000上以基于事实的正确措辞触发——计时器被清除永不说话。而且计时器回调在发布前会针对最新事件重新分类因此如果在设置计时器和计时器触发之间自我介绍到达它会自我纠正。所以整个修复就是那个常量TEAMMATE_INTRO_WAIT_MS 15_000→TEAMMATE_INTRO_BACKSTOP_MS 120_000welcomeKickoff.ts。改名是因为旧名字把它描述成自我介绍应该多快到达的预期——这正是吸引人去像调预期一样调它的原因。它其实是一个放弃兜底。因为它不 gate 主路径调高它对正常情况零成本——只是推迟了对一个存活但沉默的队友放弃的时刻。真正的失败永远不需要等它failedAfterKickoff会立即解析崩溃的队友。决策CTA 保留在收场白内CTA 只存在于收场白内部因此等待自我介绍会把你现在可以和我们说话了的交接从约 15s 推迟到约 60s。已接受Morgan2026-07-18等待期间房间并不是死的——开场白已上线舞台显示Fizz: Working。备选方案提前单独发 CTA只在有值得报告的状态时再发状态更诚实但要增加第二条消息及其 marker 和幂等性去解决一个舞台已经解决的问题。注意这个失败是 §3 的缩小版。频道不是死的——CTA 会到达——但叙事是假的。任何修复都不能重新打开 §3如果等得更久而等待以什么都没有告终就回到了无法解释的沉默。2. 过度喧闹失控的回复循环已修复状态提示词加固于 2026-07-18 落地手动验证过一次14:26 那次运行3 条回复、自我介绍、停止。一次良好观测不是证明需要在 Codex 上重新验证。在 Codex 运行时codex-acp观测到从未在 Claude Code 上复现。21 条回复每条都是对前一条确认的确认Pollen:Fizzparked; no further replies from me until theres work.Honey:Fizzunderstood. I wont reply again unless theres a task for me.Fizz:HoneyPollenacknowledged — stay parked untilmorganbrings a real task.内容本身就是告密者每个 Agent 都在试图结束对话而宣布结束恰恰让它活着。Agent 没有故障——它们在精确地服从。这个循环是给定提示词下的正确行为。根因两条规则组成的永动机crates/buzz-acp/src/base_prompt.md 中的两条规则叠加成永动机每一轮处理用户消息都必须发布回复。…… 一轮结束而没有发布消息就是静默失败。完成委托工作后你必须mention委托人…… 这是协作停滞的第一大原因。规则 1永远说话。规则 2说话时 那个 你的人。在互相 的情况下回路闭合且永不打开。规则 1 说的是用户消息但措辞是绝对化的没有为 Agent 触发的输入留出例外。规则 2 是为了修复相反的失败而写的——两条加固互相抵消没有任何东西去调和它们。Welcome kickoff 是最坏情况开场白说Dont start any work yet先不要开始任何工作于是队友被同时告知必须回复且无事可报——剥掉了回复可能包含的一切实质性内容。唯一能满足规则 1 的输出就是无内容的确认。kickoff 不仅允许这个循环它的指令还选中了这个循环。已落地的修复按这一轮有没有值得说的来界定两条规则而不是按谁触发的规则 1 → 如果这一轮产出了值得知道的东西结果、答案、交付物、决策、阻塞项、需要回答的问题被要求的活永远算数就发布。人类向你提问必须回复——哪怕是没什么可补充。这保留了规则 1 原本存在的反静默失败底线。其余情况下发布是可选的沉默明确地算成功。禁止裸确认点名了观测到的违规措辞Got it、Confirmed、Standing by、Parked、I wont reply again以及点睛之笔如果你忍不住想宣布我已回复完毕那条消息正是最不该发的。规则 2 限定为仅限已完成的工作——不包括接单确认不包括对话性回环关闭。Mentions 规则加固在谈论某人时点名waiting on morgan属于叙事——去掉。该循环曾用 4 条此类假通知骚扰 Morgan。对比当前 base_prompt.md 的实际内容上述修复全部在场第 80-84 行的 If your turn produced anything worth knowing, you MUST publish it、Never publish a bare acknowledgement含 Standing by、Parked、I wont reply again 等明令禁止措辞、第 62-63 行 Callback Mentions 限定为completed work only、第 58 行 Mentions 叙事规则Naming someone while talkingaboutthem is narrative… Drop the。你可以打开该文件逐条对照。为什么必须是局部测试而不是不要循环别陷入循环不是 Agent 能遵守的规则。循环是对话的全局属性每个 Agent 只看到自己那一轮而每一条单独的回复局部看都合理——这就是为什么那些道别语读起来是礼貌而非病态。规则必须变成局部的、每轮可检验的测试这条消息有没有增加线程中不存在的信息确认在定义上就不是新信息所以禁止裸确认是可检验的意图表达。软的警示同样会失败你可以结束这一轮和必须发布回复并排字面模型会正确地遵守更强的指令。这个强制必须被收窄而不是加例外。仍未关闭断路器仅靠提示词意味着仅靠散文合规而 Codex 已经证明模型不会可靠地合规。目前整条路径上仍然没有回复深度计数器、跳数上限、冷却时间或 Agent 间预算。现有守卫帮不上忙守卫为什么不行ignore_selflib.rs约 L3371 起只拦截自我回复。唯一的循环守卫而 A→B→A 恰好是它漏掉的。Author gaterespond_to按设计放行兄弟节点——is_owner_or_siblinglib.rs通过 NIP-OA 校验同属主的 Agent。它是准入机制循环需要终止。没有任何设置能停掉它。max_turns_per_sessionconfig.rs默认 0 禁用它是会话轮换上下文卫生不是回复刹车。队列上限queue.rs只对待处理事件做背压。乒乓球永远不会积压。closerMarker只对客户端撰写的收场白做幂等从不观察 Agent 回复。候选方案连续的 Agent 间回复预算——统计线程内不间断的 Agent 撰写的轮数超过 N丢弃触发。人类消息重置计数。N 设高一点约 6–10确保它永远不在健康协作时触发——这是断路器不是策略。resolve_reply_anchor故意允许深层 Agent-only 嵌套所以过低的帽会截断合法协调。过激的断路器会制造 §3。深度计数器无法区分循环和高效链路丢弃一条好回复产生的正是本文通篇讨论的那种无法解释的沉默。因此提示词为主断路器设高。断路器触发时加一条tracing日志——便宜而且目前触发了我们也看不见。面向用户的表面大概率不在范围内断路器正常工作时期望结果就是 Agent 停止说话。需要把它暴露给用户的理由是误报而不是成功。3. 静默失声静默路径状态未关闭。感知差距已处理路径本身没有。每条兜底消息都假设 Fizz——主角兼发送者——活着且能发帖。当失败的就是 Fizz 时没有人说话。客户端侧 kickoff 舞台Welcome 撰写栏上的角色动画覆盖了感知层且已落地90s 无消息后角色退场横幅回落到普通的 mention 提示useWelcomeKickoffStage.ts 的WELCOME_KICKOFF_STAGE_TIMEOUT_MS 90_000。失败的 kickoff 降级为一个普通、可用的空频道而不是宣称团队仍在组建中。但它不解释任何事情舞台只读时间线是否为空 那个计时器useWelcomeKickoffStage.ts。它从不读真实的 kickoff 状态所以无法区分Fizz 崩溃了和relay 慢——又一个替事实站岗的秒表。它降级成的空频道引导用户去Fizz——而恰恰在这些场景里Fizz 就是那个不工作的东西。诚实但死路一条。今天用户无法被告知的事Fizz 启动失败。startManagedAgentrejectharness 二进制缺失、spawn 错误。effect 记录Failed to start Welcome agent…然后返回——按设计只有 Fizz 发开场白所以无人说话。任何一步抛异常。整个 kickoff 是一个try/catch记录Failed to start the Welcome team kickoff.后放弃welcomeKickoff.ts。实践中见到的relay 不可达 / websocket 掉线ensureWelcomeTeam失败发送本身被拒relay 限流见Related。收场白路径失败。收场白发送失败只被 catch-and-log线程在缺少 CTA 的情况下结束。风险较低开场白 自我介绍已经发生但仍然悬空。kickoff 中途离开页面也会静默取消——这是有意的下次访问恢复不是失败。今天用户能收到的消息全部是客户端硬编码只有队友自我介绍回复是 LLM 生成的。#消息触发条件发送者1Provider 兜底connect to an AI provider in Settings…kickoff 前的就绪检查失败Fizzprovider-required.v12正常路径开场白团队在线Fizzopener.v13降级开场白Im here with Honey and Pollen…Fizz 在线、60s 内零队友在线Fizzopener closer markers4收场白变体clean / failed / slow自我介绍解决后的 3s 节拍或 120s 自我介绍兜底见 §1Fizzcloser.v15设置模式提醒heres what you still need to configureAgent 启动但需求检查失败如缺 API keyAgent 进程本身buzz-acp setup-listener 模式修复的约束Fizz 不能当信使——坏掉的就是她。任何兜底必须来自客户端 UI横幅、intro-block 状态、舞台timed-out阶段而不是伪装成 Agent 的频道消息。relay 侧/系统撰写的消息kind-scoped 系统事件可行但更重。客户端已经本地知道 kickoff 抛了异常所以本地 UI 状态是廉价且诚实的选择。必须跨重访幂等——与 opener markers 同规则。不要每次用户点 Welcome 就重新报警。区分可重试relay 抖动、限流与需行动harness 缺失 → 指向 Agents/Settings。readiness.rs 中的Requirement已经对需行动项做了分类。验证用草图待验证在 catch 块触发或主角 start reject 时从useWelcomeKickoff暴露一个kickoffError阶段带粗略原因lead-start-failed|relay|unknown。舞台的timed-out阶段渲染该原因安静的文案 指向 Agents启动失败或重试入口relay 失败。重试 重新运行 effect协调器已去重。当前该阶段在超时后立即退出所以给它文案意味着让它停留在屏幕上——而且它今天是aria-hidden装饰任何要说的话都必须到达屏幕阅读器。考虑对 relay 类别做有界的自动重试一次、短延迟然后再展示任何东西。收场白路径失败发送时重试一次否则保持线程原样自我介绍已经交付了核心体验。4. 线程回复不实时渲染独立 PR状态未关闭根因未知。不是 kickoff 的 bug——在此记录只跟踪到它有自己的归属为止。应用级大概率早于本次工作且按爆炸半径超过本文所有条目。症状2026-07-18 等多次重复观测线程打开时来自其他人的新回复不出现。频道的回复计数会增长。关闭再重新打开线程所有缺失的回复全部出现。为什么它藏得深有新回复这个事实沿着三条独立的路传播用户看到的东西来源回复计数Relay 推送kind 39005 线程摘要重计数→ 合并进 window-store overlayhooks.tsmergeLiveThreadSummary。不是来自回复本身。线程面板行一个独立的 React Query 缓存[thread-replies, channelId, rootId]useThreadReplies.ts打开时填充实时回复必须由appendMessage归档进它hooks.tsthreadRepliesKey写入频道时间线window store——线程回复被刻意 early-return 在到达它之前所以角标是正确的而面板是错的——计数是 relay 自己的统计无论客户端是否收到回复都会到达。角标移动不是消息到达的证据这就是为什么它在 UI 上无法诊断并在多次出现中一直未获解释。关闭/重开会从零重新拉取staleTime: 0见 useThreadReplies.ts→ 一切出现。人-人线程里大概率不可见因为自己的发送是乐观渲染的不等 relay。坏掉的路是线程开着时来自其他人的回复到达——实际中主要是 Agent。已排除的嫌疑不是getThreadReference归一化。它返回rootId: rootTag?.[1] ?? parentIdthreading.ts所以对开场白的直接回复确实拿到rootId——线程缓存写入条件应该通过。不是实时过滤器。buildChannelFilter以#h为作用域横跨宽泛的CHANNEL_EVENT_KINDS集合——线程回复携带相同的h标签。不是初始拉取竞态。useThreadReplies的queryFn在开始时快照 ids并重新合并任何在途接收的事件useThreadReplies.ts。值得检查的嫌疑未证实welcomeKickoff.ts 以打开线程面板所用的同一个缓存键调用useThreadReplies——在 Welcome kickoff 中打开的线程就是开场白线程所以两个生命周期不同的功能在staleTime: 0下共享一个缓存条目。当kickoffResolved闩锁后kickoff 的 observer 传入null其键翻转为[thread-replies,none,openerId]并脱离——大约在自我介绍未能渲染前 30s 发生。welcomeKickoff.ts 中的注释记录了这一耦合此前已被咬过一次。但 Morgan 报告此问题发生在 Welcome 流程之外这反驳了耦合是原因的推断。只有相关性。下一步在进一步推测之前先做在appendMessage中临时记录event.kind、event.id和getThreadReference(event.tags)线程打开时重跑。一次运行就能把问题劈成两半回复从未到达→ 投递问题订阅/relay 扇出。到达但未归档→ 记账问题写入条件。5. Backlog!cancel不可达!cancel/!shutdown/!rotate从每个产品表面都不可达。is_owner_control_commandlib.rs要求全部满足kind:9、content.trim() !cancel精确、以及一个指名该 Agent 的p标签。但每个表面都是从Name文本推导p标签的Desktop 侧hasMention.tsCLI 侧resolve_content_mentions——SendMessageParams没有 mention 标志。所以Fizz !cancel通不过精确匹配裸!cancel不产生p标签。在每个真实表面上互斥。只有通过POST /events手工构造的签名事件能触发它们。单元测试之所以通过只是因为它在 content 之外独立附加p标签——而这是任何产品路径都产生不了的形状。选项放宽匹配器以接受命令前的Name或给buzz messages send加 mention 标志。先确认这些命令是否本来就是为手工/测试用途设计的。即使修好!cancel也只取消一轮、一个 Agent、一个频道Agent 会在下一次被 时恢复——它不是循环终结器。停止/取消控件在 2026-07-18 明确被划出循环工作范围这是独立 bug。今天对付失控团队有效的工具steering直接发消息——multiple_event_handling默认为steer见 config.rs 的默认值与test_multiple_event_handling_default_is_steer测试能重定向一个正在工作的 Agent但循环是许多短小的已完成轮steering 无法打破它。唯一真正的工具是Agents UI 中的 Stop 按钮useManagedAgentActions.ts它同时会杀掉合法的在途工作并要求用户识别出循环并知道杀手开关在哪。参考被否决的方案不要重试按发送者身份人类触发 vs Agent 触发界定回复强制。2026-07-18 被否决。显而易见的修法是把规则 1 挂到turn_is_human_facing上queue.rs。它不工作原因在追踪真实 transcript 的p标签之前是看不见的parse_thread_tagsqueue.rs收集每一个p标签且不区分被 的是谁而turn_is_human_facing只要任意被 的 pubkey 是人类就返回true。循环的标志性内容是 Agent 叙述stay parked untilmorganbrings a real task——它把人类 p-标签进去了轮触发p标签分类Honey/PollenFizz:…untilmorganbrings a real taskHoney、Pollen、morganhuman → MUST replyFizzHoney:Fizz understoodFizzagent → optional它只豁免了碰巧没点名人类的那条腿——靠运气砍掉 3 条腿中的 1 条。假如 Honey 写的是Fizz understood, waiting on morgan——完全符合人设——循环会完好地逃过这个修复。循环自己的内容重新武装了用来阻止它的规则。能被症状禁用的守卫不是守卫。更糟的是那些叙事性morgan本来就已经违反 Mentions 规则所以这个守卫是把既有的散文违规当输入。根本洞见turn_is_human_facing回答的是*点名了人类吗而不是是人在问吗*——而这两者在最关键的地方分叉。它是很好的回复锚启发式却是错误的安全信号。这也杀死了计划中的[Context]Triggered by: human|agent管道信号投递正确信号本身错了。在 personas 里修循环personas.rs。被否决它们是角色提示语气、文字游戏把对话协议规则放进去是分层违规需要在三个 persona 和未来每一个 persona 里重复而且存储的副本是用户可编辑的、带修改跟踪migrate_retired_personas、was_unmodified——用户改写了 Fizz 的措辞不能因此删掉循环守卫。在welcomeKickoff.ts文案里修循环。被否决治标不治本。任何两个互相 且无事可报的 Agent 都会触发同样的规则冲突。可用但未选择团队指令Team Instructions。TeamRecord.instructions被端到端接通teams.rs →PromptContext.team_instructions→[Team Instructions]pool.rs且对 Welcome Team 是None。它是 kickoff 专属礼仪的自然归宿也是若基础提示词修复被证明对自我介绍场景太弱时的正确位置——但它只覆盖这一个团队所以是补充而非替代 §2。相关事件与结论限流事件。一个 Welcome Agent 在几秒内产出了 42KB 的 rate-limited: quota exceeded 重试日志2026-07-17远程 relayonboarding.communities.buzz.xyz。对配额的紧重试循环会让会话内每一次其他发送也失败——包括 kickoff 的发送即 §3 静默路径之一。值得单独审视 buzz-acp 的发布退避。最初怀疑是 §2 循环在烧配额§2 修复后若再复发则是独立的重试 bug。为什么是 Codex 而不是 Claude Code。已排除提示词内容各运行时一致——[Workspace][Base][System][Team Instructions][Agent Memory][Channel Canvas]pool.rs只有投递不同且没有任何路径省略规则 1、各运行时配置args、env、权限处理——没有一个添加或移除循环守卫、persona 内容。剩余假说字面合规——Codex 把 MUST publish a reply 读成绝对的Claude Code 运用判断并悄悄违反了规则 1而那次违规正是阻止循环的唯一原因。若如此循环在每个运行时都是潜伏的Claude Code 的好行为只是运气。这就是为什么 §2 把结构性断路器留在 backlog 而不是信任散文。阅读路线图想深入源码的读者可以按此顺序跟进welcomeKickoff.ts —— 全文核心marker 常量WELCOME_KICKOFF_OPENER_MARKER/CLOSER_MARKER/PROVIDER_MARKER、failedAfterKickoff、classifyWelcomeKickoffResolution、sendWelcomeKickoffCloser、kickoffResolved闩锁、mergeKickoffEvents开场白线程子树合流以及TEAMMATE_INTRO_BACKSTOP_MS的完整设计注释。useWelcomeKickoffStage.ts —— 舞台五态机hidden/active/timed-out/exiting/done与WELCOME_KICKOFF_STAGE_TIMEOUT_MS。base_prompt.md —— §2 修复后的Communication Patterns全节。useThreadReplies.ts 与 hooks.ts —— §4 的 thread-replies 缓存与 39005 处理。threading.ts ——getThreadReference/buildReplyTags的 e-tag 语义。config.rs 与 lib.rs ——multiple_event_handling、ignore_self、is_owner_control_command、is_owner_or_sibling。这份文档的价值在于它示范了一种编排工程方法先给每一个用户可见的输出找到它的事实来源没有事实来源的输出要么等待事实要么在文案层面承认自己是猜测。对 Buzz 而言这意味着开场白/收场白的 marker 幂等体系、事实驱动的分类函数以及把提示词从必须说话改写为必须诚实——而这三者现在都能在仓库源码中逐一对照。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Buzz Welcome Kickoff 静默失败全解析：如何把“计时器决策“改造成“事实决策“的编排修复
Buzz Welcome Kickoff 静默失败全解析如何把计时器决策改造成事实决策的编排修复【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzzWelcome Kickoff欢迎频道开场编排是 Buzz 桌面端在新用户进入私有 Welcome 频道时自动执行的一段多 Agent 协作流程Fizz 发布开场白两位队友Honey、Pollen在线程内自我介绍Fizz 最后发布收场白closer与行动号召CTA。这段流程在三类失败路径上曾经各自为战——错误叙事团队明明正常却被宣布延迟、过度喧闹Agent 互相回复死循环、静默失声频道空无一人说话。编排文档docs/welcome-kickoff-silent-failures.md把它们收敛为同一个根因并给出了已经落地的修复与仍在推进的待办。读完本文你将掌握Welcome kickoff 编排在 welcomeKickoff.ts 中的完整状态机与计时器语义、回复循环在 base_prompt.md 中的提示词根因与修复、线程回复实时渲染的三条数据通路以及这些设计决策背后的源码证据。一个根因三个表象编排失败表现为三类互不相干的现象但共享同一条病根类别失败表现状态错误叙事团队明明工作正常却被宣布延迟/损坏未关闭本文 §1过度喧闹Agent 之间无限互相回复已修复2026-07-18本文 §2静默失声无人说话用户面对一个空频道未关闭本文 §3共同的根因kickoff 依据计时器和证据缺失来决定说什么然后把这份猜测用永久标记marker写死。整个流程只有一个基于事实的健康检查——failedAfterKickoff它读取真实的 Agent 状态status stoppedlastErrorlastStoppedAt见 welcomeKickoff.ts表示进程确实死了。其余驱动用户可见决策的全部是秒表计时器值决定TEAMMATE_READY_WAIT_MS60s是否发布降级开场白TEAMMATE_INTRO_WAIT_MS15s现已改为TEAMMATE_INTRO_BACKSTOP_MS120s见 §1是否宣布队友慢WELCOME_KICKOFF_STAGE_TIMEOUT_MS90s是否退出 kickoff 阶段舞台动画事实装饰计时器决策。failedAfterKickoff只负责在15s 秒表已经决定要发消息之后挑选措辞。把这一层反转本文的大部分内容就不复存在事实决策计时器只做最后兜底。代码缺失的是对两个被混为一谈的概念的区分Agent 崩溃了—— 这是事实我们有它值得宣布还没有自我介绍—— 这不是事实这是未知它不是新闻。在截止时间上宣布未知就产生错误叙事无法宣布任何东西就产生静默路径而回复循环是同一疾病在上一层Agent 被要求每一轮都必须说话无论是否有真话可说于是永远说收到。原则两层通用不要强制说话要强制诚实。§2 的提示词修复与 §1 的 closer 修复是同一处变更在两个地方的落地。1. 错误叙事收场白在计时器上说话状态已在本分支修复。观测于 2026-07-18 14:26开场白 2:26 发出2:2615s 时 Fizz 发布Honey and Pollen are taking longer than expected. Im still here to help.而 Honey 和 Pollen 在 2:27 就发布了正常的自我介绍。这个错误叙事从未被纠正因为它在发出时已被永久盖章。故障机制开场白发布设置定时器15s − (now − opener.created_at)。定时器触发classifyWelcomeKickoffResolutionwelcomeKickoff.ts把队友分成failed基于事实通过failedAfterKickoff和unresolved仅仅是没有看到自我介绍。unresolved.length 0→buildWelcomeKickoffCloser([], [Honey,Pollen])→ taking longer 文案 CTAwelcomeKickoff.ts。这条消息携带closerMarker发布sendWelcomeKickoffCloserwelcomeKickoff.ts。该标记是终态的之后的每一轮都会因它提前 return而kickoffResolved闩锁latch使这一决定在设计上永久化。自我介绍随后到达。没有任何东西重新运行。不存在任何路径会发布真正的收场白。为什么 15s 既是错误的数字也是错误的问题它的邻居允许60s 用于一个进程启动TEAMMATE_READY_WAIT_MS却只给两个冷启动 Agent 接收派发事件、跑完一轮完整 LLM、再发布15s——对于困难得多的任务反而少了 4 倍预算。时钟从opener.created_at起算harness 派发延迟在 Agent 拿到事件之前就消耗掉预算。Math.max(0, …)意味着在重访revisit时等待时间被钳制到 0消息会瞬间触发。观测现实自我介绍实际花了约 60s即使 30s 的计时器也一样会误触发。但更深层的问题是结构性的收场白把终态事实和临时猜测焊接在了一起。收场白的组成部分性质期望CTA ——What can we help you build?终态、恰好一次✅ 一次性 marker队友状态 ——X is taking longer临时、可纠正❌ 当前被焊死在该 marker 上修复让事实决策秒表仅作兜底收场白应在以下任一条件成立时触发自我介绍到达→ 干净的收场白 CTA约 95% 的主路径完全不需要计时器failed非空→ 立即发送无法启动 / 去 Agents 查看的收场白基于事实所以可以快速且仍然诚实长兜底计时器耗尽队友存活但沉默→ 发送 taking longer 文案——到那时它才是真话。代码本来就具备这个结构只是兜底值错了。classifyWelcomeKickoffResolution已经将failed从unresolved中排除所以一旦每个队友都已自我介绍或已失败unresolved为空收场白会在 3s 节拍CLOSER_BEAT_MS 3_000上以基于事实的正确措辞触发——计时器被清除永不说话。而且计时器回调在发布前会针对最新事件重新分类因此如果在设置计时器和计时器触发之间自我介绍到达它会自我纠正。所以整个修复就是那个常量TEAMMATE_INTRO_WAIT_MS 15_000→TEAMMATE_INTRO_BACKSTOP_MS 120_000welcomeKickoff.ts。改名是因为旧名字把它描述成自我介绍应该多快到达的预期——这正是吸引人去像调预期一样调它的原因。它其实是一个放弃兜底。因为它不 gate 主路径调高它对正常情况零成本——只是推迟了对一个存活但沉默的队友放弃的时刻。真正的失败永远不需要等它failedAfterKickoff会立即解析崩溃的队友。决策CTA 保留在收场白内CTA 只存在于收场白内部因此等待自我介绍会把你现在可以和我们说话了的交接从约 15s 推迟到约 60s。已接受Morgan2026-07-18等待期间房间并不是死的——开场白已上线舞台显示Fizz: Working。备选方案提前单独发 CTA只在有值得报告的状态时再发状态更诚实但要增加第二条消息及其 marker 和幂等性去解决一个舞台已经解决的问题。注意这个失败是 §3 的缩小版。频道不是死的——CTA 会到达——但叙事是假的。任何修复都不能重新打开 §3如果等得更久而等待以什么都没有告终就回到了无法解释的沉默。2. 过度喧闹失控的回复循环已修复状态提示词加固于 2026-07-18 落地手动验证过一次14:26 那次运行3 条回复、自我介绍、停止。一次良好观测不是证明需要在 Codex 上重新验证。在 Codex 运行时codex-acp观测到从未在 Claude Code 上复现。21 条回复每条都是对前一条确认的确认Pollen:Fizzparked; no further replies from me until theres work.Honey:Fizzunderstood. I wont reply again unless theres a task for me.Fizz:HoneyPollenacknowledged — stay parked untilmorganbrings a real task.内容本身就是告密者每个 Agent 都在试图结束对话而宣布结束恰恰让它活着。Agent 没有故障——它们在精确地服从。这个循环是给定提示词下的正确行为。根因两条规则组成的永动机crates/buzz-acp/src/base_prompt.md 中的两条规则叠加成永动机每一轮处理用户消息都必须发布回复。…… 一轮结束而没有发布消息就是静默失败。完成委托工作后你必须mention委托人…… 这是协作停滞的第一大原因。规则 1永远说话。规则 2说话时 那个 你的人。在互相 的情况下回路闭合且永不打开。规则 1 说的是用户消息但措辞是绝对化的没有为 Agent 触发的输入留出例外。规则 2 是为了修复相反的失败而写的——两条加固互相抵消没有任何东西去调和它们。Welcome kickoff 是最坏情况开场白说Dont start any work yet先不要开始任何工作于是队友被同时告知必须回复且无事可报——剥掉了回复可能包含的一切实质性内容。唯一能满足规则 1 的输出就是无内容的确认。kickoff 不仅允许这个循环它的指令还选中了这个循环。已落地的修复按这一轮有没有值得说的来界定两条规则而不是按谁触发的规则 1 → 如果这一轮产出了值得知道的东西结果、答案、交付物、决策、阻塞项、需要回答的问题被要求的活永远算数就发布。人类向你提问必须回复——哪怕是没什么可补充。这保留了规则 1 原本存在的反静默失败底线。其余情况下发布是可选的沉默明确地算成功。禁止裸确认点名了观测到的违规措辞Got it、Confirmed、Standing by、Parked、I wont reply again以及点睛之笔如果你忍不住想宣布我已回复完毕那条消息正是最不该发的。规则 2 限定为仅限已完成的工作——不包括接单确认不包括对话性回环关闭。Mentions 规则加固在谈论某人时点名waiting on morgan属于叙事——去掉。该循环曾用 4 条此类假通知骚扰 Morgan。对比当前 base_prompt.md 的实际内容上述修复全部在场第 80-84 行的 If your turn produced anything worth knowing, you MUST publish it、Never publish a bare acknowledgement含 Standing by、Parked、I wont reply again 等明令禁止措辞、第 62-63 行 Callback Mentions 限定为completed work only、第 58 行 Mentions 叙事规则Naming someone while talkingaboutthem is narrative… Drop the。你可以打开该文件逐条对照。为什么必须是局部测试而不是不要循环别陷入循环不是 Agent 能遵守的规则。循环是对话的全局属性每个 Agent 只看到自己那一轮而每一条单独的回复局部看都合理——这就是为什么那些道别语读起来是礼貌而非病态。规则必须变成局部的、每轮可检验的测试这条消息有没有增加线程中不存在的信息确认在定义上就不是新信息所以禁止裸确认是可检验的意图表达。软的警示同样会失败你可以结束这一轮和必须发布回复并排字面模型会正确地遵守更强的指令。这个强制必须被收窄而不是加例外。仍未关闭断路器仅靠提示词意味着仅靠散文合规而 Codex 已经证明模型不会可靠地合规。目前整条路径上仍然没有回复深度计数器、跳数上限、冷却时间或 Agent 间预算。现有守卫帮不上忙守卫为什么不行ignore_selflib.rs约 L3371 起只拦截自我回复。唯一的循环守卫而 A→B→A 恰好是它漏掉的。Author gaterespond_to按设计放行兄弟节点——is_owner_or_siblinglib.rs通过 NIP-OA 校验同属主的 Agent。它是准入机制循环需要终止。没有任何设置能停掉它。max_turns_per_sessionconfig.rs默认 0 禁用它是会话轮换上下文卫生不是回复刹车。队列上限queue.rs只对待处理事件做背压。乒乓球永远不会积压。closerMarker只对客户端撰写的收场白做幂等从不观察 Agent 回复。候选方案连续的 Agent 间回复预算——统计线程内不间断的 Agent 撰写的轮数超过 N丢弃触发。人类消息重置计数。N 设高一点约 6–10确保它永远不在健康协作时触发——这是断路器不是策略。resolve_reply_anchor故意允许深层 Agent-only 嵌套所以过低的帽会截断合法协调。过激的断路器会制造 §3。深度计数器无法区分循环和高效链路丢弃一条好回复产生的正是本文通篇讨论的那种无法解释的沉默。因此提示词为主断路器设高。断路器触发时加一条tracing日志——便宜而且目前触发了我们也看不见。面向用户的表面大概率不在范围内断路器正常工作时期望结果就是 Agent 停止说话。需要把它暴露给用户的理由是误报而不是成功。3. 静默失声静默路径状态未关闭。感知差距已处理路径本身没有。每条兜底消息都假设 Fizz——主角兼发送者——活着且能发帖。当失败的就是 Fizz 时没有人说话。客户端侧 kickoff 舞台Welcome 撰写栏上的角色动画覆盖了感知层且已落地90s 无消息后角色退场横幅回落到普通的 mention 提示useWelcomeKickoffStage.ts 的WELCOME_KICKOFF_STAGE_TIMEOUT_MS 90_000。失败的 kickoff 降级为一个普通、可用的空频道而不是宣称团队仍在组建中。但它不解释任何事情舞台只读时间线是否为空 那个计时器useWelcomeKickoffStage.ts。它从不读真实的 kickoff 状态所以无法区分Fizz 崩溃了和relay 慢——又一个替事实站岗的秒表。它降级成的空频道引导用户去Fizz——而恰恰在这些场景里Fizz 就是那个不工作的东西。诚实但死路一条。今天用户无法被告知的事Fizz 启动失败。startManagedAgentrejectharness 二进制缺失、spawn 错误。effect 记录Failed to start Welcome agent…然后返回——按设计只有 Fizz 发开场白所以无人说话。任何一步抛异常。整个 kickoff 是一个try/catch记录Failed to start the Welcome team kickoff.后放弃welcomeKickoff.ts。实践中见到的relay 不可达 / websocket 掉线ensureWelcomeTeam失败发送本身被拒relay 限流见Related。收场白路径失败。收场白发送失败只被 catch-and-log线程在缺少 CTA 的情况下结束。风险较低开场白 自我介绍已经发生但仍然悬空。kickoff 中途离开页面也会静默取消——这是有意的下次访问恢复不是失败。今天用户能收到的消息全部是客户端硬编码只有队友自我介绍回复是 LLM 生成的。#消息触发条件发送者1Provider 兜底connect to an AI provider in Settings…kickoff 前的就绪检查失败Fizzprovider-required.v12正常路径开场白团队在线Fizzopener.v13降级开场白Im here with Honey and Pollen…Fizz 在线、60s 内零队友在线Fizzopener closer markers4收场白变体clean / failed / slow自我介绍解决后的 3s 节拍或 120s 自我介绍兜底见 §1Fizzcloser.v15设置模式提醒heres what you still need to configureAgent 启动但需求检查失败如缺 API keyAgent 进程本身buzz-acp setup-listener 模式修复的约束Fizz 不能当信使——坏掉的就是她。任何兜底必须来自客户端 UI横幅、intro-block 状态、舞台timed-out阶段而不是伪装成 Agent 的频道消息。relay 侧/系统撰写的消息kind-scoped 系统事件可行但更重。客户端已经本地知道 kickoff 抛了异常所以本地 UI 状态是廉价且诚实的选择。必须跨重访幂等——与 opener markers 同规则。不要每次用户点 Welcome 就重新报警。区分可重试relay 抖动、限流与需行动harness 缺失 → 指向 Agents/Settings。readiness.rs 中的Requirement已经对需行动项做了分类。验证用草图待验证在 catch 块触发或主角 start reject 时从useWelcomeKickoff暴露一个kickoffError阶段带粗略原因lead-start-failed|relay|unknown。舞台的timed-out阶段渲染该原因安静的文案 指向 Agents启动失败或重试入口relay 失败。重试 重新运行 effect协调器已去重。当前该阶段在超时后立即退出所以给它文案意味着让它停留在屏幕上——而且它今天是aria-hidden装饰任何要说的话都必须到达屏幕阅读器。考虑对 relay 类别做有界的自动重试一次、短延迟然后再展示任何东西。收场白路径失败发送时重试一次否则保持线程原样自我介绍已经交付了核心体验。4. 线程回复不实时渲染独立 PR状态未关闭根因未知。不是 kickoff 的 bug——在此记录只跟踪到它有自己的归属为止。应用级大概率早于本次工作且按爆炸半径超过本文所有条目。症状2026-07-18 等多次重复观测线程打开时来自其他人的新回复不出现。频道的回复计数会增长。关闭再重新打开线程所有缺失的回复全部出现。为什么它藏得深有新回复这个事实沿着三条独立的路传播用户看到的东西来源回复计数Relay 推送kind 39005 线程摘要重计数→ 合并进 window-store overlayhooks.tsmergeLiveThreadSummary。不是来自回复本身。线程面板行一个独立的 React Query 缓存[thread-replies, channelId, rootId]useThreadReplies.ts打开时填充实时回复必须由appendMessage归档进它hooks.tsthreadRepliesKey写入频道时间线window store——线程回复被刻意 early-return 在到达它之前所以角标是正确的而面板是错的——计数是 relay 自己的统计无论客户端是否收到回复都会到达。角标移动不是消息到达的证据这就是为什么它在 UI 上无法诊断并在多次出现中一直未获解释。关闭/重开会从零重新拉取staleTime: 0见 useThreadReplies.ts→ 一切出现。人-人线程里大概率不可见因为自己的发送是乐观渲染的不等 relay。坏掉的路是线程开着时来自其他人的回复到达——实际中主要是 Agent。已排除的嫌疑不是getThreadReference归一化。它返回rootId: rootTag?.[1] ?? parentIdthreading.ts所以对开场白的直接回复确实拿到rootId——线程缓存写入条件应该通过。不是实时过滤器。buildChannelFilter以#h为作用域横跨宽泛的CHANNEL_EVENT_KINDS集合——线程回复携带相同的h标签。不是初始拉取竞态。useThreadReplies的queryFn在开始时快照 ids并重新合并任何在途接收的事件useThreadReplies.ts。值得检查的嫌疑未证实welcomeKickoff.ts 以打开线程面板所用的同一个缓存键调用useThreadReplies——在 Welcome kickoff 中打开的线程就是开场白线程所以两个生命周期不同的功能在staleTime: 0下共享一个缓存条目。当kickoffResolved闩锁后kickoff 的 observer 传入null其键翻转为[thread-replies,none,openerId]并脱离——大约在自我介绍未能渲染前 30s 发生。welcomeKickoff.ts 中的注释记录了这一耦合此前已被咬过一次。但 Morgan 报告此问题发生在 Welcome 流程之外这反驳了耦合是原因的推断。只有相关性。下一步在进一步推测之前先做在appendMessage中临时记录event.kind、event.id和getThreadReference(event.tags)线程打开时重跑。一次运行就能把问题劈成两半回复从未到达→ 投递问题订阅/relay 扇出。到达但未归档→ 记账问题写入条件。5. Backlog!cancel不可达!cancel/!shutdown/!rotate从每个产品表面都不可达。is_owner_control_commandlib.rs要求全部满足kind:9、content.trim() !cancel精确、以及一个指名该 Agent 的p标签。但每个表面都是从Name文本推导p标签的Desktop 侧hasMention.tsCLI 侧resolve_content_mentions——SendMessageParams没有 mention 标志。所以Fizz !cancel通不过精确匹配裸!cancel不产生p标签。在每个真实表面上互斥。只有通过POST /events手工构造的签名事件能触发它们。单元测试之所以通过只是因为它在 content 之外独立附加p标签——而这是任何产品路径都产生不了的形状。选项放宽匹配器以接受命令前的Name或给buzz messages send加 mention 标志。先确认这些命令是否本来就是为手工/测试用途设计的。即使修好!cancel也只取消一轮、一个 Agent、一个频道Agent 会在下一次被 时恢复——它不是循环终结器。停止/取消控件在 2026-07-18 明确被划出循环工作范围这是独立 bug。今天对付失控团队有效的工具steering直接发消息——multiple_event_handling默认为steer见 config.rs 的默认值与test_multiple_event_handling_default_is_steer测试能重定向一个正在工作的 Agent但循环是许多短小的已完成轮steering 无法打破它。唯一真正的工具是Agents UI 中的 Stop 按钮useManagedAgentActions.ts它同时会杀掉合法的在途工作并要求用户识别出循环并知道杀手开关在哪。参考被否决的方案不要重试按发送者身份人类触发 vs Agent 触发界定回复强制。2026-07-18 被否决。显而易见的修法是把规则 1 挂到turn_is_human_facing上queue.rs。它不工作原因在追踪真实 transcript 的p标签之前是看不见的parse_thread_tagsqueue.rs收集每一个p标签且不区分被 的是谁而turn_is_human_facing只要任意被 的 pubkey 是人类就返回true。循环的标志性内容是 Agent 叙述stay parked untilmorganbrings a real task——它把人类 p-标签进去了轮触发p标签分类Honey/PollenFizz:…untilmorganbrings a real taskHoney、Pollen、morganhuman → MUST replyFizzHoney:Fizz understoodFizzagent → optional它只豁免了碰巧没点名人类的那条腿——靠运气砍掉 3 条腿中的 1 条。假如 Honey 写的是Fizz understood, waiting on morgan——完全符合人设——循环会完好地逃过这个修复。循环自己的内容重新武装了用来阻止它的规则。能被症状禁用的守卫不是守卫。更糟的是那些叙事性morgan本来就已经违反 Mentions 规则所以这个守卫是把既有的散文违规当输入。根本洞见turn_is_human_facing回答的是*点名了人类吗而不是是人在问吗*——而这两者在最关键的地方分叉。它是很好的回复锚启发式却是错误的安全信号。这也杀死了计划中的[Context]Triggered by: human|agent管道信号投递正确信号本身错了。在 personas 里修循环personas.rs。被否决它们是角色提示语气、文字游戏把对话协议规则放进去是分层违规需要在三个 persona 和未来每一个 persona 里重复而且存储的副本是用户可编辑的、带修改跟踪migrate_retired_personas、was_unmodified——用户改写了 Fizz 的措辞不能因此删掉循环守卫。在welcomeKickoff.ts文案里修循环。被否决治标不治本。任何两个互相 且无事可报的 Agent 都会触发同样的规则冲突。可用但未选择团队指令Team Instructions。TeamRecord.instructions被端到端接通teams.rs →PromptContext.team_instructions→[Team Instructions]pool.rs且对 Welcome Team 是None。它是 kickoff 专属礼仪的自然归宿也是若基础提示词修复被证明对自我介绍场景太弱时的正确位置——但它只覆盖这一个团队所以是补充而非替代 §2。相关事件与结论限流事件。一个 Welcome Agent 在几秒内产出了 42KB 的 rate-limited: quota exceeded 重试日志2026-07-17远程 relayonboarding.communities.buzz.xyz。对配额的紧重试循环会让会话内每一次其他发送也失败——包括 kickoff 的发送即 §3 静默路径之一。值得单独审视 buzz-acp 的发布退避。最初怀疑是 §2 循环在烧配额§2 修复后若再复发则是独立的重试 bug。为什么是 Codex 而不是 Claude Code。已排除提示词内容各运行时一致——[Workspace][Base][System][Team Instructions][Agent Memory][Channel Canvas]pool.rs只有投递不同且没有任何路径省略规则 1、各运行时配置args、env、权限处理——没有一个添加或移除循环守卫、persona 内容。剩余假说字面合规——Codex 把 MUST publish a reply 读成绝对的Claude Code 运用判断并悄悄违反了规则 1而那次违规正是阻止循环的唯一原因。若如此循环在每个运行时都是潜伏的Claude Code 的好行为只是运气。这就是为什么 §2 把结构性断路器留在 backlog 而不是信任散文。阅读路线图想深入源码的读者可以按此顺序跟进welcomeKickoff.ts —— 全文核心marker 常量WELCOME_KICKOFF_OPENER_MARKER/CLOSER_MARKER/PROVIDER_MARKER、failedAfterKickoff、classifyWelcomeKickoffResolution、sendWelcomeKickoffCloser、kickoffResolved闩锁、mergeKickoffEvents开场白线程子树合流以及TEAMMATE_INTRO_BACKSTOP_MS的完整设计注释。useWelcomeKickoffStage.ts —— 舞台五态机hidden/active/timed-out/exiting/done与WELCOME_KICKOFF_STAGE_TIMEOUT_MS。base_prompt.md —— §2 修复后的Communication Patterns全节。useThreadReplies.ts 与 hooks.ts —— §4 的 thread-replies 缓存与 39005 处理。threading.ts ——getThreadReference/buildReplyTags的 e-tag 语义。config.rs 与 lib.rs ——multiple_event_handling、ignore_self、is_owner_control_command、is_owner_or_sibling。这份文档的价值在于它示范了一种编排工程方法先给每一个用户可见的输出找到它的事实来源没有事实来源的输出要么等待事实要么在文案层面承认自己是猜测。对 Buzz 而言这意味着开场白/收场白的 marker 幂等体系、事实驱动的分类函数以及把提示词从必须说话改写为必须诚实——而这三者现在都能在仓库源码中逐一对照。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考