作者最初质疑 MCP 与 CLI 哪个更便宜，但发现这是一个错误的问题。真正的问题在于：在实践中哪些架构元素能够存活。初步分析显示，MCP 每次调用的 token 成本显著低于原始 CLI，但对于大型单体应用，其模式（schema）开销却高得惊人。关键洞察在于浪费性的模式注入，这一问题可通过网关按实际使用情况过滤模式来解决。作者认识到，与插件不同，MCP 服务器具有生命周期独立性，能够自行恢复状态。这一认识使他明白：服务器在客户端终止后依然存活，而插件则继承其父进程的生命周期。容器化成为针对特定环境配置的成本效益解决方案，提供单一镜像，可在各种客户端上部署，无需为每个目标单独配置。漫长的拉取请求（pull request）生命周期凸显了为架构决策制定决策树的重要性，进而使人意识到 MCP 服务器的存活独立于其客户端。原有的包含 93 个工具的单体架构、针对 WSL 的逐台安装脚本以及特定的 git-push MCP 工具被弃用。作者得出结论：架构决策必须尽早做出，且应从失败中快速学习。修订后的策略优先采用 MCP 构建结构（使用类型化模式），并采用 CLI 执行低开销操作。倾向于工具数量有限的专注式服务器，以实现独立部署。容器现已成为默认部署方式，确保跨客户端的一致性技术栈。存活的架构包括：用于生命周期管理的 MCP 网关、用于执行的 CLI 桥接，以及多个专注式的 MCP 服务器。