Grok Bot 上线那天，AI 战场的规则已经变了：把员工派给机器，还是把机器派给工作

8 月 11 日，SpaceXAI 发布了 Grok Bot。官方描述很克制，产品页面上写的是"always-on AI agent service"，听起来又是一个聊天模型的升级包。真正值得注意的是它的定价：团队版每席每月120 美元，个人版200 美元，附带一台专属的云电脑。这不是一个对话产品的价格标签，这是一个岗位的价格标签。

同一天，TechCrunch 的标题是"Grok is now an AI 'teammate' you can assign work"。Verge 用了"turf war"这个词来形容 Anthropic 的同类产品。两篇报道指向同一件事：AI 正在从"回答问题的工具"变成"可以派活的同事"。

而四家巨头——OpenAI 的 ChatGPT Work、Anthropic 的 Claude Cowork、Microsoft 的 Copilot Tasks、SpaceXAI 的 Grok Bot——已经在同一个战场上排开了。

这件事之所以值得单独写一篇，是因为它触碰到了一个很少有人明说的分歧：AI 能力的下一个增长点，到底是在"回答得更好"，还是在"干得更多"。前者还在卷上下文窗口、卷推理速度、卷 benchmark 分数；后者已经在重新定义"工作"这件事本身。Grok Bot 的上线，是后者正式落地的信号。

一、反方的三张牌，每一张都成立

先说反方的立场，这不是空穴来风。

反对者的第一条理由是"agent 都是纸老虎"。这个批评不算离谱：现在的 agent 普遍靠多步工具调用串起来，中间任何一环失败，整个链条就断了。CSDN 上有篇 Grok 4.3 的实测文章提到，约 5% 的并行任务会出现子任务结果丢失。5% 听起来不高，放到每天几百次调用的生产环境里，就是好几次事故。

更麻烦的是可复现性差。同样的 prompt，这次跑通了，下次可能就不通，而你不知道区别在哪里。这意味着你没法给 agent 写测试用例，也没法做 A/B 对比——它今天的表现和昨天的表现，之间没有确定性的因果关系。

反对者的第二条理由更根本：agent 的成本说不清。一次复杂任务的 token 消耗是普通对话的 2 到 3 倍，而它到底完成了多少工作，很难用一个数字衡量。NVIDIA 在 8 月 11 日发布 Nemotron 3.5 Lightning 时，专门讲了一件事：模型路由。把大模型的请求按难度分流到不同规格的模型上。

因为"agent 效率最终取决于模型完成有用工作的速度，而不是生成 token 的速度"。这话其实是承认了，当前的 agent 成本模型还很粗糙。

反对者的第三条，也是最要命的一条：安全。Grok Bot 可以登录你已经在用的应用、读你的文件、跨多步执行操作。权限怎么管？如果 bot 能直接发邮件、改数据库、提交订单，那么它的身份就是你的身份，它的漏洞就是你的漏洞。

Cloudflare 在 8 月初开源的 AAM（Agent Access Model）恰恰是为这个问题准备的——把权限从"系统级"缩小到"一次动作级"，每个工具调用单独授权、单独记录。这说明行业自己也知道，agent 的权限模型是最大的空白。

二、常驻 agent 的真正壁垒

但把这三条反对理由摊开看，会发现它们指向的是同一个问题：agent 还不够成熟，而不是 agent 这个方向错了。

关键的分歧点在于"常驻"这两个字。此前的 agent 是任务态的——你开一个会话，它跑完就没了，下次再从头来过。Grok Bot 做的事情是把 agent 变成常驻的：它有自己独立的云电脑，可以登录你的工具，可以记住你的工作习惯，你不用在场它也在干活，干完了才回来找你。

SpaceXAI 的原话是"bots can learn and save your existing workflows and retain context about how you perform tasks"。这跟"每次重新告诉它该干什么"是两种完全不同的产品思路。前者是秘书，后者是实习生——前者记住你怎么做事，后者每次都要重新教。

这个转变为什么重要？因为真实工作本来就是长跑，不是问答。一个市场调研要查十几个数据源、交叉验证、整理成表格、再写分析——这个过程里的大部分动作，不需要人在中间决策，需要的只是"有人把活派出去，然后等结果"。

此前的 AI 要么让你自己拆成几十次对话，要么让你写一堆 prompt 来描述流程。Grok Bot 的做法是：你像给同事发消息一样说一句"帮我把 Q2 的 SaaS 融资情况整理出来"，剩下的它自己跑。

这里有一个容易被忽略的技术细节。常驻 agent 要跑得稳，靠的不是更强的模型，而是三样基础设施：持久化的身份、可撤销的权限、可回放的执行日志。身份解决"这个 bot 是谁"，权限解决"它能动什么"，日志解决"它干过什么、干错了怎么回滚"。这三样东西补齐之前，agent 永远只能是玩具，不能是员工。

Grok Bot 之所以敢按"岗位"来定价，正是因为它在产品里把这三样当成标配来做了：专属云电脑就是身份，应用登录需要审批就是权限，断点恢复和事件流就是日志。

三、四家同台，谁的牌更硬

再看数据。Grok Bot 的定价本身就是一个信号：团队 120 美元/席/月，个人 200 美元/月。对比一下人力成本，这个价格已经低于任何一个全职员工的月成本。再对比一下现有的 AI 产品：ChatGPT Pro 是 20 美元/月，Claude Max 是 200 美元/月但只提供对话能力。Grok Bot 贵，但它卖的不是对话，是一台会干活的云电脑。

VentureBeat 的标题直接把定价和"persistent digital coworkers"绑在一起，说明市场在按"数字员工"这个单位来理解它。这个认知转变很关键——当一个产品的价格标签是"每个岗位每月"，它就不再是一个软件许可，而是一个人力外包合同。

竞争格局的数据更有说服力。四家厂商的 agent 产品在 8 月这个时间窗口同时推进：OpenAI 的 ChatGPT Work 定位为"longer, multi-step work and finished deliverables"，Codex 专注软件开发；Anthropic 的 Claude Cowork 面向白领办公。

Microsoft 的 Copilot Tasks 在整合自家的 Copilot 应用，做"super app"；SpaceXAI 的 Grok Bot 则打出了"teammate"这张牌。

四家撞在同一个时间点，不是巧合——是底层能力（工具调用、多步推理、上下文管理）刚刚成熟到可以支撑"常驻 agent"这个形态的临界点。

既然是四家同台，就把各自的牌摊开比一遍。OpenAI 的优势在生态：ChatGPT 的用户基数、Codex 的开发者口碑、Work 环境对长任务的承载，三者加起来是目前最完整的 agent 栈。Anthropic 的优势在安全叙事：Claude 的开发者社区对"负责任 AI"有认同感，Cowork 直接把权限控制当卖点，这是差异化打法。

Microsoft 的优势在企业渠道：Copilot 已经嵌进了 Office 和 Windows，Tasks 想做的是"一个能干所有事的超级应用"，渠道壁垒最高。SpaceXAI 的优势在激进：Grok Bot 直接把 agent 拟人化为"同事"，用独立云电脑这个概念把复杂性封装起来，定价也最接近"一个岗位"的心理账户。

四家的差异，本质上是在回答同一个问题的不同答案：agent 应该像什么？OpenAI 说像 IDE，Anthropic 说像秘书，Microsoft 说像 Office 助手，SpaceXAI 说像同事。目前来看，"像同事"这个说法在传播上最强——因为它绕过了所有技术名词，直接回到了工作关系的常识。

四、模型路由：agent 经济学的前提

那它适合谁？先说结论：如果你的工作是"重复的多步骤信息处理"，Grok Bot 类的产品值得现在就试。如果你的工作是"一次性的创造性决策"，它现在的表现还不足以替代你。

具体到场景，Grok Bot 官方演示里提到的四个用例很有说服力：销售外推、市场运营、办公自动化、bug 修复。这些任务的共同特征是——有明确的起点和终点，中间的步骤可以标准化，而且不需要人类在每一步做审美判断。

另一个信号是它支持多 bot 并行，一个 bot 带着自己的专长，bot 之间可以直接互相发消息协调。这已经不是"一个助手"，而是"一个团队"的雏形。

这里插一段供参考的代码。下面是一个极简的模型路由函数，灵感来自 NVIDIA NeMo Switchyard 的思路：把不同难度的任务分给不同规格的模型，而不是所有请求都扔给最大的那个。理解这个逻辑，就能理解为什么"agent 效率"这件事跟模型能力本身关系不大，更多是调度问题。

def route_task(prompt: str) -> list[str]: """ 根据任务类型选择模型，返回候选模型列表。 灵感来自 NVIDIA NeMo Switchyard 的路由思路。 """ lower = prompt.lower() code_keywords = ["bug", "错误", "异常", "代码", "审查", "排查", "重构", "性能"] creative_keywords = ["文案", "写作", "创意", "博客", "故事", "市场营销"] multimodal_keywords = ["图片", "图表", "图像", "视频"] selected = [] if any(kw in lower for kw in code_keywords): selected.append("fast-model") # 代码/排查 → 低延迟模型 if any(kw in lower for kw in creative_keywords): selected.append("quality-model") # 文案 → 高质量模型 if any(kw in lower for kw in multimodal_keywords): selected.append("vision-model") # 多模态 → 视觉模型 # 无命中时默认双保险：速度 + 质量 if not selected: selected = ["fast-model", "quality-model"] return selected # 并行调用，总耗时 ≈ 最慢的那个，而不是三者之和 # asyncio.gather(*[call_model(m, prompt) for m in route_task(prompt)])

上面这段代码揭示了一件反直觉的事：在 agent 系统里，模型选型的收益远大于模型升级。一个 30B 的专用执行模型加上一个 70B 的推理模型组合，其任务完成效率可能高于单一的 400B 大模型——因为大多数请求不需要最贵的那档，而延迟和成本恰恰是被那些"本来可以用小模型处理"的请求撑起来的。

NVIDIA 的 Nemotron 3.5 Lightning 就是一个 30B 的 MoE 模型，激活参数只有 3B，官方定位就是"执行层"，专门吃高并发、低延迟的 agent 调用。在 PinchBench 上，它完成 1 万项任务的速度比同精度的 Qwen3.6 35B 快 30%。模型分层，是 agent 经济学的前提。

五、它适合谁，还不适合谁

但必须把话说清楚：Grok Bot 现在是 beta，而且只对 SuperGrok Heavy、Cursor Ultra 和 Cursor Teams Premium 订阅用户开放，企业用户还得排队。它没有公开 benchmark，因为 agent 任务的评估本身就很难量化。这意味着你现在还不能把它当生产力工具来依赖，只能当探路来用。

更现实的问题是中文生态。Grok Bot 目前的入口在国内并不方便，这恰好是留给国内模型厂商的窗口期。豆包、Kimi、通义千问都具备做"常驻 agent"的技术基础，缺的只是产品化决心。如果哪家率先把"常驻 + 可派活 + 权限可控"这三件事做扎实，它可能不只是做一个 AI 产品，而是重新定义"AI 和工作到底是什么关系"。

最后说一个容易被忽略的点。Grok Bot 的真正威胁，不是抢了谁的对话市场，而是它让"AI 能不能干活"这个问题的评判标准变了。以前我们评估模型看的是回答质量、推理能力、代码正确率；现在评估 agent 看的是任务完成率、失败重试的成本、权限管理的完备度。这是两套完全不同的记分卡，而率先按第二套记分卡来设计产品的公司，会获得先发优势。

对做技术内容的人来说，这个变化也意味着选题逻辑得跟着改。以前写"Grok 4.3 用了什么架构"能火，因为大家都在卷能力；现在要写"agent 怎么管权限""模型路由怎么设计"才切中痛点，因为行业已经进入了工程期。读者关心的不再是模型能不能，而是它靠不靠谱、出错了怎么办、成本怎么算——这些恰好是技术写作最擅长拆解的问题。

Grok Bot 上线才几天，现在评价它为时过早。但四家巨头同时挤进同一个赛道这件事本身，已经足够说明一个问题：AI 的下半场，比的不再是谁更能聊，而是谁更能干。