在 Amazon Bedrock 上推出 Grok

xAI 的 Grok 4.3 现已通过 Amazon Bedrock 正式可用，为构建 AI Agent 和工作流的团队提供了一个能够可靠推理长输入内容的模型。此次发布标志着 xAI 成为 Amazon Bedrock 的模型提供商。Grok 4.3 具有可配置的推理力度，提供强大的工具使用和指令遵循能力以构建 Agent，并具备高效 token 处理能力以支持高吞吐量推理。该模型支持文本和图像输入，拥有 100 万 token 的上下文窗口，可用于长文档和多轮对话。模型运行在 Amazon Bedrock 的下一代推理引擎 Mantle 上。

为什么 Grok 4.3 非常适合 Agent 和推理工作负载？

据 xAI 称，Grok 4.3 专为需要准确性的企业工作而构建。在其发布时的基准测试中，xAI 报告其超越了多个行业基准。Grok 4.3 在 Artificial Analysis Omniscience 基准测试中排名第一，在比较的顶级模型中幻觉率最低。它还在客户支持场景的工具调用基准测试 Artificial Analysis Tau2 Telecom 中排名第一，并在 Vals AI Case Law 和 Corporate Finance 基准测试中排名第一。xAI 还将其置于智能与成本帕累托前沿，称其每美元智能度是其他前沿模型的 2 到 10 倍。

通过 Grok 4.3，您可以在每次请求中控制模型在回答前的思考程度，通过设置推理力度（无、低、中、高）来实现。分类调用可以设置为无以保持低延迟；合同分析或判例法任务可设置为高，当深度比响应时间更重要时。Grok 4.3 接受文本和图像输入并返回文本，其 100 万 token 上下文窗口为长文档和扩展的多轮对话留出空间。模型擅长工具调用和指令遵循，这对于依赖函数调用来执行操作的 Agent 非常实用。这些特性适用于合同审查、信用协议分析和金融文档问答等用例。在这些情况下，模型对长输入进行推理，然后调用记录系统。

如何在 Amazon Bedrock 上访问 Grok 4.3

Grok 4.3 运行在 Mantle 上，其访问方式与使用 Amazon Bedrock Runtime API 的模型不同。Mantle 使用 OpenAI 兼容的 API。您可以通过 OpenAI SDK 或直接 HTTPS 请求到 Chat Completions API 或 Responses API 来调用 Grok 4.3。

Mantle 端点 URL 是区域特定的，遵循特定模式。例如，在 us-west-2 区域，基础 URL 为 https://bedrock-mantle.us-west-2.api.aws/openai/v1。请注意，Mantle 端点的 Responses API URL 路由与 Runtime 端点略有不同。

要使用 Grok 4.3 设置 SDK，需按照上述描述设置基础 URL 和区域。使用 Grok 时，注意上下文窗口为 100 万 token，默认值在三个方面与标准 OpenAI 规范不同：temperature 默认为 0.7，top_p 默认为 0.95，max_completion_tokens 默认为 131072。如果您的应用程序需要不同行为，请显式设置这些参数。

认证并运行第一个请求

您有两种方式对 Mantle 端点进行认证，两者都适用于相同的 OpenAI SDK。对于生产环境，我们建议使用从 IAM 凭据生成的短期 bearer 令牌，因为它们会自动过期并保持访问与您的 IAM 身份绑定。对于快速探索和入门，请使用长期 Amazon Bedrock API 密钥。将长期密钥限制于此用途，而不是嵌入到生产应用程序中。

以下示例展示了如何使用长期 Amazon Bedrock API 密钥进行认证以访问模型。视为仅用于探索的凭据。您可以从 Amazon Bedrock 控制台生成一个，然后安装 OpenAI SDK。将客户端指向区域性的 Mantle 端点并使用 API 密钥进行认证。模型 ID 为 xai.grok-4.3。

当您准备好将 Amazon Bedrock 集成到需要更高安全性的应用程序中时，建议使用短期凭据。您可以在请求时使用 Amazon Bedrock 令牌生成器从现有的 AWS 凭据生成短期 bearer 令牌。这使认证与您的 IAM 身份绑定，并避免使用长期密钥。

配置推理输出

您可以通过 Responses API 上的 reasoning 参数控制模型使用的推理力度。力度级别为 none（禁用推理）、low（默认）、medium 和 high。更高的力度通常有助于解决多步问题，但代价是生成更多的输出 token。

Chat Completions API 不返回推理轨迹。如果您希望模型的推理在多个轮次中可用，请使用 Responses API。在默认的有状态模式下，设置 store=True 并通过 previous_response_id 链式调用，服务会自动保留每个轮次的推理并将其反馈，因此您无需自行管理。加密推理用于无状态情况。如果您设置 store=False（例如，工作负载要求轮次不在服务器端持久化），请使用 include=["reasoning.encrypted_content"] 请求推理。在下一个请求的输入中将其传回，以将模型自身的先前推理作为上下文提供。

一个实用模式是：将分类、提取和简短事实查询设置为 none 或 low 力度，将 high 保留给规划步骤、数学和链式任务，其中单个早期错误会破坏整个任务。

使用 Grok 4.3 调用工具

工具调用对于 Agent 工作负载至关重要，Grok 4.3 通过相同的 OpenAI 兼容接口支持它。您描述可用的工具，模型决定何时调用，并返回一个结构化请求，您的代码执行该请求并反馈结果。Grok 4.3 遵循标准的 OpenAI 工具调用格式，因此您使用 JSON Schema 为每个工具定义参数。

以下示例提供了一个 get_weather 工具并询问一个应触发它的问题。模型从问题中解析出城市并生成了一个与 schema 匹配的有效参数对象。然后您运行函数，添加工具角色消息，并再次调用模型以使结果融入自然语言回复。这是 Grok 4.3 上多步 Agent 的构建块。

结构化输出

当您需要模型返回代码可直接解析的数据时，请使用带有 JSON Schema 的结构化输出。Grok 4.3 支持 json_schema 响应格式并带有严格模式，因此响应将符合您提供的 schema，而不是给出自由文本。将 strict 设置为 True 并将 additionalProperties 设置为 False 可将响应限制在您所请求的键内，当下游系统期望固定记录格式时，这与工具调用配合良好。测试中的一个操作注意事项：即使是无害输入，请求偶尔也会从自动内容安全检查返回 400 错误，因此请在生产调用中构建简短的重试。

图像输入

Grok 4.3 接受图像作为输入并返回文本，适用于文档理解、图表阅读和视觉问答。您可以使用与 OpenAI Chat Completions API 相同的模式传递图像，作为包含 base64 编码字节的 data: URL 或公共图像 URL 的内容部分。文本和图像部分位于同一个 content 数组中，以便模型同时看到问题和图片。在测试中，模型正确读取了生成的测试图像并命名了其主要颜色。请使用受支持的图像格式（如 PNG 或 JPEG）并保持编码整洁：格式错误或截断的图像负载将返回验证错误。