一个协议改变一切
兄弟们,你们有没有想过一个问题:AI Agent 为什么总是「看起来很厉害,用起来一般般」?
原因很简单——Agent 跟外部工具的交互太混乱了。有的用 REST API,有的用 WebSocket,有的直接执行 shell 命令,有的用自己发明的 DSL。每个 Agent 都要自己实现一套工具调用逻辑,开发者每切换一个 Agent 就要重新学一套工具接口规范。
就在这种混乱中,Anthropic 推动的 MCP(Model Context Protocol) 悄然成为了事实标准。2026 年,MCP 已经被超过 500 个项目所支持,从代码编辑到数据库查询,从浏览器控制到文件操作,Agent 终于有了一套通用的「交流语言」。
MCP 到底是什么?
别被「Model Context Protocol」这个高大上的名字吓到。MCP 本质上就是一套定义好的 JSON-RPC 协议,规定了 AI 模型如何向外部工具发起请求、工具如何返回结果。就像 HTTP 是 Web 的通用协议一样,MCP 要成为 AI Agent 的工具调用通用协议。
MCP 的核心设计非常简洁。一个 MCP 工具就是一个暴露出来的「端点」,定义了输入参数和输出格式。Agent 通过 tools/list 发现可用工具,通过 tools/call 调用工具,通过 resources/read 读取外部数据源。
// MCP 工具定义的 JSON Schema 示例{ "name": "search_codebase", "description": "在代码库中搜索匹配特定模式的代码片段", "inputSchema": { "type": "object", "properties": { "pattern": { "type": "string", "description": "搜索的正则表达式或文本模式" }, "fileGlob": { "type": "string", "description": "文件过滤模式,如 *.py 或 *.tsx", "default": "*" }, "maxResults": { "type": "integer", "description": "最大返回结果数", "default": 20 } }, "required": ["pattern"] }}claude-context:MCP 生态的明星项目
在这次 MCP 浪潮中最亮眼的项目之一,是 Zilliz 出品的 claude-context。这个项目目前在 GitHub 上有 8.3K+ stars,增长非常迅猛。它的功能是什么呢?简单说就是给 Claude Code 装上「记忆」和「上下文管理」能力。
传统的 AI 编码工具有一个共同的问题:每次对话都是「全新开始」的。你上周让它重构了一个模块,这周再问它那个模块的架构,它已经忘了——因为对话上下文已经清空了。claude-context 通过 MCP 协议把长期记忆能力注入到 Agent 中,实现跨会话的记忆持久化。
# 使用 claude-context MCP 服务器from mcp import ClientSession, StdioServerParameters
# 启动 claude-context 的 MCP 服务器server_params = StdioServerParameters( command="python", args=["-m", "claude_context.server"])
async with ClientSession(server_params) as session: # 列出可用工具 tools = await session.list_tools() print("可用工具:", [t.name for t in tools]) # 输出: ['store_memory', 'retrieve_memory', 'search_knowledge', 'index_project']
# 存储关于项目架构的记忆 await session.call_tool("store_memory", { "key": "project/arch/auth", "content": "认证模块使用 JWT + Redis 会话缓存,Token 有效期 2 小时", "tags": ["auth", "architecture", "jwt"] })
# 下次会话时检索 result = await session.call_tool("retrieve_memory", { "query": "认证模块是怎么设计的?", "max_results": 3 }) print(result.content[0].text)如何开发你自己的 MCP 工具?
MCP 协议的精髓在于「低门槛接入」。任何语言都可以实现 MCP 服务器,只要遵循 JSON-RPC 2.0 规范即可。下面是一个用 Python 实现的简单 MCP 工具示例:
# 一个简单的 MCP 服务器:获取当前系统信息import psutilimport jsonimport sysfrom mcp.server import Server, stdio_server
app = Server("system-info")
@app.tool("get_system_stats")async def get_system_stats(include_disk: bool = False) -> str: """获取系统资源使用情况统计""" cpu_percent = psutil.cpu_percent(interval=1) memory = psutil.virtual_memory()
result = { "cpu": f"{cpu_percent}%", "memory": { "total": f"{memory.total / 1024**3:.1f}GB", "used": f"{memory.used / 1024**3:.1f}GB", "percent": f"{memory.percent}%" }, "processes": len(psutil.pids()) }
if include_disk: disk = psutil.disk_usage("/") result["disk"] = { "total": f"{disk.total / 1024**3:.1f}GB", "used": f"{disk.used / 1024**3:.1f}GB", "percent": f"{disk.percent}%" }
return json.dumps(result, ensure_ascii=False)
if __name__ == "__main__": stdio_server.run(app)MCP 的实际应用场景
说了半天理论,来几个实际的案例让大家感受一下 MCP 能做什么。
场景一:让 AI Agent 直接操作数据库
以前要让 AI 帮你查数据库,你需要先把 SQL 语句拷贝到数据库客户端里执行,再把结果粘贴回来。有了 MCP 之后,你可以直接部署一个数据库 MCP 服务器,Agent 自动发送 SQL 查询、接收结果,整个过程完全自动化。
# 数据库 MCP 服务器 — 让 Agent 直接执行 SQL 查询import sqlite3import jsonfrom mcp.server import Server, stdio_server
app = Server("database-query")
@app.tool("query_database")async def query_database(sql: str, limit: int = 50) -> str: """执行 SQL 查询并返回结果""" conn = sqlite3.connect("production.db") cursor = conn.cursor() try: cursor.execute(sql) rows = cursor.fetchmany(limit) columns = [desc[0] for desc in cursor.description] result = [dict(zip(columns, row)) for row in rows] return json.dumps(result, ensure_ascii=False, default=str) except Exception as e: return f"查询失败: {str(e)}" finally: conn.close()场景二:让 AI Agent 管理 CI/CD 流水线
你可以在 CI/CD 系统中嵌入 MCP 服务器,让 AI Agent 在发现代码中的问题后自动触发回滚、调整部署策略或者通知相关人员。这个能力在大型团队中尤其有用——它大大缩短了从发现问题到执行操作的延迟。
MCP 的局限性
诚实地讲,MCP 也不是银弹。我在使用过程中遇到了几个问题:
第一是安全性。MCP 协议目前没有内置的权限控制机制。如果一个 Agent 能调用所有暴露出来的工具,那理论上它可以做任何操作——包括删除数据库、修改生产环境配置。目前的做法是在 MCP 服务器外面套一层代理来做权限校验,但这是社区自己加的,不是协议标准的一部分。
第二是工具的发现和治理。当你的组织里有几百个 MCP 工具时,如何让 Agent 找到正确的工具?目前的 tools/list 返回的是平面列表,没有层级分类和标签系统。大模型的注意力窗口有限,当工具列表超过几十个时,模型选择工具的正确率会明显下降。
不过好消息是,这些问题都是有解的。Anthropic 和社区正在推动 MCP 2.0 规范,预计会加入权限分级、工具分组和服务发现等新特性。届时 MCP 的可用性和安全性会上一个大台阶。
MCP 与竞争对手的对比
聊 MCP 的时候不能不提到它的竞争对手们。Google 力推的 A2A(Agent-to-Agent)协议、OpenAI 的 Function Calling 规范、以及社区自发形成的各种工具描述格式,都在试图解决同一个问题。
MCP 跟 A2A 的定位其实不太一样。A2A 解决的是 Agent 之间如何通信的问题——翻译一下就是一个 Agent 如何找另一个 Agent 帮忙干活。而 MCP 解决的是 Agent 如何调用工具的问题——Agent 怎么读写文件、怎么查数据库、怎么调用 API。两者是互补关系而非竞争关系。
OpenAI 的 Function Calling 虽然是最早的实践,但它的问题是跟 OpenAI 的 API 深度绑定。其他模型想要支持同样的功能,需要自己实现兼容层。而 MCP 从设计之初就是协议级别的——任何语言、任何模型、任何平台都可以实现 MCP 客户端或服务端。
# MCP 客户端 — 任何模型都可以用,不限于某个厂商from mcp import ClientSession
async def extract_data_with_any_model(model, query: str): """ 让任何模型通过 MCP 工具获取外部数据 model 参数可以是 OpenAI、Anthropic、GLM 等任意兼容的 API """ async with ClientSession() as session: tools = await session.list_tools() result = await session.call_tool("query_database", { "sql": f"SELECT * FROM datasets WHERE description LIKE '%{query}%'" }) response = await model.generate( prompt=f"基于以下数据回答用户问题:{result.content[0].text}", tools=tools # 模型可以自主决定是否使用工具 ) return responseMCP 生态的参与方式
如果你想参与 MCP 生态,有几种方式:
最轻量:在你的项目中集成现有的 MCP 工具。比如用 MCP 的 GitHub 工具来自动化 PR 管理,用 MCP 的文件系统工具来让 Agent 直接读写项目文件。只需要几行配置就能让 AI Agent 获得操作能力。
进阶:为你自己的服务开发 MCP 服务器。比如你的团队有一个内部的部署平台,给它加一个 MCP 接口,AI 就可以直接帮你部署服务了。我花了一个下午给团队的自建监控系统写了一个 MCP 服务器,现在用自然语言就能查询服务器状态和报警信息了。
# 给内部监控系统添加 MCP 接口from mcp.server import Server, stdio_server
app = Server("monitor")
@app.tool("check_service_health")async def check_health(service_name: str) -> str: """检查指定服务的健康状态""" result = await monitor_client.query(f"SELECT * FROM health WHERE service='{service_name}'") return format_health_report(result)
@app.tool("list_alerts")async def list_active_alerts(severity: str = "critical") -> str: """列出当前活跃的报警信息""" alerts = await monitor_client.query(f"SELECT * FROM alerts WHERE severity='{severity}' AND resolved=false") return format_alerts(alerts)深入:参与 MCP 协议本身的标准制定。MCP 2.0 正在开发中,Anthropic 在 GitHub 上公开了 RFC 流程,任何人都可以提交改进建议。
MCP 的社区实践
最后分享一个我自己的实践案例。上个月我们团队内部需要搭建一个自动化运维系统,需求是让值班工程师可以通过聊天窗口用自然语言查询服务器状态、重启服务、查看日志。按照以前的思路,我们需要写一个 ChatOps 机器人,对接 Slack 的 API、写一堆命令解析器、配置各种认证和权限。现在有了 MCP 之后,整个方案变得非常简单:我们写了三个 MCP 服务器(服务器监控、日志查询、服务管理),然后让 Claude Code 通过 MCP 客户端去调用这些工具。整个过程只用了两天,核心代码不到五百行。这个案例说明了一个趋势:MCP 不仅仅是给 AI 研究员用的高级协议,它也可以成为团队内部工具集成的基础设施。当你把所有内部工具都暴露为 MCP 接口后,任何一个兼容 MCP 的 AI Agent 都能成为你团队的智能运维助手。不需要开发专门的 UI 界面,不需要写一堆 API 文档,自然语言就是最好的用户界面。这个理念在 2026 年正在被越来越多的团队验证,我强烈建议你在自己的团队里也尝试一下。
MCP 正在改变一切
MCP 协议的普及正在深刻改变 AI 工具的开发方式。以前开发者要为每个 Agent 单独开发工具适配层,现在只需要实现一个 MCP 服务器,所有兼容 MCP 的 Agent 都能直接用。从 Chrome DevTools MCP(让 AI Agent 直接操作浏览器开发者工具)到向量数据库 MCP 集成,MCP 正在成为连接 AI 和外部世界的「通用语言」。
对于开发者来说,现在入场 MCP 生态正当时。无论你是想给团队的工具集成 AI 能力,还是想开发一个 AI 原生的新工具,从 MCP 入手都是最省力的路径。标准已经就位,生态正在繁荣,剩下的就是你的想象力了。