三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

多 MCP Server 协同实战：从信息采集到内容发布的全自动工具链

发布时间：2026/8/15 4:26:17 三亩地 编程学习日记
多 MCP Server 协同实战：从信息采集到内容发布的全自动工具链

  • 多 MCP Server 协同实战：从信息采集到内容发布的全自动工具链

    • 核心痛点：单个 MCP Server 只能解决一个环节，而真实任务（搜索 -> 抓取 -> 写作 -> 发布）是一条多环节流水线——如何让多个 Server 像工厂流水线一样协同，同时不被暴涨的工具 schema 吃掉整个上下文窗口
    • 适配人群：AI/ML 工程师、已接入 MCP 但遭遇「工具越来越多、上下文越来越挤、调用越来越慢」的进阶开发者、正在把零散 MCP 工具组装成端到端自动化流水线的技术团队
    • 收获能力：掌握多 MCP Server 协同的完整架构（数据流转管道、错误处理边界、权限隔离），吃透 Tool Search 按需加载的 Token 经济学原理，理解 MCP Resource 目录/文件读取机制，并落地一条「搜索 -> 抓取 -> 撰写 -> 发布」的全自动工具链

    • 技术背景与演进逻辑

      • 从「装一个工具」到「编排一条流水线」的必然跃迁
        • 上一篇解决了「为 Claude Code 装上一个外部工具」的问题 -> 单 Server 单工具，模型决定何时调用、传什么参数
        • 但真实世界的任务从来不是单步的 -> 写一篇文章要搜索、要抓取、要写作、要发布、要记录 -> 每一步背后可能都是不同的工具
        • 于是问题从「工具怎么接」升级为「工具怎么编排」-> 这正是本篇要回答的核心命题：多 MCP Server 如何像工厂流水线一样协同工作
      • 单 Server 架构的四个瓶颈
        • 瓶颈一：能力割裂 -> 搜索 Server 不认识发布 Server，数据必须由模型手动搬运 -> 模型成了「人肉管道」
        • 瓶颈二：上下文膨胀 -> 每接入一个 Server，它的工具 schema 就全量注入上下文 -> 十个 Server 轻松吃掉几十万 Token（见下文的 Tool Search 原理）
        • 瓶颈三：错误传染 -> 上游抓取失败，下游发布是否继续？模型需要一套明确的失败语义
        • 瓶颈四：权限失控 -> 读工具和写工具混在一起，敏感操作难以单独管控
      • 业界的两条解路线
        • 硬编码编排路线：把「搜索 -> 抓取 -> 发布」写成固定脚本，每步调用哪个 Server、传什么参数全部写死
          • 优势：确定性强、可审计、性能高
          • 劣势：失去模型的决策能力，任何需求变化都要改代码，无法处理异常分支
        • 模型调度路线（Claude Code 的选择）：把多个 Server 的 Tool 全部交给模型，由模型在每一步自主决定「下一步该调谁、传什么」
          • 优势：灵活，模型能处理脚本没预见到的分支
          • 劣势：上下文膨胀、调用不确定性、需要额外的权限与失败语义约束
        • 关键洞察：Claude Code 走的不是纯模型调度，而是「模型调度 + 工程约束」的混合路线 -> 用 Tool Search 解决上下文膨胀，用权限模型解决失控，用错误语义解决传染 -> 这也是本篇的完整主线
      • 演进时间线：工具链成熟的关键节点
        MCP 工具链演进时间线 ├── 2024-11 -> MCP 协议发布：单 Server 单工具接入 ├── 2025-01 -> 多 Server 协同成为常态：但工具 schema 全量加载 ├── 2025-06 -> 工具膨胀问题爆发：134K Token 被工具定义吃掉 ├── 2025-11 -> Tool Search Tool 进入 beta：按需发现工具（defer_loading） ├── 2026-Q1 -> Claude Code 2.1.7 引入 MCP Tool Search：懒加载默认开启 ├── 2026-Q2 -> serverInstructions 字段强化：Server 作者可引导搜索触发 └── 2026-08 -> Claude Code 2.1.231：Tool Search 默认启用 + MCP OAuth 修复
      • 总结：多 MCP 协同的核心价值不在于「多装几个工具」-> 而在于把「模型的决策能力」与「工具的确定性执行」用一条可治理的数据管道连接起来 -> 这条管道由四根柱子支撑：数据流转、按需加载、错误边界、权限隔离

    • 核心原理深度解析

      • 多 Server 协同的架构全景：Host 聚合下的多 Client

        • 回顾三层架构，聚焦「多个」这个关键变化
          多 MCP Server 协同架构 ├── Host（Claude Code CLI） │ ├── 职责：聚合所有 Server 的 Client，向模型注入工具集 │ └── 关键点：一个 Host 可以同时持有 N 个 Client │ ├── Client 层（1 个 Server 对应 1 个 Client） │ ├── Client-A -> 连接 search MCP（远程 HTTP） │ ├── Client-B -> 连接 firecrawl MCP（远程 HTTP） │ ├── Client-C -> 连接 csdn MCP（本地 stdio） │ └── Client-D -> 连接 weibo MCP（本地 stdio） │ └── Server 层（各自独立进程或远程端点） ├── search Server -> web_search / news_search 工具 ├── firecrawl Server -> scrape / crawl / map 工具 ├── csdn Server -> publish_csdn_article 工具 └── weibo Server -> publish_weibo 工具
        • 本地 stdio 与远程 HTTP 的混合部署
          • 本项目的实际配置里，search 和 firecrawl 是远程 HTTP MCP，csdn 和 weibo 是本地 stdio MCP
          • 远程 HTTP Server 通过 Streamable HTTP 连接 -> 跨网络、可 OAuth 鉴权、可部署在网关后
          • 本地 stdio Server 通过子进程连接 -> 零网络开销、天然进程隔离、能访问本机浏览器
          • 混合部署的意义：读操作（搜索、抓取）放在远程，写操作（发布）留在本地 -> 数据采集分布式、副作用收敛本地
        • 模型如何「看见」这么多工具
          • 传统模式：所有 Server 的 Tool 列表在会话启动时被汇总 -> 一次性注入到模型的工具定义中
          • Tool Search 模式：只注入「工具名称 + Server 指令」的轻量索引 -> 模型按需搜索并展开具体 schema
          • 两种模式的差异，是理解后文 Token 经济学的前提

      • 数据流转管道：上游输出作为下游输入的编排设计

        • 管道的本质是一条「语义链」
          CSDN 发布流水线的数据流转 ├── 阶段一：搜索（search MCP） │ ├── 输入：选题方向（如「多 MCP 协同」） │ ├── 工具：web_search / news_search │ └── 输出：标题 + URL + 描述列表 │ ├── 阶段二：抓取（firecrawl MCP） │ ├── 输入：阶段一输出的 URL │ ├── 工具：firecrawl_scrape / firecrawl_crawl │ └── 输出：网页正文 Markdown │ ├── 阶段三：写作（模型内部） │ ├── 输入：阶段二输出的正文素材 │ ├── 处理：标题归树 + 模块择形 + LaTeX 安全 │ └── 输出：本地 Markdown 文件 │ ├── 阶段四：校验（Bash Grep） │ ├── 输入：阶段三输出的本地文件 │ ├── 工具：Grep 扫描禁止 LaTeX 命令 │ └── 输出：通过 / 失败判定 │ ├── 阶段五：发布（csdn MCP） │ ├── 输入：标题 + 正文 + 标签 + 可见性 │ ├── 工具：publish_csdn_article │ └── 输出：文章链接 │ └── 阶段六：记录（文件写入） ├── 输入：发布结果 ├── 处理：追加到 history JSON └── 输出：历史记录更新完成
        • 三个关键设计原则
          • 原则一：管道不是硬编码的 -> 模型在每一步自主决定「调谁、传什么」-> 阶段之间的连接是「语义兼容」（上游输出类型匹配下游输入类型），而非代码写死的调用
          • 原则二：中间产物落盘 -> 阶段三的写作产物先写成本地文件，而非直接塞进发布调用 -> 这给阶段四的校验提供了可检查的对象
          • 原则三：副作用集中在管道末端 -> 搜索、抓取都是幂等读操作，发布是唯一有副作用的写操作 -> 放在最后，且失败后不自动重试
        • 模型在管道中的角色是「调度器」而非「执行器」
          • 模型决定「现在该搜索了」-> 调用 web_search
          • 模型决定「这条结果值得深读」-> 调用 firecrawl_scrape
          • 模型决定「写好了，可以发布」-> 调用 publish_csdn_article
          • 真正的执行（跑搜索引擎、开浏览器填表单）全部由 Server 完成 -> 模型只做决策

      • Tool Search 按需加载：多 Server 时代的 Token 经济学

        • 问题：工具 schema 是隐形的上下文杀手
          工具定义吃掉上下文的真实数据 ├── 单个 MCP 工具的 schema 约 500-850 Token │ ├── 包含：name + description + inputSchema（JSON Schema 定义） │ └── 一个功能丰富的 Server 可能有 30-70 个工具 │ ├── 多 Server 场景的放大效应 │ ├── 5 个 Server、58 个工具
编程学习 学习日记 实战经验
← 返回列表