当 Agent 已经有 Shell，MCP 还有什么用？

我对 Codex 说：“读取这个 PR 的全部讨论，并找出它关联的 Issue。”它完全可以执行 gh pr view、gh api 和 gh issue view。遇到一级命令没有覆盖的字段，它还可以直接调用 REST 或 GraphQL API，自己处理分页和过滤。

那么，GitHub MCP 到底多做了什么？

同一个 Agent 面前的 CLI 与 MCP

我一开始得到的解释都很熟悉：MCP 可以管理凭证，没有 Shell 时更安全，接入多个平台也不用分别适配，官方 MCP 天生更适合 Agent。听起来都有道理，往下追问却开始松动。这些解释常常把“协议为什么存在”说成了“每个人为什么都该用它”。

我的态度很直接：能用 Shell 和 gh，我就先用 gh。等同一批工具需要交给多个 Host，或者确实要按工具统一施加策略时，我才会接受这层 Server。

`gh` 已经能做什么

先把现代 CLI 的能力摆在桌面上。

gh pr、gh issue、gh repo、gh run 已经覆盖了大量日常操作。许多命令能用 --json 返回结构化结果，再交给 --jq 过滤；exit code 表示成败，Shell 负责和文件、脚本或其他程序组合。gh api 则是它留给用户的后手：只要 GitHub 公开了 API，即使一级子命令还没覆盖，Agent 往往也能直接调用。¹²

例如，常规 PR 信息可以这样读取：³

gh pr view 123 --repo owner/repo `
  --json title,body,comments,reviews,closingIssuesReferences

如果“全部讨论”还包括代码行上的 Review Comment，就继续查询并分页：

gh api repos/owner/repo/pulls/123/comments --paginate
gh api repos/owner/repo/pulls/123/reviews --paginate

麻烦在于，“全部讨论”根本不是一个字段。PR 的整体对话、Review 正文、Diff 行评论和 Commit Comment 属于不同的数据。一个命令未必能全部收齐，Agent 还可以调用 gh api graphql 或对应的 REST Endpoint。它通常受限于 GitHub 是否公开相关 API，以及当前 Token 有没有权限，而不是受限于 CLI 这层外壳。²⁴

“关联 Issue”同样有几种含义。要读取会被 PR 关闭的 Issue，可以看 closingIssuesReferences；要建立自动关闭关系，最稳妥的办法是在 PR Body 中加入 Fixes #123。这类 Closing Keyword 还受目标分支等规则约束。⁵

CLI 与 MCP 最终都要到达平台 API，区别在于中间接口由谁定义

一个 GitHub MCP Server 如果只包装了十几个高层工具，覆盖面完全可能小于 gh。

MCP 到底规定了什么

MCP 全称 Model Context Protocol。既然叫协议，先看它到底约定了什么，别急着比较谁更强。gh 是面向 GitHub 的具体客户端，MCP 则规定 Client 与 Server 怎样交谈，它们原本就不在同一层。

按当前 2026-07-28 规范，MCP 分成 Host、Client 和 Server 三个角色。Host 承载模型与交互界面，并维护一个或多个 MCP Client。Client 再去连接对应的 Server。Server 可以是本地进程，也可以是远程服务，对外提供 Tools、Resources 和 Prompts。⁶

MCP 规定能力如何暴露和调用，但不规定 Server 内部怎样完成业务

它主要把下面这些接口说清楚：

消息遵循 JSON-RPC 2.0，方法、参数、结果和错误具有统一结构。⁷
tools/list 返回工具名称、描述和输入 JSON Schema，并可附带输出 Schema；列表响应本身还可以提供缓存期限与缓存范围。⁸
Client 使用 tools/call 传递工具名与参数；结果可以包含文本、图像、资源链接或结构化 JSON，也可以表达业务执行错误。
Resources 和 Prompts 有对应的发现与读取接口；标准传输包括 stdio 和 Streamable HTTP，同时允许自定义 Transport。⁹
HTTP Transport 可以选择采用 MCP 的授权框架。它管的是 Client 如何访问受保护的 MCP Server，不负责 MCP Server 如何登录 GitHub。¹⁰

MCP 2026-07-28 下工具发现与调用的基本时序

至于 read_pr_discussion 收哪些评论、凭证放哪里、内部用 REST、GraphQL 还是 CLI，MCP 都不管。它只把 Client 和 Server 的接头定下来；业务适配由 Server 作者完成，Agent 能不能选对工具又是上一层的问题。

几种常见说法，我为什么不买账

“MCP 能代持凭证”不是答案

MCP 的 HTTP Authorization 只管 Client 到远程 Server 这一段。Server 怎样登录 GitHub、Token 需要哪些 Scope，属于下一段路。远程 MCP 仍可能要求浏览器授权或管理员预配凭证，本地 stdio Server 通常还是从环境中取凭证。CLI 也能用浏览器登录、PAT、环境变量或系统凭据存储；gh auth login 本身就支持浏览器流程。区别在部署方式，不在 MCP 三个字。¹³

Host 围绕标准化工具调用做确认、权限控制和审计，确实会更顺手。Shell 也能被沙箱、拦截和记录，只是它暴露的执行能力更宽。两者的治理成本不同，不能简化成“有 MCP 才安全”。

适配工作被搬进了 Server

GitHub、GitLab、Jira 和 Notion 的 API、权限模型、分页方式、数据结构都不一样。每个平台照样要写对应实现。MCP 做的，是让这些实现以相似的形状暴露给 Agent Host。

MCP 统一了外部接头，平台内部的适配齿轮并没有消失

自己开发 Agent 时，走 CLI 要安装并理解各平台的命令；走 MCP 要配置各平台的 Server。后者可能让 Client 侧更整齐，平台差异却一项也没少。

Schema 解决的是接口描述

Schema 有用，这一点没必要否认。统一的 JSON Schema 能减少参数拼写和输出解析成本，Host 也不用每次现读 CLI 的 --help。可它只描述接口，不会替模型规划。工具太多、描述含糊、抽象层次不一致时，Agent 还是会选错。

少量高层工具可能更好选，也可能因为包得太厚，碰到边角需求就无能为力。低质量的 MCP Server，套上标准接口后仍然低质量。

拿掉 Shell，证明不了 MCP 对强 Agent 必需

面向普通用户的聊天产品可能不开放 Shell，企业助手也可能只允许调用审核过的工具。这样的 Host 确实需要一个受控入口，MCP 很合适。

可这和本文讨论的强 Coding Agent 不是同一道题。一个功能完整的 Coding Agent 如果连 Shell 都没有，失去的不只 gh，还有编译器、包管理器、测试工具、Git 和大量本地自动化能力。先拿掉它的大部分能力，再证明 MCP 必不可少，前提已经被换掉了。

什么时候值得多这一层

我会在什么时候加 MCP？同一套内部工具不再只给 Codex，而要同时接入 IDE、桌面聊天客户端和企业工作台时。继续逐个接入，意味着每个 Host 都要重新处理认证方式、能力目录、参数和结果；采用 MCP 后，各 Host 可以复用同一套 Client 逻辑，与对应的 Server 分别通信，服务侧则按系统提供相应的 Server。工具没有少写，但不用反复谈接口。

另一个收益是工具级治理。Host 可以按 Server 或工具配置确认、审计与权限策略，也能为结构化结果做专用界面。Shell 同样能管，只是判断任意命令会做什么更难。Schema 和工具注解可以辅助治理，不能替可信实现背书。⁸

MCP 的收益落在复用和治理上，并没有多出 CLI 做不到的业务能力。多 Host 时，复用收益才真正明显；即便只有一个 Host，也可能因为工具级治理而选择 MCP。对已有 Shell 的单个强 Agent 来说，它的边际收益往往很小，还会增加维护成本。

Server 里面照样可以跑 `gh`

MCP 与 CLI 不必二选一。Server 对外说 MCP，对内完全可以调用 gh。

Agent / Host
  → MCP Client
  → MCP Server
  → gh CLI
  → GitHub API

Server 对外可以只提供一个边界清楚的工具：

read_pr_discussion(owner, repo, pr_number)

内部继续复用 gh：

gh pr view $pr --repo $repo --json comments,reviews
gh api "repos/$repo/pulls/$pr/comments" --paginate

MCP Server 可以在内部复用 gh，协议边界只存在于 Client 与 Server 之间

gh 继续处理 GitHub 的认证与 API 细节，Server 只挑出一部分能力，整理成 Host 能发现的工具。差别落在 Agent 最终能看到什么：完整的平台接口，还是 Server 挑好的一组工具。

我会怎么选

场景	默认选择
一个强 Agent、本地 Shell、成熟 CLI	CLI
临时任务、调试、脚本和批处理	CLI
需要完整平台能力或原始 API 逃生口	CLI
同一能力需要接入多个 Agent Host	MCP
Host 需要统一工具 Schema、确认和专用 UI	MCP
企业集中维护一组稳定、受控的工具	MCP
已有成熟 CLI，又要服务多个 MCP Client	MCP Server 包装 CLI
MCP Server 覆盖有限，而 CLI 很成熟	CLI

我的默认选择仍是 gh。只有两种情况我会加 MCP：同一批能力要供多个 Host 共用，或 Host 需要统一的工具级策略。其余时候，它就是额外的一层。叫它鸡肋，并不冤。

GitHub CLI，官方命令手册。 ↩
GitHub CLI，gh api 手册。 ↩ ↩²
GitHub CLI，gh pr view 手册。 ↩
GitHub Docs，Working with comments。 ↩
GitHub Docs，Linking a pull request to an issue。 ↩
Model Context Protocol，Architecture。 ↩
Model Context Protocol，Base Protocol。 ↩
Model Context Protocol，Tools。 ↩ ↩²
Model Context Protocol，Transports。 ↩
Model Context Protocol，Authorization。 ↩
Model Context Protocol，Discovery。 ↩
Model Context Protocol Blog，2026-07-28 release notes。 ↩
GitHub CLI，gh auth login 手册。 ↩