从零构建ReAct智能体：基于TypeScript的LLM应用开发实践

1. 项目概述与核心思路最近在折腾大语言模型应用发现很多框架要么太重要么封装得太深想改点东西都无从下手。特别是ReAct这种经典的“思考-行动”模式虽然原理清晰但真想自己从头实现一遍把每个环节都摸透还真得花点功夫。于是就有了这个项目OceanPresentChao/llm-ReAct。它的目标很纯粹就是抛开所有复杂的依赖和抽象用最直白的TypeScript代码从零开始搭建一个可运行、可理解、可扩展的ReAct Agent框架。这个框架的核心是模拟一个智能体的决策循环。想象一下你让一个助手去查“北京今天的天气然后根据天气推荐是否适合户外跑步”。一个简单的指令背后其实包含了好几步首先它得“想”明白要做什么规划任务查天气然后它得“动手”去查使用工具调用天气API拿到结果后它再“思考”这个结果意味着什么分析温度、降水最后它结合最初的指令“给出建议”生成最终答案。ReAct框架就是把“推理Reasoning”和“行动Acting”这两个步骤交织在一起让大模型像人一样通过一步步的思考和外部的工具交互来解决复杂问题。我选择用TypeScript来实现一方面是因为它在构建严谨的应用结构上有天然优势类型系统能帮我们提前规避很多低级错误另一方面Node.js环境部署和运行都极其方便不需要复杂的Python环境配置。整个项目不依赖任何重量级的AI框架只通过最基础的OpenAI API调用把重点完全放在ReAct流程本身的实现和拆解上。无论你是想学习Agent的工作原理还是想以此为基础快速构建自己的智能体应用这个“麻雀虽小五脏俱全”的项目都能提供一个非常扎实的起点。接下来我就带你深入代码看看这个循环是怎么转起来的。2. 核心架构与组件拆解2.1 ReAct循环大脑与手脚的协奏曲要理解这个项目首先得吃透ReAct的核心循环。它不是一个单向流水线而是一个动态的、有状态的循环过程。我们可以把它分解为以下几个核心阶段这就像给一个智能体装上了“大脑”和“手脚”观察与思考Observe Think这是循环的起点。智能体接收到用户的初始问题或上一轮行动的结果结合自己已有的“记忆”对话历史或上下文开始进行推理。在这个阶段大模型的任务是分析当前状况并规划出下一步应该做什么。它的输出不是最终答案而是一个结构化的“想法”通常包含两个部分一个是对当前步骤的推理过程Reasoning另一个是决定要执行的具体行动Action比如调用哪个工具、传入什么参数。行动与执行Act根据上一步思考得出的行动指令智能体需要调用对应的“工具”Tool来执行。工具可以是查询数据库、调用外部API、进行计算等等这是智能体与外部世界交互的唯一方式。执行完成后工具会返回一个观察结果Observation这个结果可能是成功的数据也可能是错误信息。结果整合与循环判断Integrate Loop将工具返回的观察结果连同之前的整个思考-行动历史一起作为新的输入喂回给大模型开启下一轮的“观察与思考”。智能体会评估这个结果问题解决了吗如果没解决是哪里出了错需要换一种方法还是补充信息这个循环会一直持续直到大模型在“思考”步骤中认为已经收集到足够的信息可以直接给出最终答案Final Answer而不是再提出一个行动指令。这时循环终止。这个循环的精妙之处在于它将大模型强大的推理能力但缺乏实时信息和执行能力与外部工具精准的执行能力但缺乏复杂规划能力完美地结合了起来。我们的框架就是为这个循环搭建一个稳定、可靠的运行环境。2.2 项目结构五脏俱全的微型系统打开项目仓库你会看到一个非常清晰和简洁的目录结构。这反映了我“模块化、职责单一”的设计思想每个文件都像乐高积木一样有明确的功能方便你理解和修改。llm-ReAct/ ├── src/ │ ├── agent.ts // 智能体核心管理与大模型的对话和思维生成 │ ├── executor.ts // 执行引擎驱动整个ReAct循环运转 │ ├── llm.ts // 模型接口封装与OpenAI API的通信 │ ├── prompt.ts // 提示词工程精心设计引导模型思考的模板 │ ├── tool.ts // 工具抽象定义所有工具必须遵守的契约 │ └── toolkit.ts // 工具集几个现成的、可用的工具实现 ├── config.json // 配置文件集中管理API密钥和模型参数 └── doc/ // 文档目录agent.ts(智能体)这是框架的“大脑”接口。它不关心循环怎么跑只负责一件事根据当前的对话历史和上下文调用大模型生成下一步的“思考”文本。它接收结构化的历史信息输出纯文本的模型响应。这个响应里就包含了我们期待的“推理”和“行动”指令。executor.ts(执行器)这是框架的“心脏”和“调度中心”。它持有Agent和一系列Tool并运行一个while循环严格遵循ReAct的步骤。它的职责包括启动循环、调用Agent进行思考、解析Agent的输出、调用对应的Tool、收集工具结果、判断循环是否应该结束。整个项目的流程控制逻辑基本都集中在这里。llm.ts(大模型客户端)这是一个轻量级的封装层。它隐藏了直接调用OpenAI API的细节比如HTTP请求、错误处理向上提供一个简单的异步函数如generate(prompt: string): Promisestring。如果你想换用其他模型提供商如Azure OpenAI、 Anthropic Claude基本上只需要修改这个文件。prompt.ts(提示词模板)这是引导大模型正确进行ReAct思考的“剧本”。它定义了输入给模型的文本格式通常包含系统指令扮演什么角色、工具描述你能用什么工具、怎么用、对话历史、以及当前需要思考的问题。一个设计良好的提示词是ReAct成功运行的关键。tool.ts(工具抽象类)这是所有工具的“蓝图”。它用一个抽象的Tool类定义了任何工具都必须有的属性如name、description和方法call。这保证了Executor可以用统一的方式调用任何工具。toolkit.ts(工具实现)这里提供了几个具体的工具例子比如计算器、搜索工具模拟、获取当前时间的工具等。它们都继承自Tool类实现了具体的call方法。你可以在这里轻松添加你自己的工具比如调用公司内部API、查询数据库等。config.json(配置)将敏感信息如OpenAI API Key和可变参数如模型名称gpt-3.5-turbo集中管理避免硬编码在代码中提高了安全性和可配置性。提示这种清晰的分层结构最大的好处是“可插拔”。例如你想把思考模型从GPT-3.5换成GPT-4只需在config.json里改个配置。你想加一个新工具只需在toolkit.ts里写一个新类并在创建Executor时传入即可。这种设计让项目的扩展和维护变得非常轻松。3. 关键代码实现深度解析3.1 提示词工程如何让模型学会“思考-行动”prompt.ts是整个项目的灵魂所在。大模型本身并不知道ReAct流程我们需要通过精心设计的提示词来“教”它。这个模板通常是一个多部分的字符串我们来看一个简化但核心的版本// 这是一个简化的示例实际项目中的模板会更复杂包含更详细的工具描述和格式要求。 export const REACT_PROMPT_TEMPLATE 你是一个善于思考并借助工具解决问题的助手。 你可以使用以下工具 {toolsDescription} 你必须严格按照以下格式回应 Thought: 这里是你对当前情况的分析和下一步该做什么的思考。 Action: 需要调用的工具名称必须是以下之一[{toolNames}] Action Input: 调用该工具时需要的输入参数一个字符串。 或者当你认为已经得到最终答案时请使用 Thought: 我认为我已经得到了所有必要信息。 Final Answer: 这里是你给用户的最终答案。 现在开始 之前的对话历史 {history} 当前问题或观察{input} 你的回应 ;我们来拆解这个模板的每个部分及其作用角色与指令你是一个善于思考并借助工具解决问题的助手。这行系统指令设定了模型的“人设”让它进入一个协作式的问题解决模式。工具库说明{toolsDescription}是一个占位符在实际运行时会被替换成所有可用工具的详细描述包括每个工具的名字、功能说明、以及输入参数的格式。这是模型知道“自己能做什么”的唯一途径描述必须清晰、无歧义。强制输出格式这是最关键的部分。我们明确要求模型必须按照“Thought: ... Action: ... Action Input: ...”或者“Thought: ... Final Answer: ...”的格式来回应。这种结构化约束极大地提高了模型输出结果的可解析性。如果没有这个约束模型可能会用自然语言自由发挥比如“我觉得我应该先查一下天气工具用‘get_weather’城市是北京”这对于程序来说就很难精准地提取出工具名和参数。历史与当前输入{history}和{input}是动态注入的上下文。history包含了之前所有轮次的 Thought-Action-Observation 记录让模型拥有“短期记忆”。input在第一次循环时是用户的问题在后续循环中则是上一次工具执行的Observation结果。实操心得提示词调试是关键在实际开发中这个提示词模板需要反复调试。常见的坑包括工具描述不清模型不理解某个工具是干什么的或者不知道参数该怎么填。解决办法是给工具起一个见名知意的名字并用1-2句话清晰描述其功能和输入格式最好给出例子。格式遵守不严模型偶尔会不按指定格式输出比如漏掉“Action:”前缀。除了在提示词中强调还可以在代码的解析逻辑中加入一定的容错性比如用正则表达式去匹配关键词而不是简单的字符串分割。历史上下文过长ReAct循环可能很长导致提示词token数超限。需要在Executor中实现一个简单的上下文窗口管理比如只保留最近N轮的交互记录。3.2 执行器核心循环状态机的精准运转executor.ts中的run方法是整个框架的驱动引擎。它实现了一个确定性的状态机。让我们通过代码和注释来理解其每一步async run(userInput: string): Promisestring { // 初始化将用户输入作为第一轮“观察” let observation userInput; // 存储完整的交互历史用于构建后续提示词 let history ; // ReAct 主循环 for (let step 0; step this.maxSteps; step) { // 防止无限循环 // 1. 思考阶段调用Agent生成带有Thought/Action的响应 const agentResponse await this.agent.think(history, observation); // 将本次模型的完整响应追加到历史中 history \n${agentResponse}; // 2. 解析响应从文本中提取出结构化的 Thought, Action, Action Input const parsed this.parseResponse(agentResponse); // 3. 判断是否为最终答案 if (parsed.finalAnswer) { // 循环终止返回最终答案 return parsed.finalAnswer; } // 4. 行动阶段根据解析出的Action找到对应的Tool并执行 const tool this.tools.find(t t.name parsed.action); if (!tool) { // 如果工具不存在将错误信息作为新的“观察”进入下一轮循环 observation Error: Tool ${parsed.action} not found.; history \nObservation: ${observation}; continue; } let toolResult: string; try { // 调用工具 toolResult await tool.call(parsed.actionInput); } catch (error) { // 工具执行出错将错误信息作为观察 toolResult Error: ${error.message}; } // 5. 整合观察结果 observation toolResult; // 将观察结果格式化后也加入历史供下一轮思考使用 history \nObservation: ${observation}; } // 如果循环达到最大步数仍未得出最终答案则超时退出 throw new Error(ReAct loop exceeded maximum steps (${this.maxSteps}).); }这个循环清晰地体现了ReAct的每一步第1步this.agent.think(...)封装了构建提示词和调用大模型的过程得到模型的文本响应。第2步this.parseResponse(...)是一个关键的函数它使用正则表达式或简单的字符串分割从agentResponse中提取出Thought、Action、Action Input或Final Answer这几个部分。这个解析器的鲁棒性直接决定了框架的稳定性。第3步检查解析结果中是否有finalAnswer。如果有说明模型认为任务已完成直接跳出循环并返回答案。这是循环的唯一正常出口。第4步根据action字段在注册的工具列表中查找对应的工具实例。找到后用actionInput作为参数调用其call方法。这里进行了基本的错误处理如果工具不存在或调用失败会将错误信息转化为observation让模型在下一轮去“思考”这个错误并可能调整策略。第5步将工具执行的结果或错误格式化为Observation: ...的字符串追加到history中。然后循环回到第1步将最新的observation和完整的history再次交给Agent去思考。注意事项循环终止与防呆设计最大步数限制 (maxSteps)这是一个至关重要的安全阀。大模型有时可能会陷入死循环比如在两个工具间来回调用或者始终无法得出最终答案。设置一个合理的上限如10-20步可以防止程序无限运行消耗大量API费用。解析失败处理parseResponse函数必须考虑模型输出格式不规范的情况。一个健壮的做法是先尝试用严格的正则匹配如果失败则尝试用更宽松的关键词搜索并记录日志。在最坏情况下可以抛出一个清晰的错误或者将解析失败的文本直接作为observation反馈给模型让它“自我纠正”。3.3 工具系统的设计与扩展工具是智能体的“手脚”。tool.ts中定义的抽象类非常简单但构成了强大的契约。abstract class Tool { // 工具的唯一标识符用于在提示词和解析时匹配 abstract name: string; // 工具的功能描述会出现在给模型的提示词中至关重要 abstract description: string; // 工具的执行方法输入是字符串参数输出也是字符串结果 abstract call(input: string): Promisestring; }任何具体的工具比如toolkit.ts里的计算器只需要继承这个类并实现这三个属性/方法即可。// toolkit.ts 示例 import { Tool } from ./tool; export class CalculatorTool extends Tool { name calculator; description Useful for performing arithmetic calculations. Input should be a valid mathematical expression, e.g., \(12 5) * 2\; async call(input: string): Promisestring { try { // 警告在实际生产中直接eval有严重安全风险此处仅为演示。 // 应使用安全的数学表达式解析库如 math.js const result eval(input); return The result is ${result}; } catch (error) { return Error calculating: ${error.message}; } } } export class GetCurrentTimeTool extends Tool { name get_current_time; description Useful for getting the current date and time. Input should be an empty string.; async call(_input: string): Promisestring { return new Date().toLocaleString(); } }如何添加一个自定义工具假设我们需要一个查询用户信息的工具步骤如下在toolkit.ts(或新建一个文件) 中创建一个新类继承Tool。定义清晰的name(如query_user_profile) 和description(如Fetches user profile by user ID. Input should be a user ID string, e.g., \12345\)。在call方法中实现具体的业务逻辑比如调用一个内部HTTP接口或查询数据库。在初始化Executor时将这个新工具类的实例传入工具数组。// 示例一个调用内部API的工具 export class UserProfileTool extends Tool { name query_user_profile; description Fetches user name and email by user ID. Input format: \userId\.; async call(input: string): Promisestring { const userId input.trim(); // 假设调用一个内部REST API const response await fetch(https://internal-api.example.com/users/${userId}); if (!response.ok) { return Error: Failed to fetch user ${userId}, status ${response.status}; } const userData await response.json(); return User ID: ${userData.id}, Name: ${userData.name}, Email: ${userData.email}; } }重要安全警告上面的CalculatorTool为了演示简便使用了eval这在任何生产环境中都是极度危险的因为它会执行输入字符串中的任意JavaScript代码。在实际项目中必须使用像math.js这样的安全库来解析数学表达式。这提醒我们在实现工具时尤其是那些会执行代码或进行系统调用的工具必须对输入进行严格的验证和清理防止注入攻击。4. 从零搭建手把手配置与运行4.1 环境准备与项目初始化首先确保你的开发环境已经就绪。你需要安装Node.js(版本16或以上推荐) 和npm(或 yarn/pnpm)。然后我们可以开始初始化项目。# 1. 克隆项目仓库假设你已Fork或下载 git clone 你的仓库地址 cd llm-ReAct # 2. 安装项目依赖 # 查看package.json核心依赖通常包括 # - openai: 官方Node.js SDK用于调用API # - typescript: 用于类型检查和编译 # - ts-node: 用于直接运行TypeScript文件开发便利 # - dotenv: 用于从.env文件加载环境变量更安全 npm install # 3. 配置OpenAI API密钥 # 方法A使用config.json项目原方式 # 复制提供的config.json.example文件并填入你的真实API Key和选择的模型。 cp config.json.example config.json # 然后用编辑器打开config.json填写你的信息。 # { # apiKey: sk-your-actual-openai-api-key-here, # model: gpt-3.5-turbo # } # 方法B推荐更安全使用环境变量 # 创建.env文件避免将密钥提交到版本库 echo OPENAI_API_KEYsk-your-actual-openai-api-key-here .env echo OPENAI_MODELgpt-3.5-turbo .env # 然后需要修改llm.ts中的代码从process.env读取配置而不是config.json。修改llm.ts以支持环境变量 为了更安全地管理密钥建议对原项目做一个小改动。// llm.ts import { Configuration, OpenAIApi } from openai; // 引入dotenv在项目入口文件如index.ts需要先调用 import dotenv/config; // 或者在llm.ts顶部直接加载 import * as dotenv from dotenv; dotenv.config(); const configuration new Configuration({ // 优先从环境变量读取如果不存在则回退到config.json需自行实现fallback逻辑 apiKey: process.env.OPENAI_API_KEY, // 从.env文件读取 }); const openai new OpenAIApi(configuration); export async function generateCompletion(prompt: string): Promisestring { const model process.env.OPENAI_MODEL || gpt-3.5-turbo; // 从环境变量读取模型 try { const response await openai.createChatCompletion({ model: model, messages: [{ role: user, content: prompt }], temperature: 0.1, // 温度设低让输出更确定更遵循指令 max_tokens: 500, }); return response.data.choices[0]?.message?.content?.trim() || ; } catch (error) { console.error(Error calling OpenAI API:, error); throw error; } }4.2 编写你的第一个智能体应用现在让我们创建一个入口文件比如index.ts来把各个组件组装起来并运行一个完整的示例。// index.ts import dotenv/config; // 加载环境变量 import { Agent } from ./src/agent; import { Executor } from ./src/executor; import { CalculatorTool, GetCurrentTimeTool, SearchWebTool } from ./src/toolkit; // 假设我们新增了一个工具 import { UserProfileTool } from ./src/toolkit; async function main() { // 1. 初始化工具集 // 你可以在这里添加或移除工具智能体的能力随之改变 const tools [ new CalculatorTool(), new GetCurrentTimeTool(), new SearchWebTool(), // 假设这是一个模拟搜索的工具 new UserProfileTool(), ]; // 2. 初始化智能体Agent和执行器Executor const agent new Agent(); const executor new Executor(agent, tools, { maxSteps: 8 }); // 设置最大循环步数为8 // 3. 运行智能体处理用户查询 const userQueries [ 北京现在的温度是多少如果高于25度就提醒我带伞。, // 需要搜索和判断 计算一下(15的平方加上37)除以4等于多少, // 需要计算器 用户ID为1001的邮箱地址是什么, // 需要调用自定义的用户查询工具 先告诉我现在的时间然后计算从今天到2024年元旦还有多少天。, // 多步骤组合任务 ]; for (const query of userQueries) { console.log(\n 用户问题: ${query} ); try { const finalAnswer await executor.run(query); console.log(智能体最终答案: ${finalAnswer}); } catch (error) { console.error(执行出错: ${error.message}); } } } main().catch(console.error);在运行之前我们需要编译TypeScript代码。在package.json的scripts中添加一个启动脚本会很方便。// package.json { scripts: { start: ts-node index.ts, build: tsc } }现在在终端运行npm start你就可以看到智能体是如何一步步思考、调用工具并最终给出答案的。控制台会输出每一轮的Thought、Action和Observation让你清晰地透视整个推理过程。4.3 核心配置项详解与调优要让你的ReAct智能体运行得更稳定、更高效理解并调整以下几个关键配置点非常重要模型选择 (model)gpt-3.5-turbo性价比高响应快对于大多数逻辑清晰的ReAct任务足够用。但在复杂推理或需要严格遵守输出格式时可能偶尔会“不听话”。gpt-4或gpt-4-turbo推理能力、指令遵循能力和格式一致性显著更强。如果你的任务非常复杂或者对输出格式的稳定性要求极高值得使用GPT-4。缺点是成本高、速度慢。建议开发调试阶段可以用gpt-3.5-turbo部署关键应用时考虑切换到gpt-4。生成参数 (temperature,max_tokens)temperature(温度)控制输出的随机性。范围0~2。对于ReAct任务强烈建议设置为一个较低的值如0.1或0.2。这样能确保模型尽可能确定性地遵循我们设定的“Thought/Action”格式减少解析失败的概率。max_tokens(最大令牌数)限制模型单次响应的长度。根据你的提示词长度和期望的回复长度来设置。如果提示词很长包含大量工具描述和历史需要预留足够的token给模型输出。通常设置为500-1000是安全的。执行器参数 (maxSteps)这是防止死循环的保险丝。对于一个定义良好的任务通常3-5步内就能解决。但对于开放域复杂问题可能需要更多步。建议初始设置为8-10。同时在日志中记录每一步的输出如果发现智能体经常达到上限而失败可能需要分析是工具能力不足、提示词引导不够还是问题本身过于复杂。提示词模板优化这是性能调优的主战场。除了基本格式你可以在系统指令中更加强调规则例如“你必须且只能使用提供的工具”、“你的‘Thought’部分应该详细分析当前状况和下一步计划”、“‘Action Input’必须是一个简单的字符串不要包含额外解释”。在工具描述中使用更具体、带示例的说明。例如将“输入一个城市名”改为“输入一个城市名称的字符串例如 ‘北京’ 或 ‘New York’。不要输入其他信息。”5. 常见问题排查与实战技巧即使框架搭建好了在实际运行中你肯定会遇到各种问题。下面是我在开发和测试过程中遇到的一些典型情况及其解决方案整理成了速查表。问题现象可能原因排查步骤与解决方案模型输出格式错误无法解析出Action。1. 提示词中对格式的强调不够。2.temperature参数过高导致输出随机性大。3. 模型特别是GPT-3.5偶尔“走神”。1.强化提示词在系统指令和用户指令中多次、醒目地强调格式。可以用“### 必须遵守的格式 ###”这样的标题。2.降低温度将temperature设为0.1。3.增加解析容错在parseResponse函数中使用更灵活的正则表达式如/Action:\s*([^\n])/i来匹配即使模型在格式前加了多余文字也能捕获。智能体陷入死循环反复调用同一工具或在不同工具间来回切换。1. 工具返回的观察结果未能提供有效信息导致模型无法推进。2. 任务本身模糊或无法由现有工具解决。3. 模型推理出现偏差。1.检查工具输出确保工具在失败或没有结果时返回明确的信息如“未找到相关信息”而不是空字符串或模糊错误。2.设置循环上限确保maxSteps已设置并记录每一步的历史方便事后分析。3.优化任务定义在用户问题中给予更明确的约束或通过系统指令限制其行为范围。调用工具时参数错误比如格式不对或缺少必要参数。1. 工具描述不够清晰模型不理解输入格式。2. 模型在Thought中推理出了参数但在生成Action Input时格式出错。1.细化工具描述在description中明确写出输入示例。例如“输入格式’城市名,国家代码‘例如 ’Paris,FR‘。”2.在解析后加入验证在Executor调用工具前可以简单检查actionInput是否符合预期格式如非空、包含特定分隔符如果不符合可以将这个验证错误作为Observation反馈给模型让它修正。API调用超时或网络错误。网络不稳定或OpenAI服务暂时性问题。1.实现重试机制在llm.ts的API调用和工具call方法中可以包裹一个简单的指数退避重试逻辑。2.添加超时设置为fetch或axios请求配置合理的超时时间如30秒。3.完善的错误处理确保所有异步操作都有try-catch并将错误信息转化为智能体能理解的字符串观察结果而不是让整个程序崩溃。提示词过长超出模型上下文窗口。ReAct历史记录累积过多或工具描述太详细。1.实现历史截断在Executor中不要无限制地累积全部历史。可以只保留最近3-5轮的交互或者当token数估计超过阈值时丢弃最早的几轮。2.精简工具描述在保证清晰的前提下压缩工具描述的篇幅。3.使用更高容量的模型例如使用gpt-4-32k或gpt-4-turbo等支持更长上下文的模型。实战技巧分享日志是调试的生命线在开发阶段务必让Executor打印出每一轮的完整信息Thought, Action, Observation。这能让你直观看到智能体的“思维过程”快速定位问题出在哪一环。从简单到复杂不要一开始就设计一个拥有十几个工具的复杂智能体。先用1-2个简单的工具如计算器、时间工具跑通整个流程确保基础循环和解析工作正常。然后再逐步添加更复杂的工具。模拟工具先行在集成真实的外部API或数据库之前可以先创建一些“模拟工具”Mock Tools。这些工具返回固定的或简单的模拟数据。这能让你在无需依赖外部服务的情况下快速测试智能体的逻辑流和提示词。成本监控每次调用OpenAI API都需要付费。在llm.ts中添加简单的日志记录每次调用的token使用量响应体中的usage字段有助于你预估成本并优化提示词。这个从零搭建的ReAct框架就像一个乐高底板你已经拥有了最核心的循环机制、组件接口和扩展能力。接下来你可以根据自己的需求在上面搭建出各种各样的智能体应用无论是内部数据分析助手、智能客服路由还是复杂的多步骤工作流自动化其核心模式都万变不离其宗。最重要的是通过亲手实现一遍你对智能体如何思考、如何行动有了最根本的理解这是使用任何高级框架都无法替代的收获。