9.22 大语言模型研究简报：grok-4.7-harness-co-design-blog-zh发布

Grok 4.7：从更强推理走向 Model–Harness Co-design

北京时间 2026 年 9 月 22 日 00:17:53，SpaceXAI 发布了0 Grok 4.7。相比 Grok 4.6，这次最值得关注的并不是单一 benchmark 涨分，而是训练范式继续向 long-horizon agent + model–harness co-design 推进：更大的 base model、更长的 RL 训练、更高比例的多小时任务，以及对 Grok Bot harness 的原生训练适配。

换句话说，Grok 4.7 的目标已经不是单纯：

给定问题 → 生成答案

而是进一步变成：

任务
↓
进入 Agent Harness
↓
调用工具 / 维护上下文 / 检查结果
↓
长时间执行
↓
自我验证
↓
完成工作

这反映出一个越来越明显的前沿趋势：

模型能力开始与运行它的 Harness 一起被训练，而不是把 Harness 仅仅视作推理阶段的外部包装。

1. 核心规格

根据官方模型文档，Grok 4.7 的主要规格如下。

官方模型文档：
https://docs.x.ai/developers/models/grok-4.7

API Release Notes：
https://docs.x.ai/developers/release-notes

2. 更大的 Base Model

SpaceXAI 官方明确写道：

Grok 4.7 使用了一个相比 Grok 4.6 新的、更大的 base model。

这件事值得单独强调。

因为 Grok 4.6 的主要提升路线更多是：

supplemental training
+
better SFT trajectories
+
agentic RL

而 Grok 4.7 又进一步回到了底层模型容量的提升。

也就是说，整体路线变成：

Base Model Scaling
+
Longer RL
+
Harder Agent Tasks
+
Harness-specific Training

而不是只靠 post-training 榨取已有 checkpoint 的能力。

官方目前没有公布：

• 总参数量；
• Active Parameters；
• 是否 MoE；
• 训练 FLOPs；
• 具体 pretraining token 数。

因此不能把“更大的 base model”进一步推断成某种具体参数规模。

3. 更长 RL 训练时间，更长的任务

官方对 Grok 4.7 RL 训练的描述非常关键：

a longer reinforcement learning run
on a harder mix of tasks
weighted toward problems that take many hours to complete

这里真正重要的是最后一句：

训练任务分布被显式加权到需要多个小时才能完成的问题。

这和传统 reasoning RL 有明显区别。

普通数学 / coding RL 的 episode 往往接近：

problem
↓
reasoning
↓
answer
↓
verifier

而 long-horizon agent RL 更接近：

Task
↓
Inspect environment
↓
Plan
↓
Execute tool
↓
Observe
↓
Modify files
↓
Run tests
↓
Detect failure
↓
Re-plan
↓
Continue
↓
Verify
↓
Finish

训练目标因此不再只是：

[
P(\\text{correct final answer})
]

而开始涉及：

[
P(\\text{successful trajectory})
]

也就是：

整个任务轨迹是否最终完成。

4. Harness-aware Training

Grok 4.7 官方发布中最值得关注的一句话是：

We also trained Grok 4.7 to natively understand the Grok Bot harness.

这是这次发布最有研究价值的信号之一。

过去我们通常把系统拆成：

Model
+
External Harness

其中 Harness 在模型训练完成后才被接上。

例如：

LLM
↓
Agent Loop
↓
Tool Parser
↓
Shell
↓
Files
↓
Browser

模型本身并不天然理解这个 Runtime。

于是 Harness 需要通过：

• system prompt；
• tool schema；
• examples；
• error messages；

向模型解释：

你现在能做什么
工具有什么语义
运行环境怎样工作
什么算完成

Grok 4.7 则明确开始做：

Model Training
×
Harness Semantics

即：

让模型在训练阶段就看到并学习真实 Harness 的交互结构。

5. 什么叫 Model–Harness Co-design？

可以把传统 Agent 写成：

┌────────────────────┐
│ Model │
│ pretrained + RLHF │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Harness │
│ tools / state / UI │
└────────────────────┘

两者开发相对独立。

而 Model–Harness Co-design 更接近：

Training
│
┌───────┴────────┐
▼ ▼
Model Harness
▲ ▲
└──── feedback ──┘

模型训练过程知道：

• Harness 会提供什么工具；
• observation 怎么返回；
• context 如何组织；
• task completion 怎么表示；
• shell / browser / files 有什么语义；
• 如何从失败状态恢复；
• Harness 的 memory / session 结构是什么。

这意味着 Harness 不再只是产品工程。

它开始进入：

训练分布设计。

6. Harness-aware Training

考虑一个 coding Agent。

假设 Harness 规定：

每一次 bash 调用都在独立 shell 中执行

那么：

cd /repo

下一次 command 不一定仍在 /repo。

一个没有适配 Harness 的模型可能反复犯错：

cd repo
→ 下一轮
pytest
→ 在错误目录执行

传统解决办法是：

System Prompt:
Directory changes are not persistent.

但更进一步的做法是：

在训练轨迹中让模型反复经历这种 Runtime semantics。

这样模型学到的是：

Harness behavior

而不是临时从 prompt 中理解规则。

Grok 4.7 的 Grok Bot harness training，就是这个方向的实际信号。

7. 从“Test-Time Compute”走向“Trajectory-Time Compute”

近两年 reasoning model 的一个核心 scaling axis 是：

Test-Time Compute

即让模型在回答前思考更久。

例如：

low
medium
high
xhigh

Grok 4.7 仍然支持这一套 reasoning effort。

但 Agent 引入了另一个时间尺度：

Trajectory-Time Compute

它不只是：

一个 response 想 30 秒

而可能是：

Agent 持续工作 30 分钟
Agent 持续工作 2 小时
Agent 持续工作 8 小时

这两种 compute 不一样。

可以抽象成：

$$C_{\text{total}}=C_{\text{reasoning}}+C_{\text{trajectory}}+C_{\text{tools}}$$

对于长期 Agent，后两项越来越重要。

8. Long Context

Grok 4.7 保持：

500K token context window

单看数字，它并不是一次新的 context scaling。

但对于 long-running Agent，它的用途和普通聊天不同。

一个 Agent trajectory 可能包含：

system instructions
+ task
+ repository files
+ shell commands
+ test output
+ diffs
+ errors
+ planning notes
+ browser results
+ previous attempts

因此 long context 逐渐从：

“一次读一本很长的书”

转变成：

“持续维护任务 working memory”。

真正困难的问题变成：

• 哪些历史应该保留；
• 哪些应该 compact；
• 哪些 tool result 应该删除；
• 哪些失败路径应该留作 memory；
• 多小时后如何保持目标一致性。

这也是 Harness Engineering 和 Context Engineering 开始融合的原因。

9. Benchmark：Agent 任务提升明显

官方给出的主要 benchmark 包括：

* Grok 4.7 DeepSWE 使用 high effort。

其中最值得注意的是：

Terminal-Bench 4.0
20.3% → 38.0%

相对提升很大。

这类 benchmark 更偏：

terminal
+
multi-step interaction
+
environment execution

因此相比普通静态代码生成 benchmark，更接近 Agent Harness workload。

不过需要明确：

上表的大部分 launch benchmark 数字来自 SpaceXAI 官方自报，应等待更多第三方独立复测。

10. CursorBench 4.0

传统 coding benchmark 往往是：

function signature
↓
write function
↓
unit test

而 CursorBench 更偏向：

真实代码库
+
多轮修改
+
工具使用
+
测试反馈

这与 coding agent 的实际工作流更接近。

因此 Grok 4.7 从：

40.4%

提升到：

46.3%

比单纯 HumanEval 提升几个点更能说明：

模型在持续软件工程轨迹中的可靠性提高。

11. DeepSWE

官方 DeepSWE v1.1：

Grok 4.6：65.2%
Grok 4.7：71.0%

软件工程 Agent 的难点并不只是代码生成。

它通常需要：

理解 issue
↓
定位 repository
↓
搜索相关文件
↓
分析调用链
↓
修改代码
↓
运行测试
↓
处理失败
↓
重新修改
↓
验证 regression

所以研究对象已经从：

Code Generation

转向：

Software Engineering Trajectory

12. Self-verification

官方指出 Grok 4.7：

checks its own work more carefully

这与 Grok 4.6 延续下来的一条趋势一致。

Grok 4.6 的官方发布中已经提到：

longer trajectories
→ more self-testing
→ more verification

到了 Grok 4.7，这种行为继续被强化。

Agent 的一个核心问题是：

模型什么时候知道自己“真的完成了”？

弱 Agent 很容易：

修改代码
→ 看起来合理
→ 直接提交

更成熟的 Agent 应该：

修改
→ 测试
→ 检查输出
→ 查看 diff
→ 检查 edge case
→ 再提交

因此：

verification behavior

本身正在成为训练目标。

13. 与 Grok 4.6 的关系

Grok 4.6 已经明确定位：

long-running agents

其训练过程包括：

• longer supplemental training；
• regenerated SFT trajectories；
• multiple reasoning efforts；
• multiple agent harnesses；
• agentic RL tasks；
• kernel optimization；
• web development；
• CAD；
• knowledge work。

官方 Grok 4.6 发布：
https://x.ai/news/grok-4-6

Grok 4.7 则沿着这条路线继续向前：

Grok 4.6
Long-running agent training
↓
Grok 4.7
Larger base model
+
Longer RL
+
Harder multi-hour tasks
+
Native Grok Bot harness understanding

这说明 xAI / SpaceXAI 的 Agent 路线不是一次性的产品 feature，而是在逐步进入模型训练本身。

14. Harness 开始影响 Foundation Model

过去典型关系是：

Foundation Model
↓
Agent Framework
↓
Product

现在可能逐渐变成：

Foundation Model
↕
Agent Harness
↕
Training Environment
↓
Product

Harness 产生：

tool trajectories
failure traces
successful workflows
verification behavior
long-running tasks

这些数据又可以反过来进入：

SFT
RL
evaluation

于是形成闭环：

Model
↓
Harness
↓
Real trajectories
↓
Training data / reward
↓
Model

这可能是未来 Agent 模型最重要的数据飞轮之一。

15. Safety：新的 Safeguard Stack

SpaceXAI 表示 Grok 4.7 使用：

an entirely new safeguard stack

官方报告中提到：

• jailbreak resistance 更强；
• refusal calibration 改善；
• 在 cyber / bio 等 dual-use 领域强化安全策略；
• LatchBio biosafety benchmark 达到 62.4%；
• HackerBench v0.3 中，仅 3.3% 的 risky dual-use prompts 被允许通过。

需要注意：

这些数字目前主要来自官方发布材料，不能直接等同于外部独立安全审计结论。

16. Pricing：能力提升但保持同一基础价位

Grok 4.7 基础价格维持：

Input:
$2 / 1M tokens

Cached input:
$0.50 / 1M tokens

Output:
$6 / 1M tokens

当 prompt 超过：

200K tokens

价格提升为：

Input:
$4 / 1M

Cached input:
$1 / 1M

Output:
$12 / 1M

这里对 Agent 系统尤其重要。

因为 long-running Agent 的真实成本不是：

single request cost

而是：

$$\text{Task Cost}=\sum _{i=1}^N({\text{input}}_i+{\text{output}}_i)$$

其中 (N) 可能是数十乃至数百次模型调用。

所以：

context compaction
prompt caching
tool output pruning

仍然是 Harness 的核心系统问题。

17. Fast Variant

SpaceXAI 同时提供 Grok 4.7 Fast。

官方说明：

same model
+
faster serving infrastructure

价格为标准版本约两倍。

但它目前：

Cursor
Grok Build

可用，而不是公开 xAI API 的独立模型 endpoint。

这说明模型公司开始把：

Model Quality

和：

Serving Latency

作为两个独立的产品维度。

对 Agent 来说，这一点非常重要，因为：

40-step tool trajectory

如果每一轮模型 latency 从：

5 s → 2.5 s

最终 wall-clock time 会有明显差距。

18. Harness Engineering

如果从 Harness Engineering 的角度看，这次发布最值得跟的并不是：

CursorBench +5.9

而是：

natively understand the Grok Bot harness

因为这意味着一个可能越来越重要的研究方向：

Harness-conditioned Training

未来模型训练数据可能显式包含：

Harness A trajectory
Harness B trajectory
Browser runtime
Terminal runtime
Coding runtime
Office runtime
Robot runtime

甚至不同 Harness 可能对应不同：

action semantics
memory model
state representation
permission system
observation format

模型必须学习这些环境的 operating semantics。

这和机器人领域其实很相似。

19. 与机器人 Agent 的类比

机器人系统里常见：

Planner
↓
Controller
↓
Robot
↓
Sensor feedback
↓
State estimator
↓
Planner

LLM Agent Harness 则是：

LLM
↓
Harness
↓
Tool / Computer
↓
Observation
↓
Context / State
↓
LLM

对应关系大致是：

如果模型训练时就暴露给 Harness：

本质上就是让 Planner 在训练阶段学习 Controller / Runtime 的真实 dynamics。

这可能明显提高长时程执行的稳定性。

Harness-specific training

如果模型针对：

Grok Bot harness

深度优化，会不会在：

Cursor
GitHub Copilot
OpenHands
自定义 Agent framework

中表现不同？

真正理想的目标应该是：

Harness-aware
但不是
Harness-overfit

Harness Tokens

未来模型是否会像学习：

<tool_call>
<tool_result>

一样，进一步学习：

<session>
<checkpoint>
<filesystem>
<browser_state>
<permission>
<task_complete>

这样的 runtime-native representation？

这会直接影响 Agent model architecture。

RL episode

如果今天是：

hours

未来是否会出现：

days

级别任务？

这会带来新的 RL 问题：

• reward sparsity；
• credit assignment；
• trajectory storage；
• environment replay；
• checkpoint；
• failure recovery；
• asynchronous tools。

external memory

500K context 能支撑较长轨迹，但持续 Agent 最终不可能把一切永久塞进 context。

因此未来路线很可能是：

Short-term context
+
Compaction
+
Persistent memory
+
External state

而不是无限扩大 context window。

参考链接