什么是 MCP 主机（MCP Host）？

工作原理

MCP Host 是 Model Context Protocol 架构最上层的 AI Application。IDE、Desktop Assistant、Agent Runtime 或自研产品在创建 MCP Client、连接 Server、集成 LLM、展示 Consent 与 Result，并决定可用 Context 和 Action 时，就是 Host。MCP 只标准化 Client 与 Server 的 Context Exchange，不规定 Host 使用哪家模型、Reasoning Loop、Memory、User Interface 或 Context-management Strategy。

Host、Client 与 Server 是逻辑角色，即使同一产品把它们打包在一起。Host 拥有用户工作流和应用策略；每个内嵌 MCP Client 是一个对应 Server 的 Protocol Adapter；Server 暴露 Tool、Resource 与 Prompt。AI Agent 是运行在 Host 内部或旁边的行为流程，不是 MCP Protocol Role。Gateway 可以代理 Routing 或组织策略，却不一定拥有模型和用户体验；Registry 发布 Discovery Metadata，却不授予 Runtime Trust。混用这些名称会掩盖真正需要作出安全决策的组件。

2026-07-28 协议是 Stateless。Host 仍可为每个 Server 创建一个使用 Dedicated Connection 的 Client，但该 Connection、stdio Process 或 HTTP Stream 不是 Protocol Session、Conversation、User 或 Task。每个 Request 都在 _meta 中携带 Protocol Version 与相关 Client Capabilities，跨请求业务状态使用显式 Handle。Client 应提供 clientInfo，但它只是 Self-reported Display / Debugging Metadata，不能充当认证身份。兼容 2025-11-25 及更早版本的 Host 必须把 Legacy Initialize、Session ID、Capability 与 Server-initiated Request 语义和现代路径隔离。

Server Onboarding 始于 Configuration Trust，而不是 Capability Discovery。Host 要验证 Endpoint 或本地 Command 的提供者、不可变 Package / Deployment Identity、Update Channel、Transport、所需 Credential 和允许的数据边界。内嵌 Client 可以先调用 Server 必须实现的 server/discover，也可直接发 Request 并处理版本错误。成功响应只证明 Protocol Compatibility，不能证明 Provenance 或 Approval；自报 serverInfo、Icon、Name、Description、Schema 与 Link 都是不可信 Metadata。

Host 在向模型或用户暴露能力前进行 Capability Curation。它校验 Schema 与 Content Limit，为每个 Server 绑定稳定 Namespace，并处理 Tool / Prompt Name Collision，不能只依赖 Server 自报名称。Discovery 与 List Cache 要按 Configured Server Identity、Protocol Revision、Authorization Context、cacheScope 与 TTL 隔离；Change Notification 负责失效，而不是自动批准。Descriptor 或 Schema 即使不改 Name 也能改变模型行为，高影响 Capability 因此要比较 Hash，并在重新启用前审查。

Context Assembly 是隐私与可靠性边界。Host 保留完整 Conversation，只向每个 Server 发送当前 Request 必需的 Argument、Resource Identifier 或其他信息。它决定哪些 Resource Byte、Prompt Message、Tool Description 与 Tool Result 进入模型上下文，并实施 MIME、Byte、Token、Provenance 与 Freshness 检查；默认禁止一个 Server 看到另一个 Server 的 Credential 或私有输出。Context 并非越多越好：超大 Catalog 与 Result 会增加 Cost、降低 Relevance，并扩大 Prompt Injection Surface。

模型选择不等于授权。Tool Call 前，Host 要评估 Configured Server、有效 Tool Revision、Principal、Tenant、Argument、Purpose、Side Effect、Data Destination 与 Enterprise Policy。低风险读取可遵循预批准规则，高影响写操作则应展示绑定实际 Argument 的 Preview 并要求显式确认。Approval 在关键 Argument 或 Policy 变化后失效，并且必须可撤销。Server 仍要实施 Object-level Authorization、Idempotency 与 Transaction；Host Dialog、OAuth Scope 或 Tool Annotation 都不能替代这些控制。

在 Streamable HTTP 中，内嵌 MCP Client 扮演 OAuth Client，Server 是 Resource Server。Host 提供 Browser Flow 与 Credential Vault，并为每个 User、Server、Issuer 和 Target Resource 隔离 Authorization Transaction 与 Token。它要校验 Protected Resource / Authorization Server Metadata、精确 Redirect URI、PKCE、State、Issuer、Resource Indicator、Token Audience 与 Challenged Scope；重新授权只请求当前操作需要的 Scope Union。不得跨 Server 复用 Token、把 Token 放入 URL 或 Log、把 Model Provider Key 交给 MCP Server，或沿着 Metadata 与 Redirect 访问内部网络。

stdio 使用进程 Credential，而不是 HTTP OAuth Profile，需要另一套 Sandbox。Host 只启动经过审查的 Binary 或 Package，使用固定 Executable 与 Argument Array，禁止插值 Shell Command。最小化 Environment Variable、Working Directory、Filesystem Mount、Network Egress、Child-process Permission、CPU、Memory、Output Byte 与 Runtime，并将协议 stdout 与 stderr Log 分离。Package Provenance 与 Hash 要固定，Update 需要重新审查，Cancellation 或 Shutdown 应终止整个 Process Tree。本地 Server 使用 Pipe 并不代表可信，它仍能产生本地副作用。

MRTR 让 Host 充当附加输入的中介，而不向 Server 提供主动请求通道。prompts/get、resources/read 或 tools/call 返回 input_required 时，可以请求受支持的 Elicitation、Deprecated Roots 或 Deprecated Sampling 输入。Host 检查声明 Capability，展示真实 Origin 与 Purpose，允许用户拒绝，只收集必要字段，再通过同一 Client 发送独立 Retry。Host 要原样回传不透明 requestState，不得解析，也不能把它当授权。新设计应使用 Direct Model-provider Integration 替代 Legacy Sampling，并以显式参数或配置替代 Roots。

动态更新通过显式 subscriptions/listen Stream 完成。Host 选择 Notification Filter，核对 Acknowledged Subset，以 Subscription ID 关联每个 Event，限制 Refresh 频率，并在断线后重新订阅。Notification 可以使 Tool、Resource 或 Prompt Catalog Cache 失效，却不能静默授予新 Capability 或跳过审查。Cancellation 应尽可能从 UI 与 Model Timeout 传递到 Client、Server Request、Downstream Work 和本地 Process；Stream 关闭不能证明副作用已回滚。

所有 Server Response 都是不可信数据。Tool Description 可携带 Tool Poisoning，Resource 可携带 Indirect Prompt Injection，Prompt 可改变 Instruction Priority，一个被攻陷的 Server 也可能试图影响另一个 Server 的选择或调用。Host 应保持 Server Output 的 Namespace 与 Provenance Label，分隔 Instruction 和 Data，禁止自动转发 Credential 或 Context，并对每个 Cross-server Step 重新授权。Sandbox、Human Approval、Gateway 或更强 System Prompt 各自只能降低部分风险，不能把模型解释能力变成安全边界。

生产 Trace 应关联 Immutable Host Build、User 与 Tenant、Configured Server Identity、Client Instance、Protocol Era、Transport、Effective Capability、Descriptor / Schema Hash、Model 与 Policy Revision、所选 Primitive、脱敏 Argument Digest、Authorization 与 Approval Decision、OAuth Issuer 与 Target Resource、MRTR Step、Cache / Subscription Event、Latency、Error Class、Cancellation、Idempotency Decision 与 Final Effect Status。Log 必须排除 Token、Secret、无限制 Conversation Text 与原始敏感 Resource Body。Host 是协调与应用策略边界，不是万能信任源：Server 仍要校验 Request，Authorization System 仍要签发受限 Credential，用户仍应理解并能停止高影响动作。

主要特点

• 应用协调者：拥有用户体验、模型集成、上下文组装与 MCP Client 之上的策略决策
• 一 Server 一 Client：隔离 Protocol Adapter 与 Dedicated Connection，同时把 Conversation 和 Identity 排除在 Transport State 之外
• 能力治理者：为 Tool、Resource、Prompt、Schema 与 Descriptor Change 提供命名空间、校验、限制、缓存和审查
• 凭据边界：按 User、Issuer、Server 与 Target Resource 隔离 OAuth Transaction 和 Token，并区分 stdio Credential
• 同意与执行治理：实施 Risk-based、Argument-bound Approval，同时保留 Server-side Authorization 与 Idempotency
• 跨 Server 安全边界：限制 Context Propagation、隔离本地进程、标记 Provenance，并在不记录 Secret 的前提下审计端到端决策

常见用途

1. AI 编码环境为 Filesystem、Source Control 与 Issue Tracker Server 创建独立 Client，并限制各自 Workspace Boundary
2. 企业 Assistant 为重名 Tool 分配 Namespace，只向当前 User 与 Tenant 暴露 Policy-approved Capability
3. Desktop Host 以最小 Environment、Filesystem Allowlist、No-shell Spawn 和 Process Limit 启动已审查的本地 Server
4. Remote Host 为每个 Server 使用 PKCE 与 Resource Indicator 完成 OAuth，并仅为当前操作请求 Step-up Scope
5. 受监管 Agent Runtime 展示高影响 Argument、记录 Approval 与 Effect Status，并阻止不可信输出驱动 Cross-server Action

常见问题

相关工具

相关术语

相关文章