阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/MCPSkillAgentLLMHarness-guanxiquanjingtu/ 「芋道源码」欢迎转载，保留摘要，谢谢！

• 新人最容易在这 5 个名词上崩溃
• 一张图先把关系讲清楚
• LLM：什么都读过的”大脑”
• Agent：给大脑装上手脚
• Skill：Agent 的”具体手艺”
• MCP：让 Agent 接外部工具的”USB-C”
• Harness：把 AI 调试稳了再上线的”工作台”
• 一张表收口：5 个概念的层级关系
• 最后说一句

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

新人最容易在这 5 个名词上崩溃

最近不少同事问我：「LLM、Agent、Skill、MCP、Harness——这一堆词到底什么关系？谁包谁、谁调谁？」

打开任意一篇 AI 文章，5 个词混着用：一会儿说 Agent 调用 MCP，一会儿说 LLM 跑 Skill，一会儿又冒出 Harness。单个词都能查到定义，但放一起就糊了。

问题不在概念本身——问题在大家解释概念时，只讲是什么、不讲谁依赖谁。这一篇用一张图把 5 者的依赖关系画出来，再用大白话挨个 30 秒讲清楚。

一张图先把关系讲清楚

记住一条主线：LLM 是大脑，Agent 是身体，Skill 是手艺，MCP 是接口，Harness 是工作台。

概念	在体系里扮演什么	依赖谁
LLM	大脑（只会想）	无
Agent	身体（手脚都全）	LLM
Skill	一项手艺	Agent
MCP	工具的统一插头	Agent + 外部工具
Harness	调试 / 跑评测的工作台	上面 4 个

下面挨个讲，每个 30 秒搞定。

LLM：什么都读过的”大脑”

LLM = Large Language Model，大语言模型。

可以理解成一个什么书都翻过的学霸——你问什么它都能答，但它只会动嘴：不会查数据库、不会发邮件、不会执行命令。

举例：你问 GPT-4「今天北京天气怎么样」，它会承认「我没法实时联网」——它能聊天气知识，但没法主动去查。

LLM 是底座，剩下 4 个名词都是为了让 LLM 真的能干活搭出来的。

Agent：给大脑装上手脚

Agent = 智能体，等于 LLM + 一组可调用的工具 + 自主决策循环。

还是「查天气发邮件」的例子：

• LLM 自己只会回答「我不知道」；
• Agent 会拆任务——先调天气 API、再调邮件 API、最后写一段总结发出去。

整个过程的关键是 Agent Loop：每一步都让 LLM 看一眼当前状态，决定下一步调什么工具，反复跑直到任务完成。Claude Code、Cursor、OpenHands 这些都是 Agent 的具体实现。

判断标准——能”自己决定下一步做什么”的，就是 Agent；只会回答问题的，是 LLM。

Skill：Agent 的”具体手艺”

Skill = Agent 会的一项具体活，封装一个完整的工作流。

比如：

• 「审一个 PR 的 Skill」——读 diff、检查规范、给评论；
• 「生成 Vue 组件的 Skill」——按团队规范出代码；
• 「写微信公众号的 Skill」——按公众号风格改写文章（就是这篇文章用的）。

Skill vs Agent：Agent 是引擎，Skill 是「这个引擎会哪些套路」。一个 Agent 可以有几十上百个 Skill——用到哪个加载哪个，按需触发，不占上下文。

具体到 Claude Code：每个 Skill 就是一个 SKILL.md 文件，写清「什么时候用、怎么用」，Claude 自己识别匹配，不需要你手动喊。

MCP：让 Agent 接外部工具的”USB-C”

MCP = Model Context Protocol，模型上下文协议——Anthropic 推的开放标准。

它解决的是一个工程问题：Agent 要调外部工具（GitHub、Notion、Slack、数据库），怎么调？

• 没有 MCP 之前——每个工具都得写一套适配代码；接 GitHub 写一份、接 Notion 写一份、接 Slack 再写一份；
• 有了 MCP 之后——工具方按 MCP 规范暴露接口，Agent 端插上就能用，跟 USB-C 一样。

类比理解——MCP 之于 Agent，就像 HTTP 之于浏览器：一个统一协议把”百花齐放的工具”和”统一调用的客户端”对接起来。

现在 GitHub、Notion、Slack、Sentry、阿里云 OSS、Linear 这些主流服务都已经有官方或社区的 MCP Server，Agent 拿来即用。

Harness：把 AI 调试稳了再上线的”工作台”

Harness = AI 应用的开发 / 测试 / 评测平台——把 AI 应用打磨稳了再上线的”工作台”。

把上面 4 个东西（LLM / Agent / Skill / MCP）拼起来真要落到生产里，会冒出一堆问题：

• 怎么知道 Agent 答得对不对？
• 怎么跑回归测试？（提示词改一下，几百个 case 要重跑）
• 怎么追踪 token 消耗、延迟、失败率？
• 怎么对比不同模型 / 不同提示词的效果？

Harness 就是干这个的——把”AI 跑通”和”AI 跑稳”这两件事分开：跑通靠 Agent + Skill + MCP，跑稳靠 Harness。

代表性的工具：LangSmith、Helicone、OpenAI Evals、Anthropic 内部的 Symphony / 评测框架，以及国内的 Dify、FastGPT 等也带轻量级 Harness 能力。

判断标准——想让 AI 应用”上生产关键链路”，Harness 是绕不开的一环。

一张表收口：5 个概念的层级关系

层级	概念	一句话	没它会怎样
底座	LLM	大脑，只会想	啥也没有
执行体	Agent	LLM + 工具 + 决策循环	只能聊天，不能干活
能力包	Skill	Agent 的具体手艺，按需加载	啥都得当场临时写
工具协议	MCP	Agent 调外部服务的 USB-C 接口	每接一个工具写一套代码
质量保障	Harness	调试 + 评测 + 监控的工作台	上线靠玄学，bug 靠用户报

学习顺序建议——从下往上一层一层来：先搞清 LLM 是什么、再玩 Agent（用 Claude Code 上手最快）、再尝试写 Skill 和接 MCP、最后想往生产里塞才碰 Harness。跳着学最容易把自己绕晕。

最后说一句

5 个名词放一起一定要看清楚两件事：

• LLM、Agent、Skill 是”实体”——它们是真实存在的代码 / 模型；
• MCP、Harness 是”基础设施”——前者是接外部工具的协议，后者是开发它们的工作台。

一句话总结：

LLM 是脑、Agent 是身、Skill 是手艺、MCP 是插头、Harness 是工作间——五个角色各司其职，AI 应用才跑得起来、跑得稳。