架构师老Y-优快云博客

原创 004. curl_cffi 实战：在 Python 中复现浏览器网络指纹

本文从requests触发 403 的现象出发，解释了 TLS/HTTP2 指纹在握手阶段识别的机制，并利用curl_cffi在 Python 中复现浏览器网络指纹。参数不只是协议栈预设，它还会自动设置浏览器默认请求头（含 UA）；手动覆盖请求头时必须保持一致性。通过在线指纹服务和本地抓包两种验证途径，可以确认curl_cffi与默认requests在 JA3/JA4 上的显著差异。排错清单覆盖了 ALPN、异步 API、代理/证书、HTTP/2 连接复用和 TCP 指纹等维度。

2026-09-13 17:59:45 100

原创 010. 综合实战：异步并发网关与全专栏回顾展望

回到第 001 篇的起点，我们最初要解决的问题是“为什么同步阻塞模型在大量 I/O 场景下效率低下”。协程与事件循环async def函数只有在事件循环中才真正执行，await点在让出控制权的同时保留了调用状态；Task 与 FutureTask是调度和取消的基本单元，Future表示尚未完成的结果，理解它们的状态流转是使用高层 API 的前提；并发编排TaskGroupgather各有边界，结构化并发让任务生命周期可控；取消与异常组：协作式取消和保证失败传播不丢失信息，except*允许选择性处理。

2026-09-13 14:12:49 138

原创 008. 事件循环性能调优：uvloop、阻塞检测与连接池参数

本文围绕 asyncio 应用常见的三类性能瓶颈展开：事件循环实现、阻塞调用和连接池策略。uvloop 利用 libuv 优化了事件循环调度能力，可以在很多网络 I/O 场景中提升吞吐，但它不能替代对业务阻塞点的治理。asyncio debug 模式与让慢回调从隐性抖动变为可定位证据，是从正确性排查走向性能排查的关键工具。连接池参数则是一项需要持续权衡的控制阀：太小会排队，太大会溢出到远端，合适值来自测量而非猜测。

2026-09-13 14:11:47 61

原创 002. 事件循环、Future 与 Task：asyncio 的调度核心

本文从“直接调用协程函数为什么不会执行”入手，落到与的事件循环生命周期管理上。async def调用后得到协程对象，不执行函数体。创建并关闭事件循环，是普通脚本的标准入口，不应嵌套使用。事件循环负责推进所有可等待对象，Task 是并发调度的基本单元。Task包装协程并立即排队，Future表示最终结果，Task是Future的协程驱动子类。是应用代码创建任务的推荐方式；更适合兼容旧接口或处理未知可等待对象。Runner为命令行和持久应用提供了更细致的事件循环资源管理。

2026-09-13 14:09:47 124

原创 001. 从同步阻塞到事件循环：Python 异步编程的认知框架

本篇文章建立了 Python 异步编程的第一个认知框架：同步阻塞 I/O 在高并发网络场景下会因为等待单个连接而冻结整个线程，导致吞吐量受限、延迟升高；事件循环通过非阻塞 Socket 和协作式调度，在单线程内交替执行多个协程，解决了 I/O 等待期间的空转问题；语法则提供了“可暂停、可恢复”的函数执行模型，让开发者可以像写同步代码一样编写异步逻辑，但底层并不是多线程并行。需要记住的核心结论是：协程不是线程；await不是阻塞调用；asyncio适合网络 I/O 密集场景，而不是 CPU 密集计算；

2026-09-13 14:08:46 173

原创 025、记忆系统：短期记忆与长期记忆

咱们做一个智能客服Agent，能记住用户历史咨询。比如用户第一次问“我的订单号是12345”，第二次问“那个订单到哪了？”，Agent应该能关联。"""智能客服Agent，带记忆系统"""self.session_id = None # 实际生产用UUID"""处理用户查询，集成记忆检索"""# 1. 检索长期记忆，获取用户历史# 拼接历史上下文if score < 0.8: # 相似度阈值，太低不采用continuecontext += f"[历史记录]

2026-05-01 16:44:26 216

原创 024、多工具协调：Agent的规划与执行

上篇咱们聊了如何给Agent“插上”自定义API和插件，就像给机器人装上了各种工具。但工具多了，问题就来了：Agent该先用哪个？怎么串起来？失败了怎么办？这篇咱们就深入聊聊Agent的“大脑”——规划与执行引擎。我会结合生产中的踩坑经历，手撕ReAct、Plan-and-Execute等核心模式，并附上完整的代码实现。

2026-05-01 16:39:38 169

原创 023、Agent工具开发：自定义API与插件

上篇文章咱们手撸了Function Calling的协议，把大模型和外部函数连上了。但真正的Agent开发里，你不可能每次都手写函数定义——那些API调用、数据库查询、计算器逻辑，必须封装成可复用的“工具”。今天咱们就深入源码，聊聊如何把外部能力做成Agent的插件，顺便把错误处理和超时这种“生产杀手”给干掉。

2026-05-01 16:37:32 243

原创 022、Function Calling实战：工具定义与调用

Function Calling的Schema遵循JSON Schema标准# 一个复杂的工具Schema示例"description": "预订航班，支持单程和往返","from": {"description": "出发地机场代码，如PEK" # 用代码而不是城市名，减少歧义},"to": {"description": "目的地机场代码，如SHA"},"date": {"format": "date", # 指定日期格式。

2026-05-01 16:36:59 77

原创 021、ReAct模式：推理与行动的结合

ReAct是“Reasoning + Acting”的缩写，由Shunyu Yao等人在2022年的论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出。它的核心思想是：让LLM在每一步中都交替进行“推理”（思考下一步做什么）和“行动”（执行具体动作），并基于行动结果继续推理，形成闭环。思考：“电脑蓝屏了，可能是内存问题。行动：打开机箱，拔插内存条。观察：电脑依然蓝屏，错误代码变了。思考：“可能是驱动问题。行动。

2026-05-01 16:29:45 134

原创 020、Agent概念解析：从LLM到自主行动

工具描述的质量直接决定Agent成败。我总结了一个黄金法则名称：动词+名词，如，不要用weather（LLM可能理解成名词）。描述：包含使用场景和示例，如“用于获取某个城市的实时天气，比如北京或上海”。参数：明确类型、枚举值、示例。比如城市参数加enum: ["北京", "上海"]，LLM就不会传“东京”。

2026-04-30 22:41:48 220

原创 019、RAG进阶：多轮对话与记忆管理

假设用户和系统聊了10轮，每轮平均200 tokens，总长2000 tokens。如果直接拼接，不仅浪费LLM的上下文窗口，还会让检索器“迷失”在无关细节中。压缩的核心是提取对话的语义骨架，去掉闲聊、重复、无关的细节。我一开始用摘要压缩，让LLM对每5轮对话生成摘要。结果发现，当对话涉及敏感信息（如用户地址、银行卡号）时，摘要会“创造”出不存在的内容——比如用户说“我的卡号是1234”，摘要却写成“用户提供了银行卡号是5678”。这是LLM的幻觉在作祟。解决方案：对关键实体（如数字、日期、人名）做。

2026-04-30 22:41:09 262

原创 018、RAG系统评估：指标与自动化测试

这个坑我踩得最深。有次我们的Recall@10达到了0.95，但用户反馈说“搜出来的都是边角料”。后来发现，标注人员把“部分相关”也标记为“相关”，比如用户问“Python装饰器”，标注人员把“Python函数基础”也标为相关。这导致Retrieval得分虚高，但实际效果很差。解决方案：严格区分“完全相关”和“部分相关”，评估时只计算完全相关。或者使用NDCG（归一化折损累计增益），给不同相关度分配不同权重。语义理解。比如用户问“哪个Python库最适合做数据分析？”，系统回答“Pandas很好用”。

2026-04-30 22:40:32 231

原创 017、RAG Prompt优化：将检索结果融入生成

以为检索质量决定一切。重排序、过滤做得再好，如果Prompt设计不当，模型依然可能“跑偏”。这就像你给一个顶级厨师（大模型）准备了上等食材（检索结果），但食谱（Prompt）没写清楚，他可能把鱼香肉丝做成水煮鱼。如何将检索结果融入生成？结构化：不要生硬拼接，用Markdown、编号、标签让文档“有形状”。引导：通过指令、位置、高亮，让模型知道“看哪里”。防御：显式隔离文档、标记优先级、动态截断，防止“污染”。Prompt是RAG系统的“最后一公里”。检索做得好，只成功了50%；

2026-04-30 22:39:42 189

原创 016、RAG中的重排序与过滤机制

上一篇咱们聊了混合检索，把稀疏和稠密向量组合起来，确实能召回更多相关文档。但有个头疼的问题：召回的Top-K里，总有几篇“滥竽充数”的，或者排序靠前的文档其实相关性一般。这就是今天要解决的——检索后处理。重排序模型（Cross-encoder）能精打细算地重新打分，过滤机制能剔除噪声，去重能避免信息冗余。咱们直接上代码和原理，看看如何让LLM吃到“干净”的上下文。

2026-04-30 22:38:13 169

原创 015、检索策略：相似度搜索与混合检索

相似度搜索不是“一个度量打天下”，余弦适合文本，点积适合推荐，欧氏适合图像。而混合检索通过BM25+向量的融合，解决了纯语义搜索的“歧义”问题。关键是调好alpha、k1、b这些参数，以及处理高维向量的维度诅咒。

2026-04-29 08:48:34 192

原创 014、向量数据库实战：Milvus、Chroma与Pinecone

上一期咱们聊了如何用Sentence-Transformers把文本“拧”成向量，结果发现Embedding模型选对了，但存进去之后查起来却慢得像蜗牛爬——这就是向量数据库的锅。本文从源码层面剖析Milvus、Chroma、Pinecone的索引原理、安装配置、性能瓶颈，并给出选型决策树，帮你避开“分布式部署后索引炸了”的坑。

2026-04-29 08:47:52 218

原创 013、向量化与Embedding模型选型

Embedding向量生成后，我们需要计算两个向量之间的“距离”来判断语义相似度。最常用的是余弦相似度为什么不是欧氏距离？因为Embedding向量的模长往往不稳定。比如“好”和“非常好”的向量方向相近，但模长可能差很多（“非常好”的每个维度值更大）。余弦相似度只关注方向，模长被归一化，所以更能捕捉语义方向的一致性。实战经验：OpenAI的Embedding默认就是L2归一化后的向量，直接用点积就能得到余弦相似度，省去了手动归一化的步骤。而BGE的原始向量未归一化，需要显式调用。

2026-04-29 08:47:21 221

原创 012、文档解析与分块策略：从PDF到知识库

咱们先看一个典型场景——你拿到一份PDF，里面既有大段文字，又有表格，还有代码块。直接扔给大模型？99%的模型会告诉你“抱歉，我无法解析这种格式”。但你知道，PDF里的内容其实是“视觉排版”的产物，不是文本流。比如一个表格在PDF里可能拆成了几十个坐标位置，你直接提取文本，得到的是一堆乱序的碎片。我踩过的坑：有一次做金融研报的RAG，PDF里表格的“合计”行被单独提取到了下一页末尾，结果大模型回答“公司总资产为-1000万”，因为解析把负号单独拎出来和数字分开了。这种坑，不是模型不聪明，是解析没做好。

2026-04-29 08:46:39 237

原创 011、RAG入门：为什么需要检索增强生成

上一期咱们聊了Prompt注入攻击，你可能会想：LLM连自己的“边界”都守不住，还敢让它回答专业问题？别急，今天讲的RAG（检索增强生成）正是解决这个痛点的利器——它让LLM从“闭卷考试”变成“开卷考试”，知识局限和幻觉问题迎刃而解。

2026-04-29 08:45:19 149

原创 010、Prompt注入攻击与安全防护

即使模型被注入，也无法访问核心资源。使用沙箱、最小权限原则。import os"""Prompt沙箱：隔离模型执行环境"""# 定义沙箱允许的操作白名单"query_product": True, # 允许查产品"get_weather": True, # 允许查天气"access_database": False, # 禁止访问数据库"read_file": False, # 禁止读文件"execute_command": False, # 禁止执行命令。

2026-04-28 14:29:00 239

原创 009、上下文窗口管理：长度限制与信息压缩

summary_compression.py - 智能压缩client = OpenAI() # 假设已配置API Key"""用LLM压缩历史：将旧对话总结成一句话，保留关键信息。🚀 核心思路：牺牲细节，保留上下文连贯性。Args:history: 对话历史max_tokens: 目标token上限Returns:压缩后的历史（包含系统指令 + 摘要 + 最近对话）"""# 1. 分离系统指令（绝对不能压缩！else:# 2. 计算当前总token数（略去计算细节）

2026-04-28 14:16:18 229

原创 008、输出控制：结构化输出与后处理技巧

咱们得先接受一个残酷现实：大模型本质是个“概率生成器”，它没有内置的格式校验逻辑。你让它输出JSON，它可能给你甩个Markdown表格，或者直接来段散文。我当年在京东做客服对话系统时，就因为模型在JSON里插了个“抱歉，我重新回答一下”的废话，导致整个解析流程崩溃，线上告警炸了半小时。2. 核心解决思路：Prompt约束 + 后处理兜底咱们的策略是“双保险”：这两个缺一不可，因为哪怕Prompt写得再好，模型还是可能抽风。就像你让实习生写报告，他大概率会写偏，你得有审校环节。这是我踩过无数坑后总结出的

2026-04-28 14:15:24 149

原创 007、大模型API调用避坑：Token、成本与速率限制

上篇《Prompt调优实战》咱们刚聊完怎么用迭代评估打磨提示词，结果你发现提示词写好了，API调用却崩了——要么Token超限报错，要么并发请求被限流，月底一看账单还血亏。这篇我就把生产环境中跟Token、成本和速率限制有关的那点破事全抖出来，包括底层源码分析和实战避坑方案。

2026-04-28 14:14:26 196

原创 006、Prompt调优实战：迭代、评估与自动化

上一篇咱们聊了思维链（CoT）如何让模型“慢思考”，但实际落地时，你会发现精心设计的Prompt经常翻车。本文将从手动迭代的“土办法”讲起，分享评估指标的设计逻辑，最后揭秘如何用LLM自己优化自己——这套方法论，我在大厂内部调优客服机器人时反复验证过。

2026-04-28 14:13:35 105

原创 005、思维链（Chain-of-Thought）与进阶推理技巧

模型缺乏隐式的“工作记忆”。CoT通过显式输出，模拟了人类在草稿纸上演算的过程，让模型能“看到”自己的中间状态。自洽性：用多次采样+投票，对抗单次推理的随机性。思维树：用树形搜索，处理更复杂的探索问题。一句话记住：如果模型直接回答让你心里没底，就让它“写草稿”。

2026-04-27 22:26:18 111

原创 004、少样本与零样本Prompt：何时用、怎么用

零样本：适合“开胃菜”任务——快速原型验证、通用问答、简单分类。但记住加“指令增强”，否则模型会放飞自我。少样本：适合“主菜”任务——格式严格（如 JSON 输出）、专业术语多、有歧义边界。示例选 3 个，动态检索，格式统一，成本可控。最后一句大白话：别指望模型是天才，它就是个“记性很好但理解力差”的学生。少样本就是给它“例题”，零样本就是让它“裸考”。考试想及格？至少给 3 道例题。

2026-04-27 22:25:46 118

原创 003、Prompt设计原则：清晰、具体、结构化

上篇咱们聊了“大模型交互的第一性原理”，说白了就是搞清楚Token怎么算、生成怎么停。但很多人还是栽在同一个坑里：写了半天Prompt，模型要么答非所问，要么给你一段万金油废话。今天咱们就死磕三个通用设计原则——清晰、具体、结构化。我会从生产踩坑里扒出正反案例，让你看完就能拿来用。

2026-04-27 22:25:02 211

原创 002、Prompt基础：大模型交互的第一性原理

这就是为什么LLM能处理复杂语义——它用多个“视角”同时分析你的Prompt。

2026-04-27 21:53:10 230

原创 001、LLM应用开发全景图：从Prompt到Agent的演进之路

本文为你绘制LLM应用开发的全景地图，从最基础的Prompt工程到复杂的Agent系统，梳理技术演进的主线脉络，帮你建立全局视野，避免在后续学习中迷路。

2026-04-27 21:52:13 234

原创 030、架构师思维：技术选型、权衡与未来趋势

我会问自己一个终极问题：如果三年后证明这个选型是错的，我们有没有退路？能不能平滑迁移？技术选型没有标准答案，只有适合当前团队、当前业务、当前时间点的相对优解。好的架构师不是追求最炫酷的技术栈，而是在无数个深夜告警中，依然能让你睡得着觉的那个人。记住：你今天引入的每一个依赖，都是明天要还的技术债。还得起的叫投资，还不起的叫坟墓。

2026-04-21 14:44:59 55

原创 029、高可用与灾备：多活架构与数据同步

去年双十一前夜，监控大屏突然弹出一条数据库主从延迟告警。当时业务流量还没起来，延迟却飙到30秒以上。紧急登录从库一看，发现binlog同步线程卡在一条update语句上——某个开发同事在业务表里加了个毫无索引的text字段，全表更新直接打满IO。主库勉强撑着，从库已经追不上进度。那一刻我意识到，传统的主从备份在高并发场景下有多脆弱：单点故障、同步延迟、容灾切换丢数据……这些问题不是简单的“一主多从”能解决的。

2026-04-20 22:35:40 152

原创 028、架构演进：从单体到微服务的重构策略

昨天深夜排查一个线上问题，单体服务里一个订单查询接口突然飙到8秒响应。翻日志发现关联的促销计算模块正在全表扫描——这原本只是个边缘功能，却拖垮了整个核心链路。这已经不是第一次了，每次某个非核心功能出问题，整个服务都得跟着重启。站在凌晨三点的屏幕前，我意识到：是时候认真考虑拆分了。

2026-04-20 22:35:00 238

原创 027、边缘计算与物联网后端架构：当设备开始“闹脾气”

（高频，小数据包）

2026-04-20 22:34:12 239

原创 026、微服务通信：gRPC与Protocol Buffers

上周深夜收到告警，某个订单查询接口间歇性返回数据不全。日志里没有异常抛出，但客户端拿到的订单列表总是缺最后几个字段。抓包发现HTTP响应体长度正常，但反序列化后的对象里amount和currency字段经常是默认值零和空字符串。第一反应是数据层问题，但检查数据库记录完整。接着怀疑序列化框架，这个服务用的是JSON over HTTP，字段名大小写、日期格式都反复核对过。直到在网关日志里看到一条线索：某个实例的响应时间明显偏长，触发网关超时截断了响应体。但为什么截断后还能解析成合法JSON，只是字段丢失？

2026-04-20 22:33:35 100

空空如也

空空如也