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 的控制下。
真实场景
假设任务是：
根据设计稿实现新的订单详情页，并确认接口字段是否已经上线。
没有 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 可调用的工具层里。真正落地时，重点不只是“能接”，更是“接得安全、可控、可审计”。
