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

专注分享 AI 大模型、Agent 开发、深度学习等技术实战与架构设计；兼具 C#/.NET 后端开发经验

117
技术文章
8
文章分类
533
技术标签
29444
累计字数

最新技术文章

全部 人工智能 前端开发 后端开发 嵌入式 工具与效率 数据与中间件 更多
没有 .sln 也能跑？dotnet new console 背后的项目组织逻辑
后端开发
2026-10-30 • 0k

没有 .sln 也能跑？dotnet new console 背后的项目组织逻辑

用 dotnet new console -n DemoConsole 创建项目，运行没问题，但文件夹里只有 DemoConsole.csproj 和 Program.cs——没有 .sln，Visual Studio 怎么打开？ 先说结论：sln 不是运行必需的，它是 IDE 用的多项目容器。dotnet new console 本来就不生成它。 csproj 是本体，sln 是容器 文件 角色 谁在用 .csproj 项目本体：目标框架、依赖、编译配置 dotnet CLI、VS、MSBuild .sln 容器：把多个 csproj 组织在一起 Visual Studio、Rider dotnet build、dotnet run 只认 csproj，sln 缺席不影响编译运行——所以很多人项目跑了半年才发现自己从来没有 sln。 单项目：直接打开 csproj VS 2019/2022 支持以项目文件为单位打开： 文件 → 打开 → 项目/解决方案 → 选中 DemoConsole.csproj F5 调试、NuGet 管理全都可用，单项目阶段可以一直不建 sln。 多项目：该补 sln 了 MySolution/ ├── MySolution.sln ├── DemoConsole/ ← 主程序 ├── DemoConsole.Tests/ ← 单元测试 └── DemoLibrary/ ← 类库 sln 的价值在项目多起来之后：

.NET dotnet CLI Visual Studio
阅读更多
DbContext 为什么线程不安全？EF Core 生命周期与并发访问的正确姿势
后端开发
2026-10-30 • 0k

DbContext 为什么线程不安全？EF Core 生命周期与并发访问的正确姿势

线上日志里出现这行异常，几乎每个用过 EF Core 的人都见过： System.InvalidOperationException: A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext. 这说明有一个 DbContext 实例正在被多个线程同时使用。很多人第一反应是"我明明没开线程"，或者"加个 lock 就好了"——两种想法都走偏了。先记住一件事： DbContext 不是一个无状态的查询工具，而是一个短生命周期的、有状态的工作单元。 为什么不是线程安全的 它内部维护着一整套可变状态，一旦被并发读写必然出问题： 内部状态 并发后果 DbConnection ADO.NET 连接本身不支持并发，出现"连接未关闭"等异常 ChangeTracker 跟踪状态互相污染，SaveChanges 写入错误数据 实体标识映射（Identity Map） 同一实体被多线程各改一份，后写入的覆盖前一个 查询管道 / 事务 并发检测异常，或出现部分提交、回滚失败 所以问题不在于某个字段没加锁，而在于它从设计上就假定自己是独占的工作单元。这里要澄清最易误解的一点： DbContext 可以被不同线程先后使用（await 之后线程可能变化，这没问题），但绝不能被多个线程同时使用。 “线程不安全"不等于"不能跨线程”，而是不能并发。 常见错误写法 错误做法 后果 注册为 Singleton 所有请求共享同一实例，并发冲突几乎必然发生 异步方法不 await 前一操作未完成就发起新操作，直接抛异常 在 Task.Run / Parallel.ForEach 中使用注入的实例 跨线程并发共享，抛异常或写脏数据 用 lock 强行保护 DbContext 查询被串行化，吞吐骤降且易死锁，属于用错工具 其中"忘了 await“最隐蔽，它等价于在同一实例上并发发起两次查询：

Entity Framework Core DbContext 线程安全
阅读更多
同为 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
阅读更多
使用 PowerShell 和大模型打造中文 Git 自动提交命令
工具与效率
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 这两项前沿协议。读完本文，你将不仅理解“如何调用”，更能看清“调用什么”和“谁来调用”的全貌。 一、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
阅读更多
C# AI Agent 选型与框架推荐 - 2025最新指南
人工智能
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#
阅读更多
WCF已退休？.NET分布式技术的历史演进与现代替代方案分析
架构与设计
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
阅读更多
数据防篡改实用方案：从原理到落地实现 - 数字签名与HMAC详解
后端开发
2025-11-07 • 0k

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

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

RSA HMAC 数字签名
阅读更多
LangGraph记忆避坑指南：自动管理为什么还不够？
人工智能
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
阅读更多
LangChain 与 LangGraph 实战指南
人工智能
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
阅读更多

热门技术标签

.gitconfig .gitignore .net .net core .net开发 .net异步编程 163源 A2a Abp vnext Action过滤器 Agent Ai