CCB智能体卡死怎么办？$ccb_diagnose诊断命令与故障恢复完整清单

CCB智能体卡死怎么办$ccb_diagnose诊断命令与故障恢复完整清单【免费下载链接】claude_codex_bridgeVisible multi-agent CLI workspace for mixing Codex, Claude, Gemini, Kimi, Qwen, Cursor, Copilot, Pi, OpenCode, and other AI coding agents项目地址: https://gitcode.com/gh_mirrors/cl/claude_codex_bridgeCCBClaude Codex Bridge是一个可视化的多智能体 CLI 工作区让你在同一块终端屏幕里混用 Codex、Claude、Gemini、Kimi、Qwen、Cursor、Copilot、OpenCode 等 AI 编码智能体。当某个智能体卡死——不回复、不继续、显示报错时内置的$ccb_diagnose诊断命令可以一键完成体检 → 分类 → 恢复 → 验证的全流程。本文是一份面向新手的最小可用清单照着做即可。智能体为什么会卡死先建立一个直觉CCB 里每个智能体都运行在一个独立的 tmux 窗格pane里。所谓卡死通常有 8 种真实状态$ccb_diagnose会把它们自动分类 状态分类含义新手判断口诀working正常干活中有输出在滚动 没卡waiting_input在等你输入屏幕上有信任/登录/确认提示stale_prompt请求已被接受但智能体闲置在提示符最典型的假卡死provider_update卡在供应商升级/重装界面屏幕出现 update/install 字样provider_error认证、配额、限流、网络等报错屏幕有红色报错dead_or_blank窗格已死或空白画面一片空白misframed布局错乱导致状态不可观测窗格大小/焦点异常unknown证据不足交给诊断系统判断 关键认知窗格上的文字只是证据不是权威。真正的权威是 CCB 的 runtime 与作业血缘job lineage。这正是$ccb_diagnose存在的意义——它同时看屏幕证据和权威状态两者交叉验证。一步诊断如何正确使用 $ccb_diagnose在所有受支持的托管智能体中ccb-diagnose是内置必装的控制 Skill即使关闭了可选 skill 继承也依然存在。用法只有一行在对应智能体的输入框里发出$ccb_diagnose agentname它会自动按 6 个阶段执行完整工作流定义见 ccb-diagnose SKILL.md确立权威依次ccb ping ccbd、ccb ping agent、ccb ps、ccb queue --detail、ccb pend --inbox --detail必要时ccb doctor logs agent与ccb trace id深度窗格诊断用只读方式捕获窗格文本间隔一次做有无进展对比——绝不向窗格发送任何按键分类输出Status / Agent / Pane / Suspected domain / Evidence / Confidence / Next action结构化结论受限恢复只执行有证据支持的、破坏性最小的修复见下节清单验证重新跑最小检查集确认血缘、队列、ping 全部恢复一致事故包生成本地脱敏事故包提交外部 issue 前必须经你明确授权。故障恢复完整清单6 种情况各对应什么操作诊断系统遵守最小破坏原则。下表把常见结论映射到唯一推荐动作 ️诊断结论推荐恢复命令前提条件回复已被接受但确认丢失ccb repair ack ...trace 能证明回复确实被接受一次尝试未完成但血缘仍有效ccb repair retry ...原始作业血缘未失效血缘陈旧/上下文损坏ccb repair resubmit ...旧路径已终止且你确认业务影响供应商窗格陈旧/已死先取消活跃作业 → 再ccb restart agent只针对当前图上的这一个智能体上下文本身是病因ccb clear agent没有活跃/排队/待回复作业会丢失配置漂移配置校验 ccb reload只针对已诊断的配置漂移诊断契约的完整规则哪些文件是证据、哪些是权威、什么操作被禁止写在 ccbd-diagnostics-contract.md想深入理解可以阅读。四条红线诊断系统会自动遵守新手也请记住❌ 不直接tmux send-keys / kill-pane / respawn-pane乱动手❌ 不把所有智能体一起重启、不做项目级关停❌ 不读取、打印或上传任何密钥/凭据❌ 验证未通过之前不声称已恢复修复之后30 秒验证闭环恢复动作完成后一定要跑一遍最小验证集否则诊断完成 ≠ 智能体恢复 ✅ccb trace lineage_id # 作业血缘回到预期状态 ccb queue --detail agent # 队列无异常重复头 ccb pend --inbox --detail agent ccb ping agent # 智能体心跳正常三项都一致、且窗格证据与结果相符才算真正恢复。修不好怎么办导出支持包交给开发者如果受限恢复全部失败正确姿势不是继续重启而是打包诊断现场ccb doctor # 项目级诊断读路径先看总结 ccb doctor --bundle # 导出 .ccb/ccbd/support/bundle-id.tar.gz支持包是传输单元它包含 manifest、doctor 快照、当前配置、生命周期报告、后端日志、每个智能体的运行时权威与日志等并且自动排除 API key、auth token 等敏感材料规则详见诊断契约的 3.7 节。把这个 tar 包发给维护者对方无需登录你的机器就能复现故障上下文。预防卡死的 3 个日常习惯看队列先看头排队本身不是故障先检查活跃头head作业busy不等于卡活跃作业 窗格有进展 健康状态登录/配额类报错先处理供应商侧provider-auth-revoked类状态需要重新登录后再挂载重启智能体解决不了它。更多使用细节可参考中文 READMEREADME/zh.md与自助专家指南ccb-self-expert-guide.md。记住核心口诀先$ccb_diagnose拿证据再按清单选最小动作最后 30 秒验证闭环——智能体卡死就不再是玄学而是一张可以照做的检查表 。【免费下载链接】claude_codex_bridgeVisible multi-agent CLI workspace for mixing Codex, Claude, Gemini, Kimi, Qwen, Cursor, Copilot, Pi, OpenCode, and other AI coding agents项目地址: https://gitcode.com/gh_mirrors/cl/claude_codex_bridge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考