一小时学会LLM Agent - 讲座总结

过去几年，大语言模型的发展改变了人们使用人工智能的方式。以ChatGPT为代表的生成式人工智能系统，可以理解自然语言、生成文本、回答问题、总结资料、编写代码，并在很多知识型任务中表现出较强的能力。

但是，仅仅能够生成答案，还不能完全满足现实世界中的复杂需求。

例如，当用户说“帮我规划一次出差并订好机票”时，一个普通聊天机器人可能能够查询航班信息、比较价格，并告诉用户应该选择哪一个航班。但真正完成这个任务，还需要访问外部网站或API、获取实时数据、根据用户条件进行筛选，并最终执行预订操作。

这就引出了LLM Agent，即基于大语言模型构建的智能体系统。

Agent的核心思想并不是简单地让大语言模型“回答得更好”，而是让模型成为一个能够参与任务决策的组件，再结合工具、记忆、规划、执行和验证机制，使系统能够围绕一个目标进行多步骤操作。

因此，可以把从Chatbot到Agent的变化理解为：人工智能系统正在从“生成答案”进一步走向“完成任务”。

一、什么是LLM Agent

Agent通常被翻译为“智能体”或“代理”。

在人工智能领域，它通常指一种能够感知环境、根据目标进行决策，并采取行动的计算系统。

LLM Agent则是将大语言模型作为重要的推理和决策组件，使其能够根据用户目标选择下一步行动，并通过工具与外部环境交互。

需要特别注意，Agent并不等于大语言模型本身。

大语言模型主要负责处理语言和生成模型输出。它本身通常不能直接访问互联网、操作数据库、发送邮件或修改文件。要完成这些现实世界中的操作，需要由外围软件系统提供工具和执行机制。

因此，一个完整的LLM Agent通常是多个组件共同工作的结果。

从工程角度，可以将其概括为四个重要组成部分：模型、工具、记忆以及控制Agent执行过程的循环机制。复杂系统中还会进一步加入规划、状态管理、评估、安全控制和人工审核等组件。

二、Chatbot与Agent有什么区别

理解Agent最简单的方法，是比较它与传统聊天机器人的差别。

传统Chatbot的基本工作流程通常是：用户输入问题，模型处理输入，然后生成回答。

例如，用户询问某种商品价格，系统可以查询信息并将价格告诉用户。任务在生成答案之后基本结束。

Agent则更加关注“目标”。

如果用户要求Agent帮助完成一次旅行安排，系统首先需要理解目标，然后确定需要完成哪些步骤。

它可能需要获取当前日期，搜索交通信息，比较不同选项，按照用户预算进行筛选，最后调用相应服务完成预订。

因此，Agent的重点不只是“说什么”，而是“下一步做什么”。

这也是Agent与传统生成式AI应用之间的重要区别。

三、Agent的核心：Agent Loop

如果说大语言模型是Agent的重要“大脑”，那么Agent Loop可以理解为控制整个系统持续运行的“工作循环”。

一个典型的Agent Loop可以概括为几个阶段：观察、思考或决策、行动以及验证。

首先是Observation，即观察。

Agent需要获得当前任务状态，包括用户输入、已有上下文、工具返回结果以及环境信息。

然后是Reasoning或Planning，即推理和规划。

系统需要根据当前状态判断下一步应该做什么。有时可以直接采取行动，有时则需要把复杂任务分解成多个子任务。

接下来是Action，即行动。

Agent根据决策调用相应工具。例如调用搜索接口、计算工具、数据库、文件系统或者业务API。

工具执行之后，会返回新的结果。

Agent再次观察这些结果，然后继续决定下一步。

最后是Verification，即验证。

系统需要判断当前任务是否已经完成。如果完成，则结束循环；如果没有完成，则根据新的状态继续执行。

因此，Agent并不是简单地“调用一次模型”，而是一个不断获取信息、决策、执行和验证的闭环。

四、为什么工具是Agent能力的重要组成部分

大语言模型具有强大的文本处理和生成能力，但它存在明显的能力边界。

例如，模型可能知道如何解释天气数据，但它未必能够直接获得某个城市当前的实时天气。

模型可以告诉用户如何订机票，但它通常不能仅凭自身参数直接完成真实世界中的支付和预订操作。

因此，Agent需要Tools，即工具。

工具可以是一个函数，也可以是API、数据库查询接口、搜索服务、文件系统、企业内部系统或者其他软件服务。

例如，一个天气Agent可以拥有天气查询工具；一个数据分析Agent可以拥有数据库查询和计算工具；一个办公Agent可以拥有读取文件、发送邮件和创建日程的工具。

这意味着Agent的能力并不完全由大语言模型本身决定。

更准确地说，模型决定了系统在信息理解、推理和工具选择方面的能力，而工具决定了系统能够与外部世界进行哪些类型的交互。

五、Tool Calling是如何工作的

Agent调用工具通常需要一个重要机制，即Tool Calling或Function Calling。

首先，开发者需要向模型描述工具。

工具描述通常包括工具名称、功能说明、输入参数以及参数类型等信息。

例如，可以定义一个天气查询工具，并告诉模型它的功能是查询某个城市的天气，同时规定输入参数为城市名称。

当用户提出问题后，模型会根据用户目标和工具描述判断是否需要调用这个工具。

如果需要，模型输出相应的工具调用请求，包括工具名称和参数。

真正执行工具的并不是大语言模型，而是外围的Agent程序。

程序接收到模型的工具调用请求之后，调用真实的API或函数，然后将工具返回结果再次提供给模型。

模型再根据结果决定下一步操作。

因此，Tool Calling实际上形成了一条非常重要的链路：用户目标进入Agent，模型决定调用什么工具，程序执行工具，工具返回结果，模型继续处理结果。

这也是现代Agent系统能够与现实世界连接起来的重要基础。

六、为什么工具描述如此重要

在Agent系统中，工具的名称和描述并不是无关紧要的注释。

模型需要根据工具的语义判断“这个工具是否适合当前任务”。

如果工具描述过于模糊，模型可能无法准确理解工具的用途；如果参数定义不清晰，也可能生成错误的参数。

因此，在Agent工程中，Tool Schema设计非常重要。

工具应该具有清晰的名称、准确的功能描述、明确的输入参数以及必要的约束。

与此同时，还应该对工具调用结果进行验证。

不能因为模型选择了某个工具，就假设工具一定被正确调用。

七、Memory：Agent为什么需要记忆

Agent的另一个重要组成部分是Memory，即记忆。

这里的Memory不是简单意义上的计算机内存，而是系统为了未来任务保存和利用的信息。

例如，一个长期运行的个人邮件助手可能需要知道过去处理过哪些邮件、用户有哪些偏好、之前执行过什么任务，以及某些重要的历史信息。

如果每次对话都从零开始，Agent就很难形成连续的任务状态。

因此，Memory可以帮助Agent保留历史信息。

从应用角度看，通常可以区分短期记忆和长期记忆。

• 短期记忆主要与当前任务相关，包括当前对话、近期工具调用以及当前任务状态。
• 长期记忆则用于保存跨会话仍然具有价值的信息，例如用户偏好、历史任务摘要或者经过整理的知识。

八、长上下文并不等于无限记忆

随着大语言模型上下文窗口不断扩大，人们很容易产生一种误解：既然模型可以处理很长的上下文，就不需要Memory了。

事实上，两者并不是一回事。

Context Window描述的是模型一次处理时能够接收的信息规模，而Memory描述的是Agent系统如何保存、组织和在未来检索有价值的信息。

即使上下文窗口非常长，把所有历史信息全部塞入上下文也可能产生问题。

• 首先，输入信息越多，计算成本可能越高。
• 其次，大量无关信息可能干扰模型处理当前任务。
• 再次，历史信息本身可能存在重复、冲突或者过时内容。
• 因此，成熟的Agent系统通常需要进行记忆管理，包括摘要、筛选、结构化存储以及按需检索。

长期记忆可以存储在数据库、文件系统、向量数据库或者其他持久化存储中。

关键并不是“保存所有东西”，而是让系统能够在需要的时候找到真正有价值的信息。

九、Planning：复杂任务为什么需要规划

简单任务可能只需要一次模型调用和一次工具调用。

但复杂任务往往需要多个步骤。

例如，用户要求“帮我安排一次周末旅行”，这个目标至少可能包含交通查询、住宿查询、预算比较和行程规划等多个子任务。

Agent可以先进行Planning，也就是规划，将一个复杂目标拆解成多个子任务。

一种简单的方式是先制定计划，然后逐步执行。

如果某一步失败，Agent可以根据新的信息重新制定计划，而不是机械地按照原来的方案继续执行。

这说明Agent中的Planning并不是一次性生成一份永远不变的计划。

在实际系统中，规划可能是动态的。

随着工具返回新的结果，系统可以重新评估当前状态，并调整下一步行动。

十、ReAct：推理与行动交替进行

公开课重点介绍了ReAct这一经典Agent模式。

ReAct是Reasoning and Acting的缩写，其核心思想是让模型在推理和行动之间交替进行。

简单来说，模型先根据当前信息判断下一步应该做什么，然后执行相应行动，再观察行动结果，之后继续推理。

例如，一个Agent需要回答某个实时信息问题。

它首先判断需要进行网络搜索，然后调用搜索工具；得到搜索结果之后，再根据结果决定是否需要进一步搜索；最终在信息足够之后生成答案。

ReAct的意义在于，它把模型的推理过程和与外部环境的交互结合起来。

不过，需要注意的是，现代Agent并不只有ReAct一种实现方式。实际系统可以采用不同的规划、执行和控制架构，也可以根据任务复杂程度选择不同的Agent Loop。

十一、为什么Agent容易陷入无限循环

Agent最大的优势之一是能够循环执行任务，但这同时也是它的重要风险。

如果系统没有正确判断任务是否完成，或者模型持续认为还需要进一步操作，就可能出现无限循环。

例如，Agent调用工具后得到一个不理想的结果，再次调用；第二次仍然失败，又继续调用。

如果没有停止条件，这个循环理论上可以一直持续。

因此，工程系统必须设置Maximum Steps，即最大执行步数。

除了限制循环次数，还可以设置Token预算、时间预算、工具调用次数或者成本预算。

这些机制可以防止Agent在异常状态下无限消耗计算资源。

十二、模型幻觉与Agent错误需要区别对待

公开课还讨论了一个非常重要的问题：Agent系统中的错误究竟来自哪里？

一种错误可能来自大语言模型本身。

例如模型生成了不存在的事实，这属于模型幻觉问题。

另一种错误则可能来自Agent系统。

例如模型要求调用一个并不存在的工具，或者生成了错误的工具参数；如果Agent程序没有正确验证，就可能导致执行失败。

还有一种情况是工具本身返回了错误数据，但模型错误地相信了这些结果。

因此，Agent系统的故障来源至少包括模型、工具、控制逻辑以及外部环境。

这意味着Debug一个Agent不能只检查Prompt。

需要观察完整执行链路：模型输入是什么、模型产生了什么决策、调用了哪个工具、工具返回了什么、系统如何处理返回结果，以及最终为什么结束或继续循环。

十三、Verification为什么不可缺少

Agent的自主性越强，Verification的重要性就越高。

所谓Verification，就是对系统行动结果进行检查。

例如，Agent执行数据处理任务后，需要确认结果是否符合预期；发送邮件之前，需要检查收件人、主题和正文；修改文件之前，需要确认目标文件是否正确。

验证机制可以来自规则、程序检查、另一个模型、专门的评估器，或者人工审核。

对于高风险任务，仅仅依赖模型自己检查通常是不够的。

因此，企业级Agent往往需要建立多层验证机制。

十四、Human-in-the-Loop：让人在关键节点保持控制

当Agent开始执行现实世界中的操作时，Human-in-the-Loop，即人在回路中，变得非常重要。

并不是所有任务都需要人工审批。

对于低风险、可逆的操作，例如整理信息、生成摘要，可以允许Agent自动完成。

但对于不可逆或者影响较大的操作，例如发送重要邮件、删除文件、修改关键数据库记录、进行金融交易等，就应该根据风险设置人工确认机制。

这种设计的核心思想不是阻止Agent自动化，而是把人工注意力集中到真正重要的决策节点。

因此，Agent系统的自主程度应该与任务风险相匹配。

十五、Agent安全：权限、预算、验证与可观测性

一个生产级Agent必须受到约束。

首先是Budget，也就是预算限制。

系统需要限制Token、API调用、执行时间以及其他资源消耗。

其次是Permission，即权限控制。

Agent不应该拥有超出任务需要的权限。尤其是涉及文件、数据库、企业系统和外部交易时，应遵循最小权限原则。

第三是Verification，即验证。

关键行动需要进行结果检查。

第四是Observability，即可观测性。

系统需要记录Agent运行过程中发生了什么，包括模型请求、模型响应、工具调用、工具返回结果、执行时间、错误信息以及任务最终状态。

没有可观测性，就很难调试复杂Agent。

因此，Agent工程与传统软件工程一样，需要日志、监控、错误处理和系统追踪。

十六、从Single-Agent到Multi-Agent

当任务越来越复杂时，人们开始探索Multi-Agent，即多智能体系统。

Single-Agent可以理解为一个Agent承担整个任务。

Multi-Agent则可以让多个具有不同职责的Agent协作。

例如，可以设计一个负责研究的Agent、一个负责分析的Agent、一个负责执行的Agent和一个负责审核的Agent。

这种架构类似于团队协作。

但Multi-Agent并不天然优于Single-Agent。

如果一个简单任务使用一个Agent就能够稳定完成，那么引入多个Agent可能反而增加系统复杂度、通信成本和故障点。

因此，选择Multi-Agent应该基于任务结构。

当任务本身具有明显的角色分工、模块化结构或者需要多个专业能力时，多Agent架构可能具有价值；如果任务并不复杂，则单Agent通常更加直接。

十七、Agent框架正在快速发展

开发者可以从零开始实现Agent，也可以使用各种框架和SDK。

目前的Agent开发生态包括模型提供商提供的Agent SDK、通用Agent框架、图结构工作流框架以及各种工具和协议。

这些框架通常帮助开发者管理模型调用、工具调用、状态、消息、循环和任务执行。

与此同时，MCP等协议也在推动模型与外部工具和数据源之间形成更加标准化的连接方式。

Skills等机制则可以进一步封装某类能力，让Agent能够按照特定说明使用工具或完成任务。

因此，Agent生态正在从“单个模型API调用”逐渐发展为包括模型、工具、协议、记忆、工作流和多Agent协作在内的完整技术体系。

十八、如何从零开始学习LLM Agent

对于初学者而言，没有必要一开始就学习所有复杂的Agent框架。

• 第一步应该理解大语言模型的基本工作机制，包括Token、上下文、Prompt和模型调用。
• 第二步学习Tool Calling，理解模型如何选择工具以及程序如何真正执行工具。
• 第三步理解Agent Loop，掌握Observation、Reasoning、Action和Verification之间的关系。
• 第四步学习Memory和Planning，理解复杂任务如何保存状态、拆解任务并动态执行。
• 第五步学习Evaluation、Observability和Security。

最后再进一步学习Multi-Agent、MCP、Skills以及更加复杂的Agent架构。

这种学习顺序能够帮助学习者先理解原理，再学习框架，而不是把Agent简单理解成某个软件包的API。

结语：Agent的本质是一个“目标驱动的闭环系统”

LLM Agent并不是一个神秘的“数字人”，也不是简单地给聊天机器人增加几个工具。

从工程角度看，一个Agent是由多个组件共同构成的目标驱动系统。

大语言模型负责理解、生成和一定程度上的推理与决策；工具让系统能够与外部世界交互；Memory帮助系统保存和检索有价值的信息；Planning帮助系统处理复杂任务；Agent Loop则把观察、决策、行动和验证组织成一个持续运行的闭环。

与此同时，Agent的自主性越强，对安全控制的要求也越高。

最大执行步数、Token和成本预算、权限控制、工具验证、可观测性以及Human-in-the-Loop等机制，都是构建可靠Agent的重要组成部分。

从Chatbot到Agent，真正发生变化的并不是“模型突然拥有了人类一样的意识”，而是软件系统开始围绕大语言模型建立更加完整的感知、决策、工具调用和反馈机制。

未来的AI应用，很可能不再只是一个等待用户提问的聊天窗口，而是能够在明确授权和约束条件下，围绕目标执行多步骤任务的软件系统。

因此，理解Agent最重要的并不是记住多少框架名称，而是掌握一个核心思想：

大语言模型提供智能生成与决策能力，工具提供行动能力，Memory提供持续状态，Planning提供任务组织能力，而Agent Loop将这些能力连接成一个可以不断观察、行动、验证和调整的闭环。

这正是LLM Agent区别于传统聊天机器人的关键，也是理解下一阶段AI应用工程的重要基础。

感谢阅读！你还可以订阅我们的YouTube频道，观看大量大数据行业相关公开课：https://www.youtube.com/channel/UCa8NLpvi70mHVsW4J_x9OeQ；在LinkedIn上关注我们，扩展你的人际网络！https://www.linkedin.com/company/dataapplab/。

点击免费看往期公开课回放视频：https://study.dataapplab.com/course?courseid=llm-webinars