Agent 开发笔记

原创

已于 2025-05-16 09:57:34 修改 · 置顶 · 944 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#笔记 #Agent

于 2025-04-08 16:23:19 首次发布

Agent 结构

Ai Agent 是基于 LLM 的能够自主理解、自主规划决策、执行复杂任务的智能体。
在这里插入图片描述
规划 Planning + 记忆 Memory + 工具 Tools

规划 Planning

规划：一项复杂任务通常包括多个子步骤，Agent 需要提前将一项任务分解为多个子任务。

子目标与分解（Subgoal and decomposition）：Agent 将复杂任务分解为更小、更易于处理的子目标，从而实现对复杂任务的高效处理。
反思与完善（Reflection and refinement）：Agent 可以对历史的动作进行自我批评和自我反思，从错误中吸取教训，并为未来的步骤进行改进，从而提高最终结果的质量。

实现：通过 prompt engine 来引导 LLM 实现规划（即步骤分解），通过 Prompt 提示词，Prompt 里面包含关于 Tools 的描述，最后 AI Agent 智能体就可以根据模型的输出使用外部 Tools（例如计算器，搜索API，数据库，程序接口，各种模型的API）能使用外部 API 或者知识库。最常见的规划是任务分解 Task Decomposition 与自我反思 Self Reflection。

记忆 Memory

短期记忆（Short-term memory）：所有上下文学习（In-context Learning），都是利用模型的短期记忆来学习。
长期记忆（Long-term memory）：为 Agent 提供长时间保留和回忆信息的能力，这个时候需要借助外部向量存储和快速检索来实现。其实复刻的就是人类的记忆模式。

实现：短期记忆实现上主要利用 Prompt Engineering；长期记忆实现上，主要利用向量数据库。

工具 Tool

Agent 会调用外部提供好的 API，补充 LLM 输出中缺失的额外信息，包括当前状态信息、具体的代码执行能力、访问专有信息源等，都需要借助外部的工具组件。

A2A

MCP 协议

MCP（Model Context Protocol，模型上下文协议）是一种开放协议，旨在实现大型语言模型（LLM）应用与外部数据源、工具和服务之间的无缝集成，类似于网络中的 HTTP 协议或邮件中的 SMTP 协议。

MCP 协议通过标准化模型与外部资源的交互方式，提升 LLM 应用的功能性、灵活性和可扩展性。

在这里插入图片描述

MCP 通过标准化人工智能应用生态系统中的通信规则，为开发者提供了一个统一、高效且可互操作的开发环境。

MCP 的核心设计

MCP 的核心是模型上下文，即 LLM 在运行过程中所需的所有外部信息和工具。

MCP 通过定义标准化的接口和协议，使 LLM 能够动态访问和集成以下内容：

外部数据源：如数据库、API、文档库等，为 LLM 提供实时或历史数据。
工具和服务：如计算工具、搜索引擎、第三方服务等，扩展 LLM 的功能。
上下文管理：动态维护 LLM 的对话上下文，确保连贯性和一致性。

MCP 的核心设计可以用三句话概括：

通过统一的接口和标准化的工具注册机制，实现了 AI 模型与外部工具的无缝连接
采用智能的资源管理和安全的数据传输机制，确保了系统运行的高效和安全
基于上下文感知的智能调度，提供了流畅的用户交互体验和精准的工具调用

在这里插入图片描述

MCP 工作流程

在这里插入图片描述
工作流程说明：

工具发现：MCP Client 获取可用工具列表及其功能描述

查询处理：Client 将工具转换为标准格式并发送给 LLM

{
     
     
    "name":"search_weather",
	"description":"获取指定城市的天气信息",
	"parameters":{
     
     
	    "city":"城市名称",
	    "days":"天数预报（1-7天）"
	}
}

决策分析：LLM 根据用户需求选择合适的工具
工具调用：通过 MCP Server 执行工具调用并获取结果
结果处理：将工具执行结果返回给 LLM 进行分析
响应生成：LLM 生成自然语言响应
结果展示：向用户展示结果并维护对话上下文

MCP 的架构

在这里插入图片描述
总共分为了下面五个部分：

MCP Hosts : Hosts 是指 LLM 启动连接的应用程序，像 Cursor, Claude Desktop、Cline 这样的应用程序。
MCP Clients : 客户端是用来在 Hosts 应用程序内维护与 Server 之间 1:1 连接。
MCP Servers : 通过标准化的协议，为 Client 端提供上下文、工具和提示。
Local Data Sources : 本地的文件、数据库和 API。
Remote Services : 外部的文件、数据库和 API

MCP 的架构由四个关键部分组成：

主机（Host）：主机是期望从服务器获取数据的人工智能应用，例如一个集成开发环境（IDE）、聊天机器人等。主机负责初始化和管理客户端、处理用户授权、管理上下文聚合等。
客户端（Client）：客户端是主机与服务器之间的桥梁。它与服务器保持一对一的连接，负责消息路由、能力管理、协议协商和订阅管理等。客户端确保主机和服务器之间的通信清晰、安全且高效。
服务器（Server）：服务器是提供外部数据和工具的组件。它通过工具、资源和提示模板为大型语言模型提供额外的上下文和功能。例如，一个服务器可以提供与Gmail、Slack等外部服务的API调用。
基础协议（Base Protocol）：基础协议定义了主机、客户端和服务器之间如何通信。它包括消息格式、生命周期管理和传输机制等。

MCP 就像 USB-C 一样，可以让不同设备能够通过相同的接口连接在一起。

在这里插入图片描述

MCP 通信机制

MCP 协议支持两种主要的通信机制：基于标准输入输出的本地通信和基于SSE（Server-Sent Events）的远程通信。

这两种机制都使用 JSON-RPC 2.0 格式进行消息传输，确保了通信的标准化和可扩展性。

本地通信：通过 stdio （基于操作系统标准输入输出的本地进程间通信机制）传输数据，适用于在同一台机器上运行的客户端和服务器之间的通信。
远程通信：利用 SSE 与 HTTP 结合，实现跨网络的实时数据传输，适用于需要访问远程资源或分布式部署的场景。

MCP 的工作原理

MCP 通过定义标准化的数据格式和通信协议，实现 LLM 与外部资源的交互。

MCP 使用 JSON-RPC 2.0 作为消息格式，通过标准的请求、响应和通知消息进行通信。

MCP 支持多种传输机制，包括本地的标准输入/输出（Stdio）和基于 HTTP 的服务器发送事件（SSE）。

MCP的生命周期包括初始化、运行和关闭三个阶段，确保连接的建立、通信和终止都符合协议规范。

以下是其工作流程：

上下文请求
LLM 应用向外部资源发送上下文请求，包含所需的数据或服务类型。
- LLM 应用根据任务需求，向外部资源发送请求。
- 外部资源返回所需的数据或服务结果。
上下文集成

LLM 应用将外部资源返回的上下文数据集成到模型中，用于生成响应或执行任务。
- LLM 应用将外部数据与模型内部知识结合，生成更准确或更丰富的响应。
上下文管理

MCP 支持动态管理 LLM 的对话上下文，确保多轮对话的连贯性。
- 上下文管理器维护对话的历史记录和状态。
- LLM 应用根据上下文生成连贯的响应。

MCP 的应用场景

MCP 广泛应用于以下场景：

增强型问答系统：通过集成外部数据源，提供实时、准确的答案。
智能助手：通过集成工具和服务，执行复杂任务（如预订、计算、搜索等）。
知识管理：通过集成文档库和数据库，提供专业领域的知识支持。
多轮对话：通过上下文管理，实现连贯的多轮对话。

MCP 与 Function Calling 的区别?

类别	MCP (Model Context Protocol)	Function Calling
性质	协议	功能扩展机制
功能范围	通用（支持多数据源、多功能整合）	特定场景（单一数据源或功能）
目标	提供统一接口，实现跨系统互操作	扩展模型的基础能力（如查询、计算）
实现方式	基于标准协议（如REST/GraphQL）	依赖特定模型的API或SDK实现
开发复杂度	低：通过统一协议兼容多源	高：需为每个任务单独开发函数
复用性	高：一次开发可适配多场景	低：函数通常为单一任务设计
灵活性	高：支持动态适配和扩展（如动态加载数据源）	低：功能扩展需修改代码或重新开发
常见场景	复杂场景（如跨平台数据整合、多模型协同）	简单任务（如天气查询、数学计算）

关键差异总结

MCP 是协议层的抽象，解决跨系统协作问题；
Function Calling 是模型能力的扩展，解决单一功能实现问题。

function calling 的流程示意圖：

在这里插入图片描述

“通过 stdio 传输数据”指的是利用操作系统的**标准输入输出（Standard Input/Output，简称 stdio）**作为通信通道，在同一台机器上运行的客户端和服务器之间直接交换数据。具体解析如下：

stdio

1. 什么是 stdio？

• 标准输入（stdin）：程序接收数据的默认通道（如键盘输入或管道输入）。
• 标准输出（stdout）：程序输出结果的默认通道（如打印到终端或重定向到文件）。
• 标准错误（stderr）：输出错误信息的通道。

在本地通信中，客户端和服务器通过 stdin/stdout 直接读写数据，无需网络协议或额外接口。

2. 如何通过 stdio 传输数据？

通信方式：
• 客户端将请求（JSON-RPC 2.0 格式）写入服务器的 stdin。
• 服务器从 stdin 读取请求，处理后将响应写入 stdout，客户端再从 stdout 读取结果。

技术实现：
• 通常通过管道（Pipe）或重定向实现进程间通信。
例如：

 # 客户端通过管道发送数据到服务端
echo '{"jsonrpc":"2.0","method":"example","params":{}}' | server_program

• 编程语言中（如 Python、Node.js）可直接调用子进程并读写其 stdio。

3. 为什么适合本地通信？

• 高效：省去网络序列化/反序列化开销，速度更快。
• 简单：无需配置 IP、端口或协议（如 HTTP）。
• 隔离性：同一机器上的进程间通信，安全性较高。

4. 对比远程通信（SSE）

特性	stdio 本地通信	SSE 远程通信
适用场景	单机进程间通信	跨网络实时数据传输（如浏览器与服务器）
协议依赖	无（直接读写字节流）	依赖 HTTP/SSE 协议
复杂度	低（操作系统原生支持）	高（需处理网络延迟、断连等）
数据格式	均使用 JSON-RPC 2.0 标准化格式