博客

上一篇的表单提交已经能”递单子办事”了，但很多网站更狠：单子都不让你递——先登录，才有资格查。账号密码递进去不难，难的是网站认完人发你一张”工牌”（Cookie），之后每次进门都得出示它。今天新概念只有一个：requests.Session——一个自动保管工牌、进门自动出示的请求会话。学完这篇，需要登录的查询也能自动化：登录一次，工位一坐，把该查的都查完。

一、真实场景：每季度一次的”学时查询”折腾

你所在单位有个”继续教育平台”，每季度要查一次自己的培训学时：登录（用户名+密码）→ 点”我的学时” → 看着页面上的数字抄下来 → 填进单位的汇总表。你一个人查一次也就两分钟，但你们科室 15 个人，每到季度末都来问你：”帮我看看我学时够不够？”——账号密码一个个发过来，你一个个登录、一个个查、一个个回复，一上午就没了。

更气人的是：这平台的”我的学时”页面不登录根本打不开——直接访问网址，它把你踢回登录页。上一篇学的 requests.post 在这里只能递登录表单，递完之后呢？程序换下一个网址去查学时，服务器冷冰冰地回一句：”请先登录。”

问题出在哪？上一篇的程序是”一次性”的：每次请求都是陌生人上门，递完单子扭头就忘。 而真实世界的规矩是：你登录时，前台认出你，发你一张工牌；之后你去每个窗口办事，都得把工牌亮一下，工作人员一看：”哦，是三楼的老王，进来吧。”

（更多…）

项目: langfuse/langfuse

定位: 开源 LLM 工程平台（可观测性、评估、Prompt 管理、数据集）

技术栈: Next.js + tRPC + Prisma + ClickHouse + Redis (BullMQ) + TypeScript

许可证: MIT（ee/ 目录为企业版，限制性许可）

背景: YC W23，2026年1月被 ClickHouse 收购

1. 系统总体架构

Langfuse 采用经典的 Web + Worker 双进程 架构，辅以 ClickHouse 做分析型存储、PostgreSQL 做事务型存储、Redis/BullMQ 做任务队列。

┌─────────────────────────────────────────────────────┐
│                   SDK (Python/JS)                    │
│  @observe() / OpenAI wrapper / LangChain callback   │
└──────────────────────┬──────────────────────────────┘
                       │ HTTP / OTLP
                       ▼
┌──────────────────────────────────────────────────────┐
│              Web Server (Next.js App)                 │
│  ┌──────────┐  ┌──────────┐  ┌───────────────────┐  │
│  │  tRPC    │  │ REST API │  │ Next.js Pages/App │  │
│  │ (internal)│  │ (public) │  │   (React UI)      │  │
│  └────┬─────┘  └────┬─────┘  └───────────────────┘  │
│       │              │                                │
│       ▼              ▼                                │
│  ┌─────────────────────────┐  ┌──────────────────┐  │
│  │    Prisma ORM (PG)      │  │  ClickHouse Client│  │
│  │  users/orgs/projects    │  │  traces/obs/scores│  │
│  │  prompts/datasets/config│  │  (analytics OLAP) │  │
│  └─────────────────────────┘  └──────────────────┘  │
└──────────────────────┬───────────────────────────────┘
                       │ BullMQ Jobs
                       ▼
┌──────────────────────────────────────────────────────┐
│              Worker (独立 Node.js 进程)                │
│  ┌─────────────┐ ┌──────────┐ ┌──────────────────┐  │
│  │ Ingestion   │ │ Eval     │ │ Batch Export     │  │
│  │ Queue       │ │ Queue    │ │ Queue            │  │
│  ├─────────────┤ ├──────────┤ ├──────────────────┤  │
│  │ Experiment  │ │ Monitor  │ │ Data Retention   │  │
│  │ Queue       │ │ Queue    │ │ Queue (EE)       │  │
│  ├─────────────┤ ├──────────┤ ├──────────────────┤  │
│  │ OTel        │ │ Webhook  │ │ In-App Agent     │  │
│  │ Ingestion   │ │ Queue    │ │ Run Queue        │  │
│  └─────────────┘ └──────────┘ └──────────────────┘  │
└──────────────────────────────────────────────────────┘

核心设计原则：写入路径（ingestion）通过队列异步化，读取路径走 ClickHouse OLAP 查询，事务型数据（用户、项目、Prompt 配置）走 PostgreSQL + Prisma。

2. Monorepo 结构与模块划分

Langfuse 使用 pnpm workspace + Turborepo 管理 monorepo：

（更多…）

版本: v0.8.8-rc1 | GitHub: danny-avila/LibreChat | 许可证: MIT

分析时间: 2026-09-13

1. 项目概述与定位

LibreChat 是一个开源的多模型 AI 聊天平台，定位为 ChatGPT 的自托管替代方案。它提供统一的 Web UI 来对接 Anthropic (Claude)、OpenAI、Azure OpenAI、Google、Vertex AI、AWS Bedrock 等主流 LLM 提供商，同时支持 Ollama、groq、Mistral 等本地和远程 AI 服务。项目采用 MIT 许可证，截至 2026 年 9 月已积累超过 4,500 次提交，是 GitHub 上最活跃的开源 AI 聊天前端之一。

与简单的 API 代理不同，LibreChat 构建了一个完整的 Agent 生态系统：包括无代码 Agent 构建器、Agent 市场、Skills 系统（类似 Hermes 的 SKILL.md）、子 Agent 委派、MCP 工具集成、代码解释器、RAG 文件搜索、图片生成等。这使其从一个”聊天 UI”进化为一个功能完备的 AI Agent 平台。

2. 技术栈与依赖

后端 (api/)：

（更多…）

上一篇的爬虫再能干，也只是个”只读”的观众：网页给什么，它看什么。但生活里的查询网站都是”问答式”的——你得先在表单里填月份、输关键词、点”查询”，它才把结果吐给你。今天教程序开口说话：填表、提交、拿结果。新概念只有一个：requests.post。学完这篇，你的程序就从”看热闹的”升级成”能替你去窗口排队办事的”。

一、真实场景：每月一次的”填表查询”折磨

你在单位兼着一个活儿：每月月初，去人社局的”补贴发放查询”页面，把当月的公示结果逐条查出来、整理成表。查询页面长这样：一个下拉框选月份（2026-09、2026-10……），一个输入框填姓名或单位关键词，一个”查询”按钮。点一下，页面跳到结果页，列出匹配的记录。

问题是你手里有20个单位名要逐个查。于是每月这天你的操作是：选月份→粘贴”沈阳第一机床厂”→点查询→看结果→抄下来→回来→粘贴”沈阳水泵厂”→点查询→抄下来……20个单位查20次，抄错一个字就得重来。查完抬头一小时过去了，而这活儿每月一次，年年如此。

上周的爬虫对这个页面完全没辙：它只能”看”现成的网页，而这个页面你不点查询按钮，它就永远是空空的表单。差别在哪？上周的程序只会”问路”（打开网址），今天的程序要学会”递表单”（提交条件）。

（更多…）

项目: enricoros/big-AGI

版本: 2.1.1

Stars: 7.1k | Commits: 8,685 | Forks: 1.6k

许可证: MIT

定位: 面向专家的多模型 AI 工作空间

1. 项目定位与核心理念

Big-AGI 是一个独立的、非 VC 资助的开源 AI 套件，定位为”面向专家的多模型 AI 工作空间”。其核心哲学是：AI 应该提升你，而不是取代你。这体现在三个支柱上：

• Intelligence（智能）: Beam 多模型去幻觉、原生搜索、支持最新模型（Opus 5、GPT-5.6、Gemini 3.7 等）
• Control（控制）: Personas 系统、数据所有权、请求检查、自带 API Key、无厂商锁定
• Speed（速度）: Local-first 架构、零延迟、极致优化的 Web 应用

商业模式上，采用免费开源 + Pro 订阅（$10.99/月）的模式，Pro 提供跨设备同步和 1GB 存储，订阅收入资助所有开发。

2. 技术栈与框架选型

|——|———-|——|

（更多…）

前两篇你的爬虫还是”一页纸搬运工”：给它一个网址，它抓一页。但真实世界的数据从来不长在一页上——公示名单分十页、商品列表翻到手软、新闻 archive 一路排到去年。今天给爬虫装上三件装备：会翻页的腿（分页抓取）、不收重货的账本（去重）、摔了能爬起来的膝盖（异常处理）。装完这三件，你的爬虫就从”能跑”进化成”能干活”——一个人干完一个部门的活儿。

一、从”一页纸”到”一个部门”的真实麻烦

先说今天要解决的事，它真实得不能再真实。

市人社局网站挂着一份补贴发放公示名单，你领导让你”把名单整理成 Excel”。你打开一看：好家伙，名单分了 10 页，每页 20 条，每条有姓名、身份证后四位、补贴金额。领导还补了一句：”每周这名单都更新，你每周都整理一遍。”

上周你学的本事是”抓一页、提表格、存 CSV”。那按老办法干：抓第 1 页，改网址抓第 2 页，再改抓第 3 页……十页改十次，粘十次，合并十次。这不叫编程，这叫把复制粘贴升级成了复制粘贴 Pro。

（更多…）

GitHub: agentscope-ai/agentscope | Stars: 23k+ | License: Apache-2.0

核心理念：”Build and run agents you can see, understand and trust.”

1. 设计哲学与定位

AgentScope 2.0 定位为 production-ready、easy-to-use 的 Agent 框架，其设计哲学与其他框架有本质区别：

• 不约束模型：不靠严格的 prompt 模板和固定的编排逻辑来限制 LLM，而是充分利用模型自身的推理和工具调用能力
• 极简抽象：只提供必要的抽象层（essential abstractions），随着模型能力提升不断简化
• 面向 Agentic LLM：从 v1 的多智能体对话编排，转向 v2 的单 Agent 深度能力构建（ReAct、规划、记忆、RL 训练）

这与 LangChain 的”链式管道”、AutoGen 的”对话驱动”形成鲜明对比——AgentScope 2.0 更接近 Claude Code / Codex 的工具型 Agent 范式。

2. 整体架构分层

AgentScope 采用三层架构：

（更多…）

项目：openai/swarm

定位：实验性、教育性多智能体编排框架

状态：已被 OpenAI Agents SDK 取代

核心文件：swarm/core.py（~200行）、swarm/util.py（~70行）、swarm/types.py

一、设计哲学：极简主义的多智能体编排

Swarm 的设计哲学可以用三个词概括：轻量、可控、可测。整个框架的核心逻辑不到 200 行 Python 代码，却实现了完整的多智能体协调能力。这在 Agent 框架领域是极其罕见的——LangChain 的核心模块有数万行代码，AutoGen 的协调器也远比 Swarm 复杂。

Swarm 的极简主义体现在它只定义了两个原语抽象：

1. Agent——封装指令（instructions）和工具（functions）的实体
2. Handoff——Agent 之间的控制权转移机制

这种设计选择背后的理念是：多智能体系统的复杂性不应来自框架本身，而应来自业务逻辑的组合。Swarm 不引入图、状态机、消息总线等重型抽象，而是让开发者用纯 Python 函数表达一切编排逻辑。

（更多…）

上一篇你抓下了三行小表，算是爬虫入门了；今天上强度：面对一张带表头、几十行、好几列的”真表格”，让程序把表头和数据一格不落地搬下来，还能顺手存成 CSV。手艺还是那套（find + get_text），变的只是”按图索骥”的图更复杂一点。

一、从”三行小表”到”一张大表”

先说今天要解决的真实麻烦。

上一篇的值班表只有三行两列，说难听点，复制粘贴也就十秒钟。但你在工作里真正会碰到的表长这样：学校网站上的全校课程表（几十行、星期一到星期五五六列）、政务网站上的补贴发放公示表（上百行、姓名/金额/银行卡号七八列）、购物网站上的参数对比表（十几行、三个产品列）。

这种表，复制粘贴就不是十秒钟的事了——粘错了行、漏了列、表头和数据对不上，是常有的事。更要命的是它每周都更新，你每周都得重粘一遍。

（更多…）

项目: e2b-dev/e2b

定位: 开源安全沙箱基础设施，让 AI Agent 在云端隔离环境中运行生成的代码

语言: TypeScript (JS SDK) + Python (Python SDK) + Terraform (基础设施)

许可证: Apache-2.0

分析日期: 2026-09

1. 项目概述与核心价值

E2B（Environment to Build）是一个面向 AI Agent 的云端代码执行沙箱平台。其核心理念是：AI 生成的代码不应直接在宿主机上执行，而应在安全隔离的虚拟机环境中运行。E2B 基于 Firecracker 微虚拟机技术，提供毫秒级启动的轻量级沙箱，每个沙箱拥有独立的文件系统、网络栈和进程空间。

E2B 的核心价值体现在三个层面：

• 安全性: 通过 Firecracker microVM 实现硬件级隔离，防止恶意代码逃逸
• 速度: 沙箱启动延迟极低（~150ms），适合 AI Agent 的实时交互场景
• 开放性: 基础设施完全开源，支持 AWS/GCP 自托管部署

2. 整体架构设计

E2B 采用四层分离架构：

（更多…）