最近做一个企业文档处理的项目：从大量 PDF 里抽关键信息、做摘要，同时要保证数据链路尽量不出内部网络。看了一圈方案后，我选了 Amazon Bedrock 上的 Anthropic Claude（以 Sonnet 系列为主）。
为什么选 Claude
我最终看中的是三点：长上下文、多模态、以及更适合企业场景的“稳”。
1）长上下文：省掉切片工程
项目里要处理的文档动辄上百页（合同、年报、技术文档）。如果模型上下文不够，就要“切片 → 分段总结 → 合并 → 处理断裂”，链路又长又容易漏信息。
我做过一个粗测：一份 150 页的 PDF（文本为主）喂进去大概在 8 万 token 量级，完整跑下来上下文还能保持连贯，不太会出现“读到后面忘了前面”的情况（不同 PDF 差异很大，这个数只能当量级参考）。
2）多模态：表格/截图能直接吃
文档里经常夹表格、图表。Sonnet 支持图像输入，能把“截图表格”直接转成结构化输出。我的样本里：
- 简单表格（列规整、没有太多合并单元格）准确率能到 约 95%
- 复杂表格（多层嵌套、合并单元格）大概 约 85%，需要人工复核
结论是：能显著减少录入工作量，但别指望完全无人值守。
3）安全对齐：企业落地更省心
企业场景更怕“模型放飞”。Claude 的回答风格相对谨慎，配合内部的审计/规则，落地成本更可控。
为什么走 Bedrock，而不是直接调 Anthropic 官方 API
两条路我都试过。我的选择标准很现实：合规优先，其次是工程集成。
Bedrock 更适合这些情况
- 数据路径更可控：可以配合 VPC 端点走内网链路，尽量不走公网（对敏感文档很关键）。
- 和 AWS 生态更顺：S3 存文档、Lambda 做流程，接 Bedrock 少一层封装。
- 权限治理更统一：用 IAM 做细粒度权限控制，审计也更方便。
官方 API 更适合这些情况
- 接入更快：不用折腾 AWS 权限、VPC、配额。
- 新模型跟进可能更快：Anthropic 发布后，云平台通常会有一个上线周期（快则几天，慢则更久）。
如果你没有强合规/内网链路要求，且项目规模不大，官方 API 真的更省事；反过来，就优先 Bedrock。
三、我测的 2 个典型场景
下面的数据是我跑样本时记录的“效果与耗时”。成本我按 Sonnet 4.6 的公开定价口径计算，方便你估算量级。
成本估算公式：
成本 ≈ 输入 token ×（输入单价/1,000,000） + 输出 token ×（输出单价/1,000,000）
场景 1：合同关键信息抽取
- 输入：30 页采购合同 PDF（约 1.8 万 token）
- 任务：提取甲方、乙方、合同金额、签订日期、有效期
- 结果：5 次测试，字段完全正确 4 次；1 次漏了“有效期”
后来我在 prompt 里加了“若未出现也要返回‘未注明’”，问题基本解决 - 耗时：约 6–8 秒
- 成本：仅按输入 token 计约 \$0.054/次；加上输出后一般在 \$0.06 左右（取决于你让模型输出多长）
场景 2：截图表格转 JSON
- 输入：一张包含约 20 行数据的销售报表截图
- 任务：转成 JSON
- 结果：整体准确率约 85%；少量数值会出错（例如 3.2 识别成 3.1）
我最后还是加了人工复核，把错的那几项改掉
几个很容易踩的坑
1. Bedrock 的模型访问需要单独开
开通 Bedrock 不等于能直接用所有模型。一般要在控制台里到 Model access 申请对应 Claude 模型权限，等它生效。
2.请求体和官方 API 不一样
Bedrock 调 Claude（Messages API）需要在请求体里带 anthropic_version: "bedrock-2023-05-31"，字段结构也和官方 API 不完全一致。建议直接对照 AWS 的请求/响应示例来写。
3.VPC 端点 + Lambda 的网络与安全组
要走内网链路就绕不开 VPC 端点。Lambda 要放同 VPC、路由和安全组都要配对，不熟的话很容易卡在“能调用但超时/连不上”这种问题上。
4.别只盯输入上限，输出也可能被截断
长文档能塞进去，不代表你能“吐出同样长的报告”。max_tokens 的上限、服务配额、以及模型是否支持更长输出，都需要你提前确认；想输出长内容，务必在一开始就把输出策略设计好（分段输出、按章节生成、或用支持更长输出的配置/功能）。
结论
1）长上下文的价值是“省工程”。相比切片合并，链路短、失真少，能把复杂度压下来。
2）成本别只算 token 单价。切片服务、复核流程、合规审计、运维投入，往往比那点 token 差价更决定总成本。
3）企业落地优先看数据链路。能不能内网调用、权限怎么管、日志怎么审，这些决定了方案能不能进生产。
