Grok Bot 的发布页很会抓人：一支常驻 Agent 团队，各自有电脑，会互相发消息，还能 24 小时干活。看到这里，我脑子里冒出的却是一个很扫兴的问题：东西呢？
八个 Bot 在群聊里分工、复述进度，看起来很忙。页面没做出来、文件找不到、外部动作没人敢确认，这支“团队”仍然只是八个聊天窗口。Grok Bot 值得看的地方，是它把多 Agent 协作接到了云电脑、应用和 Routine；也正因为接了出去，所有权和权限问题躲不过去了。
先别看回复，去找它留下的东西
API 只允许模型做接口已经定义好的事，网页却到处是没封装的按钮、弹窗和表单。Grok Bot 让 Bot 进入应用、收件箱和网站，云电脑在用户离开后也能继续。研究资料、生成文件、打开页面、提交动作，第一次有机会落在同一个工作现场里。
这只是让 Bot 够得着更多地方。浏览器打开了页面，不代表它看懂当前状态；鼠标点下去，不代表后端已经接受；登录会话还有效，也不表示所有 Bot 都该用。Computer Use 填上了接口空白，同时把网页改版、弹窗和重复提交一起带了进来。
所以我先找产物。一个能玩的 HTML 页面、目录里的文件、应用里的草稿，都比“任务已完成”四个字可靠。xAI 在 9 月 1 日给 HTML 文件加了预览和源码入口。功能不大，却很说明问题：Bot 说自己做了页面，用户终于可以当场打开，而不是听它汇报。
对外部动作还要追问结果证据。发消息要有发送记录，创建日程要有事件链接，上传文件要能在目标服务中找到。Agent 自己生成的总结属于声明，不属于独立证据。
给 Bot 起职位名，解决不了交接
官方介绍里，多个 Bot 能并行工作、互相发消息，还能放进一个群聊。再配上“chief of staff”“研究员”“制作人”这些名字，一张 Agent 组织架构图很快就有了。可名字不会替你处理版本冲突。
研究 Bot 和页面 Bot 同时改一份素材，谁的版本算数？谁能发出去？谁对最终页面负责？这些问题没有答案，并行只会更快地制造覆盖。那个负责管理的 Bot 如果只会收集“我完成了”的汇报，也没有省掉人的协调工作。
靠谱的交接应该带着对象走。研究 Bot 交出来源列表和固定版本的摘要，制作 Bot 交出页面文件，复核 Bot 直接标问题位置。少写一段“接下来请你……”，多交一个有版本的文件。某个 Bot 掉线后，剩下的 Bot 才不用重猜整段历史。
xAI 表示 Bot 可以在同一账户或项目中保持对齐。这句话需要谨慎理解。共享上下文有利于协作，也意味着错误信息和过宽权限可能横向传播。适合共享的是项目事实与工件，不该默认共享的是每个连接的全部会话和授权。产品界面如果看不出 Bot 当前使用哪个账户、目录和连接，用户就很难判断一次跨 Bot 行动是否越界。
Routine 最容易记住偶然步骤
Routine 是 Grok Bot 里另一个容易让人兴奋的功能：做一遍给 Bot 看，它记住流程，下次自己来。变更记录还显示，Routine 可以按小时、间隔、每天或 webhook 事件启动。
示范学习降低了配置门槛，但它容易把偶然步骤固化成规则。用户演示时跳过登录，是因为会话刚好有效；某个页面按钮的位置只适用于当前布局；手工检查了一个异常，却没有说出判断依据。Bot 保存了动作序列，不一定保存了动作成立的前提。
我宁愿把 Routine 当一段需要维护的程序。它得说明输入从哪里来、什么条件下启动、结果写到哪里、什么时候停。Webhook 可能重复送达，间隔触发要知道从哪个时刻起算，运行中又来一条消息也得决定排队还是合并。只写“每天跑一次”远远不够。
xAI 9 月 1 日的变更记录说明，小时、间隔和每日 Routine 从创建时刻计算；更早的记录说明，Bot 在 Routine 运行时收到消息，会在之后再运行一次。两个细节放在一起看，就知道“每天跑”并不是完整定义。用户还需要检查时区、并发和补跑行为，否则一次普通追问也可能改变执行次数。
“你的团队想继续”不是有效审批
Grok Bot 发布页说，Bot 只在需要批准时回来找用户。8 月底的变更记录里还能看到购买金额确认、计算机权限和企业动作记录。方向没问题，难点在于批准谁。
审批的难点仍然是范围。允许一个 Bot 在一台计算机上操作，不应等价于允许所有 Bot 使用同一登录会话；批准本次购买，也不应扩展成此后同类商品自动付款。多个 Bot 能互相派活时，还要显示动作最初由谁提出、经过谁转交、最终谁执行。
一张能用的审批卡，至少得写清发起 Bot、实际执行者、目标应用和将要改变的对象，还要说明这次批准会不会变成长期规则。只弹一句“你的团队想继续”，用户根本不知道自己在放行什么。
隐私模式也不能只看名称。官方变更记录说 Privacy Mode 会让一段对话在不应存储时不进入 Bot 的计算机。验证时仍要检查附件、生成文件、浏览器历史和其他 Bot 的线程是否同步清理。对话不落盘和外部动作不发生，是两件事。
我更想看它做一个能玩的东西
官方案例里有销售、运营、招聘和工程协作。这些场景好算节省了多少时间，却不太能让我感受到“多 Agent 团队”到底新在哪里。我更想让它们一起做一个能打开、能点、能玩的东西。
可以给一组 Bot 一个公开主题：有人找一手资料，有人定信息结构，有人做互动页面，最后一个负责点开链接、缩到手机宽度检查。全程不用私人邮箱，不碰支付，也不借真实工作资料。最后网页好不好玩，一眼就知道；谁把谁的文件覆盖了，也藏不住。
这个试验会逼 Bot 面对文件、浏览器和预览。中间交接丢没丢东西，失败后能不能接着做，管理 Bot 有没有减少协调，都能从成品倒查，不必相信一串自评。
页面做完以后，还可以加一条可逆 Routine：每天从公开源更新一个数字。跑几次，改一次规则，再把它停掉。历史版本、实际触发时间和停止后的下一轮都查得到，“常驻”才不会变成黑箱。
作品出来以后，别急着听总结
验收没必要问它像不像同事。看工件能不能打开，抽两次交接有没有丢要求，再确认运行、审批和外部结果能不能从同一处追查。取消 Routine、删除 Bot 或撤销计算机权限后，等到下一个触发时间，看它是否真的安静下来。
还要测失败恢复。故意让网页失效、撤销连接、关闭本地计算机或制造同名文件，观察 Bot 会停下来说明阻塞，还是偷偷换目标继续。最糟糕的情况是每个 Bot 都汇报成功，最终工件却不存在或无法使用。
云电脑、多 Agent 消息、Routine 和审批拼在一起，Grok Bot 的确比多开几个聊天窗口走得远。代价是状态变多了：谁在做、用什么身份、改了哪个对象、下次何时再做。要是这些问题还得翻遍聊天记录，Bot 再多也只是热闹。先把作品交出来，再谈团队感。
引用信息
- 作者：邓明瑞 / 纯粹（Chuncui）
- 主题：常驻多 Agent 的协作和权限模型
- 核心结论：Grok Bot 是否像团队，要看真实工件、Bot 间交接和停止行为，不能看角色数量。
- 永久链接：https://blog.chuncui.icu/2026/09/23/grok-bot-always-on-agent-team/