如何学习AI Agent？

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

最近因为项目需要，接触到很多llm agent，但是感觉只能看着readme使用，有没有什么较基础的项目或者教程推荐.

可以先学习AI Agent相关理论，再结合应用和实践去理解。下面我从AI Agent的基本概念、原理、组成、应用、实现方法等方面来详细介绍～

AI agent（人工智能代理）是指能够感知环境、做出决策并采取行动以实现特定目标的智能系统。更先进的系统还可以随着时间的推移不断学习并更新行为，不断尝试解决问题的新方法，直到实现目标。

举个例子，自动驾驶汽车就是一种人工智能代理：自动驾驶汽车通过多种传感器感知周围环境，包括其他车辆、行人、交通信号等，并能够根据感知到的信息进行避开障碍物、遵守交通规则等实时决策，最终通过控制系统执行驾驶操作，如加速、减速、转向等。

与GPT 这类“你问我答”的聊天机器人不同，AI agent不需要不断发送带有新指令的提示。一旦我们给 AI agent一个目标来触发它们的行为，它们就会运行。它将使用其处理器来考虑问题，找到解决问题的**方法，然后采取行动。

人工智能代理比传统计算机程序更灵活、更通用，它们能够理解并应对环境：它们不需要依赖固定的编程规则来做出决策，因此它们非常适合处理复杂、不可预测的任务。

主要包含传感器、执行器、处理器和存储器。

传感器：让人工智能代理能够感知周围环境，从而收集感知信息（来自世界的输入：图像、声音、等）。这些传感器可以是摄像头、麦克风或天线等。对于软件类型的人工智能代理来说，它可以是网络搜索功能或阅读PDF文件的工具。

执行器：帮助人工智能代理在现实世界中行动。例如轮子、机械臂或在计算机中创建文件的工具。

处理器、控制系统和决策机制：这三者是代理的“大脑”。它们具有相似的功能，但可能并不都存在于 AI 代理系统中。它们处理来自传感器的信息，集思广益，制定**行动方案，并向执行器发出命令。

学习和知识库系统：学习系统和知识库用于存储帮助 AI 代理完成任务的数据；例如，事实或过去的看法、遇到的困难和找到的解决方案的数据库。

AI agent的组成取决于其具体执行的任务，不一定都囊括上述四个组件。例如，智能恒温器可能没有学习系统，只有基本的传感器、执行器和简单的控制系统。自动驾驶汽车则包含上述所有组件：传感器来观察道路，执行器来移动，决策系统来改变车道，以及一个学习系统来记住历史驾驶数据。

LLM agent指的是大语言模型代理，是人工智能代理的一种。

它由规划（Plan）、工具（Tools）、代理核心（LLM）、存储（Memory）四个部分构成。

规划是指代理分析用户查询、收集相关信息并制定行动策略以提供**建议或解决方案的系统过程。

工具是指代理可以利用来执行特定任务或增强其功能的外部资源、服务或 API。这些工具充当补充组件，将 LLM 代理的功能扩展到其固有的语言生成功能之外。工具还可以包括数据库、知识库和外部模型。

代理核心是LLM代理的基础组件，是一个大语言模型。它也是我们定义代理的目标、使用的工具和相关记忆的地方。

如果你对大语言模型感兴趣，想进一步了解AI Agent和大语言模型的基础、利用AI工具跟紧时代前沿，提升个人生产力和个人收入，推荐体验这门知乎知学堂推出的2节免费的「AI大模型公开课」。课程特邀AI技术大佬为我们讲解大模型的基础，特别是课程中涉及到大模型训练方法和定制化应用的技术细节，能帮助我们更好的理解LLM代理的核心组件，可以重点听一下：

这门视频课程目前是0元，不知道什么时候会开始付费，不要错过啦！

记忆是单个用户或单个任务的上下文和记录细节，可以分为短期记忆和长期记忆。短期记忆充当代理当前行为和想法的动态存储库，类似于其“思路”。它允许代理保持对正在进行的交互的上下文理解，从而实现连贯的通信。长期记忆则包括对话历史记录，保存从过去交流中收集到的宝贵信息；这种积累的知识库帮助代理借鉴过去的经验来丰富其与用户的互动。

Github上的这个列表也搜集了一些AI agent的相关论文，感兴趣的朋友可以去参考看看。

第一位人工智能软件工程师Devin

Devin 可以起草行动计划，了解它需要做什么，确保它拥有完成任务所需的所有资源，然后开始写代码。

例如，Devin 可以学习如何使用不熟悉的技术，在阅读了一篇博客文章后，Devin可以在 Modal 上运行 ControlNet，为 Sara 制作带有隐藏信息的图像；Devin 可以端到端地构建和部署应用程序，比如它制作了一个模拟生命游戏的交互式网站，它逐步添加用户请求的功能，然后将应用程序部署到 Netlify。

这意味着软件工程师失业吗？并不，因为 Devin 的效率只有13.86%。但是，有了这样的助手，经验丰富的程序员可以节省大量时间，非技术人员也可以从零开始开发软件。

VisualGPT

这个工具将ChatGPT 与一系列可视化基础模型链接起来，可以进行对话期间图像的交换。

拥有 25 个 AI 代理的虚拟城镇

斯坦福大学和谷歌使用 OpenAI 的 API 来创建人工智能代理并观察他们的生活方式。

为了支持该实验，该团队创建了一个用于存储记忆的平台，并为每个代理提供目标的基本提示。之后，AI 代理就可以分享信息，记住彼此关系的细节，甚至可以策划情人节派对。

数据收集：收集与LLM 代理将执行的任务相关的数据集。

预处理数据：清理并预处理收集的数据，消除噪音、格式不一致和不相关信息。标记文本数据并准备进行训练。

训练和语言模型：使用机器学习技术，特别是自然语言处理方法，在预处理数据集上训练 LLM。使用深度学习架构（例如 transformer、循环神经网络或卷积神经网络）训练模型。

微调：微调预训练语言模型，使其适应与 LLM 代理相关的特定任务或领域。微调涉及在特定任务的数据上重新训练模型，同时保留预训练期间获得的知识。

组件集成：将核心 LLM 与其他组件（如内存模块、规划模块和工具 API）集成。设计架构以有效地促进这些组件之间的通信和交互。

部署：在生产环境中部署 LLM 代理或将其集成到所需的平台或应用程序中。

学习和改进：不断使用新数据更新和重新训练 LLM 代理，以提高其性能。监控代理的交互并收集反馈，确定需要优化和增强的领域。

上述是一般的实现步骤，而我们实际要开发的时候只需要站在巨人的肩膀上就好了～

可以参考Github上LLM agent的高星项目，也可以学习Function calling、Assistant API、ChatGLM/LLama等基础模型、Langchain的使用方法。如果嫌自己摸索太麻烦，推荐参与上面提到的AI大模型免费公开课快速学习～

人工智能不是未来，而是现在。通过理论结合实践，让我们更好的掌握人工智能代理，拥抱AI时代！

参考文献：

https://zapier.com/blog/ai-agent/

https://www.truefoundry.com/blog/llm-agents

VisualGPT

拥有 25 个 AI 代理的虚拟城镇

https://ai.plainenglish.io/autonomous-ai-agents-agi-cognition-devin-54f12da594c7

我是等壹，上海交大工学硕士，多年机器学习研究，现互联网码农一枚。

既是技术极客，也是文艺青年，希望让人生尽兴、有趣～

我会定期分享人工智能与大数据技术，学习技巧，职场等内容，欢迎关注！

为什么我还是无法理解transformer？程序员如何利用周末提高自己？程序员，上班没事做该怎么办？

要学习AI Agent，我们先看看什么是顶级的AI Agent，取法乎上！

一流大模型的官网或APP，比如ChatGPT官网、豆包等，传说某些官网已经“广告”都植入这个顶级Agent里面了，让你在聊天的过程，引用有价值的（“广告”）内容，这就是有价值Agent顶级AI Agent
各种编程助手，比如github copilot，Claude AI code
Office copilot

如何学习Agent？

第一，【用】，用两种Agent

用顶级的Agent；
用自己项目需要的Agent；

怎么用？有一个比较靠谱的推荐用法，就是每天最少45分钟，使用这些Agent，解决你的工作/项目问题，横向对比不同的Agent，特别是自己的Agent和顶级Agent之间，看看各自回答的优略。

第二，【知】，知是与不是，能与不能

知道Agent是什么，Agent不是什么；
知道Agent可以解决什么问题，Agent不能解决什么问题。

这个问题，目前业界还没有很稳定的答案，看相对权威的定义，再形成自己的思考，可能比看软文和百科来得更有价值。

这里推荐李飞飞老师的论文，《Agent AI: Surveying the Horizons of Multimodal Interaction》。有兴趣啃原文，直接滑到附自取，懒得啃论文的，看看这个图，也是很有价值的了解。介绍这个图的软文成千上万，随便搜索下标题即可。

第三，【做】，打磨自己的Agent

这个开始有点门槛了，但学会了，绝对上一个层级。

可以借助扣子、dify等平台，可以减少很多入门的复杂度；
如果懂编程，可以申请一个openai或Qwen之类的api，自己手撸一个智能体。

温馨提醒，尽量不要看一篇软件，拉一堆自己认真整理以为很有材料的材料，全部使用默认条件，10分钟搭建一个Agent出来，然后不知道有什么用的那种。

要实打实找到一个场景（问题），针对问题设计一个可以解决问题的Agent，并对比和通用的差距，找到改进的方向，不断的改进下去，最少调整几十个版本的那种！

最后一个，【懂】，懂基础原理

神经网络、Transformer等基础原理，这些也不仅仅是看论文搞个略懂，
有能力，最好是自己手撸一个感知机或一个简单的神经网络之类的，完整的学习大模型怎么训练出来。

神经网络推荐这本书《深度学习入门》理论实战结合的很好，入门门槛不算太高，但有深度。（书就不挂文件了，建议自己购买，实在需要电子的，可以留邮箱，私发你推荐链接）搜不到，看附3图片。

Transformer除了官方论文，目前没找到很好的书籍，如果想深入浅出了解基本原理和实战应用，还是需要相对系统的学习、练习和实际使用，看几本书和几篇文章是不够，这个很难一触而就，如果不嫌弃，推荐一个知乎的课程，理论和实战结合的还不错，在附件2，有兴趣自己滑下去找链接。

唯有不断的学和做，搞多几个自己的智能体，就自然有感觉。

附件1 ：近期这篇文章很火，是在解决ai幻觉等核心问题上，提出了Agent的核心解决路径，还有很多深刻的描述，值得一读再读。

Agent AI Surveying the Horizons of Multimodal Interaction.pdf

附件2：该课程在深入浅出地介绍了AI大模型的技术原理的基础上，增加了AI开发的实战内容，对智能体搭建有蛮好的借鉴意义。

没时间看视频也可以点击加微获取一些材料，知乎课程资料整理的还行。最少比一些软文相对系统一点点。

附3:《深度学习入门》

2024年12月20日，发明了 Claude 的 Anthropic 公司发表了一篇博文，对如何构建有效的 LLM Agent 提供了系统性阐述，并深入探讨了各种 Workflow 和 Agent 的实现模式及适用场景。

原始文章内容干货满满，本文就针对该篇博文进行翻译，强烈推荐各位读者查看原始文章——Building effective agents。

文章整体相当长，本文仅包含正文内容，附录相关内容将在下一篇文章列出。

Agent 定义与类型:

Workflow: 预定义的代码路径协调 LLM 和工具。
Agent: LLM 动态指导流程，自主控制任务完成方式。

何时使用 Agent:

优先选择简单方案，仅在需要时增加复杂性。
Workflow 提供一致性，Agent 提供灵活性和决策能力。

常见 Workflow 模式:

提示链: 将任务分解为多个步骤，提高准确性。
路由: 分类输入并定向到不同子任务，提高任务适配性。
并行化: 将任务分解为并行子任务或多次尝试提升性能。
编排器-执行器: 动态分解任务，适合复杂、不可预测的情况。
评估器-优化器: 循环评估和改进，适合明确标准的任务。

Agent 的适用场景:

处理复杂开放问题，难以预测步骤。
提供自主性和扩展性，但需平衡成本和潜在错误。

核心原则:

简单性：从简单设计开始，逐步增加复杂性。
透明性：显式规划 Agent 的流程。
工具设计：完善的文档和接口确保可靠性。

在过去的一年中，我们与各行各业的数十个团队合作构建大型语言模型（LLM）Agent。在所有的合作中，最成功的实现并没有使用复杂的框架或专门的库。相反，他们使用简单、可组合的模式进行构建。

在这篇文章中，我们分享了我们从与客户合作和自己构建 Agent 中学到的经验，并为开发人员提供有关构建有效 Agent 的实用建议。

“Agent” 可以用多种方式定义。一些客户将 Agent 定义为完全自主的系统，可以在较长时间内独立运行，使用各种工具来完成复杂的任务。其他人则使用该术语来描述遵循预定义 Workflow 的更规范的实现。在 Anthropic，我们将所有这些变体都归类为 agentic 系统，但在 Workflow 和 Agent 之间进行了重要的架构区分：

Workflow 是通过预定义的代码路径协调 LLM 和工具的系统。
Agent 是指 LLM 动态指导其自身流程和工具使用，并保持对其完成任务方式控制的系统。

下面，我们将详细探讨这两种类型的 agentic 系统。在附录 1（“实践中的 Agent”）中，我们将介绍客户发现使用这些类型的系统具有特殊价值的两个领域。

当使用 LLM 构建应用程序时，我们建议找到最简单的解决方案，并且仅在需要时才增加复杂性。 这可能意味着根本不需要构建 agentic 系统。 Agentic 系统通常会牺牲实时性和成本以获得更好的任务性能，您应该考虑这种权衡何时有意义。

当需要更高的复杂性时，Workflow 为明确定义的任务提供可预测性和一致性，而当需要在规模上实现灵活性和模型驱动的决策时，Agent 是更好的选择。然而，对于许多应用程序来说，使用检索和上下文示例（in-context examples）来优化单个 LLM 的调用通常就足够了。

有许多框架可以使 agentic 系统更容易实现，包括：

LangChain 的 LangGraph；
Amazon Bedrock 的 AI Agent 框架；
Rivet，一个拖放式 GUI LLM Workflow 构建器；以及
Vellum，另一个用于构建和测试复杂 Workflow 的 GUI 工具。

这些框架通过简化标准底层任务（如调用 LLM、定义和解析工具以及将调用链接在一起）使入门变得容易。然而，它们通常会创建额外的抽象层，这些层会模糊底层的提示和响应，从而使调试更加困难。 它们也可能会让人在更简单的设置就足够的情况下，倾向于添加复杂性。

我们建议开发人员首先直接使用 LLM API：许多模式可以在几行代码中实现。如果您确实使用框架，请确保您了解底层代码。 对底层代码做出不正确的假设是客户错误的常见来源。

请参阅我们的 cookbook，了解一些示例实现。

在本节中，我们将探讨我们在生产中看到的 agentic 系统的常见模式。我们将从我们的基础构建模块——增强的 LLM 开始，并逐步增加复杂性，从简单的组合 Workflow 到自主的 Agent。

agentic 系统的基本模块是通过检索、工具和记忆（memory）等增强功能增强的 LLM。我们目前的模型可以主动使用这些功能：例如生成自己的搜索查询，选择合适的工具，并确定要保留的信息。

我们建议关注实现的两个关键方面：针对您的特定用例定制这些功能，并确保它们为您的 LLM 提供简单、文档完善的接口。虽然有很多方法可以实现这些增强功能，但一种方法是通过我们最近发布的模型上下文协议（Model Context Protocal），该协议允许开发人员通过简单的客户端实现与不断增长的第三方工具生态系统集成。

在本文的其余部分，我们将假设每次 LLM 调用都可以访问这些增强功能。

提示链将任务分解为一系列步骤，其中每个 LLM 调用都会处理上一个调用的输出。您可以在任何中间步骤中添加检查程序（请参阅下图中的“gate”）以确保该过程仍在进行中。

何时使用这类 Workflow：

这类 Workflow 非常适合可以简单地分解为简洁的固定子任务的情况。这么做的主要目标是通过使每个 LLM 调用成为更简单的任务来牺牲响应时间以获得更高的准确性。

适用于提示链的示例：

生成营销文案，然后将其翻译成不同的语言。
编写文档大纲，检查大纲是否符合特定标准，然后根据大纲编写文档。

路由对输入进行分类并将其定向到专门的后续任务。这类 Workflow 更关注于根据不同情况构造更专业的提示链。如果没有这类 Workflow，那对一种输入进行的优化可能会降低对其他输入的性能。

何时使用这类 Workflow：

路由适用于复杂任务，同时复杂任务可以分解为单独处理的不同类别，并且可以通过 LLM 或更传统的分类模型/算法准确地处理分类的情况。

适用于路由的示例：

将不同类型的客户服务查询（一般问题、退款请求、技术支持）定向到不同的下游流程、提示和工具。
将简单/常见的问题路由到较小的模型（如 Claude 3.5 Haiku），将困难/不常见的问题路由到更强大的模型（如 Claude 3.5 Sonnet）以优化成本和速度。

LLM 有时可以同时处理一个任务，并通过编程方式将输出聚合。这类 Workflow（并行化）主要有两种形式：

分解：将任务分解为并行运行的独立子任务。
投票：多次运行同一任务以获得不同的输出。

何时使用这类 Workflow：

当分解的子任务可以并行执行来提升响应速度，或者当需要多个视角或尝试获得更高的置信度结果时，并行化是有效的。对于有许多因素需要考虑的复杂任务，当每个因素由单独的 LLM 调用处理时，LLM 的性能通常会更好，因为每一个单独的 LLM 可以专注于每个特定方面。

并行化的示例：

分解：

实现安全性审查：其中一个模型处理用户查询，而另一个模型判断用户查询是否存在不适当的内容或请求。这往往比让同一个 LLM 调用处理安全性审查和核心响应效果更好。
LLM 性能的自动化评估，其中每个 LLM 调用都会评估模型在给定提示下的不同性能。

投票：

审查一段代码是否存在漏洞，其中多个不同的提示词会审查并标记代码（如果发现问题）。
评估给定的内容是否不适当，其中多个提示词会评估不同的方面或需要不同的投票阈值，以平衡误报和漏报。

在编排器-执行器类型的 Workflow 中，有一个处于中心的 LLM 动态分解任务，并将其分配给其他 LLM 进行执行，并对其结果进行合成。

何时使用这类 Workflow：

这类 Workflow 非常适合于那些无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量以及每个文件中更改的性质可能取决于任务）。虽然编排器-执行器的流程图与上一节并行化的流程图看上去很相似，但这两个 workflow 的关键区别在于编排器-执行器 workflow 的灵活性——子任务不是预定义的，是动态的，具体是由编排器根据特定输入确定的。

编排-执行的示例：

每次都对多个文件进行复杂更改的编码产品。
涉及从多个来源收集和分析信息以获取可能相关信息的搜索任务。

在评估器-优化器 Workflow 中，一个 LLM 生成响应，而另一个 LLM 在一个循环中提供评估和反馈。

何时使用这类 Workflow：

当我们有明确的评估标准，并且当迭代地进行改进可以提供可度量的收益时，这类 Workflow 特别有效。良好拟合的两个标志是，首先，LLM 的响应可以通过人类的详细反馈进行明显改进；其次，LLM 可以提供这种反馈。这类似于人类作者在制作精美文章时可能会经历的一遍又一遍的写作过程。

评估器-优化器的示例：

文学翻译，其中存在 LLM 在最初的翻译时可能无法捕捉到的细微差别，但评估器 LLM 可以提供有用的评论。
复杂的搜索任务，需要多轮搜索和分析才能收集全面的信息，其中评估器决定是否需要进一步搜索。

随着 LLM 在理解复杂输入、参与推理和规划、可靠地使用工具以及从错误中恢复等关键能力方面日趋成熟，Agent 正在生产环境中使用。 Agent 通常从人类的指令或交互开始参与。一旦任务明确，Agent 将独立规划和执行，并可能将结果返回给人类以获取更多的信息或判断。在执行期间，Agent 必须在每个步骤从环境中获得“基本事实”（例如，工具调用结果或代码执行）来评估其过程。 Agent 可以在检查点或遇到障碍时暂停以获取人工反馈。任务中止通常有两种情况：任务完成或者满足了停止条件（例如，最大迭代次数）。

Agent 可以处理复杂的任务，但它们的实现通常很简单。 它们通常是在基于环境反馈的循环中具有工具调用能力的 LLM。因此，清晰完备地设计工具集及其文档至关重要。我们在附录 2（“提示工程你的工具”）中详细介绍了工具开发的**实践。

何时使用 Agent：

Agent 可用于开放性问题，在这种问题中，预测解决问题所需的步骤很难，并且不能给出一个固定路径。 LLM 可能会运行多个回合，您必须对它的决策有一定的信任。 Agent 的自主性使其成为在受信任环境中扩展任务的理想选择。

Agent 的自主性意味着更高的成本，以及更可能犯一些复合性的错误。我们建议在沙盒环境中进行广泛的测试，并使用适当的安全机制。

Agent 的示例：

以下示例来自我们自己的实现：

编码 Agent，用于解决 SWE-bench 任务，这些任务涉及根据任务描述编辑多个文件；
我们的“计算机使用”参考实现，其中 Claude 使用计算机完成任务。

这些构建模块不是规范性的。它们是开发人员可以构造和组合以适应不同用例的常见模式。 与任何 LLM 功能一样，评价性能并进行迭代是成功的关键。重复一遍：只有在它能明显改善结果时，您才应该考虑添加复杂性。

LLM 领域的成功不在于构建最复杂的系统，而在于构建适合您需求的正确系统。 从简单的提示词开始，使用全面的评估对其进行优化，并且仅在更简单的解决方案不能满足需求时再添加多步骤的 agentic 系统。

在实现 Agent 时，我们尝试遵循三个核心原则：

在 Agent 的设计中保持 简单性。
通过显式的、明确的 Agent 的规划步骤来提升 系统的透明度。
通过完备的 工具文档和测试 来精心设计您的 Agent-计算机接口（ACI）。

框架可以帮助您快速入门，但当您转向生产环境时，务必减少抽象层并使用基础组件进行构建。通过遵循这些原则，您可以创建不仅强大而且可靠、可维护并获得用户信任的 Agent。

感谢阅读到这里，如果这篇文章对你有所帮助，欢迎关注【算法工程笔记】公众号！

相关推荐