MCP on 姚玉亮的网络日志

MCP 生态观察：从协议到工具市场

Sun, 17 May 2026 10:30:00 +0800

Function Calling 硬编码的苦

去年我们在知识库问答服务里做企业级知识库问答，早期的工具调用是通过 Function Calling 硬编码在 Prompt 里的：每接一个内部系统（工单、报表、知识库检索），就要改一遍适配层、重新发版。工具多了之后，模型上下文里塞几十个 JSON Schema，token 浪费严重；而且不同 LLM 供应商的 Function Calling 格式还略有差异，统一适配层写得很痛苦。

MCP（Model Context Protocol）出现后，我把它看作"工具调用界的 USB-C"：客户端和工具之间不再点对点耦合，而是通过一个标准化的 Server 暴露 resources、tools、prompts。我们在知识库问答服务里把内部的检索、工单查询、数据导出封成了几个 MCP Server，模型按需 discover 和 call。

把内部能力封成 MCP Server

MCP 的核心是三类原语：

Resources：只读数据，类似文件 URI（如 knowledge://dataset/123）
Tools：可执行函数，模型决定何时调用
Prompts：预置的提示词模板，用户主动触发

我们的架构是：知识库问答服务作为 MCP Client，通过 stdio 或 SSE 连接多个 MCP Server。工具注册时不再硬编码 Schema，而是启动时 list_tools 拉取，再转换成各家 LLM 的 Function Calling 格式。这样加一个工具就是部署一个 Server，主服务不用动。

知识库问答服务中 MCP Client 的简化封装：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


// 知识库问答服务中 MCP Client 的简化封装
type MCPClient struct {
 conn *client.Client
 tools []Tool
 toolMap map[string]Tool
}

type Tool struct {
 Name string
 Description string
 InputSchema map[string]any
 handler func(ctx context.Context, args map[string]any) (string, error)
}

func (c *MCPClient) LoadTools(ctx context.Context) error {
 resp, err := c.conn.ListTools(ctx, &mcp.ListToolsRequest{})
 if err != nil {
 return err
 }
 c.tools = make([]Tool, 0, len(resp.Tools))
 c.toolMap = make(map[string]Tool, len(resp.Tools))
 for _, t := range resp.Tools {
 c.tools = append(c.tools, Tool{
 Name: t.Name,
 Description: t.Description,
 InputSchema: t.InputSchema,
 })
 c.toolMap[t.Name] = c.tools[len(c.tools)-1]
 }
 return nil
}

// 调用时把 MCP 响应转成统一 LLM 适配层的 ToolMessage
func (c *MCPClient) CallTool(ctx context.Context, name string, args map[string]any) (string, error) {
 out, err := c.conn.CallTool(ctx, mcp.CallToolParams{
 Name: name,
 Arguments: args,
 })
 if err != nil {
 return "", err
 }
 return out.Content[0].Text, nil
}

工具列表加载之后，再按当前对话场景做一次裁剪：知识问答场景只挂检索和文献工具，报表场景挂 SQL 查询和导出工具，避免几十个 Schema 全塞进上下文。

四点观察

先说最值钱的一条：工具描述质量直接决定调用准确率。早期我们写的 Description 很随意（“查询数据”），模型经常选错工具或漏参数。后来要求每个工具都写清楚"做什么、什么时候用、参数含义、返回什么"，并在 Description 里给出一两个示例，准确率明显提升。这其实就是 Prompt Engineering 在工具层的延伸。

stdio 和 SSE 得两条腿走路。本地开发用 stdio 很方便，但线上多实例时 stdio 要随 Client 进程拉起，隔离和扩缩容都麻烦。我们内部工具用 SSE 部署成独立服务，第三方或本地脚本走 stdio，两种都要支持。

权限和审计要跟上。MCP 让工具接入变容易了，但也意味着模型能触发的操作变多了。我们对写操作类工具（发工单、导出数据）强制加二次确认和审批流，并在知识库问答服务侧记录每次 tool call 的 trace_id、入参、结果，对接 ELK 和 Jaeger。

生态正在形成，但还早期。官方和社区已经有文件系统、数据库、Git、Slack 这些 Server，但质量参差不齐，生产用前要自己过一遍代码。我判断接下来会出现"工具市场"：企业内部会有一个 MCP Registry，团队把各自的能力发布上去，像今天的 npm 包一样被发现和复用。

接下来

MCP 不是又一个 Agent 框架，而是一套让模型和工具解耦的协议。对做 LLM 平台的人来说，它把工具接入从"改代码发版"变成了"注册即插即用"，长期看会沉淀成企业内部的工具资产市场。

下一个值得关注的问题：当工具数量上百之后，怎么做路由、权限和版本治理。

封面图：ell brown / Flickr · CC BY 2.0

MCP 协议接入实践：让大模型调用多源工具

Thu, 06 Mar 2025 10:30:00 +0800

每接一个工具，就得改一轮

知识库问答服务上线后，陆陆续续接了不少工具：知识库检索、订单查询、数据集导出、学术文献检索（OpenAlex）。每个工具都是自定义的 HTTP 接口，工具描述、入参、错误返回各写各的。更要命的是，每接一个，适配代码要改一轮，Prompt 里的工具清单也得跟着改一轮，工具越多维护越累。

2024 年底 Model Context Protocol（MCP）开始流行。它定义了一套 client/server 之间发现工具、调用工具的标准 JSON-RPC 协议，把"模型怎么发现和调用工具"这件事标准化了。我们决定把知识库问答服务的工具层改造成 MCP client：内部工具和第三方工具都以 MCP server 的形式接入，业务层只面向一套接口编程。

三层：Transport、Session、工具适配

Transport 层：支持 stdio（本地子进程）和 SSE（远程 server）两种传输，对接不同来源的工具；
Session 层：封装 MCP 的 initialize、tools/list、tools/call，维护会话状态，做超时与重试；
工具适配层：把 MCP 返回的 tool schema 转成统一 LLM 适配层里的 ToolDef，调用结果再回填给模型。

服务里维护一个 MCPRegistry，启动时按配置拉起或连接多个 server，把每个 server 暴露的工具注册进工具表。

注册表与会话

配置结构和工具定义长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


type MCPServerConfig struct {
 Name string `json:"name" yaml:"name"`
 Transport string `json:"transport" yaml:"transport"` // stdio | sse
 Command string `json:"command" yaml:"command"` // stdio
 Args []string `json:"args" yaml:"args"`
 URL string `json:"url" yaml:"url"` // sse
}

type ToolDef struct {
 Name string
 Description string
 Parameters map[string]any
 Server string // 来自哪个 MCP server
}

type MCPRegistry struct {
 mu sync.RWMutex
 sessions map[string]MCPSession
 tools map[string]ToolDef // key: server.tool
}

初始化时遍历配置：stdio 类型用 exec.Command 拉起进程，通过 stdin/stdout 交换 JSON-RPC 消息；SSE 类型发起长连接。握手成功后调 tools/list 拉取工具清单并缓存。

工具调用时，先从模型返回的 tool_calls 里解析出工具名（带 server 前缀），再路由到对应 session：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


func (r *MCPRegistry) Call(ctx context.Context, server, tool string, args map[string]any) (string, error) {
 r.mu.RLock()
 sess, ok := r.sessions[server]
 r.mu.RUnlock()
 if !ok {
 return "", fmt.Errorf("mcp server %s not found", server)
 }
 req := map[string]any{
 "jsonrpc": "2.0",
 "id": snowflake.NextID(),
 "method": "tools/call",
 "params": map[string]any{
 "name": tool,
 "arguments": args,
 },
 }
 return sess.Request(ctx, req)
}

工具定义在统一 LLM 适配层里只有一份 ToolDef 切片，底下是 OpenAI、Azure 还是 VLLM 都无所谓。模型选完工具后分两类：内置函数走本地函数表，MCP 工具走 Registry.Call，结果统一塞回 role=tool 的消息。

四个坑

第一个坑是 stdio 子进程变僵尸。早期没给子进程设置进程组，主服务重启后旧的 MCP server 进程还挂着，时间一长服务器上堆了一堆 node、python 进程。后来用 SysProcAttr{Setpgid: true} 建独立进程组，关 session 时给整个组发 SIGTERM，才解决。

第二个坑是工具描述长度。有的 MCP server 把整段文档塞进 description，拼进 Prompt 里 token 直接飙升。现在注册阶段对 description 做截断，也要求内部 server 写工具时遵循"一句话用途加关键字段说明"的格式。

第三个是流式调用和 MCP 的衔接。主对话是 SSE 流式输出，但 MCP 的 tools/call 是请求-响应模型，两边节奏对不上。我们的做法：模型先吐出 tool_calls 增量，聚合成完整调用后再请求 MCP server，拿到结果继续生成；前端通过自定义事件 tool_call、tool_result 展示中间状态，用户能看见模型正在调什么。

最后是安全边界。MCP server 能访问文件系统和数据库，不能随便信任远程地址。我们只允许内网 SSE，stdio server 做白名单；工具参数做 schema 校验，防止模型把用户输入直接拼成危险命令。

接入之后

新增工具从改代码变成加一个 server 配置，工具的复用和独立演进都清爽了很多。对我们这种多模型、多工具的企业问答场景，这层抽象的投入产出比目前看是很高的。

封面图：qubodup / Flickr · CC BY 2.0