你有没有遇到过这种情况MCP Server的架构选型直接决定了LLM调用工具的准确率——工具数量超过10个Haiku 4.5的选型准确率就从91%跌到87%。这来自arXiv:2606.30317论文的实测数据作者对15个生产级MCP Server做了模式编码识别出5种正模式和4个反模式。今天咱们就拆开这套框架帮你快速判断自己的场景该用哪种模式。为什么需要架构模式MCP Server本质是LLM和外部工具之间的适配层。传统设计模式面对人类开发者——人会读文档、理解接口。但LLM只能靠自然语言描述来选工具工具列表越长、描述越模糊选错概率越高。论文通过两阶段编码对15个Server做了分析用54个held-out服务器验证Cohen’s kappa 0.76归纳出5种架构模式和4个反模式。5种正模式1. Resource Gateway资源网关古典祖先Repository Pattern场景暴露后端数据库/API为Resources 参数化查询为Tools关键点必须加sanitization层防prompt injection示例一个Postgres MCP Server把SELECT * FROM users WHERE id ?包装成ToolLLM调用时传入参数。论文特别强调任何带参数的Tool都要做输入验证。推荐场景需要暴露已有数据给Agent且数据量稳定20个资源。2. Tool Orchestrator工具编排器古典祖先Facade Pattern场景把跨系统的多步工作流封装成一个复合Tool子调用在Server内部完成。收益减少LLM的决策负担——它只需要调用一个“下单”ToolServer内部自动协调库存、支付、物流。论文中的一个案例ANSYR的订单处理Server暴露了create_order和cancel_order两个复合Tool每个Tool内部涉及7个微服务调用。// 工具编排器伪代码复合Tool屏蔽底层复杂度server.setRequestHandler(call_tool,async(req){if(req.params.namecreate_order){const{items,address,payment}req.params.arguments;constinventoryawaitcheckInventory(items);// 子调用1constpaymentOkawaitprocessPayment(payment);// 子调用2constorderawaitcreateOrder(items,address);// 子调用3consttrackingawaitdispatchLogistics(order);// 子调用4return{content:[{text:订单${order.id}已创建}]};}});如果拆成20个细粒度ToolLLM的选型准确率会显著下降。推荐场景业务流程确定且步骤固定的场景电商下单、审批流。3. Stateful Session Server有状态会话古典祖先Session Pattern场景用一个Session ID维护多轮对话的状态Server端持有per-session上下文。关键区别传统MCP Server是无状态的每次Tool调用都是独立事务。有状态Server允许LLM跨轮次共享数据。论文警告状态管理必须设定超时和清理策略。推荐场景需要多步推理的Agent如“帮我写一篇报告先查资料再格式化”。4. Proxy Aggregator代理聚合器古典祖先Proxy Pattern场景用一个中心Server聚合多个上游MCP Server通过namespace区分。问题如果简单把所有上游的工具都暴露到同一列表总工具数很快膨胀到50。论文推荐scoped变体只暴露当前任务相关的预筛选子集LLM工具数控制在10-15个以内。// 代理聚合器伪代码映射命名空间 → 路由到上游constupstreams{file:fileServer,git:gitServer,slack:slackServer};server.setRequestHandler(list_tools,async(){// scoped变体只暴露当前任务相关的namespaceconstscopedawaitgetScopeForCurrentTask();consttoolsawaitPromise.all(scoped.map(nsupstreams[ns].client.listTools()));return{tools:tools.flat()};});推荐场景已有多个独立MCP Server需要统一入口且工具数可控。5. Domain-Specific Adapter领域适配器古典祖先Adapter Pattern场景将复杂底层API适配为LLM友好的接口做三层转换描述翻译把API文档译成自然语言理解友好的描述、参数归一化底层参数名映射为语义明确的参数名、错误翻译底层错误码转为故障原因与修复建议。推荐场景对接复杂第三方API云服务、金融数据、医疗系统。4个反模式论文还识别出4种应该避免的反模式The God Tool万能工具一个工具接受do_anything这种无差别schemaLLM得自己去猜action。修复拆分——每个操作给独立的名字和schema。Unsanitized Resource Content未净化的资源内容用户生成内容不净化直接返回。一段「忽略之前的指令」的文本会被LLM当作指令而非数据。所有外部内容进MCP前要做sanitize。Synchronous Long-Running Operations同步长任务视频编码等长耗时操作做成同步工具客户端超时。正确做法返回job ID 单独暴露poll_job(id)工具。Missing or Vague Tool Descriptions缺失/模糊的工具描述工具取名send_message却不写描述。LLM靠读描述选工具描述要写清「干什么、什么时候用、返回什么」。工具数量红线10-15个是临界点论文的核心数据来自ANSYR生产环境每桶N200模型10个工具15个20个30个Haiku 4.591%87%82%74%Sonnet 494%92%90%85%结论Haiku 4.5在10-15个工具时跌破90%Sonnet 4能撑到20-30个。MCP Server设计时每个上下文里的工具数控制在10-15个以内超过即分层。总结选型框架论文给出的决策树简洁实用数据量小且无状态 - Resource Gateway跨系统多步流程 - Tool Orchestrator多轮对话需要保留上下文 - Stateful Session Server多个Server需统一入口 - Proxy Aggregatorscoped变体对接遗留复杂API - Domain-Specific Adapter任何情况下工具数控制在10-15以内超过即分层最后再说一句不是工具越多越好是LLM替你管得越少越好——把决策负担从模型转移到架构上才是生产级Agent系统的精髓。论文自己也承认语料只有15个Server更大的MCP生态可能有更多模式。但10-15个工具就是Haiku的准确率分水岭这个数据不会因为Server变多而改变。论文地址https://arxiv.org/abs/2606.30317