AWS Machine Learning Blog

Build long-horizon agents with Grok 4.7 on Amazon Bedrock

6.9内容质量
Build long-horizon agents with Grok 4.7 on Amazon Bedrock

TL;DR · AI 摘要

Build long-horizon agents with Grok 4.7 on Amazon Bedrock Artificial Intelligence Build long-horizon agents with Grok 4....

核心要点

  • 主题聚焦：Build long-horizon agents with Grok 4.7 on Amazo
  • 来源：AWS Machine Learning Blog，建议结合原文判断细节。
  • AI 分析暂不可用，本条为保底评分与摘要。
#AI#编程#后端#云计算#安全
打开原文

在Amazon Bedrock上使用Grok 4.7构建长时域代理 | 人工智能

在Amazon Bedrock上使用Grok 4.7构建长时域代理

SpaceXAI的Grok 4.7现已在Amazon Bedrock上提供，该平台提供来自多个供应商的基础模型（FMs）选择。据SpaceXAI称，Grok 4.7经过训练，能够处理更复杂的任务并持续更长时间，且知道何时检查自己的工作。这对代理（agent）而言最为关键，因为代理需要通过多个步骤完成任务，并在过程中验证所发现的内容。

以这种方式工作的代理不仅要查找信息，还需要形成候选答案，将其与所学内容进行比对，并不断优化直到答案符合要求。Grok 4.7提供了一个推理努力（reasoning effort）设置，用于控制每次响应前的思考深度，而对代理工作负载而言，一个实际问题是需要选择哪个级别进行运行。

在本文中，我们基于Grok 4.7构建了一个工具调用代理，并在三个需要搜索而非查找的任务上对其进行评估。这些任务包括：根据警报诊断双服务中断、在相互关联的约束下安排维护，以及在预算限制下选择最优迁移集。每个任务都有且仅有一个正确答案，通过穷举法验证。我们在每个推理努力级别上运行了所有三个任务，每个级别运行六次，总共进行了72次代理运行。

代理在72次运行中正确回答了67次。在xhigh级别，代理正确回答了全部18次；在low级别，代理正确回答了18次中的15次，同时仅使用了约1/8的输出token。这提供了可以根据每次请求进行调整的明确权衡，我们展示了如何在自己的任务中测量这一权衡，以及如何在生产环境中监控它。

本文中我们报告的是token数量而非货币单位。token价格会变化，而数量是您自身成本计算的基础，因此以token为单位的度量结果始终有效。

SpaceXAI关于Grok 4.7的报告

据SpaceXAI称，Grok 4.7使用的基座模型比Grok 4.6更大，并且在更复杂的任务组合上进行了更长时间的强化学习训练。该组合侧重于需要数小时才能完成的问题。SpaceXAI报告称，该模型在验证自身工作和管理更长上下文方面表现更优。

SpaceXAI发布的基准测试结果也印证了这一重点。与Grok 4.6相比，Grok 4.7在衡量持续工作能力而非单次回答的类别中显示出最大的提升。

| 基准测试 | 类别 | Grok 4.6 | Grok 4.7 | |--------|------|---------|---------| | Terminal-Bench 4.0 | 多小时终端工作 | 20.3% | 37.6% | | EEBench | 电气工程 | 53.0% | 64.0% | | Harvey Legal Agent Benchmark | 法律工作 | 15.8% | 19.6% | | CursorBench 4.0 | 长时间编码 | 40.4% | 46.3% | | HealthBench Professional | 临床推理 | 48.5% | 56.7% | | AA Briefcase v1.1 | 多小时办公工作 | 1,546 | 1,657 |

数据来源：SpaceXAI，《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端点上，通过跨区域的推理配置文件进行访问。可用的配置文件有两个：

推理配置文件 | 路由

使用场景

us.xai.grok-4.7

适用于美国地理区域

您有美国数据驻留要求

global.xai.grok-4.7

商业AWS区域

您没有驻留限制且需要最大容量

跨区域推理将请求路由到多个AWS区域，无需逐个区域管理容量即可实现更高吞吐量。请求需指定推理配置文件而非直接使用模型ID。

该模型支持兼容OpenAI的聊天完成和响应API，以及Amazon Bedrock Converse API。在Converse API中，推理结果会与文本块一同以reasoningContent块形式返回。在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身份和访问管理(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令牌，这样认证会绑定到您的IAM身份且不会存储长期密钥：

code
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,  # 重试由代码显式处理，参见下文"内置重试机制"
)

推理令牌计入输出令牌配额，会在生成回答文本前消耗max_completion_tokens配额，因此设置限制时要为两者预留空间。如果在推理过程中达到限制，响应将不包含答案文本，因此在代理代码中需要检查空内容并相应提高限制。我们的测试使用了32,768令牌的限制，在所有推理力度级别下都保留了足够的余量。

Grok 4.7支持四种推理力度级别：low、medium、high和xhigh。不同模型版本的力度级别可能变化，因此建议直接查询服务确认可用级别，而不是硬编码列表：

code
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个工具暴露接口，并在此基础上设置了3个任务。每个任务都有且仅有一个正确答案，且每个任务都设计为快速启发式方法无法找到答案。

任务

代理需要执行的操作

使其成为推理任务的关键因素

two_fault_diagnosis

在03:00和12个其他服务触发警报时，识别出两个静默失效的服务

失效服务不会触发警报，因此答案不在触发警报的服务中。共有190种可能的配对组合，但只有一种能完美解释观察到的警报

maintenance_schedule

在四晚内修补八个服务，每晚修补两个，需满足十个约束条件，并遵守同一团队的两个服务不能共处一晚的规则

共有2520种可能的排班方案，但只有一种有效。团队规则依赖于代理必须查找的数据

migration_budget

在预算限制内选择迁移候选对象以最大化风险降低，包括传递性前提条件

共有53种可行方案，其中一种最优。优先选择最佳比例的方案会比最优解少9分

四个实践方法可确保此类测量结果的可信度，这些方法适用于大多数代理评估。

明确列出评分者依赖的每条规则。如果提示信息留有边缘情况的模糊空间，合理的答案可能被误判为错误，评估最终会测量的是规范而非模型。例如诊断任务的提示明确说明失效服务不会触发自身警报。

验证每个任务只有一个答案。每个环境都足够小可以穷举，因此我们在运行任何内容前检查了每个候选答案。对于排班任务，代码如下：

code
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  # 恰好一个答案
assert len(valid_schedules(SERVICES, CONSTRAINTS_WITHOUT_TEAM_RULE)) > 1  # 规则确实起作用

只评估最终行而非完整响应。每个提示都要求代理以类似FINAL: auth, checkout的格式结束。评分者只读取该行，因此在解释推理过程时讨论其他候选方案的响应仍会根据结论评分：

code
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个响应都包含可评分的最终行。

使用枚举类型约束工具参数，当已知有效值时，确保每个工具调用都指向真实资源：

code
TOOLS = [
    {"type": "function", "function": {
        "name": "get_dependencies",
        "description": "一个服务直接依赖的其他服务。",
        "parameters": {
            "type": "object",
            "properties": {"service": {"type": "string", "enum": SERVICE_NAMES}},
            "required": ["service"],
        }}},
    # 剩余六个工具采用相同结构。
]

系统提示被有意设计得简短，并要求代理在给出答案前检查其答案：

code
AGENT_SYSTEM = (
    "你是一个基础设施分析代理。使用工具来收集事实，永远不要猜测你可以查找的值 "
    "在回答前，将你的答案与任务中的每条规则进行核对。以任务指定的格式精确结束于FINAL行。"
)

代理循环是一个标准的工具调用循环：设置reasoning_effort后调用模型，执行每个返回的工具调用，按tool_call_id键附加结果，并重复直到模型停止请求工具。在整个循环中跟踪prompt_tokens和completion_tokens的数量，即可得到下文部分报告的令牌计数。

结果

每个任务在每个努力级别上运行六次，总共72次运行。代理正确回答了67次。

low

medium

high

xhigh

5/6

6/6

所有三个任务

15/18

17/18

18/18

每轮运行

平均输出令牌数

1,184

6,430

6,778

9,147

相对于low的输出令牌数

1.0x

5.4x

5.7x

7.7x

平均工具调用次数

17.2

18.7

17.8

18.1

中位耗时

18秒

98秒

89秒

106秒

图1：每个推理努力级别正确回答的运行占比（左），以及每轮运行平均输出令牌数与中位耗时叠加显示（右）

三个观察发现：

xhigh级别正确回答了所有运行。在三个任务的18次运行中，xhigh级别全部正确，而medium和high级别各自正确了17/18次。每个任务和级别有6次运行，不同级别之间的差异具有指示性但并非统计意义上的结论性，且所有三个任务的方向一致性都保持一致。

努力级别改变的是代理的推理深度，而非探索广度。在每个级别上，每次运行的工具调用次数基本持平（17.2到18.7次之间）。无论努力级别如何，代理收集的事实相同，变化的是其对这些事实的推理深度，输出令牌数从low级别的1,184增长到xhigh级别的9,147。

low级别提供了强大的性价比。在low级别，代理用xhigh级别约1/8的输出令牌数，正确回答了18次运行中的15次，中位运行耗时仅18秒。当可以接受稍低的完成率或答案需要后续审查时，low级别是高效的选择。而当每个答案都必须首次就正确时，更高级别则是更安全的默认选择。

努力级别如何塑造答案

这些任务围绕特定类型的难度设计，观察每个努力级别如何处理这些任务，可以明确说明额外推理何时值得。

优化。迁移任务奖励综合考虑组合方案而非逐一排序选项。单独选择最优比例的候选方案会产生一个合理的答案，但距离最优解还差9分。在medium及以上级别，代理在所有18次运行中都找到了最优组合。

假设检验。诊断任务需要双向验证候选对：每个警报都必须得到解释，每个保持沉默的服务都必须与答案一致。在medium及以上级别，代理在所有18次运行中都正确识别了候选对。

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

在三种模式中，共同的规律是：当代理需要在多个候选答案之间进行权衡时，额外的推理工作最有价值，而不是沿着单一路径到达结果。

生产环境中的推理监控

在生产环境中，你没有已知答案可以作为参考标准，但你知道每次运行使用的输出令牌数和工具调用次数。这些数据为你提供了有用的运营信号。

每个层级的正确运行都保持在明确的推理量基准之上。中等及以上层级的每次正确运行至少使用了1,739个输出令牌，典型的运行使用了数千个。如果某次运行没有进行任何工具调用，或者其输出量远低于同层级的正常水平，值得标记出来进行审查：

code
def flag_for_review(run, baseline):
    """baseline: 同一推理层级下已评分正确运行的输出令牌数."""
    reasons = []
    if run["tool_calls"] == 0:
        reasons.append("未进行任何工具调用")
    if run["output_tokens"] < 0.2 * min(baseline):
        reasons.append(f"使用了 {run['output_tokens']} 个输出令牌，"
            f"不足最低正确运行 ({min(baseline)}) 的五分之一")
    return reasons

根据任务和推理层级，从已评分的运行中校准基准线，然后将其应用于未评分的运行。将标记视为需要检查或重新运行的提示。在低层级，由于每次运行都很简短，输出量是一个较弱的信号，因此需要结合抽查使用。

要求代理在系统提示中验证其答案值得保留，因为这使得在审查运行时更容易跟踪代理的推理过程。在存在已知答案的情况下，将其与自动化评分结合使用，以便独立于对话记录来衡量质量。

选择推理层级

这些结果表明了一些实用规则。

根据任务类型匹配层级。涉及搜索、优化或假设检验的任务从中等及以上层级获益最多。遵循单一路径或其答案将在下游被审查的任务可以在低层级高效运行。

按请求设置层级，而非按代理设置。层级是请求参数，因此代理可以在较高层级执行规划和验证步骤，而在低层级执行机械步骤（如格式化工具结果）。这结合了较高层级的大部分可靠性，同时降低了令牌成本。

在自己的任务上进行测量，并重复实验。每个配置仅运行一次只能提供一个观察结果。重复每个配置多次可以显示其一致性。

监控推理量。按层级跟踪每次运行的输出令牌数和工具调用次数，可以提前发现需要审查的运行。

该度量的局限性

每个任务和层级仅运行6次。这足以在三个任务中显示一致的趋势，但不足以计算置信区间。将层级间的差异视为参考指标即可。

这是一个合成环境。工具从代码生成的数据中读取，这使得每个任务都能被证明有且只有一个答案，并实现自动评分。真实工具会引入延迟、部分结果和错误，这些因素在此未被测试。

以分钟而非小时为单位。低层级的中位运行时间从18秒到xhigh层级的106秒不等。这是对长期工作的缩略版代理。方法是可迁移的，但绝对数值不适用。

一个模型版本、一个区域、每个任务一个提示。相同任务的不同表述可能会影响结果，这也是为何明确说明每条规则至关重要的原因之一。

按令牌数量计费，而非成本。要转换为货币单位，请使用 Amazon Bedrock 定价页面中对应推理配置文件和服务层级的当前费率。Global 和 US Geo 配置文件的定价不同，Flex 和 Priority 服务层级会应用倍数系数。

代理工作负载的操作控制

内置重试机制。发出大量调用的代理应将重试视为设计的一部分。设置请求超时时间，仅对可重试的错误进行重试，使用带抖动的指数退避，并在收到 Retry-After 头时遵守：

code
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 成本分析器和 AWS 成本与使用情况报告中的成本明细会按模型拆分使用情况，结合每任务的令牌数量，使您能够同时了解单位经济指标和总账单。

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

选择路由配置文件。跨区域推理会扩大长期运行任务可使用的容量池。Global 配置文件可从您选择的商业 AWS 区域提供服务，通常每令牌价格低于地理路由。US 配置文件将处理过程保留在美国境内。选择时应基于数据驻留要求和成本考量。

清理

本文中的示例除了按请求使用令牌外，不会创建其他可计费的 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)

关于作者

'"`