MCP 实战一年：我是怎么把 AI Agent 接进真实工作流的

2025-12-21 约 1454 字预计阅读 3 分钟

先说 MCP 解决了什么问题

在 MCP 出现之前，每个 AI Agent 工具集成都要自己写：

        
        
        
    
# 以前：每个 Agent 项目都要重复造轮子
class MyAgent:
    def __init__(self):
        self.github = CustomGitHubTool(...)   # 自己封装
        self.db = CustomDBTool(...)           # 自己封装
        self.filesystem = CustomFSTool(...)   # 自己封装

# MCP 出现后：
class MyAgent:
    def __init__(self):
        self.mcp_client = MCPClient()
        self.mcp_client.connect("github")      # 复用现成的
        self.mcp_client.connect("postgres")   # 复用现成的

MCP 的核心价值：工具一次实现，所有 Agent 复用。

我这一年搭建的工作流

1. GitHub + Claude Code 工作流

        
# 配置 MCP Server
claude mcp add github -- npx -y @anthropic/mcp-server-github

# 日常工作：
# 用自然语言操作 GitHub
# "帮我看看最近有哪些 PR 有冲突"
# "把这个分支的代码 review 一下"
# "给这个 issue 加个 label"

实测效率提升：以前要做 10 分钟的 GitHub 操作，现在一句话。

2. 数据库 + AI 分析

        
# 配置数据库 MCP Server
claude mcp add postgres -- npx -y @modelcontextprotocol/postgres-server

# 直接用自然语言查数据库
# "我们数据库里有多少用户？"
# "最近一周的 DAU 是多少？"
# "帮我看一下 orders 表有哪些索引"

这个场景特别有价值——以前查数据库要写 SQL，现在直接问。

3. 文件系统 + 代码库分析

MCP 的 filesystem server 让 AI 直接读写磁盘：

        
# 实际场景：
# AI 可以直接读代码文件
# AI 可以直接写代码文件
# AI 可以搜索整个代码库

# "帮我把 users/ 目录下的所有 Python 文件迁移到 users_v2/"
# AI 直接操作文件系统，不需要人来执行

踩过的坑

坑 1：MCP Server 安全权限过大

        
        
        
    
# 我最初配置的 GitHub MCP Server：
{
  "command": "npx",
  "args": ["@anthropic/mcp-server-github"],
  "env": {
    "GITHUB_TOKEN": "full_access_token"
  }
}

# 问题：这个 token 有所有仓库的读写权限
# 如果 AI 误操作，可能删掉重要代码

修复：给 MCP Server 用最小权限 token。

        
# 只读 token 用于代码审查
# 写操作需要额外确认

坑 2：MCP Server 响应超时

        
        
        
    
# 某些 MCP Server（比如数据库）可能很慢
# AI 发了一个复杂查询，MCP Server 30 秒没响应
# AI 就卡住了

# 解决：给每个 Server 设置 timeout
{
  "timeout": 30000,  # 30 秒超时
  "retry": 2         # 重试 2 次
}

坑 3：MCP Server 版本不兼容

        
# MCP 协议在快速演进
# Server A 用的是旧版 MCP SDK
# Client B 用的是新版 MCP 协议
# 连不上

# 解决：锁定版本，不要用 @latest

最值的 3 个 MCP Server

根据我这一年的使用频率：

Server	使用频率	价值
GitHub MCP Server	每天 20+ 次	⭐⭐⭐⭐⭐
Filesystem	每天 10+ 次	⭐⭐⭐⭐⭐
PostgreSQL	每周 10+ 次	⭐⭐⭐⭐
Slack	每周 5 次	⭐⭐⭐
Redis	每月 5 次	⭐⭐

MCP 不适合的场景

1. 实时性要求高的操作

        
# 不要用 MCP 做：
# - 高频 API 调用（比如每秒 100 次）
# - 需要毫秒级响应的交互
# - 长时间运行的批处理任务

# MCP 的设计是"低频高价值"，不是"高频自动化"

2. 需要事务保证的操作

        
        
        
    
# MCP Server 执行的是独立操作
# 如果你需要"先查后改"的原子性
# MCP 不能保证中间状态

# 例如：
# 1. 读取当前值
# 2. 基于值计算新值
# 3. 写回新值
# → 在步骤 1-3 之间，其他操作可能干扰

3. 复杂业务流程

        
# MCP 是工具层，不是业务流程层
# 如果你需要复杂的跨系统协调
# 用工作流引擎（Temporal/Airflow）
# 不要把业务流程写在 prompt 里

架构建议

        
        
        
    
# 我的 MCP 工作流架构：

# MCP Gateway（统一入口）
#     ↓
# MCP Client（连接各 Server）
#     ↓
# ├── GitHub Server（代码、PR、Issues）
# ├── Filesystem Server（代码库）
# ├── PostgreSQL Server（数据查询）
# ├── Slack Server（团队通知）
# └── Custom Server（内部工具）

# AI Agent
#     ↓
# 调用 MCP Tool（语义层）
#     ↓
# 执行具体操作

分层清晰，出问题好排查。

一年后的结论

MCP 的价值：让 AI Agent 从"能聊天"变成"能干活"。

以前 AI Agent 只能和你对话，现在可以真正操作外部系统——查 GitHub、改数据库、发 Slack 消息。

但 MCP 不是银弹：安全权限、稳定性、事务保证都需要额外考虑。

建议：先从 GitHub + Filesystem 这两个最常用的 Server 开始，觉得顺手了再扩展到其他系统。

项目地址：modelcontextprotocol.io