从 ReAct 到 Agent Loop：大模型应用范式是如何一步步演变的？

从 ReAct 到 Agent Loop：大模型应用范式是如何一步步演变的？

摘要

大模型应用的发展，并不是简单地从一个模型换到另一个模型，也不是单纯把 Prompt 写得更复杂。真正的变化在于：AI 正在从"回答问题的文本生成器"，逐渐演变为"能够调用工具、连接系统、持续反馈并完成任务的执行系统"。

从早期的 Prompt Engineering，到 Chain-of-Thought，再到 ReAct、Tool Use、RAG、Agent Harness 和 Agent Loop，大模型应用的核心范式正在发生明显变化。本文将围绕这条演进路径，梳理 AI 应用从"生成答案"到"执行任务"的关键变化。

---

一、为什么要讨论 AI 范式的演变？

很多人在理解大模型应用时，仍然停留在一个很浅的层面：

给模型一个问题，模型返回一个答案。

这种理解不能说错，但已经不够了。

早期的大模型应用确实主要是问答、总结、翻译、改写、代码生成等文本任务。但随着大模型能力增强，开发者很快发现一个问题：

模型只会生成文本是不够的。

因为真实业务场景里，用户想要的往往不是一句回答，而是一个完成后的结果。

例如：

• 用户不只是想问"这个订单状态是什么"，而是希望 AI 直接查询订单系统；
• 用户不只是想问"帮我画个流程图"，而是希望 AI 自动生成可编辑的图；
• 用户不只是想问"这份知识库里有没有答案"，而是希望 AI 自动检索、引用来源、整理结论；
• 用户不只是想问"帮我安排一下任务"，而是希望 AI 能分解任务、执行任务、检查结果。

所以，大模型应用的演进本质上不是"回答得更像人"，而是：

从文本生成，走向工具调用；

从单次问答，走向持续执行；

从模型能力，走向系统能力。

这也是 ReAct、Harness、Agent Loop 这些概念出现的根本原因。

---

二、第一阶段：Prompt Engineering，让模型更好地回答

最早的大模型应用主要依赖 Prompt Engineering，也就是提示词工程。

开发者通过设计更清晰的输入，让模型输出更符合预期的内容。

例如：

请你扮演一名资深 Java 后端面试官，围绕 Redis 分布式锁提出 5 个高频问题，并给出面试回答。

相比直接问：

Redis 分布式锁是什么？

前一种 Prompt 明确了角色、任务、范围和输出形式，所以模型回答会更稳定。

这一阶段的核心是：

通过更好的输入，获得更好的输出。

Prompt Engineering 主要解决的是"模型如何理解任务"的问题。它让模型更容易按照用户预期生成内容，但它仍然有明显局限：

1. 模型只能基于已有知识回答；
2. 无法主动访问外部系统；
3. 无法确认实时数据；
4. 无法真正执行任务；
5. 容易出现幻觉。

也就是说，Prompt 阶段的大模型，本质上仍然是一个"更聪明的文本生成器"。

---

三、第二阶段：Chain-of-Thought，让模型显式推理

在 Prompt Engineering 之后，一个重要变化是 Chain-of-Thought，也就是 CoT，通常可以理解为"思维链"。

它的核心思想是：

不要让模型直接给答案，而是引导模型分步骤推理。

例如普通问法是：

这道题答案是多少？

CoT 式问法则是：

请你一步一步分析这道题的解法，并给出最终答案。

这样做的好处是，模型不会直接跳到结论，而是会先拆解问题，再逐步推导。

在数学推理、逻辑分析、代码理解、复杂决策等任务中，CoT 可以明显提升模型表现。

但是，CoT 仍然有一个根本问题：

它只是让模型"更会想"，但没有让模型"真的能做"。

模型可以分析一个订单系统应该怎么查，但它不能真正查数据库。

模型可以解释一个接口应该怎么调用，但它不能自动完成业务操作。

模型可以写出计划，但不能持续跟踪执行结果。

所以，CoT 解决了推理问题，但还没有解决行动问题。

---

四、第三阶段：ReAct，让模型开始"边想边做"

ReAct 是 Reasoning and Acting 的结合。

这里要特别注意：ReAct 不是前端框架 React 。

它是大模型智能体领域中的一种典型范式。

ReAct 的核心是让模型在任务执行过程中交替进行：

Thought → Action → Observation

也就是：

思考 → 行动 → 观察结果

一个简单例子如下：

用户问题：请帮我查一下某个订单的当前状态。

Thought：用户想知道订单状态，我需要调用订单查询工具。
Action：调用订单查询接口，传入订单号。
Observation：接口返回订单状态为"运输中"。

Thought：已经拿到订单状态，需要整理成用户能理解的话。
Final Answer：该订单目前处于运输中，预计明天送达。

可以看到，ReAct 和普通 Prompt 最大的区别是：

模型不再只是直接回答，而是可以先思考，再调用工具，再根据工具返回结果继续推理。

这一步非常关键。

它让大模型从"静态生成器"开始向"任务执行者"转变。

ReAct 解决了三个问题：

第一，模型可以使用外部工具。

比如搜索引擎、数据库、计算器、业务接口、代码执行器等。

第二，模型可以根据外部反馈修正答案。

如果第一次工具调用失败，模型可以换一种方式继续尝试。

第三，模型可以处理多步骤任务。

不再局限于一次输入、一次输出，而是可以逐步推进任务。

但是，ReAct 也不是最终答案。它只是让模型"会行动"，但还没有解决工程落地中的复杂问题。

例如：

• 模型可以调用哪些工具？
• 工具权限怎么控制？
• 调用失败怎么办？
• 每一步执行过程怎么记录？
• 重要操作是否需要人工确认？
• 多轮任务状态怎么保存？
• 错误结果如何回滚？

这些问题不是 ReAct 本身能完全解决的。

于是，大模型应用开始进入下一个阶段：工具调用和系统接入。

---

五、第四阶段：Tool Use / RAG / MCP，让模型连接外部世界

如果说 ReAct 解决的是"模型如何行动"，那么 Tool Use、RAG 和 MCP 解决的就是：

模型如何连接真实世界。

1. Tool Use：让模型调用工具

Tool Use 可以理解为让模型使用外部工具完成任务。

例如：

• 调用搜索工具获取最新信息；
• 调用数据库查询用户订单；
• 调用企业微信或飞书发送通知；
• 调用绘图工具生成流程图；
• 调用代码执行器运行脚本；
• 调用日历工具创建会议。

在这个阶段，模型不再完全依赖自己内部的知识，而是可以借助外部系统完成任务。

这本质上是把模型从一个"知识容器"，变成了一个"工具调度器"。

---

2. RAG：让模型接入外部知识库

RAG 的全称是 Retrieval-Augmented Generation，通常可以理解为"检索增强生成"。

它的核心流程是：

用户问题 → 检索知识库 → 找到相关文档 → 把文档交给模型 → 模型生成答案

RAG 主要解决的是大模型的知识局限问题。

因为模型本身可能不知道企业内部制度、最新产品文档、业务流程、用户手册等内容。

这些内容不能只靠模型参数记忆，而应该通过外部知识库实时检索。

例如在企业智能问答场景中，用户问：

公司报销流程是什么？

模型不应该凭空编答案，而应该先检索企业知识库，找到对应制度文档，再基于文档回答，并给出引用来源。

这也是很多企业知识问答系统的基础架构。

RAG 的价值在于：

1. 降低幻觉；
2. 支持私有知识；
3. 支持知识更新；
4. 可以返回引用来源；
5. 让模型回答更可追溯。

---

3. MCP：让工具和上下文接入更加标准化

当大模型应用越来越复杂时，工具和数据源会变得非常多。

比如一个企业 Agent 可能需要连接：

• 飞书文档；
• 企业知识库；
• 数据库；
• GitHub；
• 日历；
• 邮件；
• 工单系统；
• 内部业务系统；
• 文件系统。

如果每个工具都单独适配，开发成本会非常高。

因此，行业开始强调工具和上下文接入的标准化。

MCP 可以理解为一种连接模型与外部工具、数据源、上下文资源的协议思路。

它试图解决的问题是：

如何让不同模型、不同工具、不同系统之间，以更统一的方式协作。

这一阶段的核心变化是：

模型不再是孤立存在的，而是开始嵌入企业系统、业务流程和工具生态中。

但是，只能调用工具还不够。

真正的工程系统还必须解决稳定性、安全性、权限、日志和可控性问题。

这就引出了 Agent Harness。

---

六、第五阶段：Agent Harness，让 Agent 变成可控工程系统

Harness 这个词可以理解为"执行壳"或"运行框架"。

在大模型应用里，Agent Harness 指的是围绕模型构建的一整套运行环境，用来管理工具、状态、权限、日志、错误处理和人工审批。

简单来说：

ReAct 让模型知道下一步该做什么；

Tool Use 让模型有工具可以调用；

Harness 则负责让整个执行过程变得安全、稳定、可控。

一个成熟的 Agent Harness 通常包含以下模块：

模块	作用
Prompt 管理	控制模型角色、任务边界和输出格式
Tool Registry	管理模型可以调用哪些工具
Memory / State	保存上下文、任务状态和历史记录
Guardrails	限制危险行为，避免越权和错误输出
Tracing	记录每一步模型推理和工具调用过程
Retry / Fallback	工具失败时进行重试或降级
Human Approval	关键操作前加入人工确认
Permission Control	控制用户身份和工具权限
Result Validation	对模型输出或工具结果进行校验

这一步非常重要。

很多人谈 Agent，只喜欢谈"模型会自己干活"。

但现实是，如果没有 Harness，Agent 很容易变成一个不可控的黑盒。

例如，模型要帮用户删除一批文件。

如果没有权限控制和人工确认，它可能误删重要内容。

模型要调用企业内部系统。

如果没有身份校验和权限透传，它可能访问不该访问的数据。

模型要执行多步任务。

如果没有日志追踪和状态管理，一旦出错，很难知道是哪一步出了问题。

所以，真正能落地的 Agent，一定不是单纯靠一个大模型完成的，而是依赖完整的工程框架。

可以这么理解：

模型负责判断和生成，Harness 负责约束和执行。

这也是大模型应用从"Demo"走向"生产系统"的关键分界线。

---

七、第六阶段：Agent Loop，让 AI 具备闭环执行能力

Agent Loop 是智能体运行过程中最核心的结构之一。

它通常可以概括为：

Observe → Plan → Act → Reflect → Continue

也就是：

观察 → 规划 → 执行 → 反思 → 继续

或者用更接近 ReAct 的形式表达：

Thought → Action → Observation → Thought → Action → Observation

Agent Loop 的核心是：

模型不再只是被调用一次，而是在循环中持续推进任务。

例如，让一个 Agent 帮用户完成一份竞品分析报告，它可能会经历以下过程：

1. 理解用户目标；
2. 拆解任务；
3. 搜索竞品资料；
4. 提取关键信息；
5. 生成初稿；
6. 检查内容是否完整；
7. 补充遗漏信息；
8. 调整结构；
9. 输出最终报告。

这和普通问答完全不同。

普通问答是：

用户输入 → 模型输出

Agent Loop 是：

用户目标 → 多轮规划 → 多次工具调用 → 多次反馈修正 → 最终结果

也就是说，Agent Loop 让 AI 从"回答者"变成了"执行者"。

---

八、Agent Loop 的价值：从一次性回答到持续完成任务

Agent Loop 的价值主要体现在三个方面。

1. 可以处理复杂任务

复杂任务往往不是一步完成的。

例如：

• 自动写一份报告；
• 自动分析一个代码仓库；
• 自动整理会议纪要并生成任务；
• 自动查询业务系统并生成图表；
• 自动根据用户反馈修改方案。

这些任务都需要多个步骤。

如果只靠一次模型调用，很难完成得稳定。

Agent Loop 可以让模型持续推进任务，每一步根据前一步结果调整后续动作。

---

2. 可以根据反馈修正错误

传统大模型生成答案后，结果基本就结束了。

但 Agent Loop 可以让模型在执行过程中检查结果。

例如：

模型生成了一段 SQL。
执行后发现报错。
模型读取报错信息。
模型修改 SQL。
再次执行。
最终返回正确结果。

这就是典型的闭环。

模型不再只是"给出答案"，而是可以根据环境反馈不断修正。

---

3. 可以更接近真实业务流程

真实业务流程往往包括：

• 查询；
• 判断；
• 审批；
• 执行；
• 记录；
• 通知；
• 回滚。

这些流程不是简单问答能完成的。

Agent Loop 可以让 AI 嵌入业务流程，承担一部分自动化执行工作。

例如企业内部的智能办公 Agent，可以完成：

• 查询员工信息；
• 检索制度文档；
• 生成流程图；
• 整理会议结论；
• 创建待办任务；
• 调用业务系统；
• 返回引用来源。

这类应用已经不再是传统聊天机器人，而是面向业务流程的智能执行系统。

---

九、但 Agent Loop 不是越长越好

很多人一谈 Agent Loop，就会误以为循环越多、自治程度越高越好。

这是一个很危险的误解。

Agent Loop 也会带来明显风险。

1. 成本上升

每一轮循环都可能调用模型、调用工具、读取数据。

如果没有轮次限制，成本会迅速上升。

2. 错误累积

如果前一步判断错了，后面的步骤可能会沿着错误方向继续执行。

这会导致结果越来越偏。

3. 进入无效循环

有些 Agent 可能反复尝试同一个失败动作，导致一直无法结束任务。

4. 权限风险

Agent 能调用的工具越多，风险就越大。

尤其涉及删除、修改、发送、支付、审批等操作时，必须非常谨慎。

5. 可观测性要求更高

如果一个 Agent 执行了十几步，最后结果错误，开发者必须知道每一步发生了什么。

否则根本无法排查问题。

所以，真正可落地的 Agent Loop，必须和 Harness 结合。

也就是说：

Loop 提供持续执行能力，Harness 提供安全边界和工程控制能力。

没有 Harness 的 Loop，只是一个容易失控的循环。

---

十、从 Prompt 到 Agent Loop 的完整演进路径

可以把整个大模型应用范式总结成下面这条路径：

Prompt Engineering
        ↓
Chain-of-Thought
        ↓
ReAct
        ↓
Tool Use / RAG / MCP
        ↓
Agent Harness
        ↓
Agent Loop
        ↓
Multi-Agent

每一步都在解决上一阶段的问题。

阶段	核心能力	解决的问题	局限
Prompt Engineering	指令控制	让模型更好地回答	不能执行任务
Chain-of-Thought	显式推理	让模型更会分析	仍然不能行动
ReAct	推理 + 行动	让模型调用工具	工程控制不足
Tool Use / RAG / MCP	外部接入	连接工具和知识库	权限和稳定性复杂
Agent Harness	工程控制	管理工具、状态、日志、权限	仍需循环执行
Agent Loop	闭环执行	持续规划、行动和修正	成本、风险、稳定性更高
Multi-Agent	多智能体协作	分工处理复杂任务	协调成本更高

这条路径说明了一个核心事实：

AI 应用的进化方向，不是单纯让模型更会说，而是让模型更会做。

---

十一、未来趋势：从单体 Agent 到多智能体协作

在 Agent Loop 之后，一个明显趋势是 Multi-Agent，也就是多智能体协作。

单个 Agent 可以完成一部分任务，但复杂任务往往需要多个角色协作。

例如一个软件开发任务，可以拆成：

• 需求分析 Agent；
• 架构设计 Agent；
• 编码 Agent；
• 测试 Agent；
• Code Review Agent；
• 文档生成 Agent。

每个 Agent 负责不同环节，最终协同完成一个完整任务。

这和真实团队很像。

但是，多智能体并不一定比单智能体更好。

它会带来新的问题：

1. 不同 Agent 之间如何通信？
2. 谁负责最终决策？
3. 多个 Agent 意见冲突怎么办？
4. 如何避免重复工作？
5. 如何控制整体成本？
6. 如何保证最终结果一致？

所以 Multi-Agent 更适合作为复杂任务场景下的高级形态，而不是所有应用都必须使用。

对于大多数业务系统来说，更现实的落地路径仍然是：

单 Agent + 工具调用 + RAG + Harness + 可控 Loop

也就是先把一个 Agent 做稳定，再考虑多个 Agent 协作。

---

总结：未来不是更强 Prompt，而是更可靠的 AI 系统工程

大模型应用的发展，本质上经历了从"模型中心"到"系统中心"的变化。

早期应用关注的是：

如何写好 Prompt，让模型回答得更好？

现在真正重要的问题变成了：

如何让模型安全、稳定、可控地完成任务？

ReAct 解决了推理和行动结合的问题。

Tool Use、RAG 和 MCP 解决了外部工具与知识接入的问题。

Agent Harness 解决了工程可控性问题。

Agent Loop 则让 AI 具备了持续反馈和闭环执行能力。

所以，未来的 AI 应用不会只是一个聊天窗口，而会更像一个连接工具、数据、权限、流程和业务系统的智能执行层。

一句话总结：

AI 范式的演变，不是从一个提示词技巧走向另一个提示词技巧，而是从"模型生成文本"走向"模型嵌入系统"。真正有价值的 AI 应用，不只是能回答问题，而是能在可控边界内完成任务。