MCP如何成为Agent平台的深度扩展点：架构设计与实践

引言：从本地工具到平台级扩展

随着OpenAI Codex等自主运行Agent方案的普及，越来越多开发者意识到：一个能完全托管、自主运行的Agent具有巨大潜力。然而，现有方案在应用性和能力上往往达不到预期。Agent平台化提供了一种更工程化的可能性，而MCP（Model Context Protocol）在这个过程中重新焕发了生命力。

MCP是Anthropic于2024年底提出的开放标准协议，旨在解决AI模型与外部工具、数据源之间的集成碎片化问题。在MCP出现之前，每个AI应用都需要为每种工具单独编写集成代码，形成了大量重复的「N×M」集成矩阵——即N个AI应用分别对接M种工具，每一对组合都需要独立维护。MCP通过定义统一的Client-Server通信规范，将这一问题简化为「N+M」的插件式架构：工具开发者只需实现一次MCP Server，所有兼容MCP的Agent平台即可直接接入。这一设计理念与USB接口标准化外设连接的思路如出一辙。

本文是Agent平台系列的第三期，核心话题是：如何将MCP用作平台的扩展点，实现权限集成、UI扩展等skill方案难以替代的能力。

MCP在本地Agent与平台Agent中的差异

本地Agent：stdio的天然优势

对于本地Agent而言，stdio类型的MCP Server是最自然的选择。stdio（标准输入输出）是操作系统提供的最基础进程间通信机制——父进程通过写入子进程的标准输入（stdin）发送请求，通过读取子进程的标准输出（stdout）获取响应。这种方式无需建立网络连接，通信延迟仅受CPU调度影响，通常在微秒级别。MCP Server以进程形式与Agent Core运行在同一环境中，具备以下优势：

• 几乎零延迟：进程间通信，无需网络开销
• 本地文件直接访问：MCP Server可以直接读取本地文件系统
• 管理简单：无需额外的服务部署

这种模式下，当你在Agent对话中说"帮我处理某个代码文件"时，MCP Server能直接读取该文件，绕开了远程场景下的上传限制。市面上大部分MCP Server也都是从stdio类型起步的。

平台Agent：多租户带来的新挑战

当MCP需要运行在多租户、多用户的通用Agent平台中时，情况就完全不同了。多租户（Multi-tenancy）是SaaS平台的核心架构模式，指同一套软件基础设施同时服务多个独立用户或组织。在Agent平台语境下，多租户带来的核心挑战是资源隔离与权限管理——每个用户的工具调用凭证、数据访问范围必须严格隔离，不能相互干扰。这使得原本在本地运行的stdio模式面临根本性的架构障碍：

• 权限控制：stdio类型的MCP Server通常需要用户在本地执行命令行操作完成认证，但平台用户可能完全没有命令行经验
• 登录复杂度：每个Agent都需要单独完成一次登录，极其琐碎
• 传输协议选择：平台场景下，HTTP Streamable类型比stdio更友好，支持远程访问和统一管理

HTTP Streamable是MCP支持的另一种主要传输协议，基于HTTP协议并结合Server-Sent Events（SSE）实现流式响应。SSE是一种单向的服务器推送技术，允许服务端在一个持久HTTP连接上持续向客户端发送数据，非常适合AI模型逐token生成响应的场景。相比WebSocket的双向全双工通信，SSE实现更简单，且天然穿透大多数企业防火墙和反向代理，这使其成为平台级MCP部署的首选传输层。

因此，对于Agent平台来说，从stdio迁移到HTTP Streamable传输协议是一个必然的选择。

平台与MCP结合的架构实践

核心链路设计

在Agent平台架构中，MCP的集成有两个关键的可扩展链路：

链路一：配置下发时的信息改写

管理面的MCP配置在下发给Agent时，可以进行改写和补充。这意味着平台可以为Agent注入额外的上下文信息，让工具调用更加智能。例如，平台可以在配置中自动注入当前用户的租户ID、权限范围或环境标识，使MCP Server无需额外的身份查询即可做出正确的访问控制决策。

链路二：MCP Proxy代理层

从Agent Core到外部MCP Server的调用，不再是直连，而是先经过平台内部的MCP Proxy（网络代理，非AI Agent）。MCP Proxy本质上是一个反向代理服务，借鉴了API Gateway的成熟设计模式，将认证、限流、审计等横切关注点从业务逻辑中剥离出来统一处理。这个代理层可以完成：

• 凭证的自动注入：将平台统一管理的OAuth Token或API Key在请求转发时动态附加
• Token的自动刷新：监测凭证有效期，在过期前静默完成刷新，对Agent Core完全透明
• 安全审计和访问控制：记录所有工具调用的完整日志，支持合规审查和异常检测

这样用户使用起来既安全又简单，无需关心底层的认证细节。

工具调用串联Agent与Human

这是MCP在平台场景下最具吸引力的设计思路，也是Human-in-the-Loop（HITL，人在回路中）协作范式在Agent工程中的具体落地：通过工具的调用和返回结果，将Agent和人类串联在一起协同工作。

HITL是AI系统设计中的重要范式，指在自动化流程的关键节点引入人类判断和干预。这一概念源于控制论和早期专家系统设计，在大模型时代被重新赋予了新的工程意义——尤其在高风险操作、需要主观判断或法律合规要求的场景下，HITL成为保障AI系统可靠性的关键机制。MCP的工具调用机制天然为HITL提供了标准化的"暂停点"：Agent调用工具后等待结果，平台在此期间将控制权交给人类，人类处理完毕后再将结果注回Agent的上下文。

以Code Review场景为例，整个协作流程如下：

1. Agent在对话中执行Code Review流程，调用create_review这个MCP工具
2. 平台检测到工具调用结果，在定制化UI区域自动展示Review界面
3. 人类在嵌入式UI中完成Review操作，点击Submit
4. 平台自动将结果以prompt形式提交回Agent，对话继续

整个过程无需离开Agent平台，实现了真正的无缝协作。对比传统的skill模式——Agent给你一个链接，你打开新页面处理完再回来告诉Agent——体验提升是质的飞跃。

MCP作为产品扩展点的核心价值

为什么不是Skill？

在Agent架构中，Skill通常指预定义的、封装好的功能模块，Agent通过调用Skill完成特定任务，其交互结果以纯文本形式返回给对话上下文。这种模式简单高效，配合Agent的编程能力确实能解决大部分场景。但Skill的文本返回机制天然缺乏与平台UI层的深度集成能力——它能告诉Agent"任务完成了"，却无法在平台界面上直接渲染一个可交互的操作面板。MCP则通过标准化的工具调用协议，允许工具返回结构化数据，进而触发平台层的UI渲染逻辑，实现了从「文本交互」到「界面协作」的跨越。具体来说，MCP在以下方面展现了不可替代的优势：

• UI扩展能力：MCP工具的调用结果可以触发平台级的UI渲染，这是纯文本skill难以实现的
• 权限集成：MCP协议天然支持认证和授权的标准化流程
• 跨Agent Core可移植性：无论底层是Codex、Claude Code还是自研Runtime，只要接入统一的MCP Client-Server架构，配置即可迁移

协作模式的本质

MCP在平台中的核心价值可以概括为：Agent通过工具调用创建"协作节点