现在很多人一提 Agent，就会想到：

自动拆任务
自动调用工具
自动读文件
自动写代码
自动发邮件
自动管理日程
自动执行任务

但 Agent 不是一开始就长这样。

它是从最普通的 Prompt 对话，一步步演化出来的。

这条演化路径背后，其实一直在解决同一个问题：

怎样让大模型从“只会回答”，变成“能基于目标持续做事”？

可以先用一条主线概括：

Prompt 对话
→ Chain-of-Thought
→ RAG
→ ReAct
→ Toolformer / Function Calling
→ AutoGPT
→ Agent Framework
→ MCP / A2A
→ OpenClaw

这篇文章不展开每个节点的全部细节，只讲每个阶段：

当时遇到了什么问题
谁提出或推动了这个方向
核心原理是什么
为什么它影响了后来的 Agent

---

一、Prompt 对话：模型只负责回答

最早的大模型使用方式很简单：

用户输入 Prompt
模型生成回答
用户继续追问
模型继续回答

比如：

用户：帮我分析这个产品为什么没有留存。
模型：可能是用户需求不强、产品价值不清晰、缺少复访机制……

这个阶段，模型本质上只是：

输入文本，输出文本。

它不会主动拆任务，不会调用工具，也不会自己执行下一步。

它能告诉用户：

你应该去调研用户。

但它不会真的去调研。

它能告诉用户：

你应该整理数据。

但它不会自己打开文件、读取表格、生成报告。

这个阶段的问题是：

模型会说，但不会做。

但这种形态很快暴露出限制：

复杂任务容易跳步
模型不能查外部资料
模型不能调用工具
模型不能持续执行任务

Agent 后续的发展，基本都是围绕这些问题展开的。

---

二、Chain-of-Thought：让模型把中间过程写出来

Prompt 对话阶段，一个明显问题是：

复杂问题直接让模型回答，模型容易跳到结论。

比如问：

一个产品没有留存，应该怎么办？

普通回答可能直接说：

增加签到、积分、推送。

但更好的分析应该是：

第一步，先判断用户为什么第一次来。
第二步，再判断用户为什么第二次回来。
第三步，分析产品有没有持续价值。
第四步，再决定要不要做签到、积分、推送。

这就是 Chain-of-Thought，简称 CoT。

CoT 这个方向由 论文 《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》 中系统提出。论文的核心发现是：让模型生成一系列中间推理步骤，可以提升大模型在算术、常识、符号推理等任务上的表现，尤其是在足够大的模型上更明显。

CoT 的核心原理不是给模型写一个固定算法，而是：

通过 Prompt 或示例，引导模型先生成中间推理步骤，再生成答案。

普通回答是：

输入 → 答案

CoT 变成：

输入 → 中间步骤 → 答案

这里要注意：

CoT 不是一个真正的任务执行循环。

它不是模型自己不断判断：

我是否还要继续思考？
我是否已经完成任务？
下一步是否需要调用工具？

它仍然是在一次文本生成里完成输出，只是输出内容里多了中间推理过程。

所以 CoT 解决的问题是：

复杂问题不能直接跳到答案，需要显式中间推理。

但 CoT 仍然有明显限制：

它只能“想”，不能“查资料”，也不能“执行动作”。

模型可以写：

我需要查一下资料。

但它不会真的去查。

这就进入下一步。

---

三、RAG：让模型接入外部知识

CoT 解决了“直接回答容易跳步”的问题，但它仍然有一个限制：

模型只能依赖自己参数里的知识和当前上下文。

如果用户问的是常识问题，问题不大。

但如果用户问的是：

根据我上传的产品文档，分析这个功能优先级。

或者：

根据公司内部知识库，回答这个接口怎么使用。

模型训练时不可能知道这些私有资料。

这个问题在知识密集型任务里非常明显：

模型参数里的知识可能过时
模型不知道企业内部资料
模型难以给出可追溯来源
模型容易编造事实

RAG，也就是 Retrieval-Augmented Generation，正是为了解决这类问题。

RAG 由论文 《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》 中提出。论文的关键思路是把模型参数中的知识和外部非参数化记忆结合起来，让模型先从外部知识库检索相关内容，再基于这些内容生成答案。

RAG 的核心流程是：

用户问题
→ 检索相关资料
→ 把资料放进上下文
→ 模型基于资料生成回答

它解决的问题是：

模型不知道外部资料时，先把相关资料找出来，再让模型回答。

这让模型从：

只依赖参数里的知识

变成：

可以依赖外部知识库、文档、数据库、网页、代码仓库

这对 Agent 很重要。

因为一个真正能做事的 Agent，不可能只靠模型内部知识。

它需要读取：

文件
代码
文档
数据库
邮件
日志
知识库
用户历史记录

但也要分清楚：

RAG 本身不等于 Agent。

RAG 更像是：

给模型补充外部上下文

而 Agent 更像是：

围绕目标做决策、调用工具、持续执行

在后来的 Agent 系统里，RAG 通常会变成一个工具：

Action：retrieve_docs("情绪分析产品留存")
Observation：返回相关文档片段

所以 RAG 在 Agent 发展史里的位置是：

它让模型具备了访问外部知识的能力，为后来的工具调用和 Agent 执行打下基础。

---

四、ReAct：让模型一边推理，一边行动

RAG 让模型可以利用外部知识，但很多任务不是“检索一次资料，然后回答”就能完成的。

比如：

帮我分析这个项目为什么启动失败，并给出修改建议。

这类任务可能需要：

先读 README
再读配置文件
再看报错日志
再搜索依赖版本
再分析代码
最后生成修改方案

也就是说，模型需要：

先判断下一步做什么
再调用工具
再读取结果
再继续判断下一步

这个问题推动了 ReAct。

ReAct 由论文 《ReAct: Synergizing Reasoning and Acting in Language Models》 中提出。论文指出，之前语言模型的“推理”和“行动”通常是分开研究的，而 ReAct 把 reasoning traces 和 task-specific actions 交替生成，使模型可以一边推理，一边通过外部环境获得观察结果。

ReAct 的典型结构是：

Thought：我需要先查这个问题的背景。
Action：Search("情绪分析产品 留存")
Observation：搜索结果返回……

Thought：根据结果，我需要继续分析用户场景。
Action：Read(...)
Observation：返回内容……

Final Answer：最终回答。

它的核心原理是：

让模型在“思考—行动—观察”的循环中推进任务。

可以简化成：

Thought
→ Action
→ Observation
→ Thought
→ Action
→ Observation
→ Final Answer

但这里要注意：

循环通常不是模型自己在底层代码里执行的，而是由外部 Agent 框架控制的。

模型负责生成：

下一步要做什么

外部系统负责：

解析动作
调用工具
拿到观察结果
把结果追加回上下文
决定是否继续下一轮

可以用伪代码理解：

while not done and step_count < max_steps:
    model_output = model(context)
    action = parse_action(model_output)

    if action is None:
        break

    observation = run_tool(action)
    context += observation
    step_count += 1

这个循环不是无限执行，而是需要边界条件：

任务是否完成
是否达到最大步数
工具是否调用失败
模型是否输出最终答案
是否触发安全限制

所以 ReAct 解决的问题是：

模型不能只推理，还要能通过工具获得外部反馈。

这是 Agent 的关键转折点。

---

五、Toolformer / Function Calling：让工具调用变得稳定

ReAct 解决了“模型要边想边行动”的问题，但又暴露出新的工程问题：

模型说要调用工具，但怎么保证调用格式稳定？

早期可能让模型输出：

Action: search("OpenAI function calling")

然后程序去解析这段文本。

但这种方式很脆弱。

模型可能输出：

我想搜索一下 OpenAI function calling

也可能输出：

Search: OpenAI function calling

格式一乱，程序就解析失败。

这个阶段有两条重要路线。

第一条是研究路线：Toolformer。

Toolformer 由论文 《Toolformer: Language Models Can Teach Themselves to Use Tools》 中提出。论文关注的问题是：语言模型虽然强，但在算术、事实查询等基础功能上不如专门工具，因此应该学会何时调用外部 API、传什么参数、如何把工具结果整合进生成过程。

第二条是工程路线：Function Calling。

OpenAI 在 2023 年发布 Function Calling 能力，让开发者可以描述函数和参数结构，模型则选择要调用的函数，并输出结构化参数。OpenAI 官方更新中明确把 function calling 作为 API 更新的一部分，用来让模型更可靠地连接外部工具。

这一步解决的问题是：

模型要做事，必须稳定调用工具。

于是 Agent 的能力从：

我应该搜索一下

变成：

{
  "tool": "search",
  "arguments": {
    "query": "情绪分析产品 留存"
  }
}

这个变化非常关键。

因为真实系统需要：

工具名稳定
参数稳定
返回结果稳定
错误可处理
权限可控制

没有结构化工具调用，Agent 很难工程化。

所以 Toolformer 和 Function Calling 的影响是：

它们把“工具调用”从 Prompt 技巧，推进成了 Agent 工程能力。

---

六、AutoGPT：让模型围绕目标自己推进任务

有了推理、检索、工具调用之后，下一步自然出现一个问题：

能不能给模型一个目标，让它自己持续往下做？

AutoGPT 就是这个阶段的代表。

AutoGPT 是 Toran Bruce Richards 在 2023 年 3 月发布的开源自主 Agent 项目。它使用 GPT-4 等大模型，根据用户给定的自然语言目标，自主拆解子任务，并通过浏览网页、管理文件等工具推进任务。

AutoGPT 的典型流程是：

用户给一个目标
→ Agent 自己拆任务
→ 选择工具
→ 执行
→ 观察结果
→ 更新计划
→ 继续执行

比如用户说：

帮我调研一个创业方向，并生成报告。

AutoGPT 类 Agent 会尝试：

搜索资料
阅读网页
总结信息
继续搜索
写入文件
生成报告

这一步让开发者第一次明显感受到：

大模型不只是聊天，它可以变成一个自动执行任务的系统。

但问题也很快暴露出来：

容易循环
容易跑偏
成本高
幻觉多
停止条件不清晰
工具调用不稳定
错误会不断传播

所以 AutoGPT 的意义不是它本身已经成熟。

它真正推动的是一个观念：

Agent 可以围绕一个目标，持续规划和执行。

这个阶段解决的问题是：

用户不想每一步都手动指挥，希望模型能自己推进任务。

---

七、Agent Framework：把 Agent 工程化

AutoGPT 火了之后，开发者发现：

每个人都在重复造轮子。

一个 Agent 系统通常需要：

Prompt 模板
工具注册
工具调用
RAG
Memory
状态管理
输出解析
错误重试
执行图
日志追踪

所以 Agent 框架开始流行。

典型代表包括：

LangChain
LlamaIndex
Semantic Kernel
AutoGen
LangGraph
CrewAI

其中 LangChain 由 Harrison Chase 在 2022 年 10 月作为开源项目发布，定位是帮助开发者把大语言模型集成进应用，包括文档分析、总结、聊天机器人、代码分析等场景。

这些框架解决的问题是：

Agent 开发不能只靠手写 Prompt，需要工程抽象。

它们把常见能力封装起来：

模型调用
工具管理
RAG 检索
记忆管理
多步骤执行
多 Agent 协作
结果追踪

这一步非常重要。

因为 Agent 不再只是一个 Prompt 技巧，而开始变成一个工程系统。

在这个阶段，RAG 也从单独的问答链路，逐渐变成 Agent 系统里的一个标准模块。

比如：

需要查资料 → 调用 RAG
需要执行动作 → 调用工具
需要长期上下文 → 调用 Memory
需要多步任务 → 进入 Agent Loop

但框架化之后又出现了新问题：

每个框架都有自己的工具格式
每个应用都要单独适配工具
工具不能跨平台复用
数据源接入成本高
Agent 之间无法标准协作

这就引出了后来的协议化。

---

八、MCP / A2A：Agent 开始协议化

当 Agent 越来越多，工具越来越多，框架也越来越多时，最大的问题变成：

怎么让 Agent 标准化地连接工具、数据和其他 Agent？

这里出现了两个重要方向。

---

1. MCP：解决 Agent 连接工具和数据的问题

MCP，全称 Model Context Protocol。

它由 Anthropic 在 2024 年 11 月推出。Anthropic 官方介绍里明确说，MCP 是一个开放标准，用来在数据源和 AI 工具之间建立安全的双向连接。它的架构是：开发者可以通过 MCP Server 暴露数据或工具，也可以构建 MCP Client 去连接这些 Server。

可以简单理解成：

MCP Server：暴露工具和数据
MCP Client：Agent 或 AI 应用连接这些工具

MCP 解决的是 N × M 集成问题。

以前：

每个 Agent 应用都要单独接每个工具

后来：

工具做成 MCP Server
Agent 做成 MCP Client

所以 MCP 影响的是：

Agent 如何标准化连接工具和数据源。

---

2. A2A：解决 Agent 和 Agent 之间通信的问题

A2A，全称 Agent2Agent Protocol。

Google 在 2025 年 4 月发布 A2A。Google 官方介绍称，A2A 的目标是让不同厂商、不同框架构建的 AI Agent 能够互相通信、安全交换信息，并在企业应用上协调行动。

可以这样理解：

MCP：Agent ↔ 工具 / 数据
A2A：Agent ↔ Agent

MCP 解决的是工具和数据接入。

A2A 解决的是多 Agent 协作。

这一阶段说明，Agent 已经从“单个应用能力”，开始走向“生态协作能力”。

---

九、OpenClaw：Agent 进入真实工作流入口

最后说 OpenClaw。

这里要先说清楚：

OpenClaw 更像一个个人 Agent 产品 / 框架形态，不是像 MCP 那样的底层协议规范。

OpenClaw 由 Peter Steinberger 创建。OpenClaw 官方文档将其定义为一个 self-hosted gateway，用来把 WhatsApp、Telegram、Slack、Discord、iMessage 等聊天入口连接到 AI coding agents；用户运行一个 Gateway 进程，它就成为消息应用和可用 AI 助手之间的桥梁。

OpenClaw 代表的是 Agent 的一个新阶段：

Agent 不再只是网页聊天框里的助手，而是进入用户真实工作流。

以前：

打开 AI 网站
输入 Prompt
复制答案
自己去执行

OpenClaw 这类形态更像：

用户在 WhatsApp / Telegram 等聊天入口发一句话
→ Agent 接收任务
→ 调用邮箱、日历、文件、网页等工具
→ 执行任务
→ 把结果发回聊天入口

也就是说，OpenClaw 的重点不是提出一个全新的底层算法。

它的重点是把前面这些能力组合起来：

聊天入口
Agent Runtime
工具调用
RAG
Session
Memory
MCP
任务执行
权限控制
结果投递

所以 OpenClaw 代表的问题是：

Agent 怎么从技术演示，变成用户每天真的会用的个人执行系统？

---

十、整条发展线的本质

如果只看名字，会觉得 Agent 发展史很复杂。

但如果看底层问题，其实很清楚。

阶段	谁提出 / 推动	解决的问题	核心原理
Prompt 对话	ChatGPT 等对话式 LLM 产品推动普及	自然语言如何驱动模型生成答案	输入文本，输出文本
Chain-of-Thought	Jason Wei 等人	复杂问题直接回答容易跳步	生成中间推理步骤
RAG	Patrick Lewis 等人	模型不知道外部知识、私有知识、实时知识	检索资料后增强上下文再生成
ReAct	Shunyu Yao 等人	模型只能想，不能边做边修正	Thought / Action / Observation 循环
Toolformer	Timo Schick 等人	模型需要学会何时使用工具	模型学习调用外部 API
Function Calling	OpenAI 等 API 平台推动	工具调用格式不稳定	函数描述 + JSON 参数
AutoGPT	Toran Bruce Richards	用户不想每一步都手动指挥	目标驱动的自主循环
Agent Framework	LangChain、LlamaIndex 等	Agent 开发重复造轮子	封装工具、RAG、Memory、状态和执行流
MCP	Anthropic	Agent 连接工具和数据缺少标准	MCP Server / MCP Client
A2A	Google	Agent 之间缺少通信协议	Agent-to-Agent 通信和协作
OpenClaw	Peter Steinberger	Agent 需要进入真实聊天入口和工作流	自托管 Gateway + 多渠道入口 + Agent Runtime

---

十一、最核心的原理总结

Agent 的发展，不是简单从“聊天机器人”变成“更聪明的聊天机器人”。

它真正的发展方向是：

文本生成
→ 中间推理
→ 外部知识
→ 工具调用
→ 循环执行
→ 工程框架
→ 协议标准
→ 真实工作流

其中每一步都在解决一个实际问题。

更底层地说：

Prompt 对话：模型只生成答案
CoT：让模型生成推理步骤
RAG：让模型接入外部知识
ReAct：让模型把推理和行动交替起来
Toolformer / Function Calling：让行动变成工具调用
AutoGPT：让工具调用进入目标驱动循环
Agent Framework：让循环执行工程化
MCP / A2A：让工具、数据、Agent 协议化
OpenClaw：让 Agent 进入真实用户入口

所以最终可以这样理解 Agent：

Agent 不是一个单独模型，而是一个围绕模型构建的控制系统。

它至少包含：

目标
上下文
模型
推理
RAG
工具
观察结果
状态
循环控制
停止条件
权限
评测

从 Prompt 到 OpenClaw，整个过程就是：

让大模型从“回答问题”，一步步变成“能基于目标持续执行任务”的系统。