如果 Agent Harness 仅仅能读取本地代码、执行本地命令，其能力其实已经相当强大。然而，现实中的工程任务并非局限于代码仓库之内——需求可能散落在飞书或 Notion 中，设计稿挂在 Figma 上，任务追踪在 Jira 里，接口文档可能藏在某个内部平台，线上数据存储在数据库，告警信息又堆积在监控系统中。如果 Agent 无法触达这些系统，它所能看到的仅仅是“工程现场”的冰山一角。
MCP，全称为模型上下文协议（Model Context Protocol），它要解决的核心问题，恰恰就是这种“连接”难题。
官方对 MCP 的定义是：一个开放标准，专门用于将 AI 应用连接到外部系统——包括数据源、工具和工作流。许多人形象地将其称为“AI 应用的 USB-C 接口”，这个比喻确实非常贴切。
为何需要 MCP 协议
在缺乏 MCP 之前，情况确实相当棘手。每个 Agent 工具都需要为每个外部系统单独编写一套适配逻辑。
举个例子：假设你想让 Claude Code、Cursor 和 Codex 都能访问公司内部的接口文档。传统做法是什么？分别给这三套工具开发三个插件。而且必须维护三套完全不同的认证机制、三套工具描述以及三套调用逻辑——接口稍微改动，三个地方都得同步修改。
MCP 的思路则清晰得多：外部系统直接实现一个 MCP Server，而 Agent Harness 这一侧实现一个 MCP Client。只要双方遵循同一个协议，同一个 Server 就可以被不同的 AI 工具重复调用。
这样一来，工具能力便从“某个产品的专属插件”，摇身一变为“可复用的标准协议服务”。
MCP Server 提供的能力
具体来说，一个 MCP Server 可以对外暴露三类核心能力。
第一类是 Tools。也就是模型可以直接调用的函数，例如：
search_docs(query)
get_ticket(id)
query_database(sql)
create_pr_comment(text)
第二类是 Resources。指模型能够读取的结构化数据，例如某个文档、某张数据表的 schema 定义，或是某个设计稿的元信息。
第三类是 Prompts。即预定义好的工作流或提示模板，比如“生成发布说明”、“分析事故复盘报告”或“创建接口变更评审”。当然，在实际应用中，Tools 使用最为频繁——因为只有它才能让 Agent 真正“动”起来。
MCP 在 Harness 中的定位
需要明确的是，MCP 既不是模型本身，也不是 Agent 的本体。它是 Harness 的一个工具扩展层。
用户在下达任务后，模型会判断是否需要外部信息。如果需要，Harness 就会将所有可用的 MCP 工具展示给模型，由模型选择调用哪个工具，MCP Server 执行并返回结果，这个结果再被送入上下文，供模型做进一步处理。
这里有一个关键点：模型自始至终没有直接访问外部系统。所有的外部交互，都发生在 Harness 和 MCP Server 的严格控制之下。
真实应用场景
假设给你的 Agent 一个任务：
根据设计稿实现新的订单详情页，并确认接口字段是否已经上线。
在没有 MCP 的时候，Agent 只能对着代码束手无策。它不知道设计稿长什么样，也不清楚接口文档是否已经更新。有了 MCP，整个流程就完全不同了：
- 从 Figma MCP 读取设计稿的具体信息；
- 从接口文档 MCP 查询订单详情相关的字段；
- 从代码仓库读取现有的页面代码；
- 修改 UI 以满足设计稿要求；
- 运行测试或截图来验证效果；
- 最后输出字段差异和尚未确认的项。
这便是 MCP 的真正价值：它将 Agent 从“代码仓库”这个孤立环境，真正带入了“真实的工程上下文”之中。
安全问题不容忽视
MCP 在让 Agent 变得更加强大的同时，也显著提升了风险等级。
一个只能查阅文档的 MCP 自然不会造成太大问题。但如果某个 MCP 能够写入数据库、提交工单甚至直接部署服务，那么它就必须受到严格管控。
一个比较务实的分级建议如下：
| 类型 | 示例 | 策略 |
|---|---|---|
| 只读数据 | 查询文档、读取 schema | 可自动调用，记录日志 |
| 低风险写入 | 创建草稿、生成评论 | 可确认后执行 |
| 高风险操作 | 修改生产数据、部署、删除资源 | 禁止或强制审批 |
请务必注意，不能因为 MCP 是标准协议，就默认它一定是安全的。协议只负责“连接”，安全这件事，需要 Harness、Server 和企业策略三方联手才能兜得住。
MCP Server 设计指南
第一，工具的描述必须清晰明了。模型是依据工具名称和描述来选择工具的。不要使用 `doThing` 这类模糊的名称，应老老实实命名为 `search_api_docs`。
第二，返回的结果要结构化。不要直接返回一段杂乱无章的日志，最好返回结构清晰的 JSON、一份 Markdown 摘要以及几个关键字段。
第三，权限尽量在服务端施加。不要单纯依赖 Agent Harness 来做判断。MCP Server 自身也需要校验用户的身份和权限。
第四，默认设为只读模式。写操作的数量能少则少，并且必须明确、可审计。
第五，避免工具列表过于庞大。工具一旦增多，模型的选择能力反而会下降。可以根据项目或角色来拆分不同的 Server。
总结
归根结底，MCP 的意义并非为了让 Agent 多几个花哨的插件。而是让外部系统能够以一种统一的方式，顺利地接入 Agent Harness。
它解决的，是所有工程开发者都深有体会的“上下文割裂”问题：
代码在仓库
需求在工单
设计在 Figma
文档在知识库
数据在数据库
动作在各种内部系统
MCP 将这些原本散落在各处的系统，全部接到了 Agent 能够调用的工具层中。在真正落地时，重点不仅在于“能接上”，更在于“接得安全、接得可控、接得可审计”。
