Five colored plates stacked as one chassis, with a continuous paper log.

From describing a role → reaching the outside world

System Prompt, Skill, Workflow, Cron, and MCP are not five competing ideas. They are one stack: each layer answers a different question. Together they make a complete agent automation system.

Five layers, one question each

Read top to bottom. The top four layers handle persona → capability → orchestration → schedule. MCP is the shared floor under every outbound call.

The questionWho am I?

System Promptpersona

Set a long-term, global role and boundary: tone, rules, habits (“you are an ecommerce ops advisor; answer in Chinese”; “think first, then answer”). It also exposes skill metadata so the model knows what is available.

LikeThe employee handbook plus the job description

Load on demand — the system prompt holds names and short descriptions. The host injects the matching SKILL.md only when the model needs it. That saves tokens and keeps modules separate.

The questionWhat can I do?

Skillcapability

Package a stable, high-frequency workflow (steps, rules, examples, scripts) into a reusable module: SKILL.md, local prompts, checks, and scripts. One clear goal, such as “write the weekly report” or “review a PR.”

LikeAn SOP plus a script pack. In engineering terms, a function.

Wire them together — a Workflow lines up several Skills, tool calls, and decisions into one pipeline.

The questionHow do they run together?

Workfloworchestration

A multi-step automation in YAML or JSON. It can call several Skills, several agents, several tools. Branches, loops, multi-agent work. Triggered by CLI, HTTP, an MCP client, or a UI.

LikeA call graph / pipeline. This is the orchestrator’s job.

Fire on a clock — a Cron job’s “payload” is just “run this Workflow now.”

The questionWhen does it run?

Cronschedule

Only the time rule. 0 8 * * 1 is Monday at 08:00. Workflow answers how. Cron answers when. They are often bound together.

LikeAn alarm. At the time, it presses the Workflow’s start button.

Every outbound call from Skill or Workflow goes through ↓

The questionHow do I reach the outside world?

MCPaccess · Model Context Protocol

A standard protocol. Wrap external tools as MCP servers. JSON-RPC exposes names, parameter schemas, and resources. It only guarantees how you connect and that the call format stays consistent. It does not decide how those calls are organized. That is Skill and Workflow.

LikeA shared API spec plus SDK. HTTP, but for tools.

Where adjacent layers split

Four boundaries people mix up. Each one ends with a one-line analogy.

System Prompt×Skill

System Prompt

Long-term, global role
Tone, bounds, output shape
Also exposes skill metadata

Skill

A task-level instruction set
SKILL.md + examples + scripts
Loaded into context on demand

The handbook says how you work in general. The SOP says how this process runs, step by step.

Skill×Workflow

Skill

One capability, one class of task
May call MCP tools and scripts
Wrapped around a single goal

Workflow

Lines several Skills into a pipeline
Branches, loops, multi-agent
Orchestration in YAML / JSON

A Skill is a function. A Workflow is the call graph.

Workflow×Cron

Workflow

Defines every step and dependency
“How, and in what order”
A person or an agent can trigger it

Cron

Only the time rule
“When it runs by itself”
0 23 * * * = 23:00 every night

The usual pattern: write one Workflow, then put a Cron on it.

MCP×Skill/Workflow

MCP

How you connect, one format
JSON-RPC for tools and resources
Does not organize the work

Skill / Workflow

The Skill names which tool this step uses
Workflow nodes can include MCP calls
Organization happens here

MCP is the API spec plus SDK. Skill is the service on top. Workflow is the orchestrator that strings services together.

One full chain: the nightly store report

Put all five layers in one real job: generate and send a cross-border store report every night. Step colors match the stack above.

Nightly ops report, end to end

23:00 every day

System Promptset the persona

Set the rule: “You are a cross-border ecommerce ops assistant. Read TikTok Shop / Amazon data carefully. Prefer saving ad spend.”

Skillpackage the capability

Put the SOP in SKILL.md: pull the last 7 days, then analyze GMV, ad ROI, and the conversion funnel, with the analysis script beside it.

Workfloworchestrate

Define the pipeline: analysis Skill → report Skill → send to Feishu / email.

Cronschedule

Set 0 23 * * * so this Workflow runs itself at 23:00.

MCPconnect

TikTok / Amazon APIs, the internal database, and mail all become MCP tools. Every step above calls them the same way.

What you gain: the upper layers only talk to role + Skill + Workflow + Cron. API details stay in MCP. A new platform or a swapped tool changes the floor, not the floors above it.

Easy mix-up: MCP ≠ Connector

“MCP Connector” is the overlap of two ideas, not one thing. MCP is a protocol. A connector is a concrete integration.

MCPA standard / protocol / frame. It defines how you talk, how tools are described, and how resources are reached. It is not one connector service. HTTP is a protocol. It is not a website.

ConnectorThe wider word: any interface that joins an AI system to an outside one (Google Drive, HubSpot…). Some sit on MCP. Some are still REST or iPaaS.

MCP ConnectorThe overlap: a server or component that implements MCP and exposes a system (Notion, MySQL, TikTok Shop…) to an MCP-aware client. You can say “it is a connector.” You cannot say “every connector is MCP.”

“I need one access contract and one call style.” → You are thinking about MCP, the protocol layer.

“I need something that talks to Notion / MySQL / TikTok Shop.” → You are building a Connector. In most cases you will ship it as an MCP Connector.

One table

Keep the second column. If you remember the question, the five words stop colliding.

Layer	Question	In software	In life
System Prompt	Who am I?	Global config / runtime constraint	Handbook + job description
Skill	What can I do?	Function / business service	One SOP + scripts
Workflow	How do they run together?	Pipeline / orchestrator	A job sheet on the line
Cron	When does it run?	Scheduler / timer	An alarm
MCP	How do I reach the outside?	API spec + SDK	One socket standard

从「描述角色」→「接入外部世界」

System Prompt、Skill、Workflow、Cron、MCP 不是五个互相竞争的概念，而是一条技术栈：每一层解决一个不同的问题，组合在一起构成完整的 Agent 自动化系统。

五层堆栈：每层回答一个问题

从上往下读：上面四层负责「人设 → 能力 → 编排 → 调度」，最底下的 MCP 是所有外部调用共同踩着的基座。

解决的问题我是谁？

System Prompt人设层

给模型定长期、全局的角色和边界：语气、规则、行为习惯（「你是电商运营顾问，只用中文回答」「先思考再回答」）。通常还会暴露系统里有哪些 Skill 的元数据，让模型知道「有这些技能可用」。

类比公司员工手册 + 岗位说明书

按需加载 —— System Prompt 只放技能名称与描述；模型判断需要时，Host 才把对应 SKILL.md 塞进上下文（省 token、模块化）

解决的问题我会什么？

Skill能力层

把某类稳定、高频的任务流程（步骤、规范、示例、脚本）打包成可复用模块：SKILL.md + 局部提示词 + 检查标准 + 脚本。围绕一个明确目标封装，如「生成周报」「审查 PR」。

类比一份 SOP 文档 + 脚本合集；工程上像一个「函数」

编排串联 —— Workflow 把多个 Skill、工具调用和决策逻辑排成一条流水线

解决的问题怎么串起来？

Workflow编排层

用 YAML/JSON 定义的多步骤自动化流程：调多个 Skill、多个 Agent、多个工具，支持条件分支、循环、多 Agent 协作。可被 CLI、HTTP、MCP 客户端或 UI 按需触发。

类比函数调用图 / pipeline；orchestrator 的主战场

定时触发 —— Cron Job 的「执行内容」就是指定某个 Workflow 按时跑一次

解决的问题什么时候跑？

Cron调度层

只关心时间规则，不关心内容：0 8 * * 1 表示每周一早 8 点执行。Workflow 解决「怎么做」，Cron 解决「什么时候自动做」，两者常绑定使用。

类比闹钟 / scheduler：到点按下 Workflow 的启动键

Skill 与 Workflow 的每一次外部调用，统一经过 ↓

解决的问题怎么连外部？

MCP工具接入层 · Model Context Protocol

标准化协议：把外部工具封装成 MCP Server，通过统一的 JSON-RPC 暴露工具名、参数结构、资源。只保证「怎么连」和「调用格式一致」，不决定怎样组织这些调用——组织是上面 Skill / Workflow 的事。

类比统一的 API 规范 + SDK；像 HTTP 之于网站

相邻两层的分工

四组最容易混淆的边界，每组一句话类比收尾。

System Prompt×Skill

System Prompt

长期、全局的角色设定
定语气、边界、输出格式
顺带暴露技能元数据

Skill

具体任务的详细说明书
SKILL.md + 示例 + 脚本
按需加载进上下文

员工手册决定你整体怎么做人做事，SOP 决定某个流程每一步怎么做。

Skill×Workflow

Skill

单位能力：稳定完成一类任务
内部可调 MCP 工具、脚本
围绕单一目标封装

Workflow

把多个 Skill 排成流水线
条件分支、循环、多 Agent
YAML/JSON 描述的编排

Skill 是函数，Workflow 是函数调用图 / pipeline。

Workflow×Cron

Workflow

定义全部步骤和依赖
「怎么做、做哪些步骤」
可被人或 AI 按需触发

Cron

只关心时间规则
「什么时候自动做」
0 23 * * * = 每晚 23:00

常见模式：配置一个 Workflow，再用 Cron 做定时触发。

MCP×Skill/Workflow

MCP

统一「如何连、格式一致」
JSON-RPC 暴露工具与资源
不决定怎样组织调用

Skill / Workflow

Skill 声明「这一步调哪个工具」
Workflow 的节点里含 MCP 调用
组织与编排在这一层发生

MCP = API 规范 + SDK；Skill = 其上的业务 Service；Workflow = 把 Service 串起来的 orchestrator。

一条完整链路：跨境电商运营日报

把五层放进同一个真实场景——每晚自动生成并发送店铺运营日报。步骤颜色对应上图的层。

「每晚运营日报」自动化全流程

每天 23:00 自动执行

System Prompt先立人设

设定总原则：「你是跨境电商运营助手，严谨分析 TikTok Shop / Amazon 数据，偏向节约广告成本」。

Skill封装能力

把「拉取近 7 天店铺数据，做 GMV、广告 ROI、转化漏斗分析」的完整 SOP 写进 SKILL.md，配上分析脚本。

Workflow编排流程

定义日报流水线：数据分析 Skill → 报告生成 Skill → 发送到飞书 / 邮箱。

Cron定时调度

配置 0 23 * * *，让这条 Workflow 每天 23:00 自动跑一遍。

MCP统一接入

TikTok / Amazon API、内部数据库、邮件服务全部封成 MCP 工具，供上面每一步以同一协议调用。

收益：上层只和「角色 + Skill + Workflow + Cron」打交道，真正的 API 细节由 MCP 统一管理——以后接新平台、换新工具，改的只是底座，不动上层。

易混点：MCP ≠ Connector

「MCP Connector」是两个概念的交集，不是同一个东西：MCP 是协议标准，Connector 是具体的集成组件。

MCP标准 / 协议 / 框架。规定通信方式、工具描述格式、资源访问；本身不是某个具体的连接器服务——就像 HTTP 定义了协议，但不是某个网站。

Connector更宽泛的词：任何把 AI 和外部系统连起来的接口（Google Drive Connector、HubSpot Connector…）。有的基于 MCP，有的走传统 REST / iPaaS。

MCP Connector两者的交集：实现了 MCP 协议的 server / 组件，把某个系统（Notion、MySQL、TikTok Shop…）暴露给支持 MCP 的 AI 客户端。可以说「它是 connector」，但不能反过来说「所有 connector 都是 MCP」。

「我要设计整体接入规范和调用方式」 → 你在想的是 MCP（协议层）。

「我要做一个连 Notion / MySQL / TikTok Shop 的集成组件」 → 你在做的是 Connector，绝大多数情况下会做成一个 MCP Connector。

一表总览

软件工程视角下的对照表——记住第二列的问题，五个概念就不会再混。

层	回答的问题	软件工程类比	生活类比
System Prompt	我是谁？	全局配置 / 运行时约束	员工手册 + 岗位说明
Skill	我会什么？	函数 / 业务 Service	一份 SOP + 脚本合集
Workflow	怎么串起来？	Pipeline / Orchestrator	流水线作业单
Cron	什么时候跑？	Scheduler / 定时器	闹钟
MCP	怎么连外部？	API 规范 + SDK	统一的插座标准