Claude Code 2.1.202：workflow OTel 属性与动态规模控制，重塑多智能体运行的运营可见性

Claude Code 2.1.202 的更新日志乍看像一次常规维护发版，但其中隐藏着两项对运营团队意义重大的变更：workflow 级别的 OpenTelemetry 属性支持，以及面向运营者的动态 workflow 规模控制项。这两项改动，从根本上改变了工程团队对多智能体 workflow 运行的治理与观测方式。

发生了什么

Claude Code 2.1.202 为大规模运行动态 workflow 的团队带来三项关键变更：

1. 动态 workflow 规模配置 — /config 新增一个规模建议选项（小 / 中 / 大 agent 数量），Claude 会在决定生成多少 sub-agent 时参考这一偏好。发版说明明确指出：这是建议性设置，而非强制上限。但这是首次将该决策作为配置项暴露给运营者，而不是埋在 system prompt 里。

2. workflow.run_id 和 workflow.name OTel 属性 — 由 workflow 生成的所有 agent 发出的遥测数据，现在都携带这两个新字段。运行 OpenTelemetry collector 的运营团队，可以将每条工具调用、模型请求和 token 消耗事件，关联回一个具体命名的 workflow 运行实例，无需再手动拼接 span 树。

3. mTLS 轮转修复 — 证书原地轮转期间的瞬态握手失败问题已修复。对于在 mutual-TLS 网关或企业代理后部署 Claude Code 且使用短期证书的运营者，这一修复直接消除了潜在中断风险。

其他修复：/review <pr> 回归为单次 pass（多智能体审查需使用 /code-review <level> <pr#>）；worktree 仓库中 session 恢复您问题已修复；麦克风故障时语音输入无限重试循环已解决。

对 AI 工程团队意味着什么

自 2.1.160 引入动态 workflow 以来——Claude 自主编写并执行编排脚本，将任务分发给数十个 sub-agent——这一能力始终是 Claude Code 中运营透明度最低的部分。大型 workflow 运行的 token 消耗难以预测，事后归因更是困难重重。

2.1.202 的两项变更从不同角度分别解决了这两个问题：

规模建议作为策略旋钮。 此前，workflow 生成多少 sub-agent 完全由模型自主决定。新的小/中/大配置项为运营者提供了一个有文档支撑的调节旋钮，用以引导整体并发规模——对于 API 预算、速率限制或 provider 配额无法承载大规模并发的场景尤为关键。这并非硬性 agent 数量上限，但它提供了一个能在 prompt 重写和上下文切换中保持稳定的默认行为偏好。

OTel workflow 属性作为费用归因层。 workflow.run_id 是一个稳定标识符，将同一 workflow 执行的所有 span 归为一组；workflow.name 映射到人类可读的标签。对于需要将 API 成本分摊到项目、客户或工单的团队，这两个属性将 workflow 遥测从调试工具转变为费用归因层——前提是你的 AI gateway 能够转发 OTel 数据，且费用核算管道能够消费这些数据。

mTLS 修复是一个较小但重要的可靠性信号：Anthropic 在主动加固 Claude Code 的 gateway 集成边界，而非将边缘场景 TLS 故障列为已知问题搁置。

Router/Operator 视角分析

动态 workflow 运行制造了一个大多数运营者解决得不够好的 routing 问题：sub-agent 的模型请求在 gateway 层面看起来完全一样——相同的 API key、相同的 model、没有 workflow 上下文。随着 workflow.run_id 现在通过 OTel 传播，一个经过适当配置的 gateway 可以实现：

• 按 workflow 强制 token 预算 — 在不中断同一 key 上其他 session 的情况下，停止已超出配额的失控 workflow。
• 按 workflow 名称归因成本 — 按 workflow 类型而非仅按用户或团队拆解 API 支出。
• 审计 sub-agent 行为 — 以稳定的 run ID 为锚点，重建一次 workflow 运行中工具调用和模型请求的完整时序。

动态规模建议则提供了互补的上游控制：如果你的 gateway 按并发数限流，将 Claude 设置为"小"规模 workflow，可以在请求到达 provider 之前就降低突发系数。

关于 mTLS 修复：在企业 mutual-TLS 代理后运行 Claude Code 且使用短期证书的团队，应在下次轮转窗口前升级到 2.1.202。旧版本可能在握手期间静默失败。

TheRouter 用户建议关注的方向

OTel workflow 属性只有在可观测管道实际采集时才有价值。检查你的 AI gateway 或 OTel collector 是否配置了从 Claude Code OTel exporter 转发 span 属性——如果已配置，升级到 2.1.202 后，workflow.run_id 和 workflow.name 将自动出现在你的 trace 数据中。

关于规模建议：如果你在有速率限制的 provider 层级运营，或曾遭遇 workflow 引发 token 峰值，将 /config 动态规模选项设为 small 或 medium。这不是硬性保证，但它为模型提供了稳定的默认行为。

如果你的团队正在评估多智能体 workflow 的成本治理方案，2.1.202 的规模建议与 OTel 归因组合，是 Claude Code 迄今最接近原生 workflow 可观测性的方案。在 workflow 成为标准实践前建立费用核算层，远比事后补做成本更低。TheRouter API 文档介绍了如何接入自定义 OTel collector 实现 gateway 级归因。