从原理到实战：一文彻底搞懂AI Agent与ReAct模式

大模型能写代码、能解逻辑题，却无法自己把代码保存成文件，也无法主动查看你电脑里已有的项目。这个看似不起眼的限制，恰恰是AI Agent诞生的起点。本文基于B站UP主“海文”的实战课程，拆解Agent的本质、ReAct运行模式，以及如何用一段系统提示词加少量代码，从零搭出一个可用的Agent。

Agent是什么：给大模型装上感官和手脚

大模型（如千问、DeepSeek^广告）在回答问题、生成文本方面表现很强，但它无法感知或改变外部环境。UP主举了一个直观的例子：让千问写一个打飞机游戏的代码，它会生成对应代码，但把代码写入文件这件事仍然需要你手动完成。反过来，如果你想在已有代码基础上增加功能，也必须先手动把代码复制给模型，否则它根本看不到。

解决思路很朴素：给大模型安装工具。读写文件是工具，查看文件列表是工具，运行终端命令也是工具。工具相当于大模型的“感官和视知”，有了它，模型就能自己查询已有文件、写入代码、运行程序，全程无需人工插手。把大模型和一堆工具组装起来，变成一个能感知和改变外部环境的智能程序，这就是Agent。

Agent的类型多种多样。编程类Agent（如Cursor）是最常见的一类，此外还有做PPT的、做深度搜索的。它们的共同点是：背后都是“大模型+工具”的组合，只是工具集和擅长的领域不同。UP主现场演示了Cursor执行一个简单游戏开发任务的全过程——项目结构创建、目录创建、文件生成全部自动完成，用户最多只需要点击确认按钮，最后直接运行index文件即可看到游戏效果。

这里有一个容易被忽略的认知：大模型无法感知外部环境，并不是模型的“缺陷”需要被修复，而是它的运行边界。Agent的价值在于用工程手段把边界向外推，让模型从“回答问题”走向“完成任务”。

ReAct模式：思考、行动、观察的循环

理解Agent是什么之后，下一个问题是它如何运转。目前使用最广泛的运行模式是ReAct，全称Reasoning and Acting，即思考与行动。据UP主介绍，这一模式最初由2022年10月的一篇论文提出，距今接近三年，但仍然是学习Agent实现原理绕不开的内容。

ReAct的流程可以概括为四步循环：

1. Thought（思考）：Agent先分析用户问题，决定是否需要调用工具；
2. Action（行动）：如果需要，调用合适的工具，比如读取文件、写入文件；
3. Observation（观察）：查看工具的执行结果，比如文件内容是否读取成功、写入是否完成；
4. 循环或结束：根据观察结果继续思考，判断是否需要再次调用工具。直到模型认为信息足够，直接输出Final Answer（最终答案），流程结束。

UP主特别强调记住“Thought、Action、Observation、Final Answer”这几个词，因为后面构建Agent时，整个代码逻辑就是围绕这四个步骤展开的。

这里要澄清一个常见误解：模型在拿到问题后会先思考再行动，并不是因为它被专门这样训练过。训练关系不大，奥秘主要在系统提示词上。系统提示词与用户问题一起发送给模型，规定了模型的角色、运行规则和环境信息。比如规定回答必须包含两个XML标签，一个存放用户问题，一个存放回答，模型就会遵守这个规范。想让模型按ReAct模式返回，系统提示词就要写得更复杂：描述职责、给出Thought/Action/Observation的格式、列举可用工具、说明注意事项。

ReAct论文的全称是《ReAct: Synergizing Reasoning and Acting in Language Models》，由Shunyu Yao等人于2022年10月发表，最初在ICLR 2023上亮相。论文的核心洞察是：大模型单独做推理（如思维链CoT）时容易产生事实幻觉，因为推理过程完全基于模型内部知识；而单独做行动时又缺乏对全局目标的规划。ReAct将两者交织，让模型在每一步推理后立即通过与外部环境交互获得反馈，用真实观察结果校正下一步推理。论文在HotpotQA多跳问答和ALFWorld、WebShop等交互式决策任务上验证了该模式的有效性，随后成为LangChain、AutoGPT等Agent框架的默认范式。理解这篇论文的出发点，有助于把握为什么ReAct的循环中“观察”环节不可省略——它正是对抗模型幻觉的工程手段。

系统提示词（System Prompt）是与用户消息（User Message）在对话API中分离传入的一段特殊指令，通常位于消息列表的最前面，在OpenAI的Chat Completions接口中对应role为“system”的消息。它不同于用户提问，具有更高的优先级和全局约束力，模型在生成回复时会被训练为优先遵循系统提示词的设定。系统提示词通常包含角色定义、任务边界、输出格式规范、可用工具说明和安全约束。在Agent场景中，它是“编程”模型行为的轻量手段——不改模型权重，仅通过提示词即可让同一个模型表现出完全不同的行为模式，这正是文中“让模型演Agent”得以成立的技术基础。需要注意的是，系统提示词并非绝对可靠，模型在长对话中可能出现指令遗忘，这也是Agent工程中需要额外校验输出格式的原因。

实战演示：用系统提示词让模型“演”出Agent

UP主用千问做了一次模拟演示：把包含职责描述、格式要求、工具列表的系统提示词复制给模型，再通过task标签提交需求。模型的回答立刻变了——先输出Thought，再输出Action。由于是模拟环境，工具并没有真正执行，UP主手动把“写入成功”的结果发回给模型，模型便继续下一步思考，创建HTML文件、CSS文件、JS文件，每一步都等待观察结果，最后输出Final Answer。

这个演示说明：仅靠系统提示词，就能让模型表现出ReAct的完整行为模式。但模拟终究不是真正的Agent，因为工具调用是人工代劳的。要让Agent真正可用，还需要配套代码来实际执行工具、把执行结果自动回填给模型。

UP主随后演示了自己写好的ReAct Agent项目。项目结构包括虚拟环境、agent代码、存储目标文件的目录、main.py以及提示词模板。运行方式是通过uv run启动agent，并指定文件写入的目标目录。提交“写一个打飞机游戏”的任务后，Agent真实地写入文件，每一步都返回真实的执行结果，最终输出Final Answer，三个文件（index、CSS、JS）确实出现在项目路径下。

代码拆解：一个while循环撑起整个Agent

核心代码在ReactAgent类中。初始化部分接收工具列表、模型、项目路径，并通过OpenAI接口调用大模型。run方法接收用户输入，先构造message列表，包含渲染后的系统提示词和用户问题，然后进入while循环。

循环内做几件事：调用模型；用正则表达式检测返回内容属于Thought、Action还是Final Answer；如果检测到Final Answer，直接return结束循环；否则提取Action中要调用的工具并执行，把执行结果追加到message列表，回到循环顶部继续请求模型。UP主把这一流程画成流程图，涉及用户、Agent主程序、模型、工具四个角色。主程序负责串联：调用模型拿到思考和行动指令，展示给用户，调用工具拿到观察结果，回填历史消息，重复直到模型输出Final Answer。

这个设计的关键在于历史消息的累积。每次工具执行结果都append到message列表，下一轮请求模型时，模型就能看到此前所有思考和观察记录，从而决定下一步。整个Agent的“智能”，很大程度上来自这个朴素的消息回填机制。

Agent通过OpenAI兼容接口调用大模型，本质是向/v1/chat/completions端点发送HTTP请求，请求体包含model、messages、temperature等参数，响应中返回模型生成的内容。文中提到的千问、DeepSeek等国产模型大多提供了OpenAI兼容的API，因此同一套Agent代码只需替换base_url和api_key即可切换模型。messages列表是对话状态的核心载体，每次请求都携带完整的历史消息（包括system、user、assistant、tool等角色），模型据此理解上下文。工具执行结果通常以特定角色的消息追加，OpenAI的function calling机制使用role为“tool”的消息并附带tool_call_id，而文中采用的正则解析XML标签方式则更简单直接，把观察结果作为普通文本消息append即可。理解这一接口约定，就能明白为什么“历史消息累积”能让Agent表现出连贯的多步决策能力。

写在最后：Agent的门槛在工程，不在模型

回顾整个课程，Agent的构成可以浓缩为一句话：大模型提供推理能力，工具提供行动能力，系统提示词规定协作格式，主程序的循环把三者串起来。ReAct模式之所以成为主流，是因为它把“思考—行动—观察”的循环显式化，让模型的行为可追踪、可干预、可调试。

对想上手的人来说，这条路径的起点并不高：先写一段系统提示词让模型“演”出ReAct格式，理解每一步的输出；再补上工具函数和循环逻辑，让模拟变成真实执行。UP主在视频中提供了完整代码，并提到可以在评论区留言领取。比起追逐新的模型和框架，把ReAct这个基础模式吃透，可能是更稳妥的入门方式。