Harness 第一季完结后，我花了一个月研究 MCP——发现这才是它的真正形态

第一季 12 篇写完了，我其实挺失落的。

你别说，写了整整一个月 Harness，从插件开发到多模型混搭再到生产级部署，我一度以为自己把这家伙摸透了。结果第一季收尾那天，我随手翻了翻 GitHub 上 Harness 的 issues 区，发现有人在讨论一个叫 MCP 的东西——Model Context Protocol，模型上下文协议。

当时我第一反应是：又一个协议？

笑死，我被打脸了。而且打得很惨。

事情是这样的

我花了一个月时间，把 MCP 从概念到实战啃了一遍。说实话，越研究越觉得：「Harness 第一季我是不是白写了？」倒不是说 Harness 不行，而是我意识到一个更本质的问题——Harness 的插件体系虽然强，但它缺一个「标准化的毛细血管」来连接外面的世界。

MCP 就是那个毛细血管。

先说清楚 MCP 是什么。它不是又一个 API 规范，也不是什么新的 Agent 框架。MCP（Model Context Protocol）是 Anthropic 提出的一套开放协议，专门用来标准化 AI 模型和外部工具之间的通信方式。你可以把它理解为「AI 世界的 USB-C 接口」——不管你是 GPT、Claude 还是 DeepSeek，只要对接上 MCP，就能用同一套方式调用数据库、文件系统、浏览器、GitHub 甚至企业 IM。

我第一次跑 Harness 的时候，插件写得很爽，但每次要接入一个新工具，都得自己写一堆胶水代码。比如要接入数据库，得写一个 DatabaseTool 类，实现 run 方法，还要处理参数解析、错误返回、超时控制……而且每个插件接口都不一样。你写一个 MySQL 插件，和写一个 Redis 插件，接口签名可能完全不同。时间长了，你的插件目录就变成了一个「代码坟场」。

有意思的是，MCP 解决的就是这个痛点。它定义了一套标准化的工具描述协议——你的工具只要实现了 MCP 的接口，任何支持 MCP 的 Agent 框架都能直接调用。这意味着你不需要为每个 Agent 框架写不同的插件了。你写一个 MySQL MCP Server，Harness 能用，Claude Code 能用，甚至以后出的新框架，只要支持 MCP，也能直接用。

我一开始觉得这太理想化了。但实测下来发现，MCP 的接口设计确实很聪明——它把工具抽象成三个核心概念：Resource（资源）、Tool（工具）、Prompt（提示模板）。Resource 是 Agent 可以读取的外部数据（比如文件内容、数据库查询结果），Tool 是 Agent 可以调用的动作（比如发送消息、执行代码），Prompt 是预定义的交互模板。这三个概念覆盖了 Agent 和外部世界交互的几乎所有场景。

笑死，我第一次跑通 MCP Server 的时候，Harness 里只写了三行配置代码，就把一个本地文件系统暴露给了 Agent。三行。相比之前写一个完整的 Harness 插件要写几十行模板代码，这体验差距太大了。

当然，MCP 也不是银弹。它现在的生态还比较早期——官方的 MCP Server 清单只有几十个，而且很多是社区贡献的，质量参差不齐。我试过几个数据库 MCP Server，有的连基本的连接池都没做，跑一次就断连。另外 MCP 自身的安全模型也还在完善中——如果一个 MCP Server 暴露了文件系统操作，Agent 会不会不小心删掉重要文件？这些在实际落地中都是坑。

但话说回来，MCP 的方向是我这几年看到的最靠谱的。它不是在造一个新的轮子，而是在给现有的轮子定一个统一规格。Harness 的「一切皆插件」理念，加上 MCP 的标准化协议，就像给一个已经有强大引擎的车，装上了标准的拖车接口——你去哪都能拉东西。

你觉得 MCP 会成为 Agent 世界的标准协议吗？还是说每个大厂都会搞一套自己的协议，最后变成「战国时代」？我很好奇你的看法。下一篇咱们动手写一个 MCP Server，从零开始，让 Harness 真正「长出触角」。