15个MCP服务器同时崩溃那晚，我悟了1个反常识道理

60多个Cloudflare Workers，9个微服务，15个MCP服务器同时在线——这不是在炫耀架构复杂度，是在描述一场持续数月的救火现场。作者用这套系统跑了生产环境后，发现一个被所有人忽略的真相：写MCP服务器简单到像写个脚本，但让15个服务器乖乖协作，才是真正的工程地狱。

单点故障的连锁反应，比代码bug更难缠

任何人都能200行代码撸一个MCP服务器。child_process.exec()，解析输出，返回JSON，完事。但生产环境从不按剧本走：7号服务器超时，3号服务器正等着它的输出，12号服务器被限流，用户还在屏幕前干瞪眼。

作者团队被迫造了一个"协调守护进程"，每30秒扫一遍所有服务的健康状态。故障发生时，系统不会傻乎乎重试，而是启动降级链——主节点挂了切备用，备用也挂了就优雅降级，同时告诉用户发生了什么。这套"无聊的管道工程"，正是demo和 Production 系统的分水岭。

每个MCP服务器都是攻击面，他们造了道"宪法之门"

15个服务器意味着15个潜在突破口。作者见过各种攻击模式，最终祭出一个偏执方案："宪法之门"（Constitution Gate）。这是一层双LLM验证架构，每个输入都要过两道AI安检才能触及工具层。

听起来过度防御？但至少到现在，系统还没被攻破。

模型不重要，路由逻辑才重要

团队在Groq、Cerebras、本地Ollama和Claude之间动态切换。同一个prompt，根据任务类型、延迟要求、成本预算，走不同通道。作者的原话很扎心：「模型本身没大家想的那么重要，重要的是路由逻辑、降级链、预算治理——防止死循环一夜烧光API额度。」

三层记忆架构让错误率砍了40%

他们堆了三层记忆系统：短期对话上下文、中期任务历史、长期跨会话知识库。新任务进来时，编排器先查记忆："类似的事以前干过吗？什么方案成功了？什么踩坑了？"就这一个设计，错误率直降约40%。

最可靠的系统，知道什么时候该闭嘴

作者埋了个"死人开关"：协调器60分钟没心跳，自动报警。但反过来的逻辑更反直觉——系统不需要时刻忙个不停。那些最稳的架构，往往擅长安静等待。

这些发现没有一条是革命性的。它们只是当你真的把15个MCP服务器塞进生产环境、而不是在博客里demo一个时，被迫学会的无聊常识。

作者最后留了个钩子：如果你也在搞多服务器协调，特别想听听你踩过什么坑——毕竟大家似乎都在独立造同一批轮子。