攀岩技术的兴起最早可追溯到十八世纪的欧洲。当时的登山者为了克服类似阿尔卑斯山等终年积雪的冰岩地形,发展出一套系统的攀登技术。1983年法国人Mr. Francois SAVIGNY 发明了由树脂及混凝土合成的可移动式岩块,奠定了攀岩墙日后发展的基础。
目前攀岩在国外是一项非常兴盛而且老少咸宜的运动,攀岩墙的设立非常普遍,室内及室外都有。因此常常可以看到一些外国朋友在下班之后,到这些设有岩墙的休闲娱乐中心或健身房活动一下再回家的情形。在节假日,也常常可以看到在设有岩墙的公园里全家同乐的景象。因为对现代都市人而言,到天然岩场攀爬往往要花去不少交通的时间,而且受气候的影响很大。因此在国外,尤其是运动风气鼎盛的欧洲、北美洲,许多岩墙的设立都是由政府出资规划兴建,因为它提供了一个绝佳的旅游休闲的去处。
现代人随着经济起飞,生活的品质已不再是要求温饱而已,而是希望建立工作与身心健康、休闲品质、家庭亲子关系等相对的平衡。攀岩活动,可以完全满足这些需求,并且完全没有危险性。除了以上这些好处外,更因为攀岩活动没有体型、性别及年龄上的限制,无论男女老少皆可享受攀登的乐趣。现代人饱受生活压力与工作压力之苦,他们可以从攀岩活动中获得成就感,舒缓压力。
在休闲市场上,目前世界各地一些稍具规模的公园、游乐场、度假饭店都以此设备来招揽客人,以凸显自己的特色。
除了攀岩活动之外,人工岩墙也可以提供类似高楼逃生,绳索速降等个人或消防单位之训练以及山难搜救技术的训练。高空作业人员,如天线架设、建筑、外墙清洗作业、冷气安装工作人员,也可以在经过简单的训练后将工作的危险性大幅降低,提升产业竞争力,军方及特种部队也常常利用人工岩场开展各种作战技术演练,例如困难地形突破、突击、潜入、人质解救或是巷战、城市战等等。
攀岩的六大好处
● 增加身体柔软度与协调感
● 增强体力
● 集中力
● 进取心
● 自信心
● 平衡感
攀岩墙的类型
攀岩墙发展迄今,依照其用途可分为:
● 专业竞技型:专业设计,采用高强度仿真复合材料岩板,精心设计路线及难度,供攀岩专业人士、爱好者以及军、警、高空作业等特种行业训练、比赛。
● 仿真娱乐型:创意设计,安全、刺激,充分考虑不同人群的攀登要求,并最大限度的增加投资者的收益。
● 儿童型:岩板表面用环保材料喷涂卡通图案,适合幼儿园儿童及小学生,用于对其肌肉发展及手、眼、身体之协调训练方面。
博客
-
攀岩运动简介
-
AI编程(四十七):爬虫礼仪 — 让程序做个体面的访客
前面十篇练的全是”怎么从网上拿东西”:抓网页、抠表格、提交表单、带登录拿、批量下载。但有一句老话得在第47篇正式讲:程序能干,不等于可以随便干。今天新概念只有一个:
robots.txt——网站贴在大门口的”欢迎参观 / 后院别进”告示牌,程序进门之前先看一眼。再配一个老手艺的新用法:time.sleep限速,让程序做个”走马观花的体面访客”,而不是”把人家门槛踏破的暴走团”。学完这篇,你的爬虫才算毕业:不光会拿,还知道什么能拿、拿多快、拿多少。一、真实场景:一封”友好”的律师函
你把第43篇的爬虫升级了一下:盯上了一个行业资讯网站,每小时跑一次,把所有新文章扒下来存进自己的资料库。头两天美滋滋——数据哗哗地来。第三天早上,程序报错了:
Connection refused。浏览器一打开,人家网站正常得很,就你的程序被拒之门外——你的 IP 被封了。你心想:封就封,我换个网络接着爬。于是改成每 10 秒狂抓一次,一晚上抓了人家三万页。第四天,收到的不是新数据,是网站管理员的一封邮件,措辞客气但意思很硬:”贵方的自动化访问已对我方服务器造成明显负载,请立即停止,否则我方将保留进一步追究的权利。”
你懵了:网上公开的东西,我”看”一下怎么还犯法了?
-
AI编程(四十六):下载文件 — 让程序把”资料”搬回家
前面四十多篇拿到的都是文字——网页内容、表格数据、JSON。但网上更多好东西是文件:PDF 通知、Excel 模板、图片素材、安装包。今天新概念只有一个:二进制文件写入——
resp.content拿到的不再是”字”,而是”原样的字节”,得用open(path, "wb")原封不动写进硬盘。学完这篇,”右键→另存为→等→再右键→再另存为”的体力活就彻底交给程序了:它半夜能把 30 份 PDF 整整齐齐搬进你的文件夹。一、真实场景:月底的”资料搬运工”
单位的”资料下载”栏每月更新一批文件:本月的工作简报 PDF(12 期,编号 01 到 12)、报销模板 Excel、还有几张通知截图。领导让你”把这些都下下来,归到
D:月度资料10月里”。这事没有任何技术含量:点开链接 → 右键 → 另存为 → 选文件夹 → 改文件名 → 重复 15 遍。难就难在烦:每次都要选路径、等进度条、文件名还容易存错(
简报(1).pdf、简报(2).pdf这种鬼东西就是这么来的)。而且这种活每月一次,下个月还得再来一遍。更别提另一种情况:批量。比如教研组要下载 200 份学生交的电子作业(每份一个 PDF 链接,都在一个页面上排着),手工点 200 次另存为?点到手抽筋。
-
37.Instructor架构分析
项目: instructor-ai/instructor (567-labs/instructor)
定位: 为 LLM 提供结构化输出的 Python 库,基于 Pydantic 实现类型安全的 JSON 提取
版本: v1.17.1 | Stars: 13,000+ | 语言: Python 100% | 许可证: MIT
主页: https://python.useinstructor.com/
1. 项目定位与核心价值
Instructor 解决的是一个极其具体的问题:从 LLM 的非结构化文本输出中可靠地提取结构化数据。传统方式需要手动编写 JSON Schema、处理验证错误、实现重试逻辑、解析不同提供商的 API 差异——Instructor 将这一切封装为一个极简接口:
client = instructor.from_provider("openai/gpt-4o-mini") user = client.chat.completions.create( response_model=User, # Pydantic 模型即 Schema messages=[{"role": "user", "content": "John is 25 years old"}], ) # 直接得到 User(name='John', age=25)核心理念是 Schema-First:开发者只需定义 Pydantic BaseModel,Instructor 自动完成 JSON Schema 生成、API 适配、响应解析、验证重试的全链路。与 PydanticAI(Pydantic 官方的 Agent 运行时)形成互补——Instructor 聚焦于快速提取场景,PydanticAI 面向更复杂的 Agent 编排。
2. 整体架构:v1/v2 双层结构
Instructor 的代码库经历了从 v1 到 v2 的重大重构,当前采用 兼容层 + 核心层 的双层架构:
-
AI编程(四十五):登录和Cookie — 让程序带着”工牌”进门
上一篇的表单提交已经能”递单子办事”了,但很多网站更狠:单子都不让你递——先登录,才有资格查。账号密码递进去不难,难的是网站认完人发你一张”工牌”(Cookie),之后每次进门都得出示它。今天新概念只有一个:
requests.Session——一个自动保管工牌、进门自动出示的请求会话。学完这篇,需要登录的查询也能自动化:登录一次,工位一坐,把该查的都查完。一、真实场景:每季度一次的”学时查询”折腾
你所在单位有个”继续教育平台”,每季度要查一次自己的培训学时:登录(用户名+密码)→ 点”我的学时” → 看着页面上的数字抄下来 → 填进单位的汇总表。你一个人查一次也就两分钟,但你们科室 15 个人,每到季度末都来问你:”帮我看看我学时够不够?”——账号密码一个个发过来,你一个个登录、一个个查、一个个回复,一上午就没了。
更气人的是:这平台的”我的学时”页面不登录根本打不开——直接访问网址,它把你踢回登录页。上一篇学的
requests.post在这里只能递登录表单,递完之后呢?程序换下一个网址去查学时,服务器冷冰冰地回一句:”请先登录。”问题出在哪?上一篇的程序是”一次性”的:每次请求都是陌生人上门,递完单子扭头就忘。 而真实世界的规矩是:你登录时,前台认出你,发你一张工牌;之后你去每个窗口办事,都得把工牌亮一下,工作人员一看:”哦,是三楼的老王,进来吧。”
-
36.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:
-
35.LibreChat架构分析
版本: 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/):
-
AI编程(四十四):网页表单提交 — 让程序替你去窗口排队
上一篇的爬虫再能干,也只是个”只读”的观众:网页给什么,它看什么。但生活里的查询网站都是”问答式”的——你得先在表单里填月份、输关键词、点”查询”,它才把结果吐给你。今天教程序开口说话:填表、提交、拿结果。新概念只有一个:
requests.post。学完这篇,你的程序就从”看热闹的”升级成”能替你去窗口排队办事的”。一、真实场景:每月一次的”填表查询”折磨
你在单位兼着一个活儿:每月月初,去人社局的”补贴发放查询”页面,把当月的公示结果逐条查出来、整理成表。查询页面长这样:一个下拉框选月份(2026-09、2026-10……),一个输入框填姓名或单位关键词,一个”查询”按钮。点一下,页面跳到结果页,列出匹配的记录。
问题是你手里有20个单位名要逐个查。于是每月这天你的操作是:选月份→粘贴”沈阳第一机床厂”→点查询→看结果→抄下来→回来→粘贴”沈阳水泵厂”→点查询→抄下来……20个单位查20次,抄错一个字就得重来。查完抬头一小时过去了,而这活儿每月一次,年年如此。
上周的爬虫对这个页面完全没辙:它只能”看”现成的网页,而这个页面你不点查询按钮,它就永远是空空的表单。差别在哪?上周的程序只会”问路”(打开网址),今天的程序要学会”递表单”(提交条件)。
-
34.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. 技术栈与框架选型
层级 技术选型 说明 |——|———-|——|
-
AI编程(四十三):爬虫进阶 — 一个人干完一个部门的活儿
前两篇你的爬虫还是”一页纸搬运工”:给它一个网址,它抓一页。但真实世界的数据从来不长在一页上——公示名单分十页、商品列表翻到手软、新闻 archive 一路排到去年。今天给爬虫装上三件装备:会翻页的腿(分页抓取)、不收重货的账本(去重)、摔了能爬起来的膝盖(异常处理)。装完这三件,你的爬虫就从”能跑”进化成”能干活”——一个人干完一个部门的活儿。
一、从”一页纸”到”一个部门”的真实麻烦
先说今天要解决的事,它真实得不能再真实。
市人社局网站挂着一份补贴发放公示名单,你领导让你”把名单整理成 Excel”。你打开一看:好家伙,名单分了 10 页,每页 20 条,每条有姓名、身份证后四位、补贴金额。领导还补了一句:”每周这名单都更新,你每周都整理一遍。”
上周你学的本事是”抓一页、提表格、存 CSV”。那按老办法干:抓第 1 页,改网址抓第 2 页,再改抓第 3 页……十页改十次,粘十次,合并十次。这不叫编程,这叫把复制粘贴升级成了复制粘贴 Pro。
-
33.AgentScope架构分析
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 采用三层架构: