perf(agents): MCP 工具并发加载，多 MCP server 启动耗时从 sum 降到 max

[zgpnuaa]

现象

智能体启动时，配置了多个 MCP server 的情况下，工具加载是串行的：每个 server 逐个 await get_enabled_mcp_tools。单个 server 加载 33-300ms，6 个串行累加就是 1-2 秒——都花在智能体启动阶段，用户感知为「发出去后要等一下才开始」。

机理

resolve_configured_runtime_tools 里对 context.mcps 逐个串行 await：

for server_name in ...:
    mcp_tools = await get_enabled_mcp_tools(server_name)   # 逐个等

各 MCP server 之间互相独立，串行没有道理，总耗时是 sum 而非 max。

改进方法

改成 asyncio.gather 并发加载全部 MCP server 的工具，取 max 而非 sum：

• 先收集去重后的 server 名单（保持配置顺序，保证工具注册顺序不变）；
• asyncio.gather 并发加载；
• 单个 server 失败仍只 warn、不影响其他（用返回值 (name, None) 代替 continue，保持容错语义）。

这是上游 deepagents-code #4659 同款优化（deepagents 官方已采用并发加载）。

效果

多 MCP server 场景下，工具加载耗时从 sum 降到 max（6 个 server 约 1-2s → 单次最慢 server 耗时）。单 server 失败容错语义不变。

[xerrors]

Codex Review:

仅供参考：本轮预 review 基于 7957e7efe54f，不是正式批准或合并结论。

本轮未发现可确认的功能缺陷。检查了实际 MCP loader：数据库读取各自使用 session，网络工具发现没有被全局 _mcp_lock 包住；gather 的返回顺序仍按配置顺序，后续工具名冲突检查也保留，因此这处并发改动方向合理。

实际验证：在该 head 独立源码快照运行 PYTHONPATH=package:server python -m pytest test/unit/services/test_tool_service.py test/unit/middlewares/test_skills_middleware.py -q --disable-warnings --tb=short 的两个文件（分两次执行），共 15 passed。另调用真实 resolve_configured_runtime_tools，用可控 MCP loader 验证并发启动屏障、重复 server 去重、反序完成仍按配置排序、单 server 失败隔离、同名工具拒绝、取消时两个加载协程均退出，全部通过。

建议把并发屏障/排序/取消的回归用例加入 PR；现有改动没有新增测试。性能数字目前仍是 PR 自述，本次没有连接真实 MCP server 测冷缓存启动耗时，不能据 mock 探针确认“1–2 秒降到单个最慢 server”。