Agent的核心定义与能力边界

大模型如GPT-4o虽具备强大的逻辑推理能力，但其本质存在无法感知或改变外界环境的根本限制。这意味着模型无法直接操作文件系统或执行外部程序，例如编写贪吃蛇游戏代码后，仍需人工介入将代码写入文件。若需基于已有代码进行修改，用户必须手动复制代码提供给模型，因为模型无法主动查询本地环境中的已有资源。这种局限性表明，单纯的大模型只是一个封闭的“大脑”，缺乏与物理或数字世界交互的感官与四肢。

“大模型无法感知或者是改变外界环境……这就是大模型无法感知外界环境的体现。”

为突破这一限制，Agent（智能体）应运而生。Agent通过将大模型与读写文件、查看目录、运行终端命令等工具相结合，赋予模型感知和改变环境的能力。形象地说，如果说大模型是“大脑”，那么Agent就是拥有感官和四肢的“机器人”，能够自动化地完成如Cursor编写代码或Manus搜索比较手机性能等复杂任务，全程无需人工干预。

ReAct运行模式的原理解析

Agent最核心的运行模式是ReAct（Reasoning and Acting，思考与行动），该模式源于2022年10月提出的论文，至今仍是应用最广泛的架构。ReAct流程包含四个关键步骤：Thought（思考）、Action（行动）、Observation（观察）和Final Answer（最终答案）。模型首先思考任务步骤，决定是否调用工具；若调用，则执行Action并获取工具返回的Observation；随后再次进入Thought阶段，判断是否需要继续行动或输出结论。这一循环直到模型认为信息充足，输出Final Answer为止。

“ReAct流程的核心步骤是 Thought Action Observation 和Final Answer 记住这几个词 我们后面会用到”

ReAct模式的实现主要依赖于系统提示词（System Prompt）而非模型训练本身。系统提示词如同给模型设定的“迷你剧本”，规定了角色、规则及工具使用规范。一个标准的ReAct提示词通常包含五个部分：职责描述（分解任务、循环思考与行动）、示例（展示Thought-Action-Observation流程）、可用工具（如读写文件）、注意事项及环境信息（如当前OS和目录结构）。通过这种结构化指令，模型被强制引导遵循特定的交互逻辑。

基于DeepSeek的ReAct流程模拟演示

为了验证ReAct模式的有效性，演示者使用DeepSeek模型配合自定义系统提示词进行了模拟测试。任务要求使用HTML、CSS和JS编写贪吃蛇游戏，代码分文件存储。由于DeepSeek未提供独立的系统提示词接口，演示者将提示词与用户任务合并发送。模型严格遵循指令，在Thought中规划步骤，通过Action请求调用write_to_file工具写入index.html，并等待模拟的Observation反馈。

在模拟过程中，模型依次完成了三个文件的写入请求： 1. Thought: 分析需先创建HTML结构。 2. Action: 调用write_to_file写入index.html。 3. Observation: 模拟返回“写入成功”。

随后模型重复上述流程，分别写入CSS和JS文件。当所有必要文件写入完毕后，模型在Thought阶段判断无需再调用工具，随即输出Final Answer，标志着任务完成。这一过程清晰展示了模型如何像剧本演员一样，一步步执行预定的ReAct逻辑。

简化版Claude Code的代码实现与运行

基于上述原理，演示者构建了一个名为ReActAgent的Python类，实现了真正的工具调用功能。核心代码位于agent.py，构造函数接收工具列表（读取、写入、运行终端）、模型实例（GPT-4o）及项目目录。run函数是核心引擎，它初始化包含系统提示词和用户任务的Message列表，进入while循环直至收到Final Answer。

在循环中，程序调用模型获取响应，提取Thought并打印；若未结束，则解析Action中的函数名与参数。出于安全考虑，执行终端命令前会主动询问用户确认。执行工具后，将结果作为Observation追加至Message列表，供模型在下一次请求时参考。这种机制让模型能根据实际执行结果动态调整后续策略。

“这个while循环做的事情 请求模型 提取thoughts 检测final answer 提取action并执行其中的工具”

实际运行中，Agent成功在snake目录下生成了HTML、CSS和JS文件。生成的贪吃蛇游戏界面正常，交互流畅，验证了该简化版Agent具备类似Claude Code的代码生成与执行能力。整个架构证明了通过系统提示词引导结合工具函数调用，即可构建出具备环境感知与操作能力的智能体。

ReAct Agent 的核心流程与角色交互

要彻底理解 Agent 的运行机制，我们需要梳理其内部的角色分工与数据流向。整个系统由用户和Agent两大角色构成，而 Agent 内部又细分为三个关键部分：模型（负责推理）、工具（即函数，负责执行具体操作）以及Agent 主程序（负责串联全流程的代码逻辑，类似于代码中的 run 函数）。

“整个流程图里面有两个角色 用户和Agent 而Agent又可以分成三个部分 分别是模型 工具 也就是函数 还有Agent主程序”

在典型的 ReAct Agent 问答流程中，交互遵循严格的循环逻辑： 1. 用户提交任务，Agent 主程序首先调用模型。 2. 模型返回思考过程（thought）和行动指令（action）。主程序将这两者展示给用户，并调用 action 指定的工具。 3. 工具执行完毕后返回结果，主程序将结果展示给用户，并将其加入历史消息列表。 4. 主程序再次请求模型，处理新的 thought、action 和 observation（观察结果），形成闭环。

这一循环会持续进行，直到模型判断任务已完成。此时，模型不再返回 action，而是返回 thought 和 final answer（最终答案）。主程序展示最终答案后，整个 ReAct 流程结束。这种模式通过“思考-行动-观察”的迭代，实现了复杂的任务处理。

Plan-and-Execute 模式的架构组成

虽然 ReAct 是目前最广泛使用的 Agent 构建模式，但它并非唯一方案。另一种常见模式是“先规划再执行”，例如 Manus 和 Claude Code 中常见的创建 TODO 列表后逐步执行的方式。LangChain 提出的 Plan-and-Execute 模式是这一类的典型代表，其核心优势在于引入了动态修改规划的环节，从而具备更高的灵活性。

该模式的 Agent 内部结构更为复杂，包含以下核心组件： * Plan 模型：负责生成初始的执行计划。 * Re-Plan 模型：负责根据执行结果动态调整计划。Plan 和 Re-Plan 可以是同一模型，也可以是两个独立模型，此处暂视为两个。 * 执行 Agent：负责执行计划中的具体步骤。这是一个“Agent 套 Agent”的设计，执行 Agent 内部可以运行 ReAct 模式或其他模式，只要它能完成指定步骤即可。 * Agent 主程序：负责串联上述所有模块，协调 Plan、执行 Agent 和 Re-Plan 之间的交互。

这种架构允许系统在每一步执行后重新评估计划，适应执行过程中出现的新信息或变化，从而比静态规划更加鲁棒。

Plan-and-Execute 的动态执行循环模拟

为了清晰展示 Plan-and-Execute 的工作机制，我们以一个问题为例：“今年澳网男子冠军的家乡是哪里？”（注：澳网为每年举办的澳大利亚网球公开赛）。Agent 主程序首先将问题发送给 Plan 模型，生成初始执行计划： 1. 查询当前日期。 2. 根据年份查询澳网男子冠军名字。 3. 查询该冠军的家乡。

随后，主程序将计划发给执行 Agent 执行第一步。执行 Agent 通过内置的网络搜索工具查询当前日期（假设为 2025 年），并将结果返回。接着，主程序将用户问题、第一个执行计划和历史执行记录一并发送给 Re-Plan 模型，以生成新的计划。

“Agent的主程序接到新的执行计划之后 它便会回头再重复这个框中的流程 在我们这个例子中 这个框中的流程一共会运行三轮”

Re-Plan 模型会根据新信息优化计划： * 第一轮调整：由于日期已查知，新计划中不再包含“查询日期”步骤；原“查询对应日期冠军”的步骤被精确化为“查询 2025 年澳网男子冠军名字”。 * 第二轮执行与调整：执行 Agent 查询到冠军名字后，Re-Plan 模型再次介入，生成包含最后一步（查询家乡）的计划。 * 第三轮执行与终止：执行 Agent 完成最后一步后，Re-Plan 模型判断所有步骤已完成，不再返回新计划，而是直接返回最终答案。

值得注意的是，Re-Plan 模型的输出有两种可能：新的执行计划（若仍有步骤）或最终答案（若任务完成）。这种动态反馈机制确保了 Agent 能够根据实时执行情况灵活调整策略，直至解决问题。