Grok 4.7上线Amazon Bedrock：官方博客实测四种推理强度，xhigh级 18 次全部答对
AWS机器学习博客介绍了SpaceXAI的Grok 4.7在Amazon Bedrock上的可用情况，并用三个需要搜索而非查表的一次性答案任务做了 72 次智能体运行评测。据SpaceXAI公布的数据，Grok 4.7在多项长时程任务基准上较Grok 4.6有提升。
AI解读：据SpaceXAI说法，Grok 4.7使用比Grok 4.6更大的基础模型，并在更难的任务组合上做了更长的强化学习训练，官方报告该模型更擅长自检和管理更长上下文。
AWS博客的实测中，三个任务各有唯一正确答案并用暴力枚举验证，低、中、高、极高四档推理强度各跑 6 次，共 72 次，答对 67 次；xhigh档 18 次全对，low档 18 次对 15 次且输出token约为xhigh的八分之一，说明推理强度可按请求调节。
三个任务的平均工具调用次数在四档之间基本持平（17.2 至 18.7 次），说明提高推理强度改变的是对已获取事实的思考量，而非探索范围；该结论仅来自这一合成环境、单一模型版本和单次提示词配置。
AWS机器学习博客发布文章，介绍SpaceXAI的Grok 4.7已在Amazon Bedrock上可用。文章称Grok 4.7通过bedrock-runtime端点访问，使用跨区域推理配置文件，可选us.xai.grok-4.7（美国地理范围）和global.xai.grok-4.7（商业AWS区域）；模型支持OpenAI兼容的Chat Completions、Responses API以及Amazon Bedrock Converse API，并支持可配置推理强度、工具调用和结构化输出。
据SpaceXAI公布的信息，Grok 4.7支持 500K token上下文窗口，输入为文本和图像，输出为文本。在Converse上，推理内容通过reasoningContent块与文本块一同返回；inferenceConfig中只设置maxTokens，推理强度等模型特定参数放在additionalModelRequestFields。
SpaceXAI报告的基准提升集中在长时程任务
文章引用SpaceXAI的说法称，Grok 4.7使用比Grok 4.6更大的基础模型，并以更长的强化学习训练运行在更难的任务组合上，该组合偏重需要数小时完成的问题。SpaceXAI报告其自检能力和更长上下文管理能力有所提升。
SpaceXAI公布的基准数据显示，较Grok 4.6提升最大的是衡量持续工作的类别：Terminal-Bench 4.0从 20.3% 升至 37.6%，EEBench从 53.0% 升至 64.0%，Harvey法律智能体基准从 15.8% 升至 19.6%，CursorBench 4.0从 40.4% 升至 46.3%，HealthBench从 48.5% 升至 56.7%，AA Briefcase v1.1从 1546 升至 1657。文章注明这些分数为SpaceXAI在模型发布时公布。
- Terminal-Bench 4.0（多小时终端工作）：20.3% → 37.6%
- EEBench（电气工程）：53.0% → 64.0%
- Harvey法律智能体基准：15.8% → 19.6%
- CursorBench 4.0（较长时编码）：40.4% → 46.3%
- HealthBench（专业临床推理）：48.5% → 56.7%
- AA Briefcase v1.1（多小时办公工作）：1,546 → 1,657
AWS博客的评测设置与结果
博客构建了一个工具调用智能体，在由 20 个服务、7 个工具构成的合成环境中运行三个需要搜索而非查表的一次性答案任务：从告警诊断两个静默故障服务、在相互制约的约束下安排维护计划、在预算内选择最优迁移集合。每个任务只有一个正确答案，并用暴力枚举事先验证。
评测在每个推理强度档位（low、medium、high、xhigh）各跑三个任务 6 次，共 72 次运行。智能体总计答对 67 次。xhigh档 18 次全部答对，medium和high各答对 17 次，low档答对 15 次。三个任务在各档的对错分布为：two_fault_diagnosis 5/6、6/6、6/6、6/6；maintenance_schedule 5/6、5/6、5/6、6/6；migration_budget 5/6、6/6、6/6、6/6。
每档的平均输出token分别为low 1,184、medium 6,430、high 6,778、xhigh 9,147；相对low的倍数分别为 1.0x、5.4x、5.7x、7.7x。平均工具调用次数依次为 17.2、18.7、17.8、18.1，各档基本持平。运行中位耗时从low的 18 秒到xhigh的 106 秒。博客称，由于每个任务每档只跑 6 次，各档差异属于指示性而非统计结论，但三个任务的方向一致。
博客还给出使用细节：推理token计入输出token并先于答案文本消耗max_completion_tokens，若在推理阶段达到上限则响应不返回答案文本。其运行使用 32,768 token上限。Grok 4.7支持low、medium、high、xhigh四档推理强度，博客建议向服务确认可用档位而非硬编码列表。
- 72 次运行总计答对 67 次；xhigh档 18/18，medium与high各 17/18，low档 15/18
- 平均输出token：low 1,184 / medium 6,430 / high 6,778 / xhigh 9,147
- 平均工具调用：17.2–18.7 次，各档基本持平
- 运行中位耗时：18 秒（low）至 106 秒（xhigh）
- 各任务每档 6 次运行，博客称差异为指示性
博客报告的任务类型差异与限制
博客将三个任务按难度类型区分：迁移预算任务奖励考虑组合而非逐项排序，按单项比例最高挑选会比最优解低 9 分，medium及以上在全部 18 次运行中找到最优集合；故障诊断任务要求双向检验候选对，medium及以上全部答对；排班任务包含十条约束加一条依赖查得归属数据的同团队规则，xhigh档每次都能得到有效排班，这也是最高档差异最明显的任务。博客由此称，额外推理强度在需要权衡多个候选答案时价值最大。
博客列出了该测量本身的限制：每任务每档 6 次运行，只能显示一致趋势，不足以给出置信区间；环境为合成环境，工具从代码生成的数据读取，真实工具会带来延迟、部分结果和错误；运行时间在分钟级而非小时级，是长时程工作的缩小代理；结论仅来自一个模型版本、一个区域、每任务一套提示词；报告的是token数而非费用。
- 迁移任务：按单项比例最优会比真实最优低 9 分；medium及以上 18/18 找到最优集合
- 诊断任务：medium及以上 18/18 找到正确服务对
- 排班任务：xhigh每次得到有效排班，最高档差异最明显
- 限制：6 次重复不足做置信区间；合成环境；分钟级而非小时级；单一模型版本与区域；token数而非费用
生产监控与运维建议
博客提出在生产中没有已知答案可评分时，可用输出token和工具调用次数作为运行信号：medium及以上每一正确运行至少使用 1,739 输出token；没有工具调用或输出远低于同档正常水平的运行值得标记复查。基线应利用已评分的运行按任务和档位校准，标记结果作为检查或重跑的提示，low档因每次运行都简短，需辅以抽查。
运维方面，博客建议对高调用量智能体把重试纳入设计：设置请求超时，仅重试可重试的错误，采用带抖动的指数退避，并在返回Retry-After头时遵守；按需吞吐会随时间扩展，新增高负载工作负载应逐步提升而非直接满速；模型调用日志可写入Amazon S3或Amazon CloudWatch Logs。
博客还建议按任务类型匹配推理强度，并把强度按请求而非按智能体设置：规划与验证步骤用较高档，格式化工具结果等机械步骤用low档。文中称该做法可兼得较高级别的可靠性和较低的token成本。
- 正确运行在medium及以上至少使用 1,739 输出token
- 无工具调用或输出低于同档已评分最低值五分之一时标记复查
- 重试策略：超时设置、仅重试可重试错误、指数退避加抖动、遵守Retry-After
- 模型调用日志可写入Amazon S3或Amazon CloudWatch Logs
- 推理强度按请求设置，可在规划/验证步骤用高档、机械步骤用low档