开发者分享Grok BotAI助手初步使用体验

Grok Bot不需要用户管理多个对话线程，而是让用户管理多个带名称、拟人化的智能体。这个设计思路大致合理：相当于雇佣一队可以相互沟通的专家完成工作。

但这个设计会带来一个问题：用户无法在单个智能体上同时处理多任务。如果给智能体分配一个耗时很长的大任务，用户既不想中途打断它，目前也找不到给消息排队的功能。

虽然 technically 每个消息气泡都有创建新对话线程的按钮，但这个按钮被刻意隐藏，官方似乎并不推荐用户使用。

我习惯用对话线程给不同任务划分独立上下文，避免不同内容互相干扰。但Grok Bot的每个智能体只对应一个长期运行的线程，没有明确的方式拆分、压缩不同任务。如果处理敏感数据，我只能复制同一个智能体，手动给敏感任务划分独立上下文。

目前我不确定，多数用户会更喜欢Jarvis风格、管理多个线程和项目的全能单智能体，还是希望搭建管理多个互相协作的独立智能体。两种路线各有取舍，最终可能不同用户群体需要不同的设计模式。

Grok Bot的智能体本身能力不错，动态表现超出预期。它响应速度快，处理长任务时会像iMessage一样实时更新进度，还能自行调整配置，手动修改配置后也能做出合适的反应。

Grok Bot隐藏了AI的思考步骤和工具调用，这一点比较出人意料。包括我在Notion开发的Notion Agent在内，几乎所有其他AI智能体都会展示这些内容。

我们去年做Notion Agent时，也曾尝试移除这些步骤简化界面，但用户要求加回来。一方面这些内容能充当加载指示器，观看AI工作也很有趣；另一方面用户可以通过这些内容发现AI偏离方向，及时介入暂停或调整方向。

不过过去一年模型的速度和质量都有提升，这两点需求的重要性已经降低，因此隐藏底层运行信息或许是可行的。Grok Bot本身也会发送任务中途的进度更新，这些更新应该都来自Grok 4.6。

新建包含多个智能体的聊天这个设计很不错，类似频道、项目或工作空间的形态。但目前智能体还不够智能，经常会陷入互相对话的循环，最后才停止，或许可以通过提示词优化解决这个问题。

让智能体同时在云服务器、本地设备和Cursor云编程会话中并行完成任务，使用体验很好。整个系统运行稳定，给智能体分配各种趣味任务都没有出现大问题。

将技能、MCP、连接器和其他复杂工具整合统一为「插件」概念，这个设计方向是对的，前沿领域的开发者大多都得出了相同的结论。

不提供模型选择功能感觉很奇怪，这只是因为我习惯在其他编程工具里给每个任务调整模型和运算量。推测Grok Bot应该在后台自动完成模型路由。

将模型路由、思考令牌和工具调用都设置为不透明状态，使用这款应用时用户必须完全交给模型主导。长期来看这或许是对的方向，但短期使用会感到不习惯，毕竟用户交出了控制权。

Grok Bot的界面很好看，移动应用体验也不错，Cursor的移动应用处理代码会话也很舒服，整体使用感受很流畅。设计团队把视觉打磨和细节都做得很好，智能体头像的动效设计是顶级水平。

现在这类工具已经越来越多，很多公司甚至开源项目都在做，很难说用户为什么会选择每月花200美元订阅这款而非其他。短期内用户选择可能会偏向体验偏好、群体认同或者代币补贴，直到功能层面出现足够大的差异点。

我做了一个实验，让我的Grok Bot智能体改用Notion数据库作为记忆层。智能体没有提出问题，还在我的记忆数据库里创建了大约20到30个页面。

生成的内容看起来很多很乱，不清楚这对效果会有什么影响，但智能体能适配我的使用需求，这一点很棒。我也无法确定智能体在后台是否真的正确使用了数据库，整个系统的透明度很低。

对于一款主打协调多个机器人工作的应用来说，Grok Bot这个名字有点奇怪。

我猜测大多数用户日常生活中其实没有太多内容需要自动化，我很好奇这款产品的用户留存数据。