系列第 1 篇个人入门笔记按自己的原文草稿和理解由AI重写方便复习。目录1. 我先记住的等式2. 工具Agent 的手脚3. 一次工具调用是怎么转起来的4. LLMAgent 的大脑5. 三种学习机制我怎么区分6. 上下文Agent 的眼睛7. ReAct 循环、轨迹以及那条关键事实参考链接1. 我先记住的等式部件在系统里是什么我的比喻缺了会怎样LLM决策内核大脑只会按写死的分支走不会临场判断上下文这一步可见的全部信息眼睛模型在瞎猜看不到工具结果和历史工具能访问信息、改变外部状态的动作集合手脚只会说不能查也不能做这张表我用来挡两种常见误解。第一种把提示词写得很长就叫 Agent。提示词只是上下文里的一块静态说明。没有工具、没有「看结果再决定」的循环它仍然是一次生成。第二种接了一堆 API就叫 Agent。脚本也能调 API。差别在于是谁决定这一步调不调、调哪个、参数是什么。这个决定权在模型不在外面那层if/else。实践补充Anthropic 在《Building effective agents》里把生产里常见的 Agent 概括成「在循环中根据环境反馈使用工具的 LLM」。和上面这句等式是同一件事只是他们更强调先把这个循环做简单、做透明再考虑多 Agent。原文Building effective agents。2. 工具Agent 的手脚我把笔记里的工具分成五类。前三类是模型可以主动选择的动作后两类更像「信息怎么进来、怎么回去」。类型做什么例子感知工具让 Agent 访问信息不改外部世界读文件、搜索、查天气、读网页执行工具让 Agent 改变世界写文件、发消息、跑命令、下单协作工具让 Agent 和其他 Agent 分工把子任务交给另一个专门的 Agent事件触发不是模型主动发起的而是外部输入到达后模型能感知并响应新邮件、定时点到达、构建失败告警用户沟通专注把信息传递给人和收回人的判断提问、确认、汇报进度事件触发容易和「工具调用」混在一起。我的区分是邮件到了、时间到了这是外部把一条新消息推进上下文模型看到之后再决定要不要调用感知工具或执行工具。触发器本身通常不是模型填参数去「调用」的那个函数。设计工具时尽量保持通用笔记里有一句我反复提醒自己为 Agent 设计工具时应尽量保持工具的通用性。专用工具看起来省事比如单独做一个rename_readme_to_backup。下次要改的是另一个文件、另一种改名规则这个工具就废了。通用工具是read_file、search、write_file、run_command这种可组合的动作。专用流程放进提示词或外部知识库不要焊死在工具名上。实践补充同一篇文章的附录把工具文档比作 Agent 和计算机之间的界面。描述要写清用途、参数、边界和例子让模型不容易用错。绝对路径优于「当前目录下的相对路径」因为模型会忘了自己已经换过目录。这不是我原文里的句子是我后来对照官方工程文章补上的判断。3. 一次工具调用是怎么转起来的工具不是模型「自己执行」的。模型只能产出结构化的调用请求。执行发生在模型外面结果再写回上下文。我笔记里的四步是在上下文里告诉模型有哪些工具可用包括名称、用途和参数。模型自己判断要不要调用、调用哪个、传什么参数。框架执行工具把结果追加进上下文。模型据此决定下一步。这个循环就是后面 ReAct 的基础。工具定义我习惯写成下面这种结构。名称要短描述要写「什么时候用、什么时候不用」。{name:lookup_city_weather,description:查询指定城市的当日天气。仅当用户在问天气且上下文里还没有当日结果时使用。,parameters: {type:object,properties: {city: {type:string,description:城市名例如上海。不要传国家或经纬度。} },required: [city] } }下面这段不是生产框架只用来把四步画成能跑的形状。model_step在真实系统里是一次 LLM 调用这里用规则假装模型避免把笔记写成某个厂商 SDK 的教程。TOOLS {lookup_city_weather:lambdacity:f{city}多云22°C, }defmodel_step(context:list[dict]) -dict:教学替身真实系统中这一步是一次 LLM 调用。asked any(天气inm.get(content,)formincontext) already any(m.get(role) toolformincontext)ifaskedandnotalready:return{reasoning:没有当日数据先调用查询工具。,content:,tool_calls: [{name:lookup_city_weather,arguments: {city:上海}, }], }return{reasoning:工具结果已在上下文中可以回答。,content:上海今天多云大约 22°C。,tool_calls: [], }循环本身和「谁来执行工具」分开。run_turn只负责把请求发出去、把结果写回并在没有调用或步数用尽时停下来。# 接上一段TOOLS 与 model_step 已定义defrun_turn(user_text:str, max_steps:int4) -str: context [ {role:system,content:没有实时数据时必须调用工具。}, {role:user,content: user_text}, ]for_inrange(max_steps): step model_step(context) context.append({role:assistant,content: step[content],tool_calls: step[tool_calls], })ifnotstep[tool_calls]:returnstep[content]forcallinstep[tool_calls]: result TOOLS[call[name]](**call[arguments]) context.append({role:tool,name: call[name],content: result})return达到步数上限停止并说明未完成。我用这段代码记住三件容易说反的事模型输出的是请求不是天气本身。工具结果是一条新消息不是改写用户原话。必须有步数上限。否则模型可以一直「再查一次」。4. LLMAgent 的大脑LLM 是 Agent 的决策内核。和其他自动化相比它独特的地方是内部思考在真正行动之前先规划、先推演再决定要不要动手。笔记里我把一次模型回复拆成最多三块后面讲上下文时还会再见到它们思考过程reasoning内部推演用来保持连贯也让决策可以被人看懂。文本内容content给用户的话。工具调用请求tool_calls这一步打算采取的行动。三块可以只出现其中一部分。只思考不调用是在计划只调用不说话是在动手三者都空通常是这一轮失败了不该假装它「已经做完」。模型即 Agent当模型本身成为产品笔记里我写过两个短句模型即 Agent以及方向认同节奏务实。我的理解是当一个模型产品自己就能看上下文、选工具、把结果接回来Agent 就不再只是「模型外面再包一层状态机」。方向我认同。节奏上我故意放慢——先把单循环、工具描述和停止条件做稳再谈多 Agent 分工。框架能少写就少写。看不懂底层消息是怎么拼起来的后面一定排不了错。5. 三种学习机制我怎么区分Agent 会「变好」不代表每次都在改模型权重。我把笔记里的三种学习并排放机制经验放在哪能做什么代价后训练写进模型参数把反复出现的经验内化成默认行为更新成本高不能每次任务都重训上下文学习放在当前窗口里的例子和历史套用已经见过的模式不能凭空发现全新规律外部化学习知识库以及可执行的工具代码把知识和流程放到模型外面用到再取要自己维护这些外部工件过期了会误导模型三者不是互斥的。后训练决定模型「默认会不会用工具」上下文学习决定「这一次照着哪条轨迹做」外部化学习决定「查不到的知识不必塞进参数也不必塞满窗口」。我现在的优先级是能外部化的流程先写成工具和说明不要指望靠一次后训练记住我的目录结构。目录会变工具描述可以改。6. 上下文Agent 的眼睛上下文不是「聊天记录」的别名。它是模型在这个决策点能看到的全部信息。我笔记里的组成是部分谁写的变不变系统提示词开发者整段对话里通常保持不变。它是岗位说明书身份、权限、行为准则工具定义开发者相对稳定。声明名称、功能描述、参数格式用户消息用户随对话增加模型回复模型最多含思考、文本、工具调用请求工具执行结果Agent 框架工具跑完后追加回来前两块我称为静态前缀岗位说明书 工具清单。后面三块会随任务增长那就是下一节的轨迹。实践补充上下文窗口是有限的。Anthropic 后来把这件事叫作 context engineering在每一步放进「最小的一组高信号信息」而不是把能找到的材料全塞进去。工具的价值之一就是不必事先把整个资料库放进眼睛里用到再取。原文Effective context engineering for AI agents。所以「眼睛」不是越大越好。塞进无关邮件、过期工具结果、重复的系统说明模型仍可能看见但决策会被噪声带着走。7. ReAct 循环、轨迹以及那条关键事实ReAct 不是又一个聊天格式。它是把「先想一句再做一个动作再看环境返回什么」交错起来的循环。名字来自 Yao 等人 2022 年的论文ReAct: Synergizing Reasoning and Acting in Language Models。论文页arxiv.org/abs/2210.03629项目页react-lm.github.io。论文里的核心观察我用自己的话记只推理容易把不知道的事实说成知道只行动有了观察也组织不成下一步。交错之后推理负责改计划、处理异常行动负责从外部把新信息拿回来。他们报告的对比我只引用论文摘要里的数字不自行加戏在 ALFWorld 和 WebShop 上一两条例子的 ReAct比模仿学习或强化学习方法的成功率分别高出 34 和 10 个百分点。问答和事实验证任务上它通过和简单的 Wikipedia 接口交互减轻只靠链式推理时的幻觉和错误传递。轨迹轨迹是 Agent 执行任务时不断积累的消息历史用户消息、模型回复含思考和工具调用、工具执行结果。关键事实Agent 的上下文 静态前缀 轨迹。静态前缀回答「你是谁、你能用什么」。轨迹回答「到目前为止发生了什么」。模型下一步的判断只能基于这两者不能基于你以为它「应该记得」、但没有写进消息里的东西。一轮成功的天气查询轨迹长这样user: 上海今天天气怎么样 assistant: reasoning先查询 assistant: tool_callslookup_city_weather(上海) tool: 上海多云22°C assistant: content上海今天多云大约 22°C。 stop: 没有新的工具调用循环结束排错时我只看这条轨迹不问「模型聪不聪明」。常见断点就四个工具没写进前缀、模型没发出调用、框架没把结果追加回去、结果追加了但描述和真实返回对不上。参考链接ReAct: Synergizing Reasoning and Acting in Language ModelsReAct 项目页Building effective agentsEffective context engineering for AI agents 
长河君 · 2026/10/9 5:43:11 · 阅读 1.2k AI Agent 学习笔记 01：现代 Agent = LLM + 上下文 + 工具
系列第 1 篇个人入门笔记按自己的原文草稿和理解由AI重写方便复习。目录1. 我先记住的等式2. 工具Agent 的手脚3. 一次工具调用是怎么转起来的4. LLMAgent 的大脑5. 三种学习机制我怎么区分6. 上下文Agent 的眼睛7. ReAct 循环、轨迹以及那条关键事实参考链接1. 我先记住的等式部件在系统里是什么我的比喻缺了会怎样LLM决策内核大脑只会按写死的分支走不会临场判断上下文这一步可见的全部信息眼睛模型在瞎猜看不到工具结果和历史工具能访问信息、改变外部状态的动作集合手脚只会说不能查也不能做这张表我用来挡两种常见误解。第一种把提示词写得很长就叫 Agent。提示词只是上下文里的一块静态说明。没有工具、没有「看结果再决定」的循环它仍然是一次生成。第二种接了一堆 API就叫 Agent。脚本也能调 API。差别在于是谁决定这一步调不调、调哪个、参数是什么。这个决定权在模型不在外面那层if/else。实践补充Anthropic 在《Building effective agents》里把生产里常见的 Agent 概括成「在循环中根据环境反馈使用工具的 LLM」。和上面这句等式是同一件事只是他们更强调先把这个循环做简单、做透明再考虑多 Agent。原文Building effective agents。2. 工具Agent 的手脚我把笔记里的工具分成五类。前三类是模型可以主动选择的动作后两类更像「信息怎么进来、怎么回去」。类型做什么例子感知工具让 Agent 访问信息不改外部世界读文件、搜索、查天气、读网页执行工具让 Agent 改变世界写文件、发消息、跑命令、下单协作工具让 Agent 和其他 Agent 分工把子任务交给另一个专门的 Agent事件触发不是模型主动发起的而是外部输入到达后模型能感知并响应新邮件、定时点到达、构建失败告警用户沟通专注把信息传递给人和收回人的判断提问、确认、汇报进度事件触发容易和「工具调用」混在一起。我的区分是邮件到了、时间到了这是外部把一条新消息推进上下文模型看到之后再决定要不要调用感知工具或执行工具。触发器本身通常不是模型填参数去「调用」的那个函数。设计工具时尽量保持通用笔记里有一句我反复提醒自己为 Agent 设计工具时应尽量保持工具的通用性。专用工具看起来省事比如单独做一个rename_readme_to_backup。下次要改的是另一个文件、另一种改名规则这个工具就废了。通用工具是read_file、search、write_file、run_command这种可组合的动作。专用流程放进提示词或外部知识库不要焊死在工具名上。实践补充同一篇文章的附录把工具文档比作 Agent 和计算机之间的界面。描述要写清用途、参数、边界和例子让模型不容易用错。绝对路径优于「当前目录下的相对路径」因为模型会忘了自己已经换过目录。这不是我原文里的句子是我后来对照官方工程文章补上的判断。3. 一次工具调用是怎么转起来的工具不是模型「自己执行」的。模型只能产出结构化的调用请求。执行发生在模型外面结果再写回上下文。我笔记里的四步是在上下文里告诉模型有哪些工具可用包括名称、用途和参数。模型自己判断要不要调用、调用哪个、传什么参数。框架执行工具把结果追加进上下文。模型据此决定下一步。这个循环就是后面 ReAct 的基础。工具定义我习惯写成下面这种结构。名称要短描述要写「什么时候用、什么时候不用」。{name:lookup_city_weather,description:查询指定城市的当日天气。仅当用户在问天气且上下文里还没有当日结果时使用。,parameters: {type:object,properties: {city: {type:string,description:城市名例如上海。不要传国家或经纬度。} },required: [city] } }下面这段不是生产框架只用来把四步画成能跑的形状。model_step在真实系统里是一次 LLM 调用这里用规则假装模型避免把笔记写成某个厂商 SDK 的教程。TOOLS {lookup_city_weather:lambdacity:f{city}多云22°C, }defmodel_step(context:list[dict]) -dict:教学替身真实系统中这一步是一次 LLM 调用。asked any(天气inm.get(content,)formincontext) already any(m.get(role) toolformincontext)ifaskedandnotalready:return{reasoning:没有当日数据先调用查询工具。,content:,tool_calls: [{name:lookup_city_weather,arguments: {city:上海}, }], }return{reasoning:工具结果已在上下文中可以回答。,content:上海今天多云大约 22°C。,tool_calls: [], }循环本身和「谁来执行工具」分开。run_turn只负责把请求发出去、把结果写回并在没有调用或步数用尽时停下来。# 接上一段TOOLS 与 model_step 已定义defrun_turn(user_text:str, max_steps:int4) -str: context [ {role:system,content:没有实时数据时必须调用工具。}, {role:user,content: user_text}, ]for_inrange(max_steps): step model_step(context) context.append({role:assistant,content: step[content],tool_calls: step[tool_calls], })ifnotstep[tool_calls]:returnstep[content]forcallinstep[tool_calls]: result TOOLS[call[name]](**call[arguments]) context.append({role:tool,name: call[name],content: result})return达到步数上限停止并说明未完成。我用这段代码记住三件容易说反的事模型输出的是请求不是天气本身。工具结果是一条新消息不是改写用户原话。必须有步数上限。否则模型可以一直「再查一次」。4. LLMAgent 的大脑LLM 是 Agent 的决策内核。和其他自动化相比它独特的地方是内部思考在真正行动之前先规划、先推演再决定要不要动手。笔记里我把一次模型回复拆成最多三块后面讲上下文时还会再见到它们思考过程reasoning内部推演用来保持连贯也让决策可以被人看懂。文本内容content给用户的话。工具调用请求tool_calls这一步打算采取的行动。三块可以只出现其中一部分。只思考不调用是在计划只调用不说话是在动手三者都空通常是这一轮失败了不该假装它「已经做完」。模型即 Agent当模型本身成为产品笔记里我写过两个短句模型即 Agent以及方向认同节奏务实。我的理解是当一个模型产品自己就能看上下文、选工具、把结果接回来Agent 就不再只是「模型外面再包一层状态机」。方向我认同。节奏上我故意放慢——先把单循环、工具描述和停止条件做稳再谈多 Agent 分工。框架能少写就少写。看不懂底层消息是怎么拼起来的后面一定排不了错。5. 三种学习机制我怎么区分Agent 会「变好」不代表每次都在改模型权重。我把笔记里的三种学习并排放机制经验放在哪能做什么代价后训练写进模型参数把反复出现的经验内化成默认行为更新成本高不能每次任务都重训上下文学习放在当前窗口里的例子和历史套用已经见过的模式不能凭空发现全新规律外部化学习知识库以及可执行的工具代码把知识和流程放到模型外面用到再取要自己维护这些外部工件过期了会误导模型三者不是互斥的。后训练决定模型「默认会不会用工具」上下文学习决定「这一次照着哪条轨迹做」外部化学习决定「查不到的知识不必塞进参数也不必塞满窗口」。我现在的优先级是能外部化的流程先写成工具和说明不要指望靠一次后训练记住我的目录结构。目录会变工具描述可以改。6. 上下文Agent 的眼睛上下文不是「聊天记录」的别名。它是模型在这个决策点能看到的全部信息。我笔记里的组成是部分谁写的变不变系统提示词开发者整段对话里通常保持不变。它是岗位说明书身份、权限、行为准则工具定义开发者相对稳定。声明名称、功能描述、参数格式用户消息用户随对话增加模型回复模型最多含思考、文本、工具调用请求工具执行结果Agent 框架工具跑完后追加回来前两块我称为静态前缀岗位说明书 工具清单。后面三块会随任务增长那就是下一节的轨迹。实践补充上下文窗口是有限的。Anthropic 后来把这件事叫作 context engineering在每一步放进「最小的一组高信号信息」而不是把能找到的材料全塞进去。工具的价值之一就是不必事先把整个资料库放进眼睛里用到再取。原文Effective context engineering for AI agents。所以「眼睛」不是越大越好。塞进无关邮件、过期工具结果、重复的系统说明模型仍可能看见但决策会被噪声带着走。7. ReAct 循环、轨迹以及那条关键事实ReAct 不是又一个聊天格式。它是把「先想一句再做一个动作再看环境返回什么」交错起来的循环。名字来自 Yao 等人 2022 年的论文ReAct: Synergizing Reasoning and Acting in Language Models。论文页arxiv.org/abs/2210.03629项目页react-lm.github.io。论文里的核心观察我用自己的话记只推理容易把不知道的事实说成知道只行动有了观察也组织不成下一步。交错之后推理负责改计划、处理异常行动负责从外部把新信息拿回来。他们报告的对比我只引用论文摘要里的数字不自行加戏在 ALFWorld 和 WebShop 上一两条例子的 ReAct比模仿学习或强化学习方法的成功率分别高出 34 和 10 个百分点。问答和事实验证任务上它通过和简单的 Wikipedia 接口交互减轻只靠链式推理时的幻觉和错误传递。轨迹轨迹是 Agent 执行任务时不断积累的消息历史用户消息、模型回复含思考和工具调用、工具执行结果。关键事实Agent 的上下文 静态前缀 轨迹。静态前缀回答「你是谁、你能用什么」。轨迹回答「到目前为止发生了什么」。模型下一步的判断只能基于这两者不能基于你以为它「应该记得」、但没有写进消息里的东西。一轮成功的天气查询轨迹长这样user: 上海今天天气怎么样 assistant: reasoning先查询 assistant: tool_callslookup_city_weather(上海) tool: 上海多云22°C assistant: content上海今天多云大约 22°C。 stop: 没有新的工具调用循环结束排错时我只看这条轨迹不问「模型聪不聪明」。常见断点就四个工具没写进前缀、模型没发出调用、框架没把结果追加回去、结果追加了但描述和真实返回对不上。参考链接ReAct: Synergizing Reasoning and Acting in Language ModelsReAct 项目页Building effective agentsEffective context engineering for AI agents