用开放权重模型在 Amazon Bedrock 上打造你的 AI 编程代理

AWS ML Blog 2026-09-24T11:55:41.465287

AI 编码智能体已经成为开发者编写、调试和重构软件的核心工具。Amazon Bedrock 上的开放权重模型（open weight models）让这些智能体可以私密、低成本地运行。但市面上大多数方案要么要求你把专有数据发送到第三方 API，要么把你绑定在单一模型供应商上，要么不管实际用了多少都按席位收订阅费。如果你有数据驻留要求、对成本敏感，或者需要灵活切换模型，这些限制都会带来切实的麻烦。能不能有一种 AI 编码智能体，把数据留在你自己的 AWS 账号里，可以按需在前沿开放权重模型之间切换，并且只按实际用量付费？

OpenCode 是一款开源、终端原生的 AI 编码智能体，用 Go 编写。它能读写文件、执行 shell 命令，并通过语言服务器协议（LSP）诊断来理解项目结构。它可以连接 75 家以上的大语言模型（LLM）供应商，包括 Amazon Bedrock。把 OpenCode 和 Bedrock 上的开放权重模型搭配使用，你就得到一个本地运行的编码助手，推理过程安全地发生在你的 AWS 账号内部。无需管理基础设施，也没有按席位收费。

本文将演示如何在 Amazon Bedrock 上把 OpenCode 与开放权重模型搭配起来，配置多模型工作流，为不同任务匹配最合适的模型，并用 Moonshot AI Kimi K3、OpenAI GPT-OSS 120B 和 NVIDIA Nemotron 3 Super 120B 走一遍实际编码示例。我们还会分享 Ethara.AI 如何把这一架构部署到生产环境，通过多智能体编排大规模支撑 AI 工程和研究工作流。

为什么 AI 辅助编码要用开放权重模型

整个行业正在向开放权重模型转移。麦肯锡《AI 时代的开源技术》报告（2025）显示，76% 的组织计划增加开源 AI 的使用，而领先的 AI 采用者使用开放权重模型的可能性要高出 40%。在编码类业务上，有五个因素推动了这一转变：

性能持平：经过微调的开放权重模型在特定领域任务上可以超越专有方案。

CrowdStrike 微调后的 NVIDIA Nemotron 实现了 96% 的有效查询准确率，超过 GPT-4o（61%）和 Claude Sonnet 4.5（94%）。

成本效率：Gartner 2026 年的分析指出，智能体工作流会让 token 消耗量增加 5 到 30 倍，因此每 token 成本变得至关重要。当月度对话量达到数百万级别时，切换到 Bedrock 上的开放权重模型可以显著降低年度化成本。

定制与控制：开放权重支持微调、蒸馏和领域适配。较小的模型可以替代昂贵的通用模型，同时保持质量。

模型灵活性：使用开放权重，可以为每个任务选择最合适的模型，并在新模型出现时随时切换。在 Amazon Bedrock 上，切换模型只需改一个 API 参数。

透明度：模型架构和行为可审查，满足受监管行业对 AI 治理的要求。

为什么选择 Amazon Bedrock 作为后端

Amazon Bedrock 提供完全托管、无服务器的开放权重模型访问方式。不需要配置 GPU，也不用管理推理基础设施。

对于企业编码工作流，Bedrock 相比自托管或直接对接模型提供商有几个优势：

数据驻留与合规：代码、提示词和响应都留在你的 AWS 账户中。通过区域内或地理配置文件访问的模型，只会在该区域或地理范围内运行。你可以通过跨区域推理配置文件调用 Kimi K3。对于没有区域限制的工作负载，我们推荐使用全局配置文件 global.moonshotai.kimi-k3，它会把每个请求路由到全球任意支持的商业 AWS 区域。全局跨区域推理的费用比地理配置文件低约 10%。美国地理配置文件 us.moonshotai.kimi-k3 则确保处理过程留在美国境内，满足数据驻留要求。

Amazon Bedrock 符合 HIPAA、SOC 2、ISO 27001、FedRAMP 和 GDPR 等常见合规项目的要求。完整列表请参阅按合规项目划分的 AWS 服务范围。

企业级安全管控：开放权重模型和专有模型一样，沿用同一套 AWS Identity and Access Management（IAM）策略、AWS CloudTrail 日志、AWS PrivateLink 连接和加密管控，不需要单独搭一套安全体系。定价灵活：三档计费对应不同负载，Priority 适合对延迟敏感的生产环境，Standard 是按 token 付费的按需推理，Flex 成本低 50%，适合能接受延迟波动的任务。不用你的数据训练模型：Bedrock 不会拿你的输入或输出去训练、改进基础模型（FM）。默认容量高：每分钟 1 亿 token、每秒 1 万请求的默认上限，团队规模扩大时不容易卡在吞吐瓶颈上。

按任务挑合适的模型

不是每个编程任务都需要同一种模型。用 OpenCode 搭配 Bedrock 的一大好处，就是能根据手头的活儿随时切换模型。

评估模型去哪里看：Artificial Analysis Coding Index 提供了一套综合基准，覆盖真实软件工程任务（SWE-Bench、Terminal-Bench、SWE-Atlas）。可以用它对比模型性能、单任务成本和延迟。如果想用自己的提示词和数据做评测，可以用 Amazon Bedrock Evaluations 做并排对比，支持自动打分、LLM-as-a-judge 或人工评审。

性能之外的考量

推理深度：处理复杂调试、架构决策或生成方案时，推理模型会一步步推演问题。Kimi K3 会先推理再作答，你可以通过 reasoning_config 设置深度（low、high 或 max）。难题上用延迟换正确率。

生成速度与延迟：代码补全、样板代码生成、交互式结对编程这类场景，低延迟比峰值推理能力更重要。NVIDIA 表示，Nemotron 3 Super 120B 的吞吐量最高可提升 7 倍，原因是它采用混合专家（Mixture-of-Experts）架构，每个 token 只激活 120B 总参数中的 12B。

单 token 成本：批量重构、大型代码库这类高频工作流，成本会不断累积。

Bedrock 上的开放权重模型按 token 计费的价格低于闭源方案。

上下文窗口：Kimi K3 支持 100 万 token 上下文，大约相当于数万行代码。你可以一次加载整个仓库，而不只是几个文件，从而进行跨文件推理。

区域可用性：先确认目标区域有哪些模型可用。这关系到数据主权和延迟要求。

本文介绍三款覆盖不同定位的模型：

模型	优势	适用场景
Moonshot AI Kimi K3	常驻推理，100 万 token 上下文	调试、架构分析、复杂逻辑
OpenAI GPT-OSS 120B	前沿代码生成（120B 参数）	全流程生成、多文件实现
NVIDIA Nemotron 3 Super 120B	吞吐量优化，经企业验证	高并发生成任务

方案概览

整个架构分两部分：OpenCode 在本地机器上以终端用户界面（TUI）运行，通过 Amazon Bedrock Converse API 发起推理请求。Bedrock 以全托管、无服务器的端点形式承载这些模型。

图 1：OpenCode 搭配 Amazon Bedrock 开放权重模型的方案架构。开发者在终端中与 OpenCode 交互，请求经 Bedrock Converse API 发往开放权重模型。AWS IAM 对每个请求做身份验证，AWS CloudTrail 记录 API 活动

OpenCode 的代理架构支持给不同角色分配不同模型：用推理模型做规划，用更快的模型做代码生成。这样在单个会话里就能跑起多模型工作流。

前提条件

开始之前，请确认具备以下条件：

已开通 Amazon Bedrock 访问权限的 AWS 账户。
在 Amazon Bedrock 控制台中已获得 Kimi K3、GPT-OSS 120B 和 NVIDIA Nemotron 3 Super 120B 的模型访问权限。
已配置 AWS 凭证（IAM 访问密钥、AWS IAM Identity Center 或 Bedrock API 密钥）。
Node.js 18+（用于 npm 安装方式）或 Homebrew（用于 macOS/Linux）。

安装并配置 OpenCode

本节介绍如何安装 OpenCode CLI，并配置它通过 Amazon Bedrock 进行身份验证。

安装 OpenCode

下面几种方式任选其一：

# Install script (recommended)

curl -fsSL https://opencode.ai/install | bash

# 或者通过 npm

npm install -g opencode-ai

# 或者通过 Homebrew（macOS/Linux）

brew install sst/tap/opencode

验证安装：

$ opencode --version

1.18.20

配置 AWS 凭证

OpenCode 的 Bedrock 提供商使用标准的 AWS 凭证链。配置以下任一方式即可：

方式 A：AWS IAM Identity Center（企业用户推荐）

aws sso login --profile my-bedrock-profile

export AWS_PROFILE=my-bedrock-profile

export AWS_REGION=us-west-2

方式 B：IAM 访问密钥

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE

export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

export AWS_REGION=us-west-2

把上面的值换成你自己的凭证。生产环境建议用 IAM Identity Center 或 IAM 角色，不要用长期有效的访问密钥。

方式 C：Bedrock API 密钥

export AWS_BEARER_TOKEN_BEDROCK=your-bedrock-api-key

export AWS_REGION= us-west-2

你也可以把这些存到项目根目录的 .env 文件里，保持配置持久可用。

配置多模型工作流

借助 OpenCode 的智能体系统，你可以给不同角色分配不同模型。在项目根目录创建或编辑 opencode.json：

{

"$schema": "https://opencode.ai/config.json",

"model": "amazon-bedrock/us.openai.gpt-oss-120b-1:0",

"agent": {

"plan": {

"model": " amazon-bedrock/global.moonshotai.kimi-k3"

},

"build": {

"model": "amazon-bedrock/us.nvidia.nemotron-super-3-120b"

}

} 这份配置把规划与架构类任务（需要深度推理）路由给 Kimi K3，代码生成和具体实现则交给 Nemotron 3 Super 120B，以获得更好的吞吐量。顶层的 model 字段把 GPT-OSS 120B 设为其他场景的默认模型。想以交互方式浏览可用的 Bedrock 模型，启动 OpenCode 后输入 /models 即可。

用开放权重模型写代码

下面的例子展示了如何把每个模型用在他最擅长的任务类型上。

用 GPT-OSS 120B 生成事件溯源订单服务

GPT-OSS 120B 是 OpenAI 推出的 1200 亿参数开放权重模型。它兼具强大的推理能力和代码生成能力，非常适合架构复杂、横跨多个文件的实现。

借助上一节的多模型配置，你可以在命令行里临时覆盖默认模型，也可以用 /model 显式切换：

$ opencode

> /model us.openai.gpt-oss-120b-1:0

> Build an event-sourced CQRS order service in Python (FastAPI) with:

> - Command side: append-only event store in DynamoDB, idempotent handlers

> - DynamoDB Streams triggering a projection Lambda that builds a read-model

> - Query side: denormalized read-model optimized for "orders by customer"

>   and "orders by status" access patterns

> - Event replay CLI to rebuild projections from scratch

> - Snapshotting every 50 events per aggregate to bound replay time

包含 CDK 基础设施。

图 2：OpenCode 用 GPT-OSS 120B 生成基于事件溯源的 CQRS 订单服务

OpenCode 通过 Bedrock Converse API 把请求路由到 GPT-OSS 120B，认证走 IAM。模型会把整套服务结构直接生成到本地文件系统，包括处理器（handler）、事件存储、投影（projection）和 CDK 堆栈。CloudTrail 会记录每次调用，你的 prompt 和模型响应都留在自己的 AWS 账户内。

用 Kimi K3 诊断分布式死锁

Kimi K3 擅长需要沿多条执行路径追踪的推理任务。它每一轮都会推理，reasoning_config 字段决定推理深度：low 适合快速过一遍，max 留给硬骨头。如果你把 Kimi K3 配成了 plan agent，它已经是分析任务的默认选择。也可以用 /model 显式切换：

/model amazon-bedrock/global.moonshotai.kimi-k3

这个 Step Functions 工作流在负载下大约 2% 的情况会卡住。

模式是这样的：任务 A 执行一次 DynamoDB 条件写入，期望 status="PENDING"；任务 B（由 SQS 触发）把 status 设为 "READY"，但要等任务 A 回调确认收到之后才动手。两个任务互相等待。请追踪这个死锁，解释它为什么只在并发下出现，并给出一个不需要重新设计状态机就能修复的方案。

@order_workflow.asl.json @task_a_handler.py @task_b_handler.py 用 @文件引用就能把本地代码当作上下文注入，不用手动复制粘贴。

Kimi K3 采用混合专家（MoE）架构，总参数量 2.8T，但每个 token 只激活其中 104B，因此既能给出前沿水平的推理，吞吐效率也不低。你能实时看到模型如何走完各条并发路径。推理过程是可见的，所以在接受它给出的修复方案之前，你可以先判断这套分析站不站得住脚。

会话中途切换模型

不必死守一个模型。会话里输入 /models 就能切换。

一个实用套路：日常快速生成代码、写模板代码时用 Nemotron 3 Super 120B 或 GPT-OSS 120B；碰到复杂调试问题，或者要权衡架构取舍，再切到 Kimi K3。

前面展示的多模型 opencode.json 配置能让这套路由自动完成：plan agent 用 Kimi K3 做推理，build agent 用 Nemotron 做实现。

用 Flex 层降低批量编码任务的成本

有些编码工作要来回交互，另一些则是批量的，比如在大型代码库里做整体重构、给已有模块生成测试套件，或者根据代码产出文档。这类任务对延迟不敏感，可以异步执行。

针对这类负载，Amazon Bedrock 的 Flex 层比标准层便宜 50%。配合 OpenCode 的命令行模式，可以把批处理写成脚本：

# Process multiple files through GPT-OSS 120B for test generation

for file in src/**/*.py; do

opencode run -m amazon-bedrock/us.openai.gpt-oss-120b-1:0 \

"Generate comprehensive unit tests for @${file}. Use pytest with fixtures."

完成分层配置：交互式会话用 Standard，批处理用 Flex，对延迟敏感的生产环境用 Priority。

扩展到多模型路由架构

本文介绍的 OpenCode + Bedrock 组合属于单开发者工作流。放到团队和生产系统中，同样的多模型思路可以扩展成一套路由架构——由一个编排器把每个子任务分派给最合适的模型：

Figure 3: Multi-model routing architecture using open weight models on Amazon Bedrock. A router analyzes incoming requests and dispatches sub-tasks to the optimal model tier to help reduce total cost of ownership compared to routing all tasks through a single model

图 3：在 Amazon Bedrock 上使用开放权重模型的多模型路由架构。路由器分析传入的请求，把子任务分派到最合适的模型层级，从而降低总拥有成本（TCO），避免所有任务都走同一个模型。

具体做法是：

意图分类交给低成本模型处理（模型小、推理快）。
代码生成用吞吐量优化的中端开放权重模型。
复杂推理（架构决策、安全分析）则走高端推理模型。

和所有任务都走同一个昂贵模型相比，这条路子能在不牺牲质量的前提下降低整体总拥有成本（TCO）。Amazon Bedrock 的统一 API 让这种方案变得可行：切换模型只是改一个参数，而且所有模型共用同一套身份认证、日志和安全护栏基础设施。如果团队想跳出单开发者场景，可以把 OpenCode 的本地代理路由，和一套服务端编排层（Amazon Bedrock Agents 或 AWS Step Functions）结合，搭建完整的多模型编码流水线。

生产部署：规模化多代理编排

AWS 客户 Ethara.AI 已经在生产环境部署了这套架构，用 OpenCode 作为 AI 工程和研究工作流的基础运行时，Oh-My-OpenAgent 则充当编排层，负责调度各类专用 AI 代理。Ethara.AI 并不依赖单一的编码助手，而是运行一整组代理，各自针对不同任务优化，涵盖规划、执行、代码审查、架构分析、知识检索、多模态理解和基准测试。

借助 Oh-My-OpenAgent 的按类别路由机制，工程师只需提出需求（比如深度推理、快速执行、可视化工程或写作辅助），系统就会把任务分派给最合适的智能体。这层抽象让团队能聚焦结果，而不用操心模型管理，同时还能灵活适应不断演进的 AI 框架。

Amazon Bedrock 与 OpenCode 采用与厂商无关的架构，支撑起 Ethara.AI 的模型选择策略。OpenCode 能接入各类基础模型，Amazon Bedrock 则提供对前沿模型的安全访问。Ethara.AI 不是只用一个模型，而是根据推理复杂度、延迟要求、成本效率和任务类型等因素，动态分配工作负载。

Amazon Bedrock、OpenCode 和 Oh-My-OpenAgent 三者结合，帮助他们把智能体能力与底层模型层解耦。这样既能确保每个任务都由最匹配的智能体—模型组合来执行，又能随着模型格局的变化，持续评估和引入新模型。

展望未来，Ethara.AI 正投入研发可自我改进的智能体系统，参考了 SkillClaw 等研究成果。他们正在开发一些机制，让技能和智能体行为能依据成功与失败的执行轨迹不断演进，从而构建出一套智能体可以在真实使用中持续变强的基础设施。这一愿景以 OpenCode 的可扩展架构、Oh-My-OpenAgent 的委派框架以及 Amazon Bedrock 的模型目录为基础，目标是打造出随时间推移变得更强、更自适应、更高效的 AI 系统。

企业使用时的安全考量

Bedrock 上的开放权重模型，享有与专有模型完全相同的企业级管控。权重来源不会改变你的安全态势。用遵循最小权限原则的 IAM 策略限制用户可调用的模型：


```json
"Version": "2012-10-17",
"Statement": [
  {
    "Effect": "Allow",
    "Action": [
      "bedrock:InvokeModel",
      "bedrock:InvokeModelWithResponseStream"
    ],
    "Resource": [
      "arn:aws:bedrock:us-west-2::foundation-model/openai.gpt-oss-120b-1:0",
      "arn:aws:bedrock:us-west-2::foundation-model/nvidia.nemotron-super-3-120b",
      "arn:aws:bedrock:us-west-2:{account-id}:inference-profile/global.moonshotai.kimi-k3",
      "arn:aws:bedrock:*::foundation-model/moonshotai.kimi-k3"
    ]
  },
  {
    "Effect": "Allow",
    "Action": ["bedrock:CallWithBearerToken"],
    "Resource": ["*"]
  }
]

你可以进一步叠加 Amazon Bedrock Guardrails，对所有调用做内容过滤和敏感信息（PII）脱敏。CloudTrail 会记录每一次 InvokeModel 调用，方便审计；Bedrock 不会用你的输入或输出来训练模型。

清理

这次演示除了开通模型访问权限，没有创建任何持久的 AWS 资源。如果你只是为了测试才开通模型访问，可以在 Amazon Bedrock 控制台的 Model catalog 下把它关掉。其他资源都不需要清理，不调用 API 就不会产生费用。

结语

我们演示了如何用 Amazon Bedrock 上的开放权重模型配置 OpenCode，搭建一套安全、灵活、按使用量付费的 AI 编程工作流。你可以同时收获开放权重模型的成本优势和可定制性，以及 Bedrock 的企业级安全与托管基础设施，还有一个融入现有开发流程的终端原生体验——并且能按任务自动路由到不同的模型。

想上手的话，先安装 OpenCode，配置好 AWS 凭证，再设置多模型配置即可。可以浏览完整的 Amazon Bedrock 模型目录，找到适合自己业务场景的模型，并用 Artificial Analysis Coding Index 对比各模型在编程任务上的表现。想进一步了解 Amazon Bedrock 的安全与合规信息，请参阅 Amazon Bedrock 用户指南。如果你想讨论 Amazon Bedrock 如何在你所在的组织里支持 AI 辅助开发，可以联系 AWS 代表。

关于作者

Aris Tsakpinis

Aris 是生成式 AI 方向的高级专家解决方案架构师，专注于 Amazon Bedrock 上的开源模型，以及更广泛的生成式 AI 开源社区。工作之外，他正在雷根斯堡大学攻读机器学习工程博士，研究方向是科学领域的应用自然语言处理。

Sainath Miriyala

Sainath 是 AWS 的高级技术客户经理，与汽车企业合作，加速自动驾驶相关项目，推动大规模的道路安全提升。

他专攻由 AI/ML 驱动的大规模分布式系统架构，帮助客户把复杂的技术需求转化为可直接上线的方案。工作之外，Sainath 喜欢陪伴家人和朋友。

Saurabh Trikande

Saurabh 是 Amazon Bedrock 和 Amazon SageMaker Inference 的资深产品经理。他热衷于与客户和合作伙伴共事，动力来自「让 AI 人人可用」这一目标。他关注的核心难题包括：部署复杂 AI 应用、多租户模型推理、成本优化，以及让生成式 AI 模型更容易部署落地。业余时间，Saurabh 喜欢徒步、了解新技术、刷 TechCrunch，以及陪伴家人。

Suryansh Rana

Suryansh 是 Ethara.AI 的联合创始人兼 CEO，负责带领公司在强化学习和训练能力更强的 AI 系统方面的工作。他毕业于 UCLA（加州大学洛杉矶分校），此前在 Canoo 和 Romeo Power 从事电动汽车电力电子与电池系统的研发。他带着一线工程师的思维方式，构建强化学习环境，帮助 AI 模型学会推理、使用工具并完成复杂任务。他关注的焦点，是缩小 AI「能生成什么」与「能可靠完成什么」之间的差距。

查看原文