值得关注的执行层 MCP

上个月我在调试一个前端页面，Claude Code 帮我改完代码之后，我习惯性地手动打开浏览器、登录、点击、确认。整个流程大概花了两分钟。

两分钟不算长，但我忽然意识到一件事：这两分钟里，我只是在帮 AI 执行一个它自己也能完成的验证步骤。它写完了代码，却看不见页面长什么样。

这其实是当前 AI 编程的一个普遍状态：AI 写代码，人负责让代码跑起来、验证结果、处理异常。人成了 AI 的手和眼睛。

而过去几个月，一批新的 MCP 正在改变这件事。

它们解决的问题和 Context7、知识库搜索不太一样。那些 MCP 做的事情是：

AI 不知道
    ↓
调用 MCP
    ↓
获得信息
    ↓
AI 知道了

比如查一份最新框架文档、搜索一个内部知识库。这些能力可以明显减少幻觉，也能提升 Coding Agent 的判断质量，但最后真正执行的人，很多时候还是你。

而最近我更关注另一类 MCP。它们不只是在回答"答案是什么"，而是直接给 AI 一双手。

用户目标
   ↓
Agent 判断下一步
   ↓
调用 MCP Tool
   ↓
真实系统执行动作
   ↓
返回执行结果
   ↓
Agent 判断是否成功
   ↓
继续执行 / 修复 / 回滚

我习惯把这类东西叫做执行层 MCP。这并不是 MCP 官方定义的分类，只是一个比较方便理解的工程视角。它背后真正有意思的地方，是 AI 编程开始从"代码生成"走向"任务执行"。

MCP 真正改变的，不只是上下文

MCP 的全称是 Model Context Protocol。所以最初很多人很自然地把它理解成"给模型补充 Context 的协议"。这个理解没错，但已经有点窄了。

MCP 官方对它的定位，本身就包含了数据访问和外部工具调用。2026 年 7 月发布的新协议版本甚至进一步改成了无状态核心，每一个 tools/call 请求都可以独立完成，并增加了基于 Mcp-Method、Mcp-Name 等 HTTP Header 的路由能力。这种变化明显更适合负载均衡、网关、权限控制和企业级部署。

一个典型 MCP Tool，可以简单理解为：

┌──────────────┐
│     LLM      │
└──────┬───────┘
       │ 判断调用什么工具
       ▼
┌──────────────┐
│  MCP Client  │
└──────┬───────┘
       │ tools/call
       ▼
┌──────────────┐
│  MCP Server  │
└──────┬───────┘
       │
       ▼
 GitHub / K8s / Browser / Database / Cloud / CI

从模型视角看，它可能只看到 deploy_application、restart_service、create_pull_request、run_sql 这些函数名。至于背后到底调用 GitHub API、Kubernetes API、Chrome DevTools Protocol 还是数据库连接池，模型并不一定需要关心。

这其实就是 MCP 很重要的一点：把现实世界中的能力，抽象成模型能理解和调用的 Tool。

所以 MCP 真正值得关注的，从来不只是 Read、Search、Retrieve，还有 Create、Update、Delete、Deploy、Execute、Restart、Rollback。而一旦 Tool 从"读"进入"写"，事情就完全不一样了。

一个真正的执行闭环是什么样

以前我们用 AI 编程，常见流程是：

需求 → AI 写代码 → 我复制代码 → 我运行 → 报错 → 把报错贴给 AI → AI 修改 → 我再运行

仔细想想，人实际上充当了一层非常低效的 RPC。AI 说"帮我运行一下"，你说"好"。AI 说"把错误给我"，你说"好"。AI 说"改完以后再运行"，你说"好"。

如果 Coding Agent 本身拥有 Shell、浏览器和外部系统 Tool，这个过程就可以变成：

理解目标 → 修改代码 → 执行构建
              ↓
         是否成功？
         ↙       ↘
        否         是
        ↓          ↓
    分析错误     启动应用
        ↓          ↓
     修改代码   浏览器验证
        ↑          ↓
        └──────结果正确？
               ↙       ↘
              否         是
              ↓          ↓
           定位问题    提交代码
              ↓
           修改代码

这里开始出现一个很重要的 Agent 模式：Act → Observe → Reason → Act。执行一个动作，观察现实世界发生了什么，再决定下一步。这和一次性生成代码，是完全不同的 AI 编程方式。

Chrome DevTools MCP：让 AI 真正"看见"自己写出来的页面

如果现在让我推荐一个最能体现执行层 MCP 价值的项目，我会把 Chrome DevTools MCP 放在很前面。

它不是简单读取 HTML，而是直接让 Coding Agent 控制和检查一个真实运行中的 Chrome。目前官方能力包括浏览器自动化、Console 分析、Network 请求检查、截图以及 Performance Trace 等。

于是前端 Vibe Coding 可以形成这样一个循环：

修改 Vue/React 代码 → 启动开发服务器 → Chrome DevTools MCP
                                              ↓
                                           打开页面
                                              ↓
                                       检查页面 / Console / Network
                                              ↓
                                        是否存在问题？
                                        ↙            ↘
                                       是              否
                                       ↓               ↓
                                   定位源码        任务完成
                                       ↓
                                   修改代码

以前你可能会告诉 Claude："这个接口好像没调成功。"以后可以直接说：

启动项目并打开登录页。检查实际页面效果、Console 和 Network。完成登录流程，如果出现异常自行定位代码并修复，直到整个登录流程正常。

区别非常大。前一种方式是人类观察世界，然后描述给 AI。后一种方式是AI 自己观察世界。

Playwright MCP：从调试页面走向验收业务

Chrome DevTools 更偏开发调试，Playwright MCP 则特别适合业务流程执行。

它的一个设计挺有意思：AI 并不一定需要看截图，而是读取页面的 Accessibility Tree。比如页面在模型眼里可能是：

heading "登录"
textbox "手机号" [ref=e5]
textbox "密码" [ref=e8]
button "登录" [ref=e12]

然后模型直接调用 click e12、fill e5、fill e8。

于是我们终于可以让 AI 做以前需要人手动做的验收：

启动系统，登录管理员账号，创建一个学生，搜索刚刚创建的学生，进入详情页，修改学生信息，保存，刷新页面，确认修改结果仍然存在。

整个过程完全可以是一个 Agent Loop。

不过 Playwright 官方现在明确提到：对于 Coding Agent，高频自动化场景下 CLI + Skills 可能比 MCP 更节省 Token，因为不用长期把大量 Tool Schema 和 Accessibility Tree 放进上下文；而 MCP 更适合需要持续浏览器状态、探索性操作和复杂 Agent Loop 的场景。

这其实也是现在选 MCP 时很值得注意的一点：不是所有能力都应该 MCP 化。 如果 Claude Code 本来就能很好地运行一个 CLI，再包一层 MCP 不一定更先进。

GitHub MCP：让 AI 进入研发流程

GitHub 官方 MCP Server 也是一个非常典型的执行型 MCP。它现在已经覆盖 Repository、Issue、Pull Request、Git、GitHub Actions、Code Security、Dependabot 等能力，并且可以通过 Toolsets 精确控制向 Agent 暴露哪些功能，官方还提供了 --read-only 模式。

为什么这一点重要？因为真正的 AI Coding Workflow 会变成：

读取 Issue → 分析代码 → 修改代码 → 运行测试 → 创建 Branch → 提交代码 → 创建 PR → 等待 CI
                                                                            ↓
                                                                      CI 成功？
                                                                     ↙        ↘
                                                                    否          是
                                                                    ↓           ↓
                                                               读取日志    等待 Review
                                                                    ↓
                                                                修改代码

以前 AI Coding 到"代码写完了"基本就结束了。现在"写代码"反而只是整个 Agent Workflow 中间的一个节点。这也是我越来越觉得：未来 Coding Agent 的竞争重点，不只是模型写代码有多强，而是谁能完成更长的工程闭环。

Kubernetes MCP：AI 开始碰运行环境

再继续往下，就进入 DevOps 了。containers/kubernetes-mcp-server 已经可以对 Kubernetes Resource 执行 Create、Update、Get、List、Delete 等操作。

于是可以出现这种 Prompt：

把当前服务部署到 dev namespace。部署以后等待 Pod Ready。如果 Pod 无法启动，检查状态、查看日志、定位代码或配置问题、修复、重新部署。最后访问健康检查接口确认服务正常。

Agent 背后的实际动作是：build → push image → update deployment → watch pod → read logs → health check。

到这里，AI 已经不再只是 Coding Agent。某种程度上，它正在变成一个小型 Software Engineer + DevOps Engineer。

Terraform MCP：再往下一层就是基础设施

HashiCorp 官方 Terraform MCP Server 已经支持 HCP Terraform 的 Workspace 管理，包括变量、Tag 以及 Run 等操作。于是 Agent 理论上可以继续向下：

需要测试环境 → 生成 Terraform → 创建 Workspace → 配置 Variables → Terraform Plan
                                                                        ↓
                                                                    需要审批？
                                                                   ↙        ↘
                                                                  是          否
                                                                  ↓           ↓
                                                             Human       Apply
                                                             Approval      ↓
                                                                  ↓     创建基础设施
                                                              Apply →       ↓
                                                                          部署应用
                                                                             ↓
                                                                          验证环境

这一层开始真正碰到 VM、Database、Network、Load Balancer、DNS、Cloud Resource。

所以越往执行层走，越会发现一个问题：AI 能不能执行已经不是最困难的问题。真正困难的是：AI 应该被允许执行到什么程度？

数据库 MCP：很好用，也是我最谨慎的一类

Google 维护的 MCP Toolbox for Databases 已经支持 MySQL、PostgreSQL、MariaDB、SQL Server、Oracle、MongoDB、Redis、Elasticsearch、ClickHouse、Neo4j、Snowflake 等大量数据库，并提供 list_tables、execute_sql 等通用工具。

对于后端 Coding Agent 来说，这非常舒服。以前代码和真实数据库 Schema 是两个世界，现在 Agent 可以：读取 Mapper → 检查数据库表 → 查看索引 → 执行 EXPLAIN → 修改 SQL → 重新 EXPLAIN → 验证优化结果。

但数据库也是我最不建议"无脑给权限"的 MCP。开发环境可以允许 SELECT、INSERT、UPDATE、CREATE、ALTER，而生产环境最好只开放 SELECT、SHOW、EXPLAIN。

甚至进一步，不给 AI 一个通用的 execute_sql(sql)，而是给 get_user_by_id(id)、query_order_status(order_id)、get_slow_queries(start_time, end_time)、explain_query(query_id) 这类明确的工具。表面看起来第二种能力弱了，实际上企业环境里反而更强——能力越明确，权限越容易治理。

为什么我不太推荐"万能 Shell MCP"

看到这里可能会想到：那是不是搞一个 execute_shell(command) 就什么都解决了？理论上当然可以，实际上我反而不建议。

因为 Claude Code、Codex 这种 Coding Agent 本来就有很强的本地 Shell 能力：git、npm、mvn、gradle、docker、curl、python、go。再套一层 Shell MCP 很多时候只是重复建设。

更重要的是，在企业环境里，execute_shell("anything") 几乎等于给 Agent 一把万能钥匙。

真正好的执行层 Tool 应该尽量从 execute_command 收敛成 deploy_service、restart_service、rollback_release、create_pull_request、run_database_migration、get_application_logs。AI 不需要知道怎么 SSH 上服务器再执行十条 Bash，它只需要知道"我要回滚 payment-service 到上一个稳定版本"。至于背后的执行方式，由平台决定。

执行层 MCP 最终一定会碰到 Gateway

当 MCP Server 只有两三个时，问题不大。但当企业逐渐出现 GitHub、GitLab、Jenkins、Kubernetes、Docker、Harbor、MySQL、Redis、Prometheus、Grafana、Nacos、内部业务系统、内部审批系统……你很快会发现：让每个 Agent 分别连接十几个 MCP Server，并不是一个好架构。

更合理的形态会慢慢变成 MCP Gateway：

Claude / Codex / Agent → MCP Gateway
                              ↓
              ┌───────────────┼───────────────┐
              ↓               ↓               ↓
         Authentication  Authorization      Routing
              ↓               ↓               ↓
         Rate Limit         Audit         Approval
              ↓               ↓               ↓
              └───────────────┼───────────────┘
                              ↓
              ┌───────────────┼───────────────┐
              ↓               ↓               ↓
        GitHub MCP      Kubernetes MCP  Database MCP
              ↓               ↓               ↓
              └───────────────┼───────────────┘
                              ↓
                          Real Systems

Docker 现在的 MCP Gateway 就已经明显往这个方向走。它定位成 MCP Client 与多个 MCP Server 之间的统一代理，负责 Server Lifecycle、Routing、Authentication，并将 MCP Server 放入受限制的 Docker Container 中运行。

这种架构其实已经越来越像 AI Agent 的执行控制平面。

真正困难的是执行之前那一层

比如 Agent 想调用 restart_service。如果目标是开发环境，问题不大。如果目标是生产环境呢？

再比如 delete_database。理论上 MCP Tool Schema 完全可以定义这个工具，但"协议允许调用"和"企业允许执行"完全是两回事。

我认为一个真正可用的执行层 MCP 架构至少应该有：

Agent Request → Policy Engine → 风险等级判断
                              ↙       ↓        ↘
                            低        中         高
                            ↓         ↓          ↓
                        自动执行   规则校验   人工审批
                            ↑         ↓          ↓
                            └───── 通过?     通过?
                                     ↙ ↘      ↙ ↘
                                    是 否     是 否
                                    ↓  ↓      ↓  ↓
                                 执行 拒绝   执行 拒绝
                                    ↓
                                Audit Log

这时候 MCP 才真正从一个"AI 插件协议"进入企业基础设施。

我现在比较推荐的执行层 MCP

如果主要场景是 Claude Code、Codex 这样的 Coding Agent，我目前会重点关注下面几类：

但我不会把这些东西全部永久开启。更合理的是按场景组合。

日常开发：Context7 + Serena + Chrome DevTools + GitHub 需要测试时增加：Playwright 后端排查：Database Toolbox DevOps 场景：Kubernetes + Terraform

不要给一个 Agent 一次性塞几十个 MCP Tool。Tool 越多不一定越聪明，有时候只是让模型面对一个越来越大的工具箱，不知道该拿哪把扳手。

AI 编程真正值得期待的，可能不是"代码写得更快"

过去一两年大家聊 AI Coding，最容易想到的是"以前写一个接口 30 分钟，现在 AI 3 分钟写完"。当然很爽，但我越来越觉得，这可能只是 AI 编程最早期的一层价值。

真正发生变化的是整个软件工程链路正在逐渐被 Tool 化：

需求 → 设计 → 编码 → 测试 → 代码评审 → CI/CD → 部署 → 监控 → 故障处理
  ↑      ↑      ↑      ↑        ↑        ↑      ↑      ↑        ↑
  └──────┴──────┴──────┴────────┴────────┴──────┴──────┴────────┘
                             AI Agent

当 GitHub、浏览器、数据库、Kubernetes、Terraform、监控平台逐渐都拥有标准化 Tool 接口后，Agent 能覆盖的就不再只是中间那个"编码"节点。它开始沿着软件生命周期向两边扩散。

这时候 AI Coding 的问题，也会从"AI 能不能帮我写代码？"慢慢变成"我愿意把整个工程链路中的哪些权限交给 AI？"

这两个问题差别非常大。前者主要是模型能力问题，后者已经是软件架构、权限、安全、审计、审批和组织治理问题。

所以如果今天让我看 MCP，我反而不会太纠结又出了多少个"帮 AI 查资料"的 Server。我更关注的是：AI 的手，已经伸到哪里了。 以及更重要的：在它真的能够执行之前，我们有没有准备好控制这双手。