在 Amazon Bedrock 上用 Grok 4.7 构建长时程智能体

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

以这种方式工作的智能体必须做的不仅仅是查阅资料。它必须形成一个候选答案，用已学到的知识来检验它，并不断改进，直到它符合要求。Grok 4.7 提供了一个推理力度设置，用于控制在每次响应之前进行多少思考，而对于智能体工作负载，一个实际问题是应该运行在哪个级别。

在本文中，我们在 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，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。

有关当前支持的区域、服务层级和 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) 身份需要对推理配置文件和你账户的默认项目都具有 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，因此请设置限额以便为两者都留出空间。如果在推理期间达到限额，响应将不包含答案文本，因此请在 agent 代码中检查空内容，若发现该情况则提高限额。我们的运行使用了 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']

设计需要推理的任务

许多 agent 评估测试的是勤勉程度：读取一条记录、过滤它、把它加起来。这些任务值得保留，但要看出推理工作量的作用，任务必须要求搜索：答案不能直接从数据中读出，而必须被提出并随后验证。

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

以下四种做法能让这样的测量结果保持可信，它们也适用于大多数智能体评测。

明确列出评分器所依赖的每一条规则。如果提示词留下了边界情况未定义，一个合理的答案也可能被判为错误，于是评测衡量的就成了规格说明，而非模型本身。例如，诊断提示词明确说明，服务失败本身不会触发任何警报。

证明每项任务只有一个答案。每个环境都小到可以枚举，因此我们在运行任何内容之前检查了每一个候选答案。对于排班任务，这只需几行：

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，即可得到下一节所报告的词元数。

结果

每项任务在每个努力级别上各运行六次，共 72 次运行。智能体答对了 67 次。

图 1：每个推理努力级别下回答正确的运行占比（左），以及每次运行的平均输出词元数并叠加每次运行的中位秒数（右）

三点观察。

xhigh 每次运行都回答正确。三项任务在 xhigh 下的全部 18 次运行均正确，而 medium 和 high 各答对 18 次中的 17 次。由于每项任务在每个级别上只有六次运行，各级别之间的差异只是指示性的，而非统计上的定论，但方向在全部三项任务上是一致的。

努力程度改变的是智能体推理的多少，而不是它探索的多少。工具调用次数基本持平，在每个级别上均为每次运行 17.2 到 18.7 次之间。无论努力程度如何，智能体收集到的事实都相同，变化的只是它对这些事实施加了多少推理，输出词元数从 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 成本。

在你自己的任务上测量，并重复运行。每种配置只运行一次只能得到一个观测值。将每种配置重复运行多次，才能看出它有多稳定。

监控推理量。按 effort level 跟踪每次运行的输出 token 数和工具调用次数，可以在结果被使用之前获得一个用于审查运行的早期信号。

本次测量的局限性

每个任务和 effort level 运行六次。足以在三个任务上显示出一致的方向，但不足以给出置信区间。请将各 level 之间的差异视为指示性的。

合成环境。这些工具读取的是由代码生成的数据，正因如此才能证明每个任务恰好只有一个答案，并实现自动评分。真实工具会带来延迟、部分结果和错误，这些在此均未测试。

分钟级，而非小时级。中位运行时间从 low 的 18 秒到 xhigh 的 106 秒不等。这是长周期工作的一个缩小版代理。方法可以迁移，绝对数值则不能。

单一模型版本、单一 Region、每个任务单一提示词。同一任务的不同措辞可能会改变结果，这也是为什么明确陈述每条规则很重要。

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 使用量的聚合视图，前文所述的按 level 基线由此成为可以对其设置告警的对象。

将支出归因到各代理。AWS Cost Explorer 和 AWS Cost and Usage Report 中的成本明细可按模型拆分用量，结合按任务的 token 数量，你既能获得单位经济性，也能获得总账单。

让成本与紧迫性相匹配。服务层级是按请求设置的，因此一次部署可以将夜间分析通过 Flex 层级发送，将交互式请求通过 Priority 发送。对于以更高 effort level 运行的工作负载，层级选择是进一步控制成本的杠杆。

选择路由配置。跨区域推理扩大了长时间运行可从中获取资源的容量池。Global 配置从你选择的商业 AWS Region 提供服务，每 token 定价通常低于地理路由。US 配置将处理保留在美国境内。请根据你的数据驻留要求以及成本来做出选择。

清理

本文中的示例除了按请求计费的 token 用量外，不会创建任何可计费的 AWS 资源。如果你生成了长期有效的 Amazon Bedrock API 密钥，请在完成后于 Amazon Bedrock 控制台中将其删除，因为它在被撤销之前一直有效。由 IAM 凭证生成的短期令牌会自行过期。

如果你在测试时启用了将模型调用日志记录到 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 定价
• 推出 Grok 4.7 (SpaceXAI)

关于作者

Suheel Farooq

Suheel 是 AWS 的首席解决方案架构师，专攻人工智能、机器学习和生成式 AI。他帮助基础模型提供商客户在 AWS 上设计、构建、现代化和扩展其 AI/ML 与生成式 AI 工作负载——从将基础模型引入 Amazon Bedrock，到优化训练和推理，再到构建智能体 AI 解决方案。他的经验涵盖 AWS AI/ML 与生成式 AI 产品组合，尤其是 Amazon Bedrock、Amazon Bedrock AgentCore 和 Amazon SageMaker AI。闲暇时，Suheel 喜欢健身和徒步。

Anirban Gupta

Anirban 是 AWS 驻美国西雅图的首席工程师，专注于为 Amazon Bedrock 设计安全、高规模的模型服务基础设施。他推动了该平台上多个基础模型发布背后的技术工作。在加入 Amazon Bedrock 之前，他曾是 AWS Outposts 的首席工程师，负责构建混合本地云基础设施。

James Wang

James 是 SpaceXAI 的高级产品增长经理。此前，他曾任 Cerebras 的产品营销总监，负责推出 Cerebras Inference 和 CS-3 AI 加速器。在那之前，James 是 ARK Invest 的首席 AI 分析师。他的职业生涯始于 NVIDIA，在深度学习早期推出了首批支持 CUDA 的 GPU。

Ikenna Izugbokwe

Ikenna 是 AWS 的首席解决方案架构师，专攻网络、容器和 AI 基础设施。他指导模型提供商扩展其训练和推理系统，同时支持在 AWS 上快速部署不断演进的前沿模型。他的工作日益涵盖智能体 AI——构建可靠、高性价比的多智能体系统及其背后的生产推理基础设施。