写给她的 AI 发展史：从 Transformer、ChatGPT 到 MCP、Skills 与 Agent 时代

引言：写给想弄懂 AI 的她，也写给你

这篇文章的起因其实很生活化：她想了解 AI，问我现在大家天天说的 GPT、Agent、MCP、Skills、A2A、文生图、文生视频各种模型、各种名词到底是什么。

我想了想，如果只是丢给她一串名词、论文和产品链接，估计只会越看越晕；但如果从“这轮 AI 为什么突然火起来”开始讲，也许就能把很多看似零散的技术和产品串成一条线。

所以这不是一篇只写给工程师看的模型报告，而是一篇尽量用普通人也能顺着读下来的 AI 发展史。我们会从 2017 年的 Transformer 架构说起，看到 2020 年 GPT-3 把“大模型 + 提示词”推到台前，再到 InstructGPT、GPT-3.5 和 ChatGPT 让 AI 从实验室能力变成日常产品。

你是否还记得初次体验 ChatGPT 时的场景？彼时大家热衷于让它写两首打油诗、润色一段周报，或者扮演某种角色陪自己聊天。那时的 AI，就像坐在茶馆里嗑瓜子吹牛的相声演员——口齿伶俐、知识广博，但如果你让它真正操作电脑、查询业务系统或交付一份文件，它往往只能表示“我只是一个语言模型”。

短短几年后，AI 不仅获得了视觉、语音等多模态能力，也通过 Tool Calling、MCP 和 Agent 运行时接上了软件工具与外部数据。

今天的前沿 AI 产品，正在从单纯的**“聊天答疑框”**走向能够规划、调用工具、检查结果并交付产物的 Agent（智能体）。不过，“自主”并不等于完全可靠：权限边界、确认机制、可观测性与人工复核仍然是生产系统的重要组成部分。

本文想做的事，就是把这些变化按时间和用途讲清楚：AI 是怎么从 Transformer、GPT-3、ChatGPT 一路走到今天的 Agent 时代；文本、代码、图像、视频、音频这些“AI 时代的产物”分别经历了什么突破；以及 MCP、Agent Skills、Agent2Agent（A2A）这些新协议和新工具，为什么会在这一阶段集中出现。

有些概念一句话就能先抓住，比如 Token、Prompt、Tool Calling；有些概念则值得单独写一篇，比如 Transformer、RLHF、RAG、Diffusion、MCP 和 Agent 工作流。本文会先给出“地图”，让你知道每个词大概站在哪里；至于每个山头怎么爬，我们后面再一座一座慢慢拆。

本文按可公开核验的一手资料改写；模型与产品迭代很快，具体型号、上下文长度、价格和可用地区应以链接到的官方页面为准。

历史时间线：AI 的“炼丹与觉醒”史

在展开技术细节之前，我们先梳理一条可由论文与厂商发布记录交叉验证的时间线：

先认识几个关键词

如果第一次看这些名词，先不必急着把每个机制都吃透。下面这张表只是“地图路标”：用最通俗的话带你快速理解它们到底是什么，点击名称可跳转深入阅读。

如果只想快速补基础，可以先读这篇：AI 基础术语速查：Token、Prompt、Few-shot 与 Tool Calling。

生成式 AI 主要模态：代表产品与突破方向

如果把基础模型比作硅基大脑，那么文本、代码、图像、视频、音频就是它感知与表达世界的主要通道。严格说，代码也是文本的一种，但它需要运行、调试、测试和交付，所以值得单独拎出来讲。除此之外，3D/空间场景、文档/表格/UI 自动化也正在成为复合模态的重要方向。

下面列出的产品不是绝对排名；不同模型在质量、速度、成本、可控性、开放程度和部署方式上各有取舍。

graph TD
    AI["生成式 AI 主要模态"] --> Text["文本 / LLM"]
    AI --> Code["代码 / Coding Agent"]
    AI --> Image["图像 / Image Gen"]
    AI --> Video["视频 / Video Gen"]
    AI --> Audio["音频 / Speech & Music"]
    AI --> Scene["3D / 空间场景"]
 
    Text --> T_MoE["MoE 与稀疏激活"]
    Text --> T_RL["推理时计算与强化学习"]
    Code --> C_Tools["仓库上下文与工具执行"]
    Code --> C_Tests["测试、审查与交付"]
 
    Image --> I_DiT["Diffusion Transformer"]
    Image --> I_Flow["Flow Matching / Rectified Flow"]
 
    Video --> V_Patch["时空联合建模"]
    Video --> V_Control["一致性与可控编辑"]
 
    Audio --> A_Codec["神经音频编解码器"]
    Audio --> A_Diff["自回归 / 扩散 / Flow"]
    Scene --> S_3D["3D 资产、世界模型与仿真"]

连接“孤岛 AI”：MCP、Agent Skills 与 A2A

模型本身不会天然获得你的文件、数据库、浏览器或企业系统权限。要让 Agent 真正工作，应用需要解决三类不同问题：如何连接工具与上下文、如何复用操作知识、以及不同 Agent 如何互操作。MCP、Agent Skills 和 A2A 分别覆盖这三类问题的一部分，它们不是相互替代的同一种技术。

graph LR
    Host["AI Host / Agent"] -->|MCP Client| MCP1["MCP Server: GitHub"]
    Host -->|MCP Client| MCP2["MCP Server: Database"]
    Host -->|按需加载| Skill["Agent Skill: SKILL.md + resources"]
    Host <-->|A2A| Remote["Remote Agent / A2A Server"]

1. MCP（Model Context Protocol，模型上下文协议）

MCP 架构中，一个 Host（如 IDE 或桌面 Agent）可以运行一个或多个 MCP Client，每个 Client 与 MCP Server 建立连接。Server 可以公开三类主要的服务器原语：

1. Tools：可由模型发现和调用的操作，例如查询 API、写入工单或执行受控命令。
2. Resources：由应用读取并提供给模型的上下文数据，例如文件、数据库记录或文档。
3. Prompts：由服务器提供、通常由用户显式选择的提示模板或工作流入口。

规范还包含 sampling、elicitation、roots、logging 等客户端能力和实用功能，所以把 MCP 永久概括为“只有三项功能”也不完整。MCP 统一的是通信与能力发现方式，并不会自动让任意 Server 变得可信；Client 仍需显示权限、确认高风险调用、保护凭据，并防范提示注入和恶意工具描述。

MCP 最初由 Anthropic 发布，并在多个模型厂商、IDE、桌面 Agent 和开发工具中快速扩散。关于治理归属和最新规范版本，应以 MCP 官方站点与项目仓库为准。

2. Agent Skills：可复用的操作知识包

如果说 MCP 更像“工具和数据插座”，那么 Agent Skill 更像 Agent 按需打开的专业操作手册。

Agent Skills 规范定义了一种轻量开放格式：每个 Skill 至少是一个带 YAML 元数据与 Markdown 指令的 SKILL.md 文件，也可以包含脚本、参考资料与模板。Agent 启动时只加载名称与描述；任务匹配后再读取完整说明，并按需加载其他资源。这种 progressive disclosure（渐进式披露） 可以减少常驻上下文占用。

• 它解决什么问题？
  • 把团队 SOP、领域知识、检查清单和脚本封装为可版本控制、可复用的目录，降低每次重新写长提示词的成本。
• 它不保证什么？
  • Skill 不是新的模型能力，也不是安全沙箱。说明写错、依赖缺失或工具权限过大时，Agent 仍会失败或造成副作用。
• 它与 MCP 如何配合？
  • Skill 可以告诉 Agent 何时、为何以及按什么步骤使用某个 MCP 工具；MCP 则提供实际的工具或数据连接。二者互补，但没有强制绑定。

“Skill”这个普通名词在不同产品里也可能指插件、提示模板或平台功能。本文特指最初由 Anthropic 开发、后来作为开放格式发布的 Agent Skills；不能假定所有叫 Skill 的产品都完全兼容这份规范。

3. A2A（Agent2Agent）：让独立 Agent 互操作

Agent2Agent（A2A） 是一个用于独立、可能由不同厂商或框架构建的 Agent 系统之间通信与互操作的开放协议。它允许 Agent 发布 Agent Card 以描述身份、能力、端点与认证要求，并以 Message、Task、Artifact 等对象协商和跟踪工作。

A2A 与“在一个程序里启动多个子 Agent”不是同义词：

• 内部多 Agent 编排：一个运行时自己拆任务、共享状态、调度多个角色，不一定需要网络协议。
• A2A 互操作：一个 A2A Client 与外部 A2A Server（远程 Agent）按共同规范通信，重点是跨实现边界的发现、认证、消息和任务生命周期。

Google 于 2025 年 4 月发起 A2A，随后将其捐赠给 Linux Foundation。当前规范支持 JSON-RPC、gRPC、HTTP/REST 等协议绑定。下面的协作流程可以由单一框架内部实现，也可以在独立 Agent 均实现 A2A 时跨系统完成：

sequenceDiagram
    participant User as 用户
    participant PM as 路由/项目经理 Agent
    participant Coder as 研发 Agent
    participant QA as 测试/质检 Agent
 
    User->>PM: 提出需求: "开发一个在线格式化工具"
    PM->>Coder: 委派实现任务
    Coder->>QA: 提交产物与验证请求
    QA-->>Coder: 返回边界条件问题
    Coder-->>QA: 修复并重新验证
    QA-->>PM: 返回测试结果与产物
    PM->>User: 汇总交付并请求最终确认

Agent 究竟是什么？典型产品与框架

1. Chatbot 与 Agent 的区别

两者不是非黑即白的产品分类，而是一条能力光谱：

• Chatbot（聊天机器人）：主要围绕多轮对话生成回复，通常由用户逐步推动流程。
• Agent（智能体）：围绕目标管理状态，在一个循环中规划下一步、调用工具、读取结果、处理错误并继续执行，直到完成、失败或需要人工接管。

可以把常见 Agent 抽象为：

$\text{Agent} = \text{Model} + \text{Instructions} + \text{State/Memory} + \text{Tools} + \text{Control Loop} + \text{Guardrails}$

“反思”并不是每个 Agent 都必须单列的模块；它可能表现为测试、验证器、重试策略、另一个审查 Agent 或人工审批。Agent 也不意味着无限自治：可靠系统通常会设置最大步数、预算、超时、权限范围和高风险确认点。

2. 典型 Agent 产品形态：不只有办公助手

办公 Agent 只是 Agent 落地的一类。真正火起来的，是一批“能进入具体工作现场”的产品：有的写代码，有的管知识库，有的操作浏览器，有的做研究，有的把多个专家角色组织成团队。

这些产品听起来都叫 Agent，但侧重点不同：办公 Agent 重在文件和协作系统，编码 Agent 重在工程反馈，浏览器 Agent 重在 UI 操作，研究 Agent 重在证据链，多 Agent 平台重在把流程编排成可复用应用。它们共同的风险也很像：权限过大、工具误用、提示注入、数据泄露、错误结果被自动写入业务系统。

3. Agent 产品、协议与框架矩阵

补充思考：Scaling Law 下半场与未来展望