前言最近在折腾 AI Agent 和模型接入相关的事情时，意外发现英伟达居然提供了一个面向开发者、可以免费调用模型 API 的平台。更关键的是，这个平台上不仅能用到一些主流开源模型，还能直接使用最近热度很高，号称开源 Coding 能力最强的 GLM4.7，以及综合表现相当稳的 minimax-m2.1。 说实话，在如今 API 几乎全面 token 计费、随便一个复杂任务就轻松几十万甚至上百万

前言从去年入职新公司之后，我主要在做的一个前端项目，仅源码体积就接近 1G。说实话，刚接触的时候我也觉得很离谱：一个前端项目为什么能做到这么大？更离谱的是，打包产物能膨胀到 5G。至于它为什么会这样、有没有优化空间，这些并不在本文讨论范围内，也不是我当下能决定的事情。 在这样的体量下，每次切换分支、拉取代码，VS Code 都非常容易卡死。在每次 Git checkout / pull

前言在前两篇中，我们已经比较系统地梳理了 AI Agent 的发展历程，也对 AI Agent 和 AI Workflow 之间的区别做过一次完整的拆解，同时重点讲解了目前最经典、也是被讨论最多的 ReAct 模式。这一篇我们继续介绍另一个在工程实践中同样非常重要、并且经常和 ReAct 搭配使用的模式：Plan and Execute（简称 P&E）。 P&E 的核心思想其实并不

前言上一篇我们介绍了 AI 应用的发展历程以及 Agent 的整体概念，这一篇将针对 ReAct（Reasoning + Acting）模式，并对其设计思想和工程实现进行一次更为系统、偏实战向的讲解。 在讲解 ReAct 之前，有必要先澄清一个经常被混用的问题：Agent 到底是什么？ 在早期以及当下大量工程实践中，不同 AI 应用对 Agent 的定义并不一致。很多所谓的 Agent，本质上更接

前言这周在组内做了一次关于 Agent 设计模式 的分享，主要介绍和讲解了 ReAct 模式 与 P&A（Plan and Execute）模式。我计划将这次分享拆分为三篇文章，对我在组会中讲解的内容进行更加系统和细致的整理。 在正式进入具体的 Agent 模式实现之前，有一个绕不开的问题需要先回答清楚： 什么是 AI Agent？它解决了什么问题？以及在近几年 AI 技术与应用快速演进

前言最近在学习大模型的实现原理，为了更好地理解整个流程，我把学习中的关键概念和实现细节整理成了笔记。一方面帮助自己梳理思路、加深印象，另一方面也作为日后复习和查阅的基础。内容会按照模型的实际处理流程展开，希望能以清晰易懂的方式记录大模型的核心机制。 大模型原理概述大模型最经典的架构图来自《Attention Is All You Need》，从这张图可以看到 Transformer 的基础结构是由

前言在 Gin 中实现一个中间件是一件非常轻量的事情，几乎没有“生命周期钩子”这种复杂概念，也不需要学习多少新 API。只需要返回一个 gin.HandlerFunc 类型的函数即可。 得益于 Gin 的“洋葱模型”执行链路机制，我们可以利用 ctx.Abort 中断请求，也可以利用 ctx.Next 控制中间件在请求前/请求后两个阶段执行逻辑，从而轻松实现日志、鉴权、限流等能力。 本篇

前言在第一篇 Gin - Hello World 中，我们提到过：gin.Default() 本质上就是帮你提前挂载了两个默认中间件（Logger 和 Recovery）。这一篇我们就动手来体验一下 手动注册中间件，顺便更清楚地理解 Logger 和 Recovery 的实现原理。 使用中间件Gin 的中间件机制本质上是一个典型的洋葱模型（pipeline）处理结构。每一个中间件都是一个 gin.

前言在 Gin 中实现一个自定义验证器，本质上就是 实现一个函数 + 注册它 + 在结构体标签里使用它。Validator 底层用的是 go-playground/validator/v10，所以整个流程也完全遵循该库的规则。 1. 实现一个验证器函数要写一个验证器，说白了就是写一个回调函数，这个函数最终会被 Gin 的 Validator 调用。它的签名非常固定： 1func(fl valida

介绍dive 是 Gin 依赖的 go-playground/validator 库中专门用于切片（slice）/数组的校验标签，作用是「穿透切片外层，对切片内的每个元素执行后续校验规则」。 一、核心场景：切片必传 + 元素规则校验场景 1：仅要求「切片必传 + 每个元素长度 ≥1」需求拆解： 必传 tags 字段（不允许 JSON 中缺失该字段，即切片不能为 nil） 切片内每个 ta