在Amazon Bedrock上用Grok 4.7构建长周期智能体

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

以这种方式工作的智能体必须做的不仅仅是查找信息。它必须形成一个候选答案，将其与所学知识进行核对，并不断细化，直到答案合适为止。Grok 4.7 暴露了一个推理努力（reasoning effort）设置，用于控制每次响应前进行多少斟酌，对于智能体工作负载，一个实际的问题是应该运行哪个级别。

在本博文中，我们在 Grok 4.7 上构建了一个工具调用智能体，并在三个需要搜索而非查找的任务上对其进行评估。这些任务包括：从警报中诊断双服务中断、在相互制约的约束条件下安排维护，以及在预算限制下选择一组最优迁移。每个任务都有且仅有一个正确答案，通过暴力搜索（brute force）进行验证。我们在每个推理努力级别下运行了所有三个任务，每个任务运行六次，共计 72 次智能体运行。

该智能体在 72 次运行中正确回答了 67 次。在 xhigh 时，它正确回答了全部 18 次；在 low 时，它正确回答了 18 次中的 15 次，同时使用的输出令牌（tokens）约为前者的八分之一。这提供了一个清晰的权衡，您可以按请求进行调整，我们将展示如何在您自己的任务上测量它，以及如何在生产环境中监控它。

我们在全文中报告的是令牌数量而非货币金额。令牌价格会变动，而数量是您自身成本推导的基础，因此以令牌表示的测量结果保持有效。

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 令牌上下文窗口，支持文本和图像输入以及文本输出。在 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 中。

有关支持区域、服务层级和令牌价格的当前列表，请参阅 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
)

推理令牌计为输出令牌，并在生成答案文本之前消耗 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 个服务的合成环境，通过七个工具暴露，并在其上设计了三个任务。每个任务都有且仅有一个正确答案，并且每个任务都构建得使简单的启发式方法不足以找到答案。

四种做法能让此类测量保持可信，它们适用于大多数智能体评估。

明确评分者依赖的每一条规则。 如果提示词留有边缘情况未定，合理的回答可能被判定为错误，评估最终衡量的是规范而非模型。例如，诊断提示词明确说明故障服务本身不会触发警报。

证明每个任务只有一个答案。 每个环境都足够小，可以枚举，因此我们在运行任何内容之前检查了每个候选答案。对于调度任务，只需几行代码：

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 可得到下一节报告的令牌计数。

结果

每个任务在每个努力级别运行 6 次，共 72 次运行。智能体正确回答了 67 次。

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

三个观察。

xhigh 正确回答了每次运行。 在三个任务的所有 18 次运行中，xhigh 均正确，medium 和 high 各正确回答了 18 次中的 17 次。由于每个任务和级别有 6 次运行，级别之间的差异具有指示性而非统计上的决定性，且方向在所有三个任务中保持一致。

努力程度改变智能体推理的量，而不是探索的量。 工具调用基本持平，在每个级别每次运行之间为 17.2 到 18.7 次。无论努力程度如何，智能体收集了相同的事实，改变的是它应用于这些事实的推理量，输出令牌从 low 的 1,184 增加到 xhigh 的 9,147。

low 提供了出色的性价比。 在 low 下，该智能体在 18 次运行中正确回答了 15 次，使用的输出令牌数约为 xhigh 的八分之一，中位运行时间为 18 秒。如果可以接受稍低的完成率，或者答案会在下游经过审核，low 是一个高效的选择。如果要求每个答案首次就必须正确，较高的级别是更安全的默认设置。

努力程度如何影响答案

这些任务围绕特定类型的难度设计，观察每个努力程度如何处理它们，有助于明确何时额外的推理是值得的。

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

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

约束满足。 调度任务将列出的十个约束与一条依赖于查找到的所有权数据的团队规则相结合。xhigh 在每次运行中都生成了有效的调度，并且这是最高级别产生最明显差异的任务。

这三者的共同模式是，当智能体需要权衡多个候选答案，而不是沿着单一路径得出结果时，额外的推理努力最有价值。

在生产环境中监控推理

在生产环境中，你没有已知的答案来评分，但你知道每次运行使用了多少输出令牌和工具调用。这些提供了有用的操作信号。

每个级别的正确运行都保持在明确的推理量下限之上。在 medium 及以上，每次正确运行都至少使用了 1,739 个输出令牌，典型运行使用了数千个。如果一次运行没有进行工具调用，或者产生的输出远少于该级别的正常水平，则值得标记以供审查：

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 运行其机械步骤，例如格式化工具结果。这将较高级别的大部分可靠性与较低的令牌成本相结合。

在您的任务上进行测量，并重复执行。 每种配置仅运行一次只能得到一个观测值。将每种配置重复运行多次可以展示其一致性。

监控推理量。 按努力级别跟踪每次运行的输出令牌数和工具调用次数，可为您提供早期信号，以便在结果被使用之前审查该次运行。

此测量方法的局限性

每个任务和努力级别运行六次。 这足以展示三个任务之间的一致方向，但不足以得出置信区间。请将不同级别之间的差异视为指示性结果。

合成环境。 工具从代码生成的数据中读取，这使得能够证明每个任务恰好有一个答案并自动评分成为可能。真实工具会增加延迟、部分结果和错误，这些均未在此处测试。

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

一个模型版本、一个区域、每个任务一个提示词。 同一任务的不同措辞可能会改变结果，这也是明确陈述每条规则之所以重要的原因之一。

令牌计数，而非成本。 要转换为货币，请应用 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 Cost and Usage Report 中的成本细分按模型拆分使用情况，结合每个任务的令牌计数，可为您提供单位经济性和总账单。

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

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

清理

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

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

结论

SpaceXAI 训练 Grok 4.7 以在更困难的任务上运行更长时间，并知道何时检查自己的工作。在三个需要搜索而非查找的任务中，该智能体在 72 次运行中正确回答了 67 次，且每次运行都在 xhigh 处。由于推理努力程度是按请求设置的，您可以选择智能体的每个步骤在彻底性与令牌成本之间的权衡位置。

有三件事值得带入您自己的评估中。设计具有唯一可证明答案的任务，并陈述评分者依赖的所有规则。重复运行，以便查看每种配置的一致性。并按努力程度监控输出令牌和工具调用，以便在质量度量之外拥有运营信号。

延伸阅读

• 在 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，到优化训练和推理，以及构建 Agentic 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 上快速部署。他的工作越来越多地涉及 Agentic AI——在生产环境中构建可靠、成本高效的多智能体系统及其背后的推理基础设施。