14 个 bot 的办公室做成网页，Grok Bot Pages 把产出从聊天里捞出来

Akshay 在 X 上演示了 Grok Bot 的 Pages 功能：bot 可以把工作发布成可访问的页面，不必留在聊天记录里。原帖给了三个例子：给 14 个 bot 组成的组织做一个 live HQ office，一个自定义分析面板，还有互动学习指南。视频在下面。

这三个例子里，最直观的是 14 bot 的 HQ。聊天窗口适合追问和试错，不适合当作工作产物的陈列架。bot 一多，输出散在对话流里，回看、分享、比较都费劲。Pages 把结果放到一个 URL 下，至少解决了“东西在哪”的问题。对没有开发背景的读者，可以把它理解成 bot 的发布页：bot 干活，页面承载结果。

但“live”不等于实时协作。有网友问页面是自动更新还是得让 bot 刷新，Akshay 回复说，他建了一个 routine，每小时抓取所有更新并更新页面。也就是说，页面刷新频率是小时级，不是每次写入都推送到前端。另有网友追问，14 个 bot 同时更新 HQ 时怎么处理状态冲突，页面支持并发写还是 last bot wins。这个问题很关键，但原帖没有展开回答。把多 bot 协作塞进一个页面，展示层容易做，状态一致性不容易做。

成本也是回复区里的问题。有人问 18 个 bot 每月花多少钱，和人类相比是否划算。原帖没有给数字。单看素材，无法判断性价比，因为成本取决于模型调用量、任务频率和 routine 的复杂度。页面本身不产生答案，它只是把 bot 的产出摆出来。

Akshay 还展示了自定义分析面板和互动学习指南。前者适合把指标集中看，后者适合把学习材料做成可交互页面。两个方向都指向同一件事：bot 的输出不该只服务一次对话，它可以沉淀成可复用的页面。有网友说，给 agent 做 UI 对管理有没有帮助，他自己多数时间待在终端，但能理解 UI 对别人有价值。这个反馈比“酷”更实际。终端用户和页面用户不是同一批人。

回复区还有一条视频反应：

页面能解决展示，解决不了协作里的冲突和成本。后两个问题在回复里被提出来，帖子没有给出完整答案。如果要评估 Grok Bot Pages，先看你的 bot 产出是否需要被反复查看和分享，再看更新频率能不能接受小时级。两个条件都成立，页面有价值；只想要实时协作，另找工具。

原帖：Akshay 的 X 帖子