企业官网建设流程全解析

在AWS上用Claude做AI应用，很多人一开始会低估两件事：第一，Claude不是只能在官网网页上聊天，它可以通过Amazon Bedrock作为一段API接入你自己的系统；第二，从“能调用API”到“稳定上线”，中间还隔着一大段工程工作——权限、模型选择、异常处理、成本控制、日志监控，任何一个环节没想清楚，项目都会卡在半路。

这篇文章准备把“在AWS上用Claude从开发到落地”这条链路完整拆一遍。先说明我的判断：在AWS上落地Claude，真正决定项目成败的不是“选哪个模型”，而是能不能把四条链路串起来——模型接入链路（Bedrock）、开发工具链路（Claude Code）、Agent编排链路、生产部署与成本治理链路。前两条解决“能不能跑起来”，后两条解决“能不能长期稳定跑下去”。

如果你正在做AI应用开发、Agent开发，或者团队准备把Claude接入内部业务系统，那这篇文章应该能帮你少走不少弯路。我们会从环境准备讲到模型开通，从Claude Code安装讲到Python完整示例，从Lambda部署讲到常见问题排查，最后给出工程上的最佳实践。文章里的代码和配置都经过整理，可以直接复制到自己的环境里验证。

1. 这篇文章真正要解决的问题

先说实话：现在关于Claude和AWS的资料并不少，但大部分内容只覆盖了其中一个片段。

有人只讲Bedrock控制台怎么开模型，不讲代码怎么调用；有人只讲Claude Code怎么安装，不讲怎么对接Bedrock而不是Anthropic官方API；还有人一上来就谈Agent架构，但读者连模型都没调通，根本接不上那个语境。

在AWS上用Claude开发，最典型的三类卡点是这样的。

第一类是接入卡点。AWS账号开了，但不知道Bedrock在哪里开通模型访问权限，也不知道IAM角色应该配什么策略。调接口时遇到AccessDeniedException，第一反应是去改密钥，实际原因往往是模型访问没有开通。

第二类是开发工具卡点。很多开发者会用Claude Code做AI辅助编程，但装完之后发现Windows上报“claude不是内部或外部命令”，或者不知道如何让Claude Code走Bedrock通道，而不是去连Anthropic官方的账号。

第三类是落地卡点。Demo写完，模型调用也通了，但怎么部署成线上服务？用Lambda还是ECS？成本怎么控？ASG（Auto Scaling Group）把desired设为0了，为什么账单还在涨？这类问题如果不提前想清楚，项目往往会卡在“开发完成、上线受阻”的状态。

这篇文章就是围绕这三类卡点展开的。读完你应该能回答下面几个问题：

• Amazon Bedrock、Claude Code、Agent三者是什么关系，怎么组合使用。
• 从零开始，如何开通Bedrock模型访问并用AWS CLI验证。
• Claude Code如何安装、对接Bedrock、处理Windows环境常见问题。
• 如何用Python写一个真实可用的Claude数据提取示例，并演进出Agent形态。
• 如何通过Lambda + API Gateway把Claude应用部署上线。
• 上线后如何做权限、成本、监控和模型质量管理。

2. 三条技术路线：Bedrock、Claude Code、Agent 分别解决什么

在展开实操之前，先把几个概念的关系理清楚。很多新人混淆它们，是因为这三者都和“Claude”有关，但在AWS的语境里，它们属于完全不同的层次。

2.1 Amazon Bedrock：模型接入层

Bedrock是AWS的托管大模型服务。它的作用很简单：让你用统一的API调用包括Claude在内的多家大模型，而不需要自己去部署模型或管理GPU服务器。

对开发者来说，Bedrock解决的核心痛点是模型调用的“企业化接入”。比如模型访问权限可以纳入IAM管理，调用日志可以进入CloudWatch，账单可以和AWS其他服务统一结算，网络请求可以走在VPC里。这些特性对个人开发者可能不太重要，但对有合规要求的业务系统非常关键。

2.2 Claude Code：AI编程工具层

Claude Code是Anthropic推出的命令行AI编程助手，可以在终端里读取你的代码仓库、修改文件、执行命令、提交代码。它的定位是“帮程序员更快写代码”，而不是“给业务系统提供模型能力”。

这里容易混淆的点是：Claude Code是一个面向开发者的交互式工具，不是后端服务。你不能把它直接嵌到自己的业务系统里，但你可以用它加速开发过程。同时，Claude Code可以配置成走Bedrock通道，也就是说，你用AWS的模型访问权限来驱动这个编程助手，而不再需要额外的Anthropic账号。

2.3 Agent：应用形态层

Agent是以大模型为核心、能够调用外部工具和系统来完成任务的软件形态。比如让Claude读一段OCR识别出来的合同文本，调用代码做字段校验，再写入数据库，这就是一个极简Agent的雏形。

Agent和普通API调用的区别在于：普通API调用是“问一句答一句”，Agent则多了规划、工具调用、循环执行的环节。在AWS落地Agent，通常的架构是“Bedrock提供模型能力 + Lambda或ECS承载业务逻辑 + 其他AWS服务作为工具”，这条链路是本文后面示例的主线。

2.4 三者如何组合

可以用一句话概括：Bedrock是发动机，Claude Code是修车工具，Agent是你造的车。发动机决定性能上限，修车工具决定造车效率，而车能不能上路，取决于你整体的设计和工程水平。

我们用一张表来对比，方便你判断自己当前最需要哪一块。

3. 环境准备与前置条件

动手实操前，先把环境准备好。我们不需要特别高的机器配置，普通的开发电脑就够用，因为重计算都在AWS侧完成。

3.1 AWS账号与Region选择

你需要一个可以登录AWS控制台的账号。首次使用建议选择模型覆盖比较全的Region，比如美东（us-east-1）或美西（us-west-2）。不同Region的Bedrock模型可用性不同，这是很多新人踩坑的地方——在某个Region找不到某个模型，大概率不是没权限，而是这个Region根本没上架。

3.2 IAM用户与访问密钥

实际开发中不建议直接用根账号的Access Key。更稳妥的做法是创建一个IAM用户，只授予Bedrock相关的最小权限，然后把Access Key配置到本地。

创建IAM用户时，先不急着给任何权限。我们后续会用到两种权限场景：一种是在本地用AWS CLI调用Bedrock，另一种是在Lambda里调用Bedrock。前者需要给IAM用户挂一个内联策略，后者需要给Lambda的IAM角色挂策略。

3.3 本地工具链

需要安装的本地工具如下：

安装完成后，先用AWS CLI配置访问密钥：

aws configure

按照提示输入Access Key ID、Secret Access Key和Region。配置完成后，可以用下面命令验证身份是否生效：

aws sts get-caller-identity

如果输出里能看到你的账号ID和IAM用户名，说明本地AWS环境已经就绪。

4. 在Amazon Bedrock上启用Claude模型

这一步是整个流程的门槛。很多人在调用Claude时报AccessDeniedException，不是因为密钥错了，而是因为根本没有在Bedrock控制台里开通模型访问权限。

4.1 申请模型访问权限

登录AWS控制台，进入Amazon Bedrock服务页面。在左侧菜单找到“Model access”（模型访问），点击“Manage model access”，勾选你要用的Anthropic Claude模型，然后提交申请。

这里有一个常见误解：以为申请之后要等很久。实际上，Anthropic Claude模型在Bedrock上通常是自动审批或者几分钟内就能生效，只有少数模型需要人工审批。开通成功后，控制台里对应模型的状态会变成“Access granted”。

4.2 用AWS CLI验证模型调用

开通完成后，先用AWS CLI做一次最小验证。Claude在Bedrock上的调用协议和Anthropic官方API类似，核心字段包括anthropic_version、max_tokens和messages。

aws bedrock-runtime invoke-model \ --model-id anthropic.claude-3-5-sonnet-20241022-v2:0 \ --region us-east-1 \ --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":64,"messages":[{"role":"user","content":"用一句话说明什么是Amazon Bedrock"}]}' \ --cli-binary-format raw-in-base64-out \ invoke-model-output.txt

运行成功后，查看输出文件：

cat invoke-model-output.txt

你会看到类似下面的JSON结构：

{ "id": "msg_xxx", "type": "message", "role": "assistant", "content": [ { "type": "text", "text": "Amazon Bedrock是AWS提供的托管大模型服务，可以用来调用多种基础模型。" } ], "stop_reason": "end_turn", "usage": { "input_tokens": 18, "output_tokens": 26 } }

这段输出说明Bedrock链路已经打通。注意model-id参数，不同Region、不同账号看到的模型ID可能不完全一样，以Bedrock控制台里显示的模型ID为准，这里的anthropic.claude-3-5-sonnet-20241022-v2:0是早期常用的一个格式参考。

4.3 这一阶段最常见的错误

如果执行时返回AccessDeniedException，按以下顺序排查：先确认Bedrock控制台里模型访问状态是否为“Access granted”，再确认IAM用户是否有bedrock:InvokeModel权限，最后确认Region是否正确。这三项占了九成以上的失败原因。

5. 安装并配置Claude Code

模型链路通了之后，再来看开发工具。Claude Code的价值在于：你可以在终端里让它阅读代码、生成文件、运行测试，等于把AI编程助手直接嵌到开发流程里。

5.1 安装方式

Claude Code的官方推荐安装方式是通过npm全局安装：

npm install -g @anthropic-ai/claude-code

安装完成后，在终端执行：

claude --version

这里有一个很典型的坑：Windows用户在PowerShell里执行claude时，可能看到这样的提示——claude : 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。原因是npm全局安装目录没有加入系统的PATH环境变量。

有两种解决办法。第一种是把npm全局目录加入PATH；第二种是临时用npx启动，不污染全局环境：

npx @anthropic-ai/claude-code

5.2 对接Bedrock

Claude Code默认会尝试连接Anthropic官方服务。如果你使用AWS环境，可以通过环境变量让它走Bedrock通道。以Linux或macOS为例：

export CLAUDE_CODE_USE_BEDROCK=1 export ANTHROPIC_MODEL=anthropic.claude-3-5-sonnet-20241022-v2:0 export AWS_REGION=us-east-1 claude

Windows PowerShell用户对应写法：

$env:CLAUDE_CODE_USE_BEDROCK="1" $env:ANTHROPIC_MODEL="anthropic.claude-3-5-sonnet-20241022-v2:0" $env:AWS_REGION="us-east-1" claude

认证方面，Claude Code会通过AWS默认凭证链获取访问密钥，也就是说，只要你前面执行过aws configure，就能直接使用。具体环境变量名在不同版本中可能有调整，建议以官方文档为准。

5.3 持久化配置

每次打开终端都要export一遍环境变量很麻烦，可以把配置写进Claude Code的配置文件~/.claude/settings.json：

{ "env": { "CLAUDE_CODE_USE_BEDROCK": "1", "ANTHROPIC_MODEL": "anthropic.claude-3-5-sonnet-20241022-v2:0", "AWS_REGION": "us-east-1" } }

这样启动claude命令时会自动加载这些配置。

5.4 界面与工作区概念

启动Claude Code后，你会进入一个交互式终端界面，可以像聊天一样输入指令，比如“阅读当前目录的README并总结项目结构”“给某个函数补充单元测试”。它会在你的工作区里直接读写文件，因此建议只在版本管理的项目目录中使用，避免它对临时目录里的文件乱改。

6. 完整示例：用Claude从文本中提取结构化数据

工具链准备好之后，我们用真实场景写一个完整示例。这个场景在开发中非常常见：上游系统给了一段非结构化文本，可能是OCR识别出来的合同内容、客户留言、工单描述，我们需要让Claude把关键字段提取出来，输出成结构化JSON。

6.1 场景设定

假设我们拿到一段采购合同文本，需要提取“供应商名称”“合同金额”“签订日期”三个字段。如果只用正则写解析逻辑，供应商名称稍微变一下格式，正则就得重写。而让Claude来做提取，只要提示词写清楚，它能扛住大部分格式变化。

关键点在于：Claude返回的是文本，理论上说“JSON”，但实际返回内容里可能带有解释文字。所以提取层要做两件事：第一，让模型严格只输出JSON；第二，在代码里做一次JSON解析和字段校验。这就是最简单的Agent雏形——模型负责理解，代码负责确定性。

6.2 完整Python代码

新建文件extract_contract.py，代码如下：

import boto3 import json import re bedrock_runtime = boto3.client( service_name="bedrock-runtime", region_name="us-east-1" ) MODEL_ID = "anthropic.claude-3-5-sonnet-20241022-v2:0" SYSTEM_PROMPT = """ 你是一个合同信息提取助手。用户会给你一段合同文本，你需要提取以下字段： - supplier_name: 供应商名称 - contract_amount: 合同金额，只保留数字 - sign_date: 签订日期，格式为YYYY-MM-DD 要求： 1. 只输出JSON，不要输出任何解释文字。 2. JSON格式固定为 {"supplier_name": "...", "contract_amount": "...", "sign_date": "..."} 3. 如果某个字段无法从文本中找到，值设为 null。 """ def call_claude(text: str) -> str: body = json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024, "temperature": 0, "system": SYSTEM_PROMPT, "messages": [ { "role": "user", "content": f"请提取以下合同文本的字段：\n\n{text}" } ] }) response = bedrock_runtime.invoke_model( modelId=MODEL_ID, contentType="application/json", accept="application/json", body=body ) result = json.loads(response["body"].read()) return result["content"][0]["text"] def parse_json_response(raw_text: str) -> dict: """从模型输出中解析JSON，去掉可能存在的代码块标记。""" cleaned = raw_text.strip() cleaned = re.sub(r"^```json\s*", "", cleaned) cleaned = re.sub(r"\s*```$", "", cleaned) return json.loads(cleaned) def validate_fields(data: dict) -> dict: """对模型提取结果做二次校验，属于Agent里的确定性兜底。""" required = ["supplier_name", "contract_amount", "sign_date"] for field in required: if field not in data or not data[field]: data[field] = None return data if __name__ == "__main__": sample_text = """ 采购合同 甲方：上海某某科技有限公司 乙方：深圳市振华精密机械有限公司 双方于2025年3月18日签订本合同，合同总金额为人民币贰拾陆万伍仟元整（￥265000.00）。 """ raw_output = call_claude(sample_text) print("模型原始输出：") print(raw_output) print("---") extracted = validate_fields(parse_json_response(raw_output)) print("结构化结果：") print(json.dumps(extracted, ensure_ascii=False, indent=2))

6.3 关键逻辑解释

这段代码里有三个值得注意的设计。

第一，system提示词里明确要求“只输出JSON，不要输出任何解释文字”，并且给出了字段格式和缺失值处理规则。模型对格式约束的理解能力很强，但你必须把规则说死，否则它会自作主张加解释。

第二，parse_json_response对模型输出做了一层清理。这是因为模型偶尔会把JSON包在Markdown代码块里，直接json.loads会报错。这种“别信模型输出一定干净”的意识，是做AI应用的基本素养。

第三，validate_fields做了确定性兜底。模型可能漏字段、给错类型，代码负责把不符合要求的数据纠正为null，或者输出告警。把“模型负责理解，代码负责确定性”这个原则拆开，是Agent开发里很关键的分工。

6.4 运行与结果验证

在配置好AWS密钥的机器上执行：

python extract_contract.py

预期输出类似：

模型原始输出： {"supplier_name": "深圳市振华精密机械有限公司", "contract_amount": "265000.00", "sign_date": "2025-03-18"} --- 结构化结果： { "supplier_name": "深圳市振华精密机械有限公司", "contract_amount": "265000.00", "sign_date": "2025-03-18" }

如果输出不是这个格式，先检查是不是region_name或者MODEL_ID与你的环境不一致，再看IAM用户是否有bedrock:InvokeModel权限。错误日志里通常会直接告诉你是哪一步失败。

7. 落地部署：Lambda + API Gateway 将Claude应用上线

Demo跑通只是第一步。真正落地到生产环境，我们要考虑：接口怎么暴露、权限怎么控制、日志怎么看、成本怎么控。用Lambda + API Gateway是相对轻量且成本友好的方案，特别适合文档提取这类不需要长时间会话的场景。

7.1 为什么选Lambda

拿文档提取这个场景来说，它不是常驻服务，是来一个请求处理一次。用EC2或ECS常驻一个服务当然可以，但空闲时间也在计费；Lambda按调用次数和运行时长计费，空闲时不花钱，对这类场景更合适。

如果你后续要做多轮对话、长连接、流式输出，再换成ECS或EKS也来得及。先用Lambda跑通业务，是更稳的落地路径。

7.2 配置Lambda的IAM角色

创建Lambda函数时，需要指定一个IAM角色。这个角色只需要一个权限：调用Bedrock模型。策略如下：

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock:InvokeModel" ], "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0" } ] }

这里刻意把Resource限定到了具体模型，而不是写成*。最小权限原则在AI应用里同样适用，避免Lambda一旦被滥用，攻击者能调用账号下所有模型。

7.3 Lambda函数代码

在Lambda控制台创建函数，运行时选择Python 3.x，把下面的代码粘贴到lambda_function.py：

import json import boto3 bedrock_runtime = boto3.client( service_name="bedrock-runtime", region_name="us-east-1" ) MODEL_ID = "anthropic.claude-3-5-sonnet-20241022-v2:0" def lambda_handler(event, context): text = event.get("text", "") if not text: return { "statusCode": 400, "body": json.dumps({"error": "text字段不能为空"}, ensure_ascii=False) } body = json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024, "temperature": 0, "messages": [ { "role": "user", "content": f"从以下文本中提取供应商名称、合同金额、签订日期，只输出JSON：\n\n{text}" } ] }) response = bedrock_runtime.invoke_model( modelId=MODEL_ID, contentType="application/json", accept="application/json", body=body ) result = json.loads(response["body"].read()) model_text = result["content"][0]["text"] return { "statusCode": 200, "headers": { "Content-Type": "application/json" }, "body": json.dumps({"result": model_text}, ensure_ascii=False) }

7.4 通过API Gateway暴露接口

在Lambda控制台创建函数后，选择“添加触发器”，类型选“API Gateway”。创建HTTP API后，系统会生成一个调用URL。后续客户端向这个URL发送POST请求，把文本放在text字段里，就能拿到Claude的提取结果。

有几个生产环境需要特别注意的点：

• Lambda默认超时是3秒，调用Claude往往不够。建议在Lambda配置里把超时调整到1分钟，否则模型输出稍长就会超时。
• 不要在Lambda代码里写死Access Key，用IAM角色自动获取临时凭证，这是安全底线。
• API Gateway默认不限制调用频率，如果担心成本被刷，可以在API Gateway或WAF层加限流。

8. 运行验证与效果检查

部署完成后，用curl做一次端到端验证：

curl -X POST https://你的API-Gateway地址 \ -H "Content-Type: application/json" \ -d '{"text": "合同编号HT-2025-001，供应商为苏州工业园区众合电子有限公司，签约金额18.5万元，日期2025年4月2日。"}'

预期返回结果：

{ "result": "{\"supplier_name\": \"苏州工业园区众合电子有限公司\", \"contract_amount\": \"185000\", \"sign_date\": \"2025-04-02\"}" }

判断这次落地是否成功，可以从三个维度看：

第一，功能维度。接口能稳定返回预期JSON，多次测试中字段准确率可以接受，没有出现大面积解析失败。第二，工程维度。CloudWatch日志能完整记录每次调用的请求和响应，IAM权限是最小化的，账单在预算范围内。第三，体验维度。接口响应时间在业务可接受范围内。如果发现模型输出慢，可以考虑换更小更快的模型，或者把请求改成异步模式。

如果验证失败，第一件事是去Lambda的CloudWatch日志里看错误堆栈。AccessDeniedException说明IAM角色权限问题，timeout说明函数超时设置太短，json.decoder.JSONDecodeError说明模型输出不是合法JSON，对应调整提示词或者增强解析容错。

9. 常见问题与排查方法

把开发上线过程中最容易遇到的几个问题整理成下面这张表，建议收藏备用。

这里特别说一下ASG的计费问题。很多开发者以为把Auto Scaling Group的desired capacity设为0，成本就会归零。这个操作确实会终止ASG托管的EC2实例，实例的计算费用会停止，但账单里仍然可能出现费用，原因是关联资源没有一起释放。常见的有：绑定的弹性IP（Elastic IP）本身会计费、NAT网关按小时计费、负载均衡器按LCU计费、EBS快照按存储量计费。做成本治理时，不能只盯着EC2这一项，要把整个VPC网络链路上的资源都过一遍。

另外还有一类问题值得单独提醒：Bedrock模型并不是每个Region都齐全。换了一个Region发现找不到之前用的模型，先去控制台确认该Region是否支持，再决定是切换Region还是调整模型选择。

10. 最佳实践与工程建议

10.1 IAM权限与安全边界

AI应用的权限管理往往比普通应用更复杂，因为模型调用是一种“高价值API”。建议从三个层面控制边界。

第一，权限最小化。IAM策略里的Resource尽量限定到具体模型，不要图省事写*。第二，密钥管理。绝不把Access Key写在Lambda代码或前端代码里，Lambda用IAM角色，EC2用Instance Profile，本地开发用环境变量或AWS配置。第三，数据合规。如果业务数据涉及个人信息，建议在代码层面做脱敏和审计，明确哪些数据可以传给模型，哪些必须过滤。

10.2 成本治理

Bedrock按token计费，这意味着成本通常和“输入文本量、输出长度、调用次数”强相关。建议从几个方向控制成本。

按模型分级。简单任务用便宜的小模型，复杂任务才用更强的模型，尽量避免所有请求都走同一款大模型。按调用量设限。利用AWS Budgets设置月度预算，超过阈值自动告警；在API Gateway层做并发限制或请求配额。还要关注流式和非峰值请求。不需要实时响应的批量任务，可以放到异步队列里处理，利用空闲时段降低成本。

在应用层还有一个容易被忽略的点：提示词越长，每次调用的输入token成本越高。系统提示词里不必要的背景说明、过长的示例，都是持续支出的成本。建议定期审查生产环境里的提示词，删掉无用内容。

10.3 可观测性与模型质量

大模型应用的可观测性比普通应用更重要，因为它多了一层不确定性。除了常规的API错误率、接口延迟，建议把每次调用的模型输出、输入token数、输出token数、用户反馈记录下来。

在Bedrock侧，可以开启Model Invocation Logging，把调用日志写入CloudWatch或S3。这样一旦线上出现“某段时间提取结果质量下降”的问题，你能回溯到具体是改了提示词、换了模型，还是上游文本格式变了，而不是靠“感觉”排查。

模型质量的评估也是工程问题，不是玄学。建议准备一份固定测试集，比如50到100条有标准答案的合同文本，每次修改提示词或切换模型后，在这份测试集上跑一遍准确率。没有评测集的AI应用，改提示词就像在盲改代码。

10.4 版本管理与灰度发布

提示词本质上也是代码。提示词的变更、模型的切换、参数的调整，都应该走版本管理。实际项目中可以这样操作：把不同版本的提示词存成配置文件或单独目录，在代码里通过版本号引用；先用小流量测试新提示词，确认质量不下降后再全量切换。

如果线上应用对格式要求严格，建议在调用层加一层“结构化输出校验”。比如让Claude先输出JSON，再用代码校验必填字段、类型、枚举范围，校验失败时自动重试或者降级。这样能显著减少脏数据进入下游系统。

11. 总结与后续学习方向

这篇文章从问题出发，把在AWS上用Claude从开发到落地的完整链路拆了一遍：先用Bedrock打通模型接入，再用Claude Code提升开发效率，接着通过一个文本提取示例演示了模型调用和Agent雏形，最后用Lambda和API Gateway完成上线，并整理了权限、成本、可观测性方面的实践建议。

如果只记一句话，那就是：AI应用的开发链路和普通后端应用没有本质区别，模型只是其中一环，工程化和成本治理才是决定成败的关键。Claude再强，如果权限混乱、成本失控、输出不可验证，项目照样会失败。

下一步建议你先做一件最小的事：用AWS CLI跑通一次Bedrock的invoke_model调用，然后用Python把你的业务文本交给Claude提取字段。这比看十篇教程都有用。跑通之后，再去研究Lambda部署、API Gateway限流、提示词评测、LangChain4j或LangGraph这类Agent框架。

最后提醒一句：所有涉及生产环境的变更，先在小流量或测试环境验证，再逐步放量。模型返回不稳定的情况一定会出现，你的架构里需要给“不稳定”留好兜底方案。