人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载当测试“时好时坏”、每次跑挂的测试都不同、单独跑全绿、只在 CI 上失败时请不要盲目进入假设循环。间歇性本身就是一个证据。本篇基于 oh-my-openagent 仓库中 debugging 技能 的排障方法论references/methodology/03-flaky-triage.md完整讲解四步 flaky triage 流程捕获失败特征签名、解读签名、并发运行争用检查清单与修复策略。读完你将对“随机失败的测试”拥有可复现、可分类、可修复的系统化处置能力并能结合本仓库的测试隔离实践如 script/root-test-serial-quarantine.ts理解真实工程中的落地形态。前置认知间歇性本身就是证据典型的 flaky 信号包括失败并非每次运行都复现“偶尔失败”每次运行挂掉的测试都不一样“每次挂不同的测试”单独运行某个测试能通过“孤立运行通过”只在 CI 上失败本地永远通过。面对这类信号不要盲目进入假设循环。03-flaky-triage.md开篇就强调“间歇性本身就是证据”intermittence itself is evidence。正确的做法是在进入 Phase 2假设形成之前先用下面的四步流程做一次 triage——通常一轮就能把搜索空间大幅收窄。在整个 debugging 技能中这份文档属于跨阶段的方法论文档其调用时机在 SKILL.md 中有明确说明当失败是间歇性的必须在进入 Phase 2 之前阅读本方法失败特征签名通常能在一轮内收窄搜索空间。Step 1 — 捕获失败特征签名三次廉价重跑在形成任何假设之前先做以下重跑实验并逐条记录journal每次结果。任何一次重跑都不该花掉昂贵的调试时间——这正是“廉价重跑”的含义。重跑方式命令形态回答的问题相同范围、相同命令与刚才失败时完全相同的命令同一个测试会再次失败还是换了一个不同的测试失败测试孤立运行单个文件 / 测试过滤器单独跑它能否通过安静机器上跑全量先停掉并发构建、其他测试套件、后台 Agent当没有其他东西在跑时整个套件是否全绿当怀疑顺序时乱序运行-shuffleon/pytest-randomly/ runner 的随机种子特定的执行顺序能否复现失败记录种子值。要点每条结果都要 journal。本仓库 debugging 技能在 Phase 1 要求建立单一 journal.debug-journal.md规则是“先记录再修改”journal-then-modify详见 references/methodology/00-setup.md。乱序运行时务必保存随机种子——它是后续二分定位测试顺序依赖的关键依据。Step 2 — 解读签名将 Step 1 捕获到的特征与下表对照直接映射到“主导假设 下一步动作”。失败特征签名主导假设下一步动作同一个测试在任何地方都间歇失败被测代码里的真实竞态race或异步测试缺陷固定 sleep、未 await 的 promise、轮询等待时间进入标准阶段循环见 02-investigate.md通过订阅完成事件或注入时钟来确定性复现每次运行挂的是不同测试/文件每个单独跑都能过安静机器上全绿并发运行之间的环境争用——不是代码问题执行 Step 3 检查清单总是同一个测试但只在全量套件中失败孤立运行通过测试顺序依赖 / fixture 泄漏未重置的模块状态、泄漏的环境变量、共享单例用记录的乱序种子做二分找到泄漏的测试修复其 teardown只在 CI 上失败本地从不失败资源上限磁盘/CPU 更慢 → 超时、不同的并行度默认值、容器时钟在受约束条件下本地复现taskset、降低--maxWorkers提高信号而不是提高 sleep同一 commit 的普通重跑就变绿它仍然是一个 flake——在忽略它之前先按此表分类一个未分类的 flake 就是一份隐藏的 bug 报告回到 Step 1并坚持 journaling这张表的核心价值在于先分类、后处置不同的签名指向完全不同的修复方向。尤其是“不同测试轮流失败 孤立通过 安静机器全绿”这个组合直接指向环境争用而不是被测代码——这是最常见的现代 flaky 根因。Step 3 — 并发运行争用检查清单文档明确指出两个同一仓库的 checkout 或 worktree——或一个 checkout 加上一个后台 Agent——在同一时刻运行测试套件并共享某个全局可变资源这是现代最常见的 flaky 成因。多 Agent 工作站让这种模式成为默认失败模式而不是罕见异常。逐项检查以下共享资源共享 tmp 根目录沙箱/缓存目录基于固定的 tmpdir 路径派生如$TMPDIR/project-fixed-name而不是每次运行用mktemp生成独立目录。两轮运行读写同一棵树输家会看到“被删除了一半”的状态。固定端口测试服务器中硬编码的监听端口。两套测试套件竞争绑定输家在运行中途随机遇到 404 / ECONNREFUSED——正好挂在当时正在运行的那个文件上。全局 env / 配置变更测试写入了进程外部状态dotfiles、共享配置、全局 env另一轮运行会读到。共享容器 / 数据库同名容器、同 schema、同 volume。缓存与锁包管理器缓存、lockfile、.git索引争用。失败窗口期的现场取证在争用“活着”的时候捕获证据而不是事后推断lsof -i :port—— 在失败窗口期查看端口被谁占用列出共享 tmp 路径下的文件——看是否存在两轮运行互相覆盖的痕迹进程列表——确认确实存在并发 runner。仓库中的真实印证本仓库在根测试套件层面已经把“并发运行会互相干扰”当作一等公民来治理是这份检查清单的工程化样本script/root-test-serial-quarantine.ts 维护了一个串行隔离清单那些因为“共享安装根目录”“共享 plugin 构建输入”“独占 console 句柄”“对文件系统负载敏感”等原因不能与其他测试共享进程池的测试文件必须在并行腿之前串行跑完。比如packages/omo-codex/src/install/install-codex-legacy-agent-purge.test.ts会“从共享安装根目录清除旧 Agent 状态”packages/omo-native/test/payload.test.ts会“修改共享 plugin 构建输入”——这正对应 Step 3 清单里的“共享容器 / 缓存与锁 / 共享状态”类别。script/ci-root-test-partition.test.ts 用契约测试把这一治理钉死它断言 CI workflow 中的串行命令与隔离清单完全一致、bunfig 的pathIgnorePatterns恰好忽略这些文件、POSIX 与 Windows 分片顺序正确。script/test-environment-isolation.test.ts 则对应“全局 env 变更”类别它验证宿主机的OPENCODE_SERVER_PASSWORD凭据不会被测试继承。也就是说本仓库把“两套 suite 并发互不干扰”从口头约定变成了代码与 CI 契约——这正是 Step 4 中“验收标准”的落地实现。Step 4 — 修复策略按分类修复环境争用→ 修复测试基础设施永远不要去修单个测试把每个 suite 全局资源按运行隔离——mktemp生成根目录、端口用0/临时分配ephemeral allocation、容器名唯一。验收标准是同一仓库的两个 checkout 并发跑测试套件互不干扰programming 技能的测试隔离规则拥有这条标准的解释权。顺序依赖→ 用记录的乱序种子找到泄漏的 fixture在 teardown 中重置反复乱序重跑直到该种子类完全干净。真实竞态→ 走正常阶段循环自 02-investigate.md 起修复必须随附一个能确定性复现该 bug 的失败优先测试failing-first test遵循 06-fix.md 的 TDD 纪律先红后绿最小改动全量回归通过才算修复完成。无论原因如何都禁止的做法以下手段一律禁止因为它们都是在埋葬 bug 报告给测试包 retry 包装器.retry(N)放大 sleepquarantine隔离/跳过该测试直接删除该测试。分类而未修复 必须上报的发现一个你已分类但未修复的 flake是要上报的发现finding而不是要隐藏的东西把签名、证据和分类都 journal 下来并在最终报告中明确写出。实战速查一次完整 triage 走查假设你在 CI 上看到“每次跑挂的测试都不同本地全绿”。按本文流程Step 1安静机器上停掉所有并发构建与后台 Agent重跑全量 → 全绿。再乱序重跑一次并记录种子 → 挂的还是不同的测试。Step 2对照表格 → 命中“不同测试/文件轮流失败 孤立通过 安静机器全绿” → 主导假设是环境争用而不是被测代码。Step 3按清单排查——lsof -i :port发现两个 suite 抢同一个固定端口共享 tmp 目录被两轮运行同时读写。Step 4修复基础设施——端口改0临时分配tmp 目录改用mktemp容器名加运行唯一后缀随后跑两次并发 suite 验证互不干扰并把验证结果 journal 进.debug-journal.md最终报告中如实记录。这套流程的价值在于在进入昂贵且盲目的假设循环之前先让失败签名自己说话——大多数 flaky 问题在这一轮就能定性并且修复方向几乎不会跑偏。总结间歇性失败不是“偶尔抽风”而是信息量极高的信号。oh-my-openagent 的 debugging 方法论把这一信号系统化为可执行的四步流程捕获签名 → 解读签名 → 检查并发争用 → 按分类修复。其中“并发运行之间的环境争用”是当代多 Agent / 多 worktree 工作方式下的默认假设本仓库的 root-test-serial-quarantine.ts 与 ci-root-test-partition.test.ts 就是这一思想在生产级仓库中的真实落地。遵循“修复基础设施而非单个测试”“失败优先测试锁定修复”“分类未修复必须上报”三条铁律你就能把最让人头疼的 flaky 测试问题变成可复现、可分类、可收敛的确定性工程问题。赞分享人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载相关推荐oh-my-claudecode 调试基准实战定位 Kubernetes 滚动发布后 Redis ECONNREFUSED 间歇性故障oh my claudecode 调试基准实战定位 Kubernetes 滚动发布后 Redis ECONNREFUSED 间歇性故障 本篇以 oh my c人工智能AI Agent多智能体Agent 编排Agent 工作流AI 技能CLI开发工具oh-my-openagent 中 ast-grepsg的安装完全指南一键脚本、多平台命令与故障排查oh my openagent 中 ast grepsg的安装完全指南一键脚本、多平台命令与故障排查 本文以 oh my openagent 仓库内 as人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排VS Code Flaky Smoke Tests 流水线出现间歇性失败时如何排查VS Code Flaky Smoke Tests 流水线出现间歇性失败时如何排查 VS Code 仓库里有一条专门的 Flaky Smoke Tests 流水开发工具代码编辑器上一篇Visual Studio Code 主题配置完全指南下一篇严格模式启用指南用h2spec的--strict选项提升HTTP/2实现质量创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考