这两年，“AI Agent”这四个字几乎成了所有技术社区的热词，朋友圈、推文、招聘JD里到处都在提。但坦白说，很多人对它的理解是碎片化的：有人觉得Agent就是“会调工具的ChatGPT”，有人觉得是“能自己写代码的机器人”，还有人把它等同于某几个热门的开源框架名。这些说法都有点影子，但都不完整。我花了不少时间把这一堆概念逐个拆开再串起来，越梳理越觉得，Agent不是某一个具体技术点，而是一整套“把大语言模型从对话机器变成任务执行器”的方法论。
这篇“概念串烧”想把AI Agent涉及的核心概念——从LLM的局限、ReAct范式、记忆与工具调用，到多Agent协作、评估兜底，再到最小可落地的实操案例——全部放进一条线里讲清楚。它不针对某个单一框架，也不吹捧某个特定方案，适合三类人看：想入门的开发者、准备把Agent落到实际业务里的产品/项目负责人，以及被各种概念绕晕、想建立一张清晰认知地图的同学。读完你能得到的不是一堆名词，而是一套能用来判断“什么是好的Agent方案”的思维框架。
1. 先把事情定义清楚：Agent到底是什么，它和普通LLM应用差在哪
1.1 LLM只是“大脑”，不是Agent的全部
很多人一开始会把Agent等同于“大模型+Prompt”，也就是在系统提示词里写一堆角色设定，再让模型回答问题。但真正跑过一个业务场景你就会发现，这种组合只能叫“聊天机器人”，离Agent差得远。Agent的关键不在于模型“会说什么”，而在于模型“能做什么”、并且“知道什么时候做什么”。
一个合格的Agent至少要具备四样东西：一个是规划能力，能把一个模糊的大目标拆成若干可执行的小步骤；一个是记忆能力，能记住当前任务做到哪一步了、之前做过什么；一个是工具调用能力，能去查询数据库、调用接口、操作文件、发送通知；还有一个是自我反思能力，能发现自己走错方向并主动纠正。LLM本身只是这里面负责“做决策”的那一部分，它算是大脑，但如果没有手和脚，大脑再聪明也只能困在原地。
我见过一个项目，团队把一份几万字的PDF文档塞给大模型，然后用提示词要求它“总结、分类、提炼”，最后效果非常差。原因很简单：上下文窗口放不下整份文档，模型根本没有“读全”的能力。后来改成用Agent的方式，先拆章节、再分段向量化、最后逐段召回并汇总，效果立刻就不一样了。同样的模型，换了一套执行架构，结果天差地别。这就是Agent和普通LLM应用最本质的区别：Agent是在给模型搭建一套完整的“感知—决策—执行”回路。
1.2 核心能力拆解：规划、记忆、工具、反思
我把Agent的核心能力拆成四个模块，方便理解，也方便后面设计系统时对号入座。
第一个是规划（Planning）。规划解决的是“怎么做”的问题。简单任务可以一步到位，复杂任务就必须拆解。比如目标是“做一份竞品分析报告”，Agent需要自己判断要分几步：先定竞品范围、再收集公开资料、再整理数据、再生成报告。每一步之间还有依赖关系，第2步没做完第3步就没办法开始。现在主流的做法是让模型输出一份任务清单，然后逐个执行，执行完一个打个勾，再决定下一步。这就是著名的“计划—执行”范式的雏形。
第二个是记忆（Memory）。记忆解决的是“做得怎么样”的问题。Agent在执行长任务时必须能回溯之前的结论，否则每走一步都会“失忆”。记忆又分两类，短期记忆就是会话里的对话历史，长期记忆就是把关键信息存进向量数据库或其他持久化存储，下次任务还能复用。我自己的经验是，记忆设计得好不好，直接决定Agent在复杂任务里会不会绕圈子。
第三个是工具调用（Tool Use）。工具解决的是“靠什么做”的问题。模型不会算精确的财务数字，不会查实时库存，不会给你发邮件，这些能力都需要通过外部工具补充。工具调用的本质是让模型学会“按格式输出调用请求”，系统再把这个请求翻译成真正的API调用，然后把结果喂回给模型。
第四个是反思（Reflection）。反思解决的是“做错了怎么办”的问题。早期Agent一跑就出Bug，因为模型不知道自己的输出对不对。现在常见的做法是加一个“评审员”环节，让模型自己检查一遍结果，或者用另一条提示词对结果做交叉校验。反思机制是我强烈建议别省掉的部分，它投入产出比极高，往往一两轮自我检查就能让任务成功率提升一大截。
1.3 一个场景看懂全链路：用Agent订机票
光讲概念不好理解，我用一个生活化的例子把四个能力串起来。假设你让一个Agent帮你订一张下周三从上海去北京的机票，预算不超过1500块。
第一步，Agent调用“规划”能力，把任务拆成三步：查询航班、筛选价格、提交预订。第二步，它需要“记忆”来记住预算限制是1500块、日期是下周三、出发地是上海，这些信息不能丢。第三步，它调用“工具”能力去访问航司查询接口，拿到实时航班列表，然后自己做一轮比较。第四步，找到合适的航班后，它不会直接下单，而是把结果呈现给你确认，如果你说“太贵了，换早上的”，它就把这个反馈写进记忆，重新规划查询条件。
整个过程中，LLM只负责“理解意图、做决策、生成调用指令”，真正的查航班、比价格、占座操作全靠工具。这一套跑通之后，你对Agent的理解就不会停在“聊天”层面了。
2. 概念串烧第一串：从链式调用到自主决策，模式在怎么演化
2.1 一条清晰的进化线：Prompt Chain → State Machine → Agent
概念串烧的第一串，我想先聊Agent的“模式进化史”，因为它能帮你理解为什么现在的Agent长这样。
最开始大家用的是Prompt Chain（提示词链），就是把一个大任务拆成几个子任务，每个子任务写一个Prompt，按顺序把上一个的输出传给下一个。优点是思路简单，适合流程固定的场景；缺点是完全没有反馈回路，只要中间某一步出错，整条链就断了。
后来有人觉得不行，就开始做状态机。把Agent定义成“一定数量的状态+状态之间的转移条件”，比如初始态、工具调用态、等待用户确认态、结束态。每一步执行完，程序判断当前状态，决定下一步跳转到哪里。状态机的好处是可控性很强，适合业务规则明确的场景；缺点是所有的转移条件都要提前写死，一旦遇到预料之外的情况，Agent就卡死。
再往后，就是现在大家说的Agent自主决策模式。它不再依赖预先写死的规则，而是让大模型在每一轮都自主决定下一步做什么、用哪个工具、什么时候结束。这种方式灵活度极高，代价是结果不可控。所以成熟的Agent系统不会走极端，而是把状态机当骨架，把LLM当决策引擎——主流程仍然是可控的状态转移，但在每个状态内部，用大模型来决定具体操作。我实操下来，这种“半自主”设计是在可控性和效果之间最平衡的方案。
2.2 ReAct：让推理和行动交替前进
概念串烧里必须重点讲ReAct，因为它是目前绝大多数Agent框架的底层逻辑。ReAct的全称是Reasoning and Acting，核心思想就是“边想边做”，模型不再闷头输出一个最终答案，而是一步步地输出思考过程、再输出动作，看到动作结果后继续思考。
一个典型的ReAct循环长这样：模型先输出一个Thought（我看到了什么，我打算怎么做），再输出一个Action（我要调用哪个工具，传入什么参数），系统执行工具并返回Observation（结果是这样的），模型再基于Observation继续输出Thought，循环往复，直到它认为任务完成。
这个模式好在哪里？我自己的体会是，它把“推理过程”暴露给了开发者，你可以在日志里看它为什么做出这个决定，排查问题的时候特别有用。理解ReAct别把它想得多高深，它本质上就是“人干活的方式”：先想一想，再上手做，做完看看结果，再决定下一步接着做还是换个思路。
2.3 Plan-and-Execute与Reflection：让长任务不再半途崩坏
ReAct适合中等长度的任务，但真遇到一个需要20步以上才能完成的长任务，纯ReAct就容易出问题——Agent走着走着就会把最初的目标忘了。这时候就需要Plan-and-Execute模式：先不用边想边做，而是让模型在开始阶段就把整个任务拆成一份完整计划，然后照着计划一步步执行，每一步执行完再快速校验。
我更喜欢把Plan-and-Execute和**Reflection（反思）**放在一起用。反思机制是在每一步执行完之后，加一轮“我是谁、我在哪、我要干什么”的自我核对。具体做法是在Prompt里要求模型先总结“目前已完成的内容”和“离最终目标的差距”，再决定是继续当前计划，还是需要修正计划。这里有个很值得注意的细节：反思不是简单地让模型“检查一下”，而是要给出一套明确的检查标准，比如“输出必须含有三部分结论”“预算不能超过1500元”，没有标准的反思，模型只会自我表扬，不会发现问题。
3. 概念串烧第二串：记忆、工具、多Agent协作，三块拼图一个都不能少
3.1 记忆系统：让Agent不再“聊完就忘”
记忆是Agent从“demo玩具”走向“生产可用”的关键一跃，但也是被忽视得最严重的一块。简单的Chatbot不需要记忆，因为每轮对话都是孤立的；但Agent跑一个多步任务，每一步对下一步都有影响，没有记忆系统，整个任务就是无源之水。
我习惯把记忆分成三档：会话记忆、工作记忆、长期记忆。会话记忆是把最近几轮的对话原文放进上下文窗口，适合短任务，成本低、实现快。工作记忆是结构化地记录“当前任务的目标、已完成步骤、当前卡片”，对应人类工作台面上放的东西，适合中等复杂任务。长期记忆则把有价值的信息向量化之后存进向量库，当新任务到来时通过相似度检索把相关记忆召回，适合跨会话的个性化场景。
设计记忆系统时最大的坑是“上下文污染”：你把太多历史记录塞给模型，模型反而分不清哪条是当前任务的有效信息。我常用的方案是“三层筛选”，第一层是置顶系统提示词里的目标说明，第二层是最近3—5轮的会话记录，第三层是检索回来的长期记忆。三层合并后，再交给模型处理。这样既不会让上下文爆炸，又能让模型始终盯着核心目标。实际跑下来，同样一个模型，加了良好记忆设计的成功率能提升50%以上，这不是夸张，Agent丢目标是最常见的失败原因。
3.2 工具调用：从“会说话”到“会办事”的关键一跳
Agent和普通LLM应用最大的分水岭就是工具调用。没有工具的Agent只能输出文字建议，比如“我建议你查一下天气”；有工具的Agent能直接拉取天气数据、判断是否需要带伞、再自动更新你的日程备注。后者才是“帮我办事”。
实现工具调用的思路主要有两种。一种是函数回调范式：给每个工具定义一个名字、一段描述、若干参数，然后把工具列表塞进Prompt或模型的工具接口，模型输出结构化的调用请求，代码去执行并返回结果。这是目前大多数正式Agent框架采用的方案。另一种是纯Prompt范式：不用专门接口，而是在上下文里约定“如果你想查天气，输出一条特定格式的JSON”，然后代码解析。这种方式不依赖模型厂商的特殊接口，通用性强。
无论哪种方案，工具定义的质量直接决定Agent智商。我踩过的坑是“工具描述太薄”，比如给模型定义了一个send_email工具，描述只写“发送邮件”，模型根本不知道什么时候该用它。正确的做法是把工具描述写得像一份使用说明，说清楚这个工具是干什么的、适用什么场景、参数格式是什么、有哪些限制。你甚至可以加一两句使用示例，实测效果会明显好于一句话描述。记住一句话：你给模型看什么样的工具，模型就会变成什么样的助手。
3.3 多Agent协作：让不同角色各司其职
单Agent能力再强，真到了生产环境也往往不够，因为现实任务的复杂度通常不是一个角色能覆盖的。于是有了多Agent协作模式。你可以把多个Agent当成一个团队里的不同成员：有负责拆解任务的主控Agent，有专门做数据分析的Agent，有负责写报告文案的Agent，还有负责审核质量的Agent。每个Agent的Prompt、工具、记忆都围绕自己的“岗位职责”来配置。
多Agent协作的编排方式大致有三种。第一种是主管—工人模式，一个主控Agent把任务拆分后分发给多个工人Agent，再由主控统一汇总。第二种是流水线模式，任务按顺序流经多个Agent，每个Agent在自己这步加工完再递给下一个。第三种是辩论模式，多个Agent各自给出方案，再互相评审挑问题，最终收敛出最优结果。我实际用得最多的是主管—工人模式，因为它结构清晰、好排查问题，流水线模式适合处理流程稳定的场景，辩论模式看起来酷，但成本高、耗时长，一般只在决策风险特别高的场景使用。
多Agent协作有个特别容易翻车的点就是“互相打架”。A Agent生成了结论，B Agent审核时不认可，两名Agent来回争执十轮也不会有结果。我的建议是给审核Agent明确授权：要么通过，要么打回，并且打回时只能附上具体的修改建议、不允许自由发挥。注意，权限边界不只是说“你能不能调这个工具”，还要规定“你能对别人的产出修改到什么程度”，否则协作链就是一场灾难。
4. 概念串烧第三串：框架、Prompt与评估，把概念落到工程实践
4.1 框架选型：别被“现成框架”绑架，先问自己的场景要什么
概念聊清楚了，接下来绕不开的问题是“用什么建”。市面上主流的Agent编排框架大致分三类：有一类玩的是“全宇宙一站式”，内置了记忆、工具、RAG、多Agent编排一大堆模块，功能多但对新手不友好，项目一大就容易黑盒化；有一类偏“轻量级”，核心就是一个循环执行“调用模型→调用工具→返回结果”的引擎，适合想掌控每个环节的开发者；还有一类干脆“不挑框架”，直接基于大模型函数调用接口自己写一个几十行的调度循环，灵活度最高。
我个人的选型建议有三条。第一条，如果目标是快速验证想法，优先选文档全、社区活跃的成熟框架，不在乎它是否繁琐。第二条，如果目标是做生产系统，尽量选可观测性做得好的方案，至少你要清楚每一步是“调用了哪个工具、花了多少Token、耗时多少”。第三条，如果你的场景内部系统非常特殊，比如强依赖某套内部API，那么别迷信“框架能搞定一切”，自己写一个调度器反而更省心。
还有个经常被忽略的问题：框架版本迭代快，今天能用的一套API，三个月后就可能废弃。我的习惯是把“模型调用层”在框架之外自己封装一层，这样底层框架想换就换，不至于牵一发动全身。
4.2 Prompt工程在Agent里的特殊玩法：写Prompt像写“岗位说明书”
Agent里的Prompt和传统Chatbot的Prompt不一样。Chatbot的Prompt大多是设定语气和知识边界，Agent的Prompt则更像一份“岗位说明书”，除了角色设定之外，还必须写清楚三样东西：目标定义、可用资源和执行规则、输出格式要求。
目标定义部分要写明“我要达成什么”“验收标准是什么”。可用资源列表要告诉模型“你有这些工具，分别在什么场景用”，执行规则要写明“逢年过节先发问候再谈正事”“预算超标必须请示”“上一轮结论要保留”。输出格式要求则针对不同环节做区分：规划阶段输出任务清单，执行阶段输出工具调用请求，总结阶段输出用户可读报告。
关键技巧是用“先决条件”来做决定门控。比如要查询某客户信息，就必须先确认已经拿到了客户ID，没ID直接让模型自编一个ID去查询，那是幻觉的根源。你可以在Prompt里写明“如果你发现某个必要参数缺失，必须向用户索要，不得猜测”，就是这么一句简单的规则，能让整体可靠性提升明显。我还建议给模型一个“兜底回复模板”，当它无法完成任务时，要输出“我目前缺少XX信息，无法完成，请提供YY”，而不是硬编一个错误答案。
4.3 评估与可观测性：Agent上线前最该做的事，也是99%的团队最不重视的事
Agent开发和传统后端开发最大的区别是“没有确定性输出”。你没法写一组固定的测试用例，跑一遍断言“通过或失败”就完事。因此，评估体系变得比写功能代码还重要。
我建议每个Agent项目至少维护三类评估用例。第一类是单步工具调用评估，构造一批“用户输入→预期的工具调用序列”的组合，检查模型能不能选对工具、传对参数。第二类是端到端任务评估，准备一份典型任务清单，跑完整流程后看成功率、耗时、花费Token数。第三类是回归评估集，专门收集历史上出错的案例，每次改完代码或换模型之后重跑一遍，确保没有把修复过的问题改回去。
可观测性方面，最基础的要求是记录思维链路日志：每一轮Thought、Action、Observation都要落地。第二层是记录成本明细，每个任务消耗多少Token、调了多少次模型，不然上线后账单一个月吓死你。第三层是记录状态快照，任务中途失败时，能回放它是卡在哪一步、因为什么卡住的。我自己调试Agent时，第一件事永远不是改Prompt，而是翻日志看它到底走了哪条路，看完日志再动手，往往一击即中。
5. 实操实录：用最小成本搭一个“查天气+写日报”的Agent
5.1 环境准备与方案选型
光讲概念容易飘，我决定用一个最小但完整的例子，带你从零搭一个Agent：它能根据用户输入的城市名查询天气，然后把天气信息加进一份当天日报。
任务很小，但五脏俱全：涉及用户意图解析、工具调用、上下文记忆、结果汇总。实现语言就用Python，模型接口不限。为了不掉进框架复杂度，我直接在框架外写调度循环，这样每一行代码你都看得懂。
环境准备只需要三步：安装一个Python环境；安装一个轻量的HTTP库用于调模型API和天气API；准备一个模型API的密钥。全程不需要本地大模型，也不需要GPU。整个项目几十行代码就能跑起来。
5.2 核心代码与关键步骤拆解
核心代码我拆成几块来讲。第一块是工具定义。给Agent准备一个查询天气的函数：
def get_weather(city: str) -> str: # 这里是伪接口，实际可以换成任意天气服务商 data = requests.get(f"https://api.weather.example.com/v1/weather?city={city}").json() return f"{city}当前{data['temp']}℃，天气{data['condition']}，湿度{data['humidity']}%"注意函数名要见名知意，返回结果要直接是自然语言片段，方便模型直接消化。
第二块是系统提示词。我写的是：
你是一个任务执行助手。你可以调用工具来获取实时信息。 当前可用工具： - get_weather(city)：获取指定城市的当前天气，city为城市中文名。 流程约定： 1. 如果你需要天气信息，先检查用户是否提供了城市名。 2. 如果缺少城市名，你必须向用户询问，禁止猜测城市。 3. 拿到结果后，生成一份包含天气信息的日报，结构为：日期、城市、天气概况、出行建议。 现在开始，用户说：“帮我安排明天的日报，地点是杭州。”这段提示词里最关键的是“缺失信息必须询问”的规则，它挡住了大多数幻觉。
第三块是执行循环。核心就是一个while循环：
def run_agent(user_input, messages=[]): messages.append({"role": "user", "content": user_input}) for step in range(5): reply = call_llm(SYSTEM_PROMPT, messages) action = parse_action(reply) if action is None: messages.append({"role": "assistant", "content": reply}) return reply result = execute_tool(action) messages.append({"role": "assistant", "content": reply}) messages.append({"role": "tool", "content": result}) return "超出最大步数，任务终止"parse_action是解析函数，它从模型输出里提取工具名和参数。execute_tool是执行函数，它把模型请求翻译成真实调用。循环上限设成5步，防止模型陷入死循环。这个设计虽然粗糙，但已经是“LLM+工具+上下文”的完整Agent。
5.3 真实运行记录与踩坑修正
第一次跑的时候，模型没有直接调用工具，而是“自作聪明”在文字里伪造了一个天气结果，说什么“杭州今日晴，26℃”。这其实是生成式模型最典型的毛病：它不是不能调工具，而是不知道“什么情况应该调工具”。解决办法有两个方向：优先让模型在每轮输出前加一句判断“是否需要调用工具”，如果需要就输出指定格式的JSON；同时在系统提示词里写明“你必须调用工具才能回答天气问题，任何未经工具确认的天气数据都视为错误”。加了这句话之后，模型就老实了，每次都规规矩矩先调工具再回答。
第二个踩坑是多轮对话的上下文污染。用户只问了一次杭州天气，但第二次追问“那明天呢”，模型把“明天”理解成昨天回答的天气再复述一遍，而不是重新调工具。解决办法是在工具返回的内容里加上时间戳，并且在提示词里说明“每一次查询都要重新调用工具，不得引用之前查询结果作为新答案”。这个细节在真实生产环境里极其重要，因为时间相关的数据一旦被缓存复用，结果就是错的。
第三个坑是模型被工具返回结果带偏。当天气工具返回“杭州当前32℃，天气多云，湿度80%”时，模型可能会把“当前”误以为“明天”，因为Prompt里的需求是日报里的明天。我的修正方式是在工具返回内容前强制标注数据时间：{date: 2026-01-15, city: 杭州, weather: ...}，然后让模型自己判断这个数据时间是否满足“明天”的要求。
这轮实操下来我的感受是：Agent的大部分问题不在模型能力，而在“信息链路的清晰度”。你把工具返回值标注清楚、把判断规则写明确，同样一个模型能做的事会多出一倍。
6. 常见问题速查：Agent落地最容易踩的坑
6.1 高频问题与对应解法
我在多个Agent项目里反复遇到一些相同的问题，这里整理成一张速查表，可以直接对照排查。
| 表现 | 根因 | 解法 |
|---|---|---|
| 模型不调用工具，而是直接编造结果 | 提示词里没有明确“必须调工具” | 写明“不调工具的结果视为错误”，并附工具使用示例 |
| 模型调工具但参数乱传 | 工具描述太简单，模型不知道参数格式 | 工具描述写全，含参数类型、取值范围、示例 |
| 长任务跑到一半丢失目标 | 缺少工作记忆和阶段性总结 | 增加步骤进度记录，每隔几步总结一次 |
| 多Agent互相推翻结论 | 审核Agent的修改权限过大 | 审核Agent只允许“通过/打回+建议”，不允许自由修改 |
| 同一条用户输入，答案每次都不一样 | 模型温度设置过高，或上下文不稳定 | 业务型任务把温度调到0.2以下，固定Prompt顺序 |
| 成本失控，一次任务调上百次模型 | 没有步数上限和工具失败重试限制 | 设最大循环次数，工具连续失败2次就终止并降级 |
| Agent陷入死循环反复调同一个工具 | 工具结果没有让上下文发生有意义的变化 | 工具返回里加入状态变化标记，模型判断“无进展”时退出 |
6.2 几条保命级的避坑心得
最后分享几条我在实际项目中验证过的保命经验，这些在官方文档里通常不会写。
第一，永远给Agent一个“退出通道”。不管是步数上限还是“连续三次无实质进展就停止”，必须让Agent自己有能力结束任务。我以前见过一个演示版Agent，因为没有步数上限，在测试环境里循环调用了一个查询接口整整一个晚上，第二天账单令人崩溃。
第二，工具返回值要“结构化+自然语言”双份表达。纯JSON对模型不够友好，模型读长JSON容易漏字段；纯自然语言又不好程序化处理。我习惯的格式是：先给一段自然语言摘要，再把结构化JSON放在后面，模型既好理解，程序也好解析。
第三，评测集要“脏”，不要只放标准答案。别只准备“给我查下北京天气”这种正常输入，要多放一些模糊、带错别字、缺参数的输入，例如“帮我看看天气明天”“查一下杭州的吧”，这些才是Agent真正在现实场景里遇到的输入。评测集越脏，Agent在真实环境里越稳。
第四，模型版本升级了，一定要重新跑回归集。我吃过一次亏：换了一个能力更强的新模型，结果旧工具调用的JSON格式它不认，导致整个任务链从头崩到尾。任何模型调整，都要先跑一遍历史用例，再决定要不要上生产。
我自己绕了挺大一圈才把这些概念串明白。最初也被各种术语搞得很焦虑，后来发现核心就一句话：Agent不是魔法，它只是在给LLM配上规划、记忆、工具和反思这四件装备。这些装备可以先用最简单的代码自己实现，慢慢再替换成更成熟的框架。如果你现在正准备做Agent，我的建议是从一个最简单、最不完美的例子跑通全流程，再逐步加复杂度。先把今天这篇里的几个关键“为什么”想透，你后面踩坑的次数会少很多。
