通过“MCP管理子智能体+skills”架构，将所有MCP工具调用隔离在主上下文之外，实现主Agent上下文零膨胀，即使接入80个MCP服务器也毫不卡顿。
以下是作者自述：
最近，Anthropic 发布了一篇关于“代码执行与MCP（Model Context Protocol）”的技术文章，看完之后我脑子里“啪”地一下闪出一个绝妙的点子。这个点子说起来其实特别简单，但它能从根本上解决一个困扰所有使用 Claude 工具链开发者的痛点：主上下文膨胀问题。
你可能早就注意到了，每次调用一个 MCP 工具——比如 Chrome DevTools MCP、Playwright MCP 这类——都会把一大堆工具描述、API schema、初始化代码全塞进主 Agent 的上下文里，一不小心就吃掉几千甚至上万个 token，搞得整个对话又慢又贵，还容易触发上下文长度限制。
更别说你现在可能已经接入了三四十个 MCP 服务，甚至更多！要是你像我一样，想一口气跑 80 个 MCP 服务器，那主上下文早就炸了。
但你有没有想过，既然子智能体（subagents）拥有自己独立的上下文窗口，为什么不让它们来扛这个重担？为什么不让 MCP 的加载、管理、调用全部在子智能体内部完成，而主智能体只负责下达指令、接收结果？
这个思路一出来，我就立刻动手验证——结果，大成功！下面我就用最接地气的方式，把整个方案拆给你看，保证你看完也能复刻，甚至还能优化得比我更好。具体项目点击标题！
第一大节：为什么MCP让主上下文“水土不服”？根源在于“一次性全加载”设计
要理解我这个方案的突破性，你得先明白当前 MCP 架构的运行逻辑。在 Anthropic 目前的实现里，只要你启用一个 MCP 工具，它就会把该工具的所有元信息——包括工具名称、参数说明、调用方式、甚至可能的错误码和示例——全部提前加载到主 Agent 的上下文中。这在只用一两个工具时问题不大，但当你试图构建一个真正工业级的自动化系统时，比如集成 GitHub、Slack、浏览器、数据库、CI/CD、监控平台等几十个外部系统，每个系统背后又可能挂多个 MCP 服务，那上下文的消耗就会呈指数级增长。
举个真实例子：我测试过 Playwright MCP，光是初始化描述就占了 2300 多个 token。Chrome DevTools MCP 更夸张，直接干到 3500+。如果你同时启用 20 个类似级别的工具，光工具描述就吃掉 7 万个 token——这还没算你实际任务的 prompt 和历史对话！而 Claude 3.5 Sonnet 的上下文窗口也就 20 万左右，留给真正业务逻辑的空间已经所剩无几。
更糟糕的是，这些工具描述大部分时候根本用不上。你可能今天只查个数据库，明天才操作浏览器，但系统却强迫你在一开始就加载所有工具的“说明书”。这就像是让你去超市买瓶酱油，结果超市要求你必须先背下整本商品目录才能进门——荒谬至极！
Anthropic 虽然提到了“Agent Skills”这个概念，说它能通过虚拟机环境和文件系统实现“渐进式披露”（progressive disclosure），理论上只在需要时加载信息。但现实是，只要你把 .mcp.json 放在主工作目录下，Claude 就会默认读取并塞进上下文。所以问题不在理念，而在默认实现方式。
第二大节：我的核心解法——“MCP管理子智能体 + MCP管理skills技能”双层隔离架构
既然问题出在“主上下文被迫加载所有MCP元数据”，那解决方案就很自然了：把 .mcp.json 文件从主工作目录移走，放到一个只有子智能体才能访问的专属目录里。然后，专门创建一个叫 “mcp-manager” 的子智能体，它唯一的任务就是管理所有 MCP 工具的生命周期。
具体怎么实现？分两步走：
第一步，我创建了一个叫 “mcp-management” 的技能包（Skill）。这个技能包本质上就是一个文件夹，里面包含一段 Python 脚本，它的唯一功能就是读取 .claude/.mcp.json 文件（注意，这个路径已经不在主上下文可见范围内），然后动态初始化所有注册的 MCP 客户端。这个脚本会遍历 JSON 中定义的每个服务，建立连接，并生成一份“可用工具清单”，包括每个工具的名称、描述、参数格式等——但这些信息只存在于子智能体的内存和上下文中，主 Agent 完全看不见。
第二步，我把这个 “mcp-management” 技能绑定给 “mcp-manager” 子智能体。每当主 Agent 需要调用某个外部工具时，它不会直接去查工具列表，而是发出一条指令：“嘿，mcp-manager，我需要执行一个操作：查一下 GitHub 上某个仓库最近的 commit”。于是系统会临时召唤 mcp-manager 子智能体，激活它的 mcp-management 技能，加载所有 MCP 服务，然后让它自己判断：“哦，这个任务应该用 GitHub MCP 来处理”。接着，子智能体调用对应工具，拿到结果，再把干净的结果数据（比如 commit hash、作者、时间）返回给主 Agent。
整个过程，主上下文从头到尾只看到一条指令和一条结果，中间所有的工具描述、API schema、连接细节、错误处理逻辑，全部被封装在子智能体内部。哪怕你接入了 80 个 MCP 服务器，主上下文依然像刚洗完澡一样清爽干净。这就是我所说的“主上下文零污染”架构。
第三大节：进阶优化——当子智能体也扛不住时，引入外部 CLI 协同处理
当然，理想很丰满，现实有点骨感。在实际测试中我发现，虽然主上下文干净了，但子智能体自己也开始“喘不过气”——当你一次性加载 80 个 MCP 工具的元数据时，哪怕是在子智能体里，也会迅速消耗数万个 token。特别是在工具描述特别冗长（比如某些企业级 API 文档动辄上千字）的情况下，子智能体很容易在“选工具”这个阶段就撞上 token 上限。
怎么办？我的解决方案可能有点“野路子”，但极其有效：把工具元数据的解析和筛选工作，外包给外部命令行工具。我直接写了个脚本，用 gemini-cli（对，就是谷歌那个 Gemini 的命令行接口）来预处理所有 MCP 工具的描述，提取关键信息，生成一个轻量级的工具索引表。这个索引表只包含工具名、核心功能关键词、适用场景等元标签，体积压缩到原始描述的 1/10 以下。
然后，mcp-manager 子智能体不再直接读取原始 .mcp.json，而是读取这个由 gemini-cli 生成的精简索引。当它需要调用某个工具时，再根据索引定位到原始配置，动态加载该工具的完整客户端——但只加载这一个，而不是全部。这样一来，子智能体的上下文压力骤降，token 消耗控制在 2000 以内，稳得一批。
我知道你会说：“这不就依赖谷歌了吗？”别急，重点不是 gemini-cli，而是这个“外部预处理 + 按需加载”的思想。你完全可以换成 Claude 自己的 CLI，或者本地的 LLM 微服务，甚至一个简单的 TF-IDF 关键词提取器。核心逻辑是：不要让大模型一次性处理所有元数据，而是先用轻量工具做一轮过滤，再让大模型做精细决策。Anthropic 如果真的把这套机制内置到官方框架里，完全可以用自己的模型做预处理，根本不需要外部依赖。
第四大节：为什么这个架构是未来 Agent 系统的标配？
你可能会觉得这只是一个“小技巧”，但我想告诉你，这背后其实是下一代智能体架构的必然方向。传统的“单体 Agent + 全局上下文”模式，在复杂任务面前已经力不从心。真正的工业级自动化系统，必须具备模块化、隔离化、可扩展的能力。而子智能体 + 技能（Skills）的组合，正是实现这一点的最佳实践。
Anthropic 提出的“Agent Skills”概念其实已经指明了方向——它强调“技能是为新员工准备的入职指南”，包含指令、可执行代码、参考资料，而且存储在文件系统中，按需加载。这本质上就是一种上下文分片（Context Sharding） 思想。我的方案只是把这个思想推到了极致：不仅技能内容按需加载，连技能所依赖的外部工具链也完全隔离。
更重要的是，这种架构天然支持动态扩展。你想加一个新的 MCP 服务？不用重启主 Agent，不用修改主上下文，只要把配置写进 .mcp.json，再让 mcp-manager 子智能体重新加载一次就行。甚至可以做成热插拔——主 Agent 根本不知道底下换了什么工具，只关心结果是否正确。
这种设计也极大提升了系统的安全性与稳定性。因为每个 MCP 工具的调用都发生在隔离的子环境中，即使某个工具崩溃、返回恶意数据，也不会污染主逻辑。你还可以在子智能体里加入统一的错误处理、重试机制、速率限制等，构建出真正可靠的自动化流水线。
第五大节：给 Anthropic 的建议——请把“MCP子智能体隔离”设为默认模式
说真的，Anthropic 的工程团队非常厉害，MCP 协议本身设计得相当优雅，Agent Skills 的理念也很前沿。但目前的默认行为——把所有工具元数据塞进主上下文——在实际工程落地中是个明显的短板。我强烈建议他们采纳类似我提出的“子智能体隔离”模式作为默认实现。
具体来说，可以这样做：
1. 默认将 .mcp.json 放在 .claude/skills/mcp-manager/ 目录下；
2. 自动创建一个内置的 mcp-manager 子智能体；
3. 主 Agent 调用工具时，通过标准化的子智能体 summon 机制触发；
4. 提供官方的 MCP 元数据预处理工具（用 Claude 自家模型即可），支持生成轻量索引；
5. 允许开发者自定义子智能体的生命周期策略（比如缓存、复用、销毁）。
这样一来，开发者开箱即用就能获得干净的主上下文，同时保留完整的工具调用能力。对于轻量级用户，这套机制几乎无感；对于重度用户，则提供了无限扩展的可能。这才是真正面向未来的 AI Agent 开发框架。
结尾：智能体的未来不在“更大上下文”，而在“更聪明的上下文管理”
很多人以为解决上下文限制的办法就是堆更大的窗口——100万 token、200万 token……但现实是，上下文越大，推理成本越高，延迟越严重，而且大部分信息根本用不上。真正聪明的做法，是像操作系统管理内存一样，对上下文进行分页、缓存、按需加载。
我的 MCP 子智能体方案，本质上就是为大模型引入了“虚拟内存”机制。主上下文是“寄存器”，子智能体是“内存页”，外部工具是“磁盘文件”。需要时才加载，用完就释放，绝不浪费一滴 token。
这不仅是技术优化，更是工程哲学的升级。从“把所有东西塞给模型”到“让模型只关注核心决策”，我们正在走向更高效、更可靠、更可扩展的 AI 自动化时代。而这一切，可能就始于一个简单的想法：让子智能体，去干子智能体该干的活。
所以，如果你也在被 MCP 的上下文膨胀折磨，不妨试试这个架构。说不定，你的下一个爆款自动化应用，就从这里诞生。