喵叔

原创 Week 3 --Day 3：多智能体协作系统

在前两天的学习中，我们使用 LangGraph 构建了从简单 ReAct 循环到复杂多节点流水线的 Agent 工作流，这些图在单个 Agent 的范畴内已经相当强大。然而当你把越来越多工具塞进同一个 Agent，或者让同一个 Agent 同时处理代码审查、数据分析、客户沟通这些性质迥异的任务时，单 Agent 架构的瓶颈会逐渐暴露。最直观的问题是上下文膨胀，每次工具调用，尤其是网页搜索、数据库查询、文件读取这类会返回大量内容的操作，都会在消息历史中堆积数据，很快逼近模型的上下文窗口上限。更深层的问题是工具

原创 Week 3 --Day 2：LangGraph 进阶

本文介绍了如何使用LangGraph构建复杂工作流，重点探讨了三个进阶特性：多节点顺序流水线、条件路由和状态管理。通过内容生产流水线示例，展示了如何将研究、分析、写作、审核等节点串联成工作流，并实现审核不通过自动返工的条件路由机制。文章还解释了LangGraph的状态管理机制，包括继承MessagesState自动获得消息追加能力，以及混合reducer的设计模式。这些技术为构建可定制、带决策能力的AI工作流提供了基础支持。

原创 Week 3 -- Day 1：LangGraph 入门

本文介绍了LangGraph的设计理念和核心概念。LangGraph是一个低层Agent编排框架，适用于构建多步骤、有条件分支的复杂工作流，其灵感来自Pregel系统和Apache Beam，通过有向图模型实现对Agent执行流程的精确控制。核心概念包括StateGraph（定义状态模式）、Node（执行具体逻辑的函数）、Edge（节点间的路由关系）以及特殊虚拟节点START/END。文章展示了如何构建一个基于ReAct循环的Agent工作流，包括工具定义、模型绑定、状态设计和图构建。LangGraph强调

原创 14【.NET10 实战--孢子记账--产品智能化】--智能生成预算

经过前面三篇文章的铺垫，我们先后完成了硅基流动平台的接入配置、大模型接入方式的技术选型，以及 LLM 调用层的统一封装，孢子记账的智能化基础设施已经基本就绪。从现在开始，我们的目光将从"怎么接入 AI"转向"用 AI 做什么"，将大模型能力真正嵌入到具体的业务场景中，让用户能够实实在在地感受到智能化带来的体验提升。而我们将要攻克的第一个智能化功能，就是。

原创 第2周学习笔记

工具是 Agent 系统中最基础的单元。@tool@tool"""搜索客户数据库中的匹配记录。"""return f"在数据库中找到了@tool def search_database(query : str , limit : int = 10) - > str : """搜索客户数据库中的匹配记录。""" return f"在数据库中找到了 {limit } 条与 ' {query } ' 相关的结果。

原创 Week 2 -- Day 5：Agent 系统（下）— Function Calling 与 create_agent

在 Day 4 的学习中，我们理解了 Agent 系统最核心的概念，工具（Tool）和 ReAct 推理循环。今天我们要进一步深入两个在实际开发中至关重要的主题，底层的 Function Calling 机制，以及 LangChain v1 中最强大的 Agent 构建入口和它背后的中间件（Middleware）系统。如果把 Day 4 的内容比作理解了汽车发动机的工作原理，那么今天我们要学习的是整车的电控系统和底盘架构，它们让 Agent 从"能跑"进化为"稳定、可控、可扩展"。

原创 Week 2 -- Day 4：Agent 系统（上）— 工具与 ReAct

文章摘要： 本文介绍了如何通过LangChain v1构建具备行动能力的Agent系统。主要内容包括：1) 工具定义，使用@tool装饰器将Python函数转化为模型可调用的工具，强调参数类型和描述文档的重要性；2) ReAct（推理+行动）模式，详细解释了模型如何在思考与行动间交替进行以解决复杂问题；3) Agent构建的演进，从旧版create_react_agent到新版更灵活的create_agent中间件系统。文章通过代码示例展示了工具创建、参数定义和Agent构建过程，突出了新版API的可组合性

原创 Week 2 -- Day 3：RAG 系统构建（下）

今天我们要做的，就是把这一堆零散的文本 chunk 转化为机器能够理解的数值向量，存入向量数据库，并在用户提问时从中检索出最相关的内容，最终拼接到大模型的提示词里，形成一个完整的检索增强生成（RAG）问答系统。在这个空间中，语义相近的文本会被映射到几何上彼此靠近的点，而语义无关的文本则相距甚远。举例来说，"猫是一种宠物"和"狗是人类的好朋友"这两句话虽然字面完全不同，但它们都涉及"家庭宠物"这一语义范畴，因此在向量空间中大概率会聚在一起，而"今天的股票大涨"则可能落在完全不同的区域。值得一提的是来源追踪。

原创 Week 2 -- Day 2：RAG 系统构建（上）

本文介绍了 RAG（检索增强生成）技术及其在LangChain中的实现流程。RAG通过动态检索外部知识解决大模型数据局限问题，广泛应用于企业知识库等场景。文章重点讲解了RAG前两步：文档加载和文本分割，包括LangChain提供的丰富文档加载器（如PDF、Markdown等）和递归字符分割器（RecursiveCharacterTextSplitter）的使用方法。通过调整chunk_size、overlap等参数可以优化文本分割效果，平衡检索精确性与语义完整性。最后建议实践不同文档格式的加载和分割参数对比

原创 Week 2 -- Day 1：Model IO 与模型抽象

如果说 LangChain 是一套乐高积木，那么 Model I/O 就是那几块最核心的底板砖，无论你搭建的是简单的问答链还是复杂的多智能体系统，一切逻辑的起点都是"把数据交给模型，把模型的结果拿回来"。本周我们正式进入 LangChain 核心组件的深度学习，第一天的主题就是把 Model I/O 这一层吃透，理解 LangChain 如何用统一抽象屏蔽不同模型厂商的差异，掌握模型参数的调优哲学，以及学会根据任务特征动态选择合适的模型。

原创 13.【.NET10 实战--孢子记账--产品智能化】--封装LLM

本文介绍了在孢子记账项目中封装LLM调用层的必要性及设计思路。通过对比直接调用OpenAI SDK的弊端，提出了构建统一封装层的方案，旨在解决微服务架构中配置分散、代码重复等问题。文章详细阐述了封装层的设计目标与核心功能，包括面向业务的接口设计、结构化配置模型以及重试机制。重点介绍了IOpenAIService接口的简洁设计原则和OpenAIOptions配置类，强调了重试与指数退避策略对系统稳定性的重要性。该封装层将作为微服务架构中的基础组件，为后续更多AI能力的集成提供统一接入点。

原创 Week 1 -- Day 5：周总结与综合练习

文章摘要 本周学习围绕LangChain框架展开，系统掌握了其核心架构与开发实践。课程从宏观生态到微观组件层层递进：第一天解析LangChain四层架构（核心层、社区集成层、业务组件层、LangGraph层）和关键特性；第二天实践环境配置与LCEL基础链搭建；第三天深入Runnable接口与动态工作流设计；第四天聚焦提示工程与结构化输出处理。最终通过"多语言翻译助手"项目整合所学，实现包含Pydantic数据校验、Few-Shot提示模板和健壮错误处理的完整AI应用，展示LangChain声明式编程和模块化

原创 Week 1 -- Day 4：提示工程与输出解析

LLM 的原始输出本质上是无结构的纯文本流，但真实应用几乎总是需要结构化的数据，一个 JSON 对象、一组带类型约束的字段、或某种自定义的格式。列表，模型在回答第二个问题之前会"看到"上一轮的问答，因此能够自然地延续上下文，比如第二此问的"给我一个实际例子"不需要再重复说"装饰器的例子"，模型已经知道你在接着刚才的话题继续问。构建一个包含至少 3 个示例的提示模板，并对比"有 Few-Shot"和"没有 Few-Shot"两种情况下模型的输出质量差异，用一句话写下你的发现。是结构化的入门级方案。

原创 Week 1 -- Day 3：LCEL 深度理解

LCEL 内置的组件覆盖了大多数常见需求，但总有一些业务特定的处理逻辑，例如格式转换、数据清洗、自定义聚合等，需要用普通 Python 函数来实现。就是连接普通函数与 LCEL 世界的桥梁。只需要把任意一个可调用对象（函数、lambda、带__call__的类实例）传给，它就变成了一个合法的Runnable，可以用自由拼接到任何 chain 中。函数的输入就是上游组件的输出，函数的返回值就是传给下游组件的输入，行为与其他Runnable完全一致。

原创 Week 1 -- Day 2：环境搭建与第一个应用

文章摘要： 本文介绍了LangChain环境搭建与首个应用的开发流程。首先详细说明了分层安装各组件包（核心包、社区工具、模型集成等）的方法，强调版本控制与依赖管理的重要性。接着讲解安全配置API密钥的最佳实践，推荐使用.env文件配合python-dotenv管理敏感信息。通过对比传统调用方式与LCEL表达式语言，展示了如何用管道运算符串联提示词模板、模型调用和结果解析三大组件，实现角色扮演问答功能。最后提出递进式练习任务，引导读者验证环境、切换模型并思考LangChain封装的价值——统一接口显著降低了不

原创 Week 1 -- Day 1：LangChain 生态全景

最底层的基础抽象层由 langchain-core 包实现，它是整个框架的地基，定义了核心的 Runnable 接口和 LangChain Expression Language（LCEL），所有上层组件都遵循这套统一的接口规范进行交互，保证了组件间的高度可组合性。概念理解方面，你应当能够不借助笔记，用自己的语言流畅复述四大核心层级的名称、对应包名及各自承担的职责，这是后续深入学习的基础框架。首先访问 LangChain 官方文档首页，通读其对框架定位和核心概念的介绍，建立起对整体设计哲学的感性认识。

原创 12.【.NET10 实战--孢子记账--产品智能化】--技术选型

通过对现有技术选型的分析与评估，我们最终选择了官方 SDK 作为孢子记账智能化改造阶段的主要接入方案。官方 SDK 的稳定性、易用性以及与平台的紧密集成，使其成为了我们在当前阶段实现智能化功能的最佳工具。通过上述示例，我们验证了 OpenAI SDK 可以无缝接入硅基流动平台，并且调用方式与标准 OpenAI API 完全一致，这为我们后续构建智能账单录入、消费趋势分析等功能奠定了坚实的基础。

原创 02-大模型蒸馏的本质：你到底是在「克隆能力」，还是在「自我感动」？

读到这里，你需要问自己一个比"蒸馏成没成功"更根本的问题：你到底想让这个学生模型具备什么？如果你的目标是在特定场景下，以极低的推理成本提供与教师模型相近的服务质量，比如高频、短文本、窄领域的生产环境，那么基于行为克隆的 SFT 黑盒蒸馏是一条合理、高效的路径，它能用很低的成本把教师的行为模式迁移过来，在你控制好分布的前提下运作良好。但如果你的目标是让学生模型具备真正意义上的泛化能力，能在新的问题类型上做出合理决策、能在长推理链中保持逻辑一致性、能在陌生领域触类旁通。

原创 01-发刊词：别再瞎蒸馏了！90%的大模型蒸馏，都在做无用功

大模型蒸馏是一项真正有价值的技术。它让顶级 AI 能力的私有化部署成为可能，也让端侧推理、低成本垂直领域模型的构建变得现实。但它同时也是一项被严重误解和滥用的技术，大量的人力、算力和 API 费用，正在被不正确的方法论白白浪费掉。我希望这个专栏能帮你把这笔账算清楚，把该踩的坑提前标出来，让你的每一次蒸馏实验，都真正花在刀刃上。欢迎来到「大模型蒸馏全栈实战」。

原创 11.【.NET10 实战--孢子记账--产品智能化】--接入第三方平台

本文介绍了孢子记账服务端智能化改造的技术选型过程。在对比OpenAI、Azure OpenAI、DeepSeek、通义千问、智谱AI等主流LLM平台后，最终选择硅基流动作为基础平台，因其具备国内稳定访问、极低成本、兼容OpenAI API等优势。文章详细演示了在.NET项目中接入硅基流动API的具体步骤，包括账号注册、NuGet包安装、客户端配置、对话请求发起等关键环节，并提供了在ASP.NET Core中注册服务的示例代码。该方案为中小型项目提供了经济高效的LLM接入方案。

原创 大模型蒸馏全栈实战：从Claude黑盒克隆到开源模型轻量化落地--目录

原创 10.【.NET10 实战--孢子记账--产品智能化】--其余第三方包批量升级

摘要： 孢子记账系统完成 .NET 10 升级的最后阶段，对18个第三方库进行低风险升级。这些库分为三类：多目标框架包（如AutoMapper、MongoDB.Driver）直接支持.NET 10；netstandard包（如RabbitMQ.Client）依靠.NET兼容性承诺；需验证类（如Quartz、Refit）需确认框架适配。重点关注Refit的Roslyn源生成器兼容性、Quartz的任务调度API变更，以及Serilog与ASP.NET Core 10的日志集成。升级策略采用批量版本替换与编译验

原创 9.【.NET10 实战--孢子记账--产品智能化】--SP.MLService Microsoft.ML 升级到 .NET 10

本次 SP.MLService 的依赖升级，从表象上看是三个 NuGet 包的版本替换，但它所包含的技术深度和验证复杂度远超其他步骤。和的升级，涉及对兼容性加载机制的理解、对 LightGBM 原生二进制文件跨平台加载链路的系统性验证设计，以及对机器学习模型在版本切换后数值稳定性的评估。而的升级虽然是本次操作中最轻量的部分，但作为 FeedbackStorage 的核心依赖，同样需要在功能验证阶段确认读写链路的正常运转。

原创 8.【.NET10 实战--孢子记账--产品智能化】--API 网关 Ocelot 升级

Ocelot API网关升级是系统升级计划中唯一的高风险环节，因其承担着系统唯一对外入口的关键职责。升级面临版本选择问题：24.1.0稳定版风险低但需二次升级，25.0.0-beta.2预发布版支持.NET 10但存在潜在风险。经过评估，选择直接升级到25.0.0-beta.2，因其核心功能稳定且符合项目需求。升级过程包括替换NuGet包和生成新版ocelot.json配置，重点关注移除废弃API和添加超时配置。通过AI辅助完成版本替换和配置生成，最终验证路由转发等功能正常，实现一步到位的升级目标。

原创 40_终极落地Checklist：你的公司Agent是否真的会干活了

《生产级AI Agent的五大评估维度与60项检查清单》 本文针对AI Agent从"演示就绪"到"生产就绪"的转型挑战，提出了系统化的评估框架。核心指出大多数Agent失败的根本原因在于三大系统性缺陷：测试覆盖不足、可观测性缺失和技能治理缺位。 文章详细阐述了五个关键评估维度： 技能完整性：确保任务覆盖率，避免"覆盖度假象" 执行可靠性：保障高并发和异常情况下的稳定性 可观测性：实现问题快速定位与根因分析 安全与合规：防范提示词注入等安全隐患 持

原创 39_2027年Skills会消失吗？下一代可能是Executable_Skills_Code-in-Skills

摘要： Skills作为AI代理的任务规范机制不会消失，但当前纯自然语言的Markdown形式存在精确性不足、调试困难等天花板。未来将向"Executable Skills"进化，即在Skill中嵌入可执行代码片段，用代码处理确定性逻辑，保留自然语言处理模糊任务。这种混合形态将提升可测试性和工程化水平，并可能催生Skill标准化协议、与记忆系统的深度融合，以及多Agent生态中的能力交换市场。Skills的演进本质是工程成熟度的提升，其核心价值——规范Agent行为将持续存在。

原创 38_写崩的十大Skills惨案&如何避免（反面教材合集）

这十个惨案覆盖了从设计到上线的完整生命周期，每一个都有真实的原型——有的来自初创团队的早期探索，有的来自大厂内部的"先上线再说"文化。如果你现在去检查你团队的 Skills，有超过三个惨案能在里面找到对应，那说明你们的 Agent 工程化还有很长的路要走。好消息是：这些问题都有明确的解法，而且代价都不大——大多数情况下，一份规范文档加一个 Git 仓库就能解决一半问题。坏消息是：如果你不主动修，等到生产环境爆发，代价就不只是工程成本了。

原创 37_Skills_vs_Fine-tuning_vs_RAG_vs_传统Tools：2026成本效果对比

选技术方案不是"哪个更好"的问题，而是"哪个对这个问题的性价比更高"。Skills 是成本最低、迭代最快的方案，应该成为大多数场景的首选；RAG 和 Tools 是能力补充；Fine-tuning 是最后的精修手段。把这个优先级理清楚，能让你少走两年弯路——以及少解释几十次"为什么模型微调了但效果还是不对"。

原创 7.【.NET10 实战--孢子记账--产品智能化】--API 文档迁移 — Swashbuckle → OpenAPI + Scalar

本文介绍了.NET 8到.NET 10升级过程中API文档系统的迁移方案。主要内容包括：1）从Swashbuckle.AspNetCore迁移到原生Microsoft.AspNetCore.OpenApi包；2）用Scalar替代Swagger UI作为新的文档展示界面；3）分步骤处理普通微服务和Gateway层的升级，其中Gateway层需额外处理文档聚合逻辑；4）利用AI Coding的Plan模式批量生成修改计划，提高升级效率。该方案既符合.NET 10技术方向，又提升了API文档系统的维护性和使用体

原创 36_Skills版本管理与团队协作：Git+Review+企业级部署全流程

Skills版本管理的本质是把AI能力的变更纳入工程管控的视野。没有这套机制，Skills会以一种比代码更隐蔽的方式腐化——因为它出错时系统不会崩溃，只是悄悄地变得不可信，而不可信比崩溃更难处理。对中大型团队来说，建议按顺序推进：先建Git仓库和基本分支保护（最低门槛，一天内可完成），再引入提交规范和Review Checklist（中等投入，两周内可落地），最后建设CI/CD流水线和多环境部署（重投入，但每一分钱都值得）。

原创 6.【.NET10 实战--孢子记账--产品智能化】--认证与安全包

本文介绍了对项目中三个核心安全依赖包（OpenIddict、Azure.Identity和System.IdentityModel.Tokens.Jwt）的系统性升级方案。通过AI辅助的方式，文章详细阐述了升级前的准备工作，包括版本梳理、兼容性检查和风险预案制定。升级操作采用AI自动化处理，能够智能解决版本冲突问题，确保对.NET 10框架的支持。文末提供了具体的升级包清单，涵盖各组件在不同服务中的当前版本和目标版本，并强调升级后需进行全面兼容性验证。该升级方案旨在提升系统安全性，同时通过自动化手段降低人工

原创 5.【.NET10 实战--孢子记账--产品智能化】--基础框架与微软官方包批量升级

本文介绍了如何利用AI工具高效完成.NET项目从8.0到10.0的升级工作。重点展示了两个核心环节：基础框架升级和微软官方包批量升级。作者采用"从底层向上推进"的策略，将规律性强、重复度高的机械性工作交给AI处理，包括修改.csproj文件、更新Dockerfile镜像标签、清理冗余包引用等操作。通过清晰的指令设计，AI能够准确执行版本替换、依赖关系调整等任务，并在完成后自动验证修改结果。文中特别强调了与AI的协作方式：明确任务需求、跟踪执行过程、及时检查反馈，这种模式不仅提高了升级效率

原创 35_批量异步处理：长流程Skill成本优化与结果追踪

本文探讨了如何构建可运营的长流程和批量任务处理系统。核心观点包括： 同步与异步的选择标准：应根据任务耗时、依赖复杂度、输入规模等因素决定执行方式，而非盲目追求实时性。 异步系统的关键设计： 状态追踪必须清晰可见，区分不同阶段 结果回传机制要可靠 部分失败需有补偿机制 批量处理要考虑成本优化与公平性平衡 系统评估指标： 除吞吐量外，还需关注等待时长、补偿成功率、状态可见性等综合指标 工程实现要点： 异步路由层需可解释 进度反馈要真实可靠 批量处理要分层优化 异常情况要有明确处理流程 文章强调，真正的生产级系统

原创 4.【.NET10 实战--孢子记账--产品智能化】--C# 14 新语法特性详解与实战应用

C# 14 带来多项实用改进：扩展成员语法统一支持方法、属性与运算符，field 关键字简化半自动属性实现，空条件赋值减少冗余判空代码，Span 隐式转换优化零拷贝操作。这些特性虽非颠覆性创新，但显著提升了开发效率与代码可读性，尤其在扩展方法重构和属性封装场景中体现明显价值。

原创 3.【.NET10 实战--孢子记账--产品智能化】--.NET 10 核心新特性概览：运行时与 ASP.NET Core 10

摘要：.NET 10作为新的LTS版本，延续了高性能路线，在JIT编译器、栈上分配和NativeAOT等方面带来显著优化。运行时层面改进了结构体参数处理、循环分析和数组接口去虚化，使代码执行更高效；ASP.NET Core 10则增强了Minimal API验证、OpenAPI集成和可观测性，提升开发体验。这些改进不仅优化性能，还影响代码组织方式，建议在升级前先深入理解平台行为变化，以便后续改造更有针对性。

原创 34_Skill编排与状态管理：从单Skill到多Skill工作流

文章摘要：本文探讨了多Skill工作流系统的常见误区与设计要点。首先指出三个常见误解：工作流不等于多步骤Prompt、状态管理不是存储所有上下文、编排难点在于异常恢复而非主流程。随后提出编排层应专注于流程决策而非执行细节，强调路由决策的可解释性。在状态管理方面，建议将状态分类为持久状态、瞬时上下文和恢复状态，并重视版本控制。检查点机制被强调为长流程运营的关键，需与副作用管理结合设计。最后指出输入输出契约的稳定性直接影响系统可靠性，并提出应关注多维评估指标而非单一完成率。全文旨在将多Skill工作流从概念转化

原创 33_Skill容错设计：重试策略+降级分支+优雅退化

文章摘要： 本文探讨了生产级系统容错设计的核心原则，指出真正成熟的系统不在于主流程的成功率，而在于对失败路径的系统化处理。作者首先破除三大误区：不是所有失败都该重试、降级不是简单删功能、优雅退化的关键在透明而非礼貌。随后提出具体方案：重试应作为显式策略层而非代码习惯；降级要保住关键交付而非所有功能；优雅退化需提供清晰的可执行方案。最后强调容错策略本身有成本，应区分统计各类结果，并将失败路径纳入主设计而非后期补丁。全文强调透明、边界清晰和预期管理的重要性，指出好的容错是让失败变得有边界、有节奏、有退路。（14

原创 32_生产级Skill可观测性：日志+成本追踪+失败告警

文章摘要：本文强调可观测性在AI技能系统中的核心价值，指出缺乏系统观测将导致团队陷入盲目优化和故障排查的困境。作者提出可观测性应从传统软件工程概念转化为具体设计实践，包括：1）建立包含决策路径、重试机制等关键字段的标准化日志体系；2）实现步骤级成本追踪以识别结构性异常；3）设计分级告警系统避免警报疲劳；4）前置处理敏感信息合规问题。文章指出，真正的可观测性应能缩短故障定位时间、提高优化精准度，最终使系统具备可诊断、可运营的生产级能力。

原创 31_Document处理通用Skill：多格式抽取+结构化输出+校验层

企业级文档处理系统的核心挑战不在于模型智能度，而在于如何处理现实世界中杂乱无章的输入格式。本文提出三层架构解决方案：抽取层负责生成标准化中间表示（保留文本块、定位信息及解析警告），结构化层将内容映射到业务字段（明确标注缺失项和来源），校验层评估结果可信度（给出明确的流程决策建议）。关键在于建立完整的定位追踪系统（location_map和source_locations），这是实现可信度验证、人工复核和错误分析的基础。文档处理不应追求表面成功率，而应防范静默错误，确保系统输出可验证、可追溯。

原创 30_教育培训Skills：学习路径+作业批改+教学大纲生成

教育培训领域的关键不在于生成大量内容，而是需要围绕学习者状态进行持续调整和路径优化。文章指出，教育系统不应是零散功能的拼盘，而要构建包含路径规划、作业批改和教学大纲生成的闭环体系。其中，学习路径需要基于诊断结果动态调整，作业批改应提供结构化反馈而非简单评分，教学大纲则要与课时和评估相匹配。教育场景的核心价值在于状态回流和持续优化，这使其成为展示状态管理和工作流编排的典型案例。真正的教学系统必须能够根据学习者表现不断校准路径，而非停留在一次性问答层面。