实验 5-1：跨厂商的轨迹接管

// gemini-to-kimi 之外的 kimi-to-gemini-naive.json → exchanges[1].error_body
{
  "error": {
    "code": 400,
    "message": "Function call is missing a thought_signature in functionCall parts.
      This is required for tools to work correctly, and missing thought_signature
      may lead to degraded model performance. Additional data, function call
      `default_api:get_flight_price` , position 2. Please refer to
      https://ai.google.dev/gemini-api/docs/thought-signatures for more details.",
    "status": "INVALID_ARGUMENT"
  }
}

• 凭证的位置决定谁能接谁的盘。gemini 收下 kimi 的直传轨迹时只检查 thoughtSignature 这一格在不在，不检查是谁签的；而反过来，gemini 签出来的轨迹到了缺凭证的接收端就直接 400。校验强度的不对称，比格式差异更容易让人踩坑。
• 「直传能过」不等于「直传是对的」。本次 naive 臂在 gemini → kimi 方向一次通过，但真正决定成败的不是它带对了什么，而是接收端没查。同一个格子在另一个方向就成了 400。
• kimi 侧没有凭证，于是两条对照臂退化成同一条臂。kimi → gemini 的 naive 与 strip 报的是同一句 missing a thought_signature，交出去的 functionCall 结构完全一致。这不是重复实验，是「无凭证可搬」这个事实的直接后果。
• 中立臂 2/2 通过，且两个方向都算对了 ¥6,944。它的做法是：凭证丢弃，可移植的明文以普通文本身份带走（带 ［接手前由 kimi 留下的思考记录］ 前缀），工具调用 id 按目标厂商重铸，遇到强制要求凭证的接收端再单独补发。
• 重复调用全为 0，这是个负结果。本任务的状态全落在工具结果里，而工具结果在三条臂里都完整保留——所以思考带不带走并不影响模型接着往下做。真正卡住接管的是格式与凭证，不是思考内容。若关键状态只存在于思考中（例如模型在思考里排掉了某个方案却没写进任何工具调用），差异才会显现。
• 带思考要付钱，但买的是确定性。gemini → kimi 三条臂轮数相同（均 3 轮），输入 token 却从剥离的 2,062 涨到直传的 4,113。步数没省，钱省不下来。
• 本次结论的适用边界要写清楚。仅 2 家厂商、2 个有向组合、6 个单元；Anthropic 缺席。厂商接口约定演进很快，具体字段名与报错文案都可能已变，重跑前需自行确认。