引言

模型上下文协议（Model Context Protocol）让 LLM 客户端接入既有系统变得更加容易，但多数示例仍停留在“Demo 看起来有意思”为止。更难的问题在于，当相同的集成触及真实的业务数据、真实流程和真实运维约束时，会发生什么？

在我们的场景中，我们希望通过 MCP 服务器把一个基于超过 100 万家企业档案构建的 B2B 情报平台暴露给 LLM 客户端。面向用户的想法很简单：用户无需打开门户、输入查询、人工筛选、手动导出，只需提出结构化的请求，例如，“查找德国 50-200 人规模的 SaaS 公司”，就能在 LLM 客户端获得结果。但是，工程方面的问题远远不是这么简单的，如何让这一流程可用，同时避免把 LLM 与生产数据的连接成不安全的通道呢？

这个问题从一开始就决定了其实现方式。我们没有把 MCP 服务器当作现有 API 的便捷包装层，而是将其视为一等接口，并为其单独定义契约、安全假设、测试策略和运维控制。

由于底层平台服务提供的是 100 万家企业的档案，所以，MCP 层从一开始就必须按照可扩展系统来进行设计，而不是轻量级的实验性集成。在这个规模下，清晰的工具边界、可预测的请求处理和可审计性不仅关乎安全，也直接关系到工程师与用户能否理解系统的行为。

架构设计

平台原本已经通过 AWS AppSync 上的GraphQL对外提供数据，这为读取业务对象提供了清晰的后端边界。我们另外构建了一个基于 Go 的 MCP 服务器，把用户请求转换为一组边界明确的工具，而不是把业务逻辑推给 LLM 层。实现上使用了 mcp-go、面向 AppSync 的 GraphQL 客户端，以及覆盖搜索、AI 辅助搜索和集合操作的工具层。

该架构带来了两点收益。首先，AppSync 可以继续作为后端访问的系统事实来源，避免 MCP 层演化为临时拼接的集成面。其次，工具层可以围绕明确的职责进行设计，使系统更易测试，也更易推理。

实践证明，这套架构比协议本身更重要。MCP 只提供了连接模型，真正的生产问题在于每个工具被授予了多大的能力，以及其行为的定义是否足够精确。如果工具契约模糊，MCP 服务器将难以验证、难以观测，也容易被误用。

从实现层面看，MCP 服务器承担的是“契约执行层”而非“透传代理”的角色。用户请求先被规范化为显式的工具调用，再映射到边界受控的 GraphQL 操作，响应结构也保持足够收敛，从而可独立于 LLM 客户端进行校验。这种分层降低了提示词歧义直接泄露到后端行为的风险。

端到端的请求流

当用户通过 LLM 客户端发起请求时，系统按以下层次依次进行处理：

• LLM 客户端通过 MCP 的 stdio 传输发送工具调用，并携带 JSON 参数（例如，{"query":"SaaS companies in Germany","country":"DE","limit":20}）。MCP 服务器通过mcp-go库接收调用，并将其分发给已注册的工具处理器。

• 参数解析与校验。每个工具先把原始的map[string]any参数通过 JSON 序列化/反序列化解析为类型化的 Go 结构体，再执行校验：必填字段检查、limit 封顶检查（比如，最大值为 100）、输入裁剪与规范化。对写工具会先检查mutationsAllowed布尔值。如果校验失败，立即返回错误，不触达后端。

• 执行 GraphQL。工具构建变量映射并调用client.Execute(ctx, query, variables, &result)以访问 AppSync。GraphQL 客户端统一处理认证（OIDC Bearer Token、API Key 或 AWS SigV4 签名）和 HTTP 层错误（401/404/429）。

• 响应整理。GraphQL 响应会先反序列化为内部类型（比如，gqlCompanyModelV2、gqlCollection），再映射为扁平、对 AI 友好的公开类型（如CompanySummary、CompanyDetail、Collection）。搜索/读取类工具通过toCompanySummary()等函数实现扁平化；写入工具会返回最小化的结果结构（比如，add_to_collection仅返回{collection_id,success}）。

• 序列化与返回。结果被序列化为 JSON，并作为CallToolResult文本内容块返回给 LLM 客户端。

关键点在于校验、执行、响应整理分别由独立的层来进行处理。MCP 服务器既不会把原始用户输入直接传给 GraphQL，也不会把原始 GraphQL 响应直接回传给客户端。

工具清单

实现中定义了 9 个工具，按能力分组如下：

只读工具（6 个）

↗ 查看原文 / 完整内容
https://www.infoq.cn/article/YG0Qxe0YwsIz9jBToPj3?utm_source=rss&utm_medium=article