如何用 Grok 4.7 操作已登录的浏览器

想让 Grok 4.7 操作你已经登录的网站，应在本机 Agent 客户端中运行模型，并给客户端配置浏览器工具。一种有官方文档可核对的组合是 Grok Build 加 Tabbit CLI Skill，在客户端中用 /tabbit 调用。xAI 的 Web Search 和 X Search 能查公开网页，却不会替你点击本机浏览器里的已登录页面。xAI 开发指南列出模型 ID grok-4.7 和 API 工具，Tabbit 快速开始说明了 Skill 与登录态复用。

这几个概念容易混淆。一位 Reddit 用户说，Grok Bot 无法“点击”自己 Edge 窗口里的内容；另一位用户说，在自己的环境里让 Grok 打开网站并点按钮也失败了。这些是个人使用经历，不能证明所有 Grok 客户端都缺少浏览器控制能力。真正需要确认的是客户端、它能调用的工具，以及登录态所在的浏览器环境。

要点

• Grok 4.7 是模型名称，不能据此判断它能控制哪个浏览器。

• xAI 文档列出 Grok 4.7 API 和 Grok Build；Grok Build 也会从 ~/.agents/skills/ 发现用户级 Skill，并使用 /<skill-name> 调用。

• 分别确认模型可用、Tabbit Skill 已发现、目标网站已经登录。

• Tabbit CLI 可通过所选 Tabbit Browser 环境使用已有登录态。任务会使用自己的标签页，你仍可在其他窗口继续工作。

• 先让 Agent 检查网页并准备未发布草稿，再由人核验内容并决定是否保存或发布。

• 本地测试夹具验证了该环境中的 Tabbit CLI 登录态复用，但未测试 Grok Build 或生产运营后台。

先选对工作层

“Grok 可以搜索网页”和“Grok 可以操作我已登录的后台”是两回事。前者可能调用 xAI 服务端工具；后者需要 Agent 客户端里有浏览器连接。

Grok 4.7 官方指南列出 API 函数调用、Web Search、X Search 和代码执行。xAI 函数调用说明明确区分服务端和本机工具：内置 Web/X 搜索运行在 xAI 服务器，调用方自己执行自定义函数。自定义函数可以连接浏览器，但客户端必须真的配置了这个连接。只开搜索工具，不等于能操作网页。

配置 Grok Build 与 Tabbit

可以先检查 Grok Build，因为 xAI 将 Grok 4.7 列为默认模型。官方说明它会读取 ~/.agents/skills/ 下的用户级 Skill，并把可由用户调用的 Skill 显示为 /<skill-name>。Tabbit Skill 名为 tabbit，因此发现成功后可输入 /tabbit。详见 Grok Build 概览和 Skill 发现规则。

开始任务前分别确认这三项：

1. 运行 grok models，确认列表中有 grok-4.7。API 模型 ID 与产品菜单中的显示名可能不同，以客户端显示为准。

2. 运行 grok inspect --json，确认它发现了 Tabbit Skill。如果没有，先启动 Tabbit，再重启 Grok Build 并复查。Tabbit CLI 完整指南提供安装检查；Codex 配置说明展示另一种本机 Agent 如何发现同一 Skill。

3. 在 Tabbit Browser 中亲自打开目标网站，确认登录的是正确账号和工作区。发现 Skill 不会替你登录网站。如果 Agent 能显示 /tabbit，但 CLI 无法连接 Tabbit，先检查浏览器控制器，不要把它当作网站登录问题。

在本机启动 Grok Build，选择模型并调用 Skill：

grok models
grok inspect --json
grok -m grok-4.7

在会话里输入 /tabbit，并说清楚允许 Agent 检查哪个网站和页面。不要把密码、一次性验证码、恢复密钥或客户记录写进提示词。CLI 安装和任务回执可看完整 Tabbit CLI 指南。若已有已登录标签页，可参考将 Agent 连接到现有浏览器了解会话边界。

Tabbit Skill 提供支持的启动器和任务写法。只读检查可以使用新任务名和唯一请求 ID：

"$HOME/.local/bin/tabbit-cli" nodejs \
  --task "Grok release review" \
  --request-id grok-release-review-001 <<'JS'
return {
  title: await page.title(),
  url: page.url(),
  headings: await page.getByRole('heading').allTextContents()
};
JS

这里仍要分别确认 Skill 发现、启动器可用和网站登录。示例只展示只读检查的形式，没有证明 Grok Build 会自动接受所有 Tabbit CLI 参数，也没有测试过 CMS 编辑。若任务要改动网页内容，先检查页面和具体动作，再决定是否允许写入。

在浏览器中复核带来源的更新

可以先用发布说明草稿做一个范围明确的例子。先读公开发布来源，再检查已登录的运营页面。随后让 Agent 准备一个有名称的草稿，并停在浏览器里供人复核。每条事实旁都保留来源 URL。

2026-11-09 的本地测试夹具在未登录时返回 401。设置短时测试 Cookie 后，第二个 Tabbit CLI 任务在同一 Tabbit Browser 环境打开相同页面，读取到标题 Release notes review 和夹具记录 GEO-104，请求为 200。两个任务各自拥有一个任务标签页。之后已清除测试 Cookie 并关闭临时标签页。这个结果只验证该本地夹具的登录态复用，不代表 Grok Build、CMS 编辑器或已发布更新经过了测试。

以下是根据 xAI 的 Grok 4.7 发布公告和开发指南写的建议草稿。公开来源描述模型能力；测试夹具只提供示例复核页标题和记录 ID。

提示词要说明来源、只读检查内容和停止条件：

/tabbit
在我的 Tabbit Browser 中打开已登录的发布复核页面。只读取页面上可见的草稿名称和记录 ID。
对照这两个公开来源核对下面的更新：https://x.ai/news/grok-4-7 和 https://docs.x.ai/developers/grok-4-7。
准备名为“Grok 4.7 发布说明复核”的草稿，保持草稿在浏览器中可见，附上来源链接。不要保存、发布或更改状态。
返回草稿全文、页面标题、记录 ID 和任何不一致之处。停下等待我复核。

预期结果是一个可见但未发布的草稿，附官方公告和 API 指南链接，返回运营页面标题和记录 ID，列出发现的不一致项，并且不执行保存或发布。如果网站没有草稿编辑器，就让 Grok 在聊天中返回文字，再由你粘贴。上述测试夹具是只读页面，因此这一步是示例流程，不是已观察到的端到端操作。

第一次实际操作时，先照着浏览器 Agent 首次任务检查表，选低风险网页。如果页面会改动数据、发起付款或要求确认，就停下来复核。其他连接方式可参考浏览器 MCP 与 CLI 对比。可读取或改动网页的 Agent 也有相应权限和风险，先看 AI 浏览器概览、网页交互说明和浏览器 Agent 安全风险。

按场景选本机或远程流程

如果任务要用本机浏览器登录态，而且 Tabbit Skill 已经可用，本机 Grok Build 更合适。不要默认云端 Runner 能访问本机 Tabbit Browser。若它无法连接，让远程 Agent 先整理带来源的核查清单，再交给本机 Grok Build 或你自己完成网页步骤。

Tabbit 适合这里的原因是任务依赖现有浏览器登录态。它不是 Grok 4.7 的替代品，配置过程也不代表 xAI 内置了 Tabbit 连接器。Tabbit 快速开始说明任务标签页可以让你继续在其他窗口工作。Agent 在独立页面执行，你仍能查看其过程并掌握登录站点的最终决定权。

操作顺序很简单：选择已验证可用的 Grok 客户端，确认 grok-4.7 和 /tabbit，在 Tabbit Browser 中登录目标网站，然后先做只读检查。让 Agent 准备附来源的草稿，再在浏览器里复核后决定是否保存或发布。

Secholar.L

Tabbit 增长与内容

Secholar.L 专注 AI 浏览器与 Agent 工作流的实操写作,基于真实调研对比工具,引用可验证的一手来源。