阅读目录 · 10 个章节
Grok Bot 深度研究
把持续职责交给一支 Bot 团队：
协作怎样发生，委派如何闭环。
核心判断
Grok Bot 把“长期负责一件事的 Bot”放在产品中心。它的价值取决于能替用户承担多少协调工作，以及完成结果所需的检查和返工成本。
产品已把持久环境、角色上下文、异步消息、业务工具和周期触发组合起来。多个 Bot 可以互相交接，具备小型协作团队的产品结构。不过，公开资料还不能证明：增加 Bot 数量会稳定提高端到端质量，也不能证明它已经能可靠替代一个业务岗位。官方架构概览 · 协作说明
本报告的三个判断：
- Agent / swarm 线：长期角色与临时执行可以分层。 具名 Bot 承接职责、上下文和跟进，必要时委派给 Cloud Agents。这个分层值得关注；调度、冲突处理和失败恢复的质量仍需实测。团队架构
- 产品线：创建同事、教会流程、处理例外，构成了一套清晰的委派体验。 它使“下次继续找谁”容易理解。身份、记忆与自治程度仍容易被用户高估；“有名字”尤其不代表拥有独立权限。
- 两线合并：真正需要验证的是委派是否闭环。 一项工作需要明确负责人、可靠状态、可检查结果和可恢复的审批点。用户反馈里的惊喜与失望，常常发生在这几处连接上，而非一次回答是否聪明。
证据强度：产品结构清楚；个人价值已有具体自述；长期可靠性、swarm 净收益和普遍 ROI 尚未证实。 本研究没有登录 Grok Bot 做任务实测，所有可靠性描述均保留其来源身份。
两条研究线，在同一项工作里汇合
Agent / swarm
角色怎样分工
状态怎样接续
权限怎样约束行动
产品与用户
用户怎样开始委派
怎样信任和接管
怎样判断值得付费
一项可验收、可恢复的委派负责人 · 真实状态 · 交付证据 · 权限 · 成本
对象与时间边界
本报告讨论的是 2026-08-11 发布、通过桌面与移动端使用的 Grok Bot。它可在业务软件中执行工作。X 上的公开 @grok 回复机器人不纳入用户样本，Grok 聊天应用的记忆、写作或图像争议也不移植到本产品。发布说明
三种容易混淆的“多 Agent”
| 对象 | 对应的工作单元 | 本报告如何使用 |
|---|---|---|
| Grok Bot | 具名、持续存在的职责承担者，可群聊和交接 | 主研究对象 |
| Grok Build Workflows | 将一项复杂任务拆成多个阶段与并行执行者，最终汇总 | 用于区分工作流编排；其并行预算不能当作 Bot 群聊规模 |
| Grok multi-agent API | 多个推理 Agent 围绕一次问题协作，由 leader 输出 | 用于区分推理层；不能据此断言 Bot 后台固定使用同一结构 |
Grok Build 的工作流文档描述显式阶段与结果校验；multi-agent API 文档描述 leader 合成与 4 / 16 Agent 配置。它们都不能替代对 Grok Bot 实际运行机制的证明。Grok Build Workflows · Multi-agent API
影响判断的产品节点
| 日期 | 公开事件 | 对研究的意义 |
|---|---|---|
| 08-11 | 发布 Beta | 当前外部观察窗口很短，早期体验不能当作长期稳定性证据 |
| 08-26 | 扩展到更多 Grok、Cursor 订阅 | 降低试用门槛，也让额度与成本问题进入更广泛讨论 |
| 08-29 | 接入 X connector，提供起始 API credits | X 成为业务数据入口之一；不等同公开回复机器人 |
| 09-03 | Enterprise 发布，公开设计文章 | 企业控制与“持续 Agent”的设计意图变得可查 |
| 09-04 | 发布采购案例 | 出现可拆解的业务结果叙事，但仍是厂商内部案例 |
来源：发布 · 订阅扩围 · X 接入 · Enterprise · 设计文章 · 采购案例
文档存在版本差异。 发布页已更新过权益；部分 FAQ / Get started 仍列较窄的套餐。当前访问与计费以文档自己指向的 Plans and billing 为准。本文不从今日的发布页反推首发套餐，也不采用第三方的“已结束 Beta”说法。
多方观点：谁在什么工作里感受到价值
以下是目的性选取的 12 个观点记录，来自 6 个 Reddit 讨论、同一个 HN 发布讨论和 3 篇自述实测博客。它们覆盖业务经营者、创作者、工具供应商、内测者及未使用产品的讨论者。不是访谈，不是随机抽样，也没有可据以计算满意率的分母。
“自述实测”表示作者称自己用过，并提供了具体任务；不表示本研究独立复现了结果。“有利益关联”单独标注。Reddit 日期取可见搜索索引中的绝对日期，缓存相对时间不作为依据。
显示 12 / 12 条观点
pavel_lishin
观点评论Adrig
观点评论James Swierczewski
自述短测为自己的网站做链接合作外联，保持“仅草稿”边界。
对话式设置很快形成联系人、邮件草稿与跟踪表计划。
一度生成用户看不到的文件，后改在对话中展示；未验证长期运行。
阅读 James Swierczewski 的原始讨论Ok-Bug7181
自述业务使用六个 Bot 分担 BD、寻源与质检。
定制跟进能处理真实回复，跨工具工作无需等待专门集成。
称设定重置、Chrome 崩溃，首日用掉周额度 42%；所感知并发不是官方上限。
阅读 Ok-Bug7181 的原始讨论BoddhaFace
自述使用SentiSense Team
有利益关联 · 自测数据 API 供应商；使用自家数据技能，具有商业关联。
试用中成功安装技能并得到灵活的数据输出。
集成和额度仍有摩擦；空 API 错误由其自身修复，不能归咎于 Bot。
阅读 SentiSense Team 的原始讨论Bubbly_Sort849
自述业务使用经纪业务试用不足一周，采用多 Bot 与运营协调角色。
尝试把真实业务持续交给团队处理，提供了具体失效环节。
报告审批过期后遗忘、漏跑 Routine、重复发送、覆盖共享 Sheet，以及几天触限；均未独立复现。
阅读 Bubbly_Sort849 的原始讨论dizzygoldfish
自述使用Dragos Roua
自述短测约 24 小时测试，设置移动端、网页和分析三个 Bot。
认可设置简单、角色能交流；认为已有能力被组合成容易理解的产品。
“高度自主”是短测印象，无成功率或对照；本文不采信其过期套餐信息。
阅读 Dragos Roua 的原始讨论SaschaFromWhaaat_ai
同类产品从业者自述开发 Agent 团队产品；基于文档提出观点。
认可通过示范教流程的体验。
关注同一用户下共享登录和权限；这是架构评论，不是攻击实证或失败用户证言。
阅读 SaschaFromWhaaat_ai 的原始讨论DeCiel
自述使用从分歧中读出什么
第一，上手体验和长期维护是两个不同的评价对象。 James 与 Dragos 的积极体验主要来自短时设置和初次协作。复杂业务使用者 Bubbly_Sort849 则关注数天后的状态丢失、重试和共享结果。二者可以同时成立。短测证明“能开始”，不能直接证明“会一直正确地继续”。
第二，多 Bot 的价值与质量瓶颈发生在不同层。 专业分工、自动跟进能提升用户的掌控感；写作质量、浏览器稳定性与外部系统状态仍会拖累成果。为任务增加一个 reviewer Bot，也不能直接假定它发现的错误多于它制造的成本。
第三，认可产品与嫌贵并不冲突。 额度抱怨出现在正面和混合反馈中。对使用者来说，判断对象是一个星期能完成多少有用工作；消息次数、角色个数和单个模型价格都只是间接指标。
第四，提出架构风险的人不一定是失败用户。 Sascha 是同类产品从业者，Adrig 未自述使用，pavel_lishin 提出的是外部性疑问。其问题值得检验，但不能写成已发生的安全事件或客户流失。
一个必要的反证修正： HN 采购案例中，jjcm 后续说明先联系少数供应商，再由本人要求扩大范围。把约 40 家全部归因于 Bot 自主决定，会夸大自治程度。讨论中也有人认为广泛询价是正常商业流程；外部性问题应围绕询价质量、真实性和对方处理成本，而非仅以数量判断。HN 原始讨论及补充
Agent / swarm：持续协作的结构与边界
这里将 swarm 作为分析术语：多个执行者在共同目标下交换信息、分工并反馈。它可以是集中协调，也可以局部自治。本报告不把“多 Agent”自动等同于去中心化、自组织或具有涌现优势的系统。
角色、状态与权限需要分开看
| 层次 | 文档支持的机制 | 它尚不能证明什么 |
|---|---|---|
| 职责 | Bot 有名称、工作描述、对话和逐步积累的角色上下文 | 一个角色就能稳定承担整项岗位责任 |
| 工作记忆 | 保留偏好、重要事实与工作摘要 | 记忆完整、准确，或实时反映业务真相 |
| 操作环境 | 每用户一个持久云电脑；Bot 分别使用屏幕 | 每 Bot 独立 VM、凭证或数据隔离 |
| 协作 | 异步消息唤醒接收者；群聊可见交接 | 消息恰好一次送达、任务去重或全局一致状态 |
| 主动性 | 日程或特定事件触发 Routine | 模型持续无间断推理，或永远无需人类处理异常 |
| 产物 | 文件与可检查的结果回到对话，工作区支持共享 | 多人并写、版本冲突与交付验收已自动解决 |
来源：Bot 的职责与记忆 · 电脑与应用 · 消息与协作 · Skills 与 Routines · 文件与结果
角色可以不同，信任边界仍然共享
同一用户的 Grok Bot 云电脑
研究 Bot角色上下文 · 屏幕
业务 Bot角色上下文 · 屏幕
协调 Bot角色上下文 · 屏幕
可委派 Cursor Cloud Agents另有执行电脑，适用 Cloud Agent 控制；属于另一执行层
共享电脑：协作捷径，也是一项边界选择
技术文档明确：一个用户的所有 Bot 共享文件、浏览器会话、登录状态及命令行凭证；独立屏幕只是不同操作面。 用户之间通过 Firecracker microVM 隔离；同一用户内部不能以 Bot 名称划出安全边界。电脑与应用 · 安全 FAQ
由此可推论：共享环境降低了重复登录和传递文件的成本，却把多个角色放进同一信任域。即使“研究员 Bot”只被口头要求查网页，电脑上仍可能存在用户为“财务 Bot”建立的会话。角色说明与实际可达权限之间因此存在距离。
这也影响竞争定位。对于一个人、同一信任域内的协作，共享是一种合理的便利取舍；对于跨客户、跨机密等级的任务，把更多 Bot 放到同一账号下不会自然产生更细的隔离。文档建议需要独立电脑与凭证的工作使用独立用户。这是架构条件，不是本研究做出的安全认证。安全 FAQ
已存在的三种协同形态
专家交接。 两个角色分别负责上游材料和下游结果，异步通信把等待从用户身上移走。官方支持 Bot 间消息、群聊与明确下一位 owner；群聊支持 2–6 个 Bot，Bot 向群组交接当前为文本形式。协作说明
协调者带专家。 一个 chief of staff 接收用户请求、路由给专职 Bot、汇集需要判断的事项。这是发布页展示的组织模式。合理的使用前提是协调者确实减少了人的路由次数，而非给每项工作增加一轮同义转述。发布说明
持久管理者带临时执行者。 Bot 可以把代码任务交给另有电脑的 Cursor Cloud Agents，受 Cloud Agent 控制约束。这与同一用户的 Bot 共享电脑是不同层级，不能混画成一个隔离模型。团队架构
研究推论：第三种最适合解释长期职责与执行规模如何解耦。稳定角色保留工作标准与优先级，任务型 worker 承接一次具体执行。它也多了一条需要验收的交接链；若管理者只转发 worker 的“完成”声明，层次增加并未带来质量提升。
持久化不等于一致性，互相聊天不等于编排完成
公开文档说明了角色记忆和共享产物，但未给出任务级状态机、写入锁、去重键、重试协议或一致性保证。因此，Bubbly_Sort849 报告的重复发送与 Sheet 覆盖，应被当作需要复现的失效信号；不能直接推断具体后端用了哪一种错误实现。
从系统设计角度，一条可靠的交接至少需要：任务标识、当前 owner、输入与输出版本、已发生的外部动作、等待条件，以及下一步谁负责。自然语言适合表达意图，但这些状态若只隐含在长对话中，后续执行者就可能重复解释和重复行动。这是本报告建议的验收框架，并非 Grok Bot 已公开承诺的内部协议。
自治控制的可见能力与缺口
官方说明 Auto Review 使用独立模型评估高风险动作，可放行、转人工或拒绝；成员仍可关掉它，尚无组织级锁定。网络白名单是 Enterprise 能力；封禁 connector 并不会自动封禁同一服务的网站。Action Recording 与管理审计日志分开，且前者默认关闭。安全架构
用户授权表达了“允许做什么”；运行控制还需要确保动作对象没有变化、旧审批不会被误用于新版本、失败后不会重复提交。多 Bot 参与时，审批应与任务状态保持一致，尤其要区分“已经执行”与“等待执行”。这解释了为什么一个看似简单的确认卡片，实际上是 swarm 可靠性的关键接口。
另外，官方明确 Bot 使用用户的业务身份，并非独立机器身份；模型由 Cursor 管理选择，没有面向用户的 model picker。身份与安全说明 这意味着不能仅因产品名叫 Grok Bot，就把体验变化直接归因于某个固定 Grok 模型。
产品分析：用户如何学会委派
目标用户与用户故事
以下故事由官方示例与用户经历重构，用于分析用户需求，不是本研究新增的访谈或实测。共同特征是：工作跨多个工具、有可以保留的职责，而且完成标准不止是生成一段文字。
| 角色与触发 | 想交出去的工作 | 对用户有意义的完成 | 应保留的人类判断 |
|---|---|---|---|
| 销售：客户回复了跟进邮件 | 找对应材料，整理上下文，准备下一次沟通 | CRM 和草稿都与最新客户状态一致 | 是否发送、承诺什么、怎样处理敏感客户 |
| 采购：合同临近续约 | 对照支出、使用率和报价，形成可行动建议 | 每个节省机会有来源、机制和下一步 | 外部谈判、购买与合同决定 |
| 小团队负责人：自己离线时工作仍在进行 | 跟踪多个任务，提醒阻塞并汇集结果 | 回来时看到可验收的产物和少量决策 | 改优先级、资源分配、无法自动判定的质量 |
| 内容或产品创作者：跨网站与开发工具协作 | 收集素材、拟稿、实现、交叉检查 | 能编辑和继续使用的成果，而非更多聊天 | 语气、论证、设计标准与发布 |
来源：扩围时的业务故事 · 采购案例 · Ok-Bug7181 的 BD 体验 · Dragos 的三个 Bot
用户需求可以写成一句话：“当这项职责再次产生新工作时，我希望有人继续处理，并把需要我的决定带回来。”这一需求比“帮我回答问题”更接近一种持续服务。
产品把哪些复杂概念藏到了后面
设计文章把产品对象收敛到 Bot、Chat、Prompt、Tool、Artifact 五类。侧栏由 Bot roster 组织；身份与工作状态通过头像呈现，细节按需展开。电脑有状态、预览、接管三个访问层次；对话中可直接出现产物和操作对象。产品设计原文
这些安排的产品含义，可拆成四项推论：
| 设计选择 | 降低的用户负担 | 同时需要防止的误解 |
|---|---|---|
| 以具名 Bot 组织入口 | 不必从历史聊天中找“上次那件工作” | 稳定头像不保证稳定记忆与能力 |
| 以职责描述设置角色 | 用业务语言指定谁负责什么 | 工作描述不自动变成最小权限配置 |
| 将运行细节按需展开 | 不必持续盯着电脑 | 显示“正在工作”不等于结果已经正确 |
| 将产物与操作放回对话 | 减少聊天、文件和业务系统间寻找结果 | 产物可见不等于多人写入受控或可撤销 |
这套 UI 给用户的是“同事关系”的心智模型。它应该帮助用户定位责任，也需要让未完成、等待审批与已经产生外部影响的状态容易区分。若视觉上过早传达“我替你负责到底”，失败后的预期落差会更大。
激活与习惯形成的路径
从第一次交付，到持续委派
- 选一项明确职责先让角色边界可理解
- 完成一次具体工作按需连接工具，检查产物
- 保留规则与偏好修正过程，整理成 Skill
- 设定重复触发Routine 运行，例外交回用户
官方 onboarding 先了解用户使用的工具、建议第一位 teammate，再由用户创建角色并给出具体任务；选择工具本身不会自动连接账号。首次委派应交代结果、来源、限制、产物和复核点；登录需要时再由用户接管。Get started
研究推论：这是一条渐进委派路径。先让用户看到一件工作如何完成，再累积偏好并自动化。激活指标应是“第一次交付可接受结果”，而不只是“建好一个头像”或“创建六个 Bot”。后者可以很快完成，却没有证明任何生产价值。
技能与触发也被分开：Skill 定义怎么做，Routine 定义何时由哪个 Bot 运行；示范学习会生成需要复核的草稿，录制最长十分钟且逐步开放。官方建议先稳定一次任务，再重复运行。Skills 与 Routines
因此，“教一次”更适合被理解为减少流程起草成本。一次演示一般不会包含缺数据、账号过期、重复事件等分支。产品若能引导用户补上这些边界，才有机会把一次顺利演示变成稳定习惯。
分发、留存与收费的逻辑
分发。 订阅扩围把 Grok Bot 放到已有 Grok 与 Cursor 用户面前。当前官方计费页列出付费 Cursor、Teams，以及个人 SuperGrok / X Premium+ 关联入口；具体权益随套餐变化。当前套餐与计费 已有用户跨入新产品的成本可能较低，但这只是分发优势的机制推论，尚无公开转化率可验证。
留存。 随着职责、工作偏好和重复流程积累，用户可能更愿意继续找同一 Bot。值得注意的是，公开分享复制的是配置；复制 Bot 不携带原对话和已学记忆。Bot 管理与分享 因而“分享模板”与“迁移一位熟悉业务的队友”是两项不同产品能力。迁移摩擦可能形成留存，也可能削弱用户信任。
收费。 厂商在 8 月扩围时强调 Bot 的独立用量；当前 Teams 文档则以席位额度说明。计费取决于任务步骤与 token，不能把几条聊天当成几次低成本动作，也不能把包含访问权理解为无限自治运行。扩围说明 · 当前计费规则
从产品经济性看，用户购买的是可持续的工作能力，账单却来自推理与执行过程。两者之间需要可预测的任务预算、异常停止和结果成本解释。DeCiel、BoddhaFace 等人的反馈提示了这个问题，但不足以证明统一的小时成本。
两个案例：把产品承诺放回业务闭环
采购 Bot：从找到线索，到可以作出决定
官方 Haggle Bot 案例把支出、合同和使用数据连在一起，称已发现超过 10 万美元直接节省。权限分为内部研究、需要同意的外部动作及禁止承诺；案例展示了识别闲置 SaaS、准备续约谈判和比较日常采购。这是厂商自报，未给出可独立审计的完整账单、净成本或对照组。 采购案例原文
其研究价值在于责任定义：目标并非“做采购研究”，而是发现有来源、可执行的机会，并推动到决策点。信息缺口会成为下一项工作，而不只是报告最后的建议。
分析这个故事时，应分开三个结果：识别潜在节省、获批采取动作、实际账单下降。它们不能全部归为已实现收益；即使账单下降，也还要扣除软件费、人工复核、切换成本和错误处理。公开案例足以提出价值假设，尚不足以给普通企业一个可复制的收益率。
工程 Bot：长期管理层与任务执行层
产品团队工程师 Lingxi Li 的公开自述描述了专业 Bot 管理 Cloud Agents、用 Notion 保存任务状态、周期检查 PR，以及由运营 Bot 汇集教训。作者宣称同时管理超过 200 个 Cloud Agents。本文读到的是原文的第三方转存，原 X 页面未成功打开；这是内部作者的经验陈述，不是公开并发保证或效率基准。Lingxi 原文转存
这个案例最有价值的结构是把三类状态分开：长期角色知道怎么工作，任务账本知道哪些工作还没完，worker 知道当前这项任务如何执行。评审产物把三者重新连起来。这个结构可以用更少 Agent 验证，无须把“200 个”当作目标。
它也构成一条反证：即使在产品团队的积极案例中，仍需要外部任务数据库、固定检查节奏和反馈规则。具名 Bot 与群聊提供了协作入口；可靠的组织过程仍要围绕业务状态建立。
合并两个案例
采购和工程表面上属于不同业务，但工作闭环相似：持续读取真实系统，识别差异，收集补充证据，推进可逆工作，在不可逆决定前交回判断。可复用的是这个闭环的设计，不能直接迁移的是厂商案例中的规模、收益与自治程度。
竞品比较：各自让用户管理什么
以下比较截至 2026-09-08，以官方文档为依据，比较的是产品对象与协作模式，没有同题实测，不给性能排名。“主要委派对象”是本报告的产品抽象，不是互斥分类。
| 产品 / 具体形态 | 主要委派对象 | 持续性与执行环境 | 多 Agent 如何呈现 | 用户主要验收什么 |
|---|---|---|---|---|
| Grok Bot | 一项长期职责、一组具名 Bot | 每用户共享持久云电脑；角色上下文与 Routine | Bot 间异步消息、群聊，可委派 Cloud Agents | 真实工具里的结果与需要判断的例外 |
| Claude Cowork | 任务、项目 | 当前文档已支持云端持续任务；使用本地文件或浏览器仍依赖 Desktop | 内部拆分和并行子 Agent | 文档、数据、任务成果；中途可调整 |
| Codex cloud | 代码任务、可审阅变更 | 并行的隔离仓库环境 | 多个任务在后台推进，工作系统集成 | Summary、diff、PR |
| Manus | 一项结果，或持续运行的服务 | 任务 Sandbox 加可选 Cloud Computer；后者当下为命令行环境 | Wide Research 拆分并行工作并合成 | 交付结果或持续服务是否达到目标 |
| OpenClaw | Agent 身份、会话与消息渠道 | 自托管 gateway，配置角色、状态和调度 | 多 Agent 路由、后台子任务、结果回传 | 功能结果，以及自己维护的运行配置 |
来源：Grok Bot · Cowork 当前说明 · Codex cloud · Manus Cloud Computer · Manus Wide Research · OpenClaw 多 Agent 路由 · OpenClaw 子任务
相同点：底层能力正趋于重叠
云端运行、工具使用、并行工作和持久上下文，已不能单独作为 Grok Bot 的独有主张。Cowork 当前的云端任务与定时能力尤其说明，旧的“必须开着电脑”对比需要更新；本地依赖仍需单独说明。Cowork
OpenClaw 的 heartbeat 通过周期唤醒执行检查；它也说明“主动”通常来自事件、调度和状态管理，而非模型永远在思考。Heartbeat
差异：长期关系在界面中占据什么位置
Grok Bot 把职责和队友直接摆到用户面前。Cowork 的任务 / 项目、Codex cloud 的变更审阅、Manus 的任务合成、OpenClaw 的可配置 Agent，各自给用户不同的管理抓手。
据此，本报告判断 Grok Bot 的竞争点是把角色配置、运行环境和协调入口整合成低门槛产品。它的优势若成立，应表现为更少的上下文搬运、更低的重复设置成本、更容易接续的职责；而不是简单拥有更多 Bot。
这也不是不可复制的功能壁垒。长期优势需要来自跨周可靠性、可迁移的经验、可核算成本和可信的控制边界。新建 Bot 的体验可以令人印象深刻，长期委派的可信度需要持续交付积累。
按工作选择，而非按模型品牌选择
作为分析性适配判断：持续跨工具职责适合研究 Grok Bot；以文档和项目交付为主可比较 Cowork；围绕代码 diff 与 PR 验收应纳入 Codex cloud；大量同类对象调研可比较 Manus；需要掌握部署、模型与渠道配置时可评估 OpenClaw。每一项都应以自己的代表任务验证，本文没有建立谁普遍优于谁的结论。
两条线合并：委派契约决定团队是否有效
产品用“同事”让职责易懂，agent 系统需要把职责落到实际状态和动作。两者汇合的地方，是一份可以验收的委派契约。 这里的“契约”是本报告提出的设计框架，指人和 Bot 对目标、权限、证据及完成条件的共同约定，不是法律合同。
把“替我负责”拆成可检查的过程
- 委派目标、owner、边界
- 读取事实来源、版本、时效
- 执行与交接状态、动作、下一位 owner
- 检查与审批对象不变，等待可恢复
- 验收结果、证据、总成本
- 反馈修正规则，接续下一轮
下一轮重新读取业务事实；不把上一轮记忆直接当作当前真相。
从产品承诺到可检验条件
| 产品承诺 | 对应的系统要求 | 用户材料揭示的张力 | 应观察的结果 |
|---|---|---|---|
| “它一直记得这项职责” | 持久角色上下文，重要事实能重新读取 | 偏好和任务状态是否随时间漂移 | 同一规则跨次执行的保持率；过期事实被纠正的次数 |
| “它们会自己协调” | 明确 owner、共享状态与可靠交接 | 多个 Bot 是否重复行动或覆盖结果 | 成功交接率、重复动作数、协调者人工介入时间 |
| “只在需要时找你” | 可恢复的等待状态与精确审批对象 | 审批是否成为过期后遗忘的断点 | 等待时长、超时后的恢复率、每项任务打断次数 |
| “工作已经完成” | 产物可见，来源和外部动作可核对 | 文件存在，但用户无法验收 | 可接受交付率、返工时间、实际系统状态差异 |
| “它能持续替你工作” | 预算、重试上限、停止机制 | 认可价值，却无法预测一周用量 | 每项合格结果的总成本，以及无人值守期间失败暴露时间 |
这些要求解释了前文用户材料，仍是待验证假设。不能因某种错误“符合架构风险”，便断定架构一定造成了该错误。
一份具体的委派契约示例
下面是为说明方法而构造的销售场景，不代表 Grok Bot 已内置这些字段或强制检查。
| 字段 | 示例约定 |
|---|---|
| 目标 | 每个工作日整理需要跟进的客户，只交付待审草稿 |
| 责任 | Sales Bot 是唯一负责人；Research Bot 补充证据；Coordinator 汇总异常 |
| 输入 | CRM 当前状态、最新往来邮件、已批准材料；读取时记录时间 |
| 完成 | 每条草稿关联客户与来源，排除已跟进对象，状态写入同一任务表 |
| 权限 | 可读取、检索、拟稿；未经本次批准不得外发或修改客户承诺 |
| 状态 | 同一客户同一轮跟进有唯一任务标识，写入前检查最新版本 |
| 失败与恢复 | 数据不可达即标为阻塞；审批超时保留草稿，恢复时重新核对目标 |
| 预算 | 到达预设费用或重试上限即停，报告已完成与未完成部分 |
如何验证 swarm 是否真的有增益
建议做一次任务级对照，先比较“一个 Bot 端到端”与“一个 owner 加必要专家”，再考虑更大团队。相同任务、输入、授权、验收标准和预算上限；多次执行覆盖正常、缺数据、登录失效、审批延迟与重复事件情境。记录版本与配置，避免把一次模型更新误当架构进步。
至少记录以下指标：
- 合格交付率：达到预先定义验收条件的任务 / 已启动任务。失败与触限不能移出分母。
- 人工负担：设置、指路、检查、审批、返工分别花多少时间；不能只算省掉的点击。
- 协作质量：漏接、重复动作、冲突写入、消息往返及 owner 不清的次数。
- 结果成本：订阅的合理分摊、按量费用、外部工具成本，加人工处理成本，除以合格结果数。
- 边界可靠性：是否越过授权；停止后是否仍有后台动作；恢复时是否重复提交。
- 持续性：跨多个业务周期是否仍使用最新事实，流程是否在环境变化后及时失败并通知。
只有当多 Bot 在可接受质量与权限边界下，减少总人力负担或提高有价值的产出，才能说 swarm 对该类任务有效。更活跃的群聊、更多 token 或更多完成声明都不能单独证明它。
对下一代 Agent 产品的启示
职责应可持续，任务状态应可检查。 用户可以通过自然语言委派，但系统仍需保留明确 owner、输入版本、产物和已发生动作。
可见状态应该帮助决策。 “忙碌”只是一种存在感；用户更需要知道是否阻塞、等待什么、何时必须介入，以及这次批准会产生什么影响。
记忆应可修正、可迁移、可区分来源。 稳定偏好、临时判断与业务系统事实需要不同生命周期。一次成功纠正不应依赖用户反复在群里重申。
协作规模必须与预算和责任一起增长。 新增角色时，应能说明它接走了哪一项工作、增加多少协调负担，以及其失败由谁处理。
外部接收者也应进入价值计算。 大量代理发起的询价、招聘和跟进，可能让发起者更省力，同时增加对方筛选工作。公开材料不足以量化这种影响，但产品应追踪有效响应与最终成果，避免只奖励发出次数。
最终判断是：Grok Bot 展示了一种值得研究的持续团队界面。它能否成为可靠的工作系统，要看委派、状态、证据、权限和成本能否在日常使用中闭合。 现有资料足以看清设计方向，尚不足以宣布“自治组织已经解决”。
方法、分歧与待验证问题
研究方法
先按产品名称核对实体和时间，再沿两条线检索：官方产品 / 技术文档与竞品原始资料；有具体任务描述的早期用户反馈。第二轮针对共享电脑、当前权益、持久记忆、协作失效和竞品时效查找反证。主研究将两条线合并，并复核关键来源。
停止继续扩展搜索的原因是：核心机制和重要文档冲突已能解释，新增大量内容开始重复发布页或同一组案例。没有因为缺少代表性样本而用重复转载补足数量。
本报告保留的主要分歧
| 表面冲突 | 处理方式 |
|---|---|
| “每个 Bot 自有电脑”与“每用户共享电脑” | 以前者为面向用户的简化描述，采用技术文档的用户级隔离解释 |
| 早期用户认为并发只有 1–2 个，文档称可并行 | 保留用户观测，不改写成官方限制；设备状态、版本和负载原因均未复现 |
| “教一次长期运行”与“演示生成草稿” | 区分宣传体验与操作要求；自动化前仍需补齐和验证规则 |
| “已发现节省”与“ROI 已得到证明” | 保留厂商结果口径，不推导普遍净收益 |
| 旧套餐 / 旧本地限制与当前帮助页 | 给出截止日，优先当前指定计费页和具体运行边界 |
尚不能下结论的七件事
- 正式使用数月后的留存、任务成功率和平均人工返工量。公开发布距截止日约四周。
- 多 Bot 相对单 Bot 的净收益；没有同题、同预算、同验收标准的公开对照。
- 记忆召回、冲突合并与迁移保真度；公开能力描述不是 benchmark。
- 所报告失败是否在后续版本修复，是否与某种配置相关。本文没有复现记录。
- 每个合格结果的实际总成本。用户额度百分比对应不同套餐、任务和日期，不能横向平均。
- 独立业务身份、角色级隔离、组织级治理能否满足具体企业要求；文档能力不能替代该企业的部署验证。
- 中文用户与中国本地软件环境的适配。公开反馈以英文为主；补充的中文界面截图能展示使用方式，但不足以说明广泛适配或长期体验。
HN 的多个观点来自同一发布帖，不能当作独立调查渠道。公司员工、早期内测者和售卖相关服务的作者也可能有不同激励。未发现针对这个新产品的代表性用户调查或长期同行评审研究。
报告中的结构图是研究分析示意；标注“用户提供”的图片是本次补充的原始界面截图，拍摄日期据随附说明为 2026-09-08。截图用于观察角色、协作与产物如何呈现，不计入前述 12 条公开观点；群内规则由用户设置，图中事实、模拟数据和附件功能未经本研究独立验证。截图来源与逐图说明
来源索引
所有重要功能事实与用户经历都在附近提供原始链接。下面的索引保留机构 / 作者、日期及访问说明；“官方”表示产品自述来源，并不自动等于经过独立验证。
显示 38 / 38 个来源
没有匹配的来源。请更换关键词或选择全部来源。
- Introducing Grok Bot
产品对象、角色与发布
- Grok Bot: more plans
分发、早期业务故事
- Grok Bot and X
X connector
- Grok Bot for Enterprise
企业版时间边界
- Designing Grok Bot
五类对象、roster、状态与电脑入口
- Grok Bot procurement case
采购职责与权限、厂商节省声明
- Overview
架构概览
- Get started
创建角色与首次委派
- Chat and collaboration
异步消息、群组与交接
- Bots
角色记忆、复制与分享
- Computer and apps
共享环境、屏幕与凭证
- Skills, routines and automations
技能、示范学习、触发与重复运行
- Files and results
共享产物与验收
- Approvals, security and privacy
审批与授权原则
- Security
Auto Review、网络、审计与模型选择
- Security FAQ
用户级隔离、角色身份与权限
- Teams and enterprises
Cloud Agent 委派与企业控制
- Plans and billing
当前访问、额度与计费
- Grok Build Workflows
区分任务工作流与 Bot 团队
- Multi-agent text API
leader 与推理 Agent 配置
- Grok Bot 发布讨论与补充
采购自述、交互评论、外部性；原楼补充修正自治程度
- James Swierczewski 的 Grok Bot 体验与观点
使用背景、体验评价与限制；具体观点见「多方观点」章节
- Ok-Bug7181 的 Grok Bot 体验与观点
使用背景、体验评价与限制；具体观点见「多方观点」章节
- BoddhaFace 的 Grok Bot 体验与观点
使用背景、体验评价与限制；具体观点见「多方观点」章节
- SentiSense Team 的 Grok Bot 体验与观点
使用背景、体验评价与限制；具体观点见「多方观点」章节
- Bubbly_Sort849 的 Grok Bot 体验与观点
使用背景、体验评价与限制；具体观点见「多方观点」章节
- dizzygoldfish 的 Grok Bot 体验与观点
使用背景、体验评价与限制；具体观点见「多方观点」章节
- Dragos Roua 的 Grok Bot 体验与观点
使用背景、体验评价与限制；具体观点见「多方观点」章节
- SaschaFromWhaaat_ai 的 Grok Bot 体验与观点
使用背景、体验评价与限制；具体观点见「多方观点」章节
- DeCiel 的 Grok Bot 体验与观点
使用背景、体验评价与限制；具体观点见「多方观点」章节
- Grok Bot for Engineering · Lingxi Li
持久 Bot、Notion 账本与 Cloud Agents 分层
- Get started with Claude Cowork
任务、项目、云运行与本地依赖
- Codex cloud
隔离仓库任务、并行、diff 与 PR
- Manus Cloud Computer
持久电脑、任务 sandbox；当前电脑为 CLI
- What is Wide Research?
并行子任务与合成
- Multi-Agent Routing
Agent 身份、工作区与渠道路由
- Sub-Agents
后台子会话与结果回传
- Heartbeat
周期检查与主动性