Headroom Rust 代理 Phase D 详解原生 Bedrock 与 Vertex 信封、SigV4 签名与二进制 EventStream 流式转发【免费下载链接】headroomCompress tool outputs, logs, files, and RAG chunks before they reach the LLM. 20% fewer tokens for coding agents, 60-95% fewer tokens for JSON, same answers. Library, proxy, MCP server.项目地址: https://gitcode.com/GitHub_Trending/head/headroomHeadroom 的 Rust 代理headroom-proxy在 Phase D 阶段用原生路由替换了原本基于 LiteLLM 的假Bedrock/Vertex 路径——后者会在 Anthropic↔OpenAI 两种消息格式之间做有损转换。本文以REALIGNMENT/06-phase-D-bedrock-vertex.md为主线完整还原该阶段 4 个 PRD1 非流式 Bedrock Invoke、D2 EventStream 流式、D3 可观测性与 auth-mode 集成、D4 原生 Vertex publisher的设计目标、验收标准与回滚策略并结合仓库中实际落地的 Rust 源码信封解析、SigV4 签名、EventStream 增量解析器、GCP ADC token 缓存、Prometheus 指标逐层印证关键实现帮助你理解压缩之后再做签名字节保真契约无静默回退等工程约束如何在代码里兑现。一、Phase D 的目标、节奏与四个 PR 的分工Phase D 的总目标是让 Anthropic-on-Bedrock 与 Anthropic-on-Vertex 在穿过 Headroom 代理时完整保留thinking、redacted_thinking、document、search_result、image、server_tool_use、mcp_tool_use这些内容块同时接入 live-zone 压缩引擎与直接调用 Anthropic 时一致。原始文档给出的节奏与拆分如下日历2 周SigV4 与 EventStream 是主要工作量。形态4 个 PR。D1D2D3 面向 AWS BedrockD4 面向 GCP Vertex。依赖链D1 依赖 Phase C 的 PR-C1Anthropic SSE 状态机D2 依赖 D1D3 依赖 D2 与 PR-F1auth-mode 助手D4 依赖 C1 与 D1信封模式。D2/D3/D4 均阻塞 Phase H 的 PR-H2删除 Python LiteLLM 转换路径。PR分支风险新增 LOC核心内容PR-D1realign-D1-bedrock-native-invokeHIGH1500原生 Bedrock/model/{model}/invoke非流式路由 SigV4PR-D2realign-D2-bedrock-event-streamHIGH1100/invoke-with-response-stream二进制 EventStream 解析/转 SSEPR-D3realign-D3-bedrock-observabilityLOW400按模型/区域指标、IAM 归因、auth-mode 集成PR-D4realign-D4-vertex-nativeHIGH1300Vertex:rawPredict/:streamRawPredict ADC bearerPhase D 完成后的验收清单来自文档Phase D acceptance summaryRust 中原生 Bedrock/model/{model}/invoke路由/model/{model}/invoke-with-response-stream二进制 EventStream 被解析并翻译压缩后做 SigV4 签名signing post-compression所有 Anthropic 块类型穿过 Bedrock 不被破坏stop_sequence: null不再硬编码tool_calls.function.arguments保持字符串形态原生 Vertex:rawPredict与:streamRawPredict路由ADC bearer token 解析Bedrock/Vertex 均被归类为AuthMode::OAuthpassthrough-prefer 压缩按 Bedrock 模型、Vertex 模型的 Prometheus 指标。文档同时声明Phase D 淘汰 bug 清单里的 P4-37/38/39/43此后 Bedrock/Vertex 请求路径上不再经过 LiteLLM Python 转换器该转换器将在 Phase H 被删除。二、PR-D1非流式 Bedrock Invoke 与压缩后签名2.1 信封Envelope形状为什么 Bedrock 体里没有modelBedrock 的 InvokeModel 对任意anthropic.claude-*模型期望的请求体形如{ anthropic_version: bedrock-2023-05-31, messages: [...], max_tokens: 1024, ...其余 Anthropic 字段: ... }与直接调用 Anthropic/v1/messages的关键差异是model在 URL 路径里/model/{model}/invoke而不在 body 中anthropic_version是必需字段且必须是 Bedrock 认可的版本字符串如bedrock-2023-05-31。这一点在源码 crates/headroom-proxy/src/bedrock/envelope.rs 中被精确落地。BedrockEnvelope结构持有anthropic_version与完整解析后的Value并提供两类关键操作BedrockEnvelope::parse(body)只解析、不改写字节校验顶层是对象、anthropic_version存在且为字符串否则返回MissingAnthropicVersion/AnthropicVersionNotString/NotObject/NotJson结构化错误。BedrockEnvelope::ensure_anthropic_version_first(body)仅当压缩器返回Modified需要重组 body 时调用借助serde_json的preserve_order工作区默认开启保留键序仅在anthropic_version不是第一个键时才重排。源码注释中明确了一条缓存安全契约对应REALIGNMENT/02-architecture.md的 I1压缩器若返回NoChange代理原封不动转发最初缓冲的字节——绝不重新序列化若返回Modified其产出的字节切片已通过preserve_order保持键序ensure_anthropic_version_first在正常路径上几乎总是 no-op只是作为防御性断言确保字节序正确后再签名。2.2 关键约束SigV4 必须在压缩改写之后签名原始文档在 Notes 中强调签名范围覆盖host、x-amz-date、x-amz-content-sha256头 规范化请求体body 哈希必须在任何压缩改写之后计算。源码 crates/headroom-proxy/src/bedrock/sigv4.rs 用一段模块级注释把这条策略写成不变量失败签名尝试返回结构化错误处理器返回 5xx 并记录事件。我们绝不把未签名请求转发给 Bedrock。 body 字节在压缩之后被哈希。签名输入包含的[u8]就是转发器将要发送的精确字节切片不存在哈希压缩前 body的单独代码路径。sign_request的核心实现细节服务名固定为bedrockBEDROCK_SERVICE_NAME用于 SigV4 string-to-sign。通过PayloadChecksumKind::XAmzSha256强制把x-amz-content-sha256纳入规范化请求。源码解释原因若用 crate 默认的NoHeader签名器会跳过该头任何真正检查该头的下游网关都会 403。用aws-sigv4的SignableRequest::new(method, url, extra_signed_headers, SignableBody::Bytes(body))构造签名输入body必须恰好是即将发送的字节压缩后。签名器固定输出authorization、x-amz-date、x-amz-content-sha256三个头调用方还需把extra_signed_headers如content-type、accept一起纳入签名列表。每次签名成功都会发出event sigv4_signed的结构化日志含 region、method、host、body_bytes、headers_added便于运维确认签名发生。该模块还声明了几条刻意不做的边界不解析凭证那是aws-config的职责在应用启动时解析一次让每请求签名保持廉价不缓冲 body调用方在压缩门处缓冲是同一片字节不处理 SigV4a跨区变体因为 Bedrock 每区使用标准 SigV4。单元测试覆盖了四条性质固定输入产生确定性签名、改变 body 会改变签名、改变 region 会改变签名、最小请求必然产出authorization/x-amz-date/x-amz-content-sha256三头且签名是 64 位十六进制32 字节。2.3 Invoke 处理器的完整管线处理器入口 crates/headroom-proxy/src/bedrock/invoke.rs 的handle_invoke完整实现了文档描述的 6 步管线从路径提取{model_id}Bedrock 约定形如anthropic.claude-3-haiku-20240307-v1:0。若厂商是anthropic把 body 当作 Bedrock 信封解析并对 body 字节跑 live-zone Anthropic 压缩调度器——这个调度器与/v1/messages用的是同一个Bedrock 的 body 只是没有model字段的 Anthropic。重新发出可能被压缩的body保证anthropic_version是第一个键。构造上游 URLhttps://bedrock-runtime.{region}.amazonaws.com/model/{model}/invoke或运维覆盖端点。用 AWS SigV4 对压缩后的body 字节签名签名头覆盖host、x-amz-date、x-amz-content-sha256以及额外头content-type、accept。转发到 Bedrock把响应流式回给客户端。处理器的失败模式在源码注释里被明确列举与文档的无静默回退项目规则一致凭证缺失eventbedrock_credentials_missingWARN返回 500绝不转发未签名请求信封解析失败eventbedrock_envelope_parse_error原字节透传Bedrock 自己拒绝失败归属于客户而非代理与 Anthropic 压缩路径Outcome::Passthrough行为一致非 Anthropic 模型跳过压缩但仍然签名 转发Amazon Titan、Cohere、AI21、Meta 等厂商的 body 形状代理尚不理解做不透明透传SigV4 签名失败eventbedrock_sigv4_failed返回 500绝不转发未签名。值得留意的实现细节动作解析处理器同时挂载在/invoke与/converse上extract_invoke_action从入站路径推断 action以避免/converse请求被错误转发到上游/invoke。这是文档中PR-D1 修改lib.rs路由/model/{model}/invoke与/model/{model}/converse的落地。压缩调度run_anthropic_compression里对压缩器显式传入AuthMode::OAuth——源码注释解释Bedrock 下游使用 IAM 签名的 AWS SigV4入站请求可能有也可能没有自己的鉴权但 Bedrock 是 subscription/IAM 通道而非 PAYG所以硬编码RequestAuthMode::OAuth以跳过 PR-E3 的cache_control自动放置保持 Bedrock 字节契约稳定live-zone 压缩本身照常运行。可观测性RAII 守卫LatencyGuard在进入处理器时启动无论走哪条返回路径都在 Drop 时观测bedrock_invoke_latency_seconds直方图record_bedrock_invoke(model_id, region, auth_mode)在处理器入口就计数一次在任何错误路径 early-return 之前与结构化日志通过request_id关联。凭证来源从state.bedrock_credentials读取应用启动时通过aws-config默认链解析。aws_profile配置项允许指定 AWS profile 名未设置时走默认链env →[default]profile → IMDS。2.4 配置项region、endpoint、profile 与开关文档要求 D1 在 crates/headroom-proxy/src/config.rs 添加--bedrock-region默认us-east-1与 AWS 凭证配置。实际配置源码把这些做成了完整的一套 CLI 环境变量参数CLI flag环境变量默认值说明Bedrock 原生路由开关--enable-bedrock-nativeHEADROOM_PROXY_ENABLE_BEDROCK_NATIVE由 rollout 决定测试默认开特性门控Feature::NativeBedrock区域--bedrock-regionHEADROOM_PROXY_BEDROCK_REGIONus-east-1用于 SigV4 签名与未显式指定端点时推导上游 URL端点覆盖--bedrock-endpointHEADROOM_PROXY_BEDROCK_ENDPOINT无由 region 推导优先级CLI → 环境变量 → 由 region 推导FIPS/VPC/本地 mock 场景使用AWS profile--aws-profile—NoneNone时使用默认凭证链EventStream CRC 校验--bedrock-validate-eventstream-crcHEADROOM_PROXY_BEDROCK_VALIDATE_EVENTSTREAM_CRCtrue仅调试可关闭上游 URL 推导逻辑在build_bedrock_upstream中若state.config.bedrock_endpoint有值则直接作为 base否则用模板bedrock-runtime.{region}.amazonaws.com拼接https://。路径与 query 部分从原始 URI原样保留——Bedrock 的路径 schema/model/{id}/{action}与代理对外暴露的路径完全一致。2.5 D1 的验收标准、阻塞关系与回滚验收新增的集成测试全部通过在开发者真实 AWS 账号下手动测试成功既有的假 Bedrock 路径Python 端headroom/backends/litellm.py继续可用——本 PR 是在其旁路并行添加 Rust 路径。阻塞D1 依赖 PR-C1阻塞 D2、D3 与 Phase H 的 H2。回滚git revert。Bedrock 请求回落到 Python LiteLLM 转换器即假路径。未使用 Rust Bedrock 的用户没有回归。文档列出的 D1 集成测试位于crates/headroom-proxy/tests/integration_bedrock_invoke.rs覆盖了信封回环字节相等、压缩后 SigV4 正确签名、thinking/redacted_thinking/document 块保留、带图像的 tool_result 数组保留、stop_sequence: null仅当存在时出现、tool_use.input字节相等保留键序等。三、PR-D2二进制 EventStream 流式——不是 SSE3.1 EventStream 线格式Bedrock 的流式面/model/{id}/invoke-with-response-stream返回application/vnd.amazon.eventstream分帧消息不是Server-Sent Events。源码 crates/headroom-proxy/src/bedrock/eventstream.rs 用 ASCII 图描述了帧布局---------------------------------------------------------- | prelude (12B) | headers (N1 B) | payload (N2 B) | 4-byte CRC32 ----------------------------------------------------------Prelude 是三个大端 u32total_length消息起点到含尾部 CRC32 的长度、headers_lengthheaders 块字节数、prelude_crc32prelude 前 8 字节的 CRC32。payload 长度按total_length - 12 - headers_length - 4计算。每个 header 为[name_len: u8][name (UTF-8)][value_type: u8][value]AWS 定义了 10 种值类型Bedrock 实践中只用类型 7字符串[u16 BE 长度][字节]与类型 6字节数组。3.2 增量解析器状态化、无 panic、无回退TCP 分块在不可预测的边界交付——一条 EventStream 消息可能分散在任意数量的片段中到达一个 chunk 也可能含多条完整消息加一条残缺尾巴。解析器必须以状态化结构跨 chunk 恢复、不丢字节EventStreamParser累积到内部BytesMut在完整消息成形时通过next_message吐出API 形状刻意与sse::framing::SseFramerPhase C保持一致熟悉 SSE 侧的调用方可以直接迁移心智模型。解析器的关键工程约束对应项目规则feedback_no_silent_fallbacks.md永远返回Result从不 panic、从不用零值静默填充。ParseError的变体覆盖了每一种可诊断的畸形ImplausiblePreludeLengths { total_length, headers_length }total_length小于最小合法值12B prelude headers 4B CRC是线格式违例MessageTooLarge { total_length, cap }超过max_message_bytes上限默认 32 MiB AWS 文档最大值 16 MiB 的 2 倍余量防止损坏流解码出垃圾长度后分配 GB 级内存可用with_max_message_bytes覆盖PreludeCrcMismatch { expected, got }/MessageCrcMismatch { expected, got }CRC 不匹配指示在途比特翻转、chunk 截断或线格式版本漂移TruncatedHeader { offset, needed }、HeaderNameNotUtf8、HeaderValueNotUtf8、UnsupportedHeaderType { value_type, offset }头解析的逐点失败。CrcValidation枚举默认Yes与--bedrock-validate-eventstream-crcfalse调试 flag 联动运维可在排查时关闭 CRC 校验——但源码明确注释生产必须校验。3.3 EventStream → SSE 翻译与客户端选择文档要求 D2 新增eventstream_to_sse.rs对 Anthropic 形状的 Bedrock 响应每个:event-type为chunk的EventStreamMessage其 payload 携带一个 Anthropic SSE 事件代理把它重新作为 SSE 发出给客户端也可以原样透传 EventStream——具体走哪条由客户端Accept头决定。源码中EventStreamMessage提供event_type()与message_type()便捷访问器message_type区分event数据帧与exception同步错误。D2 的验收测试通过 真实 Bedrock 流式端点手动测试成功阻塞 H2回滚为git revert流式 Bedrock 回落 Python LiteLLM。D2 的测试矩阵crates/headroom-proxy/tests/integration_bedrock_streaming.rs包含eventstream_parses_correctly、eventstream_translated_to_sse、usage_extracted_from_translated_stream、client_can_choose_eventstream_or_sse以及一条属性测试proptest! { fn eventstream_parser_no_panic(bytes in any::Vecu8()) { let _ parse(bytes); } }——用任意字节流验证解析器不 panic。四、PR-D3Bedrock 侧可观测性与 auth-mode 集成D3 目标按 Bedrock 模型的指标、区域标记、IAM role 归因以及与 auth-mode 策略的集成Bedrock IAM 默认视为 oauth 模式压缩采用 passthrough-prefer。文档列出的 Prometheus 指标在 crates/headroom-proxy/src/observability/prometheus.rs 中被完整注册指标类型标签语义bedrock_invoke_count_totalCounter{model, region, auth_mode}每次 invoke 入口 1bedrock_invoke_latency_secondsHistogram{model, region}处理器入口到 Drop 的墙钟时间含上游 RTT 签名 压缩bedrock_eventstream_message_count_totalCounter{model, region, event_type}解析出的 EventStream 消息数按事件类型分桶源码注释解释了 RAII 设计LatencyGuard保证所有返回路径成功、签名失败、上游错误、响应构建失败都观测直方图避免未来有人新增错误路径时忘加埋点计数器在 handler 入口就增加一次请求一次在任何 early-return 之前与结构化日志通过request_id关联。auth-mode 分类文档要求把入站/model/.../invoke归类为AuthMode::OAuth。源码里这一动作不在处理器内重复分类——处理器通过ExtensionAuthMode提取中间件预先填好的值见 crates/headroom-proxy/src/bedrock/invoke.rs 顶部对 PR-F1 PR-D3 的注释中间件提供的值是单一真相源——处理器不重新分类那会与中间件的解析 WARN 日志产生漂移。Bedrock 专用分类逻辑位于 crates/headroom-proxy/src/bedrock/auth_mode_layer.rs。D3 的验收测试通过Prometheus scrape 包含 Bedrock 指标。回滚git revert丢失 Bedrock 可观测性功能路径不变。文档还要求新增docs/bedrock.md运维文档AWS 凭证配置、支持的模型——任意anthropic.claude-*、期望的压缩行为——仅 live-zone、偏好无损。五、PR-D4原生 Vertex publisher 路径5.1 路由与信封D4 添加两条路由POST /v1beta1/projects/{project}/locations/{loc}/publishers/anthropic/models/{model}:rawPredict POST /v1beta1/projects/{project}/locations/{loc}/publishers/anthropic/models/{model}:streamRawPredict信封同样使用anthropic_versionbody 字段、无model字段但鉴权头换成 GCP 的Authorization: Bearer jwt。Vertex 的流式与 Bedrock 相反——使用 SSE所以 PR-C1 的AnthropicStreamState可以直接工作无需 EventStream 解析器。5.2 GCP ADC → bearer token 解析Vertex 的:rawPredict/:streamRawPredict期望Authorization: Bearer jwt其中 JWT 是短生命周期的 Google 签名访问令牌来自 ADC provider 链gcloud 用户凭证、GCE/GKE metadata server、GOOGLE_APPLICATION_CREDENTIALS服务账号 JSON、workload-identity federation 等并在过期前刷新。源码 crates/headroom-proxy/src/vertex/adc.rs 的实现要点抽象而非直连TokenSourcetrait 只有两个显式实现——生产GcpAdcTokenSource与测试StaticTokenSource。源码注释解释理由测试绝不能真打 GCP无静默回退项目规则必须有一个显式且与生产区分的 mockgcp_auth每次调用都取 token缓存 过期前刷新的策略放在这一层使其独立可测可调。刷新策略令牌剩余寿命低于REFRESH_AHEAD_SECS60 秒时刷新避免请求恰好在过期时发出、与上游时钟竞争的悬崖失败60 秒足以覆盖慢上游与钟漂。gcp_auth内部虽缓存但仍要包一层以控制刷新前窗口gcp_auth的内部默认是实现定义、可能变动的并每次刷新发出event vertex_adc_token_refreshed结构化日志。默认 scopehttps://www.googleapis.com/auth/cloud-platformgcloud为 ADC 默认输出的最宽 scope。懒加载 providerGcpAdcTokenSource::new()不解析 provider——推迟到首次.bearer()调用让未实际接入 Vertex 路由的运维启动廉价。provider 缓存在MutexOptionArcdyn TokenProvider而非OnceCell因为初始化可能失败我们希望下次调用在瞬态失败后重试而非把 cell 永久锁死成错误。失败模式ADC 获取失败无凭证、metadata 不可达、IAM 拒绝等时处理器把TokenSourceError转成结构化 5xx502event vertex_adc_fetch_failed——绝不静默无 token 转发因为上游 401 比代理自己的 502 更难调试。5.3 rawPredict 处理器管线crates/headroom-proxy/src/vertex/raw_predict.rs 的forward_vertex_request同时被:rawPredict与:streamRawPredict复用管线步骤与注释一一对应缓冲 body受compression_max_body_bytes限制超限返回 413event vertex_body_too_large信封解析确认anthropic_version存在、model不存在不匹配返回 400event vertex_envelope_invalidlive-zone 压缩开启时body 就是/v1/messages接受的 Anthropic Messages 形状只是anthropic_version替代了model。调度器用基于RawValue的手术只改写messages[*]条目anthropic_version与其他非messages顶层字段字节相等回环。压缩器同样硬编码AuthMode::OAuthVertex 下游用 GCP ADC bearer 而非 Anthropic 凭证PAYG/OAuth/subscription 分类不适用跳过 E3cache_control自动放置ADC bearer token解析缓存、过期前刷新并附Authorization: Bearer token。ADC 失败 → 502绝不静默未鉴权转发转发到配置好的 Vertex 端点https://{region}-aiplatform.googleapis.com/path流式回写响应 body 不变。流式 SSE 字节原样回客户端。VertexCallContext载体结构从 URL 路径中解析出project、location、model_id、verb日志与错误路径共用一致字段。5.4 D4 的验收与回滚验收测试通过真实 Vertex 端点手动测试成功。阻塞 H2。回滚git revertVertex 请求回落 LiteLLM Python。测试矩阵crates/headroom-proxy/tests/integration_vertex_raw_predict.rsnative_envelope_round_trip_byte_equal、adc_bearer_token_signed_correctly、thinking_block_preserved、stream_raw_predict_sse_handled。六、把 4 个 PR 串起来字节保真、无静默回退与 auth-mode 统一从源码结构看Phase D 的四个 PR 共享三条贯穿始终的工程不变量这也是理解整个阶段设计的关键字节保真契约I1压缩器NoChange→ 原字节透传从不重新序列化Modified→ 借助preserve_order保键序ensure_anthropic_version_first作为防御性断言。这条契约让未修改字节字节相等回环成为可测试的性质D1/D4 的集成测试都以..._byte_equal命名。无静默回退SigV4 失败、ADC 失败、信封解析失败、EventStream CRC 不匹配——每一种失败都转为结构化 5xx 明确event日志绝不转发未签名请求、绝不静默用零值填充、绝不把解析失败吞掉。EventStream 解析器永远返回Result、TokenSource无 blanket impl、GcpAdcTokenSource用MutexOption而非OnceCell以便失败重试都是这条规则的体现。auth-mode 统一为 OAuthBedrockIAM 签名与 VertexGCP ADC bearer都不是 PAYG 通道因此压缩器在两条路径上都硬编码AuthMode::OAuth跳过 E3cache_control自动放置保证字节契约稳定而 live-zone 压缩照常运行。auth-mode 分类由中间件PR-F1 D3统一完成处理器只提取、不重新分类避免漂移。七、如何在仓库中继续深入信封与键序crates/headroom-proxy/src/bedrock/envelope.rsBedrockEnvelope::parse、ensure_anthropic_version_firstSigV4 签名crates/headroom-proxy/src/bedrock/sigv4.rssign_request、SigningInputs、PayloadChecksumKind::XAmzSha256非流式 Invoke 处理器crates/headroom-proxy/src/bedrock/invoke.rshandle_invoke、run_anthropic_compression、build_bedrock_upstream、LatencyGuardEventStream 增量解析crates/headroom-proxy/src/bedrock/eventstream.rsEventStreamParser、ParseError、CrcValidation、帧布局注释EventStream → SSEcrates/headroom-proxy/src/bedrock/eventstream_to_sse.rs 与 crates/headroom-proxy/src/bedrock/invoke_streaming.rsVertex ADC token 源crates/headroom-proxy/src/vertex/adc.rsTokenSource、GcpAdcTokenSource、REFRESH_AHEAD_SECSVertex rawPredict / streamRawPredictcrates/headroom-proxy/src/vertex/raw_predict.rs、crates/headroom-proxy/src/vertex/stream_raw_predict.rs、crates/headroom-proxy/src/vertex/envelope.rsBedrock auth-mode 中间件crates/headroom-proxy/src/bedrock/auth_mode_layer.rsPrometheus 指标crates/headroom-proxy/src/observability/prometheus.rsrecord_bedrock_invoke、observe_bedrock_invoke_latency、record_bedrock_eventstream_message配置项crates/headroom-proxy/src/config.rsbedrock_region、bedrock_endpoint、aws_profile、bedrock_validate_eventstream_crc、enable_bedrock_native、vertex_region集成测试crates/headroom-proxy/tests/integration_bedrock_invoke.rs、crates/headroom-proxy/tests/integration_bedrock_streaming.rs、crates/headroom-proxy/tests/integration_bedrock_authmode.rs、crates/headroom-proxy/tests/integration_vertex_raw_predict.rs阶段规划原文REALIGNMENT/06-phase-D-bedrock-vertex.md八、适用范围与前提以上实现均对应当前仓库中已落地的 Rust 代理代码Phase D 的 4 个 PR 在文档中规划为 HIGH/LOW 风险、合计约 4300 LOC当前代码已包含 D1–D4 对应的全部源文件与集成测试。Bedrock 路径要求配置 AWS 凭证--bedrock-region 默认凭证链或--aws-profile未配置时非流式 invoke 会以 500bedrock_credentials_missing拒绝转发而不是透传。Vertex 路径要求可解析的 GCP ADCgcloud 登录、GOOGLE_APPLICATION_CREDENTIALS或 metadata server解析失败返回 502vertex_adc_fetch_failed。压缩行为Bedrock 与 Vertex 都只启用 live-zone Anthropic 压缩偏好无损、passthrough-prefer不执行 PAYG 专属的cache_control自动放置非 Anthropic 厂商的 Bedrock 模型不做压缩、仅签名转发。流式差异Bedrock 用二进制 EventStream需 D2 的解析/翻译Vertex 用 SSE直接复用 PR-C1 的AnthropicStreamState。掌握以上内容后你可以独立定位 Bedrock/Vertex 请求在 Headroom Rust 代理中的完整生命周期——从路径路由、信封校验、live-zone 压缩、压缩后签名SigV4 / ADC bearer、EventStream 或 SSE 流式回写到按模型/区域的 Prometheus 可观测性以及每条失败路径的结构化错误与无静默回退边界。【免费下载链接】headroomCompress tool outputs, logs, files, and RAG chunks before they reach the LLM. 20% fewer tokens for coding agents, 60-95% fewer tokens for JSON, same answers. Library, proxy, MCP server.项目地址: https://gitcode.com/GitHub_Trending/head/headroom创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考