- 引言
- 引入 MCP 前应先确定的事项
- Transport 选型：stdio 与 Streamable HTTP
- Tool 设计原则
- Token 预算与减少上下文浪费
- 认证与权限模型
- 可观测性与运维检查清单
- 反模式
- 结语
- 参考资料
引言
Model Context Protocol，简称 MCP，是一种试图把智能体应用与外部系统交互方式标准化的尝试。从实际运维的角度看，真正重要的问题往往不是协议本身，而是以下这些：
- 一个 MCP 服务器该管到什么范围为止
- tool 与 resource 该如何划分
- stdio 与 HTTP 该如何取舍
- 如何设计才能不让模型因读取过多工具说明与结果而浪费 token
- 该如何审计是谁调用了哪个 tool
本文以 MCP 官方文档为基准，梳理在生产环境中会立刻遇到的设计与运维问题。
引入 MCP 前应先确定的事项
MCP 很强大，但如果不假思索地把所有内部系统都接到同一个服务器上，很快就会变成运维负担。开始之前，最好先明确以下原则。
1. 服务器边界按业务领域划分
最常见的失败方式，是"把公司全部工具塞进同一个 MCP 服务器"这种做法。这样一来会出现以下问题：
- 工具说明变得过长，占用模型上下文
- 权限边界变得模糊
- 故障隔离变得困难
- 版本管理被固定在一个庞大仓库的粒度上
更好的方式是按业务领域或安全边界来划分。
| 服务器边界示例 | 包含的功能 | 分离理由 |
|---|---|---|
github-governance | PR 查询、检查状态、ruleset 信息 | 开发工作流与权限模型清晰明确 |
incident-ops | 告警查询、runbook 链接、故障时间线 | 运维数据与审计日志的要求不同 |
docs-search | 文档搜索、文档摘要用资源 | 读取性质较强 |
2. 区分 Tool 与 Resource
按官方文档的定义，tool 更接近调用时会有副作用或需要计算的动作，而 resource 更适合提供可读的上下文。
tool- 审批、部署、创建 issue、查询执行状态等接近函数调用的功能
resource- 策略文档、runbook、架构说明、服务清单等接近可读上下文的信息
这个区分之所以重要，是因为它会改变模型的行为模式。如果把所有可读上下文都做成 tool，模型就会反复进行不必要的调用；反过来，如果把动作包装成 resource，治理与审计就会变得困难。
Transport 选型：stdio 与 Streamable HTTP
在 MCP 官方文档中最先遇到的选择之一就是 transport。
适合 stdio 的场景
- 本地开发工具与桌面客户端
- 单用户场景
- 可以让客户端直接管理进程生命周期的场景
优点：
- 实现简单
- 能在本地安全边界内快速起步
- 相比部署，更利于集成测试
注意事项：
- 服务器进程的生命周期依赖于客户端
- 中央审计与多租户运维较困难
适合 Streamable HTTP 的场景
- 多个客户端调用同一服务器的平台环境
- 需要中央认证、日志、rate limit、网络策略的场景
- 需要按组织单位运维与自动化部署的场景
优点：
- 容易接入运维标准
- 与 API gateway、service mesh、ingress 策略天然结合
- 即使客户端种类繁多也易于扩展
注意事项：
- 需要更明确地设计认证与会话边界
- 设计不当很容易沦为"又一个 HTTP 包装层"
Tool 设计原则
名称要便于模型推理，范围要窄
不好的例子是过于笼统的名称。
run_action
manage_item
operate_system
好的例子是输入与效果都可预期的名称。
list_pull_requests
get_ruleset_status
create_incident_note
名称一旦含糊，模型就得做更多推理，选错 tool 的概率也会随之上升。
输入 schema 要短且严格
输入字段越多，模型出错的可能性也越高。实务中以下规则很有用：
- 必填字段尽量保持最少
- 能用 enum 限制的值不要留成自由文本
- 说明文字要简短，且面向行动
- 不要把人类可读标识符与内部标识符混在一起
Tool 结果应贴合"下一步行动"，而非"大块数据"
比起冗长的 JSON dump，模型更擅长使用为选择下一步行动而结构化的结果。
好的结果示例：
{
"repository": "platform/api",
"ruleset_status": "blocking",
"missing_checks": ["lint", "integration-test"],
"next_actions": [
"wait_for_required_checks",
"request_codeowner_review"
]
}
从运维经验来看，在 tool 结果中放入候选的下一步行动，有助于减少模型不必要的重复调用。
Token 预算与减少上下文浪费
正如 GeekNews 上热议的 MCP optimizer 之类工具所展示的那样，实际瓶颈往往不是模型质量，而是上下文浪费。
常见的浪费模式
- tool 说明冗长且重复
- 每次都完整返回 resource 正文
- 把用不到的字段也全部塞进结果
- 单个服务器暴露过多 tool
运维原则
- 保持 tool 说明简短。
- 把 resource 拆分成比整篇文档更细的可摘要单元。
- 结果分为默认摘要与按需详细查询两个阶段。
- 借助日志与追踪数据，清理实际调用频率低的 tool。
举例来说，如果是 runbook 系统，最好不要一开始就返回完整的 markdown，而是优先返回标题、负责团队、最后修改日期、核心步骤。
认证与权限模型
一旦 MCP 服务器接入组织系统，核心问题就不再是便利性，而是权限边界。
必须先厘清的问题
- 调用主体是用户代理，还是系统账号
- 只读 tool 与可写 tool 是否混在一起
- 敏感资源的访问是否要分离到独立服务器
- 审计日志应保留哪些最小字段
推荐的运维模式
- 将只读服务器与变更型服务器分离
- 对可写 tool 明确设定幂等性与审批环节
- 在调用日志中记录用户、会话、tool 名称、输入摘要、结果状态
- 失败原因也要以人可审阅的形式记录下来
可观测性与运维检查清单
如果把 MCP 服务器当作运维系统来对待，至少应该监控以下内容。
| 领域 | 需要关注的指标 | 理由 |
|---|---|---|
| 可用性 | 请求成功率、响应时间 | 便于快速找到模型放弃 tool 调用的原因 |
| 质量 | tool 调用后的重试比例 | 可以判断工具说明或输入 schema 是否含糊 |
| 成本 | 平均响应大小、token 使用量估算 | 用于减少过度的上下文传递 |
| 安全 | 被拒绝的调用、权限错误、异常调用模式 | 用于检测策略违反与滥用 |
上线前检查清单
- 服务器边界是否按领域与权限划分
- tool 名称与 schema 是否足够窄且明确
- resource 是否会返回过大的 payload
- 审计日志是否充分
- 失败时的 fallback 行为是否已定义
- transport 选型理由是否已文档化
反模式
"把内部 API 全部用 MCP 包一层就行"
这种做法几乎总会失败。MCP 的核心不是简单的代理层，而是让模型能够理解并做出选择的接口设计。
"工具越多越聪明"
恰恰相反，工具数量越多，选择错误与 token 浪费也会随之增加。好的 MCP 靠的不是工具数量，而是边界与命名规范。
"本地能跑，运维也没问题"
即便基于 stdio 的本地集成运行良好，一旦进入中央认证与多客户端环境，就会出现其他问题。在生产环境中，transport、rate limit、审计、部署策略都需要单独处理。
结语
把 MCP 引入得好的团队，与其说是"模型变聪明了"，不如说更接近"设计出了模型可以安全使用的接口"。归根结底，决定成败的不是协议本身，而是服务器边界、tool schema、transport 选型、权限模型，以及 token 预算的运维方式。
可以从小处起步，但以下两点最好从一开始就把握好：
- 按业务领域划分服务器
- 简短明确的 tool 与 resource 接口
守住这两点，后续的认证、可观测性、成本优化也会容易得多。
参考资料
현재 단락 (1/119)
Model Context Protocol，简称 MCP，是一种试图把智能体应用与外部系统交互方式标准化的尝试。从实际运维的角度看，真正重要的问题往往不是协议本身，而是以下这些：