AI 工程实践
MCP 首发复盘：连接标准化为什么不等于企业权限治理
以 2024 年 11 月 25 日至 27 日的一手资料为边界，恢复 MCP 首发的 Host、Client、Server、resources、prompts、tools 与传输层，并区分协议互操作和生产授权。
时间与证据
本文研究的是 Anthropic 于 2024 年 11 月 25 日公开 Model Context Protocol 的事件，信息截止到 11 月 27 日。文章发布日期与更新日期见页首。后来的 OAuth 2.1 框架、Streamable HTTP、tool annotations、Registry 和远程生产生态都不属于首发能力。
证据包括 Anthropic 发布页、发布当日 archive，以及规范仓库完整 commit 08d35a04cbd5d5bb3d7481e5a14901d7972600f4 的 T+2 快照。官方网页可能更新，因此由同期 archive 固定原文；协议概念和传输细节以固定仓库为准，而不是引用今天的 main。
首发时可以确认：MCP 是连接 LLM 应用与外部数据源、工具的开放协议；Host 是 Claude Desktop 或 IDE 一类 LLM 应用，Host 内每个 Client 与一个 Server 保持 1:1 连接。Server 可以暴露 resources、prompts 和 tools；协议层使用 JSON-RPC 2.0，传输同时包括适合本地进程的 stdio，以及 server-to-client 使用 SSE、client-to-server 使用 HTTP POST 的 HTTP+SSE。由此可见，“首发 MCP 只能本地 stdio”是不准确的；但 Claude Desktop 首发产品侧重点确实是本地 server。
本文证据等级为 sourced。我阅读了同期规范，但本篇没有运行 Client/Server、抓取协议流量或验证故障路径。本站另有 2026 年实际执行的 MCP 权限网关可复现实验，其结果不能倒灌成 2024 首发自带能力。
当时发生了什么
MCP 试图解决 N×M 连接问题
没有共同协议时，N 个 AI 应用连接 M 个数据源可能形成大量专有适配：每个客户端分别实现文件、GitHub、数据库、搜索和内部 API。MCP 把连接抽象成 Host/Client/Server，使 Server 可以被不同 Host 发现和调用，SDK 负责协议消息、初始化、能力协商和请求响应。
它减少的是连接层重复工作，不是所有业务集成工作。一个 GitHub Server 仍要处理 GitHub 身份、权限、分页、限流和错误；一个数据库 Server 仍要处理 SQL、连接池、租户与事务。协议统一方法名和数据结构，并不会让不同系统的语义自动一致。
三种核心原语的控制者不同
T+2 概念文档对三类 Server 能力作了重要区分：
| 原语 | 作用 | 预期控制方式 | 生产风险 |
|---|---|---|---|
| Resources | 暴露文件、数据库记录、API 响应等上下文 | application-controlled，由客户端决定何时纳入 | 越权读取、敏感上下文混入、资源 URI 注入 |
| Prompts | 暴露可复用模板和工作流 | user-controlled，由用户显式选择 | 模板来源、参数注入、错误上下文 |
| Tools | 暴露可执行功能和真实动作 | model-controlled，文档建议 human in the loop | 写入、命令执行、资金与外部副作用 |
这三种控制意图不能混成“模型都可以自动用”。Resources 即使只读也可能泄露数据；Prompts 即使由用户选择也可能包含不可信内容；Tools 即使有 JSON Schema 也不自动拥有业务授权。Host 必须把它们以不同 UI、权限和审计呈现。
生命周期和能力协商提供互操作骨架
连接先由 Client 发送 initialize，Server 返回协议版本与 capabilities，Client 再发送 initialized notification。之后双方交换 request、response、notification 和 error。能力协商让客户端不必假设每个 Server 都有 tools 或 resources，也为列表更新和订阅提供基础。
但 capability 表示“Server 声称支持什么”，不是“当前用户有权做什么”。tools/list 返回工具名称、描述和 input schema，也不是 RBAC。Server 在实际 tools/call 时仍要根据可信身份、租户、资源和参数授权；否则任何能连接的 Client 可能获得超出业务范围的动作。
首发规范已有安全建议，也承认无法强制
T+2 tools 文档要求实现方验证输入、清洗路径和命令、执行访问控制、记录审计并考虑限流；同时工具设计为模型可控，建议敏感操作 human in the loop。sampling 流程也描述客户端审查 Server 请求、模型输出和上下文选择。
问题在于这些是实现职责。JSON Schema 可以拒绝错误类型，不能判断用户 A 是否能修改租户 B 的工单；确认弹窗可以提醒用户，不能防止重放同一批准；协议 error 能表示失败，不能证明上游业务状态未改变。MCP 提供插入控制的结构，不替组织定义控制政策。
任务判断
假设一家 B2B SaaS 希望让客服 Agent 同时查询知识库、读取 CRM 客户状态，并在审批后更新工单优先级。团队计划为三套系统各建一个 MCP Server，让 IDE、客服工作台和自动化任务共用。
适合标准化的部分包括 server discovery、工具 schema、资源读取、错误格式和客户端连接。不能委托给协议的部分包括：员工身份来自哪里、当前租户是谁、CRM 字段权限、哪些工单可改、审批由谁签发、更新是否幂等、失败后如何对账。
一条安全写路径应当是：Host 从企业会话获得不可由模型伪造的 principal 和 tenant；Client 建连时把身份放进受信通道；Gateway 或 Server 根据 tool 与规范化参数评估策略；高风险写入需要 out-of-band 一次性 approval；业务服务以 expectedVersion 更新；最后读取权威工单状态并写审计。模型生成的 userId 或 tenantId 只能是普通参数，不能成为身份来源。
首个试点应从只读开始
选择 50 个客服查询，固定三类资源：公开产品文档、租户内工单和客户合同。测试未知资源 URI、跨租户 ID、过大内容、Server 超时、内容提示注入和列表变化。先证明只读请求在权限与引用上正确，再增加“生成工单更新草稿”；真正写入放到最后。
验收指标包括跨租户泄漏 0 次、未授权工具调用 0 次、资源引用正确率、P95、Server 故障隔离、人工确认分钟和最终状态一致率。模型回复“更新成功”不算成功，只有 CRM 中对应版本被正确改变才算。
工程影响
Host 是高价值信任边界
Host 同时连接多个 Server、模型与用户界面，可能接触所有资源描述、prompt 和工具结果。它要隔离不同 Server 的凭据和上下文，清楚显示数据来源，防止一个恶意 Server 通过描述诱导模型调用另一个高权限工具。Server 名称和工具描述都是不可信输入，不应改变 Host 的全局策略。
Client 与 Server 的 1:1 关系有助于隔离连接生命周期，但不等于租户隔离。如果同一 Server 背后共享数据库，仍要在每次请求执行业务过滤。断开 Client 也不会自动撤销已经产生的副作用。
传输与授权分层
stdio 通过本地进程标准输入输出通信，部署简单，但启动命令、环境变量和本地文件权限都属于供应链边界。HTTP+SSE 跨网络时要考虑 TLS、来源认证、会话绑定、CSRF/SSRF、代理超时和连接恢复。无论哪种传输，协议连通都不能证明调用者身份。
首发规范没有后来标准化的 OAuth 框架，因此 2024 团队若要远程生产使用，只能自行设计身份协商或放在已有受信服务后面。本文不能用 2025 的 OAuth 文档为首发安全性背书，也不能反过来说 MCP 首发完全没有网络传输。
Schema、错误与终态
工具 input schema 要限制字段、长度、枚举与资源格式，但授权应基于服务端重新加载的主体和资源。写操作使用幂等 key 与版本，避免超时重试重复执行。若网络在上游提交后中断，结果必须标记为“终态未知”，进入 reconciliation，而不是向模型返回确定失败后立即重试。
审计记录协议 request ID、principal、tenant、tool、参数摘要、策略版本、approval、上游调用、响应验证和最终状态。敏感原文不应直接落日志；哈希可以支持相等性检查，但对低熵参数仍可能被字典猜测，不能称真正保密。
商业价值
MCP 的付费价值首先在连接复用：工具提供方实现一次 Server，多个 AI Host 可以使用；Host 也能用一致方式接入新的数据源。潜在客户是已有知识库、代码仓库、工单、CRM 和内部 API，并计划让多个 Agent 访问的组织。
它替代的是部分专有适配与 SDK 胶水，不替代系统集成、数据治理和安全。成本来自 Server 开发、Host 兼容、身份桥接、策略、审批、监控与版本升级。只有新增连接速度更快、重复代码和维护下降，并且安全事故没有增加时，标准化收益才成立。
建议 90 天采用试点：第一月两个只读 Server，第二月加入草稿工具，第三月才开放一个可逆写动作。若新增一个数据源仍需超过原专有集成 80% 的工程时间、跨租户或未授权调用出现 1 次、协议升级导致超过半天服务中断、人工审批占用超过节省时间，或每个 Host 仍需大量专有分支，就暂停扩张。这些门槛是可证伪计划，不是本文实测。
不应采用的场景包括只有一个稳定客户端和一个简单 API、没有持续集成需求，或者团队以为安装社区 Server 就能绕过内部安全审查。标准协议在连接数量增加时价值更大；连接很少时，直接 API 可能更清晰。
局限与风险
第一，本篇没有运行 MCP，只能解释固定规范，不能声称某 SDK 或 Server 可用。第二，T+2 仓库是快速演进阶段的文档快照，概念名称和细节可能与后来规范不同。
第三，Server、tool description、resource 内容和 prompt 都是潜在不可信输入；跨 Server prompt injection 需要 Host 与业务策略共同限制。第四，社区 Server 可能读取本地凭据、执行命令或引入依赖，必须固定版本、审查代码和隔离运行。
第五，人机确认不是通用安全证明。审批若不绑定主体、租户、工具、参数、版本和过期时间，可能被重放或用在不同资源。第六，协议成功响应不等于业务成功，返回结构也要验证，终态要向权威系统查询。
面试表达
30 秒结论： MCP 首发解决的是 AI 应用连接数据源和工具的标准化。Host 内每个 Client 与一个 Server 1:1 连接，Server 暴露 resources、prompts、tools，传输已有 stdio 与 HTTP+SSE。但协议不自动提供 OAuth、租户 RBAC、参数级授权、审批、幂等和审计，这些仍是业务系统责任。
3 分钟展开： 我会把 MCP 分成互操作层和治理层。互操作层做初始化、能力协商、JSON-RPC 与工具 schema；治理层从可信会话注入 principal/tenant，在 Server 或 Gateway 做策略，写操作绑定一次性 approval 和 expected version，最后查权威状态。首个试点只读，测跨租户、恶意资源、超时与 Server 故障，再逐步开放草稿和可逆写入。
如果追问“MCP 首发是否只能本地”，答案是否定的：T+2 规范同时写了 stdio 和 HTTP+SSE；但首发 Claude Desktop 的产品用法主要强调本地 Server，远程生产身份框架也尚未被后来规范化。
复盘
站在 2026 年回看，MCP 的长期信号是 Agent 工具层正在从框架私有接口走向公共协议。协议成功会让连接更便宜，也会让一个错误 Server 或过宽权限影响更多客户端，所以标准化与治理必须同步。
最需要避免的两种叙事是“协议什么安全都没有”和“协议已经解决企业安全”。首发材料已有验证、访问控制、人机确认等责任说明；但它们不是可自动强制的业务授权。准确结论是：MCP 给出了插入硬控制的统一位置，控制本身仍要实现和验证。
下一步可复现路径已经在本站权限网关实验中落地，但两篇证据要保持分离：本篇只说明 2024 首发；实验只证明 2026 固定 SDK 与本地上游下的 24 个测试。未来还需验证真实 OAuth、分布式状态与长期流量。
方法披露
本文使用 AI 工具协助读取 T+2 规范、整理三类原语和绘制 Host/Client/Server 图；事件日期、固定 commit、传输、后续能力排除和最终判断由作者核验。本篇没有运行 MCP，涉及网关的结果只通过链接指向独立实验，不冒充首发能力。
修订记录
2024-11-27：初版发布；固定 2024-11-25 至 11-27 的公告、archive 与规范，明确首发已有 stdio 和 HTTP+SSE，并将协议互操作与企业授权、审批、幂等、终态审计分层。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论