AI Agent、Harness、MCP、Skills：一文讲透四层架构的串联关系

AI Agent、Harness、MCP、Skills：四层架构串联解析

一、写在前面：四个概念，一个体系

最近几个月我深度使用了 Claude Code 的 Harness 系统和 Superpowers Skills 体系，也自己开发过 MCP Server 和 Claude Code Skill。在这个过程中，我发现很多开发者对这四个概念的关系理解比较模糊——Agent 是什么？Harness 做什么？MCP 和 Skill 有什么区别？它们之间怎么串联？

本文不是官方文档的翻译，而是我在实战中形成的理解。我会用一个完整的请求处理链路，把 Agent、Harness、MCP、Skills 四个概念串联起来，让你看完之后能真正理解这个体系的架构设计。

二、四层架构总览

先给一个一句话总结，再逐层展开：

Agent 是大脑，Harness 是中枢神经，MCP 是外接设备接口，Skills 是专业能力模块。

从用户输入到最终执行的完整链路：

用户说："帮我发一篇CSDN帖子"
    │
    ▼
┌──────────────────────────────────────┐
│  Agent（大脑/推理引擎）                 │
│  - 接收用户输入                        │
│  - 理解意图：用户想发帖                 │
│  - 制定计划：需要生成内容→审查→发布      │
└──────────────┬───────────────────────┘
               │ "我需要发帖能力"
               ▼
┌──────────────────────────────────────┐
│  Harness（中枢神经系统）                │
│  - 工具调度：有什么工具可用？            │
│  - 权限管控：这个操作安全吗？            │
│  - 上下文管理：该加载哪些指令？          │
│  - 状态跟踪：当前执行到哪一步了？        │
└──────────────┬───────────────────────┘
               │
    ┌──────────┼──────────┐
    ▼          ▼          ▼
┌──────┐ ┌──────┐ ┌──────────┐
│ MCP  │ │Skills│ │ 内置工具  │
│工具接口│ │能力模块│ │curl/文件  │
└──┬───┘ └──┬───┘ └────┬─────┘
   │        │           │
   ▼        ▼           ▼
 CSDN   爆文方法论    文件系统
 浏览器  合规审查    HTTP请求
  API    发布执行

下面逐层深入。

三、Agent：大脑与推理引擎

3.1 Agent 的本质

Agent 不是一个具体的技术，而是一种架构模式。核心公式我已经在另一篇文章里写过：

Agent = LLM + Planning + Tool Use + Memory

但在 Harness 体系里，Agent 有了更具体的定位：它是决策者，不是执行者。

Agent 负责三件事：

1. 理解意图： 用户说"发帖"，是真的想发帖还是想了解发帖流程？
2. 选择路径： 是走全流程（生成→审查→发布），还是只做审查？
3. 动态调整： 合规审查不通过时，是退回修改还是终止流程？

Agent 不负责实际干活。它不做 HTTP 请求，不操作文件，不调用浏览器。这些都是下面几层的事。

3.2 Agent 在 Harness 中的位置

Harness 给我的 Agent 提供了什么？

• 工具清单： Harness 告诉 Agent “你现在有哪些能力可用”——MCP 工具、Skill 指令、系统内置工具
• 权限边界： 什么操作可以直接做，什么需要用户确认
• 上下文注入： 当前项目信息、用户偏好、历史记忆

换句话说，Agent 是 Harness 体系里的"租客"，Harness 是"房东"。房东提供水电气网（工具、权限、上下文），租客决定怎么用（推理、规划、决策）。

四、Harness：中枢神经系统

4.1 Harness 是什么

Harness 是 Claude Code 的运行时框架。用一句话理解：它是 Agent 和外部世界之间的中间层。

如果没有 Harness，Agent 就是一个只会说话的 LLM——能回答问题，但不能实际操作任何东西。有了 Harness，Agent 获得了"动手能力"。

4.2 Harness 的核心职责

4.3 Harness 不等于 Agent

这是最容易混淆的地方。很多文章说"Harness 就是 Agent 框架"，这个说法不太准确。

Agent 是决策逻辑（“我要发帖”），Harness 是执行基础设施（“我帮你调用工具来发帖”）。两者的关系就像大脑和身体——大脑决定往哪走，身体负责走路。

4.4 我理解 Harness 的关键洞察

使用 Harness 一个多月后，我最大的感受是：Harness 解决的不是"AI 能做什么"的问题，而是"AI 如何安全、可控、可编排地做"的问题。

没有 Harness，你也能用 API 调 LLM + 自己写工具调用。但你会面临：

• 每次调工具都要自己写 JSON 解析
• 权限控制需要自己实现
• 多步骤任务的状态管理全靠手动
• 子任务之间上下文污染

Harness 把这些"基础设施"抽象掉了，让你（和 Agent）专注于业务逻辑。

五、MCP：外接设备接口

5.1 MCP 解决什么问题

MCP（Model Context Protocol）是 Anthropic 提出的一个开放协议，用于 LLM 和外部工具/数据源之间的标准化通信。

在 MCP 出现之前，每个 LLM 应用都要自己实现工具调用协议：

• LangChain 有 LangChain 的方式
• OpenAI 有 Function Calling 的方式
• 自研框架又有自己的方式

MCP 的目标是做"AI 世界的 USB 接口"——不管什么工具，只要实现了 MCP 协议，就能被任何支持 MCP 的 Agent 调用。

5.2 MCP 的三层架构

┌─────────────────┐
│   MCP Host      │  ← Claude Code / VS Code / 其他AI应用
│   (宿主程序)     │
└────────┬────────┘
         │ JSON-RPC over stdio/SSE
         ▼
┌─────────────────┐
│   MCP Client    │  ← 协议客户端，管理连接和生命周期
│   (协议客户端)   │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   MCP Server    │  ← 工具实现方，对外暴露能力
│   (工具服务)     │
└─────────────────┘

以我的 CSDN MCP 为例：

• Host： Claude Code 本身
• Client： Claude Code 内置的 MCP 客户端
• Server： 我写的 Java 程序，暴露了 saveArticle 工具

5.3 MCP 的核心概念

5.4 MCP 的局限性

MCP 很适合工具调用（Tool），但不太适合复杂的工作流编排。这就是为什么还需要 Skills。

MCP 能做的：定义一个函数，让 LLM 调用它。
MCP 做不了的：定义一个多步骤工作流，带决策分支、上下文切换、错误恢复。

六、Skills：专业能力模块

6.1 Skill 不是 MCP 的替代品

很多人问："有了 MCP 为什么还要 Skill？“或者"Skill 能替代 MCP 吗？”

答案是：它们解决的是不同层面的问题。

MCP 解决的是"通信协议"问题——LLM 怎么和外部工具标准化通信。
Skill 解决的是"能力编排"问题——如何把 Agent 推理 + 多个工具调用 + 领域知识组合成一个可复用的能力模块。

6.2 Skill 的本质

Skill 是一份 Markdown 指令文件，它告诉 Agent：

1. 你是谁（角色定义）： “你是 CSDN 爆文优化专家”
2. 你要做什么（工作流）： 生成标题→正文→SEO元数据→输出
3. 怎么做（方法论）： 三种标题公式、五段式结构、排版铁律
4. 边界在哪（约束）： 不低于3000字、不违反社区规则

6.3 我设计 CSDN Publisher Skill 的分治实践

我的 CSDN Publisher 不是一个 Skill，而是六个 Skill 组成的体系：

.csdn-publisher/
├── agent.md                  ← 主编排器（路由判断+流程调度）
├── cookie-capture.md         ← Cookie 自动捕获（Playwright 扫码）
├── content-optimizer.md      ← 爆文优化（标题公式+结构模板）
├── compliance-checker.md     ← 合规审查（10条红线逐项扫描）
├── publisher.md              ← 发布执行（浏览器内 fetch API）
└── scheduler.md              ← 定时任务（CronCreate 调度）

这个设计的核心理念是分治——借鉴了 Harness 本身的设计思想。每个子 Skill 只做一件事，有独立的上下文，通过 agent.md 调度协作。这样做的好处：

• 上下文干净：优化文章时，合规规则不占 Token
• 推理深度：每个子 Skill 专注一个领域，推理更精准
• 可维护：改爆文方法论不影响发布逻辑
• 可复用：compliance-checker 可以被其他 Skill 复用

6.4 Skill vs MCP：何时用什么

最佳实践：MCP 提供原子能力（单个工具），Skill 负责编排这些能力（工作流）。

七、四者串联：一个完整的请求处理链路

用一个实际例子串联四个概念。用户说"帮我发一篇 MySQL 常见错误的帖子"：

步骤1：Agent 接收并理解
  "发帖" → 意图识别 → 需要 内容生成+审查+发布 全流程

步骤2：Agent 向 Harness 请求能力
  "我需要发帖的能力"
  
步骤3：Harness 检查可用资源
  - Skills: csdn-publisher（含6个子Skill）
  - MCP: Playwright（浏览器操作）
  - 内置: curl, 文件系统

步骤4：Harness 加载 agent.md Skill
  → 注入编排规则（意图路由表、安全守则）
  
步骤5：Agent 按编排规则调度子 Skill
  Skill("csdn-content-optimizer")  → 生成MySQL文章
  Skill("csdn-compliance-checker") → 审查标题+内容+篇幅
  用户确认
  Agent 决定：通过，执行发布

步骤6：Harness 执行发布
  → 调用 MCP Playwright browser_run_code_unsafe
  → 在浏览器内执行 fetch() 发 CSDN API
  → 返回文章链接给用户

步骤7：Harness 记录状态
  - 文章ID: 161617149
  - 发布时间: 2026-06-02
  - 状态: 草稿

每层各司其职：

• Agent 只做决策（发什么、怎么发、什么时候发）
• Harness 只做调度（加载哪个Skill、调用哪个MCP、权限够不够）
• MCP 只做执行（浏览器操作、API调用）
• Skills 只做指导（方法论、工作流、约束条件）

八、我的核心理解

8.1 这个架构的精妙之处

使用这套体系一个多月后，我最深刻的感受是：它用极简的抽象层数，覆盖了极其复杂的能力谱系。

• 最底层：MCP 协议定义了工具通信的标准（就像 HTTP 定义了浏览器和服务器通信的标准）
• 中间层：Harness 提供了运行时的安全和管理（就像操作系统管理进程）
• 能力层：Skills 封装了可复用的领域知识（就像 npm 包封装了可复用的代码）
• 最上层：Agent 负责智能决策（就像用户决定了要做什么）

8.2 和传统开发模式的对比

8.3 未来展望

我个人觉得这个架构会成为 AI 应用开发的主流范式，原因很简单：它把"AI 能做什么"和"AI 怎么做的"解耦了。

以后开发者不需要写"调用 LLM → 解析 JSON → 调 API → 处理错误 → 返回结果"这些样板代码。他们只需要：

1. 写一个 MCP Server 暴露原子能力
2. 写一个 Skill 文件定义工作流
3. Agent 自动完成剩下的

这就像从汇编语言进化到高级语言——底层细节被抽象掉了，你只需要描述"做什么"，不需要描述"怎么做"。

九、总结

这篇文章的核心观点浓缩为四句话：

1. Agent 是决策者，不干活。 它理解意图、制定计划、动态调整。
2. Harness 是调度器，不思考。 它管理工具、控制权限、隔离上下文。
3. MCP 是通信协议，不编排。 它标准化工具接口，实现即插即用。
4. Skills 是知识模块，不执行。 它们封装方法论和工作流，指导 Agent 正确做事。

四种能力组合在一起，形成了从"用户意图"到"完整执行"的闭环。理解了这个四层架构，就理解了现代 AI 应用的核心设计思想。