LangChain与AutoGPT双核驱动：手写Agent记忆循环与容错机制
当AutoGPT的无限递归让Token消耗飙升至$0.8/次任务失败时，我决定用LangChain重写Agent内核。本文记录了一个生产级Agent的诞生过程：通过Zep开源库实现滑动窗口记忆，使上下文检索准确率从62%提升至91%；引入LangGraph的状态机循环控制，将死循环率降低至0.3%。手写实现工具注册表、异常熔断器与流式输出，最终在MATH-500基准上达到78.4%的准确率，单次任
FastAPI接口延迟飙到2.8秒，我用cProfile和Redis把P95砍到180ms
一个内部数据看板接口，单次请求要聚合7张表的数据，上线后P95延迟高达2.8秒，被业务方连续投诉三天。这篇文章记录了我完整的调优过程：先用cProfile和py-spy定位到瓶颈在N+1查询和JSON序列化，然后通过SQLAlchemy 2.0的selectinload优化查询、引入Redis缓存热点聚合结果、最后用orjson替换标准json库。压测数据从wrk的123 QPS提升到892 QP
Docker Compose编排多服务容器化部署：网络、卷、健康检查与启动顺序
本文分享一个生产级多服务项目的docker-compose.yml配置，涵盖自定义网络、命名卷挂载、依赖健康检查与启动顺序控制，解决服务启动竞态与数据持久化问题。配置基于Docker Compose v2.20+与Docker Engine 24.0，包含PostgreSQL 15、Redis 7、Nginx 1.25及Spring Boot应用四节点编排。通过实际压测数据，展示健康检查将服务可用
RAG召回率从67%到89%：chunk重构与混合检索调优实录
在构建企业知识库问答系统时，我们遭遇了召回质量瓶颈：针对技术文档的复杂查询，基于固定512字符分块的RAG召回率仅67%，且Top-5命中率不足50%。通过将分块策略改为“章节语义边界+重叠窗口”、Embedding模型从BGE-large-zh切换至BGE-M3、并引入Cohere Rerank重排序，最终将召回率提升至89%，Top-5命中率提升至78%。本文将完整记录这一调优过程，附全部核心
RAG命中率从61%到89%：chunk重构与embedding选型全记录
两个月前我们的内部知识库RAG系统还处于“能跑但不可用”的状态——检索命中率仅61%，用户问“发票报销流程”返回的是“差旅费管理制度”。本文记录一次完整的RAG系统优化过程：从vLLM部署的Qwen2.5-7B，到BGE-large-zh-v1.5与text2vec-large-chinese的PK，再到引入bge-reranker-v2-m3。通过重构chunk策略（固定256字符→语义段落），
告别Prop Drilling：React 18与Vue 3项目迁移至Zustand与Pinia的工程化实践
在维护一个超500个组件的中后台项目时，Context/Props层层透传导致重渲染次数激增42%，且新成员接手成本极高。本文记录了我们将React 18项目迁移至Zustand 4.x、Vue 3项目迁移至Pinia 2.x的完整过程。通过对比三种方案的内存占用、渲染性能与代码量，给出了详细的迁移步骤、核心代码示例及性能优化数据。迁移后，React项目首屏渲染时间从2.3s降至1.1s，Vue项
Git分支策略与Code Review流水线：支撑20人团队的协作体系
当团队从5人扩张到20人，主干开发模式导致的代码冲突率飙升300%，发布前集成耗时从30分钟增长到3小时。本文基于Git 2.39.1与GitLab 15.11，落地了一套基于Trunk-based的分支策略，配合强制Code Review与CI/CD流水线。通过引入pre-commit钩子、GitLab CI的merge request pipeline，将平均代码审查周期压缩至4.2小时，线上
LangChain与AutoGPT双引擎：手写AI Agent核心循环的五个关键实现
当AutoGPT的无限循环撞上LangChain的工具调用链，一个能稳定运行200轮不崩的Agent需要怎样的骨架？本文记录了我用LangChain 0.1.0重写AutoGPT核心循环的完整过程。从工具定义到记忆压缩，从异常重试到循环终止条件，手写一个支持Python代码执行、文件搜索、算术计算的Agent。实测单轮工具调用延迟从3.2秒降到1.8秒，内存占用稳定在480MB，连续运行6小时无死
LangChain+AutoGPT思想手写Agent：循环控制与记忆管理全解析
上周在开发一个代码审查助手时，我尝试用LangChain 0.2.1搭建了一个具备AutoGPT风格的Agent，但发现官方AgentExecutor在连续执行超过5轮后内存占用飙升到1.2GB，且工具调用失败时无法自愈。于是我用约300行代码手写了一个轻量Agent，将工具定义抽象为Pydantic模型，用双端队列实现滑动窗口记忆，并引入最大重试次数与错误注入机制。最终在12个真实测试用例上，任
RAG问答延迟降低42%：chunk重构与embedding选型及rerank重排全记录
线上知识库问答系统在2000+文档规模下暴露出召回准确率低、幻觉严重等问题。本文记录了从v1.0到v3.0的三轮优化：将固定256字符chunk改为基于语义边界的动态切片，命中率提升18%；将BGE-small替换为bge-m3，召回Recall@5从68.5%提升至79.2%；最后引入bge-reranker-base重排，Top-1准确率从61%跃升至82%，整体首响延迟仅增加85ms（从68
Docker Compose编排多服务：网络隔离与健康检查的工程实践
本文记录一次真实的多服务容器化部署经历，涉及Nginx、Spring Boot应用、PostgreSQL、Redis共4个服务。通过docker-compose.yml配置，解决服务间网络通信、数据卷持久化、启动顺序依赖三大核心问题。实测部署时间从手工配置的30分钟缩短至2分钟，服务启动失败率降低80%。文中包含完整的compose文件、健康检查配置参数及容器启动顺序验证方案，适合需要快速搭建生产
asyncio重构Flask接口：并发吞吐提升340%的完整记录
一个基于Flask 2.2 + MySQL的订单查询接口，在QPS 120时P99延迟飙到2.8s。改用asyncio + aiomysql + uvloop后，同样的16C16G机器压测，QPS稳定到528，P99降到410ms。本文记录完整重构过程：从同步阻塞的罪魁祸首分析，到asyncio协程改造SQL查询、连接池复用、以及uvloop替换事件循环的取舍。含前置代码、改造后代码、wrk压测数
asyncio重构Flask接口，QPS从120飙到850的全记录
上周我把一个基于Flask的同步商品详情聚合接口改成asyncio协程版，压测结果从120 QPS直接干到850 QPS，P99延迟从2.3s降到380ms。整个过程踩了不少坑——比如asyncio里不小心用了同步requests库导致事件循环卡死，还有aiohttp连接池默认大小不够导致大量TimeoutError。这篇文章会完整记录这次改造的技术方案、核心代码（含before/after）、以
RAG问答延迟砍半：chunk重切+embedding换型+rerank三段式调优实录
线上RAG系统初期Answer Pass Rate仅61%，首Token延迟高达1.8s。本文记录一次完整的检索链路手术：将固定256字chunk改为按Markdown标题自适应切片（平均966字/块），Embedding从text2vec-large-chinese切换至bge-large-zh-v1.5（维度1024，余弦相似度阈值从0.55压到0.42），并在召回Top20后引入bge-re
React 19与Vue 3.5下从Context到Zustand/Pinia的状态迁移实录
在支撑百万级PV的电商后台项目中，Context/Props层层透传导致组件重渲染次数暴增320%，交互延迟突破120ms。本文记录将React 19.1与Vue 3.5混布项目核心模块从Context/Props迁移至Zustand 5.0与Pinia 3.0的全过程，对比三种方案的内存占用（Context：68MB vs Zustand：41MB）、渲染耗时（Props：23.6ms vs P
asyncio重构Flask接口：QPS从300到1800的并发优化实录
一个内部报表接口因串行调用3次第三方服务，平均耗时2.8秒，压测QPS仅320。用asyncio+httpx将其改造为并发请求后，接口耗时降至0.6秒，QPS飙升至1750。本文记录完整改造流程，包括asyncio.Semaphore限流、httpx.AsyncClient连接池复用、以及Python 3.10+的TaskGroup写法，并附上wrk压测对比数据。踩坑部分重点分析了协程与线程混用导
7B模型LoRA微调实录：显存9.3G吞吐提升3.1倍的调参全流程
在单卡A100(80G)上对Llama-2-7B-Chat进行LoRA微调，采用peft 0.5.0+transformers 4.36.2，rank=8时训练显存仅9.3GB，相比全参微调降低72.6%。通过构造中文医疗指令集3.2万条，训练3个epoch后，模型在CMB医学问答基准上BLEU从5.2提升至12.8，F1从0.31升至0.61。本文记录从数据清洗到推理部署的完整链路，包含三个关键
Docker Compose编排多服务容器化部署：网络、卷挂载与健康检查全解析
本文基于Docker Compose 2.24.0，详细拆解一个包含Nginx、Spring Boot后端、PostgreSQL、Redis四服务的生产级编排方案。重点演示自定义Bridge网络隔离、命名卷持久化、依赖健康检查（healthcheck + depends_on.condition）以及启动顺序控制。通过实际压测数据：服务启动时间从串行的47秒缩短至23秒，容器重启故障恢复时间控制在
React 18与Vue 3告别Props钻透：Zustand与Pinia迁移实录
项目从React 16升级到React 18，同时Vue 2老项目重构为Vue 3，两者都面临组件层级深、Props/Context传递混乱导致的重复渲染问题。本文记录了分别迁移到Zustand 4.4.7和Pinia 2.1.7的完整过程。通过对比Context/Props与状态管理库的性能差异，用Lighthouse和React Profiler数据说明：迁移后首屏渲染时间平均减少23%，交互
Prompt Engineering实验对比：从5.2%到68.4%的准确率跃升
同一文本分类任务，使用零样本、少样本、思维链与自我一致性四种Prompt方案，在GPT-4o-mini上准确率从5.2%提升至68.4%，单次推理token消耗从312增至1867。本文记录完整实验过程，包含Prompt模板、OpenAI SDK调用代码、成本核算与失败案例分析，证明结构化Prompt对输出质量的杠杆效应远大于模型微调。
