---

视频信息

• 标题：Agent 的概念、原理与构建模式 —— 从零打造一个简化版的 Claude Code
• 作者：马克的技术工作坊
• 链接：https://youtu.be/GE0pFiFJTKo?si=RyLyOEHpO6KOKmcj

---

开篇引入

在当今大模型浪潮汹涌而来的时代，一个名为“Agent”（或称AI Agent）的关键概念正迅速崛起，成为技术社区的热门焦点。然而，尽管Agent一词被频繁提及，其本质、运作机制以及如何构建却常常让许多人感到困惑。本视频旨在彻底厘清Agent的这些核心问题，带你从零开始，构建一个简化版的Agent，帮助你深刻理解这一前沿技术，并感受到它如何将大模型的潜力提升到一个全新的维度。如果你曾好奇大模型如何突破感知和改变外部世界的限制，那么这篇深度解析将为你揭示Agent的奥秘，让你对AI的未来发展拥有更清晰的认知。

---

详细内容

Agent 的诞生：突破大模型的边界

核心观点
Agent（AI Agent）是大模型热潮兴起的重要概念，它通过集成外部工具，赋予大模型感知和改变外界环境的能力，从而克服了传统大模型的固有局限性。

深度阐述
视频开篇便直指当前大模型的显著优势与核心限制。像GPT-4或DeepSeek这样的大模型，在回答问题和逻辑推理方面表现卓越。然而，它们在实际应用中存在一个根本性制约：无法感知或改变外部环境。作者通过生动的例子阐明了这一点：

• 无法改变外界环境：当你想让GPT-4O帮你写一个贪吃蛇游戏时，它能提供代码，但将代码写入文件这样的操作，仍需用户手动完成。这意味着大模型自身不具备执行物理世界或数字世界操作的能力。
• 无法感知外界环境：如果你已经有一些贪吃蛇的代码，并希望模型在此基础上进行修改或添加功能，你必须主动将现有代码复制给GPT-4O。如果用户不提供，大模型无法自行查找这些代码，这体现了其缺乏对外部环境的感知能力。

为了解决大模型无法感知或改变外部环境的问题，解决方案便是为它们“接上”相应的工具。这些工具可以是：

• 读取文件内容的工具
• 查看文件列表的工具
• 运行终端命令的工具

作者形象地将这些工具比喻为大模型的**“感官和四肢”**。一旦大模型拥有了这些“感官和四肢”，它就能自行查询已有文件、自行写入代码、自行运行程序，整个过程无需用户插手，完全自动化。

Agent 的定义：像这样，把一个大模型和一堆工具组装起来，变成一个能感知和改变外界环境的智能程序，我们就称它为Agent。作者特别提到，Agent通常用一个机器人的图标来表示，这与大模型的“大脑”图标形成了鲜明对比，因为Agent具备了感官和四肢，能够独立行动，就像一个机器人一样。

Agent的类型多种多样，擅长的领域也各不相同。视频中举例说明了几种常见的Agent类型：

• 编程类Agent：例如Cursor。用户只需提交任务，Cursor便会利用大模型和各种工具来编写代码，直至任务完成。整个过程中，用户可能只需要点击确认按钮，其余大部分操作都由Agent自动完成。
• 深度搜索/信息整理类Agent：例如前一阵子比较火的MUS。用户希望比较几款手机的性能和拍照能力，MUS会生成执行计划，搜索并浏览相关网页，最终将报告整理成页面展示给用户，整个过程也基本不需要用户介入。MUS利用大模型和工具解决了用户的问题。

通过这些例子，作者让观众对Agent有了一个大致的了解，强调了其在自动化任务、感知和改变环境方面的强大能力。

视觉信息描述：虽然没有具体图表，但作者在描述Agent时，清晰地对比了大模型的“大脑”图标与Agent的“机器人”图标，这本身就是一种强烈的视觉联想，强调了Agent具备行动能力。

精华收获
Agent的核心价值在于赋予大模型**“行动力”和“感知力”**，使其能够自主地与外部世界交互，自动化完成复杂任务，极大地扩展了大模型的应用边界。

React 模式：思考与行动的循环核心

核心观点
React是目前Agent最广泛使用的运行模式，其核心在于“思考（Thought）-行动（Action）-观察（Observation）”的循环，并通过一个“系统提示词”来指导大模型严格遵循这一流程。

深度阐述
视频接下来深入探讨了Agent的运行模式，其中最著名和最广泛使用的便是React模式。

• 全称与起源：React是“Reasoning and Acting”的缩写，意为“思考与行动”。它最初由一篇2022年10月的论文提出，尽管时间已近三年，其运行模式至今仍被广泛采用。
• 核心运行流程：React模式的流程可以概括为一系列的循环：
  1. 用户提交任务。
  2. Agent思考 (Thought)：Agent首先进行思考，决定是否需要调用工具。
  3. 行动 (Action)：如果需要，Agent会调用合适的工具，如读取文件、写入文件内容等。
  4. 观察 (Observation)：在行动之后，Agent会查看工具的执行结果，例如所读取的文件内容或写入是否成功。
  5. 继续循环或给出最终答案：在观察之后，Agent会继续思考，再次判断是否需要调用工具。如果仍然需要，它会重复“行动-观察-思考”的流程，直到某个时刻，它认为不再需要调用工具，可以直接给出结论时，便输出最终答案 (Final Answer)。整个流程随之结束.

作者强调，整个React流程的核心就是thought（思考）、action（行动）、observation（观察）和final answer（最终答案）这几个关键词。

实现奥秘：系统提示词
那么，这种React模式是如何实现的呢？为什么大模型在拿到用户问题后会先思考再行动，而不是直接行动？这并非因为模型被这样训练，而大部分奥秘都集中在**系统提示词（System Prompt）**上。

• 系统提示词的作用：系统提示词是与用户问题一起发送给模型的提示词。它规定了模型的角色、运行时要遵守的规则，以及各种环境信息等。
• 引导模型行为：作者举例说明，如果在系统提示词中写入“你的回答必须包含两个XML标签，一个叫做question用于存放用户的问题，一个叫做answer用于存放你的回答”，那么大模型便会遵循这种规范来输出答案。

为了让模型按照React模式返回答案，系统提示词会更加复杂。视频中详细展示了一个具体的系统提示词例子，它大致包含五个部分：

1. 职责描述：明确告诉模型其任务是解决问题，需将任务分解为多步，每一步都先“思考（thought）”要做什么，然后“行动（action）”调用工具，工具的执行结果会通过“观察（observation）”返回。持续这个思考和行动的过程，直到有足够信息提供“最终答案（final answer）”。这一段话正是对React执行流程的描述，旨在让大模型按照React标准运行。
2. 示例：提供了具体的问答示例，展示了典型的React流程。例如，用户问“F贴有多高”，模型先用thought标签思考，然后用action调用工具（传入参数“F贴”），工具结果通过observation返回。模型收到结果后再思考，最后给出final answer。还展示了调用多次工具的例子。
3. 可用工具：列举了模型可以调用的工具，如读取文件内容、写入文件内容和运行终端命令等实用功能。
4. 注意事项：提供了一些额外的说明和约束。
5. 环境信息：告知大模型相关的环境信息，如当前操作系统、目录和目录下的文件列表等。

视觉信息描述：作者在讲解React流程时，提及“流程图”，表明此部分内容通常伴随流程图的视觉辅助，清晰展示了Thought、Action、Observation的循环关系。讲解系统提示词时，也暗示了屏幕上会显示具体的提示词文本内容及其五个组成部分。

精华收获
理解React模式的关键在于其迭代循环的决策过程，而实现这一过程的“魔法”则隐藏在精心设计的系统提示词中，它如同剧本般指导大模型每一步的思考和行动。

React 模式的实战演示与代码解析

核心观点
通过DeepSeek模拟和实际Agent代码运行，视频演示了React模式如何驱动Agent逐步完成复杂任务，并揭示了其核心逻辑在于Agent主程序对模型请求、工具调用及结果处理的循环协调。

深度阐述
视频通过两个层面的演示，进一步深化了对React模式的理解：

1. DeepSeek上的模拟演示

作者首先在DeepSeek上模拟了React模式的运行过程。

• 操作步骤：将前面构建的系统提示词复制并粘贴，作为用户输入的一部分，然后加上具体任务：“写一个贪吃蛇游戏，使用HTML、CSS和JS实现，代码分别放在不同的文件中”。作者提到，虽然规范做法是系统提示词和用户任务分开传递，但DeepSeek不提供单独提交系统提示词的地方，所以将二者合并提交，这在大多数情况下也能正常运行。
• 模拟过程与模型行为：
  1. 提交任务后，DeepSeek开始运行。它按照要求，先在thought标签中思考。
  2. 接着，它使用action标签，请求调用write_to_file工具来写入index.html文件，并附上具体的HTML内容。作者特别强调，大模型此处是“请求”调用工具，而非直接调用，实际调用工具的是Agent的工具调用组件。
  3. 在模拟环境中，作者假设工具调用完成并成功写入，于是回复observation“写入成功”。
  4. DeepSeek收到结果后继续运行，再次**thought，然后action请求写入CSS文件**。再次回复observation“写入成功”。
  5. 类似地，再次thought，action请求写入JS文件。再次回复observation“写入成功”。
  6. 当三个文件都显示完成，不再需要调用工具时，DeepSeek在thought之后直接返回了final answer。

这个模拟过程生动地展示了React模式的节奏：thoughts -> action -> observation -> thoughts -> action -> observation…一直到任务完成，最终输出thoughts和final answer。系统提示词就像给模型安排了一个“迷你剧本”，它会严格按照这个剧本一步步地走完。

视觉信息描述：此部分详细描述了DeepSeek的界面操作和模型返回的文本结构，包括thought、action、observation和final answer等XML标签的出现顺序及内容，使得读者能够清晰地想象出模拟时的屏幕交互过程。

2. 真实React Agent的构建与运行

视频随后进入了更令人兴奋的部分：演示一个真正可用的React Agent。

• 构建基础：作者提到，在系统提示词的基础上，加上一些配套代码，就能搭建出一个真实可用的React Agent。他已经将代码放在了GitHub仓库中。
• 项目结构：演示前，作者展示了项目目录，其中主要关注两个文件：agent.py（Agent代码）和snake目录（空目录，用于存放Agent生成的代码）。
• Agent运行：
  1. 通过命令python agent.py snake启动Agent，snake作为参数告诉Agent要在该目录下操作。
  2. Agent首先询问要完成的任务，用户输入：“写一个贪吃蛇游戏，使用HTML、CSS和JS实现，代码分别放在不同的文件中”。
  3. Agent开始运行并请求大模型（作者此处采用了同步返回机制，需等待模型生成所有内容）。
  4. 第一轮结果：返回thought、action、observation。这里的action是请求调用write_to_file工具写入index.html文件。最重要的区别在于，这里的observation显示“写入成功”是真实的工具执行结果，而非模拟！ Agent内部真的调用了工具函数并获得了真实返回。
  5. 后续流程：后续流程类似，在observation之后，Agent再次请求模型，然后又进入thought、action、observation循环，分别写入CSS和JS文件。
  6. 任务完成：所有文件写入完毕后，Agent给出thoughts和final answer，整个流程结束。
• 验证结果：作者展示了snake目录下确实生成了三个文件，并执行index.html验证贪吃蛇游戏功能，游戏界面、移动和吃方块功能均正常，分数也正确显示。这证明了Agent的成功运行，完全可以作为简化版的Claude Code使用。

视觉信息描述：此部分描述了命令行操作（ls、python agent.py），Agent运行时的输出（包含thought、action、observation循环），以及最终通过浏览器展示的贪吃蛇游戏界面和其可玩性，提供了从代码到实际成果的完整视觉链条。

3. Agent核心代码解析

视频进一步深入到agent.py的核心代码。

• 入口点：
  • project_directory：命令行传入的参数，如snake目录。
  • tools：一个列表，包含了可用的工具函数，如读取文件、写入文件、运行终端命令等。作者特别强调，工具本质上就是函数。
• ReactAgent类：
  • Agent的核心，构造时需要提供三个参数：工具列表、要使用的模型（例如GPT-4O）、项目目录。
  • 通过构造函数获得一个Agent变量后，程序会提示用户输入任务内容，然后将任务传入agent.run函数。
• run函数（ReactAgent的核心）：
  • 接受用户输入的任务作为参数。
  • 内部构建了一个message列表，包含系统提示词和用户问题。
  • 系统提示词由render_system_prompt函数渲染生成，它接受一个系统提示词模板，该模板内容与前面讲的基本一致，但包含一些占位符（如工具列表、操作系统、当前目录下的文件列表等），这些占位符在运行时会被填入具体信息。
  • 拼接好message列表后，使用call_model函数调用模型，获取模型的执行结果。
  • 循环逻辑：在一个while循环中处理整个React流程。
    • 提取thought：从模型返回结果中提取thought部分并打印。
    • 检测final answer：如果thought之后的内容是final answer，则返回final answer，函数执行结束。
    • 提取并执行action：如果不是final answer，则模型返回中一定包含action。代码会解析action，提取其中的函数名和参数列表。
    • 安全提示：如果当前工具是运行终端命令的工具，会提示用户是否继续，因为运行终端命令存在风险，编程Agent通常会在执行前询问用户。
    • 执行工具：如果没有安全问题，便会执行action中指定的工具函数，并将执行结果放入observation中。
    • 更新message列表：将observation添加到message列表中，因为处于while循环中，下一步会再次请求模型。这样，模型就可以拿到工具的执行结果，并根据结果推测下一步要做什么。
  • 这个while循环总结起来就是：请求模型 -> 提取思考 -> 检测最终答案 -> 提取并执行工具。这个过程会一直重复，直到模型返回final answer为止。

Agent的整体架构：作者通过一个流程图（虽然视频中是可视化展示，但文字描述清晰地呈现了其逻辑）总结了React Agent的问答流程。整个流程图中有两个主要角色：用户和Agent。Agent又可细分为三个部分：模型、工具（函数）和Agent主程序。

• Agent主程序：负责串联整个流程的逻辑代码，在合适的时候调用工具或模型（大体对应run函数）。
• 沟通流程：
  1. 用户提交任务给Agent主程序。
  2. Agent主程序调用模型。
  3. 模型返回thought和action。
  4. Agent主程序打印thought和action给用户看。
  5. Agent主程序调用action中指定的工具。
  6. 工具执行完毕后返回结果。
  7. Agent主程序将结果发给用户看。
  8. Agent主程序将工具执行结果加入到历史消息列表。
  9. 再次重复请求模型并处理thought、action和observation的逻辑。
  10. 直到某个时刻，模型认为用户任务已完成，不再需要调用工具，便返回thought和final answer。
  11. Agent主程序展示thought和final answer给用户，流程结束。

视觉信息描述：代码解析部分暗示了会展示agent.py的具体代码片段，包括类定义、构造函数、run函数内部的while循环、message列表构建、render_system_prompt的模板内容，以及call_model和工具执行的逻辑。作者还提到了画流程图来帮助理解，说明了用户、Agent主程序、模型和工具之间的交互路径。

个人感受
作者在代码解析时，通过强调write_to_file工具的真实执行，表达了Agent真正“动起来”的兴奋感，并自豪地展示了最终贪吃蛇游戏的成功运行，认为这个Agent可以作为一个简化版的Claude Code。他这种从理论到实践，最终看到成果的喜悦是显而易见的。

精华收获
React模式的强大之处在于其**“系统提示词”驱动的循环决策机制**，它将大模型、工具和Agent主程序无缝结合，实现自动化的问题解决。关键在于将每次工具的执行结果作为新的“观察”反馈给模型，让模型能够基于最新信息进行迭代决策，直至任务完成。

Plan and Execute 模式：动态规划与执行

核心观点
Plan and Execute模式是另一种重要的Agent运行模式，它通过“规划-执行-再规划”的循环，引入动态修改计划的环节，使其在处理复杂多步骤任务时更具鲁棒性和灵活性。

深度阐述
React模式虽然常见且广泛使用，但它并非Agent构建的唯一方案。视频随后介绍了另一种重要的Agent运行模式：Plan and Execute（规划与执行）。

• 核心理念：许多Agent的运行过程遵循“先规划再执行”的模式。例如，之前演示过的MUS，它在开始回答时会构建一个代办列表，后续的执行都遵循这个列表。Claude Code中也常出现先创建待办事项再执行的情况。
• LangChain的实现：这种“先规划再执行”的模式没有统一的名字，且每个Agent的实现可能有所差异。视频重点讲解了LangChain提出的Plan and Execute模式。从总体上看，它也遵循先规划再执行的流程，但其独特之处在于引入了一些动态修改规划的环节。

Plan and Execute Agent的组成模块
为了理解其运行流程，作者首先清晰地拆解了Plan and Execute Agent的组成部分。它包含以下几个核心角色：

1. Plan模型：负责执行（生成）计划的模型。
2. Replan模型：负责根据每一步的执行结果动态调整计划的模型。Plan和Replan模型可以是同一个，也可以是两个不同的模型。
3. 执行Agent：负责执行计划中每一步的Agent。值得注意的是，这个Plan and Execute Agent内部还包含了一个Agent（Agent套Agent的设计方案是比较常见的）。执行Agent可以使用前面讲的React模式来运行，它内部可以集成网络搜索工具等。Plan and Execute模式只要求执行Agent能完成指定步骤，不关心其具体运行模式或内置工具。
4. Agent主程序：负责串联整个流程。

Plan and Execute模式的运行流程
作者通过一个具体的例子（查询当年澳网男单冠军的家乡）来模拟其运行流程。

• 起始：
  1. 用户将问题（“今年澳男子的冠军的家乡是哪里？”）提交给Agent主程序。
  2. Agent主程序将问题发给Plan模型，让它给出具体的执行步骤。
  3. Plan模型返回一个合理的执行计划，例如：
     • 查询当前日期。
     • 查询当前年份下的澳男单冠军名字（如2025年或2024年的冠军）。
     • 根据冠军名字查询其家乡。
• 循环执行：计划生成后，Agent主程序会将计划传递给执行Agent，让它执行计划中的第一步（如“查询当前日期”）。
  • 执行Agent内部进行操作（例如通过网络搜索工具）后，吐出一个执行结果并返回给Agent主程序。
  • 动态再规划：Agent主程序会将用户问题、当前执行计划和历史执行记录都发给Replan模型。
  • Replan模型根据新的信息生成一个新的执行计划。因为拿到了第一步的执行结果，情况可能发生变化，修改原计划是正常的。
  • Agent主程序接到新的执行计划后，会回头重复这个“执行-再规划”的循环过程。

三轮模拟详解：
作者为了让观众彻底理解，详细模拟了三轮循环：

• 第一轮：
  • 执行阶段：Agent主程序将执行计划发给执行Agent，处理第一步（查询当前日期）。执行Agent返回结果。
  • Replan阶段：Agent主程序将用户问题、第一个执行计划和历史执行记录发给Replan模型，让它给出第二个执行计划。
  • 计划变化：第二个执行计划与第一个有两点不同：
    1. “查询当前日期”这一步不再出现，因为它已执行完毕。
    2. “查询澳男单冠军名字”这一步变得更精确，例如从“查询对应日期的澳男单冠军名字”变为“查询2025年的澳男单冠军名字”，因为日期已查出，可以直接将具体年份放入计划中。
• 第二轮：
  • Agent主程序取出最新的执行计划，发给执行Agent执行其中第一步。
  • 拿到执行结果后，加入历史执行记录。
  • Replan阶段，将用户问题、执行计划和历史执行记录发给Replan模型，拿到第三个执行计划。
• 第三轮：
  • Agent主程序取出执行计划，让执行Agent处理最后一步。
  • 拿到执行结果后，加入历史执行记录。
  • 关键变化：Replan阶段，将所有信息发给Replan模型。此时，Replan模型会发现所有步骤都已完成，用户问题可以回答了。因此，Replan模型返回的不再是新的执行计划，而是最终的答案。
  • Agent主程序接到最终答案后，转发给用户，整个流程结束。

Replan模型的两种返回可能性：作者强调，Replan模型有两种可能的返回：

1. 新的执行计划：如果还有未执行的步骤。
2. 最终答案：如果所有步骤都已完成，用户的问题已可回答。

作者指出，LangChain官方提供了Plan and Execute的具体实现代码，可在其页面获取。

视觉信息描述：此部分通过描述“时序图”来辅助讲解Plan and Execute模式的运行流程，清晰地展示了用户、Agent主程序、Plan模型、Replan模型和执行Agent之间的消息传递和角色转换。尤其是在模拟三轮循环时，对计划内容的变化和Replan模型返回结果的描述，帮助读者在脑海中构建出动态的执行过程。

个人感受
在讲解Plan and Execute模式时，作者的语速会稍微快一些，但他提前打预防针，并细致地拆解每一轮的执行和再规划过程，力求让复杂概念变得易于理解，体现了其教学的热情和严谨。

延伸思考
Plan and Execute模式通过引入Replan环节，使得Agent在面对不确定性或复杂多变的任务时，能展现出更强的适应性和鲁棒性。它不像React模式那样严格地循环“思考-行动-观察”，而是允许在每个步骤执行后重新评估和调整整体策略，这对于需要长期规划和动态调整的任务（例如项目管理、复杂科研模拟）具有重要意义。这种“Agent套Agent”的设计也揭示了构建复杂AI系统的一种模块化、分层化的思路。

精华收获
Plan and Execute模式的精髓在于其**“动态再规划”能力**，即在每一步执行之后，Agent都能基于最新的信息重新评估和调整整个任务计划。这使得Agent能够处理更复杂、更不确定的任务，并在执行过程中进行自我修正，最终给出准确的答案，代表了Agent设计在鲁棒性和智能化程度上的进一步飞跃。

---