过去两三年，“大模型应用”从聊天机器人迅速演进到能读文件、写代码、跑脚本、查数据库、自动完成任务的智能体（Agent）。很多概念逐渐出现：Prompt、Context、Memory、RAG、Search、Function Calling、Workflow、LangChain、Agent、Skill、SubAgent、MCP……看起来像“术语堆砌”，但它们几乎都对应着一个非常具体的工程痛点。

这篇文章按时间顺序梳理：每个概念出现的历史原因、解决的问题、典型架构与实践要点。

---

0. 技术演进主线

可以把这条演进理解为：从“生成文字”到“连接世界并执行任务”。

• LLM：生成文本的引擎

• Prompt / Context：让引擎按你想要的方式输出

• Memory：跨会话保持用户信息与偏好

• RAG + Search：让模型引用外部知识、降低幻觉

• Function Calling / Tools：让模型能“做事”，而不只是“说”

• Workflow：让多步骤任务可靠执行、可观测、可复现

• LangChain（或类似框架）：把 Prompt/Memory/RAG/Tools/流程组织起来

• Agent / Skill / SubAgent：把任务拆解、规划、协作自动化

• MCP：工具接入标准化，让工具生态可复用、可插拔

---

1) LLM：一切的起点（2020–2022）

为什么出现

深度学习的语言建模能力达到“通用生成”的阈值：你给它一段输入，它能续写、总结、翻译、写代码、写文章。

解决了什么问题

• 大幅降低自然语言任务的开发成本

• “一个模型，多种任务”的通用能力（泛化）

但工程上很快撞墙

只有 LLM 时，你得到的是：

输入文本 → 输出文本

它的局限非常现实：

• 知识不更新：训练数据固定，无法天然知道企业文档、最新数据

• 不可访问私有数据：项目文件、数据库、内部系统都不在模型里

• 不能执行动作：它最多“建议你怎么做”，不会自己去做

• 缺少可控性与一致性：同一问题不同提法，输出差异大

于是下一阶段出现：Prompt。

---

2) Prompt：从“会说话”到“可控输出”（2022）

为什么出现

人们发现：同一个模型，“怎么问”会极大改变结果。Prompt 工程本质上是对模型的行为约束与角色设定。

有什么用

• 让输出更符合格式：JSON、步骤、要点、代码风格

• 让输出更符合身份：面试官、法务、产品经理、资深工程师

• 让输出更符合任务：总结、对比、推理、生成、校对

但 Prompt 仍解决不了两类硬问题

1. 模型仍然不知道你的外部信息（文档、代码库、数据库）

2. 模型仍然不会跨轮次稳定“记住”你说过什么

于是出现：Context 与 Memory。

---

3) Context：把“对话历史”喂回模型（2022–2023）

Context = 模型当前能看到的输入信息
Memory = 系统长期保存的信息

为什么出现

LLM是“无状态”的。每一次调用，如果你不提供之前的内容，它就像“失忆”。

有什么用

• 让对话可持续：把前面的对话内容拼到当前请求里

• 让模型在当前会话中保持一致：你说的限制条件、目标、背景能被记住

核心限制：上下文窗口

Context 的本质是“把历史重新塞回去”，它受限于：

• token 预算（越长越贵、越慢）

• 长上下文会引入噪声，效果反而下降

• 跨天/跨项目的长期记忆难维护

于是出现：Memory（持久记忆）。

---

4) Memory：把“用户相关信息”持久化（2023）

为什么出现

你不希望每次都重新解释：

• 我的项目背景是什么

• 我喜欢什么风格

• 我上次做到哪一步

• 我常用的技术栈、约束条件

有什么用

• 用户偏好：语言、格式、风格、默认工具

• 长期事实：身份、常用路径、项目约定

• 任务状态：上次未完成的步骤、待办清单

工程上要注意的点

• 记忆不是越多越好：需要“可更新、可删除、可解释”

• 区分短期记忆（session）与长期记忆（profile）

• 隐私与合规：哪些能存、存多久、用户可控

Memory 解决了“记住用户”，但还没解决“知道真实世界最新事实”。这在企业应用里尤其致命，于是出现：RAG 与 Search。

---

5) Search + RAG：让模型引用外部知识（2023）

为什么出现

LLM 的回答经常“看似合理但不真实”（幻觉），尤其涉及：

• 企业内部制度、产品规格、流程

• 最新文档、最新数据、最新代码状态

• 需要引用证据的场景（可追溯、可审计）

Search 是什么

Search 是“找资料”的能力，包括：

• 关键词检索（BM25/Elastic）

• 向量检索（embedding）

• 混合检索（关键词 + 向量 + rerank）

RAG 是什么

RAG（检索增强生成）是一个完整链路：

1. 把问题转成检索 query

2. 从知识库检索相关内容（Search）

3. 将检索结果作为 context 注入到 LLM

4. LLM 基于引用内容生成回答

有什么用

• 回答基于证据，幻觉显著下降

• 企业知识可用：文档、FAQ、代码注释、Wiki、数据库摘要

• 可追溯：能告诉用户“我根据哪段内容回答的”

RAG 让模型“知道”，但还没让模型“做”。现实任务往往需要读取文件、执行脚本、调用 API，于是出现：Function Calling（工具调用）。

---

6) Function Calling：让模型从“说”变成“做”（2023）

为什么出现

LLM 最初只能生成文本，但真实需求往往需要 执行操作，例如：

• “分析这个 CSV” → 需要运行 Python

• “查询订单状态” → 需要调用数据库/API

• “把 PDF 转成表格” → 需要调用解析工具

• “修改代码并运行测试” → 需要读写文件并执行命令

也就是说，用户真正需要的是 任务结果，而不仅仅是文字建议。

核心思想

Function Calling 让模型可以输出 结构化的函数调用指令，而不是普通文本：

{
  "tool": "get_weather",
  "arguments": {"city": "Shanghai"}
}

系统收到后：

1. 执行对应函数

2. 获取结果

3. 将结果返回给模型继续推理

整体流程：

因此模型具备了 调用外部能力的入口。

有什么用

• 串起外部能力：文件、数据库、Shell、浏览器、内部系统

• 大幅扩展可用场景：从聊天到自动化任务

工程要点

• 工具必须有清晰的 schema（参数类型、必填项、错误码）

• 工具执行要隔离与安全（权限、沙箱、确认机制）

• 需要可观测（日志、输入输出、重试、超时）

• 当工具数量较少时，可以直接将全部工具定义随请求发送给模型；但在实际生产系统中，通常会先做工具筛选，只将与当前任务最相关的工具注入上下文，以降低 token 成本并提高工具选择准确率。

当工具越来越多、任务越来越复杂，一个函数调用不够用，就进入了“流程化”阶段：Workflow。

---

7) Workflow：把多步任务做成“可运行的流程”（2023–2024）

为什么出现

复杂任务不是一次调用完成，而是几十个步骤：

• 读文件 → 清洗 → 统计 → 画图 → 写报告

• 拉代码 → 分析 → 修改 → 编译 → 测试 → 提交 PR

• 搜索 → 摘要 → 对比 → 生成提案 → 输出格式化文档

如果没有 workflow，系统会：

• 难以复现（同一任务每次结果不稳定）

• 难以调试（不知道哪一步出错）

• 难以治理（超时、重试、并发、资源消耗不可控）

有什么用

• 把任务拆成步骤节点（可重试/可恢复/可观测）

• 把关键步骤固定下来，提高稳定性

• 支持人类审批（例如运行危险命令前确认）

---

8) LangChain：把“零散能力”封装成开发框架（2023）

为什么出现

当你同时需要 Prompt、Memory、RAG、Tools、Workflow，纯手写会变成大量胶水代码。LangChain（以及同类框架）出现的价值是：

• 提供统一抽象：LLM、Retriever、Tool、Chain、Agent

• 让组合更快：把“检索+生成”“工具调用+循环”做成组件

有什么用（工程角度）

• 快速搭建原型

• 统一管理工具与检索

• 更容易引入 tracing / 评估 / 记忆等能力

但随着任务更复杂，人们希望系统不只是“按固定链条走”，而是能根据目标自动规划，于是出现：Agent。

Workflow 可以用很多方式实现，LangChain 只是其中一种。

---

9) Agent：让系统学会“规划与决策”（2024）

为什么出现

Workflow 需要人把流程写好，但现实任务变化太多。人们希望：

给目标即可，系统自动拆解与执行

这就是 Agent：大模型 + 规划（planning）+ 工具（tools）+ 循环（loop）。

Agent 是一个能够根据目标自动决定下一步行动并执行的 AI 系统。

Agent 有什么用

• 自动分解任务：把“做个项目分析”拆成搜索、阅读、执行、总结

• 自动选择工具：该读文件就读文件，该跑脚本就跑脚本

• 自动纠错：失败时重试、换方案、收敛结果

Agent 的关键工程难点

• 不稳定：自由规划可能“跑偏”

• 成本高：多轮调用、工具调用、搜索很贵

• 安全风险：可能执行危险命令/写坏文件

• 可控性：需要边界、预算、审计

解决办法通常是：
把 Agent 的能力模块化、可控化，于是出现：Skill 与 SubAgent。

---

10) Skill：把能力做成“可复用技能包”（2024）

为什么出现

工具很多，但直接暴露给 Agent 会导致：

• 选择困难（tool selection 难）

• 参数错误（schema 不匹配）

• 输出难用（返回格式不一致）

Skill 可以理解为“更高层的工具封装”，例如：

• analyze_csv()：内部包含读文件、清洗、统计、画图

• summarize_pdf()：内部包含解析、分段、要点汇总

• fix_build()：内部包含构建、解析报错、搜索、改代码、再构建

Skill 的价值是：把复杂操作变成稳定能力。

---

11) SubAgent：多智能体协作（2024）

为什么出现

复杂任务需要不同角色：

• 研究与检索

• 数据分析

• 代码修改

• 文档写作

• 审核与评估

把一个 Agent 做得“什么都能做”会很混乱。SubAgent 的思路是：

• 主 Agent 负责规划与协调

• 子 Agent 负责特定子任务（更专业、更可控，通常也不会增加主 Agent 的上下文）

工程上常见模式：

• Planner / Executor：规划与执行分离

• Researcher / Writer：研究与写作分离

• Critic / Judge：评审与打分分离

---

12) MCP：为什么工具生态需要“统一协议”（2024–2025）

为什么出现

Function Calling 让模型能调用工具，但工具接入仍然碎片化：每个框架、每个 IDE、每个平台都有自己的工具描述方式、鉴权方式、传参方式。

当生态开始形成（文件、搜索、数据库、脚本、PDF、Git、内部系统……），你会遇到一个“HTTP 之前的互联网”问题：

工具无法一次开发、多处复用。

MCP 的定位

Function Calling 解决“模型如何调用工具”，
MCP 解决“工具如何接入系统”。

在没有 MCP 时，LLM 通常通过 Function Calling 生成工具调用指令，由 Agent 在本地执行预先注册的工具函数。
引入 MCP 后，工具可以以独立服务（MCP Server）的形式存在，Agent 通过 MCP 协议访问这些外部工具，从而实现工具的标准化接入和复用。

MCP（Model Context Protocol）可以理解为：

• Agent 与工具之间的标准接口

• 工具以“server”的形式暴露能力，Agent 可以发现、调用、获取结果

它的价值在于：

• 可插拔：同一工具可以给多个 Agent/IDE/应用复用

• 可治理：权限、审计、沙箱能力更统一

• 可扩展：企业内部系统更容易按统一方式接入

---

结语：为什么这条演进几乎是必然的

从 LLM 到 MCP 的演化，不是“为了新概念而新概念”，而是每一步都在解决一个不可回避的现实问题：

• 只有 LLM：会说不会做

• 只有 Prompt：可控但不知外部事实

• 只有 Context：短期记忆，成本高

• 没有 RAG：幻觉高、不可审计

• 没有 Tools：无法自动化任务

• 没有 Workflow：不可靠、不可复现

• 没有 Agent：复杂目标无法自动拆解

• 没有 MCP：工具生态碎片化，重复造轮子