提出通过子代理加载MCP服务器避免主上下文膨胀
解决MCP服务器上下文膨胀的方案:
当我读完Anthropic的“使用MCP执行代码”文章时,突然灵光一闪...
很多人可能已经知道,子代理有自己的上下文窗口,而当前使用MCP会膨胀主上下文(用过Chrome Devtools MCP或Playwright MCP的人都知道它们的工具从一开始就消耗大量上下文)
那么:为什么不把所有MCP加载到子代理的上下文中?
我立刻测试了...
想法很简单:“mcp-manager”子代理 + “mcp-management”技能
1/ “mcp-management”技能包含从“.claude/.mcp.json”初始化MCP客户端的脚本片段(我将“.mcp.json”移到这里,这样主代理一开始就不会加载它们到上下文中)
2/ “mcp-manager”子代理配备“mcp-management”技能
每当需要调用工具时 -> 召唤“mcp-manager”子代理 -> 激活“mcp-management”技能 -> 加载MCP服务器 -> 子代理接收工具列表并分析选择工具 -> 调用工具并获取结果 -> 返回给主代理
搞定!
即使使用80个MCP服务器,主上下文也保持干净整洁👌
看这张图片你会更明白。
附注:我认为Anthropic应该默认采用这种方法,当然去掉“gemini”部分。
你怎么看 @trq212?😜
当我读完Anthropic的“使用MCP执行代码”文章时,突然灵光一闪...
很多人可能已经知道,子代理有自己的上下文窗口,而当前使用MCP会膨胀主上下文(用过Chrome Devtools MCP或Playwright MCP的人都知道它们的工具从一开始就消耗大量上下文)
那么:为什么不把所有MCP加载到子代理的上下文中?
我立刻测试了...
想法很简单:“mcp-manager”子代理 + “mcp-management”技能
1/ “mcp-management”技能包含从“.claude/.mcp.json”初始化MCP客户端的脚本片段(我将“.mcp.json”移到这里,这样主代理一开始就不会加载它们到上下文中)
2/ “mcp-manager”子代理配备“mcp-management”技能
每当需要调用工具时 -> 召唤“mcp-manager”子代理 -> 激活“mcp-management”技能 -> 加载MCP服务器 -> 子代理接收工具列表并分析选择工具 -> 调用工具并获取结果 -> 返回给主代理
搞定!
即使使用80个MCP服务器,主上下文也保持干净整洁👌
看这张图片你会更明白。
附注:我认为Anthropic应该默认采用这种方法,当然去掉“gemini”部分。
你怎么看 @trq212?😜