同为 XAML + C#：一文说清 WPF、WinUI 3 与 MAUI 的本质差异

后端开发

2026-10-28 • 0k

同为 XAML + C#：一文说清 WPF、WinUI 3 与 MAUI 的本质差异

很多开发者第一次接触 WPF、WinUI、MAUI 时都会有一个疑问：这三者是不是都一样？反正都是 XAML 写界面 + .NET 写逻辑。

答案是：不完全一样。虽然它们在"使用 XAML 进行 UI 声明"和"基于 .NET/C#“这一点上高度相似，但在底层框架、目标平台、XAML 方言细节以及语言支持范围上存在关键差异。

相同点：表面上的"一样”

从开发体验的宏观层面看，三者确实共享同一套核心范式：

XAML 声明式 UI：三者都使用 XAML 来定义用户界面布局、数据绑定和样式。XAML 于 2006 年随 WPF 首次推出，后续的 WinUI 和 MAUI 都沿用了这一语法习惯。
.NET 与 C# 后端：业务逻辑主要用 C# 编写，并运行在 .NET 运行时之上。WPF 本身就是 .NET 类型的一个子集。

关键差异：实质上的"不一样"

尽管表面相似，但它们的定位和实现截然不同。

1. 目标平台与定位

WPF：仅限 Windows 桌面。它是一个成熟的、用于构建 Windows 富客户端应用的框架，无法跨平台运行。
WinUI（特指 WinUI 3）：仅限 Windows 桌面（及 UWP）。这是微软目前推荐的用于开发新 Windows 原生应用的最现代框架，深度集成 Windows App SDK，支持 Windows 10 1809 及以上版本。
MAUI：真正的 跨平台 框架。它的目标是用一套代码库构建 Android、iOS、macOS 和 Windows 应用。在 Windows 上，MAUI 底层实际上是基于 WinUI 3 来渲染的。

2. XAML 方言与控件库

虽然语法相似，但三者能用的"零件"不同。

WPF WinUI MAUI

工具与效率

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 即可提交。

工作原理

整个命令主要分为以下几个阶段。

1. 检查 Git 仓库

脚本首先执行：

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 这两项前沿协议。读完本文，你将不仅理解“如何调用”，更能看清“调用什么”和“谁来调用”的全貌。

AI Agent 工具调用技术演进总览

一、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
适用场景：企业级 Agent 开发、AI 原生应用（Copilot 类工具、自动化工作流）、跨平台 Agent 项目。

2. LangChain.NET

核心定位：Python 热门框架 LangChain 的 C# 官方移植版，专注于「大模型应用的模块化组装」，Agent 是其核心模块之一。
关键特性：

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？

WCF 的衰落是技术迭代和自身局限共同作用的结果，如今在新项目中已无使用意义：

平台绑定严重：WCF 是.NET Framework 专属框架，.NET Core/.NET 5 + 虽有 “WCF Core”，但仅支持核心子集（MSMQ、WS-* 等高级特性被砍），无法跨语言（Java 等其他语言对接成本极高），与现在跨平台、多语言协作的需求脱节；

WCF 分布式技术 .NET

后端开发

2025-11-07 • 0k

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

数据防篡改实用方案：从原理到落地实现

在后端服务、文件传输、接口通信等场景中，数据完整性是不可忽视的安全底线 —— 无论是网络传输中的字节丢失，还是恶意攻击者篡改核心业务数据（如转账金额、订单信息），都可能引发严重的业务风险。

很多开发者知道用散列算法（如 SHA256）做数据校验，但容易陷入一个误区：如果篡改者同时修改数据和对应的散列值，接收方该如何识别？本文将从底层原理出发，拆解单纯散列校验的漏洞，通过简洁的代码示意，演示 “数字签名” 和 “HMAC” 两种防篡改方案，帮你快速落地数据完整性防护。

一、数据校验的核心逻辑：给数据加 “唯一指纹”

1. 基础原理

数据校验的本质是通过数学算法，将任意长度的原始数据转换为固定长度、独一无二的特征值（类似人类指纹），这个特征值被称为 “校验值”（散列值、校验位等）。

核心流程：

发送方：原始数据 → 校验算法（如 SHA256）→ 校验值 → 发送 “数据 + 校验值”
接收方：接收数据 → 相同校验算法 → 新校验值 → 对比 “新校验值” 与 “接收的校验值”
结论：一致则数据未篡改，不一致则数据异常

2. 散列算法的关键特性

散列算法是防篡改的基础，其安全性依赖两个核心特性：

抗碰撞性：不同数据几乎不可能生成相同散列值，哪怕修改 1 个字符（如 “123” 改为 “124”），散列值也会完全不同；
不可逆性：只能通过原始数据计算散列值，无法通过散列值反推原始数据。

3. 单纯散列校验的致命漏洞

单纯的 “数据 + 散列值” 方案存在明显缺陷：如果篡改者修改原始数据后，对篡改数据重新计算散列值，再将 “篡改数据 + 新散列值” 一起发送，接收方会误以为数据合法 —— 因为散列值本身没有 “身份标识”，无法证明是合法发送方生成的。

解决核心：让校验值 “不可伪造”，只有合法发送方能生成有效校验值。

二、实用防篡改方案：代码示意

主流开发框架中都提供了完善的加密库，无需第三方依赖即可实现 “数字签名” 和 “HMAC”。以下是两种方案的精简代码示意，聚焦核心逻辑。

方案 1：数字签名（非对称加密）—— 适合跨主体通信（如 API、支付）

核心思路

采用 “私钥签名、公钥验签” 机制：私钥仅发送方持有，用于给散列值加密生成 “数字签名”；公钥公开给接收方，用于解密签名并验证合法性。篡改者没有私钥，即便修改数据，也无法伪造有效签名。

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. 不同节点需要不同的上下文

假设用户连续提问：

用户：介绍一下A型号打印机。
用户：它支持双面打印吗？

理解节点需要参考历史，把第二个问题改写为：

A型号打印机支持双面打印吗？

后续知识库检索更适合使用这个独立问题，而不是整段聊天记录：

历史消息 + 当前问题
        ↓
问题改写
        ↓
独立、明确的问题
        ↓
检索、SQL或知识图谱查询

如果把全部历史直接交给每个节点，旧话题中的地点、商品和条件可能干扰实体抽取与查询生成。

2. 自动保存不会自动理解历史

真实用户常使用省略和指代：

第一轮：介绍一下A产品。
第二轮：多少钱？
第三轮：它和B产品有什么区别？

系统需要将后两轮改写为：

A产品多少钱？
A产品和B产品有什么区别？

Checkpointer不会自动完成指代消解、问题改写、实体继承和业务参数提取。这些仍需要专门节点或业务代码。

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.1 定义状态 (Schema)

这是 LangGraph 的核心！你的应用所有数据都存在于这个状态中:

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 评估指标

AI 大模型与智能应用实践与技术

最新技术文章

相同点：表面上的"一样”

关键差异：实质上的"不一样"

1. 目标平台与定位

2. XAML 方言与控件库

文件位置

首次配置

基本用法

工作原理

1. 检查 Git 仓库

导读

一、Function Call: 最容易被误解的技术

1.1 一个常见的认知误区

1.2 Function Call 的完整四步流程

一、通用型开源 C# AI Agent 框架（核心推荐）

1. Semantic Kernel（微软官方）

2. LangChain.NET

引言

一、先澄清：WCF 不是 “临时 API 替代”，而是当年的 “全能服务框架”

二、现在的 WCF：新项目零价值，存量系统仍需 “续命”

1. 新项目为什么完全不推荐用 WCF？

数据防篡改实用方案：从原理到落地实现

一、数据校验的核心逻辑：给数据加 “唯一指纹”

1. 基础原理

2. 散列算法的关键特性

3. 单纯散列校验的致命漏洞

二、实用防篡改方案：代码示意

方案 1：数字签名（非对称加密）—— 适合跨主体通信（如 API、支付）

核心思路

一、大模型本身没有记忆

二、LangGraph自动记忆做了什么

三、为什么真实项目仍要手动管理

1. 不同节点需要不同的上下文

2. 自动保存不会自动理解历史

一、为什么需要 LangGraph？

二、核心概念：图 vs 链

2.1 语言模型的三种执行模式

2.2 关键术语

三、实战示例：状态管理的艺术

3.1 定义状态 (Schema)

核心区别

举例说明

实际工作中的使用策略

一、RAG系统基础流程

二、RAG Assessment框架概述

三、四大核心评估指标

四、指标对应模块与优化方向

五、基于LangChain与Ragas的评估实现

热门技术标签

AI 大模型与智能应用
实践与技术