基于 MCP 的 AI Agent 应用开发实践

最近大家都在聊 MCP,发现有个最重要的点被忽略了 『通过标准化协议,将工具提供方与应用研发者解耦』 ,这一点带来的将是 AI Agent 应用研发范式的转移(类似 Web 应用研发的前后端分离)。 本文以开发 Agent TARS 应用为例,尽可能详细地介绍 MCP 在『开发范式』、『工具生态扩展』上起到的作用。
名词解释
背景
AI 从最初只能对话的 Chatbot,辅助人类决策的 Copilot,再到能自主感知和行动的 Agent,AI 在任务中的参与度不断提升。这要求 AI 拥有更丰富的任务上下文 (Context),并拥有执行行动所需的工具集 (Tools)。
痛点
缺少标准化的上下文和工具集导致开发者的三大痛点:
开发耦合度高:工具开发者需要深入了解 Agent 的内部实现细节,并在 Agent 层编写工具代码。这导致在工具的开发与调试困难。
工具复用性差:因每个工具实现都耦合在 Agent 应用代码内,即使是通过 API 实现适配层在给到 LLM 的出入参上也有区别。从编程语言角度来讲,没办法做到跨编程语言进行复用。
生态碎片化:工具提供方能提供的只有 OpenAPI,由于缺乏标准使得不同 Agent 生态中的工具 Tool 互不兼容。

目标
"All problems in computer science can be solved by another level of indirection" -- Butler Lampson 在计算机科学中,任何问题都可以通过一个抽象层解决。
将工具从 Agent 层解耦出来,单独变成一层 MCP Server 层,并对开发、调用进行标准化。 MCP Server 为上层 Agent 提供上下文、工具的标准化调用方式。

演示
从几个例子中看 MCP 在 AI Agent 应用中发挥的作用:
已支持自定义 MCP Servers !415 !489,可以添加 Stdio、Streamable HTTP、SSE 类型的 MCP Server。
介绍
什么是 MCP?
Model Context Protocol(模型上下文协议)是 Anthropic 在推出的用于 LLM 应用和外部数据源(Resources)或工具(Tools)通信的标准协议,遵循 JSON-RPC 2.0 的基础消息格式。 可以把 MCP 想象成 AI 应用程序的 USB-C 接口,规范了应用程序如何为 LLMs 提供上下文。

架构图如下:

MCP Client:通过 MCP 协议与 Servers 通信,并保持 1:1 连接
MCP Servers:上下文提供方,暴露外部数据源(Resources)、工具(Tools)、提示词(Prompts)等由 Client 进行调用。
语言支持层面:TypeScript 和 Python、Java、Kotlin、C#
流程图
一句话解释就是 MCP 提供给 LLM 所需的上下文:Resources 资源、Prompts 提示词、Tools 工具。

MCP 和 Function Call 区别?
从前后端分离看 MCP
早期 Web 开发在 JSP、PHP 盛行时,前端交互页面都是耦合在后端逻辑里的,造成开发复杂度高、代码维护困难、前后端协作不便,难以适应现代 Web 应用对用户体验和性能的更高要求。
AJAX、Node.js、RESTful API 推动前后端分离,对应 MCP 也正在实现 AI 开发的“工具分层”:
前后端分离:前端专注界面,后端专注 API 接口;
MCP 分层:让工具开发者和 Agent 开发者各司其职,工具质量和功能的迭代不需要 Agent 开发者感知。这种分层让 AI Agent 开发者能像搭积木一样组合工具,快速构建复杂 AI 应用。

实践
整体设计
以 MCP Browser 浏览器工具 开发和接入为例,逐步解析具体实现。

在设计 Browser MCP Server 时,并没有采用官方的 stdio call 方式(即通过 npx
方式跨进程调用)。原因是为了降低使用门槛,避免用户在首次使用时先安装 Npm、Node.js 或 UV,从而影响 Agent 开箱即用的体验(相关 issue#64)。
因此,Agent 工具的设计分为两类:
内置 MCP Servers:完全遵循 MCP 规范,同时支持 Stdio 和函数调用。(换句话说用『MCP 标准开发 Function Call 』)
用户自定义 MCP Servers:针对需要扩展功能的用户,默认他们已经具备 Npm 或 UV 环境,因此可以支持更灵活的扩展方式。
两者的区别:
内置 MCP Servers 是完成当前 Agent 功能的必备工具
调用方式:内置方式不需要 Agent 用户安装 Node.js / npm,这对于小白用户比较友好。
MCP Server 开发
以 mcp-server-browser 为例,其实就是一个 npm 包,package.json
配置如下:
bin
指定通过 stdio 调用的入口文件main
、module
执行通过 Function Call 同进程调用的入口文件
开发(dev)
实践下来,通过 Inspector 来开发调试 MCP Server 是比较好,Agent 与工具解耦,可以单独调试和开发工具。 直接运行 npm run dev
启动一个 Playground,里面包含 MCP Server 可调试的功能(Prompts、Resources、Tools 等)

注:用 Inspector 调试开发 Server 时,console.log 是无法显示的,这点 debug 确实有点麻烦。
实现(Implement)
启动入口(Entry)
为了内置 MCP Server 可以当 Function call 同进程调用,这里在入口文件 src/server.ts
中导出三个共用方法:
listTools
:列举所有函数callTool
:调用具体函数close
:Server 不使用后的清理函数
同时 _Stdio 调用支持_,直接在 src/index.ts
导入模块即可使用。
工具定义(Definition)
MCP 协议要求用 JSON Schema 约束工具的入参、出参,这里实践下来:推荐用 zod 来定义一套 Zod Schema,导出到 MCP 时再将 zod 转成 JSON Schema。
技巧 Tips:与 OpenAPI 返回结构化数据不同,MCP 的返回值专为 LLM 模型设计。为了更好地连接模型与工具,返回的文本和工具的描述
description
应更具语义化,从而提升模型的理解能力,提高工具调用的成功率。 例如,browser_scroll(浏览器滚动)
在每次执行工具后,应返回页面的滚动状态(如距底部剩余像素、是否已到底等)。这样模型在下次调用工具时即可精准提供合适的参数。
Agent 集成
开发完 MCP Server 后,需要在 Agent 应用中进行集成。原则上,Agent 无需关注 MCP Servers 提供的工具、入参和出参的具体细节。
MCP Servers 配置
在 MCP Servers 配置中分为『内置 Server』和『用户扩展 Server』,内置 Server 通过同进程 Function Call 调用,保证 Agent 应用对小白用户开箱即用,扩展 Server 则提供给高级用户扩展 Agent 上限功能。
MCP Client
MCP Client 的核心任务是集成不同调用方式(Stdio / SSE / Streamable HTTP / Function Call)的 MCP Server。Stdio 和 SSE 方式直接复用了 官方示例,这里主要介绍下我们对 Function Call 调用是怎样在 Client 中支持的。
Function Call 调用
MCP Client 调用方式如下:
至此,MCP 的整体流程已全部实现,涵盖了从 Server 配置、Client 集成到与 Agent 的衔接等各个环节。更多 MCP 细节/代码已开源到 Github:Agent 集成、mcp-client、mcp-servers。
Remote 远程调用
如果是 Web 应用(无法使用 Stdio MCP Server),可以用 FaaS 将 Stdio 转成 SSE MCP Server,从而在 Function Call 的基础上无缝支持 MCP 类型的 Tools,这个过程换句话讲是『MCP Servers 云化』。

调用代码示例:
思考
生态
MCP 生态不断发展壮大,越来越多的应用支持 MCP,同时开放平台也提供 MCP Server。同时也有像 Cloudflare、Composio、Zapier 使用 SSE 方式将 MCP 进行托管(即接入一个 MCP Endpoint 即接入一批 MCP Servers),通过 Stdio 方式最理想场景是 MCP Servers 和 Agent 系统跑在同一 Docker 容器中(类似 Sidecar 模式)。

举个例子:接入地图厂商的 MCP Server 后,Agent 具备生活服务工具能力,远远优于单纯依赖搜索的方式。
未来
目前的 MCP 开发非常初级,在工程化上缺少一套完善的框架来约束和规范。
根据 MCP Roadmap,未来主要三件事:
Remote MCP Support:鉴权、服务发现、无状态服务,很明显奔着 K8S 架构去的,这样才能构建一个生产级、可扩展的 MCP 服务。根据最近的 RFC Replace HTTP+SSE with new "Streamable HTTP" transport,支持 Streamable HTTP,可以低延迟、双向传输。
Agent Support:提升不同领域复杂的 Agent 工作流,并可以处理更好的人机交互。
Developer Ecosystem:更多的开发者和大厂商参与进来,才能扩展 AI Agent 的能力边界。
实践下来,MCP Server SSE 并不是理想的方案,因为需要保持连接和 session 状态,而云服务(如 FaaS)更倾向于无状态架构(issue#273),所以最近提出了更适配云场景的 Streamable HTTP Transport。
MCP 模型调用与 RL 强化学习:如果 MCP 成为未来的规范,那么 Agent 应用能否准确调用各个 MCP,将成为模型 RL 未来需要支持的关键功能。与 Function Call 模型不同,MCP 是一个动态的工具库,模型需要具备对新增 MCP 的泛化理解能力。
Agent K8S:虽然目前 LLM 和上下文之间建立了标准化的通信协议,但 Agent 之间的交互协议尚未形成统一标准,Agent 服务发现、恢复、监控等一系列生产级问题等解决。目前 Google 的 A2A(Agent2Agent) 和社区的 ANP(Agent Network Protocol)在做这方面的探索与尝试。
评论