xAI 发布了 Team Bots:能融入团队工作流,随着用得越多,它会变得越来越懂业务

它像团队新招的一位虚拟同事:拿到工作手册、工具、受限权限和工作记忆后,能跨应用推进任务,并把团队的决定与纠正带到下一次工作里。

作者:SpaceXAI09-29 · 约 10 分钟

xAI 发布了 Team Bots,一种可以由整个团队共享、能进入实际工作流的 Grok Bot。你可以把它理解成团队新招的一位“虚拟同事”:普通聊天助手更像临时顾问,每次见面都要重新告诉它项目背景;Team Bot 则带着团队的工作手册、工具箱、门禁卡和工作笔记,知道该去哪里找资料、按什么规则办事,以及上次和团队一起做到了哪一步。

它要解决的痛点不是“AI 不会回答”,而是企业的业务上下文太分散:客户动态在 Gong,项目决定在 Slack,任务在 Linear,规范在 Notion,数据又在仓库里。每次提问都要重新搬运这些背景,换人时还可能把已经做过的判断一起丢掉。团队可以围绕销售账户、工程项目、品牌审核或数据分析建立一个 Team Bot,把这些资料、规则、应用连接、API 权限和长期记忆放进去,让它持续跟进同一项工作。

xAI 官方演示:创建 Team Bot、连接工作应用、执行跨工具任务,再把它分享给团队或加入 Slack。

主要功能特点

  • 围绕一个岗位或流程建立共享 Bot:把销售账户、工程项目、营销审核或数据问答交给一个持续工作的角色,而不是每次新开一段对话。
  • 把上下文、插件、凭据和记忆放在一起:既知道团队怎样做事,也能进入工作系统、调用获准使用的能力,并记住后续决定和纠正。
  • 连接 Slack 和业务应用:可以从 Gong、Notion、GitHub、Linear、Databricks 等系统读取变化,并把简报、工单、预览或分析结果带回团队协作现场。
  • 共享团队能力,保留个人对话:团队成员使用同一套知识和技能,但各自与 Bot 的单独对话及个人上下文保持分开。
  • 在持续使用中积累组织知识:Bot 会记住团队确认过的决定和纠正,让后来处理同类任务时不必每次从头解释。

1. 用共享上下文统一一个岗位的工作方法

Team Bot 围绕一个团队共同承担的角色或流程建立。团队可以把内部文件、操作说明和技能交给它,让它理解这家公司怎样处理客户、交付代码、审核品牌内容或解释数据。

xAI 将这种岗位能力拆成四个部分:

  • 上下文(Context):文件、说明和技能,例如品牌手册、内部文档与交付流程,负责告诉 Bot 公司怎样做事。
  • 插件(Plugins):Salesforce、Notion、GitHub 等应用连接,让 Bot 能读取或操作工作实际发生的系统。
  • 凭据(Credentials):第三方 API 的访问凭据,用来连接没有现成插件的团队系统,并限定它获准调用的范围。
  • 记忆(Memories):工作中积累的决定、纠正和使用者上下文,让后续任务可以延续此前判断。

如果继续用“虚拟同事”的类比:Context 是它入职时拿到的工作手册,Plugins 是它使用 Salesforce、Notion、GitHub 等软件的工具,Credentials 是只允许进入指定系统的门禁卡,Memories 则是它随工作不断更新的笔记本。

四项能力必须连起来才有意义。只有工作手册,它只是会查资料;只有插件和凭据,它虽然能进入系统,却不知道团队希望它怎样做;没有记忆,每次任务结束后,团队刚纠正过的判断下次还要再讲一遍。四项合起来,Bot 才能从“回答一个问题”变成“持续跟进一项工作”:先理解规则,再去相应系统取信息和执行动作,最后把新的决定与纠正带到下一次任务里。原本由成员临时拼装的上下文,也因此变成整个团队反复使用的工作底座。

2. 连接应用和 API,把信息变成下一步动作

Team Bot 不只读取资料。通过插件和 API 凭据,它可以跟踪不同系统里的变化,再按照团队设定的流程推动下一步。

四个案例虽然工作不同,基本链条却很一致:

  1. 从文档、通话、Slack、工单、监控或数据表读取最新状态;
  2. 使用品牌规范、交付流程、指标定义或账户策略解释这些变化;
  3. 生成草稿、创建工单、调用执行 Agent、更新内容或发起只读查询;
  4. 把简报、预览、证据和阻塞带回 Slack,交给团队继续处理;
  5. 记录新的决定和纠正,供下一次任务使用。

它的作用因此不止是生成一段答案,而是把分散的信息接回一条可以继续推进的工作链。

3. 共享团队能力,同时保留个人对话

团队共享的是 Bot 及其岗位知识、技能和团队配置。Team Bot 也可以拥有自己的 Slack 账号;加入频道后,频道成员能够向它提问、补充信息,并共同看到它的回答。

个人与 Team Bot 的单独对话则保持私密。按照 xAI 的说明,Bot 会为每位用户保留彼此分开的上下文和记忆,同时调用团队共同拥有的技能;插件既可以由个人连接,也可以由团队统一配置。

因此,共享的重点是一套工作方法,而不是把所有人的聊天记录合并到一起。公开频道承载共同协作,个人对话保存各自的工作现场。

4. 在持续使用中积累决定和纠正

记忆让 Team Bot 能够延续一项长期工作,但“越用越懂业务”并不是一句自动变聪明的口号。它背后有一条具体闭环:先读取团队已经提供的资料和规则,在 Slack 与业务系统中参与任务,再记下团队确认过的决定、纠正和使用者上下文;以后遇到同类任务时,它沿用这些信息,而不是重新从零猜测。

xAI 的数据团队已经为超过 4.5 万张表建立技能库,用来说明正确的数据来源、分析方法和图表规范。Data Bot 接入这套既有知识后,还会记住使用者对查询的纠正。这里的“学习”不是自动读取公司的所有数据,也不能理解为每次对话都在重新训练基础模型;原文明确描述的是技能、记忆以及查询纠正被后续任务继续使用。Team Bot 越用越懂业务,靠的是组织知识与反馈被持续留下,而不是模型凭空获得了业务常识。

越用越懂业务,具体发生在哪里?

知识不是一次性喂进去,而是在工作中形成闭环

四步默认全部可见。选择任一步,可以查看它在真实工作里的作用。

当前环节

先拿到团队的工作底稿

Bot 先读取文件、规范与技能。它的起点不是空白聊天框,而是团队已经写下来的做事方法。

例如:品牌指南、账户资料、PR 完成标准、指标定义。

这里展示的是技能、记忆和反馈如何被后续任务复用,不代表基础模型会自动读取或训练公司全部数据。

四个场景,Team Bot 具体怎样工作

销售与客户成功:每天生成账户简报

xAI 为重要销售账户配置专用 Team Bot,由客户经理(AE)、客户成功经理(CSM)、解决方案架构师(SA)和销售负责人共同使用。过去,这几类人各自掌握一部分客户情况:有人知道最近的通话内容,有人知道技术阻塞,有人知道账户策略,完整背景散在不同工具和成员手里。

Team Bot 每晚查看公司新闻、近期 Gong 通话、Notion 文档和相关 Slack 讨论;第二天早上在账户频道发布简报,为不同角色列出下一步建议和草稿。白天,团队再用账户数据核对它的判断,并把新决定留下来。它因此更像这个账户的“活字典”:省掉的不只是写晨报的时间,还包括反复向不同同事追问背景、手工拼接最新状态,以及成员轮换后重新口头交接的成本。

Harper CEO Dakotah Rice 表示,其团队在 24 小时内搭建了一个 Team Bot,用来跨三个平台检查保单失效客户、查询余额并发送个性化邮件,并称这套流程在数百份保单中为客户节省了超过 12 万美元。这是客户提供的案例数据。

产品与工程:协调工单、Agent 和交付证据

xAI 的工程 Team Bot 从项目 Slack 频道获取信息,并连接 Notion、Linear、Hex、Datadog 和 Cursor。工程流程原本容易断在工具之间:产品决定留在聊天里,Bug 还要有人整理成工单,执行 Agent 修完代码后,又要有人确认测试与交付证据。

Team Bot 把这条链串起来:跟踪决定、分拣缺陷、在 Linear 创建清楚的工单,再把边界明确的修复交给 Cloud Agents。团队通过技能告诉它怎样做 PR 审查、什么时候必须向人求助,以及一项改动需要哪些证据才算完成。执行 Agent 返回通过检查、有验证证据的 PR 后,Bot 再回到 Slack 汇报进度和阻塞。它替代的是跨工具搬运信息和盯进度的协调劳动,不是取消工程师对复杂改动的判断。

xAI 称,一个 Team Bot 在开发这项产品时编排了数百个 Cloud Agents,帮助 5 人团队在几周内完成发布,并实现每天提交超过 100 个 PR。这是 xAI 自报的生产数据,原文没有披露 PR 规模、返工率或与人工基线的比较。

营销:按统一规则审核并送到预览

大型营销团队常卡在两段等待上:地区团队写完内容,要跨时区等总部检查品牌口径;网页或 SEO 文案通过后,还要向工程团队提工单才能改到网站上。营销 Bot 获得品牌指南、博客文章和社交媒体文案后,有人在 Slack 提交草稿,它就能先按照品牌语气和最新信息审核,让不同地区使用同一套标准。

内容通过审核后,它还可以继续更新网站和 SEO 内容、生成预览链接,再回到 Slack 等待最终确认。这样缩短的是“等总部初审”和“等工程排期”两段时间;最后的人类签字仍然保留,并不是让 AI 自己决定上线。

Amplitude 营销负责人 Angela Ferrante 表示,公司正在尝试把 Team Bots 用于市场与客户情报、AI 搜索可见性、发布审核和效果判断。

数据分析:用只读权限回答临时问题

xAI 的数据团队每天会收到数十个临时分析请求。传统流程里,业务人员要先找分析师排期,分析师再确认指标口径、寻找正确的数据表并写查询;即使只是一次临时问题,也可能消耗多轮沟通。

Data Bot 使用共享的只读凭据查询 Databricks 中获准访问的表,并连接 Datadog、Hex 和 Statsig 完成调查、分析和展示。员工因此可以直接问业务问题,不必先等待分析师排期,也不用自己申请和配置仓库访问。数据团队此前两年为超过 4.5 万张表积累的技能库,帮助它找到正确数据、理解指标并按公司规范制图;有人纠正查询后,这次纠正还会帮助之后提问的人少踩一次同样的坑。这里的前提是访问范围已经限定:Bot 使用只读凭据,并且只能查询获准访问的表。

四个场景共同改变了什么

表面上看,四个 Bot 分别在写晨报、建工单、审文案和查数据;真正共同的变化,是团队不再每次都由人来充当“信息搬运工”。Bot 把散落在聊天、文档、业务软件和数据仓库里的信息拉回同一条工作链,再按照已经写清的团队规则推进下一步。

这带来三种具体价值:信息不会因为分散在不同工具里而反复重找;员工轮岗或离开后,已经确认的决定和做法仍可继续使用;分析师、工程师、总部审核者等稀缺角色,也能少花时间处理查资料、转工单和第一轮审核,把注意力留给真正需要判断的例外和复杂问题。

哪些团队工作适合先做成 Team Bot

Team Bots 目前面向 Teams 和 Enterprise 计划公开测试。用户可以把已有的 Grok Bot 分享给团队,也可以从 xAI 提供的销售、产品管理、营销和数据分析预制 Bot 开始。

如果要判断一项工作是否适合先交给类似 Team Bot 的系统,可以检查五件事:

  • 任务是否反复发生,而且上下文分散? 每天都要跨多个系统查资料、汇总变化的流程,比一次性问题更适合建立共享 Bot。
  • 团队规则是否已经说得清? 品牌指南、PR 完成标准、指标定义和升级条件越明确,Bot 越容易稳定执行。
  • 能否用最低权限完成工作? 能只读就不先给写入;需要修改内容时,把预览与最终确认分开。
  • 共享与私密的边界是否明确? 团队技能、公开频道和个人对话分别承载不同信息,需要提前定义可见性和交接规则。
  • 结果能否被检查? 除了生成数量,还应观察等待时间、返工、错误、人工升级次数,以及结果是否通过原有质量门槛。

最合适的起点,是一个角色清楚、资料可控、结果可复核的流程。Team Bots 展示的产品方向也很明确:企业 AI 正从个人问答工具,走向由团队共同配置、能连接系统并持续积累工作记忆的岗位角色。

来源
Team Bots: AI coworkers that learn from your teamSpaceXAI·查看主材料
本站说明
依据官方文章与 26 秒产品演示整理;产品能力、效率数据与客户收益均保留原始归属,本次未实际部署 Team Bot。