xAI Grok Build 深度拆解：Rust 编写、200万上下文、ACP 协议——终端编码 Agent 三国杀，xAI 如何杀出重围

2026 年 7 月 14 日，xAI 把 Grok Build 的核心源码以 Apache-2.0 协议开源。9 天之后，GitHub 上已突破 2.1 万颗 Star、4092 次 Fork——这个速度在 2026 年的 AI 编程工具赛道里称得上现象级。

它的出现让原本 Claude Code 与 Codex CLI 双雄对峙的格局，变成了三国杀：Claude Code 背靠 Anthropic，拥有最成熟的 IDE 集成和社区生态；Codex CLI 来自 OpenAI，坐拥最广泛的用户基数；Grok Build 则是 xAI 的奇袭——用 Rust 重写运行时、200 万 token 超长上下文、原生 ACP 协议支持，试图在"专业软件工程师"这个细分场景里建立壁垒。

这篇文章不写软文式的功能列表，而是从源码架构、协议设计、工程细节三个维度，把 Grok Build 拆到骨灰级。读完你会知道：它的核心竞争力在哪里、什么场景下它比 Claude Code 更顺手、以及如何把它接入自己的工具链。

一、背景：2026 年的终端编码 Agent 格局

在聊 Grok Build 之前，有必要先梳理一下 2026 年中这个时间节点的背景。

2025 年下半年，Claude Code 和 Codex CLI 先后开放了完整的工具调用能力：代码搜索、文件读写、Git 操作、终端命令、测试运行——这些原本只有人类工程师能做的事，AI 已经能独立完成了。但两种工具走了完全不同的路线：

Claude Code 选择深耕 IDE 集成。Claude Desktop → Claude Code → Sourcegraph 三级跳，让 AI 能理解整个代码宇宙。它的上下文窗口从最初的 20 万 token 逐步扩展到 100 万，覆盖大多数中小型仓库的单次分析。

Codex CLI 则押注 API 易用性。OpenAI 把 Codex 的能力抽象成标准化的 agent API，让任何支持 OpenAI SDK 的应用都能接入。这种"水暖先知"的策略让它在企业级市场铺得极快。

两种路线的共同问题是：封闭或半封闭的运行时。Claude Code 的核心代理循环是闭源的，Codex CLI 虽然开源但 Rust 化时间不长，定制空间有限。对于那些想把"AI 编码能力"嵌入自己平台、做差异化产品的团队来说，这是一道隐形的墙。

Grok Build 的切入角度正是这道墙。99.6% 的代码开源、模型与运行时分离、ACP 协议嵌入——它的定位不是"另一个 AI 编程助手"，而是"AI 编程能力的可嵌入底座"。

二、核心概念：从 Grok Build 到它的技术栈

2.1 它到底是什么

Grok Build 本质上是一个跑在终端里的 CLI 工具，背后驱动它的是 Grok-4.3 beta——xAI 于 2026 年 4 月发布，拥有当时西方闭源模型里最大的 200 万 token 上下文窗口。

但它的野心不止于"大模型 + 终端"。xAI 把 Grok Build 设计成了一个分层架构，每一层都可以独立替换：

┌─────────────────────────────────────────────┐
│           Grok Build TUI (交互层)            │
├─────────────────────────────────────────────┤
│         Agent Loop / Plan Mode / Subagents   │
│              (代理循环引擎层)                  │
├─────────────────────────────────────────────┤
│  MCP Client │ ACP Client │ Hooks │ Skills    │
│              (扩展协议层)                      │
├─────────────────────────────────────────────┤
│  Model Abstraction Layer (模型抽象层)          │
│  默认 Grok-4.3 / 可替换任意 OpenAI 兼容端点    │
├─────────────────────────────────────────────┤
│  Rust 运行时 / Sandbox / Git Integration      │
│              (基础设施层)                      │
└─────────────────────────────────────────────┘

这种分层设计的直接好处是：你不需要 Grok 的订阅，也可以跑 Grok Build。只要配置一个兼容 OpenAI API 格式的端点——本地 Ollama、Kimi API、DeepSeek、百炼上的 Qwen3-Coder——就可以把底层模型换成任何你想要的。

2.2 200 万上下文在实践中意味着什么

200 万 token 的上下文窗口，不是一个数字游戏，它解决的是真实痛点。

当你在 Claude Code 里处理一个 20 万行代码的 Monorepo 时，常见的工作流是"切片式"喂上下文：先分析 A 模块，把结论记在脑子里；再切到 B 模块；最后人工拼接全局视图。这个过程消耗的是工程师的注意力，而不是 token 配额。

Grok Build 的 200 万上下文，意味着整个仓库可以一次性装进模型的注意力窗口。对于以下场景，这个能力是决定性的：

• 遗留代码审计：接手一个没有文档的老系统，AI 可以一次性读完所有源码，而不是分段猜测架构
• 大型重构：涉及数十个文件的相关性分析，上下文窗口不够大时，AI 只能盲人摸象
• 协议文档对照：通信协议实现 + RFC 文档同时读，对照理解零错误

当然，200 万 token 不是银弹。超长上下文会带来推理成本的线性增长、首次 Token 生成时间（TTFT）的显著提升。Grok Build 的解法是引入 streaming 输出和 分片索引——模型在 streaming 输出的同时，用户已经在终端里看到进展，而不是等到整个分析完成才能看到任何内容。

三、架构深度解析

3.1 为什么选择 Rust

Grok Build 宣称 99.6% 的代码由 Rust 编写。这个数字在 AI 编程工具圈子里是异类——大多数竞品选择 Python 或 TypeScript 作为主要语言，Rust 通常只用于性能关键模块。

Rust 在这里的选择有其工程逻辑：

第一，并发安全。 Grok Build 的 Subagents 机制允许最多 8 个并行子代理同时运行，每个子代理可能发起网络请求、读写文件、执行 shell 命令。用 Rust 的类型系统和所有权模型，可以在编译期消除大多数并发 bug——数据竞争（data race）、空指针解引用、内存泄漏——而不需要依赖运行时检查或复杂的锁机制。

第二，沙箱执行。 代码 Agent 必然会执行用户提供的代码片段，这些片段可能是恶意的（有人会故意测试 Agent 是否会执行 rm -rf /）。Rust 的 wasmer 或 wasmtime 集成，使得在进程级别而非虚拟机级别实现轻量沙箱成为可能。相比 Python 的 subprocess 方案，Rust 原生编译的二进制体积更小、冷启动更快。

第三，与底层工具链的集成。 Git 操作（libgit2）、文件监控（notify-rs）、HTTP 客户端（reqwest）、TOML 配置解析（toml-rs）——Rust 生态里这些库的成熟度在 2026 年已经达到生产级别，Grok Build 可以直接复用，而不需要自己造轮子。

Tokio 异步运行时 + mpsc 通道，实现了主 Agent 与子代理之间的消息传递；Box<dyn Tool> 的 trait object 模式，让工具系统具备良好的可扩展性。Agent 循环的核心逻辑是：接收用户提示 → 调用模型 → 解析工具调用 → 执行工具 → 把结果反馈给模型 → 循环直到任务完成。

3.2 ACP 协议：让 Agent 之间说"普通话"

在 Grok Build 的架构里，ACP（Agent Communication Protocol）是连接外部宿主应用的关键协议。

ACP 由 IBM Research 发起，现已捐给 Linux Foundation 做开放治理。它的核心定位是多 Agent 协作时的通信标准，与 MCP 的"模型调用工具"定位形成互补。

用一个类比来理解两者的关系：

• MCP 定义了"人怎么使用工具"——就像 USB 协议定义了电脑怎么连接外设
• ACP 定义了"Agent 和 Agent 之间怎么沟通"——就像 HTTP 协议定义了两台电脑怎么对话

ACP 的设计有几个鲜明特点：

1. 基于标准 HTTP REST，而非 JSON-RPC

# 用 curl 直接调一个 ACP Agent
curl -X POST http://agent-server/runs \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "ORD-001",
    "input": {
      "prompt": "分析这个仓库的测试覆盖率"
    }
  }'

不需要专门的 SDK，不需要特殊的协议解析库。任何能发 HTTP 请求的环境——curl、Postman、浏览器、CI Runner——都能与 ACP Agent 通信。这降低了集成门槛。

2. 异步优先

Agent 的任务经常是长时间运行的（"分析这份 50 页的合同"可能耗时几分钟）。ACP 默认返回 run_id，客户端通过轮询或 WebSocket 订阅结果：

# 提交任务，立即获得 run_id
curl -X POST http://agent-server/runs \
  -d '{"agent":"ORD-001","input":{"prompt":"审查 src/auth.py 的安全漏洞"}}'
# 返回: {"run_id":"run_abc123","status":"queued"}

# 查询任务状态
curl http://agent-server/runs/run_abc123
# 返回: {"run_id":"run_abc123","status":"completed","output":"..."}

3. ACP 在 Grok Build 里的嵌入方式

Grok Build 的 ACP 嵌入让 IDE 或其他宿主应用可以把 Grok Build 当作后端调用：

# Grok Build 监听 ACP 请求
grok --acp-server --port 8080

# VS Code 插件 / 其他宿主应用通过 ACP 调用
curl -X POST http://localhost:8080/runs \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "grok-build",
    "input": {
      "task": "为这个 PR 添加单元测试",
      "context": {
        "pr_url": "https://github.com/org/repo/pull/123"
      }
    }
  }'

这种架构使得 Grok Build 可以作为"AI 编码能力"接入任何平台，而不仅限于终端 CLI。

3.3 Plan Mode：把决策前置的工程哲学

Grok Build 最具工程哲学的设计是 Plan Mode。这不只是功能特性，而是对 AI 编码 Agent 最大风险的理解：Agent 最大的危险不是"不会写代码"，而是"很自信地改错方向"。

传统的 AI 编程工作流是：用户说需求 → Agent 执行 → 用户看结果。这个流程中，决策发生在 Agent 拿到需求的那一刻。一旦 Agent 对需求产生了错误理解，它会用正确的方式执行错误的任务，直到最终输出才暴露问题——此时浪费的时间可能已经很多。

Plan Mode 把这个顺序反转了：

用户 → Grok Build → 结构化计划（待批准）→ 执行 → 完成
                    ↑
              你在这里介入

Agent 先输出计划，格式是结构化的 markdown，包含每个步骤的描述、涉及的文件、预期产出。只有当你 approve 之后，才会真正执行。计划的格式经过精心设计——每个步骤都有清晰的行动描述，便于你快速判断方向是否正确：

## Bottom Line
Swap legacy sessions for JWT + rotation, behind a flag with 7d compat.

## Approach
- [ ] Add jwtVerify helper in src/lib/jwt.ts
- [ ] Add /auth/refresh with rotating refresh tokens
- [ ] Replace session check in authMiddleware
- [ ] Add feature flag auth.jwt.enabled (default false)
- [ ] Emit metric auth.migration.legacy_used for 7-day window
- [ ] Update README "Authentication" section

## Risks
- [ ] 7-day window 内旧 token 和新 JWT 并存，需要 Session/JWT 双读
- [ ] 移动端 token 刷新时机需对齐

用户对计划的反馈可以是 approve（全部执行）、comment（对某步写反馈让 Agent 修正）、quit（取消会话）。这种设计把"是否执行"的决策权还给人类工程师，Agent 只负责执行。

Plan Mode 适合的场景：

• 多文件架构调整（组件拆分、schema 迁移）
• 不确定原因的 bug（p99 延迟上升、偶发 checkout 失败）
• 文档与代码同步（代码已支持但 README 没更新）
• 任何涉及多人协作、影响范围不明确的重构

Plan Mode 不适合的场景：

• 拼写修正、单行代码改动
• 简单重复性任务（"把所有 console.log 改成 logger.info"）
• 紧急 hotfix（等不及计划，直接修）

四、实战：完整的 Grok Build 工作流

4.1 安装与首次会话

macOS / Linux / WSL

curl -fsSL https://x.ai/cli/install.sh | bash

Windows PowerShell

irm https://x.ai/cli/install.ps1 | iex

验证安装：

grok --version
# grok build 0.9.3 (x86_64-apple-darwin)

首次认证

Grok Build 启动时会通过浏览器完成 OAuth 认证，使用 SuperGrok 或 XPremium Plus 账号。没有浏览器环境（CI Runner、Docker 容器、远程主机）改为环境变量认证：

export XAI_API_KEY="xai-xxxxxxxxxxxxxxxx"
grok

API Key 在 https://console.x.ai/team/default/api-keys 创建，仅展示一次，请立即存入密码管理器。

4.2 grok inspect：启动前的配置审计

无论用 Grok Build 处理什么任务，第一步永远是 grok inspect：

cd your-project
grok inspect

它会列出当前目录已加载的所有配置来源：

Configuration sources (in priority order):
  1. ./grok/           ← 项目级配置（最高优先级）
  2. ~/.grok/          ← 用户级配置
  3. /etc/grok/        ← 系统级配置（如果存在）

Loaded:
  - AGENTS.md: ✓ (found)
  - SKILL.md: ✓ (found)
  - MCP Servers: filesystem, linear
  - Hooks: before_tool (guard-shell)
  - Plugins: none

这个输出非常关键：Grok Build 会向上查找项目根目录，也会读取用户目录的配置。如果项目已经在用 Claude Code，Grok Build 会自动复用 CLAUDE.md、.claude/rules/、marketplaces、plugins、skills、mcp、agents、hooks，无需重复建设。

同时也要注意：项目级的 ./grok/ 优先级最高，会覆盖用户级配置。如果项目里有人写了过于宽泛的 Hook 或 Skill，可能意外放大或限制 Agent 的权限。看清楚 grok inspect 的输出，才能避免这类隐蔽的配置冲突。

4.3 模型替换：把 grok-4.5 换成 Qwen3-Coder

这是国内开发者最关心的能力。Grok Build 通过 ~/.grok/config.toml 配置模型：

[model.qwen3-coder]
model = "qwen3-coder-plus"
base_url = "https://dashscope.aliyuncs.com/compatible-mode/v1"
name = "Qwen3-Coder (Aliyun)"
env_key = "DASHSCOPE_API_KEY"

[models]
default = "qwen3-coder"

导人环境变量后启动：

export DASHSCOPE_API_KEY="sk-xxxxxxxxxxxxxxxx"
grok

在 TUI 内也可以动态切换：

/model qwen3-coder

这套机制的意义是：底层模型完全可插拔。任何 OpenAI 兼容 API——DeepSeek、Kimi、GLM、百炼 Qwen3-Coder、Ollama 本地模型——都可以接入 Grok Build 的 Rust 运行时。对于没有 xAI 订阅的团队，或者需要用国产模型的场景，这是关键能力。

4.4 Plan Mode 完整工作流

假设你要让 Grok Build 完成一个认证模块的 JWT 迁移：

> 请用 Plan Mode 帮我把这个仓库的认证从 session 迁移到 JWT + rotation。要求：保留 7 天兼容窗口，支持 token 刷新，所有改动需可回滚。

Agent 会先输出结构化计划（见上文格式）。你仔细 review 后：

• 输入 a（approve）：Agent 开始执行计划中的每一步
• 输入 c（comment）：对某个步骤写反馈，例如"第 3 步中的 middleware 路径不对，应该是 src/middleware/auth.ts"
• 输入 q（quit）：取消会话

执行过程中，每个步骤都会输出日志：

[Step 1/6] Adding jwtVerify helper in src/lib/jwt.ts
  Writing src/lib/jwt.ts... ✓
  Added: import { jwtVerify } from 'jose'
  Added: verifyAccessToken(token: string): Promise<JWTPayload>
  ✓ Step 1 complete

[Step 2/6] Adding /auth/refresh endpoint with rotating refresh tokens
  ...

如果某步骤失败，Agent 会停下来等你介入，而不是继续执行后面的步骤（后面的步骤可能依赖前面的成功状态）。

4.5 Subagents 并行工作

对于复杂的多模块分析任务，Subagents 可以把工作分片并行：

> 请用 Subagents 并行调研 p99 延迟回归的原因：
  1. explore-checkout：阅读 checkout 流程相关模块
  2. explore-infra-ci：检查部署和 CI 配置
  3. explore-shared-libs：阅读可观测性共享库
  4. explore-order-service：阅读订单服务
  5. explore-fulfillment-jobs：阅读履约任务
  6. explore-pricing-engine：阅读定价引擎

每个子代理独立工作，最终由主 Agent 汇总输出。

重要提醒：并行不等于一定正确。Subagents 的输出最终由主 Agent 汇总，开发者仍需审查最终 diff 和测试结果。如果仓库使用 git worktree，可以为每个子代理指定独立 worktree，避免多个 Agent 同时修改同一文件造成冲突。

4.6 MCP 接入实战

Grok Build 天然支持 MCP 协议，通过 grok mcp add 命令添加 MCP 服务：

# 把指定目录暴露给 filesystem MCP server
grok mcp add filesystem -- \
  npx -y @modelcontextprotocol/server-filesystem ./src

# 添加 Linear 的 MCP 服务
grok mcp add --transport http linear \
  https://mcp.linear.app/mcp

# 项目级配置（写入 .grok/config.toml，可提交到仓库）
grok mcp add --scope project filesystem -- \
  npx -y @modelcontextprotocol/server-filesystem ./src

添加完成后用 grok mcp doctor <name> 检查连通性。如果在 CI 环境中，首次运行可能因为下载依赖而超时，适当提高 startup_timeout_sec：

[mcp_servers.filesystem]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem", "./src"]
startup_timeout_sec = 60
tool_timeout_sec = 6000

4.7 Hooks 拦截危险操作

生产环境最怕的不是 Agent 写不出代码，而是它顺手改了一个不该动的文件。Hooks 在特定操作前后触发脚本，实现权限审计和危险命令拦截：

# ~/.grok/config.toml
[[hooks]]
event = "before_tool"
tool = "shell"
script = "~/.grok/hooks/guard-shell.sh"

#!/usr/bin/env bash
# guard-shell.sh — 拦截危险 shell 操作
set -euo pipefail

PAYLOAD=$(cat)
COMMAND=$(echo "$PAYLOAD" | jq -r '.input.command // ""')

# 危险操作拦截
if echo "$COMMAND" | grep -qE 'rm -rf /|git push --force|:!|sudo '; then
  echo "Blocked dangerous command: $COMMAND" >&2
  exit 2  # 非 0 退出码 = 拒绝执行
fi

echo "$PAYLOAD"

可用的 Hook 事件：

• before_run：在 Agent 开始运行前触发
• before_llm：在每次 LLM 调用前触发（可注入上下文）
• before_tool：在工具执行前触发（危险命令拦截）
• after_tool：在工具执行后触发（自动 lint、测试）
• after_run：在 Agent 完成后触发（审计日志）

4.8 无头模式与 CI 集成

脚本和 CI 场景不需要 TUI，Grok Build 支持无头模式：

grok -p "审查 src/auth.py 的安全漏洞" \
     --output-format streaming-json > audit.json

--output-format streaming-json 输出结构化流式 JSON，便于下游工具解析。

GitHub Actions 集成示例：

name: ai-code-review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Grok Build
        run: curl -fsSL https://x.ai/cli/install.sh | bash

      - name: Run review
        env:
          XAI_API_KEY: ${{ secrets.XAI_API_KEY }}
        run: |
          grok -p "审查本次 PR 的安全漏洞，列出发现的问题和修复建议" \
               --output-format streaming-json > review.json

      - name: Post comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = JSON.parse(fs.readFileSync('review.json', 'utf8'));
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: '## AI Code Review\n\n' + review.summary
            });

五、性能与调优：让 Grok Build 跑得更稳

5.1 模型选择与成本权衡

Grok Build 支持"默认模型 + 可替换端点"的双层设计。选择哪个模型取决于具体场景：

成本上，Grok-4.3 的 API 定价远高于开源模型，但对于"一次性的大型分析任务"，时间成本的节省可能远超 API 费用差。对于高频的日常开发任务，切换到 Qwen3-Coder 可以把单次成本降低 90% 以上。

5.2 上下文窗口的高效利用

200 万 token 的上下文不是无限的，聪明的上下文管理能显著提升效果：

1. 优先使用 @ 文件引用而非自然语言描述

# 低效：让 Agent 自己去读
> 帮我分析 src/auth 模块的认证逻辑

# 高效：直接用 @ 引用
> 帮我分析这个模块的认证逻辑 @src/auth/jwt.ts @src/auth/middleware.ts

@ 引用让 Agent 明确知道需要分析哪些文件，避免浪费上下文去猜测。

2. 善用 Plan Mode 中的 context 文件列表

Plan Mode 的输出中，每个步骤都标注了"涉及文件"。在 approve 之前确认文件列表是否完整，比执行完成后再修复遗漏要高效得多。

3. Subagents 的输出是累加的

8 个 Subagents 同时分析，每个输出约 5000 token，汇总后主 Agent 需要处理 40000 token 的中间结果。如果仓库太大，考虑先让 Subagents 做"索引"而非"分析"——让每个子代理只提取关键信息和文件引用，而不是写完整报告。

5.3 Hooks 的性能开销

Hooks 在每个工具调用前后都会触发脚本。如果 Hook 脚本本身很慢（例如每次触发时都读一个大文件），会显著拖慢 Agent 的整体响应速度。

建议把 Hook 脚本设计成无状态的轻量检查：

#!/usr/bin/env bash
# ✓ 好：O(1) 复杂度，固定时间完成
if echo "$COMMAND" | grep -qE 'rm -rf /|git push --force'; then
  exit 2
fi

# ✗ 坏：每次都读外部文件（拖慢）
CONFIG=$(cat ~/.grok/hooks/whitelist.json)

六、Grok Build vs Claude Code：什么时候选谁

这是每个想引入 Grok Build 的团队都会问的问题。以下是基于实际使用经验的分场景对比：

6.1 上下文需求对比

Grok Build 的 200 万 token 上下文 vs Claude Code 的 100 万 token，对于大多数场景这不是决定因素。但对于以下情况，上下文容量会成为瓶颈：

• 超大型 Monorepo（超过 100 万行源码）
• 需要同时读协议规范 + 源码实现 + 测试用例
• 多语言混合且每种语言都有大量文件

这些场景下，Grok Build 的优势是实质性的。

6.2 开源 vs 闭源

Claude Code：核心代理循环闭源，适合"直接用，不折腾"的团队。对于只是想提高日常开发效率的工程师，Claude Code 是更低摩擦的选择。

Grok Build：99.6% 开源，适合以下场景：

• 团队想研究"编码 Agent 底层怎么转"
• 需要把 AI 编码能力嵌入自研平台
• 想在模型层面做定制（不同任务用不同模型）

6.3 生态成熟度

这是 Grok Build 目前最大的短板。截至 2026 年 7 月：

• Claude Code：成熟的 marketplace（大量 pre-built skills/plugins）、完善的文档体系、活跃的社区
• Grok Build：开源刚满两周，社区 Skill/Plugin 数量有限，文档深度不足

对于需要"开箱即用"的团队，Claude Code 的生态优势在短期内难以撼动。对于愿意投入时间搭建体系的团队，Grok Build 的开放性提供了更大的定制空间。

七、总结与展望

Grok Build 在 2026 年 7 月的开源，是 xAI 从"聊天机器人"向"开发者工具链"扩张的标志性事件。它用 Rust 重建了运行时、用 ACP 协议打开了嵌入能力、用模型可替换设计解耦了依赖——这三个决策，每一个都是对当前 AI 编程工具封闭生态的直接回应。

对于国内开发者而言，最实用的价值有两点：

第一，模型可插拔意味着不受制于 xAI 订阅。 只要配置一个兼容 OpenAI API 格式的端点——百炼 Qwen、DeepSeek、Kimi——就可以把 Grok Build 的所有能力（Plan Mode、Subagents、MCP 接入、Hooks）嫁接到国产模型上。这在国内 AI 基础设施尚未完全开放的环境里，是非常实际的工程价值。

第二，ACP 协议让 AI 编码能力成为可集成的组件。 企业微信机器人、内部代码审查平台、自研 IDE 插件——有了 ACP 协议，这些场景不需要等待厂商开放 SDK，可以自己接入。

当然，Grok Build 目前仍处于 Early Beta 阶段。Rust 生态的工具体系（调试、日志、性能分析）与 Node.js/Python 相比尚不成熟；社区 Skill/Plugin 的数量与 Claude Code 差距明显；SuperGrok 订阅要求对于没有 xAI 账号的开发者仍是门槛。

但开源本身是最好的答案。当所有人都能读源码、改源码、提 PR 的时候，成熟度问题只是时间问题。