在 AI Agent 工程里反复出现的”Skill、Tool、MCP、Memory、Harness”五个词，分的其实是五层职责：连接、能力、流程、状态、运行环境。判断一段能力该沉淀成哪一类，要回到”它解决的是哪一层的问题”——这一层决定了它的运行时形态、维护成本与替换难度。下面从职责边界、典型形态与判断依据三方面展开。
一、五个概念的职责定位
| 概念 | 职责层 | 核心问题 | 典型载体 |
|---|---|---|---|
| MCP | 连接层 | 怎么把模型稳定地接到外部系统 | JSON-RPC 2.0 协议，本地 stdio 或远端 HTTP |
| Tool | 动作层 | 模型能直接执行的最小动作是什么 | 单一函数，有明确入参 / 出参 |
| Skill | 流程层 | 如何把多步任务稳定跑成 SOP | 以 SKILL.md 为核心的指令与检查清单 |
| Memory | 状态层 | 跨会话 / 跨调用如何保留上下文 | 长期记忆文件、向量库、KV 缓存 |
| Harness | 运行环境层 | 谁来调度 Agent 与它的工具链 | 评测脚本、CI 流水线、Agent 运行时 |
MCP 解决”连哪里”；Tool 解决”做什么”；Skill 解决”怎么稳定做好”；Memory 解决”上一次走到了哪一步”；Harness 解决”由谁来跑、怎么评测”。任何一类都不该越界做另一类的事。
二、各自的运行时形态
2.1 MCP：连接层
MCP 由 Anthropic 在 2024 年 11 月开源，是一套基于 JSON-RPC 2.0 的客户端 / 服务器协议，本地通过 stdio 通信，远端通过 HTTP 通信。模型侧通过 tools/list 发现能力，通过 tools/call 触发动作。一次接入即可被多个 MCP 兼容 Agent 共用，避免每个 AI 应用重复造轮子。
2.2 Tool：动作层
Tool 是 Function Calling 层面的最小单元：一个入参、一个动作、一个结构化返回。它有强确定性，能写测试用例，能用 mock 验证，但不带任何业务规则与流程编排。示例包括 read_file、create_jira_ticket、run_bash_command，这些都只描述”我能做什么”，不回答”该按什么顺序、达到什么质量标准”。
2.3 Skill：流程层
Skill 以 SKILL.md 为核心，本质是一组被 LLM 解释执行的指令、资源与检查项。加载策略通常采用”渐进式披露”：启动时只读取元数据（YAML frontmatter，几十个 token 量级），触发后再加载完整正文，执行时按需展开 references/、scripts/ 等子资源。这意味着 20 个 Skill 的元数据合计只占约 1,000 token 的常驻上下文。
2.4 Memory：状态层
Memory 解决”会话结束后上下文丢失”的问题，常见形态包括项目级 CLAUDE.md、长期记忆文件、向量检索、KV 缓存。Tool 与 Skill 都不应承担跨会话状态，否则会让函数变成”带副作用的巨无霸”。
2.5 Harness：运行环境层
Harness 是包裹 Agent 的”脚手架”，包括评测脚本、CI 流水线、Plan Mode、子 Agent 调度、hook 触发等。它决定 Agent 怎么被启动、被监控、被重试、被评分，是工程化与可重复性的关键。
三、哪些任务沉淀成 Skill，哪些做 Tool
判断依据通常落在三点：是否多步、是否需要领域知识、是否需要可重复的”完成定义”。
- 多步 + 领域规则 + 完成定义齐全：典型场景如”按公司模板生成 PRD””把会议纪要拆成行动项”——应做 Skill；
- 单步原子动作 + 高频复用：典型如”搜索网页””发送 Slack 消息””读取文件”——应做 Tool；
- 需要连外部服务但 Agent 自带 Tool 不够稳定：如 GitHub、数据库、Notion 等需要鉴权与协议适配的——优先评估 MCP，协议能带来”一次接入、处处可用”的复用收益；
- 需要跨会话保留偏好、历史、未完成任务：沉淀为 Memory，写入项目级配置文件或长期记忆文件；
- 需要在 CI / 评测流水线里反复跑、记分、回放：交给 Harness 调度，而不是塞进 Skill 或 Tool。
四、典型决策流程
把候选能力放进选型流程，能避免”什么都写成 Skill”的反模式：
- 先问”它是不是一个最小动作”。是 → Tool；不是 → 进入下一步；
- 再问”它要不要连外部系统”。要 → 评估 MCP 协议是否已有对应服务器；不要 → 进入下一步；
- 再问”它是不是一组步骤 + 检查项 + 模板”。是 → Skill；不是 → 进入下一步；
- 再问”它是否需要跨会话记忆”。是 → Memory；不是 → 评估是否属于 Harness 调度范畴；
- 如果以上都不是，再考虑”是不是单纯的 Agent 调度 / 评测需求”——这种情况归 Harness。
五、组合关系与常见误用
实际生产中它们经常组合出现：一个 Skill 内部可能通过 MCP 调外部 Tool；一个 Agent 同时挂载多个 Skill 与一个 Memory 模块；Harness 把整套链路包成 CI 任务跑回归。容易踩的坑是把 Skill 写成”伪 Tool”（只有动作、没有检查），或把 Tool 写成”巨型 Skill”（附带业务规则与流程，测试时无法 mock）。前者会导致质量不可控，后者会导致维护成本陡增。
下面是一段 MCP 与 Tool 在 JSON-RPC 2.0 上的标准交互片段，可直接被任何 MCP 兼容 Agent 复用：
// 1. 客户端列出可用工具
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": {}
}
// 2. 服务端返回工具描述
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
{
"name": "read_file",
"description": "读取文件内容",
"inputSchema": {
"type": "object",
"properties": { "path": { "type": "string" } },
"required": ["path"]
}
}
]
}
}
// 3. 客户端发起调用
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": { "name": "read_file", "arguments": { "path": "src/auth.ts" } }
}这一交互模式让 MCP 把连接层标准化、把 Tool 限定在最小动作、把 Skill 留给 LLM 解释的流程层，三层各司其职。
常见问题（FAQ）
Q1：MCP 出现后，Tool 还有必要自己写吗？
仍要；MCP 解决连接标准，自定义 Tool 解决”我独有的原子动作”。
Q2：什么情况下不要做 Skill？
只要是单步、确定性强、无领域规则的，都不应做 Skill。
Q3：Memory 和 Skill 的边界在哪里？
Skill 装”方法”，Memory 装”上下文与历史”；前者按需加载，后者常驻或按会话留存。
