Grok 4.7 智能体如何平衡推理成本

SpaceXAI 的 Grok 4.7 现已在 Amazon Bedrock 上推出。Amazon Bedrock 提供来自多家供应商的基础模型（FM），供用户选择。据 SpaceXAI 介绍，Grok 4.7 经过训练，能够在更困难的任务上持续工作更长时间，并且知道何时检查自己的工作。这一点对 AI 智能体尤其重要，因为它们需要经过多个步骤完成任务，并在过程中验证自己的发现。

以这种方式工作的 AI 智能体，不能只会查找信息。它必须提出候选答案，根据已经获取的信息进行核验，并不断改进，直到答案符合要求。Grok 4.7 提供了推理强度设置，用于控制每次响应前的思考程度。对于 AI 智能体工作负载，一个实际问题是：应该使用哪个强度级别。

本文将基于 Grok 4.7 构建一个支持工具调用的 AI 智能体，并用三项需要搜索求解、而非直接查找答案的任务对其进行评估。这三项任务分别是：根据告警诊断涉及两个服务的故障、在相互影响的约束下安排维护，以及在预算限制下选择最优的迁移组合。每项任务都只有一个正确答案，并通过穷举验证。我们在每个推理强度级别下，将三项任务各运行六次，共完成 72 次 AI 智能体运行。

在这 72 次运行中，AI 智能体有 67 次回答正确。在 xhigh 级别下，18 次全部正确；在 low 级别下，18 次中有 15 次正确，而输出 token 用量约为 xhigh 的八分之一。这呈现出一个明确的权衡，你可以针对每个请求进行调整。我们还将展示如何在自己的任务上衡量这一权衡，以及如何在生产环境中监控它。

全文报告的都是 token 数量，而非货币金额。token 价格会变化，而你的实际成本取决于 token 用量，因此，以 token 表示的测量结果能够持续保持有效。

SpaceXAI 对 Grok 4.7 的介绍

据 SpaceXAI 介绍，Grok 4.7 使用了比 Grok 4.6 更大的基础模型，并针对一组难度更高的任务，进行了更长时间的强化学习训练。这组任务更侧重于需要数小时才能完成的问题。SpaceXAI 表示，该模型在验证自身工作和管理更长上下文方面都有所改善。

SpaceXAI 公布的基准测试结果也体现了这一侧重点。与 Grok 4.6 相比，报告中最大的提升出现在衡量持续工作能力、而非单轮回答能力的类别中。

来源：SpaceXAI，《Introducing 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 中，推理内容以 reasoningContent 块的形式返回，与文本块并列。在 inferenceConfig 中，只设置 maxTokens；推理强度等模型专属参数应放在 additionalModelRequestFields 中。

有关当前支持的区域、服务层级和 token 价格，请参阅《Amazon Bedrock 用户指南》中的 Grok 4.7 模型卡，以及 Amazon Bedrock 定价页面。

一个能够访问 Amazon Bedrock，且已启用 Grok 4.7 模型访问权限的 AWS 账户。

Python 3.9 或更高版本，并已安装 openai、boto3 和 aws-bedrock-token-generator。

在环境中配置好 AWS 凭证。

你的 AWS Identity and Access Management（IAM）身份需要对推理配置文件和账户的默认项目同时拥有 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
)

推理 token 计入输出 token，并且会在生成答案文本之前消耗 max_completion_tokens 配额，因此，设置上限时要为两者都留出空间。如果在推理过程中达到上限，响应就会返回，但不包含答案文本。因此，请在 AI 智能体代码中检查内容是否为空；如果出现这种情况，就提高上限。我们的运行使用了 32,768 token 的上限，在每个推理强度级别下都留有余量。

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']

设计需要推理的任务

许多 AI 智能体评估测试的是执行是否细致：读取记录、筛选记录、求和。这些任务值得保留，但要看出推理强度带来的作用，任务就必须需要搜索求解：答案不能直接从数据中读出来，而是必须先提出，再验证。

我们构建了一个包含 20 个服务的合成环境，通过七个工具向 AI 智能体开放，并在此基础上设计了三项任务。每项任务都只有一个正确答案，而且在设计上，简单的启发式方法不足以找到答案。

以下四项实践可以保证这类测量的可信度，也适用于大多数 AI 智能体评估。

明确说明评分程序依赖的每一条规则。如果提示词没有明确某个边界情况，合理的答案也可能被判为错误，最终评估衡量的就会是任务规范，而非模型能力。例如，诊断任务的提示词明确说明：发生故障的服务本身不会发出告警。

证明每项任务只有一个答案。每个环境的规模都足够小，可以穷举，因此，我们在开始运行之前检查了所有候选答案。对于维护安排任务，只需要几行代码：

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

只对要求输出的最终答案行评分，而非整个响应。每个提示词都要求 AI 智能体以类似 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.
]

系统提示词刻意保持简短，并要求 AI 智能体在给出答案之前先进行检查：

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 数量。

在每个推理投入级别下，每项任务各运行六次，总计 72 次。智能体正确完成了其中 67 次。

图 1：各推理投入级别下正确完成的运行占比（左），以及每次运行的平均输出 Token 数量，叠加每次运行耗时的中位数（右）

xhigh 在每次运行中都给出了正确答案。三项任务在 xhigh 下的 18 次运行全部正确，medium 和 high 则各正确完成了 18 次中的 17 次。每项任务在每个级别下只运行了六次，因此级别之间的差异只能作为参考，尚不足以得出统计上的确定结论，但三项任务呈现出的变化方向一致。

推理投入改变的是智能体的推理量，而不是探索量。各级别的工具调用次数基本持平，每次运行介于 17.2 到 18.7 次之间。无论投入级别如何，智能体收集的事实都相同，变化的是它针对这些事实进行了多少推理，输出 Token 数量从 low 下的 1,184 增加到 xhigh 下的 9,147。

low 在成本与质量之间提供了不错的平衡。在 low 下，智能体正确完成了 18 次运行中的 15 次，输出 Token 数量约为 xhigh 的八分之一，运行耗时的中位数为 18 秒。如果可以接受略低的任务完成率，或者答案会在后续流程中接受审核，low 是一个高效的选择。如果要求每个答案第一次就正确，那么默认选择更高的级别更稳妥。

推理投入级别如何影响答案

这些任务围绕特定类型的难点设计。观察各推理投入级别如何处理这些难点，有助于判断何时值得增加推理投入。

优化。 迁移任务更看重对候选组合的考量，而不是逐一对选项进行排名。选择单项比值最优的候选项，可以得到一个合理的答案，但其得分比最优解低九分。在 medium 及以上级别，智能体在全部 18 次运行中都找到了最优集合。

假设检验。 诊断任务要求从两个方向检查候选组合：既要解释每一条告警，也要确保每个未触发告警的服务都与答案一致。在 medium 及以上级别，智能体在全部 18 次运行中都识别出了正确的组合。

约束满足。 调度任务结合了十条明确列出的约束，以及一条依赖查询归属数据的团队规则。xhigh 在每次运行中都生成了有效的调度方案，这也是最高级别优势最明显的任务。

这三项任务呈现出共同的规律：当智能体需要权衡多个候选答案，而不是沿着单一路径得出结果时，额外的推理投入最有价值。

在生产环境中监控推理

在生产环境中，你没有已知答案可用于评分，但你知道每次运行使用了多少输出 Token，以及进行了多少次工具调用。这些数据可以提供有用的运维信号。

各级别下正确完成的运行，其推理量都保持在一个明确的下限之上。medium 及以上级别的每次正确运行都至少使用了 1,739 个输出 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 指标提供 Token 使用量的汇总视图，让前文描述的各级别基线成为可用于设置告警的依据。

将支出归因到各个智能体。 AWS Cost Explorer 和 AWS Cost and Usage Report 中的成本明细按模型拆分用量，结合每项任务的 Token 数量，就能同时了解单位成本和总账单。

让成本与紧急程度匹配。 服务层级按请求设置，因此同一个部署可以通过 Flex 层级运行夜间分析，通过 Priority 层级处理交互式请求。对于以较高推理投入级别运行的工作负载，选择服务层级是进一步控制成本的手段。

选择路由配置。 跨区域推理可以扩大长时间运行可调用的容量池。Global 配置可从你选择的商业 AWS 区域提供服务，其每 Token 定价通常低于按地理范围路由的配置。US 配置将处理过程限制在美国境内。选择时应同时考虑数据驻留要求和成本。

本文中的示例除了每次请求的 token 用量费用外，不会产生其他 AWS 资源费用。如果你生成了长期有效的 Amazon Bedrock API 密钥，请在使用完毕后前往 Amazon Bedrock 控制台将其删除，因为该密钥在被撤销之前会一直有效。通过 IAM 凭证生成的短期 token 会自动过期。

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

SpaceXAI 训练 Grok 4.7，使其能够在更困难的任务上持续工作更长时间，并知道何时检查自己的工作。在三项需要搜索而非简单查找的任务中，智能体在 72 次运行中答对了 67 次，而在 xhigh 推理强度下，每次运行都回答正确。由于推理强度是按请求设置的，你可以为智能体的每一步选择合适的配置，在处理的充分程度与 token 成本之间进行权衡。

在你自己的评估中，有三点值得借鉴。设计只有一个可验证答案的任务，并明确列出评分器所依赖的每一条规则。重复运行，以观察每种配置的一致性。按推理强度监控输出 token 数量和工具调用次数，这样除了质量指标，你还能获得运行层面的信号。

在 Amazon Bedrock 上引入 Grok

Grok 4.7 现已在 Amazon Bedrock 上推出

使用跨区域推理，在不同 AWS 区域之间路由模型推理请求

Amazon Bedrock 入门

Amazon Bedrock 定价

Grok 4.7 介绍（SpaceXAI）