软件工程 / 架构设计方法论知识图谱 / 分组目录 / 案例层 / MCP 四件套选型对比
X · P2 · active

MCP 四件套选型对比

Selection Benchmark of Four MCP Servers
P2进阶verified案例X · 跨域/其他质量属性技术债GC-CASE · 案例层

§1摘要与结论

TL;DR · 一句话结论

对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。

别名：MCP 四件套、MCP 服务器选型、token 预算选型　|　英文：Selection Benchmark of Four MCP Servers　|　类型：案例 / selection

§2局部关系图

MCP 四件套选型对比 的 1-2 跳邻域关系图前置依赖（prerequisite）：本质复杂度不可消除，故架构只能在约束下权衡前置依赖（prerequisite）：边界划分是对多重质量属性的权衡依据推导（derives_from）：SLO 目标选择体现架构即权衡依据推导（derives_from）：权衡决策方法依据架构即权衡的本质依据推导（derives_from）：风格选型本质是以约束换取期望属性依据推导（derives_from）：能力成本速度三角是权衡不可消除的实例依据推导（derives_from）：属性冲突治理依据架构即权衡的本质依据推导（derives_from）：属性冲突只能显式化与排序，无法消除依据推导（derives_from）：复杂度阶梯以降低认知复杂度为目标细化（refines）：复杂度阶梯是选型够用原则的时序细化依赖关联（dependency）：成本与质量冲突约束技术选型前置依赖（prerequisite）：成本量化是选型匹配的前置输入张力冲突（conflicts）：能力与质量提升同成本约束存在张力对照（contrasts）：静态选型与动态进阶是同一成本观的两面前置依赖（prerequisite）：本质复杂度不可消除支撑权衡不可消除依据推导（derives_from）：敏感点与权衡点分析是架构权衡判断的内核细化（refines）：效用树构造与敏感点识别细化 ATAM 评估流程的分析环节促成（enables）：敏感点与权衡点分析为架构风格选型提供判据案例印证（case_instance）：印证：去中心化与本地优先等主张皆为显式架构取舍案例印证（case_instance）：印证：以适配器与事件驱动组合出可扩展的架构风格案例印证（case_instance）：印证：零依赖零构建按约束选择刚好够用的技术案例印证（case_instance）：印证：以双通道与密钥隔离划清信任与能力边界案例印证（case_instance）：印证：以够用原则选择最小接入组合案例印证（case_instance）：印证：能力成本速度三角下的分级接入案例印证（case_instance）：印证：选型即权衡，无全能工具实现（implements）：Azure 风格目录指导架构风格选择实现（implements）：技术雷达采用环支撑技术选型够用原则对照（contrasts）：Azure 稳定工程清单对照雷达时效快照组合（combination）：风格目录与技术雷达组合用于技术选型案例印证（case_instance）：印证：带观点的分级接入推荐，与雷达四环同构组合（combination）：风格选择是架构权衡的典型对象依据推导（derives_from）：决策记录依架构即权衡，留存取舍与理由依据推导（derives_from）：ATAM 以架构权衡为根本前提依据推导（derives_from）：风格选择依质量属性权衡而非对错前置依赖（prerequisite）：识别敏感点与权衡点是记录架构决策的前提前置依赖（prerequisite）：质量属性场景与评估是风格权衡选型的前置分析组合（combination）：风格选型结果以 ADR 记录理由与被否决项MCP 四件套选型对比MCP 四件套选型对比（CAS-X-12）架构即权衡架构即权衡（ESS-O-02）技术选型的够用原则技术选型的够用原则（MTH-O-03）能力-成本-速度三角能力-成本-速度三角（MTH-O-04）ThoughtWorks…ThoughtWorks 技术雷达（TEC-G-04）边界与接口隔离边界与接口隔离（ESS-G-03）本质复杂度与偶然复杂度本质复杂度与偶然复杂度（ESS-O-01）权衡的不可消除性权衡的不可消除性（ESS-O-03）质量属性场景与ATAM质量属性场景与ATAM（MTH-G-02）架构风格选择方法架构风格选择方法（MTH-G-03）质量属性冲突治理质量属性冲突治理（MTH-O-05）效用树与敏感点权衡点分析效用树与敏感点权衡点分析（MTH-G-06）去中心化聊天架构逆向去中心化聊天架构逆向（CAS-X-01）网申填写扩展逆向架构网申填写扩展逆向架构（CAS-X-02）架构风格架构风格（ESS-G-05）架构决策记录架构决策记录（MTH-G-01）服务等级目标方法服务等级目标方法（MTH-K-01）复杂度阶梯与演进时机复杂度阶梯与演进时机（MTH-O-08）Azure 架构中心Azure 架构中心（TEC-G-03）质量属性权衡决策方法质量属性权衡决策方法（MTH-M-06）
前置依赖实现依据推导案例印证对比冲突
以本节点为中心，静态内联 1–2 跳邻域：内环 4 个直接邻接、外环 15 个二跳节点，共 20 个节点；连线按边类型着色（六类配色见下）。构建期计算，无运行期脚本。

§3原理 · 为什么

工具接入的稀缺资源不是磁盘或算力，而是每个 Agent 提示词里被工具定义长期占用的上下文预算。工具 schema 会注入每一个子Agent 的提示词，固定开销随工具数量放大，直接压缩有效工作窗口——这意味着「多接几个工具」的代价是全局的，而非局部的。因此选型不能只看「能力多强」，必须把常驻 token 成本、与既有能力的重叠度、以及是否真增量当作一等公民。核心判断标准从「它能不能做这件事」变成「为这件偶发的事，值不值得在每次调用里都支付固定成本」。这就是够用原则在工具生态里的具体形态：宁可少而精，不要多而全；每多一个常驻工具，都是对所有任务征税。把这项固定成本前置到选型阶段逐项称量，远比在运行中才发现有效窗口被悄然挤占、再回头精简既有能力要便宜，也更不容易引发团队对工具治理的抵触。把工具视为有租金的资产而非一次性安装的功能，选型的心态就会自然从「尽量多」转向「尽量省」。

§4机制 · 如何运作

方法分三阶段。第一，实测而非照搬文档：统计每个候选的真实工具数与常驻 token（有的候选实测工具数高于文档声称，有的候选虽有十余个工具但默认只启用两个），因为文档常滞后于代码，厂商口径也可能乐观。第二，构建多维对比：能力矩阵覆盖本地代码关系查询、库文档检索、百科、联网语义搜索、URL 抓取；部署形态区分本地建索引与远程托管；再标注数据外发与认证方式，把安全边界纳入选型。第三，做与内置工具的冲突分析——某个联网抓取工具与内置网页抓取重复、某代码图工具与探索子Agent 互补。据此给出分级方案：最小开销者首选，唯一真增量者追加，重且低频者默认禁用按需开启，已失效者直接剔除。整个对比过程要求每一步都保留数字与出处，使结论可被质疑、可被复核、也可在新版本下重跑，而不是停留在「感觉这个更轻」的模糊判断上。对于相互替代的候选项，对比表还给出「若移除谁、保留谁」的取舍顺序，使结论可直接转成行动。

§5工程 · 怎么落地

决策以「累计常驻 token 是否可接受」为硬阈值：基线约三千 token，接入后累计若逼近八千则判为过高。安全维度要求显式标注数据外发边界（哪些候选会把内容发往云端、哪个把图数据留在本地），避免为便利牺牲数据边界。接入策略区分常驻与按需两类：把「需要先建索引、调用频率低」的重能力降级为手动开启，避免为偶发需求支付持续成本；把「体积小、纯增量」的能力列为常驻。最终产出一张可直接执行的接入顺序表与回滚方案，而非一堆孤立评测，使决策可复现、可复核、可随版本更新。接入顺序表还标注了每一项的触发条件与移除方式，便于在需求消失或版本变化时随时回退，也预留观测手段用真实用量反哺下一轮评估。整个过程强调可复现：任何人按同一口径重测，都能得到相近的量级判断，而不必信任某个人的主观描述。

§6权衡卡

代价 · 风险

把重能力降级为按需虽省下常驻成本，却增加了使用时的心智负担与操作步骤，可能在实际任务中因「懒得开启」而失去价值。

原文要点
  • 对比结论有时效性：工具数、token 估算与限流政策会随版本漂移，star 数也不等于适配度。
  • token 估算依赖具体客户端如何注入 schema，与真实占用存在偏差；「唯一真增量」的判断建立在既有内置能力不变的前提上，一旦内置补齐语义搜索，该工具的增量即归零。
  • 本案例真正的产出是以稀缺资源为轴做选型的框架，具体数字必须按当时快照解读，不可当作长期结论；选型决策应随版本定期复核，并把「未接入」也视为一种有效决策。
  • 因此这类选型报告必须写清版本与日期，并把复核动作制度化，而不是当成一次性结论存档；更要接受「当前最优」随时可能变成「次优」。
  • 最后应把「暂不接入」也写成有理由的结论，避免下次讨论时重新从零争论一遍。

权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。

§7案例带

CAS-X-01 · 经 ESS-O-02

去中心化聊天架构逆向

对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。

CAS-X-02 · 2 跳派生：当前节点 → ESS-O-02 → ESS-G-05

网申填写扩展逆向架构

对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。

CAS-X-04 · 2 跳派生：当前节点 → MTH-O-04 → ESS-O-03

网申 v2 深度重构

一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。

CAS-X-05 · 2 跳派生：当前节点 → ESS-O-02 → ESS-G-03

preset 通道耦合分析

对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。

CAS-X-08 · 2 跳派生：当前节点 → ESS-O-02 → ESS-G-03

dsh-manager 插件深度分析

以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。

CAS-X-11 · 2 跳派生：当前节点 → ESS-O-02 → ESS-G-05

Hermes 七层架构总览

对八千余文件的工业级 AI Agent 项目做七层架构总览逆向，揭示其「越用越聪明」的自进化闭环如何在层间传导的控制型架构案例。

CAS-X-13 · 2 跳派生：当前节点 → ESS-O-02 → ESS-O-01

Claude Code 架构逆向

以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。

CAS-X-16 · 2 跳派生：当前节点 → ESS-O-02 → MTH-O-05

控制理论⊗Agent 设计

将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。

§8信源与核验

核验状态True（verified）
置信度medium
复核日期2026-09-10
生命周期active
规范信源LOC-031
勘误
常见误解：选 MCP 只需比较功能覆盖，工具越多越好
核验结论：工具 schema 会注入每个子Agent 的 prompt，常驻 token 与功能重叠才是关键约束；重且低频的能力宜按需开启，且结论具时效性　[LOC-031]

§9原始关系清单

展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
关系方向对端节点说明
案例印证→ ESS-O-02架构即权衡
E-977		印证：选型即权衡，无全能工具
案例印证→ MTH-O-03技术选型的够用原则
E-975		印证：以够用原则选择最小接入组合
案例印证→ MTH-O-04能力-成本-速度三角
E-976		印证：能力成本速度三角下的分级接入
案例印证→ TEC-G-04ThoughtWorks 技术雷达
E-17		印证：带观点的分级接入推荐，与雷达四环同构