coding-proxy 0.3.1a10__tar.gz → 0.4.1a1__tar.gz

{coding_proxy-0.3.1a10 → coding_proxy-0.4.1a1}/.gitignore

@@ -23,5 +23,8 @@ config.yaml
 .claude/.prompts.md
 .python-version
 
+# Playwright MCP
+.playwright-mcp/
+
 # Log files (dual-write logging)
 coding-proxy.log*

{coding_proxy-0.3.1a10 → coding_proxy-0.4.1a1}/CHANGELOG.md

@@ -4,16 +4,27 @@
 
 ## [Unreleased]
 
-- fix(vendor-channels): 为所有 targeting zhipu 的转换通道（zhipu→zhipu、copilot→zhipu、anthropic→zhipu）新增 `tool_result.id` 字段注入，修复 zhipu GLM-5 后端错误访问 `.id` 属性（`'ClaudeContentBlockToolResult' object has no attribute 'id'`）导致的 500 错误，使 zhipu 可完全承接含 tool_result 的会话；
-- fix(vendor-channels): 新增 zhipu 同 vendor 自清理通道，修复 GLM-5 自循环 400 + tool_results 偶发降级；
-- fix(vendor-channels): 修复 `_rewrite_srvtoolu_ids` 块顺序敏感性导致 inline tool_result 漏改名，进而 enforce 阶段 dict key 与 tool_use_ids 错位、anthropic 报 `tool_use ids without tool_result blocks immediately after` 的 cascade failover 问题（改为两遍扫描：先收集 id_map，再统一改写所有 tool_result.tool_use_id 引用）；
-- fix(vendor-channels): `enforce_anthropic_tool_pairing` 增加全局 sanity check pass，主循环边角错位让 dangling tool_use 漏过校验时兜底合成 is_error 占位并打 `pairing_sanity_repaired` 标签，避免 anthropic 二次报错；
+## [v0.4.0](https://github.com/ThreeFish-AI/coding-proxy/releases/tag/v0.4.0) — 2026-05-01
 
-### Bug Fixes
+> [!IMPORTANT]
+>
+> **🚀 Session 级专属路由策略！**
+>
+> 给每个 Session 指定专属的 vendor，动态调节不同 vendors 间的 LLM 流量。
+
+![session](assets/session-v0.4.0.png)
+
+### ✨ 核心亮点
+
+- feat(session-policy): 新增 Session 级专属路由策略 (#219)
+- feat(dashboard): 新增会话活动面板 (#222)
+
+### 🔧 更多特性
 
-- fix(vendor-channels): 新增 `anthropic → zhipu` 跨供应商转换通道，修复 Anthropic beta 功能（web search, computer use）产生的 `server_tool_use` 块导致 zhipu 400 错误的问题；
-- fix(error-classifier): 增强语义拒绝检测，识别 zhipu 等供应商返回的中文错误消息（如「API 调用参数有误」code=1210），确保正确触发故障转移；
-- fix(vendor-channels): `_remove_vendor_blocks` 增加空内容占位保护，防止内容块全部剥离后消息结构不合法。
+- refactor(logging): 移除已被 ModelCall 汇总行覆盖的冗余 DEBUG 日志 (#203)
+- style(dashboard): 加宽图表 tooltip 令模型名称与用量值单行显示 (#211)
+- fix(usage-parser): 补充 OpenAI/Gemini SSE 流式分支的 model_served 提取 (#214)
+- fix(usage-parser): 兼容 SSE chunk 中 usage 字段为 null 的极端格式 (#212)
 
 ## [v0.3.0](https://github.com/ThreeFish-AI/coding-proxy/releases/tag/v0.3.0) — 2026-04-20
 

{coding_proxy-0.3.1a10 → coding_proxy-0.4.1a1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: coding-proxy
-Version: 0.3.1a10
+Version: 0.4.1a1
 Summary: A High-Availability, Transparent, and Smart Multi-Vendor Proxy for Claude Code. Support Claude Plans, GitHub Copilot, Google Antigravity, ZAI/GLM, MiniMax, Qwen, Xiaomi, Kimi, Doubao...
 Project-URL: Source Code, https://github.com/ThreeFish-AI/coding-proxy
 Project-URL: User Guide, https://github.com/ThreeFish-AI/coding-proxy/blob/master/docs/user-guide.md
@@ -57,7 +57,7 @@ When you're deeply immersed in your coding "zone" with **Claude Code** (or any A
 ## 🌟 Core Features
 
 <div align="center">
-    <img src="assets/dashboard-v0.2.4.png">
+    <img src="assets/dashboard-v0.4.0.png">
 </div>
 
 - **⛓️ N-tier Chained Failover**: Autonomous descending sequence, supporting Claude's official plans, as well as Coding Plans from GitHub Copilot, Google Antigravity, Z AI, MiniMax, Alibaba Qwen, Xiaomi, Kimi, Doubao, etc.

{coding_proxy-0.3.1a10 → coding_proxy-0.4.1a1}/README.md

@@ -30,7 +30,7 @@ When you're deeply immersed in your coding "zone" with **Claude Code** (or any A
 ## 🌟 Core Features
 
 <div align="center">
-    <img src="assets/dashboard-v0.2.4.png">
+    <img src="assets/dashboard-v0.4.0.png">
 </div>
 
 - **⛓️ N-tier Chained Failover**: Autonomous descending sequence, supporting Claude's official plans, as well as Coding Plans from GitHub Copilot, Google Antigravity, Z AI, MiniMax, Alibaba Qwen, Xiaomi, Kimi, Doubao, etc.

coding_proxy-0.4.1a1/docs/issue.md

@@ -0,0 +1,134 @@
+# Issue 处理档案
+
+> 维护已处理过的 Issue 摘要（问题描述、表因根因、处理方式、后续防范、同类问题影响与处理注意事项），便于同类问题的跨上下文处理。识别相同 Issue 时应在原条目追加复盘，避免同 Issue 多处维护。
+
+---
+
+## streaming usage parse failed: 'NoneType' object has no attribute 'get'
+
+**问题描述**
+
+OpenAI 兼容 SSE 流式响应过程中，单次请求日志反复刷出数十条 WARNING：
+
+```
+WARNING streaming usage parse failed: 'NoneType' object has no attribute 'get'
+```
+
+警告本身被上层 `try/except` 吞掉不影响主链路，但日志噪声严重，且每帧都丢失了 usage 累加。
+
+**表因**
+
+`StreamingUsageAccumulator.feed` 调用 `parse_usage_from_chunk` 解析 SSE chunk 时抛出 `AttributeError`。
+
+**根因**
+
+`src/coding/proxy/routing/usage_parser.py::parse_usage_from_chunk` 中 Anthropic message_start 与 Anthropic message_delta / OpenAI 两条分支都使用了脆弱的判空模式：
+
+```python
+if "usage" in data:        # 仅判断 key 存在
+    u = data["usage"]      # 但值可能是 null
+    u.get("output_tokens", 0)  # AttributeError
+```
+
+部分上游（含某些 OpenAI 兼容供应商）在中间 chunk 显式发送 `"usage": null` 占位帧，`in` 检查通过但取出的是 `None`。
+
+**处理方式**
+
+将两处 guard 统一改为 `u = container.get("usage"); if isinstance(u, dict):`，既排除缺省也排除 null，并顺手移除内部冗余的 `if isinstance(u, dict):` 包装层（已被外层 guard 覆盖）。同时新增三个回归用例覆盖 `data.usage = null` / `message.usage = null` / null 帧后跟有效帧三种场景。
+
+**后续防范**
+
+- 解析外部 SSE / JSON 结构时, 不要单独使用 `if key in data` 作为安全 guard, 应统一采用 `value = data.get(key); if isinstance(value, dict):` 的双重保护, 同时排除缺省与显式 null。
+- 对 try/except 包裹的 WARNING 路径要保持警觉: 异常被吞不代表无害，重复刷屏的同类警告往往暗示防御性 guard 过窄，需要回溯至根因修复，而非依赖 except 兜底。
+
+**同类问题影响与处理注意事项**
+
+- 本仓库内 `parse_usage_from_chunk` 的 Gemini `usageMetadata` 分支 (line ~219) 已经使用 `isinstance(um, dict)` 防御, 不受影响, 可作为参考实现。
+- 检查其他解析器 (如 routing / vendor adapter 层) 是否还有 `if "key" in data: v = data["key"]; v.get(...)` 这种模式, 必要时同步加固。
+
+---
+
+## anthropic 400: `tool_use` ids were found without `tool_result` blocks immediately after
+
+**问题描述**
+
+zhipu → anthropic 通道流式请求偶发 400, 错误形如:
+
+```
+WARNING anthropic stream error: status=400 body=...
+  messages.3: `tool_use` ids were found without `tool_result` blocks immediately after: toolu_normalized_2.
+INFO  Failover: anthropic → zhipu (reason: HTTP 400)
+INFO  Tier zhipu stream succeeded (took over from failed tier: anthropic)
+```
+
+同一请求伴随 `Applied transition channel zhipu → anthropic: rewritten_N_srvtoolu_ids, misplaced_tool_result_relocated, stripped_M_thinking_blocks` 的 adaptations 但**没有 `orphaned_tool_use_repaired`**, 即转换层主观上认为已配对、但 Anthropic 仍判定结构不合规。Failover 至 zhipu 后请求成功, 证明上游消息体本身没有损坏, 问题出在 zhipu→anthropic 通道转换过程引入了不一致。
+
+**表因**
+
+`src/coding/proxy/convert/vendor_channels.py::_rewrite_srvtoolu_ids` 在单遍循环中同时承担 Case A (assistant 端 `server_tool_use` → `tool_use` 与 `srvtoolu_*` ID 重写) 与 Case B (任意位置 `tool_result.tool_use_id` 同步重写)。Case B 依赖 `id_map` 已被 Case A 填入。
+
+**根因**
+
+Zhipu GLM-5 流式响应偶发将 inline `tool_result` 块输出在**对应的 `server_tool_use` 块之前** (同 assistant content 内乱序), 或将 `tool_result` 放在更早的 user 消息中而对应 `tool_use` 在更晚的 assistant 消息。两种乱序下, 单遍扫描遍历到 `tool_result` 时 `id_map` 还是空 → `tool_result.tool_use_id` 不被改写, 停留在 `srvtoolu_X`; 随后 Case A 把对应 `tool_use.id` 改写为 `toolu_normalized_N`。
+
+后续 `enforce_anthropic_tool_pairing` Step A 提取这条 misplaced tool_result 时使用**旧 ID** 作为 `extracted_tool_results` 字典 key, Step F 用新 ID 去查 → 不命中 → 走 `existing_result_ids` 分支, 因为相邻 user 的 tool_result 已经被改写到新 ID, 该 uid 命中 `existing_result_ids` 被 continue 跳过, 于是 enforce 错误地认为完成配对、不产生 `orphaned_tool_use_repaired` 标签, 而被默默丢弃的 misplaced tool_result 本应填补到的 user 槽位实际上**仍然缺位**。最终 body 中某条 assistant 的 tool_use 在下一条 user 中找不到对应 tool_result → Anthropic 400。
+
+**处理方式**
+
+1. `_rewrite_srvtoolu_ids` 改为**两遍扫描**: Pass 1 仅遍历 assistant 消息收集 `id_map` (按 assistant 出现顺序分配, 保持序号兼容性); Pass 2 全量遍历改写任意 `tool_result.tool_use_id`。以"先建表、后改写"的次序消除时序耦合。
+2. 在 `enforce_anthropic_tool_pairing` 主循环末尾追加独立 helper `_enforce_pairing_sanity_pass`, 仅做检测+合成 `is_error=True` 占位 (不剥离、不重定位), 命中追加 `pairing_sanity_repaired` adaptation 并打 WARNING (含 message index 与 uid)。这层作为纵深防御, 在主循环未来重构时仍能稳定守住 Anthropic 配对约束。
+3. 新增回归测试覆盖三类场景: 同 assistant content 内乱序、跨消息边界 tool_result 早于 tool_use、端到端复现日志故障形态。新增 `TestEnforcePairingSanityPass` 独立测试套件确保兜底分支具备正向回归保护。
+
+**后续防范**
+
+- 任何在多 content block 之间存在**前向引用** (后出现的块定义的标识符被前面的块引用) 的就地改写逻辑, 都必须采用两遍扫描或全局表先建后用, 不可依赖遍历位置上 "上一次循环已经写入" 的隐含次序。
+- 纵深防御层 (sanity helper) 必须**独立可单测**, 而不是把 sanity 内嵌在主路径内部 — 否则主路径的快速通道会让 sanity 分支永远走不到正向测试, 缺乏回归保护。
+- adaptations 标签 (`pairing_sanity_repaired`) 与主循环标签 (`orphaned_tool_use_repaired`) 分离, 便于运维聚合时按层归因。
+
+**同类问题影响与处理注意事项**
+
+- 历史教训: commit `9061cd0` 曾经实现"两遍扫描 + sanity helper"修复了正是这类问题, 但 commit `2bac9a7` revert 至 v0.3.0 时**连带回滚**了它 — revert 的真实目标是去除 `f497077` / `fdd4a92` / `43488a1` 引入的"zhipu 自清理通道"和"tool_result.id 注入"副作用, 两遍扫描属无辜方。**后续若再次需要 revert `vendor_channels.py`**, 必须先 `grep _enforce_pairing_sanity_pass` 与 `Pass 1` / `Pass 2` 注释, 确认这两段是核心修复而非可以一起回滚的实验性代码。
+- 类似 "vendor 私有 ID 跨消息体改写" 场景 (如 doubao、minimax 未来若引入类似机制), 实现时同样应当遵循"先全局收集 id_map、后统一改写"的两阶段模式。
+- 单元测试覆盖"块顺序敏感"类 bug 时, 建议在用例命名中显式标注顺序条件 (如 `test_two_pass_handles_inline_tool_result_before_server_tool_use`), 让未来 reviewer 一眼看出测试的边界价值。
+
+---
+
+## count_tokens 路由 `AttributeError: 'ZhipuVendor' object has no attribute 'name'`
+
+**问题描述**
+
+后台日志反复出现 `POST /v1/messages/count_tokens?beta=true 500 Internal Server Error`，并伴随：
+
+```
+File ".../coding/proxy/server/routes.py", line 153, in count_tokens
+    channel_fn = get_transition_channel(source, target_vendor.name)
+AttributeError: 'ZhipuVendor' object has no attribute 'name'
+```
+
+同一时间窗口内大量请求 200 OK、少量请求 500，呈"间歇性"故障特征。
+
+**表因**
+
+`src/coding/proxy/server/routes.py` 的 `count_tokens` 在 153 / 160 两处访问 `target_vendor.name`，触发 `AttributeError` 被 ASGI 中间件捕获返回 500。
+
+**根因**
+
+`BaseVendor` 仅暴露**抽象方法** `get_name() -> str`（`src/coding/proxy/vendors/base.py:75-77`），所有派生类（`AnthropicVendor`、`ZhipuVendor`、`CopilotVendor`、`MinimaxVendor`、`DoubaoVendor`、`KimiVendor` 等）均通过 `_vendor_name` 类属性配合 `get_name()` 返回名称 —— **并无 `name` 实例属性**。该错误访问在 lint/类型检查阶段无告警（因 `BaseVendor` 未在类型系统中约束 `name` 字段），仅在运行时触发。
+
+间歇性原因：第 152 行 `if source:` 是守卫；`source` 由 `infer_source_vendor_from_body(body)`（`src/coding/proxy/convert/vendor_channels.py:357-394`）从请求体启发式推断，仅当出现 zhipu 私有产物（`srvtoolu_*` 形式的 `tool_use.id` 或 `server_tool_use` / `server_tool_use_delta` 类型 content block）时返回 `"zhipu"`，否则 `None`。纯净的首轮 count_tokens 请求 `source is None` 自然绕过 153 行，因此 200/500 共存。
+
+**处理方式**
+
+1. `routes.py:153,160` 将 `target_vendor.name` 改为 `target_vendor.get_name()`，并将结果提取到局部变量 `target_name` 复用，避免重复方法调用与日志/调用点不一致风险。
+2. `tests/test_app_routes.py` 新增 `test_count_tokens_triggers_zhipu_to_target_channel`：通过注入 `server_tool_use` + `srvtoolu_*` 让 `infer_source_vendor_from_body` 返回 `"zhipu"`，断言返回 200 且 debug 日志含 `"count_tokens channel zhipu → anthropic"`，证明通道被实际触发。此前 6 个 count_tokens 测试的请求体都是纯净的、未触达该分支，是 bug 长期漏过的根因。
+
+**后续防范**
+
+- 跨模块引用 Vendor 实例字段时，**统一通过 `BaseVendor` 暴露的方法**（`get_name()`、`map_model()` 等），避免直接访问派生类未定义的"假属性"。
+- 长期演进可考虑在 `BaseVendor` 增加 `@property name` 指向 `get_name()`，将契约前移到类型系统由 mypy / pyright 拦截 —— 该重构属"演进式设计"范畴，不在本次最小干预范围内。
+- 测试覆盖原则：路由层涉及"内容感知"分支（如 `infer_source_vendor_from_body`）时，至少补一个让分支命中的最小用例，避免守卫掩盖代码缺陷。
+
+**同类问题影响与处理注意事项**
+
+- 已 `grep -rn "vendor\.name\b" src/` 全仓扫描，确认 `target_vendor.name | vendor.name` 误用仅 routes.py 的这两处，已随本次修复一并消除。`/v1/messages` 主链路在 executor 中调用 `tier.name`（`Tier` 对象的合法 dataclass 属性），与 vendor 实例 `name` 无关，不受影响。
+- 若未来新增 Vendor 子类，仍只需实现 `get_name()` 抽象方法；外部调用方应遵循同一契约，本档案的修复模式可作为参考。

{coding_proxy-0.3.1a10 → coding_proxy-0.4.1a1}/docs/zh-CN/README.md

@@ -30,7 +30,7 @@
 ## 🌟 核心特性 (Core Features)
 
 <div align="center">
-    <img src="../../assets/dashboard-v0.2.4.png">
+    <img src="../../assets/dashboard-v0.4.0.png">
 </div>
 
 - **⛓️ N-tier 链式故障转移 (Failover)**：自主降序序列，支持 Claude 官方 Plans，以及 GitHub Copilot、Google Antigravity、智谱、MiniMax、阿里千问、小米、Kimi、豆包等的 Coding Plan。

{coding_proxy-0.3.1a10 → coding_proxy-0.4.1a1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "coding-proxy"
-version = "0.3.1a10"
+version = "0.4.1a1"
 description = "A High-Availability, Transparent, and Smart Multi-Vendor Proxy for Claude Code. Support Claude Plans, GitHub Copilot, Google Antigravity, ZAI/GLM, MiniMax, Qwen, Xiaomi, Kimi, Doubao..."
 readme = "README.md"
 requires-python = ">=3.12"
@@ -84,7 +84,10 @@ docstring-code-format = true
 [tool.pytest.ini_options]
 asyncio_mode = "auto"
 testpaths = ["tests"]
-addopts = "-v --tb=short"
+addopts = "-v --tb=short -m 'not e2e'"
+markers = [
+    "e2e: marks tests as end-to-end (deselect with '-m \"not e2e\"')",
+]
 filterwarnings = [
     "ignore::DeprecationWarning",
 ]

{coding_proxy-0.3.1a10 → coding_proxy-0.4.1a1}/src/coding/proxy/convert/vendor_channels.py

@@ -219,9 +219,114 @@ def enforce_anthropic_tool_pairing(
             ", ".join(synthesized_ids),
         )
 
+    # 纵深防御: sanity 兜底，捕获主循环未覆盖的边角配对漏洞
+    adaptations.extend(_enforce_pairing_sanity_pass(messages_list))
+
     return adaptations
 
 
+def _enforce_pairing_sanity_pass(
+    messages_list: list[dict[str, Any]],
+) -> list[str]:
+    """``enforce_anthropic_tool_pairing`` 主循环之后的纯检测兜底 helper.
+
+    职责正交于主循环（不剥离 tool_result、不插入新 user 消息），仅做两件事:
+
+    1. 遍历每个 ``role == "assistant"`` 且包含 ``tool_use`` 块的消息，
+       检查 ``messages[i+1]`` 是否为 ``user`` 且包含所有 ``tool_use.id`` 对应
+       ``tool_result.tool_use_id``。
+    2. 缺失项在该 user 消息末尾追加 ``is_error=True`` 占位块；如果 next 消息根本
+       不是 user（主循环未触达此分支的退化场景），同样不做插入，仅记录 WARNING
+       供运维定位 —— 该路径正常情况下永不命中（主循环已保证 next user 存在）。
+
+    本 helper 单独抽出的目的有两个:
+
+    - 直接构造"绕过主循环"的输入做单元测试，确保 sanity 分支具备**正向回归保护**
+      （历史教训: ``9061cd0`` 引入两遍扫描+sanity 后被 ``2bac9a7`` 连带回滚，
+      重要原因之一是缺乏对兜底路径的独立单测）。
+    - 在主循环 A-F 步骤未来重构时，sanity 仍能稳定守住 Anthropic 配对约束。
+
+    Args:
+        messages_list: 消息列表（就地修改）。
+
+    Returns:
+        新增的 adaptation 标签列表（命中则为 ``["pairing_sanity_repaired"]``，否则空列表）。
+    """
+    repaired: list[tuple[int, str]] = []
+
+    for i, msg in enumerate(messages_list):
+        if not isinstance(msg, dict) or msg.get("role") != "assistant":
+            continue
+        content = msg.get("content")
+        if not isinstance(content, list):
+            continue
+        tool_use_ids = [
+            b["id"]
+            for b in content
+            if isinstance(b, dict) and b.get("type") == "tool_use" and b.get("id")
+        ]
+        if not tool_use_ids:
+            continue
+
+        next_idx = i + 1
+        if (
+            next_idx >= len(messages_list)
+            or not isinstance(messages_list[next_idx], dict)
+            or messages_list[next_idx].get("role") != "user"
+        ):
+            # 主循环正常情况下已保证 next 为 user；此处仅日志告警，不做隐式插入
+            # 以避免与主循环职责重叠。
+            logger.warning(
+                "Sanity pass: assistant at messages[%d] has tool_use without "
+                "user next message (tool_use_ids=%s). Main enforce loop may have a regression.",
+                i,
+                ", ".join(tool_use_ids),
+            )
+            continue
+
+        user_msg = messages_list[next_idx]
+        user_content = user_msg.get("content")
+        if not isinstance(user_content, list):
+            # 主循环 D 步已将 string content 归一化为 list；这里防御性兜底
+            user_msg["content"] = (
+                [{"type": "text", "text": user_content}]
+                if isinstance(user_content, str)
+                else []
+            )
+            user_content = user_msg["content"]
+
+        existing_result_ids = {
+            b["tool_use_id"]
+            for b in user_content
+            if isinstance(b, dict)
+            and b.get("type") == "tool_result"
+            and b.get("tool_use_id")
+        }
+        for uid in tool_use_ids:
+            if uid in existing_result_ids:
+                continue
+            user_content.append(
+                {
+                    "type": "tool_result",
+                    "tool_use_id": uid,
+                    "content": "",
+                    "is_error": True,
+                }
+            )
+            repaired.append((i, uid))
+
+    if not repaired:
+        return []
+
+    logger.warning(
+        "Sanity pass repaired %d unpaired tool_use(s) missed by main enforce loop. "
+        "Affected: %s",
+        len(repaired),
+        ", ".join(f"messages[{idx}]:{uid}" for idx, uid in repaired),
+    )
+    return ["pairing_sanity_repaired"]
+
+
 def _strip_cache_control(body: dict[str, Any]) -> int:
     """从 system/messages/tools 中移除 cache_control 字段（就地）.
 
@@ -294,8 +399,22 @@ def _rewrite_srvtoolu_ids(body: dict[str, Any]) -> tuple[int, dict[str, str]]:
 
     Anthropic API 要求 tool_use 类型与 ``toolu_*`` 格式的 ID。Zhipu 的
     ``server_tool_use`` + ``srvtoolu_*`` 在上游 Anthropic 兼容端点可用，但无法
-    透传至其他供应商；同时还需重写紧随其后 user 消息中 ``tool_result.tool_use_id``
-    引用，保持配对关系。
+    透传至其他供应商；同时还需重写所有 ``tool_result.tool_use_id`` 引用，保持配对关系。
+
+    **两遍扫描（消除块顺序敏感性）**:
+
+    - Pass 1: 仅遍历 ``role == "assistant"`` 的消息，按 assistant 出现顺序为每个
+      待改写的 tool_use 分配 ``toolu_normalized_N`` 新 ID，建立完整 ``id_map``。
+    - Pass 2: 全量遍历消息，对任意 ``tool_result.tool_use_id ∈ id_map`` 的块
+      原地改写为新 ID（不分 user / assistant，覆盖 misplaced 与跨消息边界场景）。
+
+    单遍方案在 GLM-5 偶发将 inline ``tool_result`` 输出在对应 ``server_tool_use``
+    之前的乱序场景下，会因 Case B 时 ``id_map`` 尚未填入而漏改 ``tool_use_id``，
+    导致 ``enforce_anthropic_tool_pairing`` 后 ``extracted_tool_results`` 的 key
+    与 ``tool_use_ids`` 不一致，进而把本应配对的 misplaced tool_result 默默丢弃，
+    最终触发 Anthropic ``messages.x: tool_use ids were found without tool_result
+    blocks immediately after`` 400 错误。两遍扫描以"先建表、后改写"的次序消除该
+    时序耦合。
 
     Returns:
         (rewritten_count, id_map) — 重写次数与 {原 ID: 新 ID} 映射。
@@ -308,45 +427,56 @@ def _rewrite_srvtoolu_ids(body: dict[str, Any]) -> tuple[int, dict[str, str]]:
         counter += 1
         return f"toolu_normalized_{counter}"
 
+    # Pass 1: 扫描 assistant 消息，改写 tool_use / server_tool_use 的 id 与 type，
+    # 按出现顺序填充 id_map（保持与单遍版本相同的序号分配，避免破坏既有断言）。
     for message in body.get("messages", []):
-        if not isinstance(message, dict):
+        if not isinstance(message, dict) or message.get("role") != "assistant":
             continue
         content = message.get("content")
         if not isinstance(content, list):
             continue
-        role = message.get("role")
         for block in content:
             if not isinstance(block, dict):
                 continue
             block_type = block.get("type")
+            if block_type not in {"tool_use", "server_tool_use"}:
+                continue
             block_id = block.get("id")
-
-            # Case A: assistant 消息里的 server_tool_use / srvtoolu_* → 改写
-            if role == "assistant" and block_type in {"tool_use", "server_tool_use"}:
-                if isinstance(block_id, str) and _ANTHROPIC_SERVER_TOOL_USE_ID_RE.match(
-                    block_id
-                ):
-                    new_id = next_id()
-                    id_map[block_id] = new_id
-                    block["id"] = new_id
-                    block["type"] = "tool_use"
-                elif (
-                    isinstance(block_id, str)
-                    and block_id
-                    and not _ANTHROPIC_TOOL_USE_ID_RE.match(block_id)
-                    and block.get("name")
-                ):
-                    # 非标准 ID（非 toolu_ / srvtoolu_），且具备 name 可改写
-                    new_id = next_id()
-                    id_map[block_id] = new_id
-                    block["id"] = new_id
-                    block["type"] = "tool_use"
-                elif block_type == "server_tool_use" and isinstance(block_id, str):
-                    # 兜底: 类型是 server_tool_use 但 ID 已是标准 toolu_ 形式，仅纠正类型
-                    block["type"] = "tool_use"
-
-            # Case B: user 消息里的 tool_result.tool_use_id 同步重写
-            if block_type == "tool_result":
+            if isinstance(block_id, str) and _ANTHROPIC_SERVER_TOOL_USE_ID_RE.match(
+                block_id
+            ):
+                new_id = next_id()
+                id_map[block_id] = new_id
+                block["id"] = new_id
+                block["type"] = "tool_use"
+            elif (
+                isinstance(block_id, str)
+                and block_id
+                and not _ANTHROPIC_TOOL_USE_ID_RE.match(block_id)
+                and block.get("name")
+            ):
+                # 非标准 ID（非 toolu_ / srvtoolu_），且具备 name 可改写
+                new_id = next_id()
+                id_map[block_id] = new_id
+                block["id"] = new_id
+                block["type"] = "tool_use"
+            elif block_type == "server_tool_use" and isinstance(block_id, str):
+                # 兜底: 类型是 server_tool_use 但 ID 已是标准 toolu_ 形式，仅纠正类型
+                block["type"] = "tool_use"
+
+    # Pass 2: 全量扫描，对任意 tool_result.tool_use_id 命中 id_map 的块同步改写。
+    if id_map:
+        for message in body.get("messages", []):
+            if not isinstance(message, dict):
+                continue
+            content = message.get("content")
+            if not isinstance(content, list):
+                continue
+            for block in content:
+                if not isinstance(block, dict):
+                    continue
+                if block.get("type") != "tool_result":
+                    continue
                 tool_use_id = block.get("tool_use_id")
                 if isinstance(tool_use_id, str) and tool_use_id in id_map:
                     block["tool_use_id"] = id_map[tool_use_id]

{coding_proxy-0.3.1a10 → coding_proxy-0.4.1a1}/src/coding/proxy/native_api/handler.py

@@ -18,6 +18,7 @@ import logging
 import time
 from collections.abc import AsyncIterator
 from typing import TYPE_CHECKING
+from urllib.parse import unquote
 
 import httpx
 
@@ -172,8 +173,16 @@ class NativeProxyHandler:
             )
 
         method = request.method.upper()
-        operation = OperationClassifier.classify(provider, method, rest_path)
-        endpoint = rest_path if rest_path.startswith("/") else f"/{rest_path}"
+        # 防御性 URL 解码：确保 %3A → : 以兼容 Gemini :verb 路径语法。
+        # ASGI 规范要求 scope["path"] 已解码，但部分服务器/反向代理对
+        # 合法路径字符（如冒号）可能保留编码形态。
+        decoded_rest_path = unquote(rest_path)
+        operation = OperationClassifier.classify(provider, method, decoded_rest_path)
+        endpoint = (
+            decoded_rest_path
+            if decoded_rest_path.startswith("/")
+            else f"/{decoded_rest_path}"
+        )
 
         upstream_headers = _filter_request_headers(dict(request.headers))
         # 强制 identity —— 阻止上游压缩（httpx 默认会自动补 gzip,deflate;

{coding_proxy-0.3.1a10 → coding_proxy-0.4.1a1}/src/coding/proxy/native_api/operation.py

@@ -51,27 +51,27 @@ _OPENAI_RULES: tuple[_Rule, ...] = (
 # Gemini 的方法动词作为路径后缀（``:generateContent``），通过正则提取
 _GEMINI_RULES: tuple[_Rule, ...] = (
     _Rule(
-        re.compile(r"^/?v1(?:beta)?/models/[^/]+:streamGenerateContent/?$"),
+        re.compile(r"^/?v1(?:beta)?/models/[^/]+(?:%3A|:)streamGenerateContent/?$"),
         "generate_content",
     ),
     _Rule(
-        re.compile(r"^/?v1(?:beta)?/models/[^/]+:generateContent/?$"),
+        re.compile(r"^/?v1(?:beta)?/models/[^/]+(?:%3A|:)generateContent/?$"),
         "generate_content",
     ),
     _Rule(
-        re.compile(r"^/?v1(?:beta)?/models/[^/]+:countTokens/?$"),
+        re.compile(r"^/?v1(?:beta)?/models/[^/]+(?:%3A|:)countTokens/?$"),
         "count_tokens",
     ),
     _Rule(
-        re.compile(r"^/?v1(?:beta)?/models/[^/]+:embedContent/?$"),
+        re.compile(r"^/?v1(?:beta)?/models/[^/]+(?:%3A|:)embedContent/?$"),
         "embedding",
     ),
     _Rule(
-        re.compile(r"^/?v1(?:beta)?/models/[^/]+:batchEmbedContents/?$"),
+        re.compile(r"^/?v1(?:beta)?/models/[^/]+(?:%3A|:)batchEmbedContents/?$"),
         "embedding.batch",
     ),
     _Rule(
-        re.compile(r"^/?v1(?:beta)?/models/[^/]+:predict/?$"),
+        re.compile(r"^/?v1(?:beta)?/models/[^/]+(?:%3A|:)predict/?$"),
         "predict",
     ),
     _Rule(
@@ -159,7 +159,8 @@ class OperationClassifier:
         normalized = path if path.startswith("/") else f"/{path}"
         return bool(
             re.match(
-                r"^/?v1(?:beta)?/models/[^/]+:streamGenerateContent/?$", normalized
+                r"^/?v1(?:beta)?/models/[^/]+(?:%3A|:)streamGenerateContent/?$",
+                normalized,
             )
         )