大语言模型（Large Language Model）

大语言模型（LLM）是一种基于****海量文本数据训练、具有超大规模参数****（通常数十亿至万亿级）的人工智能模型，能够理解、生成和推理自然语言。其核心特点是通用性强，可通过预训练学习语言的通用规律，并适配多种下游任务（如问答、翻译、代码生成等）。

**大模型与基础模型（或小模型）的核心差异主要体现在 **规模能力、训练方式、应用场景 等多个维度。以下是系统的对比分析：

1. 参数量与计算规模

本质差异**：**
大模型通过规模效应****（Scaling Laws）获得小模型不具备的涌现能力（如复杂推理、少样本学习）。

2. 能力对比

典型场景**：**

• 大模型：直接生成完整文章、调试代码、解答开放性问题。
• 小模型：垃圾邮件分类、命名实体识别（NER）等确定性问题。

3. 训练与部署成本

案例**：**

• 大模型：ChatGPT 每次查询成本约 <strong><span class="ne-text">$0.01</span></strong>（2023年数据）。
• 小模型：TinyBERT 可在树莓派上实时运行。

4. 技术实现差异

关键区别**：**
大模型的性能提升主要来自数据规模和参数规模****，而小模型依赖****领域特征工程和模型结构优化****。

5. 应用场景对比

RAG（检索增强生成，Retrieval-Augmented Generation）

检索增强生成（RAG）是指对大型语言模型输出进行优化，使其能够在生成响应之前引用训练数据来源之外的权威知识库。大型语言模型（LLM）用海量数据进行训练，使用数十亿个参数为回答问题、翻译语言和完成句子等任务生成原始输出。在 LLM **本就强大的功能基础上，**RAG 将其扩展为能访问特定领域或组织的内部知识库，所有都无需重新训练模型。是一种经济高效地改进 LLM 输出的方法，让它在各种情境下都能保持相关性、准确性和实用性。

简单理解：RAG 就是从外部先检索对应的知识内容，和用户的提问一起构成 Prompt，再让 LLM 生成内容。

• 传统LLM的局限**：**
  大语言模型（如GPT）仅依赖预训练时学到的知识，无法动态获取最新信息，且容易产生“幻觉”（编造虚假内容）。
• RAG的解决方案**：**
  在生成答案前，先从外部知识库（如数据库、文档）中检索相关片段，再结合检索结果生成最终回答。
• 

具体步骤

数据准备与索引构建

目标**：将外部知识库转换为可高效检索的结构化形式。**

• 步骤**：**

1. 收集知识库**：**

• 文本来源：文档、数据库、网页、PDF等。
• 示例：企业FAQ、维基百科、科研论文库。

2. 分块（Chunking）****：

• 将长文本切分为短片段（如每段512字符），适配模型上下文窗口。

3. 向量化（Embedding）****：

• 使用嵌入模型（如OpenAI的<strong><span class="ne-text">text-embedding-3-small</span></strong>）将文本转换为向量。

4. 构建索引**：**

• 存入向量数据库（如FAISS、Milvus、Pinecone）供快速检索。

检索阶段（Retrieval）

目标**：从知识库中查找与用户问题最相关的文本片段。**

• 步骤**：**

1. 用户输入查询（Query）****：

• 示例问题：“量子计算的主要挑战是什么？”

2. 查询向量化**：**

• 用相同的嵌入模型将查询转换为向量。

3. 相似度搜索**：**

• 在向量数据库中搜索与查询向量最相似的文本片段（Top-K，如K=3）

生成阶段（Generation）

目标**：结合检索结果和用户问题，生成最终答案。**

• 步骤**：**

1. 构造提示（Prompt）****：

• 将检索到的文本片段和用户问题拼接为模型输入。

2. 调用大语言模型（LLM）****：

• 输入提示，生成答案。

3. 返回结果**：**

• 输出答案并可附上检索来源（增强可解释性）

Memory（记忆）

**在AI和编程语境中，****Memory（记忆）**指的是系统或程序在不同时间步或交互之间保留和利用历史信息的能力。它是实现连续学习、上下文感知和个性化交互的核心机制。以下从不同维度展开解释：

一、Memory的核心作用

1. 上下文保持

• 使AI系统能理解对话/任务的连续关系（如问答中指代消解："他"指代前文提到的某人）
• 示例：ChatGPT能记住当前对话中用户提到的偏好，避免重复询问

2. 状态持久化

• 在长周期工作流中保存中间状态（如分步骤处理文档时的进度标记）
• 案例：AutoGPT跨会话保存任务执行状态

3. 经验积累

• 通过记忆机制实现持续学习（如推荐系统记住用户历史行为优化下次推荐）

二、技术实现方式

1.** **短期记忆（Short-term Memory）

• 实现技术**：**

  • 对话上下文窗口（如GPT-4的128K tokens缓存）
  • 键值缓存（Transformer的KV Cache加速生成）

• 特点**：**

  • 临时存储，会话结束即消失
  • 低延迟但受限于内存大小

2.** **长期记忆（Long-term Memory）

• 实现技术**：**

  • 向量数据库（如保存历史对话的Chroma/Pinecone）
  • 知识图谱（结构化存储实体关系）
  • 微调模型参数（将信息编码到神经网络权重中）

• 特点**：**

  • 持久化存储，可跨会话调用
  • 检索可能引入延迟

3. 混合记忆架构

# LangChain中的典型记忆实现
from langchain.memory import ConversationBufferMemory, VectorStoreRetrieverMemory

memory = CombinedMemory(
    buffers=ConversationBufferMemory(),  # 短期记忆
    vector_db=VectorStoreRetrieverMemory(retriever=vectorstore.as_retriever())  # 长期记忆
)

三、在AI工作流中的关键应用

1. 多轮对话系统

• 记忆用户偏好（如"我不喜欢恐怖电影"需持久化）
• 避免重复提问（已知用户年龄后不再询问）

2. 复杂任务分解

• RAG流程中保留之前检索到的文档片段
• 编程助手记住已生成代码的函数签名

3. 状态型服务

• 电商客服记录当前订单处理进度
• 游戏NPC记住玩家之前的选择分支

四、不同实现方案的对比

典型案例**：**

• Coze平台使用「Bot记忆」功能自动保存用户属性
• 自建系统可通过Redis+FAISS实现毫秒级记忆检索

五、前沿发展方向

1. 记忆压缩技术

• 将长上下文压缩为摘要向量（如GPT-4 Turbo的上下文压缩）

2. 动态记忆管理

• 基于重要性评分自动遗忘/强化记忆（类似人脑机制）

3. 神经符号结合

• 神经网络处理非结构化记忆 + 符号系统处理规则记忆

4. 边缘记忆

• 在终端设备本地保留敏感记忆（如手机端个性化记忆）

六、实践建议

1. 简单场景**：直接使用平台的记忆功能（如Dify的「会话记忆」开关）**
2. 复杂需求**：**

• 用LangChain的Memory类实现定制逻辑
• 关键数据建议采用双写策略（既存向量库也落关系型数据库）

3. 性能关键型**：**

• 短期记忆用Redis缓存
• 长期记忆采用分层存储（热点数据放内存，冷数据存磁盘）

agent(智能体)

Agent**（智能代理）是一种能够自主感知环境、制定决策并执行动作的智能系统，通常基于大语言模型（LLM）驱动，具备目标导向的任务处理能力。其核心特点是自治性和多步骤推理，能够像人类一样规划、调用工具、迭代优化结果。**

Agent的核心特征

agent和传统ai对话的区别

funciton calling（tool）

Function Call 是一种机制，允许AI模型在生成响应时，调用外部工具或API来获取数据、执行计算或触发操作。这些外部工具可以是数据库查询、API调用、文件操作、其他AI模型等。

作用

• 扩展能力**：AI模型可以通过调用外部工具来扩展其功能，例如访问实时数据、执行复杂计算或调用其他AI模型。**
• 提高准确性**：通过调用外部工具获取最新的数据或执行特定任务，AI模型可以生成更准确、更实用的响应。**
• 动态交互**：Function Call 允许AI模型与外部系统动态交互，而不是仅仅依赖预训练的知识。**

2.** **Function Call 的工作原理

1.** **定义工具

首先，需要定义可以被AI模型调用的工具。这些工具可以是：

• 数据库查询接口
• 外部API（如天气API、新闻API等）
• 文件操作工具
• 其他AI模型

2.** **调用工具

在生成响应的过程中，AI模型可以根据需要调用这些工具。调用时，AI模型会传递必要的参数，并接收工具返回的结果。

3.** **处理结果

AI模型将工具返回的结果整合到最终的响应中，生成更准确、更完整的回答。

3.** **示例

import json
from typing import Optional
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage
from langchain_core.utils.function_calling import convert_to_openai_function

# 1. 定义外部函数（订单生成接口）

def create_order(item: str, quantity: int, receiver: str, address: Optional[str] = None):
    """模拟生成订单的接口"""
    order_id = f"ORDER_{hash(item + receiver) % 1000000}"
    return {
        "status": "success",
        "order_id": order_id,
        "details": {
            "item": item,
            "quantity": quantity,
            "receiver": receiver,
            "address": address or "默认地址"
        }
    }

# 2. 将函数转换为OpenAI格式（用于Function Calling）
order_function = {
    "name": "create_order",
    "description": "生成一个新订单",
    "parameters": {
        "type": "object",
        "properties": {
            "item": {"type": "string", "description": "商品名称"},
            "quantity": {"type": "integer", "description": "购买数量", "default": 1},
            "receiver": {"type": "string", "description": "收货人姓名"},
            "address": {"type": "string", "description": "收货地址（可选）"}
        },
        "required": ["item", "receiver"],
    }
}

# 3. 初始化LangChain的OpenAI模型（支持Function Calling）
model = ChatOpenAI(model="gpt-3.5-turbo", temperature=0).bind(
    functions=[convert_to_openai_function(order_function)],
    function_call={"name": "create_order"}
)

# 4. 用户输入解析 + 函数调用
def process_order_request(user_input: str):
    # Step 1: 让AI解析用户输入并提取参数
    message = HumanMessage(content=user_input)
    ai_response = model.invoke([message])
  
    # Step 2: 检查是否需要调用函数
    if hasattr(ai_response, "additional_kwargs") and "function_call" in ai_response.additional_kwargs:
        function_call = ai_response.additional_kwargs["function_call"]
        if function_call["name"] == "create_order":
            # 提取参数
            args = json.loads(function_call["arguments"])
            print("解析到的参数:", args)
      
            # Step 3: 调用外部函数
            order_result = create_order(**args)
            print("订单生成结果:", order_result)
      
            # Step 4: 将结果返回给用户（可选：让AI总结）
            return f"订单已生成！订单号：{order_result['order_id']}，商品：{args['item']}"
  
    return "未能生成订单，请检查输入格式。"

# 5. 测试示例
if __name__ == "__main__":
    user_input = "我想买一台iPhone 15，收货人是张三，地址是北京市海淀区"
    print(process_order_request(user_input))

mcp

MCP（Model Context Protocol，模型上下文协议）是由Anthropic于2024年11月推出的一种开放标准协议，旨在实现AI模型与外部工具、数据源和API之间的标准化连接。它类似于AI领域的“USB-C”接口，为AI模型提供了一种统一的方式连接各种数据源和工具

MCP 帮助你在 LLM 的基础上构建代理（agents）和复杂的工作流。LLM 经常需要与数据和工具集成，而 MCP 提供了：

• 持续增长的预构建集成列表，LLM 可直接使用
• 灵活切换不同的 LLM 提供商和厂商
• 在你的基础设施内安全地处理数据的最佳实践

通用架构

MCP 核心采用客户端-服务器架构，主机应用可以连接多个服务器：

• MCP Hosts**: 如 Claude Desktop、IDE 或 AI 工具，希望通过 MCP 访问数据的程序**
• MCP Clients**: 维护与服务器一对一连接的协议客户端**
• MCP Servers**: 轻量级程序，通过标准的 Model Context Protocol 提供特定能力**
• 本地数据源**: MCP 服务器可安全访问的计算机文件、数据库和服务**
• 远程服务**: MCP 服务器可连接的互联网上的外部系统（如通过 APIs）**

省流版

mcp协议本质就是将通用的fuction calling 进行一个统一封装(车同轨，书同文)，大大减少了代码编写量，提高了编程效率；

正常fuction calling ,每进行一个函数调用，就要写一个外部函数做为中介，还要额外给每一个外部函数写一个JSON的工具说明，此外还要提供一个提示词模版，才能提高fuction call 的准确度；

因此mcp做了两件事

1.统一Function calling的运行规范

2.统一MCP客户端和服务器的运行规范

例如将查询天气、网页爬去、查询本地数据库这种通用需求，有一个人开发服务器就可以，大家都可以来使用

但复杂业务或者定制化业务，依旧需要自己去实现

a2a（Agent2Agent**）**

A2A 是一个开放协议，旨在促进 AI Agent之间的协作，特别适用于大规模、多智能体系统的部署。其设计原则和功能如下：

设计原则

A2A 基于五个核心原则：

• 拥抱智能体能力****：支持自然、非结构化的协作模式。
• 利用现有标准**：使用 HTTP、**Server-Sent Events (SSE) 和 JSON-RPC，确保与现有系统的兼容性。
• 默认安全**：支持企业级认证和授权，启动时与** OpenAPI 保持一致。
• 支持长期任务**：处理从快速任务到深入研究的任务，提供实时反馈、通知和状态更新。**
• 多模态支持**：支持文本、音频、视频流等多模态通信。**

省流版

mcp解决的是外部工具调用（ai和外部数据交互）的问题，a2a解决的就是agent之间的交互问题，通过这个协议可以更高效地实现****多agent

a2a和mcp对比

A2A 和 MCP 是什么关系？会互相竞争吗？

**谷歌官方的解释非常清晰：**A2A 和 MCP 是互补的，不是竞争关系！

简单来说：

• MCP：用于 Agent 调用“工具”

  • 场景： Agent 需要调用一个天气 API、操作一个数据库、执行一段代码等。这些“工具”的输入输出通常是明确的、结构化的。
  • 作用： 标准化 Agent 和工具之间的“函数调用”。

• A2A：用于 Agent 与 Agent 之间的“协作对话”

  • 场景： 一个 Agent 需要和另一个 Agent 讨论问题、分配任务、传递非结构化信息、进行多轮沟通以完成复杂目标。
  • 作用： 标准化 Agent 之间的“应用层”通信协议，支持更动态、更类似人类的交互。

Agent之间的对话

“汽车修理厂”的比喻：

想象一个 AI 驱动的汽车修理厂。里面有几个“汽修工 Agent”。

• MCP 的用武之地： 当汽修工 Agent 需要使用千斤顶、万用表、扳手 这些工具时，它会通过 MCP 协议来精确地控制这些工具（比如，“千斤顶升高 2 米”，“扳手向右拧 4 毫米”）。这是 Agent 与 结构化工具 的交互。
• A2A 的用武之地：
  • 当客户（可以是真人，也可以是另一个 Agent）来报修时，会对汽修工 Agent 说：“我的车发出嘎啦嘎啦的声音”。这种****自然语言的、非结构化的描述需要通过 A2A 来传递和理解。
  • 在诊断过程中，汽修工 Agent 可能需要和客户来回沟通：“拍张左前轮的照片给我看看”，“我发现有液体泄漏，这种情况多久了？”。这种****多轮对话和动态调整计划的过程，也需要 A2A 支持。
  • 汽修工 Agent 可能还需要联系零件供应商 Agent：“我需要一个型号为 XYZ 的零件，有货吗？” 这也是 Agent 之间的协作，需要 A2A。

总结一下：

• Agent 要用“锤子、钉子”（工具），就用 MCP。
• Agent 要跟“同事、客户、供应商”（其他 Agent 或人）开会、讨论、分配任务，就用 A2A。

一个成熟的 Agent 应用，很可能既需要 MCP (连接工具)，也需要 A2A (连接其他 Agent)。两者相辅相成！

谷歌甚至建议，可以将 A2A Agent 本身（通过它们的 Agent Card）

建模为 MCP 的一种资源。这样，Agent 框架就可以统一地发现和管理可用的“工具”（MCP）和可协作的“伙伴”（A2A）。

无论是a2a mcp fuction call 都是为了更好实现agent的方式