1. AI 代理概述 [0]

thumbnail 本节概述了 AI 代理的构建过程，包括其必要性、规划以及 LangChain 和 LangGraph 等不同编排工具的用途。

1.1. AI 代理的构建与需求 [0]

  1. AI 代理的构建 [0]
    1. 课程继续讲解 AI 代理，上次课程介绍了如何从存储库构建代理，并连接到 Bedrock 上的 LLM（大型语言模型），调用 Nova 模型 [0]。
    2. 还讨论了内存代理，它能存储聊天记录，例如用户提问后，代理会记住并用于后续回复，这些记录通常存储在 Python 列表中，也可以存储在 Redis 或其他向量数据库等内存中 [6]。
  2. AI 代理的需求 [12]
    1. 存在多种编排工具，如 LangChain、LangGraph、CrewAI 和 AutoGen，它们用于在实际场景中开发代理 [12]。
    2. 课程首先探讨了为什么需要代理，如何规划代理，以及代理填补了哪些空白 [14]。

2. LangChain 代理的局限性 [15]

thumbnail 本节详细阐述了 LangChain 代理在状态管理和内存方面的局限性，解释了它为何不适用于复杂的企业级应用。

2.1. LangChain 的工作原理与无状态性 [15]

  1. LangChain 的工作原理 [15]
    1. LangChain 更适合工具调用，以线性方式工作 [15]。
    2. 用户发送输入，输入通过提示模板决定调用哪个 LLM，然后 LLM 返回答案 [17]。
  2. LangChain 的无状态性 [23]
    1. LangChain 就像一个工具包，它不具备代理状态，这意味着它无法记住之前的对话内容 [23]。
    2. 有状态代理会记录输入，而无状态代理则不会 [27]。
    3. LangGraph 可以维护代理状态，但 LangChain 缺乏这种状态管理能力 [32]。

2.2. LangChain 内存管理的挑战 [34]

  1. LangChain 缺乏记忆的示例 [34]
    1. 如果用户问“你好吗？”，代理回答“我很好”，然后用户再问“你呢？”，代理会再次回答“我很好”，因为它不记得之前的对话 [34]。
    2. 同样，如果用户问“你住在哪里？”，代理回答“HYD”，然后用户再问“HYD 是海得拉巴的意思吗？”，代理会忘记之前的上下文，再次询问“HYD 是什么意思？” [41]。
    3. 在订单查询的例子中，用户提供订单 ID 查询状态，然后询问是否可以退款，代理会忘记订单 ID，再次询问，因为它没有维护之前的上下文 [46]。
    4. 每次提问，代理都会以“全新模式”启动，不保留之前的记忆 [52]。
  2. LangChain 内存的局限性 [55]
    1. 尽管可以为 LangChain 添加内存，但存在一些问题 [55]。
    2. LangChain 有三种内存类型：对话缓冲区内存、对话缓冲区窗口内存和摘要缓冲区内存 [58]。
    3. 问题在于，每次对话都会将内容存储在内存中，当用户进行多次交互后，代理在第五次提问时需要加载整个内存，这会变得非常繁重、复杂且昂贵（因为会消耗大量 token） [60]。
    4. 因此，LangChain 的内存管理相当困难 [69]。

2.3. LangChain 与 LangGraph 的适用场景 [70]

  1. LangChain 的适用场景 [70]
    1. 2024 年，LangChain 生态系统建议，如果构建小型聊天机器人或进行概念验证 (POC) 项目，可以使用 LangChain [70]。
  2. LangGraph 的适用场景 [71]
    1. 但如果需要构建更复杂、企业级的应用程序，则应使用 LangGraph [71]。
    2. LangGraph 采用图和节点机制 [72]。

3. LangGraph 代理的优势与工作原理 [73]

thumbnail

本节探讨了 LangGraph 代理如何通过图和节点机制维护代理状态，实现动态路由和多步骤规划，从而解决企业级复杂问题。

3.1. LangGraph 的核心优势 [73]

  1. 状态维护与路由 [73]
    1. LangGraph 能够维护代理状态，并利用节点、图和工具进行调用 [73]。
    2. 它根据用户问题进行路由，并根据需求做出响应，因为每个节点都可以定义特定的逻辑 [79]。
  2. 解决企业级问题 [83]
    1. LangGraph 因其解决企业级问题的能力而闻名，许多人都在其上构建代理，CrewAI 也有类似的能力 [83]。
    2. 在某些情况下，LangGraph 更具优势，而在另一些情况下，CrewAI 更具优势 [85]。

3.2. LangGraph 与 CrewAI 的对比 [86]

  1. LangGraph 的特点 [86]
    1. 使用 LangGraph 需要编写更多代码，但它更适合企业级应用 [87]。
  2. CrewAI 的特点 [89]
    1. CrewAI 需要编写的代码较少，可以构建代理团队 [89]。
    2. 用户可以构建两三个代理，并通过分配任务和角色来指挥它们，这些代理可以相互交流 [91]。

3.3. LangChain 与 LangGraph 的线性与非线性流程 [94]

  1. LangChain 的线性流程 [94]
    1. LangChain 中的代理以线性方式运行，类似于 if-else 条件 [94]。
    2. 它会按顺序执行，例如从 A 到 B，再到 C，然后给出结果 [97]。
  2. LangGraph 的非线性流程 [103]
    1. LangGraph 也可以是线性流程（A 到 B，B 到 C），但它支持条件分支，例如动态路由，这类似于 if-else 逻辑 [240]。
    2. 它还可以实现循环重试模式，即代理会不断尝试直到成功 [245]。
    3. LangGraph 支持多步骤规划，例如可以定义一个规划代理、执行代理、反思代理、验证代理或改进代理等步骤，这些步骤可以一个接一个地执行 [251]。
    4. 在实际应用中，这些工具调用会通过 API 来实现，LangGraph 会以顺序方式处理请求并返回结果 [103]。

4. 构建 LangChain 代理的实践 [111]

thumbnail

本节指导如何从零开始构建 LangChain 代理，包括环境设置、API 密钥配置、模型调用、提示模板的使用以及 LangChain 内存管理的实际问题。

4.1. 环境设置与 API 密钥配置 [111]

  1. LangChain 代理的构建方式 [111]
    1. 可以从头开始构建 LangChain 代理，也可以使用构建块 [111]。
  2. LangChain 文档与安装 [113]
    1. 建议查阅 LangChain 文档进行快速入门，并安装必要的包，例如 pip install langchain [113]。
    2. 还需要连接 OpenAI API 密钥，或者使用 Google Cloud、Open Router、Fireworks、Llama、Ollama、Azure、AWS Bedrock 等其他服务，甚至 Grok API [120]。
  3. 利用现有代码 [126]
    1. 课程将使用 LangChain 提供的现有 SDK 示例代码，并进行修改，而不是从头编写所有代码，因为现有代码已经过验证 [126]。
    2. 代码块包括系统提示和创建工具，这些都可以在 Colab 中进行实践 [132]。
  4. Colab 环境配置 [136]
    1. 在 Colab 中，首先安装 LangChain 和 LangGraph 包 [136]。
    2. 访问 Groq Cloud 创建 API 密钥，这是一个公开可用的 API 密钥，与 Google Gemini 密钥类似，但 Gemini 密钥目前存在配额限制问题，不便于练习 [140]。
    3. 安装 pip install Q LangChain, LangChain Groq, LangGraph，并根据使用的 API（如 Groq 或 OpenAI）进行相应配置 [152]。
    4. 课程使用 Groq API 密钥代替 Google AI Studio API 密钥 [156]。

4.2. 模型调用与提示模板 [159]

  1. 调用 LLM 模型 [159]
    1. 配置好 API 密钥后，可以从 LangChain grok 导入 chat grok 来调用 LLM [159]。
    2. 课程使用 Llama 3.1 8DB 模型，这是一个可通过 Groq API 访问的公共模型，可以设置温度和最大 token 数 [185]。
    3. 在笔记本中开发代理时，建议先创建最小代码并测试其功能，然后再添加其他组件，例如 GitHub、Slack、Kubernetes API 或数据库连接等不同 API 和工具 [189]。
  2. LangChain 提示模板 [205]
    1. LangChain 提示模板用于定义代理的行为方式 [205]。
    2. 可以定义一个聊天提示模板，并设置 LLM 的角色和职责，例如“你是一名高级 DevOps 工程师和 AI Ops 工程师，请用简单的真实世界语言向学生解释主题” [210]。
    3. 这样，无论用户提出什么主题，LLM 都会尝试以这种方式组织答案 [216]。
    4. 代理会首先查看提示，然后根据提示和 LLM 的处理，返回结果 [218]。
    5. 示例中，代理解释了 Kubernetes StatefulSet 和 LangChain 的概念，并以友好的学生口吻进行说明 [223]。

4.3. LangChain 内存问题的实际演示 [229]

  1. LangChain 的内存问题 [229]
    1. LangChain 的问题在于它不维护内存，即使尝试添加内存，也会因为加载整个内存或缓冲区内存而变得困难，导致结果不准确 [229]。
  2. 企业级应用的挑战 [234]
    1. 在企业级客户场景中，这种内存管理方式是不可接受的，因为它无法有效管理对话上下文 [234]。
  3. LangChain 的定位 [237]
    1. LangChain 仅适用于工具调用等简单任务 [237]。

5. 构建 LangGraph 代理的实践 [239]

thumbnail

本节详细介绍了如何构建 LangGraph 代理，包括其状态管理、节点定义、动态路由、多步骤规划以及在实际场景中如何处理工具调用和错误。

5.1. LangGraph 的工作方式与高级功能 [239]

  1. LangGraph 的线性与非线性流程 [239]
    1. LangGraph 也可以是线性流程（A 到 B，B 到 C），但它支持条件分支，例如动态路由，这类似于 if-else 逻辑 [239]。
  2. 循环重试模式 [245]
    1. 它还可以实现循环重试模式，即代理会不断尝试直到成功 [245]。
  3. 多步骤规划 [251]
    1. LangGraph 支持多步骤规划，例如可以定义一个规划代理、执行代理、反思代理、验证代理或改进代理等步骤，这些步骤可以一个接一个地执行 [251]。

5.2. LangGraph 代理的状态管理与节点定义 [261]

  1. LangGraph 的状态管理 [261]
    1. 在 LangGraph 中，需要导入相关模块，并定义一个类来维护代理状态，例如 Agent is type dict [261]。
  2. 理解问题函数 [266]
    1. 定义一个 understand_the_question 函数，它接收代理状态和用户问题 [266]。
    2. 该函数会根据问题内容进行分类，例如如果问题包含“payment”，则返回“payment pod”；如果包含“user”，则返回“user pod”；如果包含“order”，则返回“order pod”；如果包含“inventory”，则返回“inventory pod”；否则返回“unknown” [269]。
  3. 工具节点与 RCA 节点 [275]
    1. 定义一个工具节点，它接收代理状态，并检查 pod 状态，返回 pod 名称（例如“user pod”、“order pod”、“payment pod”） [275]。
    2. 定义一个 RCA（根本原因分析）节点，它接收一个提示，例如“你是一名在生产环境中工作的 AIOps 工程师”，并根据检测到的 pod 名称、Kubernetes 工具结果和状态给出答案 [280]。

5.3. LangGraph 代理的实际运行与调试 [287]

  1. 运行 LangGraph 代理 [287]
    1. 运行 LangGraph 代理的代码非常简单，可以在 LangGraph 文档中找到示例并进行修改 [287]。
    2. 视频中展示了如何从 LangGraph 文档中找到快速入门示例，包括定义工具、模型和调用它们 [303]。
  2. 处理未定义函数错误 [347]
    1. 在运行示例时，遇到了 check_pod_status 函数未定义的错误，因为该函数在工具节点中被调用，但没有实际定义 [347]。
    2. 为了解决这个问题，需要添加一个工具函数，例如 fake_pod_status，并定义一些模拟数据，例如“payment running”、“failed user pod”、“inventory” [379]。
  3. 测试 LangGraph 代理 [398]
    1. 修复错误后，再次运行代理，并询问“订单 pod 怎么了？”，代理会回答“订单 pod 不可用，这意味着它正在运行” [398]。
    2. 询问“支付 pod 怎么了？”，代理会回答“支付 pod 失败，导致检测到未知 pod”，并给出根本原因分析和修复建议 [402]。
    3. 进一步修改 fake_pod_status 函数，添加更具体的错误信息，例如“crash loop back off”或“database connection failed” [420]。
    4. 再次运行代理，并询问“支付 pod 怎么了？”，代理会给出更详细的答案，例如“支付 pod 在集群中遇到 crash loop back off 问题，这意味着它持续崩溃和重启，很可能是数据库连接失败” [432]。
    5. 询问“订单 pod 怎么了？”，代理会回答“订单 pod 正在运行，根据 Kubernetes 结果没有发现问题” [438]。
    6. 这表明 LangGraph 代理能够检查状态并返回结果，从而在代理图中实现多步骤的返回 [445]。

6. AI 代理在企业级应用中的部署与实践 [446]

thumbnail

本节讨论了 AI 代理在企业级应用中的部署策略，强调了数据科学团队与 MLOps/AIOps 工程师之间的协作，以及如何将代理代码转化为可扩展、可靠的生产环境解决方案。

6.1. 电子商务数据库与代理连接 [446]

  1. 电子商务数据库示例 [446]
    1. 课程以一个电子商务公司为例，该公司拥有一个数据库，其中包含数据 [446]。
  2. 代理与数据库的连接 [453]
    1. 代理连接到该数据库，并定义了工作流和步骤 [453]。
  3. 用户与代理的交互 [459]
    1. 用户向代理提问关于订单的问题，代理会连接数据库，获取信息并返回响应，这是一种直接与代理交互的方式，不涉及前端或后端 [459]。

6.2. 数据科学团队与 MLOps/AIOps 工程师的职责划分 [468]

  1. 数据科学团队的职责 [468]
    1. 数据科学团队主要负责研究和开发，例如构建深度学习模型、编写代码并在笔记本中执行 [468]。
    2. 他们可能会负责构建存储库，但不会提供部署、配置 CI/CD 流水线或管理基础设施的计划 [469]。
  2. MLOps/AIOps 工程师的职责 [475]
    1. MLOps/AIOps 工程师需要接管后续工作，构建所有部署和基础设施 [475]。
    2. 他们需要与数据科学团队协调，确保在基础设施中运行的代码能够提供正确的推断和预期输出 [477]。
    3. 日志记录、监控等所有工作都由 MLOps/AIOps 工程师负责 [479]。
  3. 协作与技术选型 [482]
    1. 数据科学团队擅长开发和研究，他们可能会建议使用 Pinecone DB 或 Redis DB 等向量数据库 [482]。
    2. MLOps/AIOps 工程师的职责是部署和配置这些数据库，例如使用 Milvus，创建 Helm Chart，部署到 Kubernetes，获取端点并连接 [488]。
    3. 数据科学团队可能会提供代理代码，MLOps/AIOps 工程师需要编写脚本、Lambda 函数，并将其部署到 Flask API 或 AWS App Runner 等服务中，并配置 API Gateway 和路由 [492]。
  4. 可扩展性和可靠性 [497]
    1. MLOps/AIOps 工程师的工作主要是确保数据科学团队或 AI 工程师开发的一切都具有可扩展性和可靠性 [497]。

6.3. MLOps/AIOps 工程师的角色扩展 [504]

  1. 开发者的角色 [504]
    1. MLOps/AIOps 工程师有时也会参与开发工作，例如开发代理或 RAG（检索增强生成）应用 [504]。
  2. 平台工程师的角色 [510]
    1. 在某些情况下，他们也扮演平台工程师的角色，具体取决于环境和职责 [510]。
    2. 始终需要与数据科学团队协调 [519]。

7. LangChain 与 LangGraph 代理的部署模式 [520]

thumbnail

本节详细介绍了 LangChain 和 LangGraph 代理的部署模式，从基础的 Bedrock 调用到复杂的工具调用，再到 LangGraph 的状态管理和动态路由，并通过实际代码演示了其在电子商务场景中的应用。

7.1. Bedrock 与 LangChain 的基础调用 [520]

  1. Bedrock 的基本调用 [520]
    1. 第一个实验是使用 boto3 调用 Bedrock，输入提示，然后获取 LLM 的文本输出 [520]。
    2. 环境变量（如 AWS_ACCESS_KEY 和 AWS_SECRET_KEY）从 .env 文件加载，用户需要替换自己的密钥并在本地运行 [526]。
  2. LangChain 与 Bedrock 的工具调用 [538]
    1. 第二个实验是 LangChain 与 Bedrock 的工具调用，LangChain LLM 会根据输入决定调用哪个工具 [538]。
    2. 这种模式类似于 ReAct（Reasoning and Acting）模式 [543]。

7.2. LangChain 代理的工具定义与交互 [546]

  1. 工具的定义 [546]
    1. 示例代码中定义了多个工具，例如 lookup_orders（根据订单 ID 获取订单信息）、check_stock（检查产品库存）、get_policy（获取政策）、initiate_return（发起退货）和 list_customer_orders（列出客户订单） [546]。
    2. 这些工具在实际中会通过 API 调用和查询来获取数据 [562]。
  2. LLM 与工具的绑定 [565]
    1. 通过将 LLM（从 .env 文件获取模型 ID 和区域）与所有工具绑定，实现工具映射 [565]。
    2. 系统消息定义了代理的角色和可访问的工具，例如“你是一个友好的客户支持代理 Shop Easy，你可以访问 lookup、check stock、handle returns、policies 等工具” [571]。
  3. 交互式循环管理器 [576]
    1. 代理使用交互式循环管理器（ReAct 模式）进行交互 [576]。
    2. 运行代码前，需要安装 requirement.txt 中的依赖，并激活虚拟环境 [578]。
  4. 模拟数据库与交互演示 [593]
    1. 示例中使用了 fake_db.py 文件作为模拟电子商务数据库，其中包含客户、订单和产品数据，以及退货政策 [593]。
    2. 辅助函数模拟 API 调用，从后端获取数据 [623]。
    3. 演示了代理如何回答“网络摄像头有库存吗？”（回答有 60 台，价格多少）和“我的订单在哪里？”（提供订单详情、追踪 ID 和预计送达时间）等问题 [627]。
    4. 当用户询问“我想退货”时，代理会要求提供订单 ID，即使之前已经提供了订单 ID，这再次证明了 LangChain 缺乏记忆 [645]。
    5. 即使尝试添加内存，LangChain 也会面临昂贵和复杂的问题，因此不适用于客户级别的生产环境 [656]。

7.3. LangGraph 代理的动态行为与状态管理 [661]

  1. LangGraph 的优势 [661]
    1. LangGraph 能够以动态方式处理问题，解决 LangChain 的内存、路由和升级问题 [661]。
    2. LangGraph 具有完整的对话历史记录，可以处理意图并进行路由，检测挫败感并升级问题 [666]。
    3. 它是有状态的，可以跟踪意图、客户和消息，将问题和 LLM 响应一起传递给下一个步骤，从而在图、节点和边之间保持上下文 [671]。
  2. LangGraph 代码结构 [680]
    1. LangGraph 代码通过分类客户意图（订单、退货、产品、升级）来处理问题，然后使用工具和 LLM 生成响应 [680]。
    2. 代码导入了与 LangChain 类似的工具（如 check_out_product_stack、get_customer_orders），并从 .env 文件加载环境变量 [684]。
    3. 定义了一个类来维护代理状态 [700]。
  3. 图节点与意图分类 [710]
    1. LangGraph 的第一个图节点是 classify_the_intent，它根据代理状态中的消息内容对客户意图进行分类，例如“订单状态”、“退货”、“产品”、“升级”或“通用” [710]。
    2. LLM 会根据这些分类的意图来处理问题 [730]。
    3. handle_with_tools 节点根据分类的意图，使用工具并生成响应，例如“你是一个友好的客户支持代理 Shopee Easy，客户意图是 [意图]” [732]。
    4. handle_escalation 节点处理情绪（如愤怒、沮丧的客户）并给出相应的消息 [739]。
  4. LangGraph 的路由逻辑 [740]
    1. LangGraph 的路由是基于意图进行的，例如“分类意图” -> “处理升级” -> “结束”，否则“处理工具” [740]。
  5. LangGraph 交互演示 [748]
    1. 演示了 LangGraph 代理的交互，例如询问“CG01 客户有哪些产品？”，代理会总结客户的订单产品 [748]。
    2. 询问“客户 C001 是否订购了网络摄像头？”，代理会检查订单并告知客户没有订购网络摄像头 [756]。
    3. 当用户表示“我想退货”时，代理会识别出客户想退货网络摄像头，但客户没有订购，因此建议客户购买或退回其他订单 [761]。
    4. 当用户提供订单 ID 并询问“可以退货吗？”时，代理会检查订单状态，如果订单已发货但未送达，则无法发起退货，并告知客户需要等待送达 [770]。
    5. 询问“退货政策是什么？”，代理会提供退货政策 [782]。
    6. 这表明 LangGraph 代理能够像真实的客服代理一样处理复杂的对话，并在生产环境中部署，通过 API 或 MCP 连接到电子商务数据库，处理库存、用户资料等信息 [783]。

7.4. LangGraph 与 CrewAI 的多代理对比 [787]

  1. LangGraph 的单代理流程 [787]
    1. LangGraph 代理定义了节点和图的流程，例如“如果这是函数，去这里；如果不是，去那里”，通过循环和重试机制实现 [787]。
  2. CrewAI 的多代理团队 [802]
    1. 如果需要多个代理（例如三四个代理），可以使用 CrewAI，它支持代理间对话，例如验证代理、执行代理等 [802]。
  3. LangGraph 的多代理实现 [806]
    1. LangGraph 也可以通过主管代理来管理其他进程，实现多代理功能 [806]。
    2. 最终目标是根据问题陈述进行规划、开发、部署并展示结果 [810]。

8. AI 代理的生产部署最佳实践 [811]

thumbnail

本节详细介绍了 AI 代理在生产环境中的部署最佳实践，包括前后端分离、使用 Fast API 和 Streamlit 构建应用、Docker 化部署、AWS App Runner 的使用以及如何通过分步作业和 ChatGPT 辅助完成部署任务。

8.1. 前后端分离与安全部署 [811]

  1. 前后端分离的必要性 [811]
    1. 在生产环境中，不应将代理直接部署到前端，因为前端容易受到攻击，可能导致 LLM 凭证和代码泄露，造成跨站脚本攻击或注入攻击 [811]。
    2. 这种直接部署方式存在风险 [819]。
  2. 后端部署与 API 连接 [821]
    1. 最佳实践是首先开发后端，然后通过 Fast API 将后端与代理连接 [821]。
    2. 前端请求会先到达后端，再由后端与代理交互 [826]。
  3. 身份验证与会话管理 [829]
    1. 后端可以定义身份验证方法（例如 Bearer Token、Session ID 或 JWT Token） [829]。
    2. 当用户创建会话时，会生成一个 Session ID，用于后续对话，确保每个用户都能获得个性化响应 [834]。

8.2. Docker 化部署与 AWS App Runner [837]

  1. Fast API 与 Streamlit 的应用 [837]
    1. 第四个实验是构建一个后端（使用 Fast API）和前端（使用 Streamlit） [837]。
    2. Streamlit 前端代码可以通过 ChatGPT 生成，但后端代码需要仔细迭代 [844]。
  2. 代理代码的模块化 [847]
    1. 代理代码应模块化为 agent.py、state.py 和 tools.py 等文件 [847]。
    2. 在后端，Dockerfile 会从这些文件构建 Docker 镜像，然后推送到 ECR（Elastic Container Registry）进行部署 [852]。
    3. agent.py 包含代理的核心代码（与实验三相同），state.py 包含状态管理代码，tools.py 包含所有工具定义 [855]。
    4. 这种模块化方式有助于在多个代理之间共享文件，避免重复编写代码 [861]。
  3. Docker Compose 本地部署 [864]
    1. 可以使用 Docker Compose 在本地构建后端和前端，并运行容器 [864]。
  4. Postman 测试与会话管理 [873]
    1. 使用 Postman 测试 Fast API 后端，发送 POST 请求到 localhost:8000/chat [873]。
    2. 当询问“我的订单 ID 在哪里？”时，代理会返回订单信息和会话 ID [886]。
    3. 在后续对话中（例如“我可以退货吗？”），必须包含会话 ID，否则代理会将其视为新对话，并再次询问订单 ID [897]。
    4. 包含会话 ID 后，代理会根据之前的上下文（例如订单 ID）给出准确的退货政策，这展示了会话管理如何存储内存并提供结果 [911]。
  5. AWS App Runner 部署 [938]
    1. AWS App Runner 是一种全托管服务，允许开发者快速部署容器化应用程序和 API，无需管理服务器或基础设施 [938]。
    2. 只需创建 Docker 镜像并部署，它会提供一个端点 URL [950]。
    3. 可以将该 URL 放入 CDN（内容分发网络），例如 AWS CloudFront，并设置访问限制 [953]。

8.3. 部署作业与学习方法 [958]

  1. AWS 云部署作业 [958]
    1. 建议的作业是尝试在 AWS 云中部署代理：
      1. 创建 ECR 存储库 [961]。
      2. 从本地笔记本进行身份验证 [963]。
      3. 从实验四文件夹中的存储库构建 Docker 镜像 [966]。
      4. 将 Docker 镜像推送到 ECR 存储库 [969]。
      5. 在 AWS 中创建 App Runner [972]。
      6. 将 Docker 镜像部署到 App Runner [975]。
      7. 获取 App Runner 提供的 URL [978]。
      8. 在 Postman 中使用该 URL 进行聊天 [981]。
    2. 可以使用 ChatGPT 查找 AWS CLI 命令来完成这些步骤 [990]。
  2. 学习与开发方法 [997]
    1. 讲师分享了他的学习和开发方法：
      1. 明确思考，并清晰地写下想法 [997]。
      2. 查阅文档，学习相关知识 [1001]。
      3. 使用 ChatGPT 生成命令或代码块，然后进行复制粘贴 [1004]。
      4. 运行代码，如果遇到错误，先尝试自行解决，如果无法解决，再次寻求 LLM 的帮助 [1014]。
      5. 将所有步骤和代码块组合起来，并使用 Markdown 文件进行美化 [1019]。
    2. 建议学生也采用这种方法来完成作业和项目 [1023]。
    3. 鼓励学生积极练习，以便后续课程可以深入探讨多代理 CrewAI、MCP、内存管理、Bedrock 原生功能、AI Foundry 和 Google GCP 的 ADK 等高级主题，并最终构建一个包含前端、后端、数据库和 API/MCP 连接的实时实验室 [1056]。