2781 字
14 分钟
MCP 协议成为 AI Agent 的「通用语」:从 claude-context 看 2026 年的工具连接标准

一个协议改变一切#

兄弟们,你们有没有想过一个问题: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 psutil
import json
import sys
from 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 sqlite3
import json
from 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 response

MCP 生态的参与方式#

如果你想参与 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 入手都是最省力的路径。标准已经就位,生态正在繁荣,剩下的就是你的想象力了。

MCP 协议成为 AI Agent 的「通用语」:从 claude-context 看 2026 年的工具连接标准
https://www.oferry.com/posts/a120/
作者
晨平安
发布于
2026-06-02
许可协议
CC BY-NC-SA 4.0
封面
示例歌曲
示例艺术家
封面
示例歌曲
示例艺术家
0:00 / 0:00