唤醒机制

编码 CLI 通常是「处理完一个回合就停下、等待下一条输入」的模式。这带来一个问题：即便另一个 agent 给它发了消息、或它依赖的产物刚被写好，停下的它也不会自己醒来。swarmx 用一套唤醒机制解决这一点——无需轮询，也不会因互相等待而死锁。

两条唤醒路径

回合结束时检查

每当一个 agent 结束一个回合，swarmx 会做一次检查：是否有未读的唤醒信号？

• 有——就让它续跑一个回合，去读取消息与相关黑板键并作出回应。
• 没有——它正常停止。

这条路径解决「正要停下的 agent」的问题。

写入即唤醒

对「已经停下的 agent」，等它下一次自然停止再检查就太慢了。为此，当某个黑板键被写入时，服务端会立即处理所有声明依赖该键的 agent：既向它的收件箱投递一条唤醒信号（作为可靠的底账），又直接把它「叫醒」当场续跑一个回合。写入者本身不会被自己的写入唤醒；而你在编辑器里对黑板文件的外部改动，会唤醒所有订阅者。

此外，用户或系统给一个在线 agent 直接发消息，也会即时唤醒它。

各引擎如何被唤醒

唤醒的「叫醒」动作因引擎的运行方式而异，但效果一致：

引擎	唤醒方式
claude	回合末检查钩子；即时唤醒通过终端注入
codex	回合末检查钩子（需 0.132+，见下）；即时唤醒通过终端注入
opencode	空闲事件触发的插件；即时唤醒通过其控制接口
reasonix	回合结束事件驱动下一回合；空闲时由服务端直接提交
zulu	回合结束事件驱动下一回合；空闲时由服务端直接提交

关于 codex 的自动唤醒，参见引擎参考与常见问题。

防失控与防卡死

• 限流：唤醒带滑动窗口限流（默认单位时间内至多若干次），防止 agent 陷入自我唤醒的死循环。
• 失败不静默：如果一个 worker 在写出它承诺的交接信号之前就退出了，服务端会替它合成一个「出错」信号写入黑板，让下游 agent 及时感知上游失败、走失败分支，而不是永远空等。

这套机制让「停—等」式的 CLI 也能像一支随时响应的团队那样协作：需要它时它就醒来，没事时就安静停着，不空转、不空等。