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

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

以这种方式工作的智能体必须做的不仅仅是查找信息。它必须形成候选答案，对照所学内容进行检查，并不断改进直到吻合。Grok 4.7 提供了一个推理力度设置，用于控制每次响应前的推敲程度，而对于智能体工作负载来说，一个实际问题就是应该使用哪个级别。

在本文中，我们基于 Grok 4.7 构建了一个工具调用智能体，并在 3 个需要搜索而非查找的任务上对其进行评估。这些任务包括：根据警报诊断一次涉及两个服务的故障、在相互制约的约束下安排维护，以及在预算范围内选择一组最优的迁移方案。每个任务都有且仅有一个正确答案，并已通过暴力枚举验证。我们在每个推理力度级别下运行了全部 3 个任务，每个任务运行 6 次，共计 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 仅限，并将模型特定的参数（如 reasoning effort）放在 additionalModelRequestFields.

有关当前支持的 Regions、服务层级和 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身份和访问管理（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
)

推理 token 计入输出 token 并消耗 max_completion_tokens 在生成回答文本之前生效，因此请将上限设置得足够大，以便为两者留出空间。如果在推理过程中达到上限，响应将不包含回答文本而直接返回，因此请在代理代码中检查内容是否为空，如发现该情况请调高上限。我们的运行使用了 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']

需要推理的设计任务

许多智能体评估测试的是勤勉度：读取一条记录、过滤它、求和。这些任务值得拥有，但要了解推理努力的作用，任务必须需要搜索：答案不能直接从数据中读出，必须先提出然后再检验。

我们构建了一个包含 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 计数。

结果

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

图 1:每个推理努力级别下正确回答的运行占比(左),以及每次运行的平均输出 token 数并叠加每次运行的秒数中位数(右)

三点观察。

xhigh 所有运行均回答正确。 三个任务的全部 18 次运行在 xhigh,以及 medium 和 high 两者各自答对了18题中的17题。由于每个任务和等级仅运行六次，各等级之间的差异只是指示性的，而非统计学上的结论，且方向在全部三个任务中保持一致。

Effort（努力程度）改变的是智能体推理的多少，而不是它探索的多少。 工具调用次数基本持平，在每个级别上每次运行都在 17.2 到 18.7 之间。无论推理努力程度如何，智能体收集的事实都相同，变化的是它对这些事实应用的推理量，输出令牌数从 1,184 上升到 low 时的 9,147。 xhigh.

low 提供了很强的成本与质量比。 在 low级别，智能体在 18 次运行中答对了 15 次，所用输出令牌约为 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和工具调用数，可以在运行结果被使用之前为你提供审查该运行的早期信号。

本次测量的局限性

每个任务和每个努力等级运行6次。 足以在三个任务中展示一致的方向,但不足以得出置信区间。请将各等级之间的差异视为指示性的。

一个合成环境。 工具从代码生成的数据中读取,这使得能够证明每个任务恰好有一个答案并自动评分。真实工具会引入延迟、部分结果和错误,而这些在这里都没有测试。

以分钟计,而非小时。 中位运行时间从 18 秒（在 low 到 106 秒（在 xhigh时的106秒不等。这是长时程工作的缩小版代理。方法可以迁移,绝对数值则不能。

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

是Token数量,而非成本。 要换算成货币,请在Amazon Bedrock定价页面应用您的推理配置文件和服务层级的当前费率。Global和美国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 定价
• 推出 Grok 4.7 （SpaceXAI）

关于作者