北京
第一次调用冒烟测试通过的时候，问题才刚刚开始。大多数检查都太乐观了：启动服务器，列出工具表，拿一组有效参数调一次，只要返回干净就认为集成能跑。这确实证明“可以连接成功”。但没法证明客户端能在预算内恢复、不会触发重复副作用、能拒绝恶意输出，也无法保证后续代码变更后行为不变。
可靠性的分界线就划在那次干净调用之后。
我维护的 ResiliReplay 正是为回答这道考题而建的——当一个 MCP 工具在“请求被接受”和“返回有用结果”之间失败，客户端真的准备好了吗？MCP Inspector 适合做交互式探索：发现工具、查看 schema、给参数、看真实返回。ResiliReplay 接受与 Inspector 同形的配置，但它不做那种交互工作，它的角色是盯着边界上的失控时刻。
为此它不是随机注入故障。一组有用的分析活动必须是可审核、可重现的：固定种子、显式场景、一个微型的工具许可列表、明确的超时与重试预算、声明式预期，以及落在本地的证据。如果要往某个工具发请求，ResiliReplay 会先打印一份规范的审计计划，并必须收到精确匹配的活动哈希之后才允许执行。
如果你有 Node.js 22 或 24，入口点从一次干跑开始：
npx --yes resilireplay@0.3.1 mcp audit \ --inspector-config ./mcp.json \ --server my-server \ --dry-run
这个阶段不会启动服务器，也不会进行任何工具调用。输出只告诉你可执行文件路径、参数列表、工作目录、传输方式、超时值以及环境变量名称。正因为什么都没做，它反而成了抓住错误目标或意外扩大配置的关键一步。
接着生成活动模板并做一次校验：
npx --yes resilireplay@0.3.1 campaign init reliability.campaign.yml
npx --yes resilireplay@0.3.1 campaign validate reliability.campaign.yml
在一个早期实地测试里，我把并发数卡在 1，只放行一个只读且幂等的工具，重试次数设为 1，并选用三个场景。
第一个
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
