Raikay技术博客

工具与效率

2026-02-05 • 0k

使用 PowerShell 和大模型打造中文 Git 自动提交命令

在日常开发中，编写规范的 Git 提交信息是一件简单但重复的工作。为了减少这部分操作，我制作了一个名为 git-ec 的本地命令。它可以自动读取 Git 变更、调用大模型生成中文 Conventional Commit 信息，并完成代码提交。生成效果如下： feat: 新增提示词设计文档 fix(auth): 修复登录状态失效问题 docs: 补充项目部署说明文件位置 git-ec 由两个文件组成： C:\Users\raikay\AppData\Local\Programs\GitEasyCommit\git-ec.cmd C:\Users\raikay\AppData\Local\Programs\GitEasyCommit\git-ec.ps1 其中： git-ec.cmd 是命令入口。 git-ec.ps1 包含完整的 Git 检查、模型调用和提交逻辑。 API 配置保存在： C:\Users\raikay\AppData\Local\GitEasyCommit\config.json 首次配置首次使用前，需要配置模型的 API Key： git-ec -Configure 命令会隐藏输入内容，并使用 Windows 当前用户加密机制保存密钥。配置文件中的密钥不是明文。其他 Windows 用户或其他计算机无法直接解密。基本用法自动生成提交信息并直接提交： git-ec 生成信息后等待人工确认： git-ec -c 如果使用 -c，命令会显示生成的提交信息和文件统计： Commit message: ------------------------ docs: 补充提示词使用说明 ------------------------ content/posts/blog/prompt.md | 486 ++++++++++++++++++++ 确认无误后输入 y 即可提交。工作原理整个命令主要分为以下几个阶段。

Git PowerShell AI

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

人工智能

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-11-07 • 0k

WCF已退休？.NET分布式技术的历史演进与现代替代方案分析

引言提到 WCF（Windows Communication Foundation），很多.NET 开发者并不陌生 —— 它曾是.NET Framework 时代分布式系统通信的 “全能选手”。但如今，REST API、gRPC 等技术早已成为主流，有人疑惑：WCF 是不是已经没有意义了？它真的只是 “API 不普及时代的临时替代” 吗？其实，WCF 的价值远比 “临时替代” 复杂。它的兴起源于特定时代的技术需求，衰落则是技术迭代的必然，而其设计思想至今仍在影响着现代分布式通信技术。今天我们就从时代背景、现状价值、技术替代三个维度，彻底说清 WCF 的 “前世今生”。一、先澄清：WCF 不是 “临时 API 替代”，而是当年的 “全能服务框架” 很多人对 WCF 的认知停留在 “服务调用”，但这只是它的冰山一角。WCF 的核心定位是微软为.NET Framework 打造的「统一服务开发框架」，目标是让开发者用一套代码，兼容多种通信场景，而非简单替代早期功能单一的 WebService 或 ASHX。它的核心能力远超 “基础 API 调用”：多协议支持：覆盖 HTTP（REST/SOAP）、TCP、命名管道（Named Pipe）、MSMQ、WS-* 等，既能满足简单接口通信，也能支撑企业级复杂协议（如事务、安全、可靠消息）；多交互模式：支持请求 - 响应、单向通信、发布订阅、流传输（大文件 / 实时数据）等，适配不同分布式场景；企业级特性：内置 Windows 认证、证书认证、自定义授权、数据加密、分布式事务等，无需额外开发即可满足企业级安全和一致性需求。而早期的 “API”（如简单 WebService）功能单一、缺乏统一配置能力，WCF 的出现本质是为了解决「企业级分布式系统的复杂通信痛点」，而非 “临时过渡”。二、现在的 WCF：新项目零价值，存量系统仍需 “续命” 1.

WCF 分布式技术 .NET

后端开发

2025-11-07 • 0k

数据防篡改实用方案：从原理到落地实现 - 数字签名与HMAC详解

数据防篡改实用方案：从原理到落地实现在后端服务、文件传输、接口通信等场景中，数据完整性是不可忽视的安全底线 —— 无论是网络传输中的字节丢失，还是恶意攻击者篡改核心业务数据（如转账金额、订单信息），都可能引发严重的业务风险。很多开发者知道用散列算法（如 SHA256）做数据校验，但容易陷入一个误区：如果篡改者同时修改数据和对应的散列值，接收方该如何识别？本文将从底层原理出发，拆解单纯散列校验的漏洞，通过简洁的代码示意，演示 “数字签名” 和 “HMAC” 两种防篡改方案，帮你快速落地数据完整性防护。一、数据校验的核心逻辑：给数据加 “唯一指纹” 1. 基础原理数据校验的本质是通过数学算法，将任意长度的原始数据转换为固定长度、独一无二的特征值（类似人类指纹），这个特征值被称为 “校验值”（散列值、校验位等）。核心流程：发送方：原始数据 → 校验算法（如 SHA256）→ 校验值 → 发送 “数据 + 校验值” 接收方：接收数据 → 相同校验算法 → 新校验值 → 对比 “新校验值” 与 “接收的校验值” 结论：一致则数据未篡改，不一致则数据异常 2. 散列算法的关键特性散列算法是防篡改的基础，其安全性依赖两个核心特性：抗碰撞性：不同数据几乎不可能生成相同散列值，哪怕修改 1 个字符（如 “123” 改为 “124”），散列值也会完全不同；不可逆性：只能通过原始数据计算散列值，无法通过散列值反推原始数据。 3. 单纯散列校验的致命漏洞单纯的 “数据 + 散列值” 方案存在明显缺陷：如果篡改者修改原始数据后，对篡改数据重新计算散列值，再将 “篡改数据 + 新散列值” 一起发送，接收方会误以为数据合法 —— 因为散列值本身没有 “身份标识”，无法证明是合法发送方生成的。

RSA HMAC 数字签名

人工智能

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

C#与.NET技术
实践与教程

最新.NET技术文章

使用 PowerShell 和大模型打造中文 Git 自动提交命令

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

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

WCF已退休？.NET分布式技术的历史演进与现代替代方案分析

数据防篡改实用方案：从原理到落地实现 - 数字签名与HMAC详解

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

LangChain 与 LangGraph 实战指南

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

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

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

热门技术标签

C#与.NET技术实践与教程

最新.NET技术文章

热门技术标签

C#与.NET技术
实践与教程