Grok 4.7 上线 Amazon Bedrock：长程智能体推理强度实测与工具调用评估指南

SpaceXAI 的 Grok 4.7 现已在 Amazon Bedrock 上可用，该平台提供来自多家提供商的基础模型（FM）选择。据 SpaceXAI 介绍，Grok 4.7 经过训练，能够在更复杂的任务上持续工作更长时间，并知道何时检查自身的工作成果。这一点对于智能体（agent）尤为重要，因为智能体需要在多个步骤中推进任务，并必须在过程中验证所发现的信息。

以这种方式工作的智能体不能仅仅查找信息。它必须形成候选答案，将其与已学到的知识进行核对，并不断修正直至匹配。Grok 4.7 提供了一个推理努力程度（reasoning effort）设置，用于控制每次响应前的深思熟虑程度；对于智能体工作负载而言，一个实际的问题是应该运行哪个级别。

在这篇文章中，我们基于 Grok 4.7 构建了一个工具调用智能体，并在三个需要搜索而非简单查表的任务上对其进行评估。这些任务包括：根据警报诊断双服务故障、在相互约束的条件下安排维护计划，以及在预算限制下选择最优迁移方案集。每个任务都有且仅有一个正确答案，并通过暴力枚举法进行了验证。我们在所有推理努力程度级别上运行了这三个任务各六次，共计 72 次智能体运行。

该智能体在 72 次运行中有 67 次给出了正确答案。在 xhigh 级别下，18 次运行全部正确；而在 low 级别下，18 次运行中有 15 次正确，同时输出 token 用量约为前者的八分之一。这提供了一个清晰的权衡选项，你可以针对每个请求进行调整。我们将展示如何在自己的任务上测量这一权衡，以及如何在生产环境中对其进行监控。

全文始终以 token 数量而非货币金额作为报告指标。Token 价格会变动，而 token 数量才是你计算自身成本的依据，因此以 token 为单位的测量结果更具持久有效性。

SpaceXAI 关于 Grok 4.7 的报告

据 SpaceXAI 称，Grok 4.7 使用了比 Grok 4.6 更大的基础模型，并在更难的任务混合集上进行了更长时间的强化学习训练。这种任务组合偏向于那些需要数小时才能完成的问题。SpaceXAI 表示，该模型在自我工作验证和管理更长上下文方面表现更佳。

SpaceXAI 发布的基准测试结果印证了这一侧重点。相较于 Grok 4.6，最大的性能提升出现在衡量持续工作能力而非单轮回答表现的类别中。

来源：SpaceXAI，《介绍 Grok 4.7》（https://x.ai/news/grok-4-7）。分数为 SpaceXAI 在模型发布时公布的数值。

基准测试展示了模型在标准任务上的表现。对于您自己的工作负载，有用的下一步是在与您实际任务形态相似的任务上进行测量，这正是本文后续部分将要介绍的内容。

SpaceXAI 列出 Grok 4.7 拥有 500K token 的上下文窗口，支持文本和图像输入以及文本输出。在 Amazon Bedrock 上，该模型支持可配置的推理努力程度、工具调用和结构化输出。

如何在 Amazon Bedrock 上访问 Grok 4.7

Grok 4.7 运行在 bedrock-runtime 端点上，并通过 跨区域推理 配置文件进行访问。提供两个配置文件：

跨区域推理将请求路由到多个 AWS 区域，从而为您提供更高的吞吐量，而无需逐个区域管理容量。请求指定的是其中一个推理配置文件，而不是裸模型 ID。

该模型支持 OpenAI 兼容的 Chat Completions 和 Responses API，以及 Amazon Bedrock Converse API。在 Converse API 中，推理结果作为 reasoningContent 块与 text 块一起返回。在 inferenceConfig 中，仅设置 maxTokens，并将模型特定参数（如推理努力程度）放在 additionalModelRequestFields 中。

有关当前支持的区域、服务层级和 token 价格列表，请参阅 Amazon Bedrock 用户指南中的 Grok 4.7 模型卡片以及 Amazon Bedrock 定价页面（https://aws.amazon.com/bedrock/pricing/）。

先决条件

• 拥有 Amazon Bedrock 访问权限的 AWS 账户，并已启用对 Grok 4.7 的模型访问。
• Python 3.9 或更高版本，并安装了 openai、boto3 和 aws-bedrock-token-generator。
• 在环境中配置了 AWS 凭证。

你的 AWS Identity and Access Management (IAM) 身份需要在推理配置文件（inference profile）和你账户的默认项目上拥有 bedrock:InvokeModel 权限：

• arn:aws:bedrock:{region}::inference-profile/us.xai.grok-4.7 或其对应的 global. 等效项。
• arn:aws:bedrock:{region}:{account-id}:project/default。

请在策略语句中包含这两个资源。除了推理配置文件外，还需要默认项目的权限。

连接到模型

对于生产环境，我们建议从现有的 AWS 凭证生成短期 bearer token，这样身份验证将绑定到你的 IAM 身份，并且无需存储长期有效的密钥：

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

REGION = "us-west-2"
MODEL_ID = "us.xai.grok-4.7"

client = OpenAI(
    api_key=provide_token(region=REGION),
    base_url=f"https://bedrock-runtime.{REGION}.amazonaws.com/openai/v1",
    timeout=360,
    max_retries=0,  # retries are handled explicitly, see "Build in retries" below
)

推理令牌（Reasoning tokens）计入输出令牌，并在生成答案文本之前消耗 max_completion_tokens，因此设置限制时需为两者留出空间。如果在推理过程中达到限制，响应将不包含答案文本，因此在代理代码中检查空内容，如果发现此情况请提高限制。我们的运行使用了 32,768 个令牌的限制，这在每个努力级别（effort level）下都留有余量。

Grok 4.7 支持四个努力级别：low、medium、high 和 xhigh。努力级别可能会随模型版本变化，因此值得通过服务确认它们，而不是硬编码列表：

def supported_effort_levels(candidates=("none", "low", "medium", "high", "xhigh", "max")):
    supported = []
    for level in candidates:
        try:
            client.responses.create(model=MODEL_ID, input="Say OK.",
                reasoning={"effort": level}, max_output_tokens=2048)
            supported.append(level)
        except Exception as exc:
            if "unsupported_value" not in str(exc) and "invalid_value" not in str(exc):
                raise
    return supported

print(supported_effort_levels())  # ['low', 'medium', 'high', 'xhigh']

设计需要推理的任务

许多 agent 评估测试的是勤勉度：读取记录、筛选、汇总。这些任务固然有价值，但要观察推理努力（reasoning effort）的贡献，任务必须需要搜索：答案不能直接从数据中读出，而必须先提出假设再加以验证。

我们构建了一个包含 20 个服务的合成环境，通过七个工具暴露接口，并在其上设计了三个任务。每个任务都有且仅有一个正确答案，且每个任务的设计都确保简单的启发式方法不足以找到答案。

四项实践可确保此类测量结果的可信度，它们适用于大多数 agent 评估。

明确列出评分器所依赖的所有规则。 如果提示词留下了未定义的边缘情况，合理的答案可能被判定为错误，导致评估最终衡量的是规范而非模型能力。例如，诊断任务的提示词明确指出：失败的服务不会触发自身的警报。

证明每个任务只有一个答案。 每个环境都足够小，可以进行枚举，因此我们在运行任何测试之前检查了所有候选答案。对于排班任务，只需几行代码即可实现：

import itertools

ALL_SLOTS = sorted(set(itertools.permutations([1, 1, 2, 2, 3, 3, 4, 4])))

def valid_schedules(services, constraints):
    return [s for slots in ALL_SLOTS
        if satisfies(s := dict(zip(services, slots)), constraints)]

assert len(valid_schedules(SERVICES, CONSTRAINTS)) == 1  # exactly one answer
assert len(valid_schedules(SERVICES, CONSTRAINTS_WITHOUT_TEAM_RULE)) > 1  # the rule matters

仅对必需的最后一行进行评分，而非整个响应。 每个提示都要求智能体以类似 FINAL: auth, checkout 的行结尾。评分器只读取该行，因此即使响应在解释推理过程中讨论了其他候选项，其评分也仅基于结论：

def final_line(answer):
    lines = [l for l in (answer or "").splitlines() if "FINAL" in l.upper()]
    return lines[-1] if lines else None

将格式与正确性分开追踪。 缺失最终行与最终行内容错误是两种不同的信号。在我们的运行中，所有 72 个响应都包含了可评分的最终行。

当有效值已知时，使用 enum 约束工具参数，从而确保每次工具调用都针对真实资源：

TOOLS = [
    {"type": "function", "function": {
        "name": "get_dependencies",
        "description": "Services that one service directly depends on.",
        "parameters": {
            "type": "object",
            "properties": {"service": {"type": "string", "enum": SERVICE_NAMES}},
            "required": ["service"],
        }}},
    # The remaining six tools follow the same shape.
]

系统提示刻意保持简短，并要求智能体在给出答案前检查其回答：

AGENT_SYSTEM = (
    "You are an infrastructure analyst agent. Use the tools to gather facts and never guess "
    "a value you can look up. Before answering, check your answer against every rule in the "
    "task. End with the FINAL line exactly as the task specifies."
)

智能体循环是一个标准的工具调用循环：设置 reasoning_effort 后调用模型，执行每个返回的工具调用，将结果按 tool_call_id 追加，并重复此过程直到模型不再请求工具。在整个循环中跟踪 prompt_tokens 和 completion_tokens，即可得到下一节中报告的 token 计数。

结果

在每个 effort 级别下对每个任务运行六次，共计 72 次运行。智能体正确回答了 67 次。

图 1：各推理努力等级下的正确回答比例（左），以及每次运行的平均输出 token 数并叠加了每次运行的中位秒数（右）

有三点观察结果。

xhigh 在所有运行中都给出了正确答案。 在三个任务的全部 18 次运行中，xhigh 均回答正确；而 medium 和 high 各自在 18 次运行中有 17 次回答正确。由于每个任务和等级仅有六次运行，不同等级之间的差异仅具指示性而非统计显著性，但在所有三个任务中趋势保持一致。

努力程度改变的是智能体推理的深度，而非探索的广度。 工具调用次数基本持平，在每个等级下均为每次运行 17.2 到 18.7 次之间。无论努力程度如何，智能体收集的事实相同，变化在于它对这些事实应用的推理量——输出 token 数从 low 时的 1,184 增加到 xhigh 时的 9,147。

low 提供了极佳的性价比。 在 low 等级下，智能体使用约为 xhigh 八分之一的输出 token 数，在 18 次运行中正确回答了 15 次，且单次运行的中位耗时仅为 18 秒。如果可以接受略低的完成率，或者答案会在下游经过审核，那么 low 是一个高效的选择。如果要求每次答案都必须一次性正确，则较高的等级是更稳妥的默认选项。

努力等级如何塑造答案

这些任务是围绕特定类型的难度设计的，考察各努力等级如何处理这些任务，有助于明确何时额外的推理是值得的。

优化。 迁移任务奖励那些考虑组合方案而非逐一排序选项的行为。选择具有最佳单项比率候选项会产生一个合理的答案，但比最优解低九分。在 medium 及以上等级，智能体在全部 18 次运行中都找到了最优集合。

假设检验。 诊断任务要求双向检查候选配对：每个告警都必须得到解释，且每个保持静默的服务也必须与答案一致。在 medium 及以上级别，智能体在全部 18 次运行中都识别出了正确的配对。

约束满足。 调度任务结合了十项列出的约束条件以及一条依赖于查询到的所有权数据的团队规则。xhigh 在每次运行中都生成了有效的调度方案，这也是最高推理级别带来最显著差异的任务。

这三类任务的共同模式表明：当智能体需要在多个候选答案之间进行权衡比较时，而非沿着单一路径推导结果时，额外的推理努力最具价值。

在生产环境中监控推理过程

在生产环境中，你没有已知的标准答案可供评分，但你确实知道每次运行消耗的输出 token 数量和工具调用次数。这些指标提供了有用的运营信号。

各级别中正确的运行都保持在一定的推理量底线之上。medium 及以上级别的每一次正确运行至少使用了 1,739 个输出 token，典型运行则使用数千个 token。如果某次运行没有发起任何工具调用，或者其输出量远低于该级别的正常水平，则值得标记以供审查：

def flag_for_review(run, baseline):
    """baseline: output tokens of graded, correct runs at the same effort level."""
    reasons = []
    if run["tool_calls"] == 0:
        reasons.append("made no tool calls")
    if run["output_tokens"] < 0.2 * min(baseline):
        reasons.append(f"used {run['output_tokens']} output tokens, "
            f"under a fifth of the lowest correct run ({min(baseline)})")
    return reasons

根据你已评分的运行数据，按任务和推理级别校准基线，然后将其应用于尚未评分的运行。将标记视为触发人工检查或重新运行的提示。在 low 级别下，由于每次运行都很简短，输出量作为信号的强度较弱，因此应结合抽查来使用。

在系统提示词中要求智能体验证其答案是值得保留的做法，因为这能让你在审查运行时更清晰地追踪智能体的推理过程。在存在已知答案的情况下，应将其与自动评分相结合，以便独立于对话记录来衡量质量。

选择推理级别

这些结果揭示了若干实用准则。

根据任务类型匹配推理强度。 涉及搜索、优化或假设验证的任务，最适合使用 medium 或更高的推理强度。那些遵循单一路径，或其结果会在下游被审查的任务，可以在 low 级别高效运行。

按请求而非按代理设置推理强度。 推理强度是请求参数，因此代理可以在其规划和验证步骤中使用较高的推理强度，而在机械性步骤（如格式化工具结果）中使用 low 级别。这样既能在很大程度上保留较高级别的可靠性，又能降低 token 成本。

在自有任务上进行测量，并重复实验。 每种配置单次运行只能提供一个观测值。对每种配置进行多次重复运行，可以展示其一致性程度。

监控推理量。 按推理强度级别跟踪每次运行的输出 token 数和工具调用次数，可在结果被使用前提供早期信号以供审查。

本次测量的局限性

每个任务和推理强度级别仅六次运行。 这足以在三个任务上展示一致的趋势，但不足以计算置信区间。请将不同级别之间的差异视为指示性参考。

合成环境。 工具读取的是由代码生成的数据，这使得能够证明每个任务都有唯一正确答案并实现自动评分。真实工具会引入延迟、部分结果和错误，这些均未在此测试中涵盖。

分钟级，而非小时级。 中位运行时间从 low 级别的 18 秒到 xhigh 级别的 106 秒不等。这是长周期工作的一个缩小版代理指标。该方法可迁移，但绝对数值不可直接套用。

单一模型版本、单一区域、每个任务单一提示词。 同一任务的不同表述可能会改变结果，这也是为何明确陈述每条规则如此重要的一部分原因。

Token 计数，而非成本。 若要转换为货币成本，请根据 Amazon Bedrock 定价页面应用当前推理配置文件和服务层级的费率。Global 和 US Geo 配置文件的定价不同，且 Flex 和 Priority 服务层级会应用乘数系数。

代理工作负载的运行控制

内置重试机制。 发起大量调用的代理应将重试作为设计的一部分。设置请求超时时间，仅对可重试的错误进行重试，采用带抖动的指数退避策略，并在返回 Retry-After 头时予以遵守：

import random, time

RETRYABLE = {408, 429, 500, 502, 503, 504}

def call_with_backoff(fn, attempts=7, base=4.0, cap=180.0):
    for attempt in range(1, attempts + 1):
        try:
            return fn()
        except Exception as exc:
            status = getattr(exc, "status_code", None)
            retryable = status in RETRYABLE or "timed out" in str(exc).lower()
            if not retryable or attempt == attempts:
                raise
            time.sleep(random.uniform(base, min(cap, base * 2 ** attempt)))

按需吞吐量会随时间逐步提升，因此对于新的高流量工作负载，应逐渐增加请求速率，而不是一开始就以全速运行。

审计运行过程。 模型调用日志会将请求和响应数据写入 Amazon Simple Storage Service (Amazon S3) 或 Amazon CloudWatch Logs。这为你提供了完整的事务记录，便于事后审查。

大规模监控推理量。 Amazon CloudWatch 指标提供令牌使用量的聚合视图，这使得前文提到的各层级基线成为可设置警报的依据。

跨代理归因支出。 AWS Cost Explorer 中的成本明细项以及 AWS 成本和用量报告可按模型细分使用情况，结合每个任务的令牌计数，你可以同时获得单位经济性和总体账单详情。

匹配成本与紧急程度。 服务层级是按请求设置的，因此同一部署可以通过 Flex 层级处理夜间分析任务，并通过 Priority 层级处理交互式请求。对于以更高努力级别运行的工作负载，层级选择是进一步控制成本的杠杆。

选择路由配置文件。 跨区域推理扩大了长时间运行所依赖的容量池。Global 配置文件从你选择的商业 AWS 区域提供服务，其每令牌价格通常低于地理路由。US 配置文件将处理保留在美国境内。请根据数据驻留要求以及成本进行选择。

清理资源

本文中的示例除了按请求产生的令牌使用费外，不会创建其他计费 AWS 资源。如果你生成了长期有效的 Amazon Bedrock API 密钥，请在完成后在 Amazon Bedrock 控制台中将其删除，因为该密钥在被撤销前始终有效。由 IAM 凭证生成的短期令牌会自动过期。

如果你在测试期间启用了向 Amazon S3 的模型调用日志记录，请检查存储桶并移除不再需要的对象。

结论

SpaceXAI 训练了 Grok 4.7，使其能够在更困难的任务上投入更多时间，并懂得何时检查自身的工作成果。在三项需要搜索而非简单查找的任务中，该智能体在 72 次运行中正确回答了 67 次，且所有运行均处于 xhigh（超高推理强度）级别。由于推理强度是按请求设置的，你可以自行决定智能体的每个步骤在“彻底性”与“Token 成本”之间的权衡位置。

有三点值得你在自己的评估体系中借鉴：设计具有唯一可验证答案的任务，并明确列出评分器所依赖的所有规则；重复运行测试，以观察每种配置的稳定性；按推理强度级别监控输出 Token 数量和工具调用次数，从而在质量指标之外获得运营层面的信号。