AI Agent 核心概念全景：从 Prompt 到 Agent 的七层能力演进

现在我只需要说一句："把这个文件发到博客上。" 剩下的全是 AI 自己干的。

但这件事不是一上来就能做到的。AI 从"只会聊天"到"能帮你干活"，中间经历了七次能力跃迁——每次都是因为上一层搞不定了，才出现了新东西。Prompt、Function Calling、MCP、Skills、Sub Agent、Agent，这些名字你可能都听过，但没人告诉你它们之间的因果关系。

这篇文章就用"发博客"这一个问题，把这七层能力串起来。每层都有可以直接跑的代码。

第一层：Prompt——你跟 AI 说的每一句话

最开始，我只能这样用 AI：

我：帮我读一下这篇博客草稿，提取标题和摘要
AI：这篇博客的标题是"XXX"，摘要是……

这就是 Prompt。你输入文本，AI 输出文本。听起来没什么技术含量，但问法不同，答案质量天差地别。

同样一个任务，三种问法：

• 直接问："帮我读一下这个文件" → AI 返回一个泛泛的总结，格式乱七八糟
• 加格式要求："帮我读一下这个文件，输出格式：标题（10 字以内）、摘要（80 字以内）、关键词（3 个）" → 输出立刻规范了
• 加角色和规则："你是一个资深 SEO 编辑。读一下这个文件，输出：标题（10 字以内，含关键词）、摘要（80 字以内，面向搜索引擎优化）、关键词（3 个）。标题不要用'如何''什么是'开头。" → 输出可以直接拿去用

这就是 Prompt 的三个层次：直接提问 → 加约束 → 加角色和规则。本质上都是"怎么问才能得到更好的答案"。

但不管怎么问，AI 只能返回文本。它读不了我硬盘上的文件、生成不了图片、上传不了图床、碰不了 WordPress API。

Prompt 的天花板：AI 被关在训练数据的牢笼里，跟真实世界完全隔绝。

第二层：Function Calling——AI 长出了"手"

2023 年 Function Calling 出来后，AI 第一次能执行真正的动作了。

原理不复杂。你提前告诉 AI："你有这些工具可以用。"当 AI 判断需要用工具时，它不再输出自然语言，而是返回一个 JSON：

{
  "name": "read_file",
  "arguments": { "path": "/drafts/my-article.md" }
}

你的代码拿到这个 JSON，执行真实的文件读取，把内容塞回给 AI。AI 再基于文件内容继续工作。

自己写一个 Function Calling 工具

以 Anthropic 的 Python SDK 为例。假设我需要两个工具：读文件、发布 WordPress 文章。

import anthropic
import json

client = anthropic.Anthropic()

# 第一步：定义工具——告诉 AI "你能用什么"
tools = [
    {
        "name": "read_file",
        "description": "读取本地文件内容",
        "input_schema": {
            "type": "object",
            "properties": {
                "path": {
                    "type": "string",
                    "description": "文件路径"
                }
            },
            "required": ["path"]
        }
    },
    {
        "name": "publish_to_wordpress",
        "description": "将 HTML 内容发布为 WordPress 博客文章",
        "input_schema": {
            "type": "object",
            "properties": {
                "title": {"type": "string", "description": "文章标题"},
                "content": {"type": "string", "description": "HTML 格式的文章内容"},
                "status": {"type": "string", "enum": ["draft", "publish"]}
            },
            "required": ["title", "content"]
        }
    }
]

# 第二步：发送请求
message = client.messages.create(
    model="claude-sonnet-4-6-20250514",
    max_tokens=1024,
    tools=tools,
    messages=[
        {"role": "user", "content": "把 /drafts/my-article.md 发布到 WordPress"}
    ]
)

# 第三步：AI 返回的可能是 tool_use，不是文本
print(message.content)
# 输出类似：
# [ToolUseBlock(id='...', name='read_file', input={'path': '/drafts/my-article.md'})]

AI 判断需要先读文件，所以返回了 read_file 的调用请求，而不是直接给你一篇文章。

接下来你的代码要真正执行这个工具调用，把结果送回去：

# 第四步：执行工具，把结果返回给 AI
if message.stop_reason == "tool_use":
    tool_use = next(block for block in message.content if block.type == "tool_use")

    # 执行真实的文件读取
    if tool_use.name == "read_file":
        with open(tool_use.input["path"], "r") as f:
            file_content = f.read()

    # 把工具执行结果返回给 AI
    response = client.messages.create(
        model="claude-sonnet-4-6-20250514",
        max_tokens=1024,
        tools=tools,
        messages=[
            {"role": "user", "content": "把 /drafts/my-article.md 发布到 WordPress"},
            {"role": "assistant", "content": message.content},
            {
                "role": "user",
                "content": [{
                    "type": "tool_result",
                    "tool_use_id": tool_use.id,
                    "content": file_content
                }]
            }
        ]
    )

这就是一个完整的 Function Calling 循环：定义工具 → AI 决定调用 → 你执行 → 结果送回去 → AI 继续。

AI 不再只是"回答问题"，它在"执行任务"。它自己判断需要调什么工具、按什么顺序。这个能力看起来简单，但它是后面 MCP、Skills、Agent 的地基。没有它，后面的东西全建不起来。

但问题来了：五个工具我就要写五个函数定义。换到项目 B，全部重来。换成 OpenAI 的 API，函数定义格式又不一样。

Function Calling 的天花板：每个工具都是"定制件"，不能复用，不能共享。

第三层：MCP——工具终于可以复用了

2024 年底 Anthropic 发布了 MCP（Model Context Protocol）。它做的事一句话讲清：让工具一次开发，所有 AI 都能用。

以前你给 AI 写一个"读取文件"的工具，这个工具只能在你的项目里跑。换成另一个项目、另一个 AI，就得重写。MCP 定义了一套标准协议——MCP Client（AI 应用）和 MCP Server（工具提供方）之间用 JSON-RPC 通信。任何实现了 MCP 的工具，任何支持 MCP 的 AI 都能调用。

安装一个 MCP Server 只需要一条命令

回到博客发布场景。WordPress 有社区开发的 MCP Server。文件系统也有现成的。安装方式：

# 安装文件系统 MCP Server（让 AI 能读写本地文件）
claude mcp add filesystem -- npx -y @anthropic/mcp-server-filesystem /path/to/your/blog

# 安装 WordPress MCP Server（让 AI 能操作 WordPress）
claude mcp add wordpress 
  -e WP_API_URL=https://yourblog.com/wp-json 
  -e WP_TOKEN=your_token 
  -- npx wordpress-mcp-server

# 验证安装
claude mcp list
# 输出：
# filesystem: stdio transport, running
# wordpress:  stdio transport, running

装完之后，AI 自动发现所有可用工具——read_file、create_post、upload_media、update_post……就像插上一个 USB 设备，系统自动识别。

MCP 支持三种连接方式：

比如 GitHub 官方的 MCP Server，推荐用远程模式：

claude mcp add --transport http github 
  https://api.githubcopilot.com/mcp 
  -H "Authorization: Bearer YOUR_GITHUB_PAT"

一条命令，AI 就能直接操作你的 GitHub 仓库——创建 issue、提 PR、查看 CI 状态。不用写一行接入代码。

常用管理命令：

claude mcp list           # 查看已安装的 Server
claude mcp get <name>     # 测试某个 Server 的连接状态
claude mcp remove <name>  # 卸载
/mcp                      # 在交互模式中管理（推荐，有交互式菜单）

MCP 的价值不是提供了新能力，而是让工具接入从"每个项目定制"变成了"装包即用"。

但 AI 有工具了，还是干不好活。因为它不知道先上传图片还是先转 HTML，不知道封面图应该多大，不知道 SEO 标题怎么写。

MCP 的天花板：AI 有工具了，但缺"怎么干"的知识。

第四层：Skills——给 AI 一本操作手册

2025 年 10 月，Anthropic 推出了 Skills。

Skills 解决的问题很具体：AI 有工具了（通过 MCP），但不知道按照什么流程使用这些工具。 就像一个实习生——扳手锤子都在工具箱里，但他不知道修水龙头的标准流程是什么。

自己写一个 Skill

一个 Skill 本质上就是一个文件夹，里面至少有一个 SKILL.md 文件：

blog-publish/
├── SKILL.md          # 必须：元数据 + 操作流程
├── scripts/          # 可选：脚本（比如图片压缩、格式转换）
├── references/       # 可选：参考资料（比如 SEO 规范）
└── assets/           # 可选：模板（比如 HTML 模板）

SKILL.md 的写法：

---
name: blog-publish
description: 将 Markdown 博客文章发布到 WordPress，包含封面图生成、图片压缩、CDN 上传和 SEO 优化
---

# 博客发布流程

当用户要求发布博客时，按以下步骤执行：

1. 读取文章文件，提取标题、摘要、关键词
2. 根据文章主题生成封面图（风格：科技感，色调匹配文章主题）
3. 压缩图片为 JPG 格式（quality 70）
4. 上传到图床 CDN，获取公网链接
5. 将 Markdown 转换为 WordPress 兼容的 HTML
6. 在 HTML 顶部插入封面图
7. 通过 WordPress API 创建草稿
8. 通知用户审核后发布

## 格式要求

- 标题不超过 60 字，包含核心关键词
- 摘要不超过 150 字，面向搜索引擎优化
- 封面图尺寸 1200x630
- HTML 中图片使用 CDN 链接，不使用本地路径

## 错误处理

- 图片上传失败时自动重试 3 次
- WordPress API 返回 401 时提示用户检查 Token

怎么安装 Skills

三种方式，推荐第一种：

方式 A：从社区市场安装（推荐）

skills.sh 是 Vercel 维护的开放 Skills 市场，一条命令安装，支持 19 种 AI Agent（Claude Code、Cursor、Codex、GitHub Copilot、Gemini、Windsurf、Cline……），不只是 Claude Code 专属。

# 安装单个 Skill
npx skills add vercel-labs/agent-skills

# 搜索你需要的 Skill（比如前端设计）
npx skills add anthropics/skills/frontend-design

# 安装后，你用的任何支持 Skills 的 Agent 都能直接用
# 换 Cursor 也行，换 Codex 也行，不用重新配置

社区里已经有不少高质量的 Skill——Anthropic 官方出了 frontend-design（39 万次安装）、skill-creator；Vercel 出了 vercel-react-best-practices；Microsoft 出了一整套 Azure Skills（460 万次安装）；Supabase 出了 Postgres 最佳实践。直接去 skills.sh 浏览排行榜，找到需要的装上就行。

方式 B：通过 /plugin 命令安装（Claude Code 专属）

/plugin add https://github.com/someone/blog-publish-skill

支持版本追踪和自动更新，但只对 Claude Code 有效。换到 Cursor 或其他 Agent 就用不了。

方式 C：手动复制

cp -r blog-publish/ ~/.claude/skills/blog-publish/

最原始的方式。适合你自己写的本地 Skill，或者从别处下载的 Skill 包。

如果你积累了很多好用的提示词模板，现在可以直接把它们改造成 Skills——加上 frontmatter 元数据（name 和 description），放到 ~/.claude/skills/ 目录下就行。写得好还可以发布到 skills.sh，让别人也能一键安装。

Skills 的精妙设计：按需加载

AI 启动时只看到这个 Skill 的名字和简介——"blog-publish - 将 Markdown 博客文章发布到 WordPress"，大概 50 个 tokens。只有当你说"发布博客"时，它才加载完整内容。

这个匹配过程完全由大模型决定，不是关键词匹配、不是正则、不是向量检索。AI 读到所有 Skill 的 description，自己判断哪个跟你的请求相关，再决定加载哪个。

这就是 Skills 的关键设计——按需加载。你有 20 个 Skill，每次对话只加载用到的 1-2 个，不会把上下文窗口塞满。

Skill 没被激活怎么办

因为匹配过程完全依赖大模型的语义判断，偶尔会"漏掉"。确认要使用的 Skill 没有被激活时，三个办法：

1. 直接用斜杠命令强制调用：/blog-publish — 跳过 AI 判断，直接加载
2. 把关键规则写进 CLAUDE.md：CLAUDE.md 里的内容始终在上下文里，不会被跳过
3. 设置 disable-model-invocation: true：把这个字段加到 SKILL.md 的 frontmatter 里，改为完全手动调用

从本质上看，Skills 就是你以前写的"超级 Prompt"的进化版。2023 年你把所有要求塞进一个巨大的 System Prompt，每次对话都发一遍，token 费用爆炸，AI 还容易"注意力失焦"。现在拆成独立的 Skill 文件，用到哪个加载哪个。

Skills 的天花板：任务太复杂时，一个 AI 的上下文窗口会被塞满。

第五层：Sub Agent——一个干不完，分给多个

当任务复杂到一定程度——比如同时重构三个模块、跑两套测试、部署到两个环境——单个 AI 的上下文窗口会被塞满。它开始"忘事"：前面改过的代码细节记不清了，之前讨论的方案搞混了。

Sub Agent 的解决方案很直接：把大任务拆成小任务，每个小任务交给一个独立的 AI 执行。

回到博客场景。如果我要同时发布三篇博客，每篇都要生成封面图、转换 HTML、推送 WordPress。串行执行太慢。

主 Agent：接收任务，拆分给三个 Sub Agent
├── Sub Agent 1：处理文章 A（读文件 → 生成图 → 压缩 → 上传 CDN → 转 HTML → 发布）
├── Sub Agent 2：处理文章 B（同时进行，独立上下文窗口）
└── Sub Agent 3：处理文章 C（同时进行，独立上下文窗口）

每个 Sub Agent 拥有独立的上下文窗口，互不干扰。Sub Agent 1 在处理文章 A 时产生的中间结果，不会污染 Sub Agent 2 的工作空间。这意味着即使文章 A 的封面图生成很复杂，也不会影响文章 B 的 HTML 转换质量。

在 Claude Code 中，这通过 Agent 工具实现——主 Agent 可以启动多个子 Agent，每个子 Agent 可以有不同的工具权限和指令集：

主 Agent 启动三个并行子任务：
- Sub Agent 1 (blog-A)：加载 blog-publish Skill，使用 filesystem + wordpress MCP
- Sub Agent 2 (blog-B)：加载 blog-publish Skill，使用 filesystem + wordpress MCP
- Sub Agent 3 (blog-C)：加载 blog-publish Skill，使用 filesystem + wordpress MCP

各自独立执行，完成后向主 Agent 汇报结果

Sub Agent 还有一个好处：可以独立运行在 Git Worktree 里。这意味着三个 Sub Agent 可以同时修改代码，互不冲突——每个 Worktree 是代码仓库的一个独立副本。

最终形态：Agent——说一句话，它自己搞定

回到文章开头的目标。现在我对 AI 说："把 /drafts/my-article.md 发布到博客。"

Agent 的内部过程：

1. 理解意图（Prompt）：用户要发布一篇博客
2. 加载专业知识（Skills）：发现 blog-publish Skill 匹配，自动加载完整流程
3. 按流程执行：读文件 → 提取标题摘要 → 生成封面图 → 压缩图片 → 上传 CDN → 转 HTML
4. 调用工具（MCP）：通过 wordpress MCP Server 调用 create_post 接口
5. 底层通信（Function Calling）：MCP Server 的每个工具调用，本质上还是 Function Calling 的 JSON 结构
6. 遇到问题自己调整：图片上传失败 → 自动重试；CDN 链接获取不到 → 换一个图床
7. 完成后通知我

全程我只需要说一句话。

Agent 不是某个新功能。它是前面所有能力的整合态——用 Prompt 理解意图，用 Function Calling 调用工具，用 MCP 标准化工具接入，用 Skills 加载专业知识，用 Sub Agent 分发子任务。

这就是为什么 Agent 是最终形态。其他所有概念都是 Agent 的组件。

但有一个代价必须说清楚：Agent 不可能 100% 可靠。

同一个任务跑两次，执行路径可能不同。偶尔它会跳步骤，偶尔走弯路。因为决策权交给了大模型，大模型本质上是概率性的。

所以我的原则是：关键路径用代码保底，非关键环节交给 Agent 灵活处理。 支付金额的校验必须是代码写的，绝不能靠 AI 判断。但"根据文章主题生成封面图"这种事，交给 Agent 比写代码灵活一万倍。

从哪里开始

不用一口气学会所有概念。根据你现在的场景：

• 如果你只想跟 AI 聊天 → 理解 Prompt 的三个层次就够了。把问法练好，输出质量会有质的提升。
• 如果你想让 AI 帮你操作外部系统 → 学 Function Calling。用上面的 Python 代码注册一个最简单的工具（比如读文件），感受"AI 从说话到做事"的跨越。
• 如果你有大量工具需要管理 → 装 MCP Server。一条命令 claude mcp add 就能接入 GitHub、数据库、Slack 等工具。先装一个社区现成的，体验"装包即用"。
• 如果你有重复性的工作流 → 写一个 Skill。把你每天都要做的操作流程写进 SKILL.md，放到 ~/.claude/skills/ 下，让 AI 按需加载。
• 如果任务复杂到一个 AI 搞不定 → 用 Sub Agent 拆分。各自独立执行，最后汇总。
• 如果你想造一个全自动的系统 → Agent。它就是以上所有能力的整合态。