摘要：模型上下文协议 (MCP) 正在改变生成式人工智能，成为连接人工智能代理与企业系统的通用标准。最佳实践包括将服务器视为有界上下文、首选无状态设计、选择正确的传输方式、拥抱启发、构建安全性等。

模型上下文协议 (MCP) 正在改变生成式人工智能，成为连接人工智能代理与企业系统的通用标准。最佳实践包括将服务器视为有界上下文、首选无状态设计、选择正确的传输方式、拥抱启发、构建安全性等。

译自：15 Best Practices for Building MCP Servers in Production

作者：Janakiram MSV

在 2025 年，生成式人工智能领域正经历着根本性的转变，这主要归功于模型上下文协议 (MCP) 的广泛采用。 随着组织越来越认识到碎片化人工智能集成的局限性，MCP 已成为连接人工智能代理与企业系统、数据源和工具的通用标准。

随着 AI 代理 从简单的聊天机器人发展为能够进行多系统交互的复杂自主系统，MCP 提供的基础架构对于成功的 企业 AI 转型 变得越来越重要。

以下是模型上下文协议开发的 15 个当前最佳实践，其中结合了最新的规范和当前标准。

1. 将每个服务器视为一个有界上下文

围绕单个微服务域构建 MCP 服务器模型，并且仅公开属于该域的功能。 保持工具的内聚性并且具有唯一的名称，以及清晰的 JSON 模式化的输入和输出，以便客户端/LLM 可以消除操作的歧义。

MCP 的工具设计期望具有清晰类型、可发现的操作以及准确的写入模式，该模式尽可能包含枚举，并彻底记录失败模式。

2. 首选无状态、幂等的工具设计

你的服务器将被可能重试或并行化请求的代理调用。 使工具调用具有幂等性，接受客户端生成的请求 ID，并为相同的输入返回确定性结果。 对列表操作使用分页令牌和游标，以保持响应的小巧和可预测。

该规范的 JSON-RPC 约定和 传输 指南假定具有强大的请求/响应语义。

3. 选择正确的传输方式并实现取消

支持 stdio 以实现当今最大的客户端兼容性，并在需要网络化、可水平扩展的服务器或增量结果时添加可流式 HTTP。 请注意，SSE 传输已被弃用，并在 2025-06-18 规范中被 可流式 HTTP 取代。

实现请求取消和超时，以防止长时间运行的调用占用资源。 Stdio 是开发和测试的基准和首选，而可流式 HTTP 具有用于生产中使用的远程和网络部署的一流传输。

4. 拥抱用于人机环路工作流程的启发，但要谨慎

使用 启发 来填写缺失的参数或确认有风险的操作，但切勿收集敏感数据。 保持提示简洁，根据工具的架构验证响应，并且如果主机尚不支持启发，则优雅地回退。

这是 MCP 2025 年 6 月修订版中的新增功能，并非所有主流 MCP 客户端都支持，因此请使用功能检查对其进行控制。

5. 首先构建安全性（OAuth 2.1、会话、范围）

遵循规范中提到的 MCP 安全 最佳实践。 自 2025 年 3 月的规范更新以来，OAuth 2.1 现在是基于 HTTP 的传输的强制要求。

不要使用会话 ID 进行身份验证，生成不可预测的会话标识符，验证所有授权的请求，并最大限度地减少数据暴露。 实施正确的授权服务器元数据发现和动态客户端注册。 切勿在工具结果或启发消息中回显密钥。

6. 采用具有结构化内容的“为代理和人为人类”用户体验

7. 像任何生产微服务一样进行检测

发出带有相关 ID 的结构化日志，包括工具名称和调用 ID，记录延迟、成功/失败以及令牌成本提示（如果已知）。 明确显示软限制和速率限制，以便代理可以预算调用。

这些实践与操作指南中的“管理工具预算”建议相符，并且非常适合标准 SRE 工具的最佳实践。

8. 对你的表面积进行版本控制并宣传功能

当发生重大更改时，对你的服务器和单个工具使用 语义版本控制。 在连接/握手时，发布你的工具列表、资源类型和可选功能（例如启发和结构化内容），以便客户端可以以编程方式调整其行为。 该规范的发现模型和架构概述期望具有功能驱动的客户端。

9. 保持提示、工具和资源解耦和独立

将可重用的提示存储在服务器端，并通过 MCP 提示接口公开它们。 将长模板硬编码到工具中不是一个好主意。

将“资源”视为具有显式 URI、访问规则和分页的只读或最小可变上下文表面。 这种分离简化了测试，并让客户端可以组合干净的工作流程。

10. 负责任地处理流式传输和大型输出

使用可流式 HTTP 时，为长时间运行的操作发出增量块，并在可行的情况下宣传总计数。 对于大型有效负载，返回资源的处理程序/URI，而不是将兆字节内联到单个工具结果中。 可流式 HTTP 的具有动态升级的单端点设计针对简单查询和复杂流式传输操作进行了优化。

11. 使用真实主机和故障注入进行测试

针对多个 MCP 客户端/主机进行验证，包括仅支持 stdio 的客户端/主机。 注入故障，包括减慢下游、部分失败和格式错误的输入。

使用官方的快速入门和检查器工具来验证端到端的发现、架构验证和错误路径。 测试传统内容块和新的结构化内容输出，以确定它们的有效性。

12. 像微服务一样打包和交付

容器化你的服务器，清楚地声明传输和调用命令，并发布最小的运行时映像。 提供一个包含工具目录、架构（包括输出架构）、示例和安全说明的 README。

社区指导和早期采用者强调了容器打包和提交卫生对于目录的重要性。

13. 尊重平台和生态系统的现实

MCP 的采用在 Microsoft Windows、IDE 和供应商生态系统中不断增长，但功能因主机而异。 OAuth 2.1 支持和结构化内容功能可能尚未普遍可用。

在依赖新功能之前，请查看平台说明； 实施优雅的降级和功能标志，以确保平稳运行。

14. 注意 API 设计基础知识

在你的 MCP 层之后，保持 微服务 API 的清洁，包括最小权限操作、清晰的资源生命周期、适当的最终一致性以及幂等突变。

MCP 只是适配器，而你的核心域模型仍然受益于经典的 API 规范。 JSON-RPC 基础强化了对可预测的请求/响应语义的期望。

15. 记录风险并获得对有影响力的行动的明确同意

对于任何改变状态或花费资金的事情，都需要通过启发或“试运行”模式进行确认，并在执行之前返回预期更改的差异。

使用结构化内容来提供机器可读的更改摘要以及人类可读的描述。 这反映了安全指导和新规范功能的人机环路意图。

结论

模型上下文协议代表了企业 AI 和代理开发的一个分水岭时刻，它改变了组织处理长期阻碍大规模采用 AI 的集成挑战的方式。 这 15 个最佳实践为在生产环境中构建 MCP 服务器提供了一个全面的框架。

来源：小岳科技天地