（智能工具检索）在内的核心架构，为 AI Agent 提供标准化、高性能的工具调用能力。：基于检索增强生成 (RAG) 技术，解决大规模工具集下的上下文窗口限制问题。：作为 AI Agent 与 MCP 服务端的通信桥梁，支持多种传输模式。协议的完整 C++ 实现，构建包含。：高性能、插件化的工具执行中心。本项目的核心调用链遵循。

本文旨在梳理main.cpp在中承担的核心职责，明确服务启动阶段的关键执行路径，包括以及四个部分。从工程实现角度看，main.cpp本身并不负责具体工具逻辑，而是作为整个服务的。

这份Server通过Connect()绑定并启动 transport通过Read()接收客户端消息通过与完成请求分发通过建立 method 到 handler 的映射通过提供运行时覆盖默认逻辑的能力通过、通知队列和实现异步主动通知通过Stop()统一收束 transport 与线程生命周期从设计上看，这是一套将传输层、协议处理层与业务扩展层分离的服务端骨架实现。

/ 只需改这一行// 只需改这一行 std :: unique_ptr < ITransport > transport = std :: make_unique < WebSocketTransport >();// 只需改这一行 std :: unique_ptr < ITransport > transport = std :: make_unique < WebSocketTranspor

扫描目录└─ 找动态库文件└─ dlopen / LoadLibrary ← 库加载进进程└─ dlsym / GetProcAddress ← 查找导出符号└─ CreatePlugin() ← 创建插件对象└─ Initialize() ← 插件自身初始化└─ 业务使用└─ Shutdown() ← 插件收尾└─ DestroyPlugin() ← 销毁对象└─ dlclose / FreeL

基于函数指针表的插件协议 + JSON 字符串通信。主程序先通过枚举接口"发现能力"，再通过“触发执行”，二者之间的一切信息交换都以 JSON 字符串为载体，实现了彻底的接口解耦。PluginAPI├── GetType() → PluginType（插件是哪类）├── GetToolCount/Tool → PluginTool（工具的说明书）├── GetResourceCount/Resou

本文以一个极简但完整的 C++ 插件示例为切入点，带你搞清楚插件框架的核心设计模式、JSON Schema 的参数约束方式，以及跨模块 ABI 的若干实际陷阱。

阶段核心函数作用初始化创建三大子组件，尝试加载历史索引建索引addTool()工具文本化 → 向量化 → 写入索引检索retrieve()Query 向量化 → 相似度搜索 → 结果转换性能Cache Aside 减少重复 API 调用适配检索结果转为 LLM 可用的 JSON 格式只用哈希表：查找 O(1)，但无法维护访问顺序，不知道谁最久没被用。只用链表：能维护顺序，但查找 O(n)，每次 g

插件使用静态数组methods[]定义工具清单，每个条目包含三个字段：工具名、描述、JSON Schema。这是整个「接口契约」的来源，宿主程序通过枚举所有工具，再按 Schema 构造请求。},"add",},// ... 其余工具这种「先声明接口再实现功能」的设计，让整个系统具备良好的自描述性，非常适合被 AI Agent 或自动化框架动态发现和调用。这份代码展示了一个设计合理、职责清晰的 C

MCP（Model Context Protocol，模型上下文协议）是一种标准化协议，用于让 AI Agent 与外部工具服务器进行通信。类似于 HTTP 之于 Web 应用，MCP 定义了 Agent 和工具提供方之间"说话"的方式。LLM：负责理解用户意图、决策调用哪个工具MCP Client：负责与工具服务器建立通信连接，收发 JSON-RPC 消息MCP Server：对外暴露一系列可调