先启动 Gateway
像先把整栋楼通电。柜台有人之前,后台得先活着。
Web 导读
先启动 gateway,再打开 WebChat 应用(macOS/iOS)或 Control UI 的聊天标签页。注意即使在本机环回地址,也必须配置有效的 gateway auth path(默认是 shared-secret),否则连不上。最容易搞错的是:WebChat 的回复路由是确定性的——同一会话的回复永远回到 WebChat,不会跑到其他 channel。
先讲这一页到底在解决什么
先启动 gateway,再打开 WebChat 应用(macOS/iOS)或 Control UI 的聊天标签页。注意即使在本机环回地址,也必须配置有效的 gateway auth path(默认是 shared-secret),否则连不上。最容易搞错的是:WebChat 的回复路由是确定性的——同一会话的回复永远回到 WebChat,不会跑到其他 channel。
第一站
官方开头讲得很直接:它是 native chat UI,直接走 Gateway WebSocket,不内嵌浏览器,也不用另起本地静态服务器。
WebChat 不是楼外另搭的小棚子,它就在 Gateway 这栋楼里。
它不是先过浏览器壳子再绕一圈,而是直接连到 WebSocket 这根主线。
官方说 deterministic routing,翻成人话就是:你从 WebChat 这个柜台说话,回信也会回这个柜台,不会乱跑到别的通道。
WebChat 是 Gateway 自带的聊天前台,不是外接聊天平台。
第二站
官方 quick start 很短,因为这个前台本来就不想多绕弯。
像先把整栋楼通电。柜台有人之前,后台得先活着。
像走到聊天柜台前坐下。你可以用 macOS / iOS app,也可以用 Control UI 的 chat 标签页。
哪怕在 loopback,本页也提醒你要有 Gateway auth。柜台就在楼里,不代表谁都能直接坐下。
先开楼,再坐到柜台前,再出示门票。
第三站
官方在 behavior 里提了三个关键词:chat.history、chat.send、chat.inject。这三个特别值得记住。
chat.history像柜台阿姨帮你把聊天记录本翻出来,但太大的页会被裁掉一点,免得本子重得砸桌子。
chat.send像你真的把一张问题纸条交到后台,请 agent 去跑一轮正式处理。
chat.inject像工作人员直接往聊天本里塞一张便签,不重新叫 agent 出来开工。
官方说大块内容会被截短或替换成提示。翻成人话就是:为了让前台稳定,太重的旧记录不会原样全搬过来。
第四站
这一段很像真实使用体验说明。官方明确说,abort 过的运行,前台可能还会保留部分已经吐出来的助手文本。
像工作人员刚说到一半你就喊停,但前面那半句你已经听到了,当然不会凭空消失。
如果 Gateway 已经缓冲到一部分输出,它也可能把这半段记进聊天本里,并标记“这是被中止的”。
历史总是从 Gateway 拿,不靠 WebChat 自己偷偷盯本地文件。
你喊停以后,已经飘出来的字可能还留着,因为那是现场真实发生过的半句话。
第五站
Control UI 里的 Tools 面板有两个视图。官方写这段,其实是在提醒你别把“目录里有”误会成“此刻就能用”。
像问“我现在坐的这张桌子上,此刻能摸到哪些工具”。它跟 session 紧紧绑定。
像看总仓库的目录、开关和规则,不代表全都已经摆在你眼前。
同一个 agent,不同 session 也像换了另一张桌子,手边工具可能不一样。
“能配置” 和 “现在能用” 不是一回事。
第六站
官方这句很重要:远程模式下,WebChat 还是通过 SSH / Tailscale 把 Gateway WebSocket 接过来。你不需要再单独跑一个 WebChat server。
像把柜台和你之间修一条安全通道,让你在远处也能坐过来聊天。
像不用为了一个前台,再造一栋小楼。它还是吃 Gateway 这栋楼的电和线。
不管本地还是远程,端点和认证规则仍然都看 Gateway 那边怎么设。
远程 WebChat 只是把柜台搬远,不是再额外搭后台。
最后总结
WebChat 就是一个直接连 Gateway 的聊天柜台:翻记录、递消息、塞便签都在同一套机房规则里完成,远程时也只是把这张柜台通过安全通道搬到你面前。
如果你下一页只想继续看一页,我建议回头看 /gateway/index 或继续看 /web/tui。前者讲后台机房,后者讲另一种前台形态。