Category: Backend

2026

Backend

从 LLM 到 Agent（下）：工程、框架与交付实践

前言上篇我们把“Agent 从哪来”讲清楚了：LLM/Chatbot 的结构性局限决定了它“会答”不等于“会做事”，而 Tool Calling / MCP / ReAct / DeepResearch 则让推理如何与证据、行动与产物形成闭环。 但当你真正开始落地时，会发现 Agent 的难点不在“让模型更聪明”，而在“让系统更可靠”：工具会失败、上下文会爆、成本与时延要控、权限与风险要收口、产物

Backend

从 LLM 到 Agent（上）：原理、局限与演进脉络

前言2025 年结束，Agent 这个概念在所有科技行业从业者中每天都会听到 10 次以上。那到底什么是 Agent，为什么有了 LLM 不够，还要做 Agent，我们是怎么从 LLM 演进到 Agent 的？ 本文尝试从下面两个方面解释清楚上面的问题： 理解 LLM/Chatbot 的结构性局限：为什么“会答”不等于“会做事” 搞清 Tool Calling / MCP / ReAct / D

2024

Backend

HTTP 请求的优雅取消（Graceful Cancellation）

我们经常会写一些“很慢”的 HTTP 接口：比如触发导出、跑一段复杂计算、调用外部服务、或者生成大文件。 问题在于：客户端可能在任务完成前就取消了请求（关闭页面、点了取消、网络切换、超时等）。 那服务端能不能“及时知道”客户端已经取消？如果能知道，就可以尽早停止后续的昂贵操作，省 CPU/IO/下游资源。 这篇文章用一个简单的 Go + Gin 示例，把常见场景拆开说清楚： 不经过 Nginx：

Backend

HTTP Graceful Cancellation

Suppose we’re writing an HTTP server with an endpoint that takes a long time to finish. A client may start a request and then cancel it before the handler completes (closing the tab, navigating away,

2023

Backend

本地限流器实战：四种经典算法与实现思路

高 QPS 的后端服务，几乎一定需要“限流”（Rate Limiting）。 这里讨论的是本地限流器（local rate limiter）：限流状态只存在于单个进程/单个实例中，不和其他实例共享。 它的目标很朴素： 在流量突增时保护服务自身（CPU/线程池/DB 连接/下游依赖） 让系统吞吐更可控，避免被瞬时尖峰打穿 本地限流最常见的四种算法： 固定窗口（Fixed Window） 滑动窗

Backend

Rate Limiter In Action

Backend systems that handle high QPS often need a local rate limiter to protect themselves. Here, “local” means the limiter runs within a single process and does not coordinate state across instances.

2022
2021

Backend

MySQL InnoDB Locks

InnoDB is MySQL’s transactional storage engine. After more than a decade of development, it has become the default choice for most production workloads. There are plenty of good deep-dives on InnoDB

2018

Backend

多级缓存的设计与实现

在高并发的后端业务中，多级缓存是一种非常常见的设计。事实上，多级缓存策略在计算机硬件中也普遍存在。 为什么会有多级缓存？通常缓存都比原数据要小。设立缓存的目的很简单：某些数据经常被访问，我们不想每次都去最深的地方（这里一般是指数据库）查找，所以会在更方便取到数据的地方把这些数据保存起来。 那么，为什么要用多级缓存呢？对所有数据来说，访问频率并不一致。对于访问频率非常高的数据，我们称为热点数据。例