big-AGI 中 Anthropic Messages API 集成的同步审计指南wiretypes、请求适配器与流式解析器的全链路校验【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI导读本文是一份面向开发者与维护者的技术审计指南讲解如何在 big-AGI 开源仓库中以官方 API 文档与线上真实请求为基准对 AnthropicClaudeMessages API 的集成实现进行系统性同步与校验。文章围绕仓库中三个核心文件展开——消息线类型定义anthropic.wiretypes.ts、请求装配适配器anthropic.messageCreate.ts、以及流式/非流式响应解析器anthropic.parser.ts读完你既能掌握如何审计一份 LLM 供应商集成是否与上游协议一致也能了解 big-AGI 在 Anthropic 协议层沉淀的具体实现细节与工程化手法。审计目标与范围仓库中 Anthropic 集成的三个锚点同步审计的第一步是明确看哪里。仓库中 Anthropic 的实现被刻意拆分为三个职责单一的文件分别对应协议的类型定义—请求构造—响应解析三段链路这也是官方 Claude Code 命令.claude/commands/aix/sync-anthropic-api.md要求逐一检查的清单消息线类型wire typessrc/modules/aix/server/dispatch/wiretypes/anthropic.wiretypes.ts约 1318 行——基于zod/v4定义 Anthropic Messages API 请求、响应、内容块、工具定义与流式事件的完整 Schema是整个协议面最直接、最完整的映射。请求装配adapterssrc/modules/aix/server/dispatch/chatGenerate/adapters/anthropic.messageCreate.ts714 行——把 AIX 内部统一的消息格式system message、chat sequence、工具定义与工具策略转换为 Anthropic Messages API 的message create请求负载。响应解析parserssrc/modules/aix/server/dispatch/chatGenerate/parsers/anthropic.parser.ts1208 行——分别提供流式createAnthropicMessageParser与非流式createAnthropicMessageParserNS两个解析器把上游的 SSE 事件或整包 JSON 转译为 AIX 的粒子particle流。支持的 API 范围仅 Messages API这是审计过程中必须始终坚守的一条边界big-AGI 只支持 Anthropic 的 Messages APImessage create不支持更早的 Completions API也不支持其他并列协议。因此上游文档的阅读重点应放在messages端点及其stream模式上如果在新版本中发现其他端点如旧版文本补全出现变更应直接判定为不在本项目支持范围内无需适配。原生能力的承诺缓存、工具与历史状态仓库对 Anthropic 有两个明确的原生能力承诺审计时需重点确认其是否仍然成立原生支持 Anthropic 缓存caching即cache_control断点机制。代码中体现为_CacheControl_schema{ type: ephemeral, ttl?: 5m | 1h }、系统消息与工具块上的cache_control打标以及_capTrailingCacheBreakpoints对最多 4 个断点这一 API 硬限制的处理。工具与状态tools and state包括客户端工具tool_use/tool_result、服务端托管工具server_tool_use及其结果块、历史拼接crafting the history的正确性。代码中体现为_pairInteriorToolUseBlocks对孤儿tool_use的自动配对、aixSpillSystemToUser的系统消息溢出等逻辑。双通道证据链文档核对 线上实测原命令文件把审计的证据来源分成两条通道缺一不可主证据源Primary SourcesMessages API 文档docs.claude.com/en/api/messages——请求/响应字段的权威定义。API 发布说明docs.claude.com/en/release-notes/api——破坏性变更与新能力的首要通告渠道。工具使用Tool use文档docs.claude.com/en/docs/agents-and-tools/tool-use/overview——客户端工具与服务端工具的语义说明。停止原因处理docs.claude.com/en/api/handling-stop-reasons——stop_reason各取值end_turn、max_tokens、stop_sequence、tool_use、pause_turn、refusal、model_context_window_exceeded与stop_details结构。备选证据源Alternative Sources当主文档无法访问时可按以下顺序降级Anthropic TypeScript SDKanthropic-sdk-typescriptsrc/resources/messages/messages.ts与beta/beta.ts。仓库的 wiretypes 头部注释也明确标注了这两个参考位置说明 SDK 类型是 wiretype 定义的重要对齐基准。Anthropic Python SDKanthropic-sdk-python含anthropic_beta_param.py等 beta 参数定义。网络检索搜索anthropic api changelog、new claude api、new claude api pricing等关键词获取最新通告。若所有渠道均不可用则应明确说明尝试过哪些来源并请使用者手动提供文档而不是臆测协议字段。线上端点验证以真实 SSE 为准绳原命令文件给出了一个极具工程价值的ground truth手段若 .env.api-keys或运行环境中存在ANTHROPIC_API_KEY则直接向POST https://api.anthropic.com/v1/messages发送一次真实的流式请求用返回的原始 SSE 数据来核对文档可能滞后或缺失的字段、事件类型、响应形状与错误格式。请求要点请求体携带stream: true请求头必须包含x-api-keyAPI 密钥与anthropic-version版本头绝不允许提交或回显密钥本身。仓库中对应密钥的读取逻辑位于 src/modules/llms/server/anthropic/anthropic.access.ts即access.anthropicKey || env.ANTHROPIC_API_KEY || 审计时可直接复用这一环境变量通道。这类实测的价值在代码注释中有大量印证例如 wiretypes 中标注的launch-verified、probe-verified、empirically verified——许多文档未记载的行为如 Opus 5 对temperature/top_p/top_k的 400 拒绝、Fable/Mythos 5 对强制tool_choice的 400都是靠线上探测确认后才沉淀进代码的。审计检查清单逐个协议面核对1. 协议差异protocol discrepancies对照主文档与 SDK逐一比对请求/响应的顶层字段是否存在增删改。以 wiretypes 的Request_schema为例anthropic.wiretypes.ts当前实现覆盖的请求字段包括字段类型/取值说明max_tokens必填number停止前最大生成 token 数model必填string模型 IDsystemTextBlock[]顶层系统提示Messages API 没有 system rolemessages必填MessageInput[]交替的 user/assistant 轮次首条必须是 usertoolsToolDefinition[]客户端工具 托管工具定义tool_choiceauto/any/tool/none工具选择策略auto/any/tool可带disable_parallel_tool_usestreamboolean是否 SSE 流式默认 falsethinkingadaptive/enabledbudget_tokens/disabled思考模式display支持summarized/omittedoutput_config{ effort?, format? }推理强度low~max与结构化输出json_schemacache_control顶层2026 年 2 月起的自动缓存开关temperature/top_p/top_knumber采样参数stop_sequencesstring[]自定义停止序列metadata.user_idstring透传元数据speedfast快速推理研究预览waitlistinference_geoglobal/us推理地域us为 1.1x 定价containerstring / ContainerParams代码执行容器Skills 复用mcp_serversMCP URL 数组客户端 MCP 服务器service_tierauto/standard_only服务等级审计时要特别关注必填字段如max_tokens、model、messages、流式事件类型以及任何新增的响应形状。2. 消息结构与块类型message structureAnthropicWire_Messages命名空间用 discriminated union 区分了输入块与输出块anthropic.wiretypes.ts输入块InputText、Imagebase64/url/file、Documentbase64 PDF / 纯文本 / content / url / file、SearchResult、Thinking、RedactedThinking、ToolUse、ToolResult、ServerToolUse、各类 ServerToolResult、MCPToolUse/MCPToolResult、ContainerUpload、ToolSearchToolResult。输出块OutputText、Thinking、RedactedThinking、ToolUse、ServerToolUse、各类 ServerToolResult、MCP 相关、ContainerUpload、ToolSearchToolResult。关键工程细节cache_control仅存在于输入侧永远不会出现在响应块中_CommonBlock_schema只被输入侧块继承。同时输出块解析刻意做得前向兼容——ContentBlockOutputResilient_schema用已知类型集合 looseObject 兜底的方式让未来新增的块类型代码注释中列举了fallback、compaction、advisor_tool_result、connector_text等 beta 块不会中断整个流解析器通过isKnownContentBlockOutput()门控是否处理。3. 流式事件协议streaming events解析器文件头部有一段对 Anthropic 流式协议的精炼总结anthropic.parser.ts审计时应逐条对照message_start初始化消息元数据id、model、usage、container初始 content 必须为空content_block_start开启一个内容块text / tool_use / server_tool_use / tool_result 等content_block_delta增量更新当前块已知的 delta 类型包括text_delta、input_json_delta、thinking_delta、signature_delta、citations_deltacontent_block_stop结束当前块message_delta消息级更新stop_reason、stop_sequence、stop_details、container、usagemessage_stop整个消息结束ping保活事件可随时出现解析器直接忽略error流中错误如overloaded_error伴随 200 状态码以 JSON 下发。与块类型一样delta 类型同样做了前向兼容处理_ContentBlockDeltaUnknown_schema让未知 delta如 beta 的compaction_delta被记录后跳过而不是杀死流。这类宽容解析 显式告警的模式aixResilientUnknownValue是仓库应对快速演进协议的核心手法审计新版本时值得沿用。4. 停止原因与结构化拒绝stop reasons refusalsStopReason_schema覆盖end_turn、max_tokens、stop_sequence、tool_use、pause_turn、refusal、model_context_window_exceeded并以.or(z.string())兜底未知值——例如 beta 的compaction不会中断流。stop_details仅在stop_reason refusal时出现携带categorycyber、bio、reasoning_extraction、frontier_llm、military_weapons、explanation与recommended_model。解析器会把拒绝整理成可读文案_formatAnthropicStopError并把recommended_model提示为重试建议。流式模式下message_delta.delta中的stop_details与stop_reason同时到达pause_turn会触发DispatchContinuationSignal让 dispatch 层用累积内容继续重发请求服务端工具场景的续跑机制。5. 请求装配链路中的协议适配adapter 视角请求适配器 anthropic.messageCreate.ts 是审计实现是否跟得上协议时信息密度最高的文件因为它把协议变化翻译成了具体的装配决策值得逐一复核系统消息与缓存断点system消息由 parts 归并而来meta_cache_controlpart 会把cache_control: { type: ephemeral }打到当前消息的最后一个非 thinking 块上随后_capTrailingCacheBreakpoints(..., 4)强制执行最多 4 个断点的 API 硬限制保留尾部的断点删除前缀冗余者。思考thinking参数adaptive4.6 自适应、enabled budget_tokens4.5 及更早、disabled三态由模型参数vndAntThinkingBudget驱动对claude-(fable|mythos|opus)-5系列强制归一到adaptive实测enabled/disabled返回 400并显式设置display: summarized以保留 4.6 时代的展示体验。自适应思考下删除 temperature代码在多处delete payload.temperature与adaptive/enabled 思考与 temperature 互斥的协议约束对应反之thinking: disabled时保留 temperature。强制工具调用的兼容降级claude-(fable|mythos)-5对tool_choice: any | tool返回 400适配器降级为auto并注入一条系统提示You MUST respond by calling...同时把默认 effort 压到low以约束思考开销而 Opus 5 实测放行因此正则刻意排除opus。结构化输出Structured OutputsstrictJsonOutput会递归为每个object节点补additionalProperties: false_strictNormalizeSchema否则 API 400严格模式下的工具定义额外携带strict: true。托管工具装配web_search/web_fetch依据vndAntWebDynamic选择新版本号_20260318vs_20250305/_20250910tool_search_tool_regex/bm25依参数装配code_execution_20260120在代码沙箱、Skills、程序化工具调用PTC场景下被显式加入vndAntWebSearchMaxUses、user_location、citations: { enabled: true }等按需透传。容器连续性container continuity动态 web 工具与代码执行共用一套容器 ID 复用逻辑跨轮次保持同一沙箱文件在搜索轮之间存活但不会在动态 web 轮中自动附加独立code_execution工具避免产生寄生双执行环境。Bedrock 目标差异AixAnthropicTarget anthropic | bedrock。Bedrock 的bedrock-2023-05-31passthrough 会校验 body因此需要按目标剔除 api.anthropic.com 独有字段——例如 4.5 系列模型上删除output_config.effort实测 400、删除speed、删除thinking.block_binding。这是同一协议面、不同端点不同约束的典型审计点。发送前 Schema 校验最终 payload 会经过Request_schema.safeParse预检失败即抛错从源头拦截畸形请求。6. 历史装配的健壮性crafting the history两个值得强调的历史修复逻辑是协议合规审计中容易遗漏、但恰恰是线上稳定性关键的部分孤儿tool_use自动配对_pairInteriorToolUseBlocks若某条 assistant 消息含tool_use而紧随的 user 消息没有对应tool_resultAPI 会整体 400 并毒化整段历史导致后续每一轮都被拒绝。适配器会扫描并合成占位tool_result内容为AIX_MISSING_TOOL_RESULT_TEXT跳过最后一条 assistant 消息——因为尾部tool_use是 agent 循环中的在途调用不应伪造其结果server_tool_use则不受影响托管工具不欠tool_result。连续 thinking 块的隔离hotFixAntSeparateContiguousThinkingBlocks新 thinking 块不能紧跟 thinking/redacted_thinking 块装配时若出现连续思考块会插入\n文本块作为分隔符。7. 保留 thinking 与新响应字段2026-09-01 同步点wiretypes 顶部的更新日志本身就是一份历史审计记录模板最近一次同步2026-09-01引入了两个值得在审计中验证的新面请求侧thinking.block_binding.prefix_mismatch_behaviorerror|drop_blockbeta 头thinking-binding-controls-2026-08-01——当重放的 thinking 块与已变更的历史前缀不匹配时drop_block丢弃它并继续适配器对每个 thinking 请求统一发送drop_block解析器把丢弃事件以input-transform粒子转发给客户端。响应侧input_transformations[{ type: thinking_dropped, path, reason }]流式下出现在message_start——用于告知客户端哪些被重放的 thinking 块被丢弃及原因model_binding_mismatch/prefix_binding_mismatch。流式与非流式双解析器同一协议面、两种装配解析器文件提供两个入口dispatch 层chatGenerate.dispatch.ts根据streaming布尔值选择第 104、158 行createAnthropicMessageParser()流式逐事件处理 SSE依赖message_start→content_block_start/delta/stop→message_delta→message_stop的顺序tool_use的输入以input_json_delta增量累积{}归一为空串PTC 预填对象归一为 JSON 字符串content_block_stop时对server_tool_use重发一次携带完整输入的操作状态。createAnthropicMessageParserNS()非流式直接解析整包Response_schema遍历 content 块tool_use输入是完整的json_object直接交给 transmittercitations 已完整挂载在文本块上无需增量拼接。两个解析器共享一套服务端工具结果处理函数web_search / web_fetch / code_execution / bash / text_editor / tool_search 等以操作状态粒子operation state particles的形式在 UI 上呈现搜索、抓取、执行进度未知的服务端工具如未来的 Skills会退化为通用占位而不是抛错。审计产出差异清单的优先级按原命令文件的约定审计的最终产出是一份完整的差异清单覆盖最终解析与重组到协议变更的所有层面并且优先标注破坏性变更breaking changes与能显著改善用户体验的新能力new capabilities。仓库中的更新日志wiretypes 顶部## Updates块正是这种产出在代码中的落地形态——每条记录都标注了日期、来源GA / beta / launch-verified、影响面请求/响应/流式事件/工具定义以及未采纳NOT adopted的 beta 特性及其原因例如未采纳fallbacks参数server-side-fallback beta、advisor 工具、compaction、缓存诊断、任务预算、对话中系统消息role: systemOpus 4.8 起 GA未采纳beta逐消息 effort、turn 级系统消息等。这种同步即留痕的做法让后续审计者能快速区分有意未适配与漏适配本身也值得作为审计方法的一部分。总结一套可复用的供应商协议同步方法论把以上内容收束为操作流程便是一套可复用于任何 LLM 供应商集成仓库中还有 sync-gemini-api.md、sync-openai-apis.md、sync-openrouter-api.md、sync-xai-api.md 等同类命令的审计方法论锚定代码面定位该供应商的 wiretypes类型 Schema、adapter请求装配与 parser响应解析三个文件明确支持范围与原生能力承诺。双通道取证主通道读官方文档与 SDK 类型备选通道用网络检索最终以真实 API 请求的原始响应尤其流式 SSE作为 ground truth验证文档与 SDK 的滞后与偏差。逐面核对按协议差异、消息结构与块类型、流式事件、停止原因与拒绝、请求装配决策、历史拼接健壮性、新字段新能力七个面逐项比对。宽容解析 显式告警对未知的块类型、delta 类型、事件名与 stop_reason 采用记录并跳过而非杀死流的兜底策略aixResilientUnknownValue保证协议演进期的稳定性。留痕产出将差异清单按破坏性变更 / 新能力 / 未采纳 beta分级写入更新日志标注验证方式与适用范围供后续审计复用。【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 big-AGI 中 Anthropic Messages API 集成的同步审计指南：wiretypes、请求适配器与流式解析器的全链路校验
big-AGI 中 Anthropic Messages API 集成的同步审计指南wiretypes、请求适配器与流式解析器的全链路校验【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI导读本文是一份面向开发者与维护者的技术审计指南讲解如何在 big-AGI 开源仓库中以官方 API 文档与线上真实请求为基准对 AnthropicClaudeMessages API 的集成实现进行系统性同步与校验。文章围绕仓库中三个核心文件展开——消息线类型定义anthropic.wiretypes.ts、请求装配适配器anthropic.messageCreate.ts、以及流式/非流式响应解析器anthropic.parser.ts读完你既能掌握如何审计一份 LLM 供应商集成是否与上游协议一致也能了解 big-AGI 在 Anthropic 协议层沉淀的具体实现细节与工程化手法。审计目标与范围仓库中 Anthropic 集成的三个锚点同步审计的第一步是明确看哪里。仓库中 Anthropic 的实现被刻意拆分为三个职责单一的文件分别对应协议的类型定义—请求构造—响应解析三段链路这也是官方 Claude Code 命令.claude/commands/aix/sync-anthropic-api.md要求逐一检查的清单消息线类型wire typessrc/modules/aix/server/dispatch/wiretypes/anthropic.wiretypes.ts约 1318 行——基于zod/v4定义 Anthropic Messages API 请求、响应、内容块、工具定义与流式事件的完整 Schema是整个协议面最直接、最完整的映射。请求装配adapterssrc/modules/aix/server/dispatch/chatGenerate/adapters/anthropic.messageCreate.ts714 行——把 AIX 内部统一的消息格式system message、chat sequence、工具定义与工具策略转换为 Anthropic Messages API 的message create请求负载。响应解析parserssrc/modules/aix/server/dispatch/chatGenerate/parsers/anthropic.parser.ts1208 行——分别提供流式createAnthropicMessageParser与非流式createAnthropicMessageParserNS两个解析器把上游的 SSE 事件或整包 JSON 转译为 AIX 的粒子particle流。支持的 API 范围仅 Messages API这是审计过程中必须始终坚守的一条边界big-AGI 只支持 Anthropic 的 Messages APImessage create不支持更早的 Completions API也不支持其他并列协议。因此上游文档的阅读重点应放在messages端点及其stream模式上如果在新版本中发现其他端点如旧版文本补全出现变更应直接判定为不在本项目支持范围内无需适配。原生能力的承诺缓存、工具与历史状态仓库对 Anthropic 有两个明确的原生能力承诺审计时需重点确认其是否仍然成立原生支持 Anthropic 缓存caching即cache_control断点机制。代码中体现为_CacheControl_schema{ type: ephemeral, ttl?: 5m | 1h }、系统消息与工具块上的cache_control打标以及_capTrailingCacheBreakpoints对最多 4 个断点这一 API 硬限制的处理。工具与状态tools and state包括客户端工具tool_use/tool_result、服务端托管工具server_tool_use及其结果块、历史拼接crafting the history的正确性。代码中体现为_pairInteriorToolUseBlocks对孤儿tool_use的自动配对、aixSpillSystemToUser的系统消息溢出等逻辑。双通道证据链文档核对 线上实测原命令文件把审计的证据来源分成两条通道缺一不可主证据源Primary SourcesMessages API 文档docs.claude.com/en/api/messages——请求/响应字段的权威定义。API 发布说明docs.claude.com/en/release-notes/api——破坏性变更与新能力的首要通告渠道。工具使用Tool use文档docs.claude.com/en/docs/agents-and-tools/tool-use/overview——客户端工具与服务端工具的语义说明。停止原因处理docs.claude.com/en/api/handling-stop-reasons——stop_reason各取值end_turn、max_tokens、stop_sequence、tool_use、pause_turn、refusal、model_context_window_exceeded与stop_details结构。备选证据源Alternative Sources当主文档无法访问时可按以下顺序降级Anthropic TypeScript SDKanthropic-sdk-typescriptsrc/resources/messages/messages.ts与beta/beta.ts。仓库的 wiretypes 头部注释也明确标注了这两个参考位置说明 SDK 类型是 wiretype 定义的重要对齐基准。Anthropic Python SDKanthropic-sdk-python含anthropic_beta_param.py等 beta 参数定义。网络检索搜索anthropic api changelog、new claude api、new claude api pricing等关键词获取最新通告。若所有渠道均不可用则应明确说明尝试过哪些来源并请使用者手动提供文档而不是臆测协议字段。线上端点验证以真实 SSE 为准绳原命令文件给出了一个极具工程价值的ground truth手段若 .env.api-keys或运行环境中存在ANTHROPIC_API_KEY则直接向POST https://api.anthropic.com/v1/messages发送一次真实的流式请求用返回的原始 SSE 数据来核对文档可能滞后或缺失的字段、事件类型、响应形状与错误格式。请求要点请求体携带stream: true请求头必须包含x-api-keyAPI 密钥与anthropic-version版本头绝不允许提交或回显密钥本身。仓库中对应密钥的读取逻辑位于 src/modules/llms/server/anthropic/anthropic.access.ts即access.anthropicKey || env.ANTHROPIC_API_KEY || 审计时可直接复用这一环境变量通道。这类实测的价值在代码注释中有大量印证例如 wiretypes 中标注的launch-verified、probe-verified、empirically verified——许多文档未记载的行为如 Opus 5 对temperature/top_p/top_k的 400 拒绝、Fable/Mythos 5 对强制tool_choice的 400都是靠线上探测确认后才沉淀进代码的。审计检查清单逐个协议面核对1. 协议差异protocol discrepancies对照主文档与 SDK逐一比对请求/响应的顶层字段是否存在增删改。以 wiretypes 的Request_schema为例anthropic.wiretypes.ts当前实现覆盖的请求字段包括字段类型/取值说明max_tokens必填number停止前最大生成 token 数model必填string模型 IDsystemTextBlock[]顶层系统提示Messages API 没有 system rolemessages必填MessageInput[]交替的 user/assistant 轮次首条必须是 usertoolsToolDefinition[]客户端工具 托管工具定义tool_choiceauto/any/tool/none工具选择策略auto/any/tool可带disable_parallel_tool_usestreamboolean是否 SSE 流式默认 falsethinkingadaptive/enabledbudget_tokens/disabled思考模式display支持summarized/omittedoutput_config{ effort?, format? }推理强度low~max与结构化输出json_schemacache_control顶层2026 年 2 月起的自动缓存开关temperature/top_p/top_knumber采样参数stop_sequencesstring[]自定义停止序列metadata.user_idstring透传元数据speedfast快速推理研究预览waitlistinference_geoglobal/us推理地域us为 1.1x 定价containerstring / ContainerParams代码执行容器Skills 复用mcp_serversMCP URL 数组客户端 MCP 服务器service_tierauto/standard_only服务等级审计时要特别关注必填字段如max_tokens、model、messages、流式事件类型以及任何新增的响应形状。2. 消息结构与块类型message structureAnthropicWire_Messages命名空间用 discriminated union 区分了输入块与输出块anthropic.wiretypes.ts输入块InputText、Imagebase64/url/file、Documentbase64 PDF / 纯文本 / content / url / file、SearchResult、Thinking、RedactedThinking、ToolUse、ToolResult、ServerToolUse、各类 ServerToolResult、MCPToolUse/MCPToolResult、ContainerUpload、ToolSearchToolResult。输出块OutputText、Thinking、RedactedThinking、ToolUse、ServerToolUse、各类 ServerToolResult、MCP 相关、ContainerUpload、ToolSearchToolResult。关键工程细节cache_control仅存在于输入侧永远不会出现在响应块中_CommonBlock_schema只被输入侧块继承。同时输出块解析刻意做得前向兼容——ContentBlockOutputResilient_schema用已知类型集合 looseObject 兜底的方式让未来新增的块类型代码注释中列举了fallback、compaction、advisor_tool_result、connector_text等 beta 块不会中断整个流解析器通过isKnownContentBlockOutput()门控是否处理。3. 流式事件协议streaming events解析器文件头部有一段对 Anthropic 流式协议的精炼总结anthropic.parser.ts审计时应逐条对照message_start初始化消息元数据id、model、usage、container初始 content 必须为空content_block_start开启一个内容块text / tool_use / server_tool_use / tool_result 等content_block_delta增量更新当前块已知的 delta 类型包括text_delta、input_json_delta、thinking_delta、signature_delta、citations_deltacontent_block_stop结束当前块message_delta消息级更新stop_reason、stop_sequence、stop_details、container、usagemessage_stop整个消息结束ping保活事件可随时出现解析器直接忽略error流中错误如overloaded_error伴随 200 状态码以 JSON 下发。与块类型一样delta 类型同样做了前向兼容处理_ContentBlockDeltaUnknown_schema让未知 delta如 beta 的compaction_delta被记录后跳过而不是杀死流。这类宽容解析 显式告警的模式aixResilientUnknownValue是仓库应对快速演进协议的核心手法审计新版本时值得沿用。4. 停止原因与结构化拒绝stop reasons refusalsStopReason_schema覆盖end_turn、max_tokens、stop_sequence、tool_use、pause_turn、refusal、model_context_window_exceeded并以.or(z.string())兜底未知值——例如 beta 的compaction不会中断流。stop_details仅在stop_reason refusal时出现携带categorycyber、bio、reasoning_extraction、frontier_llm、military_weapons、explanation与recommended_model。解析器会把拒绝整理成可读文案_formatAnthropicStopError并把recommended_model提示为重试建议。流式模式下message_delta.delta中的stop_details与stop_reason同时到达pause_turn会触发DispatchContinuationSignal让 dispatch 层用累积内容继续重发请求服务端工具场景的续跑机制。5. 请求装配链路中的协议适配adapter 视角请求适配器 anthropic.messageCreate.ts 是审计实现是否跟得上协议时信息密度最高的文件因为它把协议变化翻译成了具体的装配决策值得逐一复核系统消息与缓存断点system消息由 parts 归并而来meta_cache_controlpart 会把cache_control: { type: ephemeral }打到当前消息的最后一个非 thinking 块上随后_capTrailingCacheBreakpoints(..., 4)强制执行最多 4 个断点的 API 硬限制保留尾部的断点删除前缀冗余者。思考thinking参数adaptive4.6 自适应、enabled budget_tokens4.5 及更早、disabled三态由模型参数vndAntThinkingBudget驱动对claude-(fable|mythos|opus)-5系列强制归一到adaptive实测enabled/disabled返回 400并显式设置display: summarized以保留 4.6 时代的展示体验。自适应思考下删除 temperature代码在多处delete payload.temperature与adaptive/enabled 思考与 temperature 互斥的协议约束对应反之thinking: disabled时保留 temperature。强制工具调用的兼容降级claude-(fable|mythos)-5对tool_choice: any | tool返回 400适配器降级为auto并注入一条系统提示You MUST respond by calling...同时把默认 effort 压到low以约束思考开销而 Opus 5 实测放行因此正则刻意排除opus。结构化输出Structured OutputsstrictJsonOutput会递归为每个object节点补additionalProperties: false_strictNormalizeSchema否则 API 400严格模式下的工具定义额外携带strict: true。托管工具装配web_search/web_fetch依据vndAntWebDynamic选择新版本号_20260318vs_20250305/_20250910tool_search_tool_regex/bm25依参数装配code_execution_20260120在代码沙箱、Skills、程序化工具调用PTC场景下被显式加入vndAntWebSearchMaxUses、user_location、citations: { enabled: true }等按需透传。容器连续性container continuity动态 web 工具与代码执行共用一套容器 ID 复用逻辑跨轮次保持同一沙箱文件在搜索轮之间存活但不会在动态 web 轮中自动附加独立code_execution工具避免产生寄生双执行环境。Bedrock 目标差异AixAnthropicTarget anthropic | bedrock。Bedrock 的bedrock-2023-05-31passthrough 会校验 body因此需要按目标剔除 api.anthropic.com 独有字段——例如 4.5 系列模型上删除output_config.effort实测 400、删除speed、删除thinking.block_binding。这是同一协议面、不同端点不同约束的典型审计点。发送前 Schema 校验最终 payload 会经过Request_schema.safeParse预检失败即抛错从源头拦截畸形请求。6. 历史装配的健壮性crafting the history两个值得强调的历史修复逻辑是协议合规审计中容易遗漏、但恰恰是线上稳定性关键的部分孤儿tool_use自动配对_pairInteriorToolUseBlocks若某条 assistant 消息含tool_use而紧随的 user 消息没有对应tool_resultAPI 会整体 400 并毒化整段历史导致后续每一轮都被拒绝。适配器会扫描并合成占位tool_result内容为AIX_MISSING_TOOL_RESULT_TEXT跳过最后一条 assistant 消息——因为尾部tool_use是 agent 循环中的在途调用不应伪造其结果server_tool_use则不受影响托管工具不欠tool_result。连续 thinking 块的隔离hotFixAntSeparateContiguousThinkingBlocks新 thinking 块不能紧跟 thinking/redacted_thinking 块装配时若出现连续思考块会插入\n文本块作为分隔符。7. 保留 thinking 与新响应字段2026-09-01 同步点wiretypes 顶部的更新日志本身就是一份历史审计记录模板最近一次同步2026-09-01引入了两个值得在审计中验证的新面请求侧thinking.block_binding.prefix_mismatch_behaviorerror|drop_blockbeta 头thinking-binding-controls-2026-08-01——当重放的 thinking 块与已变更的历史前缀不匹配时drop_block丢弃它并继续适配器对每个 thinking 请求统一发送drop_block解析器把丢弃事件以input-transform粒子转发给客户端。响应侧input_transformations[{ type: thinking_dropped, path, reason }]流式下出现在message_start——用于告知客户端哪些被重放的 thinking 块被丢弃及原因model_binding_mismatch/prefix_binding_mismatch。流式与非流式双解析器同一协议面、两种装配解析器文件提供两个入口dispatch 层chatGenerate.dispatch.ts根据streaming布尔值选择第 104、158 行createAnthropicMessageParser()流式逐事件处理 SSE依赖message_start→content_block_start/delta/stop→message_delta→message_stop的顺序tool_use的输入以input_json_delta增量累积{}归一为空串PTC 预填对象归一为 JSON 字符串content_block_stop时对server_tool_use重发一次携带完整输入的操作状态。createAnthropicMessageParserNS()非流式直接解析整包Response_schema遍历 content 块tool_use输入是完整的json_object直接交给 transmittercitations 已完整挂载在文本块上无需增量拼接。两个解析器共享一套服务端工具结果处理函数web_search / web_fetch / code_execution / bash / text_editor / tool_search 等以操作状态粒子operation state particles的形式在 UI 上呈现搜索、抓取、执行进度未知的服务端工具如未来的 Skills会退化为通用占位而不是抛错。审计产出差异清单的优先级按原命令文件的约定审计的最终产出是一份完整的差异清单覆盖最终解析与重组到协议变更的所有层面并且优先标注破坏性变更breaking changes与能显著改善用户体验的新能力new capabilities。仓库中的更新日志wiretypes 顶部## Updates块正是这种产出在代码中的落地形态——每条记录都标注了日期、来源GA / beta / launch-verified、影响面请求/响应/流式事件/工具定义以及未采纳NOT adopted的 beta 特性及其原因例如未采纳fallbacks参数server-side-fallback beta、advisor 工具、compaction、缓存诊断、任务预算、对话中系统消息role: systemOpus 4.8 起 GA未采纳beta逐消息 effort、turn 级系统消息等。这种同步即留痕的做法让后续审计者能快速区分有意未适配与漏适配本身也值得作为审计方法的一部分。总结一套可复用的供应商协议同步方法论把以上内容收束为操作流程便是一套可复用于任何 LLM 供应商集成仓库中还有 sync-gemini-api.md、sync-openai-apis.md、sync-openrouter-api.md、sync-xai-api.md 等同类命令的审计方法论锚定代码面定位该供应商的 wiretypes类型 Schema、adapter请求装配与 parser响应解析三个文件明确支持范围与原生能力承诺。双通道取证主通道读官方文档与 SDK 类型备选通道用网络检索最终以真实 API 请求的原始响应尤其流式 SSE作为 ground truth验证文档与 SDK 的滞后与偏差。逐面核对按协议差异、消息结构与块类型、流式事件、停止原因与拒绝、请求装配决策、历史拼接健壮性、新字段新能力七个面逐项比对。宽容解析 显式告警对未知的块类型、delta 类型、事件名与 stop_reason 采用记录并跳过而非杀死流的兜底策略aixResilientUnknownValue保证协议演进期的稳定性。留痕产出将差异清单按破坏性变更 / 新能力 / 未采纳 beta分级写入更新日志标注验证方式与适用范围供后续审计复用。【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考