编码 Agent 跑久了一定会遇到这个需求：模型需要查 Jira、读 Notion、操作数据库、调内部部署系统。你可以为每个外部系统硬编码一个工具，但这会让 harness 和一堆第三方 API 紧耦合。MCP（Model Context Protocol）就是为解耦这件事而生的——它是工具供给侧的"标准插座"。这篇讲 MCP 在编码 harness 里的定位、它和你自带工具的关系，以及接入时要注意的工程问题。

MCP 在工具面里的位置

回到工具面设计的底座：模型能做事，是因为 harness 给它暴露了一组工具（tool surface）。这些工具的来源可以分两类——

  • harness 内建工具：bash、text editor、glob/grep 这类你自己实现、自己执行的工具。
  • 外部接入工具：通过 MCP 从一个独立的 MCP Server 拉进来的工具。

MCP 的核心价值是：MCP Server 自描述它提供哪些工具（名字、参数 schema、说明）。harness 作为 MCP Client 在启动时握手、拉取这份工具清单，把它们和内建工具混在同一个 tool surface 里交给模型。模型并不区分"这个工具是我 harness 自带的还是 MCP 来的"——对它而言都只是可调用的工具。

1
2
3
4
5
6
模型看到的 tool surface
├── bash            (harness 内建)
├── edit_file       (harness 内建)
├── jira.create     (MCP: jira-server)
├── jira.search     (MCP: jira-server)
└── postgres.query  (MCP: db-server)

换句话说，MCP 把"接入一个外部系统"从"在 harness 里写死一个工具"降级成了"配一个 server 地址"。

它和"提升为专用工具"是什么关系

值得澄清一个常见混淆。前面我们讨论过：要不要把 bash 里的某个动作提升为 typed 专用工具，判据是门控、渲染、审计、并行。MCP 不替代这个决策——它替代的是这个专用工具的实现与分发方式。

也就是说，一旦你决定"查 Jira 应该是个专用工具"（因为它需要审计、可能需要门控），你有两种实现路径：

  1. 在 harness 进程里手写 jira_create 工具，直接调 Jira REST API。
  2. 起一个 Jira MCP Server，由它暴露工具，harness 通过 MCP 接进来。

后者的好处是这个 Jira Server 可以被任意 MCP Client 复用（你的编码 Agent、别人的 IDE、另一个 harness），且 Jira 凭据/逻辑都收敛在 Server 里，不污染 harness。代价是多了一跳进程间通信和一层协议。

接入时的工程清单

把 MCP 接进编码 harness，下面几件事必须想清楚。

1. 门控仍然是 harness 的责任

MCP Server 只是声明工具，它不替你做安全决策。一个 db.execute(sql) 工具来自 MCP，并不意味着它就安全了——它可能 DROP TABLE。可逆性判据照样适用：harness 在调用 MCP 工具前，仍要按"是否不可逆/外发"决定要不要弹确认、要不要走策略门。把 MCP 工具当成"来源不同但同样需要门控的专用工具"来对待。

2. 命名空间与工具爆炸

接三个 MCP Server，可能一下涌进几十个工具。工具太多会稀释模型的注意力、撑大上下文里的工具描述。实务上要：给工具加 server 前缀避免重名（jira.search vs github.search）；按任务按需启用某些 server，而不是把所有工具永远全量暴露。

3. 失败与超时

MCP 工具是跨进程/跨网络调用，会超时、会断连、Server 会崩。harness 必须把这些失败转成模型能理解的结构化错误回灌，而不是让整个 Agent 循环挂死。给每个 MCP 调用设超时和重试边界。

1
2
3
4
5
6
try:
    result = mcp_client.call(tool, args, timeout=30)
except MCPTimeout:
    return tool_error("MCP server 'jira' 超时；可重试或换路径")
except MCPDisconnected:
    return tool_error("MCP server 'jira' 断连；该工具本轮不可用")

4. client-side 执行的边界

MCP 工具的执行发生在 MCP Server 那侧，但触发与结果消费在你的 harness。这意味着审计日志、用户确认 UI、上下文回灌这些"渲染层"职责仍然落在 harness。MCP 给了你工具的定义和执行，但工具调用如何呈现给用户、结果如何进上下文，依然是 harness 工程。

关注点 谁负责
工具定义（schema/说明） MCP Server
工具执行 MCP Server
是否门控/确认 harness（Client）
渲染/审计/回灌 harness（Client）
并行调度 harness（Client）

什么时候用 MCP，什么时候别用

如果某个外部能力只有你这一个 harness 用、逻辑简单、凭据本来就在手边，直接在 harness 里写个工具更省事，别为它引入 MCP 的协议开销。当这个能力需要被多个客户端复用、需要把凭据和集成逻辑从 harness 里隔离出去、或者你想接入生态里已有的现成 Server 时，MCP 才显出价值。

一句话总结：MCP 是工具供给侧的标准插座，它解决的是"外部工具如何接进来"，但门控、渲染、审计、调度这些控制权，依然牢牢握在 harness 手里。