过去两年，大模型最直观的价值是“更会回答”：写文案、改邮件、做总结、出方案，看起来样样精通。但当它走进真实业务场景，你很快会发现另一道更关键的门槛——答案之外的事实与动作。客户信息在 CRM 里、订单状态在系统里、资料在文档库里、最新动态在搜索里；如果 LLM 不能安全地“查得到”、也不能可靠地“做得到”，最终就只能停留在高级复制粘贴，离“业务闭环”差一步。
这一步，正是 MCP（Model Context Protocol） 与 GPTBots 组合要解决的问题：MCP 用统一协议把工具、数据源与外部系统标准化接入，让模型具备可控的“调用能力”；GPTBots 则把这些能力沉淀为平台资产，通过工具开关、权限、配额与审计把风险收住，再用 Agent 编排把调用串成流程。于是 LLM 不再只是“会回答”，而是开始真正“能办事”——能检索、能核验、能执行、还能把结果回写到业务系统里。
1 理解MCP
1.1 概念
MCP（Model Context Protocol，模型上下文协议）是一套用于“上下文交换”的标准协议，目的是让 AI 应用（Host）以统一方式连接不同的外部能力（Server），把工具、数据、提示模板等上下文安全、结构化地提供给模型使用。
它解决的问题：LLM 本身不自带你的业务数据与系统能力；没有统一接口会导致每个项目重复对接、难迁移、难治理。
它不解决的问题：MCP 只规定“上下文如何交换”，不规定你如何选模型、如何做 Prompt、如何管理上下文策略。
1.2 架构
MCP 是典型 Client-Server 架构，如下图：
其中，
（1）MCP Host
AI 应用本体（例如 IDE、桌面客户端、平台产品），负责管理一个或多个 MCP Client。
（2）MCP Client
与某个 MCP Server 保持连接，向 Server 获取上下文供 Host 使用。
（3）MCP Server
提供上下文与能力（Tools/Resources/Prompts），可以本地运行也可以远程运行，两种形态：
本地 Server（Stdio）：通常服务单个 Client（同机进程间通信，性能高）
远程 Server（Streamable HTTP）：通常服务多个 Client（跨网络，支持鉴权）
1.3 分层设计
MCP 分为两层：数据层和传输层。
（1）数据层（Data layer）：基于 JSON-RPC 2.0 的消息结构与语义，定义生命周期、核心原语（tools/resources/prompts/notifications）等。
（2）传输层（Transport layer）：定义通信机制与通道（如何建立连接、如何分帧、如何鉴权）。
1.3.1 数据层
1.3.1.1 生命周期管理（Lifecycle management）
MCP 是一个有状态协议（注意：Streamable HTTP 传输下，部分子集可做成近似无状态），需要在连接开始时做能力协商（capability negotiation），包括：
（1）连接初始化
（2）能力声明与协商（支持 tools/resources/prompts/notifications 等）
（3）连接终止
1.3.1.2 MCP 的“三大核心”
MCP 定义了 Server 可暴露的三类核心原语：
（1）Tools（工具）：可执行函数，供 AI 应用调用以完成动作
例：文件操作、API 调用、数据库查询
（2）Resources（资源）：提供上下文数据的数据源
例：文件内容、数据库记录、API 响应
（3）Prompts（提示模板）：可复用的交互模板
例：系统提示词、few-shot 示例模板
1.3.1.3 配套三类方法
（1）发现（Discovery）：*/list（例如 tools/list）
（2）获取/读取（Retrieval）：*/get 或 resources/read
（3）执行（Execution）：tools/call（仅 tools）
这种设计允许“列表是动态的”（比如权限变化导致可用工具变化）。
1.3.1.4 JSON-RPC 2.0
MCP 选择 JSON-RPC 2.0，因为它结构清晰、实现成本低、天然支持“请求-响应 + 通知”，非常适合 MCP 这种需要工具发现、工具调用、实时变更通知的协议层通信。JSON-RPC 2.0 是一种轻量的远程过程调用（RPC）协议：用 JSON 来描述“调用什么方法、传什么参数、返回什么结果/错误”。它不绑定具体传输方式，既可以跑在 HTTP、WebSocket，也可以跑在进程间通信（如 stdio）之上。
核心概念：
Request（请求）：客户端发起一次方法调用
关键字段：jsonrpc: "2.0"、method、params（可选）、id（用于匹配响应）
Response（响应）：服务端对带 id 的请求返回结果
成功返回 result；失败返回 error
Notification（通知）：不需要响应的消息（没有 id），常用于事件推送/状态变化
三个最常见的消息形态（示例）
（1）请求（Request）
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}
（2）成功响应（Response - result）
{ "jsonrpc": "2.0", "id": 1, "result": { "tools": [] }}
（3）错误响应（Response - error）
{ "jsonrpc": "2.0", "id": 1, "error": { "code": -32601, "message": "Method not found" }}
1.3.2 传输层
传输层负责通道、鉴权与安全通信，MCP 目前支持两种传输机制：
（1）Stdio transport
同机进程通信（标准输入输出）
性能好、无网络开销
常用于“本地 MCP Server”
（2）Streamable HTTP transport
Client→Server 使用 HTTP POST
可选 SSE 做流式返回
支持常见 HTTP 鉴权方式：Bearer Token、API Key、自定义 Header
MCP 推荐使用 OAuth 获取鉴权 token
传输层的目标是：让上层 JSON-RPC 2.0 消息格式在不同传输方式下保持一致。
2 GPTBots与MCP
在 GPTBots 平台中，MCP 的使用流程可以概括为“先接入、再选择、再治理、再编排”。首先，管理员在平台侧配置 MCP 服务（本地或远程），完成连接方式与鉴权信息后，GPTBots 会通过 MCP 协议自动拉取该服务提供的 Tool 列表（工具发现）。接着，平台支持对工具进行开启/关闭与权限控制：哪些 Tool 对哪些 Agent/角色可见、是否允许执行高风险动作、调用频率与配额如何限制，都可以在治理层做统一约束。
在此基础上，运营或开发人员可以为某个 Agent 添加 MCP 能力（挂载指定的 MCP 服务/工具集合）。当用户提出问题时，GPTBots 会先让 LLM 理解任务并判断是否需要外部工具；一旦到了“需要检索真实信息/访问业务系统/执行动作”的合适时机，Agent 就会通过 MCP Client 发起标准化的 tools/call 调用，获取结构化的 ToolResult，再将结果回灌给 LLM 作为上下文，最终生成更准确、可验证、可追溯的答案。整体来看，GPTBots 让 MCP 的价值不仅停留在“能调用工具”，而是通过“工具开关 + 权限/配额/审计”的组合，把工具调用变成一套可复用、可治理、可规模化的生产能力。
2.1 工作流程
GPTBots中MCP工作流程如下图：
2.2 实践
2.2.1 接入MCP
GPTBots通过MCP协议自动拉取该服务提供的 Tool 列表（工具发现）。
2.2.2 选择与治理
根据需要选择需要使用的Server，这里只保留查询天气的Server。
2.2.3 编排
在GPTBots的Agent中添加MCP，并使用。
3 未来发展趋势
未来一段时间，LLM 的竞争焦点将从“生成能力”转向“执行能力”，而 MCP 会像 Agent 时代的标准接口一样，推动工具与数据的接入从“项目定制”走向“生态互通”。在这个过程中，GPTBots 这样的 Agent 平台会承担更关键的角色：一方面把各类 MCP 工具沉淀为可复用资产，让组织内不同业务线可以快速组装出面向客服、销售、运营、研发的专用 Agent；另一方面把权限、配额、审计、敏感策略与审批机制平台化，让“能办事”不等于“乱办事”。更进一步，随着多 Agent 协作与长任务编排普及，工具调用会从单点能力升级为可观测、可回放、可补偿的“执行链路”，LLM 将逐步从对话助手演进为真正的业务执行系统：能查证、能行动、能回写、还能在可控边界内持续优化流程与效果。
