AIREITERGrok Bot for Enterprise 已面向符合条件的企业客户正式推出，并提供两周免费使用期。不过，如何开通、优惠结束后的价格，以及部分治理细节，目前仍需按具体账户确认。
已发布，不等于能直接下单
Grok Bot for Enterprise 确实已经发布，并非传闻，也不是换了名字的聊天机器人。xAI 在 2026 年 9 月 3 日的公告中表示，Grok 和 Cursor Enterprise 客户可免费使用两周，并可邀请整个组织加入，其中包括尚未拥有席位的员工。(查看公告)
但这里要分清一件事：“已可用”不代表“可完全自助购买”。 发布页面将企业客户引导至管理后台或销售联系人，而 Cursor 的套餐与计费文档也明确写道，企业访问权限需要与客户经理协调开通。
| 采购方关心的问题 | 截至 2026 年 9 月 4 日核实的答案 |
|---|---|
| Grok Bot for Enterprise 是否已正式发布？ | 是。xAI 已于 2026 年 9 月 3 日宣布面向企业开放。 |
| 是否有企业免费优惠？ | 有。符合条件的 Grok Enterprise 和 Cursor Enterprise 客户可免费使用两周。 |
| 企业能否邀请没有席位的用户？ | 公告称可邀请整个组织，包括尚未拥有席位的人员。 |
| 优惠结束后是否有公开价格？ | 没有。发布公告未说明价格、额度、超额费率或最低合同承诺。 |
| 任何公司都能立即启用吗？ | 不一定。现有 Cursor 文档显示，企业开通依赖客户团队或管理员操作。 |
| 它和 Grok Business 或 Grok Enterprise 聊天产品是一回事吗？ | 不是。Grok Bot 是可持续运行、能够调用工具的智能体产品；Grok Business/Enterprise 则是更广义的组织工作空间。 |
因此，这更像一次受控评估机会，而不是能靠公开价目表直接完成的预算决策。
谁能用、怎么开通，以及暂时无法预算的价格
Grok Bot 尚未提供清晰公开的独立企业 SKU。目前的商业路径，是通过符合资格的 Grok 或 Cursor 套餐获得 Bot 访问权限；面向既有企业客户的发布，则额外提供两周促销期。
官方 Cursor 套餐与计费文档列出了多种访问途径：付费个人 Cursor Pro、Pro+ 和 Ultra 套餐，自助购买的 Cursor Teams，以及已关联的个人 SuperGrok 和 X Premium+ 订阅。企业客户则需联系客户经理。该页面同时指出，SuperGrok Team、SuperGrok Enterprise 和 SuperGrok Lite 不支持通过账户关联方式接入。
最后这一区别很重要。xAI 的业务页面将 Grok Business 和 Grok Enterprise 定位为面向组织的更完整服务，而 Bot 文档描述的则是一个基于持久化云端计算机运行的智能体。在合同明确 Bot 功能、数据条款与控制措施之前，应将两者视为不同产品。
| 商业细节 | 已公开的信息 | 仍未明确的信息 |
|---|---|---|
| 企业促销 | Grok 和 Cursor Enterprise 客户可免费使用两周 | 两周从激活时开始计算，还是从固定日期开始计算 |
| 常规 Bot 访问权限 | 多个符合条件的 Cursor 套餐及个人 Grok 套餐已包含访问权限 | 各套餐的确切每周额度 |
| 用量计费方式 | Cursor 表示，付费套餐中的包含用量每周重置；额度耗尽后，按需用量可能继续产生 | 长时间运行 Bot 任务的可靠企业成本模型 |
| 企业价格 | 通过销售定制报价 | 单用户价格、最低席位数、合同期限、超额费用和支持 SLA |
| xAI 组织版定价 | 官方定价页面宣传了自定义速率限制、专用基础设施、SSO、合规支持、数据驻留和批量定价 | 这些条款中哪些专门适用于 Grok Bot，以及对应何种合同 |
预算风险不只是价格尚未公布。智能体工作量通常按活动、计算机操作步骤和模型使用量计量，而不是简单按消息数量计算。Cursor 提醒，单次较长运行就可能耗尽一个试用额度；同时，Teams 套餐默认启用按需用量。
这次企业发布到底新增了什么
Grok Bot 的设计目标，是在员工已在使用的应用和网站中直接完成工作。官方发布说明称，Bot 可以全天候运行，通过演示和后续纠正学习工作流，在需要决策时回来询问用户，并与其他 Bot 交流。
这与传统助手“生成一份回答就结束”的模式不同。对于那些起止边界明确、但底层系统难用、老旧或没有 API 的任务，它的价值可能更高。
公告列出了以下示例：
| 团队 | 官方描述的工作流 | 更稳妥的初始版本 |
|---|---|---|
| 销售 | 监控内容、准备 LinkedIn/邮件草稿，并在通话期间更新演示文稿 | 仅生成草稿；每一条对外消息都必须由人工批准 |
| 招聘 | 夜间搜寻候选人、准备短名单、排队等待外联，并创建评分卡 | 使用合成数据或已取得同意的数据；候选人相关决策必须保留人工复核 |
| 市场营销 | 阅读网络研讨会问答、识别相关客户经理，并准备 Slack 跟进内容 | 仅发送内部草稿，不直接面向客户发送消息 |
| 财务 | 监控供应商支出、使用情况和续约，以发现节省空间 | 在进入谈判或采购操作前，先仅限只读报表 |
| 工程 | 监控拉取请求、构建失败、合并冲突和安全发现 | 创建审查队列和问题；初期不要授予合并权限或生产环境凭据 |
这些都是厂商描述的使用场景，并非独立的成功率测量结果。发布页面没有提供方法论、任务成功率、延迟数据、正常运行时间承诺或独立 ROI 研究。
安全控制：已经确认的与必须实测的
xAI 表示，企业版新增了访问控制、网络控制和审计控制。发布公告还称，每位用户的工作都在安全、隔离的环境中运行；Bot 默认没有任何访问权限，只能访问用户亲自登录授权的账户。
这些属于厂商主张，而不是完整的采购规格。Grok Bot FAQ和发布页面均未具体说明针对 Bot 的加密方式、审计字段、数据保留、密钥管理、数据驻留、事件响应或正常运行时间承诺。
在企业能够查看日志和合同条款之前，应将“审计控制”视为尚待验证的功能主张。
| 控制领域 | 公开说明的立场 | 试点期间应索取的证据 |
|---|---|---|
| 用户隔离 | 每位用户的环境被描述为相互隔离 | 租户边界文档，以及证明一位用户无法查看另一位用户文件或会话的测试 |
| 默认访问权限 | Bot 初始无访问权限，需要选择性登录账户 | 账户清单、权限范围、凭据撤销机制和离职处理行为 |
| 网络控制 | 已宣布提供企业网络控制 | 允许访问目标的策略、私有网络行为、出站流量细节和失败日志 |
| 审计控制 | 已宣布提供审计控制 | 可导出的操作记录，展示用户、Bot、工具、时间戳、批准信息和结果 |
| 身份管理 | 官方定价材料为定制套餐宣传了 SSO 和 SCIM | 这些控制是否涵盖 Bot 创建、关联、预配和去配，而非仅覆盖母工作空间 |
| 数据处理 | 要求使用云端存储；不支持 Legacy Privacy Mode | 针对具体服务的保留、删除、驻留、训练使用和连接器处理条款 |
真正改变风险判断的运行限制
最关键的限制不在营销清单里，而在实际运行模式中。Grok Bot 可以在浏览器里工作，即使笔记本电脑关闭后也能继续运行；但让它有用的云端持久化能力，也同时带来了共享状态、成本和恢复方面的问题。
多个 Bot 共用一台账户云端计算机
官方 FAQ 表示，同一账户下的所有 Bot 会共享一台持久化云端计算机，包括文件、浏览器会话和登录状态。多个 Bot 可以并行工作、各自拥有独立屏幕，但每个 Bot 同一时间只能执行一项计算机操作任务。
这意味着，“多个 Bot”不能自动等同于“多个安全边界”。不要将同一账户下的不同 Bot，当作财务、客户支持和工程凭据之间唯一的隔离手段。
浏览器自动化会卡在最麻烦的环节
FAQ 称，没有正式连接器的网站仍可能通过浏览器工具使用，但自动化拦截、重新验证、CAPTCHA 和人工确认都可能中断运行。密码、双因素验证码和 CAPTCHA 均需要用户接管计算机。
因此，一个在干净演示环境中成功的工作流，实际运行时仍需设计清晰的异常处理路径。试点应有意覆盖过期会话、页面含义模糊、自动化被拦截和登录失败等情况，而不应只验证理想路径。
审批与删除，并不等于隔离
敏感操作可能会因工具规则、风险规则或自动审查规则而暂停。即便 Bot 看似能够完成以下操作，生产环境上线时也应要求人工明确批准：发送消息、发布内容、删除记录、进行采购或修改生产系统。
删除 Bot 会移除其资料、对话和例程，但 FAQ 提醒，共享计算机上的文件和登录状态可能仍会保留。因此，删除应被视为需要人工清理和轮换凭据的生命周期事件。
账户关联可能无法撤销
Cursor 文档称，将个人 SuperGrok 或 X Premium+ 账户关联至 Cursor，是一种用量授权，而不是订阅迁移。文档还表示，该关联无法通过自助方式解除，也无法转移至其他 Cursor 账户。
测试前，应先确定由哪个企业身份和工作空间拥有 Bot。将个人账户关联到企业工作空间，或把企业权益关联到个人 Cursor 账户，都会造成本可避免的离职交接问题。
真实用户的反馈也说明，访问权限和计量细节值得实测，而不该靠猜测：
“我今天开始使用 Grok 集成。我只做了些基础操作，就看到已经用了 11% 的额度。这也太夸张了。” — u/SubtleFuryTuesday，发表于 r/grok
这条评论只是某位用户的早期观察，并不代表通用消耗率。但它提出了一个很有价值的试点问题：正常任务会消耗套餐每周额度中的多少？在按需费用不断累积前，管理员能否看清这个答案？
另一则 r/cursor 讨论则从另一个角度反映了权益问题：
“至少对我来说它不能用。它一直提示我需要升级到 pro（我已经是了）……不过，我用的是旧定价套餐（500 Requests）。” — u/MidnightRambo
这同样是轶事性且与特定套餐相关的信息，但它支持一项明确的验收测试：使用公司实际会采用的旧版、Teams 和 Enterprise 身份验证访问权限。
Grok Bot 适合从哪里试点，又该避开什么
当收益来自持续的计算机操作、且错误操作的后果可控时，Grok Bot 值得试点。如果一个工作流能在没有可靠审计和回滚路径的情况下，悄然发送、删除、购买、批准或更改生产数据，它就不适合作为第一批试点对象。
| 适合作为起点 | 需增加审批关卡 | 第一轮试点应排除 |
|---|---|---|
| 内部研究简报 | 面向客户或候选人的沟通 | 不可逆的金融交易 |
| 只读式供应商与续约审查 | CRM 更新和记录变更 | 生产部署和合并操作 |
| 销售或市场跟进草稿 | 内容发布和外部发帖 | 未经审查的雇佣评分 |
| 非敏感收件箱或工单分流 | 安全工单创建和优先级排序 | 缺乏书面控制措施的受监管数据 |
| 测试代码库中的问题与构建监控 | 任何使用特权凭据的操作 | 混用的个人/企业账户 |
最适合的初始场景是跨浏览器工具的“先出草稿、后人工确认”工作：Bot 的能力比文本助手更强，但人仍然掌控对外产生的结果。最不适合的，则是高影响力工作流——组织无法准确还原 Bot 看到了什么、改了什么、又批准了什么。
用两周时间做出可采购或不可采购的结论
把企业免费期当作受控测试，而不是产品便宜或可直接投入生产的证明。
- 选择一个可逆工作流。使用测试收件箱、沙盒 CRM、模拟供应商门户或非生产代码库。定义预期结果，并明确 Bot 绝不能执行的操作。
- 建立专属负责人和测试身份。由于账户关联可能是永久性的，在员工关联个人或企业订阅前，先记录对应的所有者工作空间。
- 只授予最低限度的有效权限。尽可能从只读权限开始。避免共享管理员凭据、生产令牌、支付方式和不受限制的浏览器会话。
- 衡量工作，而非消息数量。记录耗时、成功步骤、重试次数、人工接管次数、登录失败、审批次数和已消耗的每周额度。Cursor 称用量每周重置，但具体企业额度尚未公开。
- 主动制造失败场景。测试 CAPTCHA、过期身份验证、网页中的提示注入、相互矛盾的指令、缺失数据，以及发送或删除内容的请求。Bot 应当停止并升级处理，而不是自行应变。
- 检查控制平面。确认管理员能否审查和导出操作日志、撤销已连接账户、清理遗留文件或会话、通过身份提供商管理用户，并调查安全事件。
- 计算优惠后的决策条件。向客户团队索取两周后的价格、使用限制、超额机制、最低承诺、数据条款、支持响应和 SLA。如果答案仍停留在非正式层面，就应继续维持试点状态。
试点通过的前提是：工作流有实际价值，并且公司能够说明每一项重要操作由谁授权。任务完成率再高，如果无法恢复，也不代表具备企业级就绪度。
Grok Bot for Enterprise 常见问题
发布信息回答了可用性问题，但商业和治理细节仍需与客户团队确认。
Grok Bot for Enterprise 是否已正式可用？
是。xAI 于 2026 年 9 月 3 日宣布推出，并为 Grok 和 Cursor Enterprise 客户提供两周免费使用；激活仍由管理员和客户团队主导。
Grok Bot 是否有独立的企业价格？
目前未公布优惠结束后的价格、额度、超额费率或最低合同承诺，因此在批准上线前，应要求明确这四项信息。
Grok Bot 和 Grok Enterprise 是同一个产品吗？
不是。xAI 对 Grok Business 和 Enterprise 的描述是更广义的组织服务，而Bot FAQ描述的是一个使用云端计算机、网站、文件和已连接账户的持久化智能体。
免费期内每位员工都能使用吗？
发布公告称可邀请整个组织，包括没有现有席位的人员，但权限设置和用量权益仍需确认。
每个 Bot 都有独立计算机吗？
没有，至少不能把它视为严格的安全边界：同一账户下的 Bot 会共享一台持久化云端计算机，包括文件、浏览器会话和登录状态，尽管它们可在不同屏幕上并行运行。
Grok Bot 支持 SSO、SCIM 和审计日志吗？
xAI 为企业/定制套餐宣传了访问、网络、审计、SSO 和 SCIM 控制，但采购方应验证 Bot 层面的覆盖范围、日志导出、预配、去配和保留能力。
Grok Bot 能使用没有 API 的网站吗？
可以，但自动化拦截、CAPTCHA、重新验证和人工确认都可能中断基于浏览器的工作。
目前哪些团队适合使用 Grok Bot for Enterprise？
拥有可逆、先生成草稿后人工确认工作流的团队，适合进行有限试点；需要固定价格、细粒度凭据控制、完整操作级审计能力或受监管数据保障的团队，应等待书面答复。
关键不在演示效果，而在控制能力
Grok Bot for Enterprise 值得测试，因为其基于浏览器的持续工作能力填补了真实空白；但优惠后的定价、治理证据、共享计算机行为和生命周期控制，仍需要针对具体账户逐项验证。利用这两周优惠测试一个可逆工作流，只有在企业能够控制访问、从失败操作中恢复并预测支出时，再扩大部署范围。