人工智能 文章

人工智能

2025-12-01 • 0k

AI Agent 工具调用：Function Call、MCP 与 A2A 技术演进

导读 如果你曾经尝试过让大模型（LLM）帮你查天气、订机票或操作数据库，你多半已经接触过"Function Call"技术。但你是否真正理解它的底层逻辑？当听到 MCP 和 A2A 这些新概念时，你是否感到困惑？ 本文将带你深入理解 AI Agent 工具调用的核心技术，从最基础的 Function Call 原理讲起，逐步演进到 LangChain 框架的封装，最后解析 MCP 和 A2A 这两项前沿协议。读完本文，你将不仅理解“如何调用”，更能看清“调用什么”和“谁来调用”的全貌。 一、Function Call: 最容易被误解的技术 1.1 一个常见的认知误区 很多人认为 Function Call 就是"大模型自己去调用工具"。这个说法只对了一半。 大模型本身并不执行任何代码，它只负责"决策"——输出一个结构化的指令。真正的"调用"动作，必须由你的应用程序 (宿主代码) 来完成。 这个认知偏差源于 OpenAI 等官方 SDK 封装得过于"丝滑",让开发者误以为一次 API 调用就完成了所有事情。实际上，在那些看似简单的 API 背后，隐藏着严格分离的职责边界。 1.2 Function Call 的完整四步流程 为了清晰理解，我们把一次完整的 Function Call 拆解为四个标准步骤: 第一步：注册工具 你将工具的名称、功能描述以及参数结构（JSON Schema）放入系统提示词或 API 的 tools 参数中。这相当于告诉大模型:“我有这些工具可用，它们各自做什么，需要什么参数。” 第二步：大模型决策 收到用户问题后，大模型不会直接回答。如果它判断需要借助工具，就会输出一个结构化的 JSON 对象，其中明确包含 tool_name(工具名) 和 parameters(参数值)。 第三步：宿主代码执行 这是最关键的一步。你的后端代码监听到大模型输出的 JSON 后，通过 if 判断或 switch 结构，由你的代码去真正执行对应的函数。大模型全程没有执行任何代码，它只是给出了指令。

Function Call LangChain MCP

阅读更多

人工智能

2025-11-07 • 0k

C# AI Agent 选型与框架推荐 - 2025最新指南

以下是 当前主流的开源 C# AI Agent 框架 / 项目（按成熟度、活跃度排序），涵盖通用 Agent 框架、垂直场景 Agent 实现，以及基于 C# 生态（.NET 6+）的轻量化方案，方便开发者直接复用或二次开发： 一、通用型开源 C# AI Agent 框架（核心推荐） 这类框架提供 Agent 的核心能力（任务规划、工具调用、记忆管理、多轮对话），支持对接主流大模型（OpenAI、本地 LLaMA/Phi 等），灵活性强。 1. Semantic Kernel（微软官方） 核心定位：.NET 生态首选的开源 AI Agent 开发框架（微软主导，跨语言支持 C#/Python/Java），专注于「将 AI 能力与传统代码、工具链融合」。 关键特性： 内置 Agent 生命周期管理（规划、执行、记忆、工具调用）； 支持函数调用（工具注册）、向量数据库集成（记忆存储）、多轮对话上下文管理； 无缝对接 OpenAI、Azure OpenAI、本地大模型（通过 Ollama、LM Studio 适配）； 丰富的插件生态（文件操作、HTTP 请求、数据库访问等现成工具）。 开源地址：https://github.com/microsoft/semantic-kernel 技术栈：.NET 6+（C# 10+），支持 Windows/macOS/Linux

AI Agent C#

阅读更多

人工智能

2025-10-06 • 0k

LangGraph记忆避坑指南：自动管理为什么还不够？

使用LangGraph开发多轮对话应用时，很多人都会疑惑： LangGraph已经提供了Checkpointer，为什么真实项目还要自己保存聊天记录、截取最近几轮，再手动传给大模型？ 答案是：保存状态、管理上下文、让模型正确理解历史，是三件不同的事。 LangGraph能帮助我们保存和恢复状态，但它不知道哪些历史对当前任务有用，也不会自动完成问题改写、长期存储和业务数据管理。 一、大模型本身没有记忆 调用大模型API时，每次请求都是独立的。 第一轮发送： [{"role": "user", "content": "我叫小明"}] 第二轮如果只发送： [{"role": "user", "content": "我叫什么名字？"}] 模型无法知道答案。要让它回答“小明”，应用必须在第二次调用时重新提供第一轮对话。 所以，聊天记忆的本质是： 应用保存过去的信息，并在后续调用时重新提供给模型。 模型不是自然地“回忆”起来，而是重新阅读了上下文。 二、LangGraph自动记忆做了什么 典型写法如下： from langgraph.checkpoint.memory import InMemorySaver from langgraph.graph import MessagesState, StateGraph builder = StateGraph(MessagesState) graph = builder.compile(checkpointer=InMemorySaver()) 调用时提供固定的会话标识： config = { "configurable": { "thread_id": "session-001" } } 它主要完成三件事： 根据thread_id找到对应会话； 在图运行前恢复上一次保存的状态； 将本轮消息合并进去，并保存新状态。 MessagesState已经为messages配置了消息合并规则，因此标准聊天场景不需要反复手写： history.append(user_message) history.append(assistant_message) 但要注意： Checkpointer自动保存的是“图状态”，不是业务意义上的完整记忆。 即使状态中保存了100条消息，如果节点调用模型时只传当前问题： llm.invoke([current_question]) 模型仍然看不到历史。历史必须真正进入模型输入才会生效。 三、为什么真实项目仍要手动管理 普通聊天机器人可以直接把消息列表交给模型，但真实应用通常还有意图识别、知识库检索、SQL生成、工具调用和多智能体协作。 1. 不同节点需要不同的上下文 假设用户连续提问：

LangGraph 记忆管理 Checkpointer

阅读更多

人工智能

2025-08-12 • 0k

LangChain 与 LangGraph 实战指南

LangChain 和 LangGraph 是两个强大的人工智能开发框架。 一、为什么需要 LangGraph？ LangChain 虽然提供了丰富的工具链和 Agent 能力，但在实际企业级应用中面临一些挑战: 复杂状态管理困难: 传统 Chain 难以维护跨多个步骤的状态 循环流程不支持: 无法自然表达人类交互中的"重试 - 修正"过程 调试复杂度高: 执行流不透明，问题定位困难 长期任务控制弱: 缺乏对执行流的精确干预能力 LangGraph 通过图结构解决了这些问题，让你能够构建可预测、可控的智能体系统。 二、核心概念：图 vs 链 2.1 语言模型的三种执行模式 # 1. Prompt → LLM (最基础) response = llm(prompt) # 2. Chain (串行流程) # question -> retriever -> prompt -> LLM -> answer # 3. Graph (图结构) # 节点之间可以有任意连接关系（包括循环） 2.2 关键术语 Node: 计算单元，如 retrieval_node、llm_node、tool_node Edge: 节点之间的连接，定义执行流方向 State: 图的共享状态，所有节点读写同一份状态 Cycle: 循环边，允许流程回到之前的节点 三、实战示例：状态管理的艺术 3.

LangChain LangGraph AI Agent

阅读更多

人工智能

2025-06-18 • 0k

langgraph 和 langchain 区别，实际工作中怎么使用

核心区别 LangChain：组件库与线性链。提供模型调用、RAG、工具等基础模块，适合构建线性、确定性的流程（如简单的问答机器人）。 LangGraph：状态机与循环图。基于 LangChain 构建，专为有状态、多步骤、含循环/条件分支的复杂 Agent 设计。它解决了 LangChain 难以处理“循环推理”和“持久化记忆”的痛点。 举例说明 场景 LangChain LangGraph 简单 RAG 检索 → 生成回答（一次性线性流程） ❌ 杀鸡用牛刀 代码生成 Agent ❌ 难以实现“生成→测试→报错→修改→再测试”的自动循环 ✅ 定义节点（生成/测试/修复）+ 条件边（通过/失败），自动循环直到成功 多 Agent 协作 需手动编排消息传递，状态管理困难 ✅ 原生支持 Supervisor/Swarm 模式，共享全局 State 实际工作中的使用策略 选型原则：流程是 DAG（有向无环图）选 LangChain；只要涉及 “循环”、“人工介入(Human-in-the-loop)”、“长期记忆”，直接上 LangGraph。 开发范式：将业务拆解为 State（数据结构）、Nodes（函数逻辑）、Edges（流转规则）。不要写成面条式代码，而是画成图。 生产落地：利用 LangGraph 的 Checkpointing 机制保存中间状态，支持任务暂停/恢复和断点调试；配合 LangSmith 进行 Trace 可视化监控。

LangChain LangGraph AI Agent

阅读更多

人工智能

2025-04-24 • 0k

RAG系统评估指南：基于RAG Assessment的指标体系与实现

本文讲解如何利用RAG Assessment框架，完成RAG（检索增强生成）系统的量化评估，覆盖核心指标体系与实操实现路径。 一、RAG系统基础流程 一套标准RAG系统的核心链路为：用户问题经Embedding模型向量化后，通过余弦相似度从向量库中召回Top K个相关文本块；将召回的上下文与问题拼接后填入约束型Prompt模板，输入大语言模型生成最终回答，以此减少模型幻觉。 二、RAG Assessment框架概述 该框架专为RAG系统评估设计，无需人工标注，可分别量化检索模块与生成模块的性能，解决两大核心痛点：一是为业务落地的RAG应用提供可量化的效果标准，替代主观判断；二是为集成检索器、父子文档等高阶优化方案提供客观的效果验证依据。 框架输入包含四类数据：用户问题、模型生成答案、检索上下文、标准答案；输出为多维度的量化评估得分。 三、四大核心评估指标 所有指标取值范围均为0-1，分数越高代表对应维度性能越好： 忠实度（Faithfulness）：衡量生成答案与检索上下文的事实一致性，基于答案与上下文计算。将答案拆分为多个事实片段，统计有上下文支撑的片段占比，反映模型幻觉程度。 答案相关性（Answer Relevance）：衡量生成答案与用户问题的匹配度，基于问题与答案计算。通过答案反向生成问题，计算反向问题与原问题的相似度均值，反映回答的完整性与冗余度。 上下文精确度（Context Precision）：衡量相关信息在检索结果中的排序位置，基于问题与上下文计算。统计Top K结果中相关内容的排序占比，反映检索排序的准确性。 上下文召回率（Context Recall）：衡量标准答案信息在检索结果中的覆盖程度，基于标准答案与上下文计算。拆分标准答案的事实点，统计能被检索上下文命中的占比，反映检索的完整性。 四、指标对应模块与优化方向 RAG系统的整体性能需结合所有指标综合评判，不同指标可定位不同环节的问题： 检索模块：对应上下文精确度、召回率。得分偏低时，可更换优质Embedding模型，或引入重排序、集成检索器等方案优化。 生成模块：对应忠实度、答案相关性。得分偏低时，可更换能力更强的大语言模型，或优化Prompt约束规则。 五、基于LangChain与Ragas的评估实现 核心实现步骤如下： 环境准备：安装langchain、ragas、arxiv加载工具、ChromaDB向量库等依赖，配置API密钥。 知识库构建：加载目标文档（如RAG Assessment原论文），完成文本分块、向量化，存入ChromaDB并定义检索器。 搭建RAG链路：编写约束型Prompt模板，串联检索、Prompt拼接、大模型生成的完整流程。 构建评估集：准备测试问题与标准答案，通过RAG链路批量生成对应答案与检索上下文，整理为标准评估数据集。 执行评估：调用Ragas的evaluate方法，传入数据集与四大评估指标，生成量化结果；可转为表格形式查看单题得分，定位系统短板并针对性优化。

RAG RAGAS 评估指标

阅读更多

人工智能

2025-02-28 • 0k

提示词工程实战：从面试技巧到生产级 Prompt 设计

在大模型相关岗位的面试中，“你平时怎么写提示词？”是一个看似简单、实际很容易拉开候选人差距的问题。 如果只回答“先设置角色，再描述任务，最后加几个示例”，虽然不能算错，但很难体现真实的项目经验。因为在实际的大模型应用中，提示词并不是一段写得比较漂亮的自然语言，而是模型与业务系统之间的一份“任务协议”。 一个成熟的回答，既要说清楚提示词如何设计，也要说明如何评测、如何防止模型跑偏，以及哪些问题不能只依靠提示词解决。 一、面试时可以这样回答 如果面试官问“你是怎么写提示词的”，可以先用下面这段话概括： 我写提示词时，首先会明确这个提示词在业务链路中的职责，比如它是用于意图分类、Query 改写、RAG 问答、信息抽取，还是 Agent 工具选择。不同任务的目标、约束和评测方式不同，所以我不会使用一套万能 Prompt。 在具体设计时，我通常会定义角色与目标、输入字段、任务步骤、约束边界、输出协议和 Few-shot 示例。对于需要程序继续处理的结果，我会要求模型输出符合 JSON Schema 的结构化数据。 Prompt 写完后，我不会只凭主观感觉判断效果，而是建立测试集，覆盖正常场景、边界场景、异常场景和对抗样本，评估任务准确率、格式遵循率、幻觉率、Token 消耗和响应延迟。 每次调整 Prompt 后都需要重新运行评测集，检查是否引入了回归问题。如果模型仍然不稳定，我还会在代码层增加 Schema 校验、置信度阈值、重试、降级和人工兜底。 所以我理解的提示词工程，不只是把一句话写得更清楚，而是完成任务定义、边界约束、结构化输出和评测闭环。 这个回答的重点，是让面试官意识到你不仅会“写提示词”，还具备工程化落地能力。 二、提示词应该包含哪些部分 一份适合生产环境的提示词，通常可以拆成六个部分。 1. 角色与任务目标 首先要告诉模型，它在当前任务中扮演什么角色，以及最终需要完成什么任务。 例如： 你是企业智能助手中的意图分类模块。 你的任务是识别用户问题的业务意图，并提取相关业务参数。 角色描述不需要堆砌“资深专家”“世界顶级”等无效修饰词。真正重要的是明确模型当前的职责。 2. 输入定义 需要说明模型会接收到哪些内容，以及每个字段代表什么。 例如，一个 RAG 问答任务可能包含： 用户原始问题； 检索到的参考资料； 当前用户的身份信息； 历史对话摘要； 输出格式要求。 如果输入中包含用户内容、检索资料和系统规则，最好使用明确的标签进行隔离： <user_question> {question} </user_question> <context> {retrieved_documents} </context> 这种写法能够降低不同类型信息相互干扰的概率。 3. 任务步骤 对于稍微复杂的任务，可以告诉模型应该依次完成哪些操作。 例如，一个信息抽取任务可以要求模型： 1. 阅读用户问题。 2. 判断用户意图。 3. 提取商品名称、仓库名称和日期范围。 4. 检查必填信息是否完整。 5.

提示词工程 Prompt Engineering LLM

阅读更多

人工智能

2024-11-10 • 0k

模型蒸馏完全指南：从BERT到BiLSTM的新闻分类实战

目录 为什么需要模型蒸馏？ 核心概念：教师-学生框架 三大关键公式（面试必考） 蒸馏的完整流程 实战代码：BERT → BiLSTM 新闻标题多分类蒸馏 面试高频考点总结 常见误区与调参技巧 一、为什么需要模型蒸馏？ 1.1 一句话总结 模型蒸馏 = 让一个"小学霸"（小模型）跟着"老教授"（大模型）学习，用小模型的身体继承大模型的智慧。 1.2 现实痛点 假设你用 BERT-base（1.1亿参数）训练了一个新闻标题分类器，效果很好（准确率 95%）。但当你想部署上线时，问题来了： 问题 具体表现 推理慢 BERT 单条推理约 10-30ms，高并发时扛不住 显存大 模型本身 ~440MB，加上 KV Cache 更夸张 部署难 手机端、嵌入式设备根本跑不动 蒸馏就是解决方案：训练一个 BiLSTM（可能只有几百万参数），让它学习 BERT 的"思考方式"，最终得到一个又快又准的小模型。 1.3 蒸馏 vs 其他压缩方法 模型压缩技术全景： ├── 模型蒸馏（Knowledge Distillation） ← 本文重点 │ └── 用大模型的输出指导小模型训练 ├── 模型剪枝（Pruning） │ └── 去掉不重要的权重/神经元 ├── 模型量化（Quantization） │ └── FP32 → INT8，降低精度 └── 权重共享（Weight Sharing） └── 多个参数共享同一组权重 🎯 面试考点：蒸馏是唯一一种"跨架构"的压缩方法——教师和学生的模型结构可以完全不同（如 BERT → BiLSTM），而剪枝和量化通常只能压缩同架构模型。

模型蒸馏 知识蒸馏 BERT

阅读更多

人工智能

2024-09-16 • 0k

注意力机制是如何“注意”的？一个词看懂上下文背后的秘密

你是否好奇，当 Transformer 模型读一句话时，是如何动态判断“当前这个词，最该参考前面哪几个词”的？这个过程并非魔法，也不是人工编写的规则，而是由 Q、K、V 三个向量 配合训练完成的一套精妙计算。 可以把整个过程想象成：当前词和前面每一个词进行一次“对话”，然后互相打分，得分高的就重点参考。具体来说，分四步。 第一步：三个关键角色登场 对于序列中的每个词，模型都会为它生成三个向量： Q（Query，查询）：代表“当前词”的需求。就像在大声问：“我需要理解我自己，谁有相关信息？” K（Key，键）：代表每个词的“标签”。每个词举着名牌，写着：“我主要包含这类信息。” V（Value，值）：每个词真正携带的具体内容，是最终要被提取的信息。 第二步：打分——“谁对我更重要” 当要理解词 A 时，模型就用 A 的 Q 向量，去和前面每个词的 K 向量计算点积（内积），得到一个标量分数。数学上，向量方向越相近，点积越大，意味着语义越相关。 例如，“北京”的 Q 遇上“首都”的 K，会因为语义高度相关得到一个很高的分数；而遇到“的”这类虚词的 K，分数往往很低。 第三步：从分数变成概率 这些原始分数经过 Softmax 归一化，被挤压成一组在 0 到 1 之间、总和为 1 的概率值。这个概率，就是最终的“注意力权重”。 于是，“首都”可能分到 0.6，“是”分到 0.1，“的”只分到 0.05。模型就真实地“知道”了：理解“北京”时，重点看“首都”。 第四步：提取信息 最后，用这些权重对所有词的 V 向量进行加权求和。权重高的词的 V 被大量保留，权重低的则几乎被忽略。融合后的向量，就携带了丰富的上下文信息，用来完成当前词的预测或理解。 那么，这一切是由谁决定的？ 答案是：数据训练。 Q、K、V 向量的生成矩阵一开始是完全随机的。模型在完成“预测下一个词”或“完形填空”的任务时，会不断犯错，再通过反向传播调整这些矩阵里的参数。经过万亿次调整，模型在无数句子中捕捉到了词与词之间的统计共现规律，涌现出这样的能力： “的”通常是结构词，不重要； “首都”对一个地点名词很重要； 动词和它的主语关系紧密； 代词往往指向前文出现过的实体…… 所以，“最该参考谁”的决定，本质上就是模型在海量文本中学到的、隐藏于 Q 和 K 互动中的语义相关性判断。所谓“多头注意力”，无非是准备很多套不同的 Q、K、V 生成矩阵，让模型能同时从语法、语义、长距离依赖等多个角度去做这样的打分。 这，就是注意力机制的核心秘密。

注意力机制 Transformer QKV

阅读更多

人工智能

2024-07-23 • 0k

Seq2Seq 与注意力机制：从机器翻译到 Transformer 架构

你是否好奇，当AI翻译一句话时，它是怎么做到"翻译到哪个词，就重点看哪个词"的？答案就藏在一个叫做 “专属信息包 C” 的东西里。今天，我们用最通俗的语言，一步步拆解它的诞生过程。 一、先搞懂一个问题：为什么需要"专属信息包"？ 假设我们要把中文 “我 爱 深度 学习” 翻译成英文 “I love deep learning”。 在注意力机制出现之前，传统模型的做法非常粗暴： 把整句话压缩成 一个固定长度的向量 C，然后解码器拿着这同一个 C 去翻译每一个英文单词。 这就像什么呢？就像你把一本200页的小说浓缩成一句话，然后要求别人用这句话去复述每一个章节的细节——显然不可能！ 翻译 “I” 的时候，需要关注"我" 翻译 “love” 的时候，需要关注"爱" 翻译 “deep” 的时候，需要关注"深度" 每个时刻需要的信息是不同的！ 所以我们需要为每个时刻量身定制一个 “专属信息包”——这就是注意力机制中动态计算的 上下文向量 $C_t$。 二、认识三位主角：Q、K、V 在计算"专属信息包"之前，我们先认识三个关键角色。用一个图书馆找书的比喻来理解： 角色 全称 比喻 含义 Q (Query) 查询 你脑子里想找的那本书的"关键词" “我现在需要什么信息？” K (Key) 键 图书馆每本书封面上的"标签" “这里有什么信息？” V (Value) 值 每本书的"实际内容" “这个信息的实际内容是什么？” 当解码器要生成某个单词时，它会：

Seq2Seq 注意力机制 Transformer

阅读更多