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

SpaceXAI 的 Grok 4.7 现已在 Amazon Bedrock 上提供。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 API 上，推理内容会作为 reasoningContent 块与 text 块一同返回。在 inferenceConfig 中，仅设置 maxTokens，并将推理力度等模型专属参数放入 additionalModelRequestFields。

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

先决条件

• 拥有可访问 Amazon Bedrock 的 AWS 账户，并已启用 Grok 4.7 的模型访问权限。
• 已安装 openai、boto3 和 aws-bedrock-token-generator 的 Python 3.9 或更高版本。
• 已在环境中配置 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 项服务的合成环境，通过七种工具和三个任务加以呈现。每项任务都只有一个正确答案，并且都经过设计，确保无法仅凭简单启发式找到答案。

四项实践可以确保此类测量值得信赖，而且适用于大多数智能体评估。

明确说明评分器所依赖的每条规则。如果提示词对某个边界情况没有明确规定，那么合理的答案也可能被判错，最终评估衡量的就会是规范说明，而非模型本身。例如，诊断提示明确指出，服务故障本身不会触发警报。

证明每项任务只有一个答案。每个环境都足够小，可以枚举所有情况，因此我们在运行前检查了每个候选答案。对于日程安排任务，只需几行代码：

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

结果

每种任务在每个推理力度级别运行 6 次，共运行 72 次。智能体答对了 67 次。

图 1：各推理力度级别下答对的运行比例（左），以及每次运行的平均输出 token 数和叠加显示的每次运行耗时中位数（右）

有三点观察。

xhigh 每次运行都答对了。在 xhigh 下，三个任务共 18 次运行全部答对；medium 和 high 各答对 18 次中的 17 次。每个任务和级别只有 6 次运行，因此各级别之间的差异只能作为参考，尚不足以得出统计学上确凿的结论；但三个任务呈现的趋势一致。

推理力度改变的是智能体推理的程度，而非探索的范围。各级别的工具调用次数基本持平，每次运行在 17.2 到 18.7 次之间。无论推理力度如何，智能体收集到的信息都相同；变化的是它对这些信息进行推理的程度，输出 token 数从 low 时的 1,184 个增加到 xhigh 时的 9,147 个。

low 具有很高的成本效益。在 low 下，该智能体在 18 次运行中有 15 次回答正确，输出 token 数约为 xhigh 的八分之一，中位运行时间为 18 秒。如果可以接受稍低的完成率，或者答案会在后续环节审核，那么 low 是一种高效的选择。如果要求每个答案一次就正确，那么较高的级别是更稳妥的默认选择。

推理力度如何影响答案

这些任务围绕一种特定类型的难题设计，观察各个推理力度级别如何处理这些任务，有助于明确额外推理何时值得投入。

优化。迁移任务需要考虑各种组合，而不是逐一为选项排序。选择单项比率最高的候选项能得出一个合理答案，但比最优解低 9 分。在 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 秒不等。这只是对长时程任务的缩小版模拟。该方法可以迁移使用，但绝对数值不适用。

一个模型版本、一个 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 用量；借助这些数据，前文所述的各级基线就能用于设置告警。

分摊不同代理的费用。AWS Cost Explorer 和 AWS Cost and Usage Report 中的费用明细会按模型细分用量；结合每个任务的 token 数量，你就能同时掌握单位经济效益和总账单。

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

选择路由配置。跨区域推理会扩大长时间运行任务可使用的容量池。Global 配置可从你选择的 AWS 商业区域提供服务，通常每个 token 的定价低于地理路由。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，到优化训练和推理，再到构建智能体 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——构建可靠且经济高效的多智能体系统，以及支撑这些系统在生产环境中运行的推理基础设施。