在 Amazon Bedrock 上用 Grok 4.7 构建长程智能体并实测各推理档位表现

SpaceXAI 的 Grok 4.7 现已在 Amazon Bedrock 上可用，Amazon Bedrock 提供来自多个提供商的基础模型（FM）选择。据 SpaceXAI 称，Grok 4.7 经过训练，能够在更困难的任务上工作更长时间，并且知道何时检查自己的工作。这对智能体最为重要，因为智能体需要执行多步骤任务，并且必须验证沿途发现的内容。

以这种方式工作的智能体不能只是查找信息。它必须形成候选答案，对照所学内容进行核查，并不断修正直到契合为止。Grok 4.7 提供了一个推理力度（reasoning effort）设置，用于控制每次响应前的思考程度，对于智能体工作负载来说，一个实际问题是应该选择哪个级别。

在这篇文章中，我们在 Grok 4.7 上构建了一个工具调用智能体，并在三个需要搜索而非查找的任务上对其进行评估。这三个任务分别是：根据告警诊断双服务中断、在相互制约的约束下安排维护，以及在预算内选择最优迁移集合。每个任务都恰好有一个正确答案，并已通过穷举法验证。我们在每个推理力度级别上都运行了全部三个任务，每个任务运行六次，共进行了 72 次智能体运行。

该智能体在 72 次运行中正确回答了 67 次。在 xhigh 时，它全部 18 次回答正确；在 low 时，它回答正确 18 次中的 15 次，同时只使用了大约八分之一的输出 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（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 中，推理内容作为 reasoningContent 块与 text 块一起返回。在 inferenceConfig 中，仅设置 maxTokens，并将模型特定的参数（例如推理力度）放在 additionalModelRequestFields 中。

有关当前支持的Regions、服务层级和代币价格，请参阅 Amazon Bedrock User Guide 中的 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) 身份需要在推理配置文件和账户的默认项目上都拥有 bedrock:InvokeModel 权限：

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

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

连接到模型

对于生产环境使用，我们建议从你现有的 AWS 凭证生成短期持有者令牌，这样身份验证仍与你的 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
)

推理代币计入输出代币，并在生成回答文本之前消耗 max_completion_tokens，因此设置限制时要为两者都留出空间。如果在推理过程中达到限制，响应将在没有回答文本的情况下返回，因此请检查智能体代码中的空内容，如果看到这种情况则提高限制。我们的测试使用的限制为 32,768 个代币，在每个力度级别下都留有余量。

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

设计需要推理的任务

许多智能体评估测试的是勤奋程度：读取记录、过滤记录、汇总记录。这些任务值得保留，但要了解推理力度带来的贡献，任务必须需要搜索：答案无法直接从数据中读出，而必须先提出，然后加以验证。

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

有四项做法能让这样的评测保持可信，它们适用于大多数智能体评测。

明确写出评分器依赖的每一条规则。 如果提示词留下了一个未覆盖的边界情况，合理的答案就可能被误判为错误，评测最终衡量的就是规格说明而不是模型本身。例如，诊断提示词明确说明某个服务失效本身不会触发任何告警。

证明每个任务只有一个答案。 每个环境都小到可以穷举，所以我们在运行任何内容之前都检查了每一个候选答案。对于排程任务，只需几行代码：

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

结果

每个任务在每个推理力度下运行六次，共 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 入门
• Chat Completions API
• Amazon Bedrock 定价
• Introducing Grok 4.7 (SpaceXAI)

关于作者