Sign in Subscribe
Gloary Lei

Gloary Lei

Thoughts, stories and ideas.

Flutter

Windows 安装配置 Flutter+Android Studio 开发环境

Flutter 的安装看似简单，但在实际操作中，特别是涉及到 Android 环境配置时，往往充满了“坑”。本文将带您一步步完成安装，并将原本占用 C 盘几十 GB 的 SDK 和模拟器文件全部迁移至 D 盘，还你一个清爽的系统盘。 第一步：基础环境准备 1. 安装 Git Flutter 依赖 Git 进行版本管理和依赖更新。 * 访问 Git 官网 下载并安装最新版。 * 安装过程中一路点击 "Next" 即可。 2. 配置国内镜像（关键！） 由于国内网络原因，直接下载 Flutter 依赖会非常慢甚至失败。我们需要配置环境变量使用国内镜像。 1. 按 Win + S 搜索
3 min read
ComfyUI

SAM3 笔记4：ComfyUI + SAM3 容器化部署

摘要： Meta 的 SAM3 (Segment Anything Model 3) 带来了强大的图像分割和视频跟踪能力。本文详细介绍了如何在 Docker 环境下部署 ComfyUI-SAM3，解决了依赖缺失、CUDA 编译加速以及模型路径配置等常见坑点，并提供了现成的 Docker 配置文件和测试工作流。 Meta 最近发布的 SAM3 在图像分割和视频对象跟踪方面表现出色。虽然 ComfyUI 社区迅速跟进适配了 PozzettiAndrea/ComfyUI-SAM3 插件，但在 Docker 环境下部署时，我们遇到了一系列依赖和环境问题。 本文将分享一套经过验证的 Docker 部署方案，包含显存优化、CUDA 加速编译以及常见报错修复。 1. 核心配置文件 我们将使用 pytorch/pytorch:2.5.1-cuda12.4-cudnn9-devel 作为基础镜像，以支持
6 min read
计算机视觉

在 RTX 4060 Ti 16G 上使用 Docker 部署 ComfyUI Z-Image (FP8版)

摘要：RTX 4060 Ti 16G 是运行 Z-Image 的“黄金甜点”显卡。本文记录了如何利用 FP8 量化技术、Docker 容器化部署，最终实现生图的全过程。 随着 Z-Image (S3-DiT架构) 的发布，AI 绘画进入了新的画质里程碑。但其庞大的参数量（6B 模型 + 3.4B 文本编码器）让许多显卡望而却步。 经过实测，RTX 4060 Ti 16GB 配合 FP8 量化 是目前性价比最高的解决方案。本文将手把手教你使用 Docker 部署这套环境。 1. 核心策略：为什么选 FP8？ 在开始动手前，我们需要明确模型版本的选择。Z-Image 有三种主流格式，对于
4 min read
SAM3

SAM3 笔记3：基于 Docker + GPU 的部署方案

引言 2025年11月，Meta Research 正式发布了 SAM 3 (Segment Anything Model 3)。作为一个统一了图像分割、视频跟踪和概念检测的端到端基础模型，SAM 3 的强大毋庸置疑。 但对于工程部署来说，SAM 3 带来了一个巨大的挑战：激进的环境依赖。它强制要求 Python 3.12+、PyTorch 2.7 (预览版) 和 CUDA 12.6+。如果在本地 Windows 或 WSL 环境中直接配置，极易引发“依赖地狱”，破坏现有的环境。 本文将分享如何在 Windows WSL 2 环境下，利用 Docker 和 NVIDIA
6 min read
智能体

Browser-Use笔记2：安装与测试

1. 安装 Browser-Use # 使用 pip 安装 python -m pip install browser-use # 验证安装 python -m pip list | findstr browser-use 安装输出示例： Successfully installed browser-use-0.10.1 ... 2. 安装 Chromium 浏览器 Browser-Use 需要 Chromium 浏览器来执行自动化任务。 # 安装 playwright（用于下载 Chromium） python -m pip install playwright # 下载 Chromium 浏览器 python -m playwright install chromium 预期输出：
2 min read
智能体

Browser-Use笔记1：web agent全景调研

摘要：2024 至 2025 年间，AI 领域经历了一场深刻的范式转移——从生成式文本处理（chat）转向自主智能体（Autonomous Agency）。本文深度解析开源 Web 智能体（Web Agents）的生态系统、核心架构之争（视觉 vs 代码）、以及 Browser-Use、Skyvern 等头部项目的技术护城河。 Web 自动化的“智能体” 长期以来，Web 自动化行业一直在“脆弱性”与“能力”之间权衡。传统的 Selenium 脚本依赖于刚性的选择器（如 XPath），一旦前端代码微调，脚本便会失效。 2024-2025 年的“智能体”宣告了这一确定性模型的终结。通过将大语言模型（LLM）和视觉语言模型（
5 min read
RAG

RAG 进阶之路7：REFRAG 机制应对长上下文挑战

之前的文章中，我们从基础设施（Milvus）、语义核心（BGE）、到代码落地（LangChain）以及应用层优化（Small-to-Big/HyDE），构建了一套完整的 RAG 知识体系。 然而，AI 领域的变化是指数级的。随着 Claude 3 支持 200k 上下文，Gemini 1.5 Pro 甚至支持到 1M token，一种论调开始流行：“RAG 已死，Long Context (长上下文) 才是未来。” 毕竟，如果能把整本《红楼梦》或整个公司的知识库直接塞进 Prompt 里，还需要费劲地做切片、建索引、搞检索吗？ 但现实是骨感的。“能放进去”不代表“能跑得动”。 把海量文本直接喂给
7 min read
LLM

在 RTX 4060 Ti 16GB 上基于 docker + vLLM部署 Qwen3-8B

1. 硬件背景与选型逻辑 在当前的本地 LLM（大语言模型）生态中，NVIDIA GeForce RTX 4060 Ti 16GB 是一张极具争议但也极具战略价值的显卡。 * 争议点：128-bit 的显存位宽限制了其在大吞吐量下的带宽上限。 * 战略价值：16GB 的大显存是运行大参数模型或超长上下文（Long Context）的硬门槛。 对于 Qwen3 系列模型，我们在 16GB 显存下主要面临三个选择： 1. Qwen3-30B-A3B MoE (Int3/Int4)：极高的智力上限，但显存占用极限，几乎没有空间留给上下文（KV Cache），适合短对话和难题攻克。 2. Qwen3-14B Dense (Int4/Int6)：平衡之选，但在 16GB 卡上略显平庸。 3. Qwen3-8B
3 min read
mem0

mem0学习笔记5：Mem0 是如何思考的

在 第四部分 中，我们研究了高层架构。现在，我们要进行"手术"。我们将查看 mem0/memory/main.py 中的代码，以确切了解当你调用 memory.add() 时会发生什么。 这是系统中最复杂的部分。它是"思考"发生的地方。 4 步pipline 当你调用 memory.add(messages, user_id="alice") 时，Mem0 会运行一个精心设计的 4 步管道： 1. 事实提取 (Fact Extraction)："用户实际上在说什么？" 2. 上下文检索
8 min read
mem0

mem0学习笔记4：Mem0 架构深度解析

在之前的文章中，我们专注于 使用 Mem0。现在，让我们看看它是 如何工作 的。 作为工程师，我们知道"记忆"不仅仅是一个魔法盒子。它是一个具有特定权衡的分布式系统。Mem0 做出了一些非常有主见的架构选择，使其有别于标准的 RAG 管道。 架构背后的"为什么" 在看图表之前，让我们先理解问题所在。 向量数据库的局限性 向量数据库（如 Pinecone 或 Qdrant）在 相似性搜索 方面非常出色。 * 查询："我想喝热饮。" * 结果："咖啡"、"茶"、"热巧克力"。 它们的工作原理是将文本转换为高维向量并找到&
8 min read
智能体

mem0学习笔记3：与 LangChain 的无缝集成

在 第二部分 中，我们手动实现了一个带记忆的 ReAct 智能体。但在真实项目中，你不会从零开始写 ReAct 循环。 你会使用像 LangChain 这样的成熟框架。那么，如何将 Mem0 集成进去呢？ LangChain 的 Agent 架构 LangChain 提供了一个强大的 AgentExecutor，它已经实现了完整的 ReAct 循环。你只需要： 1. 定义工具 (Tools) 2. 提供 LLM 3. 运行 executor.run() from langchain.agents import initialize_agent, Tool from langchain.llms import OpenAI
5 min read
mem0

mem0学习笔记2：构建你的第一个带记忆的 ReAct 智能体

在 第一部分 中，我们理解了 ReAct 智能体的记忆问题。现在，让我们动手构建一个真正能"记住"的智能体。 我们将从零开始实现一个 ReAct 循环，然后逐步加入 Mem0 记忆层。 ReAct 循环的核心结构 在开始之前，让我们先理解 ReAct 循环的本质。它是一个 Thought → Action → Observation 的迭代过程。 while not task_complete and steps < max_steps: # 1. Thought: 智能体分析当前状态并制定计划 thought = llm.generate(f"当前状态: {state}\n下一步应该做什么？"
4 min read
mem0

mem0学习笔记1：ReAct 智能体的记忆困境

如果你正在构建 AI 智能体，你可能已经遇到了一个让人抓狂的问题：智能体似乎患有"阿尔茨海默症"。 它刚刚花了 3 步去搜索某个 API 文档，但 5 分钟后，当你问同样的问题时，它又重新搜索了一遍。它无法记住自己做过什么、学到了什么，更不用说记住用户的偏好了。 这不是某个框架的 bug，这是 ReAct 智能体架构的固有问题。 什么是 ReAct？ 在深入记忆问题之前，让我们先理解 ReAct（Reasoning and Acting）范式。 ReAct 是由 Yao 等人在 2022 年提出的一种 Agent 架构模式。它的核心思想是：让 LLM 交替进行"思考"
4 min read
Go

Go-Sandbox 开发实录 (4)：穿越铁窗 —— 那些关于 IO 和超时的坑

牢笼建好了，犯人也关进去了。最后的问题是：我们怎么知道他在里面干了什么？ 对于 Code Interpreter 来说，用户的代码输出（Stdout/Stderr）必须实时、完整地传回给前端。而且，如果代码死循环了，我们得能把它杀掉。 这两个看似简单的需求，在实现时也让我们踩了不少坑。 坑一：IO 阻塞与 Goroutine 泄漏 最初，我们简单地用 cmd.StdoutPipe() 获取管道，然后在一个 Goroutine 里读。 // 错误示范 go func() { io.Copy(outputChan, stdoutPipe) }() 但在高并发场景下，我们发现 Goroutine 数量飙升。原来，如果 Python 进程异常退出或者被 kill 掉，有时候管道的 Read
3 min read
Go

Go-Sandbox 开发实录 (3)：画地为牢 —— 我们是如何构建“监狱”的？

把 Go 代码注入到 Python 进程后，我们拿到了控制权。现在的任务是：把这个进程关进“监狱”里。 在 internal/core/lib/python/add_seccomp.go 中，我们定义了这座“监狱”的构造。 第一步：切断退路 (Chroot) 首先要解决的是文件系统的隔离。我们不希望用户代码能看到 /etc/passwd，也不希望它能看到宿主机的任何文件。 chroot 是最古老也是最有效的手段之一。 // internal/core/lib/python/add_seccomp.go func InitSeccomp(uid int, gid int, enable_network bool) error { // 1.
3 min read
Go

Go-Sandbox 开发实录 (2)：特洛伊木马 —— 如何“黑”进 Python 进程？

在上一篇中，我们确定了“进程级沙箱”的路线。但摆在面前的第一个技术难题是：如何在 Python 进程启动的那一刻，强行插入我们的安全代码？ 我们需要在用户代码执行之前，完成 Chroot 和 Seccomp 的设置。如果等到用户代码开始跑了再限制，黄花菜都凉了。 尝试一：直接修改解释器源码？ 最硬核的办法是下载 CPython 源码，在 main 函数里加几行代码，重新编译一个 safe-python。 但这太蠢了。 1. 维护噩梦：每次 Python 发新版，我们都得重新打补丁、编译。 2. 不通用：那 Node.js 怎么办？Java 怎么办？难道都要改源码？ 我们需要一种非侵入式的方案。 尝试二：LD_PRELOAD？ Linux 有个黑魔法叫
4 min read
Go

Go-Sandbox 开发实录 (1)：为了毫秒级启动，我们放弃了 Docker

做 LLM Agent 开发时，Code Interpreter 是个绕不开的功能。让 AI 写代码容易，但让它安全地运行代码，却是个棘手的工程问题。 在设计 go-sandbox 之初，我们面临的最大抉择就是：到底是用 Docker，还是自己造轮子？ Docker 的诱惑与代价 最开始，我们自然而然地想到了 Docker。它成熟、安全、隔离性好。我们尝试为每个代码执行请求启动一个容器： docker run --rm -it python:3.10 python -c "print('hello')" 但在高并发测试中，问题很快暴露了： 1. 慢：即使是热启动，容器的创建和销毁也需要几百毫秒。对于用户来说，
3 min read
X99

X99 平台下 Docker 部署全攻略

摘要：手持 X99 平台和一张只有 2GB 显存的 GTX 960，还能玩转 Docker 和 AI 吗？本文详细对比了 Docker Desktop 与 WSL Native 两种部署方案，并深入讲解了最令人头秃的网络代理配置、数据迁移。 X99 平台凭借多核心优势，至今仍是很多开发者的主力机。但当你想在 Windows 上通过 Docker 运行 AI 模型时，往往会面临选择困难症：是装简单易用的 Docker Desktop，还是追求极致性能的 WSL 原生命令行？ 本文记录了在 Windows (X99) + GTX 960 (2GB) 环境下的完整折腾记录。 第一部分：路线选择——你属于哪一派？ 在
4 min read
X99

记一次 X99“洋垃圾”平台的卡顿排查、AI 环境搭建与显卡升级避坑

X99 平台（Xeon E5 v3/v4）凭借极其廉价的服务器拆机配件（如 E5-2696 v3 和 DDR3 ECC 内存），成为了很多技术爱好者和“垃圾佬”组建高性价比工作站的首选。 最近我在折腾一台配置为 E5 CPU + 64GB DDR3 内存 + X99-DM3 主板 + GTX 960 的机器时，经历了一系列从系统卡顿排查，到 WSL2 AI 环境搭建，再到显卡升级选型的过程。本文将详细记录这些坑点，特别是关于Tesla 计算卡与 GeForce 游戏卡的区别，以及一线主板与国产“寨板”的差异，希望能帮到同样在使用 X99 平台的朋友。 第一部分：性能排查——大内存为什么还卡？ 1. 误区：
6 min read
AWS

AWS EventBridge Scheduler 未触发 Lambda排查记录

你是否遇到过这样的情况：在 AWS 上配置了一个 EventBridge Scheduler 来定时运行 Lambda（例如每天定时关闭开发环境的 EC2），调度器状态显示“Enabled”，时间到了却什么都没发生？ Lambda 控制台没有报错，CloudWatch 甚至没有生成日志流。一切看起来都配置得天衣无缝，但就是不工作。 本文将复盘一次真实的排查过程，带你找出那个导致任务“静默失败”的隐蔽杀手——IAM 策略中的地区（Region）错配。 问题现象 在本次案例中，我们的目标是：每天晚上自动触发一个名为 StopEC2ByTag 的 Lambda 函数。 环境配置如下： * Region: ap-southeast-1 (新加坡) * Service: Amazon EventBridge Scheduler -> AWS Lambda * Status: Scheduler 显示
3 min read
爬虫

爬虫1：从 HTTP 请求伪装到浏览器指纹的攻防博弈

一、 协议层对抗：当 HTTP head不再管用 长期以来，Python 的 Requests 库统治了爬虫领域。对于简单的任务，它依然有效。但在面对 Cloudflare 等现代防火墙时，开发者常会遇到一个困惑：“明明复制了浏览器所有的 Header，为什么还是被拦截？” 答案往往不在应用层（HTTP），而在传输层（TLS）。 1. TLS 指纹 当爬虫发起 HTTPS 请求时，在发送 HTTP 头之前，必须先完成 TLS 握手。在 ClientHello 数据包中，客户端会发送加密套件列表、TLS 版本、压缩算法以及一系列扩展字段。 * 真实浏览器（如 Chrome、Safari）和编程语言库（如 Python urllib3、
10 min read
RAG

RAG 进阶之路6：优化策略Small-to-Big、HyDE 与上下文压缩

在前几篇文章中，我们搭建起了 RAG 的骨架：选好了向量数据库（Milvus），配置了强大的语义模型（BGE），甚至解决了时间衰减的问题。 现在，你的 RAG 系统已经能跑通了。但在实际测试中，你可能会撞上一堵无形的墙： * 场景 A： 你问“公司迟到怎么罚款？”，系统搜到了“罚款 50 元”的片段，但 LLM 答错了。因为那个片段太短，丢掉了前面关键的主语——“连续三次迟到者”。 * 场景 B： 用户问“怎么治那个一直在嗓子眼里的病？”，系统搜不到任何结果。因为数据库里的文档写的是专业的“慢性咽炎临床治疗方案”。 这标志着我们进入了 RAG 开发的深水区——检索质量优化（Retrieval Quality Optimization）。 不仅仅是“搜得快”，更要“搜得准”且“读得懂”
6 min read
RAG

RAG 进阶之路5：Milvus 中实现“时间衰减”

在构建 RAG系统时，我们经常会遇到这样一个尴尬的场景： 用户问：“最新的 iPhone 摄像头参数怎么样？” 你的 RAG 系统兴致勃勃地从数据库里找出了 iPhone 11 的评测文章，因为那篇文章写得非常详尽，和问题的语义相似度（Semantic Similarity）极高。而关于 iPhone 12 的介绍可能比较简短，导致向量距离稍远，被排在了后面。 这就是向量检索的“时效性盲区”。 在 HNSW 或 IVF 这样的向量索引眼里，只有空间距离，没有时间概念。数据一旦写入，它在向量空间的位置就是永恒的。但在新闻、金融或日志分析等场景中，“新”往往比“准”更重要。 那么，在使用 Milvus 或 Faiss 时，我们如何引入时间衰减（Time Decay）
6 min read
RAG

RAG 进阶之路4：LangChain + Milvus + BGE 全流程实战

在前两篇文章中，我们已经达成了共识：“Milvus + BGE-base + BGE-Reranker” 是目前构建中文 RAG 系统的高性价比黄金组合。今天，我们将使用 LangChain 框架将这三个组件串联起来，构建一个真正具备“漏斗式检索”能力的 RAG pipline。 准备工作 在开始之前，请确保你已经安装了 Docker 并启动了 Milvus 实例。同时，你需要安装以下 Python 库： pip install langchain langchain-community langchain-huggingface pymilvus sentence-transformers 注：我们将使用最新的 langchain-huggingface 库来加载模型，这是 LangChain 官方推荐的现代化方式。 核心架构设计 我们的代码将遵循以下数据流： 1. 加载与切分 (Load & Split): 将长文档切分成
6 min read