skill是什么？MCP是什么？tool又是什么？

别急着去找定义，先问问自己——你搭过Agent吗？

---

一、我曾经也以为，这些都是"新瓶装旧酒"

说实话，我曾经也是那个追着新概念跑的人。

skill、MCP、tool、agent framework……每个新概念出来，我的第一反应都是：这不就是换了个名字吗？

skill？不就是提示词嘛，套个markdown模板，降低用户写prompt的成本。

MCP？不就是RPC调用嘛，换个协议封装一下。

tool？不就是函数调用嘛，LLM时代改了个名字叫function calling。

我甚至一度觉得，这些东西本质上都是一样的，新瓶装旧酒，不过是圈子里的黑话，用来抬高门槛、制造焦虑的。

直到我真的开始搭一个Agent。

---

二、当你真的去搭一个Agent，才会发现"痛点"是真实存在的

我用的模型是 qwen3-8B，量化版本 q4_k_m，通过 llama.cpp 本地部署。

自己写了个 MCP Server，实现了几个工具调用，接了个记忆模块，心想：这不就齐活了？

结果一测试，问题接踵而至。

问题一：模型"突然抽风"

有时候对话好好的，模型突然就开始疯狂调用工具，智能ctrl+c,强行中断modle

问题二：记忆模块"间歇性失忆"

记忆系统有时候能正常提取，有时候LLM事实提取为空，标签命名直接降级成"未命名"。

明明上一轮还记得的事情，下一轮就忘了。

问题三：工具调用的"边界失控"

模型不知道什么时候该停。该用工具的时候不用，不该用的时候乱用。你给它一个 get_subdir_list，它可能顺手就把整个目录树给你翻个底朝天。

这些问题，不是"概念"能解决的，是工程问题。

---

三、Harness Engineering：不是新概念，是新痛点

面对这些问题，我的第一反应是什么？

加限制。

在 client 或者 server 端加一个检测：如果工具调用次数超过 N 次，强制中断。

甚至直接断开 MCP 连接，让模型停下来。

这就是 Harness Engineering（约束工程） 的一部分。

它不是某个框架、某个库、某个协议。它是你在实际搭建过程中，为了解决"模型行为不可控"这个问题，而不得不做的一系列工程化约束。

• 限制工具调用次数

• 设置超时机制

• 添加调用链路的熔断器

• 对模型输出做后校验

• 给记忆系统加一致性检查

这些东西，没有现成的库给你用。

MCP 不管这个。Skill 不管这个。Tool 也不管这个。

这是你自己的业务逻辑，是你必须亲手写的"缰绳"。

---

四、为什么我说"新概念的提出是痛点的解决方案"

现在回头看，skill、MCP、tool，它们真的只是"新瓶装旧酒"吗？

不是。

它们每一个概念的背后，都是一群真正搭过Agent的人，在解决真实痛点时，提炼出来的最佳实践。

Skill 不是"提示词模板"

产品侧的 skill，确实是个 markdown 文件，降低用户写 prompt 的成本。

但技术侧的 skill，是一个可复用的功能模块，包含完整的感知、决策、规划、工具调用。它有 SKILL.md 定义输入输出，有 tools/ 目录封装业务逻辑，有 config.yaml 管理配置。

为什么需要这么多结构？

因为当你把 skill 复用到第三个 Agent 的时候，你会发现：没有标准化，就是灾难。

MCP 不是"RPC 换皮"

MCP 解决的是外部系统连接的标准化问题。

浏览器、网站、数据库、文件系统——这些东西已经有人写好了、维护好了，你通过 MCP 直接调用就行。

如果没有 MCP，你每接一个新的外部工具，都要重新写一遍适配层。

Tool 不是"函数调用"

Tool 是模型与外部世界交互的接口定义。

它要解决的是：如何让模型"理解"这个工具能干什么、需要什么参数、返回什么结果。

这不是简单的函数签名，是语义对齐的问题。

---

五、Agent Skill 和 MCP：互补，不是替代

MCP已死？

我的答案是：不见得，他们是互补关系。

表格

场景	用 Skill	用 MCP
业务逻辑（核心、定制）	✅	❌
外部系统（浏览器、网站、数据库）	❌	✅

业务逻辑放 skill，外部连接走 MCP，二者相辅相成。

这不是谁取代谁的问题，是分工的问题。

就像你写后端服务，核心业务代码自己写，第三方服务用 SDK——道理是一样的。

---

六、写在最后：走进圈子，才能理解概念

我一度认为这些概念都是一样的，是因为我没有真正走进去。

当你真的去搭一个 AI，真的去调一个 8B 量化模型，真的去写一个 MCP Server，真的去处理模型"抽风"的问题——

你才会发现：

新概念的提出，从来不是新瓶装旧酒。

它们是前人踩过的坑、流过的汗、熬过的夜，最后封装成的解决方案。

Harness Engineering 也是如此。

它不是某个框架的名字，不是某个论文的术语。

它是你在亲手搭建 Agent 的过程中，为了解决"模型不可控"这个真实痛点，而不得不做的一系列工程化实践。

概念是表象，痛点是本质。

只有真正走过这条路的人，才能分辨其中的区别。

---

"没有调查，就没有发言权。"

在 AI 时代，这句话变成了：

"没有搭过 Agent，就没有资格说'新瓶装旧酒'。