昨天跑一个半自动化的代码审查任务Claude Code在连续处理了几十个文件之后突然给我弹了一行红字Run failed: Error: analyze error: INTERNAL ERROR: 0 vs. 11.。任务终止没有恢复提示也没有更多上下文。我第一反应是某个文件格式把解析器搞崩了但后来仔细排查发现问题没那么简单。如果你也撞上过类似的错误大概率知道这种报错最烦人的地方不是失败而是不知道怎么失败的。这个报错看起来简短其实分了三层每一层都对应一个判断方向Run failed是任务层的终止状态analyze error指出是分析阶段出的问题INTERNAL ERROR则意味着工具内部在做一致性校验时发现了一个无法自洽的结果。0 vs. 11就是那个不一致的数据也是整个报错里最有信息量的一段。这篇文章我就围绕这行报错把我这几天的排查过程、对内部机制的推断、以及最终验证有效的处理方式完整写出来。适合正在用Claude Code跑自动化任务、遇到agent中途挂掉又不知道从哪下手的人参考。1. 报错现场还原它到底发生在哪一步1.1 从Run failed到INTERNAL ERROR的三层结构先别急着搜答案把这行错误拆开看你会发现它本身就带着定位信息。第一层是Run failed这是任务运行器给出的最终判定意思是整个运行过程没有正常结束。这一层只告诉你结果不告诉你原因。第二层是analyze error它把问题范围缩小到了analyze这个环节。在Claude Code的agent流程里analyze阶段负责处理模型返回的内容拆解工具调用、提取代码片段、匹配语义块。换句话说模型输出到客户端之后先要经过一层解析和结构化解析不过关后面的步骤根本走不下去。第三层是INTERNAL ERROR: 0 vs. 11这是最核心的一行。它说明工具内部检测到了一个数量不一致的问题而且这种不一致触发了内部断言。所谓内部断言就是开发者在代码里埋的检查点如果实际情况和预期不符宁可主动报错退出也不带着错误数据继续跑。我后来查了社区里类似案例基本可以确认这类数量不一致的报错基本都是解析器在期望值和实际值之间出现了偏差然后被断言逻辑拦了下来。1.2 我复现时看到的完整日志为了还原现场我把出错那次任务重新跑了一遍加了debug级别的日志输出。问题稳定复现后日志大概是这样的$ claude --debug [12:03:21] Starting task: review_changes [12:03:22] Streaming response: chunk received (1524 bytes) [12:03:22] Streaming response: chunk received (4096 bytes) [12:03:23] Streaming response: chunk received (2048 bytes) [12:03:23] Stream completed: total 0x2a1f bytes [12:03:23] Analyze: parsing response body [12:03:23] Analyze: expected 11 semantic blocks, resolved 0 [12:03:23] INTERNAL ERROR: 0 vs. 11 [12:03:23] Run failed: Error: analyze error: INTERNAL ERROR: 0 vs. 11.注意那个0x2a1f字节数是十六进制换算过来是10783字节。问题是响应流明明完整结束了字节数也正常但最终解析出来的语义块数量却是0。用行话说就是传输完整解析为空。所以这个错误跟网络断流不一样它更像是模型返回的内容格式本身出了问题导致解析器一个块都没认出来。1.3 这个报错的触发频率与高发场景我连续几天的测试下来发现这个错误不是均匀分布的有几个场景明显更容易触发。第一是长会话。运行了很长的任务上下文里堆积了大量历史消息模型在输出时更容易出现格式漂移。第二是任务里塞了多个复杂工具调用比如同时让模型读文件、改文件、再跑命令返回内容里工具调用的边界就很容易混淆。第三是模型输出被某种策略截断或改写比如内容安全过滤、隐私检测这类环节在中间做了处理但处理后的数据没有保持原有结构。搞清楚什么时候容易出比为什么出更优先。因为很多情况下你不需要根因只需要规避触发条件就能继续干活。2. 0 vs. 11背后analyze阶段的计数校验到底在查什么2.1 analyze阶段的工作内容Claude Code拿回模型输出之后并不是直接执行而是要先经过一个叫analyze的中间层。这个层做的事有点像翻译校验把模型输出的自然语言、JSON结构、工具调用标记统一转换成内部可以执行的任务指令。举个例子模型输出可能长这样我检查了这两个文件发现了三处问题。 use toolread_file pathsrc/config.ts / 第一个问题是配置项缺失。 use toolwrite_file pathsrc/config.ts /analyze阶段要做的事情就是识别出这句话属于总结型内容提取出read_file和write_file两个工具调用把工具调用和后面的自然语言段落关联起来最终生成一个结构化任务列表交给执行器这个过程如果一切顺利工具调用、代码块、文本段都会被拆成独立的语义块。然后引擎会统计这个响应里有多少个块拿这个数字跟预期做比对。2.2 0和11分别代表什么我基于对这个工具运行机制的观察给出一个大概率正确的解释11是模型输出内容里应该被识别出来的语义块数量0是analyze阶段实际解析出来的数量。模型在生成内容时内部其实知道自己产出了多少个片段。这个信息会跟着响应元数据一起传给客户端。客户端收到后先看元数据说是11个然后跑一轮解析结果一个都没解析出来两个数字对不上于是内部断言直接抛错。为什么会出现元数据说有解析出来没有通常是因为模型输出的实际文本结构跟它自己声明的结构不一致。比如模型在生成过程中改了主意中途切换了输出格式前一半用的是代码块嵌套结构后一半变成了普通文本但元数据还是按原先的格式计数。客户端按旧格式去解析前半段还能勉强识别后半段直接匹配失败最后统计结果就变成了0。2.3 为什么设计成INTERNAL ERROR而不是普通错误提示这是很多人容易忽略的一点INTERNAL ERROR不是程序写错了的意思它更接近程序发现数据自相矛盾拒绝继续执行的意思。它在设计上属于快速失败fail fast策略。与其拿着一个解析数量为0的结果硬着头皮往下执行——比如假装没有工具调用直接对空数据处理——不如当场报错把问题暴露出来。因为一旦用错误数据继续跑轻则任务结果不对重则可能执行了错误的操作那才是真正的大事故。从工程角度讲这种校验是合理的。只是对用户来说错误信息太简略了只给了0 vs. 11没给11个块分别是什么、为什么解析失败。这其实是日志没做细不是设计意图有问题。3. 实测过的诱因清单从网络截断到参数越界3.1 流式响应截断最常见的罪魁祸首我复现这个错误的过程中第一个怀疑对象就是流式传输。Claude Code跟远端模型通信用的是流式响应streaming也就是内容是一块一块传回来的客户端边收边解析。如果传输中途断了客户端拿到的就是半截内容。半截内容在解析时常常表现为格式不完整——比如一段JSON只收了一半一个代码块没有闭合标签。解析器尝试解析这种半成品自然什么都匹配不上。不过我这里也碰到了一个反直觉的情况日志显示Stream completed表明传输其实是完整结束的。那就说明截断不是发生在传输层而是更早——在模型端生成内容时就已经是被截断的状态。我把测试过的网络场景列出来场景是否触发该错误说明正常网络跑短任务否几十轮对话稳定网络抖动后恢复偶尔触发的是其他的传输错误不是这个长任务代理转发是响应体在代理层被改写时更容易出公司出口防火墙策略是多次出现半截内容但没有网络报错结论是INTERNAL ERROR: 0 vs. 11这个错误的直接原因通常不是网络断流而更可能是模型端返回的响应内容本身就不完整或结构异常。网络问题通常会抛网络错误不会给你一个完整但解析为空的响应。3.2 长篇任务里上下文超限引发的连锁反应另一个高发诱因是上下文长度超限。我在测试一个长达几十轮的任务时任务进行到一半模型端提示超出上下文长度限制。有的版本会直接拒绝继续有的版本则会做自动截断——把比较早的对话记录砍掉一部分只保留最近的内容继续生成。问题就出在这个自动截断上。如果截断策略只砍了对话记录但没同步更新响应元数据里的计数信息生成结果就可能是内容被截断了但元数据没变。这个时候客户端拿到响应元数据说要解析11个块实际内容可能只有4个块或者0个有效块0 vs. 11就这么来了。所以我后来做长任务时习惯主动控制会话长度不让上下文无限膨胀。必要的时候干脆开新会话把关键信息用摘要的方式传过去而不是让模型一直背着全部历史跑。3.3 非法参数怎么让解析器拿到空结果还有一个容易被忽略的诱因参数配置异常。有次我在任务参数里加了一个thinking_budget参数想控制模型的思考深度。结果任务直接报错相关错误信息指向参数必须是正整数。我一开始以为这只是普通参数错误但后来发现这类参数在某些版本里会导致模型端生成行为异常——模型尝试按一个无法解释的预算参数去规划输出结构结果生成的内容连它自己都说不清结构。类似的还有max_tokens设置过小。模型输出的内容长度超过了token上限被硬生生截断。截断位置如果落在代码块中间或者JSON结构中间后面半截就会变成无法解析的尾巴。这种情况在日志里表现为传输正常完成、字节数正常、但解析结果为0。所以排查时不要只看网络和版本也要检查调用参数。尤其是那些看起来不该出问题的参数往往就是问题本身。3.4 客户端版本与远端接口不匹配有一次升级了本地CLI之后这个问题出现的频率一下子高了很多。我当时的操作是在旧版本任务还没跑完的时候直接升级了新版本新版本引入了不同的解析逻辑但远端模型接口返回的结构还是旧版本时代的格式。两边不匹配解析器按新格式去解旧数据部分旧结构识别失败。这个场景在社区里也有不少案例。一句话总结就是Claude Code的CLI和远端模型接口之间存在版本耦合CLI太老或太新都可能踩到兼容性问题。我自己总结了一套版本管理习惯固定使用某个经过验证的版本不追新升级之前先看changelog确认解析逻辑有没有变化升级后先在简单任务上验证再跑长任务3.5 本地环境残留多个CLI并存引发的怪问题排查到后半段我发现本地环境里存在两个不同路径的claude执行文件。一个通过包管理器安装在全局目录另一个来自项目本地的依赖目录。命令行解析时优先命中了其中一个而这个版本恰好和项目配置的模型版本不兼容。典型报错包括error: claude native binary not installed. either postinstall did not run or it was interrupted.这个错误的意思是CLI的安装后初始化步骤没完成。如果你遇到这种问题很简单重新安装一次基本能解决。但它提醒我的重点是当本地有多个版本的CLI共存时你真正跑起来的是哪个版本可能跟你以为的完全不一样。我当时用which claude和npx claude --version分别查了一下发现两个命令指向的版本不一样。这就是典型的路径解析问题。处理方式是清理掉冗余的旧版本只保留一个再重新验证。4. 排查链路我把从日志到修复的完整过程走了一遍4.1 第一步开debug日志别靠肉眼猜遇到这种错误第一件事永远是把日志级别调到debug。Claude Code支持通过--debug或环境变量ANTHROPIC_LOGdebug开启详细日志。开了之后能看到完整的请求和响应过程包括请求发送给哪个端点的哪个模型响应是以什么形式分块返回的每块字节数、总字节数解析器尝试解析时用的什么格式解析失败时具体卡在哪一步我这次排查能定位到传输完整但解析为空就是靠debug日志看到了Stream completed和resolved 0这两行。没有这层信息我只能对着外层错误瞎猜。4.2 第二步最小化复现把任务拆到最小拿到debug日志后下一步是做最小化复现。我当时的做法是把出问题的任务文件复制一份然后从中间切开前半段单独跑一次后半段单独跑一次。如果两个半段都不出错再逐步扩大范围直到找到一个刚好能触发错误的最小集合。这个方法的威力在于它能帮你区分到底是任务内容的问题还是系统状态的问题。如果最小任务也复现了说明跟具体任务关系不大是环境或版本问题如果最小任务不复现那就可以通过二分法逐步逼近真正出问题的那个文件或操作。我做了大概六轮二分最终锁定了一个包含大量多行字符串的代码文件。这个文件里有一段很长的模板字符串里面夹杂着不少引号和换行。模型在总结这个文件时输出的内容里格式标记非常复杂很容易在解析时产生歧义。4.3 第三步区分是客户端问题还是服务端问题这一步很重要你要判断错误是在客户端抛的还是远端服务端抛的。判断方式很简单看错误堆栈和错误码。如果错误来自服务端通常会有HTTP状态码或API层错误结构比如{type: error, error: {type: api_error, message: ...}}如果错误来自客户端通常就是纯粹的本地异常信息比如INTERNAL ERROR这种内部断言。我这次遇到的是客户端抛出的内部错误。因为日志显示响应已经完整接收并且没有HTTP错误码是客户端在解析阶段自己发现的矛盾。这说明问题根源在响应内容本身而不在传输链路。4.4 第四步按概率逐一排除的实操顺序结合我多次实测的经验推荐按下面的顺序排查效率最高检查版本claude --version确认客户端版本确认近期没做过不兼容的升级检查参数看调用参数里有没有可疑的数值配置比如max_tokens、thinking_budget、context相关配置检查上下文长度如果任务是长会话考虑拆分或重开会话把上下文压缩到安全范围检查本地环境用which claude确认执行路径清理多个CLI并存的情况重新安装如果怀疑安装后初始化被中断重装一次很多native binary not installed类问题可以解决降低单次任务复杂度把一次让模型做太多事的任务拆成多次降低单次输出的结构复杂度这个顺序的核心逻辑是先排除最容易验证、成本最低的因素再逐步深入。版本和参数检查只要几分钟而拆任务、改任务则要更多时间。4.5 修复后的验证怎么确认问题真的解决了修复不是不报错了就完了还要确认不会在下一个环节爆发。我做完上面几步修复后重新跑了一遍原始任务。这次没有报INTERNAL ERROR但我额外检查了两件事任务最终产出的结果文件和预期是否一致。有时候解析错位不会导致报错而是导致工具调用被错误执行——那种情况更危险。在debug日志里确认resolved的数量跟元数据声明的一致。不一致但没抛错说明是走了另一条容忍路径也要警惕。我用了一个简单但有效的验证方法把任务产出结果拿给另一个模型交叉复核看它能否识别出结果中的工具调用和代码变更是否匹配。两边对比一致我才认为问题真正解决。5. 降低同类报错率的日常操作习惯5.1 控制会话长度避免上下文无脑膨胀INTERNAL ERROR: 0 vs. 11这类问题在长会话里特别高发我的应对策略是给会话设置一个寿命上限。具体做法是当一个会话跑完20轮以上或者累计文件内容已经很多时主动开一个新会话把已完成工作的关键结论写成一个摘要文件让新会话从摘要继续。这样模型每次要处理的上下文规模是可控的输出的格式稳定性也会好很多。很多agent类任务其实不需要完整的历史信息。比如代码审查模型只要知道当前文件内容、改动的diff、以及审查规则就够了。把它之前100轮聊过的内容全塞进上下文反而会让输出噪声变大。5.2 版本固定与升级节奏工具版本的升级节奏直接影响到这类错误的出现频率。我建议把claude版本固定在一个经过验证的稳定版本不要每次发版都跟着升。尤其是在跑重要任务期间尽量不要动版本。如果必须升级先跑一遍回归测试——用几个历史任务验证升级前后行为一致。我还建议在项目根目录放一个.tool-version文件或类似方式来记录使用的CLI版本方便多人协作时统一环境。团队里如果有人用了不同版本跑出来的结果不一致排查起来非常头疼。5.3 给长任务设合理检查点长任务最怕的不是报错而是报错之后不知道前面的结果哪些是有效的。我现在跑长任务时会把输出写成多个中间文件而不是让模型一口气把所有东西都处理好。每一步的产出都落盘这样即使某一步触发了INTERNAL ERROR我只需要重跑那一步不需要从零开始。这个习惯看起来朴素但在排错时价值巨大。上次报错时我只需要重新生成三份中间文件就接上了整个流程省掉了大量重复劳动。5.4 参数不是越多越好很多人会在调用时加一堆参数看起来是在精细控制实际是在给自己挖坑。参数越多出现非法组合的概率越高模型端根据参数调整生成策略时也越容易产生异常行为。尤其是跟模型输出结构直接相关的参数比如max_tokens、thinking_budget、context相关的参数都要谨慎。我建议先用最简参数跑通任务再加参数做优化。加一个参数就验证一次确认不会引入新问题。不要在没验证的情况下堆十几个参数一起上。6. 相关报错速查表一张表定位同类问题排查过程中我还遇到了不少关联报错有些是同一个根源的不同表现有些则是完全独立的问题。我把它们整理成一张速查表方便你对照排查报错信息大概率原因优先处理动作Run failed: Error: analyze error: INTERNAL ERROR: 0 vs. 11模型响应结构异常解析器解析数量与元数据不一致检查上下文长度升级/重装CLI拆任务重试stream disconnected before completion: transport error: network error网络传输中断检查网络稳定性配置超时重试换个网络环境验证api error: 400 the thinking_budget parameter must be a positive integer参数值非法检查参数配置改成正整数api error: 400 this models maximum context length is 1048576 tokens. However...上下文长度超限压缩上下文重开会话拆分任务error: claude native binary not installed安装后初始化未完成重装CLI确保postinstall步骤执行could not locate the claude cli on path环境变量路径配置问题使用完整路径或把CLI安装目录加入PATHthe agent run failed before producing a replyagent运行早期即失败原因多样开debug日志定位检查参数和版本error: claude code process exited with code 3CLI进程异常退出查看退出时的完整日志确认具体阶段agent terminated due to error you can prompt the model to try again or startagent运行中断可尝试恢复按提示继续对话或重开会话从头开始api error: 402 insufficient balance账户余额不足充值或检查账户状态这张表不是一个严格的一一对应关系因为同样的报错在不同环境里可能由不同原因触发。我的建议是先看报错属于传输类参数类还是解析类再决定排查方向。INTERNAL ERROR: 0 vs. 11属于解析类。解析类报错的核心特点就是传输成功、参数有效、但内容本身没法用。这种时候别反复重试同一个任务重试一百次结果都一样因为触发条件还在那里。正确做法是改变输入——要么缩短上下文、要么拆任务、要么换个版本环境。另外说一个我在排查中踩过的误区。一开始我以为是这个报错跟某些特定的功能区域支持状态有关。后来发现我这个错误触发场景跟区域支持没有直接关系只是因为网络链路上多了几层转发导致返回内容被改写。所以在排查时如果你怀疑跟网络路径有关优先看响应内容和字节数而不是盯着错误类型猜测。最后分享一个我目前一直在用的稳定方案把Claude Code的版本固定每次跑长任务前把上下文压缩到合理范围任务中间增加检查点参数保持最少化。这三个动作做到之后INTERNAL ERROR: 0 vs. 11基本上没有再出现过。