设计原则 – Model Context Protocol （MCP）

设计原则

社区译文；来源： MCP 80041ab0

这些原则指导我们评估协议提案、权衡取舍并演进 MCP。它们总结了构建和维护本项目所得的经验，旨在供社区开发规范增强提案（SEP）和扩展时参考。

收敛优先于选择

在 MCP 中，一个问题应只有一种解决方式。我们不会支持多种会割裂生态系统的方案，而是选择一条设计良好的统一路径，即使这意味着需要在前期作出更艰难的决定，也要交付更具一致性的协议。

扩展用于检验能否收敛；规范则用于正式确立收敛结果。

MCP 提供资源、工具和提示词等基础原语。对于能够由这些现有构件组合实现的用例，我们不会增加协议功能。这样可以保持较小的协议表面积和简单的实现。

当有人询问 MCP 为何不直接支持某项功能时，答案通常是该功能可以用 MCP 已有能力构建。MCP Apps 和 Tasks 等扩展用于承载逐渐形成的模式。

MCP 运行于复杂程度差异很大的客户端、服务器和模型之间。相比只有所有参与方能力相当时才能工作的功能，我们更倾向于能够优雅降级的功能。能力协商将这一点具体化：参与方声明其支持的能力，协议据此适配，而不是预先假设。

向像 MCP 这样被广泛采用的协议添加内容很容易，移除内容却几乎不可能。每一项新增内容都是永久承诺，也会给客户端实现者带来持续支持成本。我们审慎推进，因为今天说“不”仍保留未来的可能，而说“是”则会永久关闭退路。

习惯快速交付的贡献者可能会对这种节奏感到受挫，但可持续的标准需要可持续的决策方式。我们的优化目标是数十年，而不是几个季度。

模型进步的速度快于协议演进。我们避免为很可能只是暂时存在的限制增加永久结构；限制会消失，复杂性却会保留下来。

这并不意味着可以忽视当下现实。较弱模型依赖、较强模型可以忽略的可选上下文不会带来什么代价。但如果一项提案主要是因为当前模型没有它就难以工作，我们会追问：在协议能够卸下这份负担之前，模型是否已经不再需要它？

MCP 看重可运行的实现，而不是理论争辩。评估提案时，我们优先考虑真实使用证据，而不是假设性论点。我们鼓励贡献者制作原型、开展实验并展示成果，而不是通过委员会式讨论来设计。实现能够揭示讨论无法发现的问题。

MCP 为促进采用和易用性作出务实取舍。我们不会以牺牲现实效用为代价追求理论上的优雅。如果“正确”的设计给实现者制造了阻力，我们会考虑“足够好”的设计是否更有利于生态系统。这意味着接受一定程度的不一致、一些历史遗留，以及事后看来可能会以不同方式作出的决定。

MCP 将已证明有价值的模式标准化。我们寻找在多个实现中有效的惯例并将其编纂为标准，而不是发明新范式后寄希望于它会被采用。

我们鼓励使用 MCP 扩展来试验可能最终走向标准化的新模式。