企业官网建设流程全解析

参考：Agent设计模式——第 6 章：规划-腾讯云开发者社区-腾讯云

规划的核心是 Agent 或 Agent 系统制定一系列行动以从初始状态向目标状态移动的能力
在 AI 的背景下，将规划 Agent 视为您委托复杂目标的专家是有帮助的。当您要求它"组织团队外出活动"时，您定义的是"什么"——目标及其约束——而不是"如何"。Agent 的核心任务是自主规划实现该目标的路线。它必须首先理解初始状态（例如，预算、参与者人数、期望日期）和目标状态（成功预订的外出活动），然后发现连接它们的最佳行动序列。
Agent 的真正力量在于其整合新信息并引导项目绕过障碍的能力。
动态规划是一个特定的工具，而不是通用解决方案。当问题的解决方案已经被充分理解且可重复时，将 Agent 限制为预定的固定工作流更有效。这种方法限制 Agent 的自主性以减少不确定性和不可预测行为的风险，保证可靠和一致的结果。
因此，使用规划 Agent 与简单任务执行 Agent 的决定取决于一个问题：是否需要发现"如何"，还是已经知道？
规划模式是自主系统中的核心计算过程，使 Agent 能够综合一系列行动以实现指定目标，特别是在动态或复杂环境中。这个过程将高级目标转换为由离散可执行步骤组成的结构化计划。
规划模式通过让 Agent 系统首先创建一个连贯的计划来解决目标提供了标准化解决方案。它涉及将高级目标分解为一系列更小的可操作步骤或子目标。这允许系统管理复杂的工作流、编排各种工具并以逻辑顺序处理依赖关系。
这种结构化方法将简单的反应性 Agent 转变为战略执行者，可以主动朝着复杂目标工作，甚至在必要时调整其计划。

参考：Agent设计模式——第 7 章：多 Agent 协作-腾讯云开发者社区-腾讯云

多 Agent 协作模式通过将系统构建为由不同专门化 Agent 组成的协作集合来解决这些限制。这种方法基于任务分解原则，其中高级目标被分解为离散的子问题。然后将每个子问题分配给拥有最适合该任务的特定工具、数据访问或推理能力的 Agent。

例如，一个复杂的研究查询可能被分解并分配给研究 Agent 进行信息检索、数据分析 Agent 进行统计处理，以及综合 Agent 生成最终报告。这种系统的效能不仅仅源于劳动分工，而是关键依赖于 Agent 间通信的机制。这需要标准化的通信协议和共享本体，允许 Agent 交换数据、委托子任务并协调其行动以确保最终输出的连贯性。

多 Agent 协作模式概述

多 Agent 协作模式涉及设计系统，其中多个独立或半独立的 Agent 协同工作以实现共同目标。每个 Agent 通常具有定义的角色、与总体目标一致的特定目标，并且可能访问不同的工具或知识库。

协作可以采取各种形式：

• 顺序交接：一个 Agent 完成任务并将其输出传递给另一个 Agent 以进行管道中的下一步（类似于规划模式，但明确涉及不同的 Agent）。
• 并行处理：多个 Agent 同时处理问题的不同部分，然后它们的结果稍后被组合。
• 辩论和共识：多 Agent 协作，其中具有不同观点和信息来源的 Agent 进行讨论以评估选项，最终达成共识或更明智的决策。
• 层次结构：管理者 Agent 可能根据其工具访问或插件能力动态地将任务委托给工作 Agent，并综合其结果。每个 Agent 还可以处理相关的工具组，而不是单个 Agent 处理所有工具。
• 专家团队：在不同领域具有专业知识的 Agent（例如，研究员、作家、编辑）协作产生复杂输出。
• 批评者-审查者：Agent 创建初始输出，如计划、草稿或答案。第二组 Agent 然后批判性地评估此输出是否符合政策、安全性、合规性、正确性、质量以及与组织目标的一致性。原始创建者或最终 Agent 根据此反馈修订输出。此模式对于代码生成、研究写作、逻辑检查和确保道德一致性特别有效。这种方法的优势包括增强的稳健性、改进的质量以及减少幻觉或错误的可能性。

多 Agent 系统（见图 1）从根本上包括 Agent 角色和职责的界定、Agent 通过其交换信息的通信渠道的建立，以及指导其协作努力的任务流或交互协议的制定。

多 Agent 协作是一种适用于众多领域的强大模式：

• 复杂研究和分析：一组 Agent 可以协作完成研究项目。一个 Agent 可能专门搜索学术数据库，另一个总结发现，第三个识别趋势，第四个将信息综合成报告。这反映了人类研究团队可能如何运作。
• 软件开发：想象 Agent 协作构建软件。一个 Agent 可以是需求分析师，另一个是代码生成器，第三个是测试员，第四个是文档编写者。他们可以在彼此之间传递输出以构建和验证组件。
• 创意内容生成：创建营销活动可能涉及市场研究 Agent、文案撰写 Agent、图形设计 Agent（使用图像生成工具）和社交媒体调度 Agent，所有这些都在一起工作。
• 财务分析：多 Agent 系统可以分析金融市场。Agent 可能专门获取股票数据、分析新闻情绪、执行技术分析和生成投资建议。
• 客户支持升级：前线支持 Agent 可以处理初始查询，在需要时将复杂问题升级给专家 Agent（例如，技术专家或计费专家），展示基于问题复杂性的顺序交接。
• 供应链优化：Agent 可以代表供应链中的不同节点（供应商、制造商、分销商）并协作优化库存水平、物流和调度以响应需求变化或中断。
• 网络分析与修复：自主操作从 Agent 架构中受益匪浅，特别是在故障定位方面。多个 Agent 可以协作分类和修复问题，建议最佳行动。这些 Agent 还可以与传统机器学习模型和工具集成，利用现有系统，同时提供生成式 AI 的优势。

多 Agent 协作：探索相互关系和通信结构

3. 监督者：在"监督者"模型中，专用 Agent（"监督者"）监督和协调一组下属 Agent 的活动。监督者充当通信、任务分配和冲突解决的中心枢纽。这种层次结构提供了清晰的权限线，可以简化管理和控制。然而，它引入了单点故障（监督者），如果监督者被大量下属或复杂任务压倒，可能会成为瓶颈。

4. 监督者作为工具：此模型是"监督者"概念的细微扩展，其中监督者的角色不太关乎直接命令和控制，而更多关乎向其他 Agent 提供资源、指导或分析支持。监督者可能提供工具、数据或计算服务，使其他 Agent 能够更有效地执行其任务，而不必规定其每一个行动。这种方法旨在利用监督者的能力，而不施加严格的自上而下控制。

5. 层次化："层次化"模型扩展了监督者概念，创建了多层组织结构。这涉及多个监督者级别，高级监督者监督低级监督者，最终在最低层有一组操作 Agent。此结构非常适合可分解为子问题的复杂问题，每个子问题由层次结构的特定层管理。它提供了一种结构化的可扩展性和复杂性管理方法，允许在定义的边界内进行分布式决策。

6. 自定义："自定义"模型代表了多 Agent 系统设计的终极灵活性。它允许创建根据给定问题或应用程序的特定要求精确定制的独特相互关系和通信结构。这可能涉及结合前述模型元素的混合方法，或从环境的独特约束和机会中产生的全新设计。自定义模型通常源于需要针对特定性能指标进行优化、处理高度动态的环境或将特定领域知识纳入系统架构。设计和实现自定义模型通常需要对多 Agent 系统原理有深入理解，并仔细考虑通信协议、协调机制和涌现行为。

多 Agent 协作模式通过创建多个协作 Agent 的系统提供了标准化解决方案。复杂问题被分解为更小的更易于管理的子问题。然后将每个子问题分配给具有解决它所需的精确工具和能力的专门 Agent。这些 Agent 通过定义的通信协议和交互模型（如顺序交接、并行工作流或层次化委托）协同工作。这种 Agent 化的分布式方法创造了协同效应，使团队能够实现任何单个 Agent 都无法实现的结果。

关键要点

• 多 Agent 协作涉及多个 Agent 协同工作以实现共同目标。
• 此模式利用专业角色、分布式任务和 Agent 间通信。
• 协作可以采取顺序交接、并行处理、辩论或层次结构等形式。
• 此模式非常适合需要多样化专业知识或多个不同阶段的复杂问题。

参考：Agent设计模式——第 8 章：内存管理-腾讯云开发者社区-腾讯云

本章深入探讨内存管理，特别关注 Agent 的即时（短期）和持久（长期）内存需求。

在 Agent 系统中，内存指代 Agent 保留并利用过去交互、观察和学习经验中信息的能力。这种能力使 Agent 能够做出明智决策、维护对话上下文并随时间持续改进。Agent 内存通常分为两大主要类型：

短期内存（上下文内存）
类似于工作记忆，保存当前处理或最近访问的信息。短期内存主要存在于上下文窗口中。该窗口包含最近消息、Agent 回复、工具使用结果以及当前交互中的 Agent 反思，所有这些都为 LLM 的后续响应和操作提供信息支撑。高效的短期内存管理涉及在有限空间内保留最相关信息，可能通过总结旧对话片段或突出关键细节等技术实现。具有"长上下文"窗口的模型出现仅扩展了这种短期内存的容量，允许单次交互中保存更多信息。因此，Agent 需要独立的内存类型来实现真正持久性、从过往交互中调用信息并建立持久知识库。

长期内存（持久内存）

作为 Agent 跨各种交互、任务或延长期间所需信息的存储库，类似于长期知识库。数据通常存储在 Agent 即时处理环境之外，常见于数据库、知识图谱或向量数据库中。在向量数据库中，信息被转换为数字向量存储，使 Agent 能够基于语义相似性而非精确关键字匹配检索数据，此过程称为语义搜索。当 Agent 需要长期内存中的信息时，会查询外部存储、检索相关数据并将其集成到短期上下文中供即时使用，从而将先前知识与当前交互结合。

• 面向任务的 Agent：管理多步骤任务的 Agent 需要短期内存跟踪先前步骤、当前进度和总体目标。此类信息可能驻留于任务上下文或临时存储中。长期内存对于访问不在即时上下文中的特定用户相关数据至关重要
• 个性化体验：提供定制交互的 Agent 利用长期内存存储和检索用户偏好、过往行为和个人信息。这使 Agent 能调整其响应和建议
• 信息检索（RAG）：设计用于回答问题的 Agent 访问知识库（即其长期内存），通常在检索增强生成（RAG）中实现。Agent 检索相关文档或数据以指导其响应

Google Agent Developer Kit（ADK）提供了结构化的上下文和内存管理方法，包含实际应用组件。深入理解 ADK 的 Session、State 和 Memory 对于构建需要保留信息的 Agent 至关重要。

ADK 通过三个核心概念及其关联服务简化了上下文管理。

与 Agent 的每次交互均可视为独特对话线程。Agent 可能需要访问早期交互数据。ADK 将其结构化如下：

• Session（会话）：独立聊天线程，记录该特定交互的消息和操作（Events），同时存储与该对话相关的临时数据（State）
• State（状态）（session.state）：存储在 Session 中的数据，包含仅与当前活动聊天线程相关的信息
• Memory（内存）：来自各种过往聊天或外部来源信息的可搜索存储库，作为超出即时对话范围的数据检索资源

ADK 为构建复杂、有状态和上下文感知 Agent 所需的关键组件提供专用服务。SessionService 通过处理 Session 对象的启动、记录和终止来管理聊天线程，而 MemoryService 监督长期知识（Memory）的存储和检索

Session：跟踪每次聊天

ADK 中的 Session 对象旨在跟踪和管理单个聊天线程。在与 Agent 开始对话时，SessionService 生成一个 Session 对象，表示为google.adk.sessions.Session。此对象封装了与特定对话线程相关的所有数据，包括唯一标识符（id、appname、userid）、作为 Event 对象的事件的时间顺序记录、用于会话特定临时数据的存储区域（称为 state）以及指示最后更新的时间戳（lastupdatetime）。开发人员通常通过 SessionService 间接与 Session 对象交互。SessionService 负责管理对话会话的生命周期，包括启动新会话、恢复先前的会话、记录会话活动（包括状态更新）、识别活动会话以及管理会话数据的删除。

每次消息交换都涉及一个循环过程：接收消息，Runner 使用 SessionService 检索或建立 Session，Agent 使用 Session 的上下文（状态和历史交互）处理消息，Agent 生成响应并可能更新状态，Runner 将其封装为 Event，sessionservice.appendevent 方法记录新事件并更新存储中的状态。理想情况下，当交互结束时使用 delete_session 方法终止会话。

State：Session 的草稿本

每个代表聊天线程的 Session 都包含 state 组件，类似于 Agent 在特定对话期间的临时工作记忆。

虽然 session.events 记录整个聊天历史，但 session.state 存储和更新与活动聊天相关的动态数据点。从根本上讲，session.state 作为字典运行，以键值对形式存储数据。其核心功能是使 Agent 能够保留和管理对连贯对话至关重要的详细信息，如用户偏好、任务进度、增量数据收集或影响后续 Agent 操作的条件标志

状态结构包含字符串键与可序列化 Python 类型值的配对，包括字符串、数字、布尔值、列表及包含这些基本类型的字典。State 是动态的，在整个对话过程中不断演变。

可使用键前缀定义数据范围和持久性来组织状态。无前缀的键是会话特定的

• user: 前缀将数据与跨所有会话的用户 ID 关联
• app: 前缀指定应用程序所有用户间共享的数据
• temp: 前缀指示仅对当前处理轮次有效且不持久存储的数据

Agent 通过单个 session.state 字典访问所有状态数据。SessionService 处理数据检索、合并和持久性。应在通过 sessionservice.appendevent() 向会话历史添加 Event 时更新状态。这确保了准确跟踪、在持久服务中的正确保存以及状态更改的安全处理

Memory：使用 MemoryService 的长期知识

在 Agent 系统中，Session 组件维护当前聊天历史（events）和特定于单个对话的临时数据（state）的记录。然而，为使 Agent 在多次交互中保留信息或访问外部数据，需要长期知识管理。这由 MemoryService 促进实现

Session 和 State 可概念化为单个聊天会话的短期内存，而由 MemoryService 管理的长期知识则充当持久且可搜索的存储库。此存储库可能包含来自多个过往交互或外部来源的信息。

LangChain 和 LangGraph 中的内存管理

短期内存：这是线程范围的，意味着它跟踪单个会话或线程内正在进行的对话。它提供即时上下文，但完整历史可能挑战 LLM 的上下文窗口，导致错误或性能下降。LangGraph 将短期内存作为 Agent 状态的一部分管理，该状态通过检查点器持久化，允许随时恢复线程

长期内存：存储跨会话的用户特定或应用级数据，在对话线程间共享。它保存在自定义"命名空间"中，可在任何线程的任何时间调用。LangGraph 提供存储来保存和调用长期记忆，使 Agent 能无限期保留知识

长期内存类型：长期内存允许系统在不同对话中保留信息，提供更深层次上下文和个性化。可分解为类似人类记忆的三种类型：

• 语义记忆：记住事实涉及保留特定事实和概念，如用户偏好或领域知识。用于基础 Agent 的响应，带来更个性化和相关的交互。此信息可作为持续更新的用户"配置文件"（JSON 文档）或作为单个事实文档的"集合"管理
• 情景记忆：记住经历涉及回忆过去事件或行动。对于 AI Agent，情景记忆通常用于记住如何完成任务。实践中常通过少样本示例提示实现，Agent 从过去成功交互序列中学习以正确执行任务
• 程序记忆：记住规则关于如何执行任务的记忆——Agent 的核心指令和行为，通常包含在其系统提示中。Agent 修改自身提示以适应和改进很常见。有效技术是"反思"，其中 Agent 被提示其当前指令和最近交互，然后被要求改进自身指令

标准化解决方案是实现区分短期和长期存储的双组件内存系统。短期的上下文内存在 LLM 的上下文窗口内保存最近交互数据以维护对话流程。对于必须持久的信息，长期内存解决方案使用外部数据库（通常是向量存储）实现高效语义检索。

像 Google ADK 这样的 Agent 框架提供特定组件来管理此过程，如用于对话线程的 Session 和用于其临时数据的 State。专用的 MemoryService 用于与长期知识库交互，允许 Agent 检索相关的过去信息并将其纳入当前上下文

关键要点

快速回顾内存管理的核心要点：

• 内存对于 Agent 跟踪事物、学习和个性化交互至关重要
• 对话式 AI 依赖单个聊天中即时上下文的短期内存和跨多个会话持久知识的长期内存
• 短期内存（即时信息）是临时的，通常受 LLM 上下文窗口或框架传递上下文方式的限制
• 长期内存（持久信息）使用向量数据库等外部存储跨不同聊天保存信息，并通过搜索访问
• 像 ADK 这样的框架具有特定部分，如 Session（聊天线程）、State（临时聊天数据）和 MemoryService（可搜索的长期知识）来管理内存
• ADK 的 SessionService 处理聊天会话的整个生命周期，包括其历史（events）和临时数据（state）
• ADK 的 session.state 是临时聊天数据的字典。前缀（user:、app:、temp:）指示数据归属位置及是否持久
• 在 ADK 中，应通过在添加事件时使用 EventActions.statedelta 或 outputkey 更新状态，而非直接更改状态字典
• ADK 的 MemoryService 用于将信息放入长期存储并让 Agent 搜索，通常使用工具
• LangChain 提供如 ConversationBufferMemory 的实用工具，自动将单个对话历史注入提示，使 Agent 能回忆即时上下文
• LangGraph 通过使用存储来保存和检索跨不同用户会话的语义事实、情景经验甚至可更新程序规则，实现高级长期内存
• Memory Bank 是托管服务，通过自动提取、存储和调用用户特定信息为 Agent 提供持久长期内存，在 Google 的 ADK、LangGraph 和 CrewAI 等框架中实现个性化持续对话

参考：Agent设计模式——第 9 章：学习和适应-腾讯云开发者社区-腾讯云

• 强化学习：Agent 尝试不同的行动，对积极结果获得奖励，对消极结果受到惩罚，从而在动态环境中学习最优行为。适用于控制机器人或玩游戏的 Agent。
• 监督学习：Agent 从标注示例中学习，建立输入与期望输出之间的映射关系，实现决策制定和模式识别等任务。适用于分类电子邮件或预测趋势的 Agent。
• 无监督学习：Agent 在未标注数据中发现隐藏的连接和模式，有助于获得洞察、进行组织并构建其环境的心理地图。适用于在没有特定指导的情况下探索数据的 Agent。
• 基于LLM的 Agent 的少样本/零样本学习：利用大语言模型的 Agent 能够用最少的示例或清晰的指令快速适应新任务，实现对新命令或情况的快速响应。
• 在线学习：Agent 持续使用新数据更新知识，对于动态环境中的实时响应和持续适应至关重要。适用于处理连续数据流的 Agent。
• 基于内存的学习：Agent 回忆过去的经验以在类似情况下调整当前行动，增强上下文感知和决策能力。对于具备记忆召回能力的 Agent 特别有效。

近端策略优化（PPO）是一种强化学习算法，用于在具有连续动作范围的环境中训练 Agent，例如控制机器人的关节或游戏中的角色。其主要目标是可靠且稳定地改进 Agent 的决策策略（即策略，policy）。

PPO 的核心思想是对 Agent 的策略进行小幅而谨慎的更新，避免可能导致性能崩溃的剧烈变化。其工作原理如下：

1. 收集数据：Agent 使用其当前策略与环境交互（例如，玩游戏）并收集一批经验数据（状态、动作、奖励）。
2. 评估代理目标：PPO 计算潜在策略更新将如何改变预期奖励。然而，它不仅仅是最大化这个奖励，而是使用特殊的"裁剪"目标函数。
3. 裁剪机制：这是 PPO 稳定性的关键。它在当前策略周围创建一个"信任区域"或安全区，阻止算法进行与当前策略差异过大的更新。这种裁剪机制就像一个安全刹车，确保 Agent 不会采取巨大而有风险的步骤来破坏其学习成果。

直接偏好优化（DPO）是一种专门为使大语言模型与人类偏好保持一致而设计的更新方法。它为此任务提供了比使用 PPO 更简单、更直接的替代方案。

• PPO 方法（两步过程）：

1. 训练奖励模型：首先收集人类反馈数据，人们在其中评级或比较不同的 LLM 响应（例如，"响应 A 比响应 B 更好"）。这些数据用于训练一个独立的 AI 模型，称为奖励模型，其任务是预测人类会给任何新响应打什么分数。
2. 使用 PPO 微调：接下来使用 PPO 微调 LLM。LLM 的目标是生成能够从奖励模型获得最高分的响应。奖励模型在训练过程中充当"评判员"。

这个两步过程可能既复杂又不稳定。例如，LLM 可能会找到漏洞并学会"破解"奖励模型，为质量较差的响应获得高分。

• DPO 方法（直接过程）：DPO 完全跳过了奖励模型。它不是将人类偏好转换为奖励分数然后优化该分数，而是直接使用偏好数据来更新 LLM 的策略。
• 它通过利用直接将偏好数据与最优策略联系起来的数学关系来工作。本质上，它教导模型："增加生成类似偏好响应的概率，减少生成类似不受欢迎响应的概率。"

本质上，DPO 通过直接在人类偏好数据上优化语言模型来简化对齐过程。

标准化解决方案是集成学习和适应机制，将静态 Agent 转变为动态的、演化的系统。这使 Agent 能够基于新数据和交互自主改进其知识和行为。Agent 系统可以使用各种方法，从强化学习到更高级的技术，如自我改进编码 Agent（SICA）中看到的自我修改。像 Google 的 AlphaEvolve 这样的高级系统利用 LLM 和进化算法来发现全新的、更高效的复杂问题解决方案。通过持续学习，Agent 可以掌握新任务、增强其性能并适应变化的条件，而无需持续的手动重新编程。

关键要点

• 学习和适应是 Agent 通过使用其经验来改进其行为并处理新情况的过程。
• "适应"是来自学习的 Agent 行为或知识的可见变化。
• SICA（自我改进编码 Agent）通过基于过去性能修改其代码来自我改进。这导致了像智能编辑器和 AST 符号定位器这样的工具。
• 拥有专门的"子 Agent"和"监督者"有助于这些自我改进系统管理大任务并保持正轨。
• LLM 的"上下文窗口"的设置方式（包括系统提示词、核心提示词和助手消息）对 Agent 的工作效率至关重要。
• 此模式对于需要在始终变化、不确定或需要个性化交互的环境中运行的 Agent 至关重要。
• 构建学习 Agent 通常意味着将它们与机器学习工具连接并管理数据流。
• 配备基本编码工具的 Agent 系统可以自主编辑自身，从而提高其在基准任务上的性能。
• AlphaEvolve 是 Google 的 AI Agent，利用 LLM 和进化框架自主发现和优化算法，显著增强基础研究和实际计算应用。

参考：Agent设计模式——第 10 章：模型上下文协议 (MCP)-腾讯云开发者社区-腾讯云

MCP 模式概述

想象一个通用适配器，允许任何 LLM 连接到任何外部系统、数据库或工具，无需为每个连接进行自定义集成。这本质上就是模型上下文协议（MCP）的功能。它是一个开放标准，旨在标准化 Gemini、OpenAI 的 GPT 模型、Mixtral 和 Claude 等 LLM 与外部应用程序、数据源和工具的通信方式。可将其视为通用连接机制，简化 LLM 获取上下文、执行操作以及与各类系统交互的方式。

MCP 基于客户端-服务器架构运行。它定义了不同元素——数据（称为资源）、交互模板（本质是提示）和可操作函数（称为工具）——如何由 MCP 服务器公开。

MCP 可包装输入或输出对 Agent 仍非固有可理解的 API。仅当 API 数据格式对 Agent 友好时才有用，而 MCP 本身无法保证此点。例如，为返回 PDF 文件的文档存储创建 MCP 服务器基本无用，若消费 Agent 无法解析 PDF 内容。更好方法是首先创建返回文档文本版本（如 Markdown）的 API，使 Agent 能实际阅读和处理。这表明开发人员必须考虑的不只是连接，还有所交换数据的性质，以确保真正兼容性。

MCP 与工具函数调用

模型上下文协议（MCP）和工具函数调用是使 LLM 能与外部能力（含工具）交互并执行操作的不同机制。

工具函数调用可视为 LLM 对特定预定义工具或函数的直接请求。

模型上下文协议（MCP）作为 LLM 发现、通信和使用外部能力的标准化接口运行。它作为开放协议促进与各种工具和系统交互，旨在建立任何兼容工具可被任何兼容 LLM 访问的生态系统。

这促进了不同系统和实现间的互操作性、可组合性和可重用性。通过采用联合模型，我们显著提升互操作性并释放现有资产价值。此策略允许我们通过简单包装符合 MCP 接口将分散和遗留服务引入现代生态系统。这些服务继续独立运行，但现可组合到新应用程序和工作流中，其协作由 LLM 协调。这促进了敏捷性和可重用性，而无需对基础系统进行昂贵重写。

MCP 与工具函数调用的基本区别：

| 特性 | 工具函数调用 | 模型上下文协议（MCP） |

| ----- | ----- | ----- |

|标准化| 专有和供应商特定。格式和实现在不同 LLM 提供商间各异 | 开放标准化协议，促进不同 LLM 和工具间互操作性 |

|范围| LLM 请求执行特定预定义函数的直接机制 | 更广泛框架，定义 LLM 和外部工具如何相互发现和通信 |

|架构| LLM 与应用程序工具处理逻辑间的一对一交互 | 客户端-服务器架构，LLM 驱动应用程序（客户端）可连接并使用各种 MCP 服务器（工具） |

|发现| LLM 被明确告知特定对话上下文中哪些工具可用 | 支持动态发现可用工具。MCP 客户端可查询服务器以查看其提供能力 |

|可重用性| 工具集成通常与所用特定应用程序和 LLM 紧密耦合 | 促进开发可重用独立"MCP 服务器"，可被任何兼容应用程序访问 |

MCP 的其他考虑因素

虽然 MCP 提供了强大框架，但全面评估需考虑影响其适用性的几个关键方面。让我们详细探讨某些方面：

• 工具 vs. 资源 vs. 提示：理解这些组件的特定角色很重要。资源是静态数据（如 PDF 文件、数据库记录）。工具是执行操作的可执行函数（如发送电子邮件、查询 API）。提示是指导 LLM 如何与资源或工具交互的模板，确保交互结构化和有效
• 可发现性：MCP 的关键优势是 MCP 客户端可动态查询服务器了解其提供的工具和资源。这种"即时"发现机制对需要适应新能力而无需重新部署的 Agent 非常强大
• 安全性：通过任何协议公开工具和数据都需要强大安全措施。MCP 实现必须包含身份验证和授权，以控制哪些客户端可访问哪些服务器及允许执行哪些特定操作
• 实现：虽然 MCP 是开放标准，但其实现可能复杂。然而提供商正开始简化此过程。例如 Anthropic 或 FastMCP 等模型提供商提供 SDK，抽象大部分样板代码，使开发人员更易创建和连接 MCP 客户端和服务器
• 错误处理：全面错误处理策略至关重要。协议必须定义如何将错误（如工具执行失败、服务器不可用、无效请求）传达回 LLM，使其能理解失败并可能尝试替代方法
• 本地 vs. 远程服务器：MCP 服务器可部署在与 Agent 相同机器本地，或远程部署在不同服务器。本地服务器可能因速度和敏感数据安全性被选择，而远程服务器架构允许组织内共享可扩展访问公共工具
• 按需 vs. 批处理：MCP 可支持按需交互式会话和大规模批处理。选择取决于应用程序，从需要立即工具访问的实时对话 Agent 到批量处理记录的数据分析管道
• 传输机制：协议还定义通信的底层传输层。对本地交互，使用基于 STDIO（标准输入/输出）的 JSON-RPC 实现高效进程间通信。对远程连接，利用 Web 友好协议如可流式 HTTP 和服务器发送事件（SSE）实现持久高效客户端-服务器通信

模型上下文协议使用客户端-服务器模型标准化信息流。理解组件交互是 MCP 高级 Agent 行为关键：

1. 大型语言模型（LLM）：核心智能。处理用户请求，制定计划，决定何时需要访问外部信息或执行操作
2. MCP 客户端：围绕 LLM 的应用程序或包装器。充当中介，将 LLM 意图转换为符合 MCP 标准的正式请求。负责发现、连接和与 MCP 服务器通信
3. MCP 服务器：通往外部世界的网关。向任何授权 MCP 客户端公开一组工具、资源和提示。每个服务器通常负责特定领域，如连接公司内部数据库、电子邮件服务或公共 API
4. 可选的第三方（3P）服务：代表 MCP 服务器管理和公开的实际外部工具、应用程序或数据源。是执行请求操作的最终端点，如查询专有数据库、与 SaaS 平台交互或调用公共天气 API

交互流程如下：

1. 发现：MCP 客户端代表 LLM 查询 MCP 服务器询问其提供能力。服务器响应清单列出可用工具（如 sendemail）、资源（如 customerdatabase）和提示
2. 请求制定：LLM 确定需要使用发现的工具之一。例如决定发送电子邮件。制定请求指定要使用的工具（send_email）和必要参数（收件人、主题、正文）
3. 客户端通信：MCP 客户端获取 LLM 制定的请求，将其作为标准化调用发送到适当 MCP 服务器
4. 服务器执行：MCP 服务器接收请求。对客户端进行身份验证，验证请求，然后通过与底层软件交互执行指定操作（如调用电子邮件 API 的 send() 函数）
5. 响应和上下文更新：执行后，MCP 服务器将标准化响应发送回 MCP 客户端。此响应指示操作是否成功，包括任何相关输出（如已发送电子邮件的确认 ID）。然后客户端将此结果传递回 LLM，更新其上下文并使其能继续任务的下一步

实际应用和用例

MCP 显著扩展了 AI/LLM 能力，使其更加多功能强大。以下是九个关键用例：

数据库集成：MCP 允许 LLM 和 Agent 无缝访问数据库中结构化数据并与之交互。

生成媒体编排：MCP 使 Agent 能与高级生成媒体服务集成。

外部 API 交互：MCP 为 LLM 提供调用任何外部 API 并接收响应的标准化方式。

基于推理的信息提取：利用 LLM 强大推理能力，MCP 促进有效的依赖查询信息提取，超越传统搜索和检索系统。

自定义工具开发：开发人员可构建自定义工具并通过 MCP 服务器公开（如使用 FastMCP）。

标准化的 LLM 到应用程序通信：MCP 确保 LLM 与它们交互的应用程序间有一致通信层。

复杂工作流编排：通过组合各种 MCP 公开工具和数据源，Agent 可编排高度复杂多步骤工作流。

物联网设备控制：MCP 可促进 LLM 与物联网（IoT）设备交互。

金融服务自动化：在金融服务中，MCP 可使 LLM 与各种金融数据源、交易平台或合规系统交互。

模型上下文协议（MCP）通过充当 LLM 和外部系统间通用接口提供标准化解决方案。它建立开放标准化协议，定义如何发现和使用外部能力。基于客户端-服务器模型运行，MCP 允许服务器向任何兼容客户端公开工具、数据资源和交互式提示。LLM 驱动应用程序充当这些客户端，以可预测方式动态发现和与可用资源交互。这种标准化方法促进了可互操作和可重用组件生态系统，显著简化复杂 Agent 工作流开发

关键要点

以下是本章核心要点：

• 模型上下文协议（MCP）是开放标准，促进 LLM 与外部应用程序、数据源和工具间标准化通信
• 它采用客户端-服务器架构，定义公开和使用资源、提示和工具的方法
• Agent 开发工具包（ADK）支持使用现有 MCP 服务器以及通过 MCP 服务器公开 ADK 工具
• FastMCP 简化了 MCP 服务器开发和管理，特别用于公开在 Python 中实现的工具
• 生成媒体服务的 MCP 工具允许 Agent 与 Google Cloud 的生成媒体能力（Imagen、Veo、Chirp 3 HD、Lyria）集成
• MCP 使 LLM 和 Agent 能与现实世界系统交互，访问动态信息，并执行超越文本生成的操作