feat(mcp): 优化 MCP 服务性能并新增MCP工具选择功能

[supreme0597]

变更描述

feat(mcp): 优化 MCP 服务性能并新增MCP工具选择功能

🔧 后端优化：

• 重构 MCP 服务，使用服务器级锁防止并发阻塞
• 提取工具获取逻辑到 _fetch_tools_from_server 辅助函数
• 移除不必要的缓存清理以提升性能
• 新增 get_mcp_servers_info 用于集中获取服务器信息
• 修复切换服务器时工具接口响应慢的问题
• 增强 DynamicToolMiddleware 的工具过滤功能

🎨 前端增强：

• 新增 McpSelector 组件实现细粒度的 MCP 工具管理
• 过滤 McpSelector 仅显示已配置的 MCP 服务器
• 重构 AgentConfigSidebar 降低耦合度
• 新增动态工具中间件实现运行时工具选择

🐛 问题修复：

• 修复 MCP 配置验证中的循环依赖问题
• 防止在仅配置部分 MCP 时显示所有 MCP

变更文件：14 个文件（+2566 行，-166 行）

变更类型

• 新功能
• Bug 修复

测试

• 已在 Docker 环境测试
• 相关功能正常工作

相关日志或者截图

说明

（可选）有什么需要特别说明的吗？
已执行： make lint 和 make format

💡 提示: 提交前可以运行 make lint 和 make format 检查代码规范

[xerrors]

牛！不过然后关于这次的改进，从功能设计的角度上，有几个点想一起探讨一下：

1. MCP 很多时候的使用频次应该没那么高，入口优先级这么高是不是不太妥（或者退一步的方案是隐藏在左侧的+号里面）；另外目前版本的用户权限管理中，普通用户没有权限配置智能体，那么这里如果保留的话，也需要对权限进行判断。
2. 另外是，需要探讨一下，MCP 是否真的是有必要使用动态调整？目前的 config 的配置，在点击保存的时候，会修改 context，然后会重新构建 graph，加载工具。我是觉得没有必要的，因此在上次重构的时候移除了动态工具中间件的使用。
3. 可能是个 BUG，当前PR版本中，在输入框旁的“MCP 工具”按钮中，不选择任何的 MCP 工具，依然是可以正确调用 mcp 工具的。
4. 印象中由于 LangChain 工具绑定的限制，需要在开始的时候，将所有工具都加载出来，在 awrap_model_call 做的修改，只是修改暴露哪些工具给 LLM。所以这个中间件额外设计了一个 initialize_mcp_tools函数，需要在 create_agent之前调用。
   

   Yuxi-Know/src/agents/common/middlewares/dynamic_tool_middleware.py

   Lines 29 to 38 in 8c2c77a

   	async def initialize_mcp_tools(self) -> None:
   	"""异步初始化：预加载所有可能用到的 MCP 工具"""
   	for mcp_name in self._mcp_servers:
   	if mcp_name not in self._all_mcp_tools:
   	logger.info(f"Pre-loading MCP tools from: {mcp_name}")
   	mcp_tools = await get_mcp_tools(mcp_name)
   	self._all_mcp_tools[mcp_name] = mcp_tools
   	# 将 MCP 工具注册到 middleware.tools
   	self.tools.extend(mcp_tools)
   	logger.info(f"Registered {len(mcp_tools)} tools from {mcp_name}")

   
   这里其实想表达的意思是，如果不是那种非常强烈的动态工具的需求（比如需要基于意图等自动化动态调整工具）的话，这种基于用户手动操作的工具变动，只需要使用基于 context 的修改就可以。

[supreme0597]

1、平台可能配置很多mcp工具，但是用户常用的可能就几个，有一堆无用的mcp在上下文中是否有必要呢？会不会降低多轮对话次数；然后权限的话，我测过，普通用户也能打开获取到可用的mcp配置，好像没有权限处理吧。当前用的都是前端的数据，没有调用接口。本来想做接口的，改造成本太高，还有可能数据不一致，就复用了agentConfig的配置
2、关于config的配置，也有需要讨论的，当前粒度太粗了，一个mcpserver下可能有几十上百个tools；然后像知识库一样列出来全部是不合适的，企业场景，随着使用团队增多，知识库可能很多，这样配置页面，交互是不友好的。要分页查询等
3、不是bug，当前代码，不选就是默认全部；不过这么一来，好像确实这个配置功能没有存在的意义了；但如果这么想，不是配置，而是查看呢，当前智能体有多少mcp功能，用户是不感知的，让普通用户去问智能体，有多少mcp工具，回答的可能会是全部，太长了；在查看的基础上，支持用户自己选需要的mcp工具组合，降低token消耗，增加多轮对话次数
4、是在create_agent之前调用的，看graph代码，调用了tools的get_mcp_tools函数

[xerrors]

目前这里有个问题，如果是从控制 MCP 工具的角度来看的话，可以在设置中配置禁用。因为当前整个平台是共享同一个 context 的，在设置里面禁用简单粗暴，和在侧边栏弹窗修改效果应该是一样的。

如果长远来说，想要实现每个用户可以配置自己的 MCP 工具和知识库，感觉需要在平台基础能力上实现

• 用户层级的 context，两个思路，1，设置为 普通用户也可以配置智能体（可以在 metadata 中控制哪些项可以修改，可修改的选项有哪些）。另一个设计的纬度，以前有个大佬提过，用户信息里新增一个部门的字段，一个部门里面的所有用户共享同一个 智能体的 context，普通用户依然无法选择配置，仅能使用。
• 等这个前提实现之后，现在的 MCP 工具选择器才有意义。另外就是如果是从 MCP 工具动态选择的角度（人为选择）来实现的话，似乎也可以不需要使用动态工具选择就可以实现。

[xerrors]

我先按照部门权限的思路设计一个吧

[supreme0597]

周末带娃，没时间看，不好意思。

感觉部门权限什么的，要好好设计吧，不只是mcp，还有知识库，工具等。

如果要跨部门检索知识库或者mcp，又要如何处理。将a部门员工加入到b部门里面么？还要再想想

[xerrors]

先实现了最基础的部门管理系统，仅在数据库和用户层面添加了这个内容。

关于后续的知识库的设计，默认创建的知识库全部都是共享的，然后可以通过一个单独的配置选择不共享该知识库。那么这个知识库只能在同部门里面去使用，那么外部是检索不到的。或者进一步的，可以修改某个知识库的公开范围，勾选可以访问的部门。

对于 MCP，想要设计为只有超级管理员可以添加 MCP，普通管理员可以在智能体的配置页面里面选择启用哪些智能体，启用哪些 MCP 或其中的某些工具，就像你实现的那样。

后续的智能体的 context 是同部门内部共享的，而且可以保存多份供普通用户来选择使用，感觉这样的权限划分也比较合理。