七个概念一张表：Function Calling、MCP、Skill、Tool、Harness、RAG、微调
Function Calling（函数调用）、MCP、Skill、Tool、Harness、RAG、微调——这七个词经常在同一段话里出现，但没几个人能说清谁管谁。
它们不是七个并列的技术，而是三个层次上的七种角色。
这张表就是用来一次性对齐的。
一、三个问题，七个概念
与其背定义，不如用三个可回答的问题，把任何一个新名词定位下来。
问题一：它改不改模型文件？ 改，就是微调，没有第二个答案。不改，进下一题。答不上来，通常说明还没分清"配置"和"训练"：一个改文件，一个改权重。
问题二：它管表达意图，还是管连接工具？ 管表达，是 Function Calling。管连接，是 MCP。两个都答不清，多半是把"工具怎么连上"和"模型怎么开口"当成了一件事。
问题三：它管流程，还是管知识？ 管流程，是 Skill。管知识，是 RAG。如果它管的是"把这些东西怎么组织起来"，那是 Harness。答不清，说明需求还停在"帮我干这件事"这一句，没拆到步骤、资料和先后顺序。
三个问题问完，位置基本就定了。Tool 是例外，只负责被调用。
二、一张表填完
| 概念 | 解决什么问题 | 在哪一层 | 改不改模型文件 |
|---|---|---|---|
| Function Calling | 模型怎么表达"我要调谁" | 模型侧表达层 | 不改 |
| MCP | 工具怎么被发现、怎么复用 | 工具侧接入层 | 不改 |
| Skill | 这件事按什么步骤干 | 业务封装层 | 不改 |
| Tool | 一个可被调用的具体能力 | 宿主侧执行单元 | 不改 |
| Harness | 模型外面那一圈怎么组织 | 编排层 | 不改 |
| RAG | 知识从哪来、怎么按需注入 | 知识注入手段 | 不改 |
| 微调 | 怎么把行为写进参数 | 训练层 | 改 |
Tool 这一行采用本文口径——它与 Skill 的边界常被含糊带过。定义：Tool 是一个可被模型请求调用、由宿主真正执行的函数、接口或命令；Skill 则是用这些 Tool 完成一件事的流程。
配七个反例：
| 概念 | 一句话反例 |
|---|---|
| Function Calling | 以为模型真的执行了工具 |
| MCP | 以为 MCP 会替模型调工具 |
| Skill | 以为 Skill 是高级 Prompt |
| Tool | 把 Tool 当成 Skill |
| Harness | 以为 Harness 只是一堆工具 |
| RAG | 以为 RAG 就是上下文工程全部 |
| 微调 | 以为微调能灌进大量新知识 |
表里还有两个位置要说明。MCP 的协议横跨内外：Client 在 Harness 里，Server 在世界里；RAG 也一样，切分与注入在 Harness 里，向量库和语料在外面。所以"在哪一层"指的是主导角色，不是全部物理位置。
三、三条判定线
表是结果，判定线才是能迁移的方法。
线一：按位置分。 表达归 Function Calling，连接归 MCP，流程归 Skill，编排归 Harness。这条线回答"它在流水线上站哪一环"。
边界在于：位置只说明它站哪一环，不说明它能不能单独存在。Function Calling 可以没有 MCP 照样工作；MCP 的价值是复用，不是表达。
线二：按对象分。 知识走 RAG（外部注入）或继续预训练（内部注入），行为走微调，流程走 Skill。这条线回答"它想改变的是信息还是行为"。
注意知识这一格有两个入口，最容易漏：微调改不了"知道什么"，继续预训练可以，但它要动参数，成本高得多。
取舍只看两条：要不要动参数、能不能等一轮训练。只改行为又要频繁迭代，走上下文；行为稳定且长期不变，才值得动微调。
线三：按形态分。 内容资产（SKILL.md、工具 schema）和运行时机制（加载、校验、执行）是两回事。同一个概念常常一半是内容、一半是机制：Skill 的文件是内容，把它发现和注入的那套机制属于 Harness。
边界在更新方式：内容资产改一次是改文件，运行时机制改一次是改代码。同一个名词落在哪边，决定你更新它要不要发版。
遇到新名词时，按这三条过一次：
- 它改不改模型文件；
- 它站在表达、连接、流程、编排的哪一环；
- 它是内容资产，还是运行时机制。
三条都答得出来，这个概念就不会再和别的混在一起。
四、三组高频混淆
混淆都发生在"看起来在做同一件事"的地方。
Function Calling 与 MCP。 一个负责"说"，一个负责"接"。用了 MCP 之后，Function Calling 并没有消失，它仍在底层把模型的意图翻译成结构化调用。插座通了，手还在。
小实验：把同一个工具先直连、再经 MCP 接入。直连能跑通，说明缺的从来不是表达，是复用。
Skill 与 Tool。 Tool 是一个可调用的能力，Skill 是一套用这些能力的流程。同一个 Tool 可以被十个 Skill 调用；同一个 Skill 也可以调十个 Tool。它们不是同一层的替代关系，是零件和工序的关系。
小实验：删掉流程，只留工具。还能完成任务的是 Tool；任务散了，说明真正起作用的是 Skill 那套步骤。
Skill 与微调。 两者都能让模型"按规矩办事"，但改的位置完全不同。
| Skill | 微调 | |
|---|---|---|
| 改什么 | 上下文里的内容 | 模型参数 |
| 更新方式 | 热更新，改文件即生效 | 冷更新，要重训 |
| 能否共享 | 能，跨宿主复用 | 难，带领域偏向 |
| 适用条件 | 具体、常迭代的流程 | 确定、长期不变的行为 |
有人会问：既然两者都能实现同一个业务决策，为什么不能混着说？因为代价不同。Skill 改一次是改一份文档，微调改一次是重训一轮。混淆它们，选型时就会拿最贵的工具去干最便宜的活。
小实验：把同一套规则只写进上下文跑一遍。规则生效就不用重训；只有上下文压不住、且长期不变，才轮到微调。
结尾
概念不是用来背的，是用来定位的。三个问题问完，任何一个新名词都能被放进这张表。
补一句最容易记错的：模型只输出调用意图，真正跑工具的是宿主。
