15年单服务器8GB内存服务50万用户——Webminal生存之道一、事件概述1. 项目背景Webminal.org 是一个在线 Linux 终端学习平台，让用户通过浏览器直接访问真实的 Linux 终端进行学习。该项目自 2011 年启动，至今已运行 15 年。2. 核心数据A. 规模数据运行时长：15 年（2011-2026）服务用户：500,000 名注册用户服务器配置：单台 CentOS 服务器，8GB RAM命令执行统计：超过 2800 万条命令B. 技术特点无 Kubernetes 集群无微服务架构无自动扩容单服务器运行3. 历史考验该平台经历了多次重大考验：2021 年数据中心火灾（丢失 15 万用户账户）荷兰多次停电2017 年西班牙科技博客涌入 1 万名用户创始人之间从未见过面的远程协作二、系统架构1. 技术栈graph TB subgraph 用户端 A[浏览器] end A -->|WebSocket/AJAX| B[Nginx] B --> C[Flask 0.12.5] C --> D[MySQL数据库] C --> E[Shellinabox终端] E --> F[共享Linux环境] C --> G[UML Root Labs] G -->|独立内核| H[用户虚拟机] H --> I[虚拟块设备 LVM/RAID/fdisk] C --> J[eBPF监控] J --> K[命令实时统计]2. 技术选型组件技术选型版本/说明编程语言Python2.7Web 框架Flask0.12.5终端模拟Shellinabox2005 年发布，2017 年弃用Root 实验室User Mode Linux2001 年技术监控eBPFexecsnoop（唯一现代技术）数据库MySQL存储在火灾中幸存前端纯 HTML + CSS无 React/Vue/npm3. 基础设施迁移历程graph LR A[2011 Linode] --> B[DigitalOcean] B --> C[AWS] C --> D[GCP] D --> E[OVH] E --> F[IBM Cloud] F --> G[2025 Linode] G -->|循环回到起点| A三、核心功能1. 新版更新A. 现代化 UI全新设计的用户界面无 Bootstrap 或 jQuery CDN 依赖自托管字体移动端响应式支持B. Root Lab提供完整 root 权限的系统管理员实践环境，支持：fdisk 磁盘分区LVM 逻辑卷管理RAID 阵列配置mkfs 文件系统创建systemctl 服务管理crontab 定时任务firewalld 防火墙配置SSH 密钥管理awk 与 sed 文本处理C. 实时命令统计首页滚动显示实时命令执行情况基于 eBPF（execsnoop）实时追踪累计执行命令超过 2800 万条2. Shellinabox 终端A. 技术选择团队曾尝试用现代 WebSocket 终端替代 Shellinabox，但生产环境仅运行几小时就出现：空白屏幕问题Firefox 兼容性问题B. 回归原因Shellinabox 虽然来自 2005 年，界面简陋且速度较慢，但具有以下优势：可穿透所有防火墙兼容各种代理服务器支持企业内网环境3. User Mode Linux 架构graph TB subgraph UML虚拟机 A[用户空间内核] B[虚拟块设备 sda-sdd] C[256MB RAM] D[Copy-on-Write] end E[主机系统] -->|资源隔离| A A -->|fdisk/LVM/RAID| B A -->|内存限制| C F[Golden镜像] -->|COW共享| D D --> G[100用户~2GB磁盘] H[poweroff] -->|退出UML| EA. UML vs Docker为什么不使用 Docker？需求DockerUML虚拟块设备不支持支持 4 个虚拟块设备fdisk 练习无法真实执行完全支持内核隔离共享主机内核独立内核实践场景容器化应用系统管理技能B. 资源分配每个 UML 实例获得：完整的 Linux 内核（非容器）4 个虚拟块设备（每个 64MB）256MB RAMCopy-on-Write 写时复制层C. 存储效率Copy-on-Write 机制使得 100 个并发用户仅需约 2GB 磁盘空间，所有用户共享同一个 Golden 镜像。四、协作模式1. 创始团队创始人：来自印度联合创始人 Freston：来自荷兰相识平台：LinuxForums.org（2010 年）2. 沟通方式2010-2015 年期间，两人从未见过面，甚至没有通过 Skype 见过对方的脸。所有协作通过 SSH 连接到服务器的 screen 会话完成：$ screen -x chat $ cat > /dev/null hey, should we add MySQL support?没有 Slack，没有 Zoom，没有 Jira 工单，只是两人在终端里打字。五、运营状况1. 商业模式A. 收入状况零收入无广告无用户追踪无风险投资B. 资金来源创始人用个人储蓄支付服务器费用。该项目在财务上投入超过个人和家庭开支。C. 尝试过的变现方式申请 Y 创业营：被拒绝PayPal 捐赠：效果不佳Stripe 付费计划：无法推行付费订阅：目标用户（学生）无法承受每月 4 美元2. 用户反馈摘录用户评价："我是一名 Windows 系统管理员，这个网站帮助我熟悉了 Linux，甚至可以在平板电脑上使用。""我是韩国电子工程专业的学生，通过这个网站学习 Linux，帮助很大！""教程很棒，我在某些地方还笑出了声。网站非常棒，请继续制作更多内容！"六、经验总结1. 技术启示A. 稳定性优先被弃用的 Shellinabox 仍能完美运行Python 2.7 和 Flask 0.12.5 服务 15 年有时"老技术"就是"对的技术"B. 简单架构的价值单服务器易于维护无需复杂的容器编排故障排查相对简单C. 适度现代化在关键组件上使用现代技术（eBPF）保持前端轻量级（纯 HTML/CSS）避免过度工程化2. 运营启示A. 专注核心价值教育价值优先于商业价值帮助学生学习 Linux 是核心使命B. 可持续性挑战个人项目的长期维持需要资金支持需要寻找可持续的运营模式3. 未来计划创始人正在通过 GitHub Sponsors 寻求支持，目标是：从 8GB RAM 升级到 128GB RAM支持更多学生同时使用 Root Lab七、总结Webminal 的故事是一个关于坚持、务实和专注技术本质的案例。在 15 年的运行中，它证明了：简单的架构可以服务大量用户"过时"的技术仍然可靠教育价值可以超越商业利益50 万人在 Webminal 上输入了他们的第一个 ls 命令。其中一些人已经成为系统管理员，一些人管理着自己的服务器，有些人管理的基础设施甚至比创始人还要多。只要还能帮助一个学生，Webminal 就会继续运行。参考资料15 years, one server, 8GB RAM and 500k users - how Webminal refuses to die
Manyana：基于 CRDT 的版本控制系统展望一、新闻概述1. 标题Manyana：Bram Cohen 发布基于 CRDT 的版本控制系统，合并永不失败2. 发布时间2026 年 3 月3. 来源Bram Cohen 官方博客二、核心内容1. 事件摘要A. 主要内容BitTorrent 创始人 Bram Cohen 发布 Manyana 项目，这是一个基于 CRDT（Conflict-Free Replicated Data Types，无冲突复制数据类型）的版本控制系统演示，提出了版本控制的未来愿景。B. 核心亮点合并永不失败，CRDT 保证最终一致性更智能的冲突标记，显示"发生了什么"和"谁做的"行顺序永久化，避免多分支合并问题历史记录存储在数据结构中，而非依赖 DAGRebase 不需要销毁历史约 470 行 Python 代码实现2. 关键信息A. 涉及技术CRDT（Conflict-Free Replicated Data Types）版本控制数据结构：WeaveB. 项目状态概念验证级别演示公有领域代码单文件操作未实现：Cherry-picking、本地撤销C. 核心特性无阻塞合并信息性冲突标记永久行排序历史感知3. 背景介绍A. 作者背景Bram Cohen 是 BitTorrent 的创始人，在分布式系统和版本控制领域有深厚经验。B. 技术背景传统版本控制系统（如 Git）使用 3-way merge，存在冲突处理困难、合并顺序敏感等问题。CRDT 是分布式系统中常用的数据结构，能保证最终一致性。三、详细报道1. 主要内容A. CRDT 基础原理CRDT（无冲突复制数据类型）的核心特性：合并永不失败最终一致性保证合并结果与顺序无关适用于多分支并行开发graph TD A[分支 A 修改] --> M[CRDT 合并] B[分支 B 修改] --> M C[分支 C 修改] --> M M --> R[一致的结果状态] M -.从不失败.-> RB. 冲突标记改进传统 VCS 的冲突标记：<<<<<<< left ======= def calculate(x): a = x * 2 logger.debug(f"a={a}") b = a + 1 return b >>>>>>> rightManyana 的智能冲突标记：<<<<<<< begin deleted left def calculate(x): a = x * 2 ======= begin added right logger.debug(f"a={a}") ======= begin deleted left b = a + 1 return b >>>>>>> end conflict改进点：标记显示操作类型（删除/添加）标记显示操作来源（left/right）清晰展示冲突的结构无需脑力重构发生了什么C. 核心设计特性特性 1：行顺序永久化当两个分支在同一点插入代码时，CRDT 选择一个顺序并保持永久。这解决了以下问题：冲突部分在不同分支上以不同顺序解决多人独立工作时合并结果不一致传统 VCS 在没有共同祖先时的合并困难特性 2：冲突不阻塞合并合并总是产生结果并发编辑"距离太近"时才会标记冲突冲突仅用于审查，不阻止工作继续算法追踪"每边做了什么"，而非仅显示两个结果特性 3：历史存储在结构中状态是一个 Weave（编织结构）：包含文件中曾经存在的每一行每行带有添加和删除的时间元数据合并不需要查找共同祖先不需要遍历 DAGgraph LR A[状态 A] --> M[CRDT 合并] B[状态 B] --> M M --> R[结果状态] R --> W[Weave 结构 包含完整历史] W -.无需.-> DAG[传统 DAG]D. Rebase 的改进传统 Rebase 的问题：创建虚构历史销毁原始提交的真实上下文激进 rebase 产生无共同祖先的拓扑CRDT 系统的 Rebase：可以逐个重放提交到新基线同时保留完整历史仅需在 DAG 中添加"主要祖先"注解优势：激进 rebase 不再破坏可追溯性传统 3-way merge 在无共同祖先时失效CRDT 不在乎，历史在 Weave 中2. 技术细节A. 架构设计graph TB subgraph Manyana File[文件] --> CRDT[CRDT 引擎] CRDT --> Weave[Weave 结构] Weave --> History[历史记录] Weave --> State[当前状态] end CRDT -.合并永不失败.-> Weave Weave -.包含.-> History Weave -.派生.-> StateC. Weave 数据结构Weave 是 Manyana 的核心数据结构：特点：单一结构包含所有历史行每行带有完整生命周期元数据支持高效的合并操作无需重构历史优势：合并复杂度与历史深度无关支持任意分支拓扑天然支持多路合并3. 数据与事实A. 项目规模代码量：约 470 行 Python许可证：公有领域（Public Domain）功能范围：单文件操作演示B. 已实现功能CRDT 合并引擎智能冲突标记Weave 数据结构基本版本控制操作C. 未实现功能Cherry-picking（拣选提交）本地撤销多文件支持完整 VCS 功能D. 设计文档完整设计文档包含在 README 中，涵盖了：Cherry-picking 的设计思路本地撤销的实现方案完整 VCS 的构建路径四、影响分析1. 行业影响A. 技术趋势CRDT 在版本控制领域的应用探索从"冲突解决"到"冲突避免"的范式转变分布式版本控制的新方向B. 竞争格局Git 统治地位面临新思路挑战其他 CRDT VCS 项目：Dolt、Yjs 等传统 VCS 可能借鉴部分概念C. 生态影响可能催生下一代版本控制工具对协作工具有启发意义推动 CRDT 技术更广泛应用2. 用户影响A. 潜在收益减少合并冲突处理时间更清晰的冲突上下文更自信的分支和合并操作更好的多团队协作体验B. 学习成本新的冲突标记语法不同的工作流程概念需要理解 CRDT 基本原理C. 迁移挑战从 Git 迁移的成本工具链生态成熟度团队采用阻力3. 技术趋势A. 技术方向从 DAG-first 到 Structure-first从冲突解决到冲突避免历史可追溯性优先分布式协作优化B. 未来发展完整 VCS 实现的可能性与现有工具的集成性能优化和扩展性企业级功能需求五、各方反应1. 官方立场Bram Cohen 强调 Manyana 是一个"演示"而非完整的版本控制系统，主要证明两点：CRDT 版本控制可以处理困难的 UX 问题提供了比现有工具更好的解决方案2. 技术意义A. 突破点解决了传统 VCS 的根本性问题提供了清晰的冲突展示保留了完整的历史记录B. 局限性当前仅为概念验证缺少完整 VCS 的功能需要更多工程实践3. 社区关注点A. 积极评价CRDT 应用方向的创新冲突标记的实际改进开源和公有领域贡献B. 技术讨论CRDT 在大规模代码库的性能与 Git 生态的兼容性实际生产环境的适用性C. 未来展望期待完整的 VCS 实现希望更多工具集成关注项目发展动态六、相关链接1. 项目资源Manyana 代码仓库README 设计文档2. 技术背景CRDT 论文和研究Bram Cohen 的技术博客3. 相关项目Dolt（SQL 版本控制）Yjs（CRDT 框架）Automerge（CRDF 实现）参考资料Manyana - Bram Cohen's Blog
贝叶斯统计入门指南一、概述1. 简介A. 是什么贝叶斯统计是一种统计推断方法，它将概率视为对不确定性的度量，而非事件发生的长期频率。与频率学派统计不同，贝叶斯统计将模型参数视为随机变量，通过数据不断更新对参数的认知。B. 为什么学提供更直观的不确定性量化方式先验知识可以自然地融入模型特别适合小数据场景和复杂模型可信区间比置信区间更易理解C. 学完能做什么理解贝叶斯与频率学派的核心区别使用贝叶斯方法进行参数估计应用 PyMC 等 MCMC 工具解决实际问题构建包含先验知识的稳健模型2. 前置知识A. 必备技能基础概率论概念条件概率和贝叶斯定理Python 编程基础B. 推荐知识频率学派统计基础最大似然估计线性回归二、核心概念1. 哲学差异贝叶斯统计与频率学派统计的根本区别在于对概率的理解：维度频率学派贝叶斯学派参数固定但未知随机变量，服从分布数据随机抽样固定观测值概率长期频率不确定性的度量区间估计置信区间可信区间A. 置信区间 vs 可信区间置信区间：如果重复抽样多次，95% 的区间会包含真实参数可信区间：参数有 95% 的概率落在该区间内graph LR A[问题] --> B{统计框架} B --> C[频率学派] B --> D[贝叶斯学派] C --> E[参数固定] C --> F[数据随机] C --> G[置信区间] D --> H[参数分布] D --> I[数据固定] D --> J[可信区间]2. 贝叶斯定理贝叶斯推断的核心是贝叶斯定理：P(θ|X) = P(X|θ) × P(θ) / P(X)其中：P(θ|X)：后验分布，是我们想求解的P(X|θ)：似然函数，表示给定参数下观测数据的概率P(θ)：先验分布，表示对参数的初始认知P(X)：标准化常数，通常不需要显式计算graph TD A[先验分布] --> B[观测数据] B --> C[似然函数] A --> D[贝叶斯定理] C --> D D --> E[后验分布] E --> F[后验预测分布]3. 核心术语先验分布：对参数的初始假设似然函数：数据对参数的支持程度后验分布：结合先验和数据后的参数认知MAP 估计：最大后验概率估计后验预测分布：对新数据的预测分布三、快速上手1. 骰子问题示例假设你观察到一个骰子投掷 8 次，结果为 [1, 1, 2, 3, 3, 4, 4, 4]，但不知道骰子有多少面。A. 频率学派方法使用最大似然估计：P(X|n) = (1/n)^8当 n = 4 时似然最大，因为投掷结果的最大值为 4。95% 置信区间为 [4, 6]。B. 贝叶斯学派方法选择先验分布 P(n)，计算后验分布：P(n|X) ∝ (1/n)^k × P(n)使用均匀先验时，后验均值约为 4.26，95% 可信区间为 [4, 5]。2. 先验的影响先验分布的作用：数据少时，先验影响大数据多时，似然函数主导后验好的先验可以补偿数据不足import pymc as pm import numpy as np # 观测数据 observations = np.array([1, 1, 2, 3, 3, 4, 4, 4]) k = len(observations) x_max = int(observations.max()) with pm.Model() as model: # 几何先验 excess = pm.Geometric("excess", p=0.5) - 1 n = pm.Deterministic("n", excess + x_max) # 似然函数 pm.Potential("likelihood", -k * pm.math.log(n)) # MCMC 采样 trace = pm.sample(10000, tune=2000, chains=4) # 获取后验分布 posterior_n = trace.posterior["n"].values.flatten() print(f"后验均值: {posterior_n.mean():.2f}")3. 环境准备安装必要的 Python 库：pip install pymc arviz numpy matplotlib四、进阶内容1. 实际应用案例A. 地理分布建模问题：根据历史订单数据生成合成数据，需要按地理位置分配订单。频率学派问题：对新类别或新邮编不鲁棒数据稀疏时估计分布噪声大贝叶斯解决方案：使用 Dirichlet-Multinomial 分布建模似然使用人口分布作为先验（非稀疏）先验作为数据不足时的后备2. 数值方法：MCMC当后验分布无法解析求解时，使用马尔可夫链蒙特卡洛方法。A. Metropolis 算法从当前点 θ_t 提议新点 θ_{t+1}，以以下概率接受：min(1, P(θ_{t+1}|X) / P(θ_t|X))关键优势：不需要计算标准化常数 P(X)。B. NUTS 算法PyMC 默认使用的 No-U-Turn Sampler，是 Hamiltonian Monte Carlo 的改进版本，效率更高。graph LR A[定义先验] --> B[定义似然] B --> C[MCMC 采样] C --> D[后验分布] D --> E[统计分析]3. 线性回归的贝叶斯方法A. 基础实现import pymc as pm import arviz as az with pm.Model() as model: # 先验 a = pm.Normal("a", mu=0, sigma=10) b = pm.Normal("b", mu=0, sigma=10) sigma = pm.HalfNormal("sigma", sigma=10) # 似然 y_obs = pm.Normal("y_obs", mu=a * x + b, sigma=sigma, observed=y) # 采样 trace = pm.sample(1000, tune=1000, chains=4) # 提取结果 a_mean = trace.posterior["a"].values.mean() b_mean = trace.posterior["b"].values.mean()B. 处理异常值使用混合模型处理异常数据：with pm.Model() as model: # 先验 a = pm.Normal("a", mu=0, sigma=10) b = pm.Normal("b", mu=0, sigma=10) sigma = pm.HalfNormal("sigma", sigma=10) delta = pm.HalfNormal("delta", sigma=5) sigma_bgd = pm.Deterministic("sigma_bgd", sigma + delta) # 混合权重 gs = pm.Beta("gs", alpha=2, beta=2, shape=len(x)) # 混合似然 mu = a * x + b w = pm.math.stack([gs, 1 - gs], axis=1) pm.Mixture( "likelihood", w=w, comp_dists=[ pm.Normal.dist(mu=mu, sigma=sigma), pm.Normal.dist(mu=mu, sigma=sigma_bgd), ], observed=y, ) trace = pm.sample(1000, tune=1000, chains=4)4. 与正则化的关系频率学派的正则化方法本质上是贝叶斯先验：Ridge 回归（L2）= 高斯先验Lasso 回归（L1）= 拉普拉斯先验目标函数：θ_MAP = min_θ Σ(y_i - θ_0 - θ_1×x_i)^2/σ^2 + F(θ)五、最佳实践1. 先验选择使用无信息先验（均匀分布、宽高斯分布）当缺乏领域知识使用有信息先验（领域知识）当数据稀疏确保先验覆盖所有合理的参数值2. 收敛诊断检查多条链的混合情况查看 R-hat 统计量（应接近 1）检查轨迹图的自相关性3. 模型验证使用后验预测检验交叉验证与频率学派方法对比六、常见问题1. 先验是否敏感数据少时敏感，数据多时影响小。Bernstein-von Mises 定理保证在大数据极限下，贝叶斯与频率学派方法收敛到同一结果。2. 计算成本MCMC 方法计算成本较高，但对于复杂问题比解析求解可行得多。使用 NUTS 算法可以提高效率。3. 何时使用贝叶斯方法小数据场景需要融入先验知识需要直观的不确定性量化复杂层次模型参考资料Bayesian statistics for confused data scientistsFrequentism and Bayesianism: A Practical IntroductionA Modern Introduction to Probabilistic Programming with PyMCPyMC library homepage
微信 iLink Bot SDK 技术文档一、概述1. 项目简介A. 是什么weixin-bot 是一个微信 iLink Bot SDK，支持 Node.js 和 Python 两种语言实现。它为开发者提供了一套简洁的 API，让任何 Agent 可以在 5 分钟内接入微信消息收发功能。B. 为什么需要它传统的微信机器人接入面临以下痛点：协议复杂，需要深入理解微信 iLink Bot APIcontext_token 管理繁琐，处理不当会导致消息投递失败Session 过期需要手动重新登录需要配置 Webhook 接收消息，部署复杂weixin-bot SDK 通过封装底层协议细节，解决了这些问题：零配置，开箱即用凭证自动保存和续期context_token 自动管理长轮询收消息，无需 WebhookC. 应用场景AI Agent 接入微信作为交互渠道客服机器人自动回复群聊助手和消息监听微信消息自动化处理2. 技术背景A. iLink Bot APIiLink Bot API 是微信提供的机器人接口协议，采用 HTTP 长轮询方式接收消息，通过 HTTP POST 发送消息。关键特性包括：扫码登录认证长轮询获取更新context_token 上下文传递机制Typing 状态支持B. 协议关键发现SDK 开发过程中发现的关键协议细节：context_token：回复消息时必须原样传回 APIsendtyping：唯一能触发"对方正在输入中"的方式message_state：GENERATING 状态在 API 层面可用，但微信客户端不渲染Session 过期：errcode 为 -14 时需要重新登录二、系统架构1. 整体架构graph TB Agent[Agent 应用] -->|调用| SDK[weixin-bot SDK] SDK -->|HTTP 长轮询| API[iLink Bot API] SDK -->|HTTP POST| API API -->|推送消息| User[微信用户] User -->|扫码/发消息| API SDK -->|保存凭证| Local[本地存储]2. 组件说明Agent 应用：使用 SDK 的上层应用，如 AI Agent、客服机器人weixin-bot SDK：封装 iLink Bot API 协议的 SDK 库iLink Bot API：微信提供的机器人接口服务本地存储：保存登录凭证，避免重复扫码3. 交互流程sequenceDiagram participant Agent as Agent 应用 participant SDK as weixin-bot SDK participant API as iLink Bot API participant User as 微信用户 Note over Agent,User: 1. 登录阶段 Agent->>SDK: bot.login() SDK->>API: GET /get_bot_qrcode?bot_type=3 API-->>SDK: 返回二维码 URL SDK-->>Agent: 终端显示二维码 User->>API: 微信扫码确认 API-->>SDK: 返回 bot_token + baseurl SDK-->>Agent: 登录成功，凭证已保存 Note over Agent,User: 2. 消息收发循环 Agent->>SDK: bot.run() loop 长轮询循环 SDK->>API: POST /getupdates (最多保持 35 秒) User->>API: 发送消息 "你好" API-->>SDK: 返回消息 + context_token SDK-->>Agent: 触发 onMessage(msg) Agent->>SDK: bot.sendTyping(userId) SDK->>API: POST /sendtyping Note over User: 显示 "对方正在输入中" Agent->>SDK: bot.reply(msg, "Echo: 你好") SDK->>API: POST /sendmessage (带 context_token) API-->>User: 推送回复消息 SDK->>API: POST /sendtyping (取消 typing) end Note over Agent,User: 3. 异常处理 API-->>SDK: 返回 errcode: -14 (Session 过期) SDK->>SDK: 自动触发重新登录 SDK->>API: 重新获取二维码和 token SDK-->>Agent: 自动恢复运行三、安装指南1. 系统要求Node.js：14+ 版本Python：3.7+ 版本网络环境：可访问微信 iLink Bot API2. Node.js 安装npm install @pinixai/weixin-bot3. Python 安装pip install weixin-bot-sdk四、快速入门1. Node.js 示例import { WeixinBot } from '@pinixai/weixin-bot' const bot = new WeixinBot() await bot.login() bot.onMessage(async (msg) => { await bot.sendTyping(msg.userId) await bot.reply(msg, `Echo: ${msg.text}`) }) await bot.run()2. Python 示例from weixin_bot import WeixinBot bot = WeixinBot() bot.login() @bot.on_message async def handle(msg): await bot.send_typing(msg.user_id) await bot.reply(msg, f"Echo: {msg.text}") bot.run()3. 运行流程创建 WeixinBot 实例调用 login() 方法，终端显示二维码使用微信扫码确认登录注册消息处理回调调用 run() 启动长轮询循环五、API 参考1. 核心方法方法参数说明login()force?: boolean扫码登录，已有凭证则自动跳过onMessage()handler: Function注册消息处理回调reply()msg, text回复消息，自动取消 typing 状态send()userId, text主动发消息，需已有 context_tokensendTyping()userId显示"对方正在输入中"stopTyping()userId取消输入状态run()无启动长轮询循环stop()无停止运行2. 消息对象interface Message { userId: string // 用户 ID text: string // 消息文本 contextToken: string // 上下文 token，SDK 自动管理 }3. 使用示例// 回复消息 await bot.reply(msg, "收到你的消息") // 主动发消息 await bot.send(userId, "你好") // 显示 typing 状态 await bot.sendTyping(userId) // 取消 typing 状态 await bot.stopTyping(userId)六、高级特性1. context_token 自动管理context_token 是 iLink Bot API 的关键机制：API 返回消息时携带 context_token回复消息时必须原样传回，否则消息无法投递SDK 内部自动管理，开发者无需关心2. Typing 状态sendtyping 是唯一能触发"对方正在输入中"的方式：await bot.sendTyping(userId) // 开始输入状态 // ... 处理消息 ... await bot.reply(msg, text) // reply 会自动取消 typing3. Session 过期自动处理当 Session 过期（errcode: -14）时：SDK 自动检测到错误自动触发重新登录流程恢复后继续运行4. 凭证持久化登录成功后，SDK 自动保存凭证：bot_tokenbaseurl后续启动自动加载凭证，无需重复扫码七、技术细节1. 长轮询机制SDK 使用长轮询获取消息更新：请求 /getupdates 接口最多保持 35 秒有消息立即返回无消息超时返回空数组循环往复持续监听2. 消息投递保证为保证消息成功投递：使用收到的 context_token 原样传回SDK 内部维护 userId 到 context_token 的映射避免跨会话复用 token3. 协议限制以下是协议分析和使用中发现的限制：message_state: GENERATING 在 API 层面可用，但微信客户端不渲染气泡更新，不建议使用sendtyping 是唯一可靠的 typing 触发方式Session 会定期过期，需要处理 -14 错误码八、最佳实践1. 消息处理建议bot.onMessage(async (msg) => { try { // 1. 先显示 typing，提升用户体验 await bot.sendTyping(msg.userId) // 2. 处理业务逻辑 const response = await processMessage(msg.text) // 3. 回复消息（自动取消 typing） await bot.reply(msg, response) } catch (error) { console.error('处理消息失败:', error) } })2. 错误处理bot.onMessage(async (msg) => { try { await bot.reply(msg, "处理中...") } catch (error) { if (error.code === -14) { console.log('Session 过期，SDK 会自动重连') } else { console.error('发送消息失败:', error) } } })3. 资源清理// 优雅退出 process.on('SIGINT', async () => { console.log('正在停止 bot...') bot.stop() process.exit(0) })九、故障排查1. 常见问题问题：登录后收不到消息检查网络连接确认 run() 方法已调用查看控制台是否有错误日志问题：消息发送失败确认 context_token 有效检查是否使用 reply() 方法而非 send()查看错误码和错误信息问题：频繁要求重新登录检查 IP 是否被限制确认账号状态正常Session 有效期可能较短，属于正常现象2. 日志调试SDK 输出详细日志，方便调试：登录状态消息收发错误信息十、生态资源1. 官方资源GitHub 仓库：https://github.com/epiral/weixin-bot协议文档：docs/protocol-spec.md（1200+ 行详细分析）2. 示例项目Node.js Echo Bot：完整示例，含日志和 typingNode.js 流式测试：GENERATING vs FINISH 测试Node.js Typing 测试：sendtyping vs GENERATING 对比3. 相关包@pinixai/weixin-bot：Node.js SDKweixin-bot-sdk：Python SDK参考资料epiral/weixin-bot - GitHub
Astral 加入 OpenAI一、新闻概述1. 标题Astral 宣布加入 OpenAI，Ruff 和 uv 等工具将继续开源2. 发布时间2025 年（具体日期未在原文中注明）3. 来源Astral 官方博客二、核心内容1. 事件摘要A. 主要内容Astral 公司宣布已达成协议加入 OpenAI，成为 Codex 团队的一部分。B. 核心亮点Astral 被 OpenAI 收购，加入 Codex 团队开源工具 Ruff、uv、ty 将继续维护每月下载量达数亿次承诺继续保持开源2. 关键信息A. 涉及产品Ruff：Python 代码检查工具uv：Python 包管理工具ty：类型检查工具B. 重要数据月下载量：数亿次公司成立时间：约 3 年投资方：Accel（种子轮和 A 轮）、a16z（B 轮）C. 收购方OpenAI Codex 团队3. 背景介绍A. 公司历史Astral 由 Charlie Marsh 创立，致力于改变 Python 开发体验。三年前的发布文章中提到："如果能让 Python 生态系统生产力提高 1%，想象一下这种影响会如何复合增长。"B. 相关上下文Astral 开发的工具链已成为现代 Python 开发的基础设施。Ruff 作为快速的 Python linter，uv 作为极速的 Python 包管理器，在开发者社区中广受欢迎。三、详细报道1. 主要内容A. 收购详情Astral 团队将加入 OpenAI 的 Codex 团队收购完成后将继续支持开源工具保持与社区共同构建的开发模式B. 开源承诺所有工具将继续开源继续为 Python 生态系统构建工具与 OpenAI 的开源理念一致C. 未来规划继续维护现有开源工具探索与 Codex 的集成方式更广泛地思考软件开发未来2. 技术细节A. Astral 工具链架构graph LR Dev[开发者] --> Ruff[Ruff 代码检查] Dev --> uv[uv 包管理] Dev --> ty[ty 类型检查] Ruff --> Code[高质量代码] uv --> Env[快速环境] ty --> Type[类型安全]B. 工具特点Ruff：用 Rust 编写的极速 Python linteruv：用 Rust 编写的极速 Python 包管理器ty：类型检查工具C. OpenAI Codex 集成展望Astral 工具与 Codex 的无缝集成AI 辅助编程工具链增强提升软件开发生产力3. 数据与事实A. 用户规模月下载量达数亿次工具已成为 Python 开发基础设施B. 投资情况Accel 领投种子轮和 A 轮a16z 领投 B 轮C. 社区影响拥有全球用户基础被称为"最受喜爱的软件之一"四、影响分析1. 行业影响A. 技术趋势AI 与开发工具的深度融合开源工具在 AI 时代的重要性Rust 编写的工具在开发者工具领域的崛起B. 竞争格局OpenAI 加强开发工具领域布局Python 开发工具进入 AI 辅助新阶段可能推动其他厂商类似投资2. 用户影响A. 现有用户工具将继续免费开源功能持续改进可能获得 AI 增强功能B. 潜在用户更易接触 AI 辅助开发工具Python 开发体验提升C. 迁移成本无需迁移，工具保持不变可选的新 AI 功能3. 技术趋势A. 技术方向AI 与传统开发工具的边界模糊开源与商业模式的结合探索开发者工具进入新纪元B. 生态影响Python 生态系统持续繁荣开发工具标准化加速AI 辅助编程成为标配五、各方反应1. 官方回应Astral 创始人 Charlie Marsh 表示："AI 正在快速改变我们构建软件的方式，这种变化的步伐只会加速。如果我们的目标是让编程更高效，那么在 AI 和软件的前沿领域构建就感觉是最有杠杆作用的事情。"2. OpenAI 官方声明OpenAI 在其公告中确认将继续支持 Astral 的开源工具。3. 社区反馈A. 正面期待开源承诺获得社区认可期待与 AI 的结合创新B. 关注点收购后产品独立性未来商业化策略六、相关链接1. 官方公告Astral 官方博客公告OpenAI 收购公告2. 项目链接Ruff GitHub 仓库uv GitHub 仓库ty GitHub 仓库参考资料Astral to join OpenAI
Folio-OCR 三栏文档 OCR 工作台一、概述1. 简介A. 是什么Folio-OCR 是一款基于 GLM-OCR 和 Ollama 的三栏文档 OCR 工作台，专为书籍和文档的日常批量识别设计。它提供了一个现代化的 Web 界面，支持图片和 PDF 文件的批量光学字符识别，并具备智能版面分析、实时编辑和多种格式导出功能。B. 为什么学解决文档数字化过程中的人工识别效率问题利用本地化 OCR 方案保护数据隐私学习 FastAPI 前后端分离架构和版面分析技术了解如何将大型语言模型集成到实际应用中C. 学完能做什么搭建本地化的 OCR 识别服务批量处理 PDF 和图片文档使用版面分析技术提高识别准确率将识别结果导出为 Markdown、TXT 或 Word 文档2. 前置知识A. 必备技能基础的 Linux 命令行操作了解 Docker 基础概念B. 推荐知识Python 基础编程知识Web 开发基础概念OCR 和版面分析基础二、环境准备1. 系统要求操作系统：Linux、macOS、Windows 10/11Docker：20.10+（推荐使用 Docker 部署）Python：3.10+（本地部署）Ollama：已安装（本地部署）硬件：建议 8GB+ 内存，有 NVIDIA 显卡可获得更好性能2. 安装步骤Docker 部署（推荐）# 1. 克隆项目 git clone https://github.com/vorojar/Folio-OCR.git cd Folio-OCR # 2. 启动服务 docker compose up -d # 3. 下载 OCR 模型（约 2GB，只需执行一次） docker compose exec ollama ollama pull glm-ocr本地部署# 安装依赖 pip install -r requirements.txt # 拉取模型 ollama pull glm-ocr # 启动服务 python server.py # Windows 一键启动 start.bat3. 验证安装打开浏览器访问 http://localhost:3000，若能看到界面则表示安装成功。# 检查 Ollama 状态 curl http://localhost:11434/api/tags # 检查服务状态 curl http://localhost:3000/api/status三、核心概念1. 基本术语GLM-OCR：智谱 AI 开发的 OCR 模型，用于图像文字识别Ollama：本地化大模型运行平台，提供 GLM-OCR 的推理服务FastAPI：Python Web 框架，用于构建后端 APIPP-DocLayoutV3：PaddlePaddle 的文档版面分析模型SQLite：轻量级数据库，用于持久化存储文档和 OCR 结果版面分析：自动检测文档中的标题、正文、表格、图片等区域2. 工作原理graph LR User[用户] --> FE[前端界面] FE --> API[FastAPI 后端] API --> DB[(SQLite 数据库)] API --> Layout[版面分析模型] API --> Ollama[Ollama OCR 服务] Layout --> API Ollama --> API API --> FE API --> Storage[文件存储]系统采用三层架构设计：前端层：提供三栏式用户界面，负责文件上传、结果显示和用户交互后端层：FastAPI 提供 RESTful API，处理版面分析、OCR 调用和数据持久化服务层：Ollama 提供 OCR 推理服务，PP-DocLayoutV3 提供版面分析能力四、快速上手1. 基本使用流程graph TD A[启动服务] --> B[上传文档] B --> C[自动拆页处理] C --> D[版面分析] D --> E[OCR 识别] E --> F[编辑校对] F --> G[导出文档]2. 上传文档支持以下文件格式：图片：PNG、JPG、GIF、BMP文档：PDF支持多文件混合上传，系统会自动将所有文件合并为一个文档，并按页码顺序排列。3. OCR 识别系统提供两种 OCR 模式：单页识别：对选中的页面进行 OCR批量识别：点击 OCR All Pages 一键处理全部页面识别过程中会显示实时进度条和 ETA 时间估算，用户可以随时点击 Stop 按钮中断处理。4. 编辑与导出识别结果支持：Edit 模式：纯文本编辑，便于手动修正Preview 模式：实时渲染 HTML 表格和 Markdown 格式段落重排：自动合并因换行断开的段落导出格式：Markdown（.md）纯文本（.txt）Word 文档（.docx）五、核心功能1. OCR 引擎A. 版面分析使用 PP-DocLayoutV3 模型进行智能版面分析，自动识别以下区域：标题（title）正文（text）表格（table）图片（figure）页眉页脚、脚注、页码（自动跳过）B. 智能合并相邻文本区域会自动合并，减少 OCR 调用次数。例如 11 个文本区域可合并为 3 组，实现约 2.5 倍加速。C. LaTeX 处理自动将模型输出的 LaTeX 符号转换为 Unicode 字符：$\textcircled{1}$ → ①$\frac{1}{2}$ → ½其他常见数学符号D. 清理处理自动清理模型输出的 Markdown 围栏标记。2. 数据持久化使用 SQLite 数据库存储以下信息：文档元数据（ID、文件名、创建时间）页面信息（页码、文件名、OCR 结果、版面区域、处理时间）自动保存编辑内容（800ms 防抖）3. 界面交互A. 三栏布局左栏：页面缩略图，支持快速切换页面中栏：图片预览，显示版面分析区域框右栏：OCR 结果，支持编辑和预览B. 双向高亮点击图片中的区域框会高亮对应的文本块，点击文本块会高亮对应的图片区域。C. 全文搜索支持 Ctrl+F 全文搜索，跨页高亮显示匹配内容并统计命中次数。D. 键盘导航使用 ↑↓ 方向键快速切换页面。4. 网络容错所有网络请求都带有超时保护：状态检查：5 秒OCR 调用：180 秒其他请求：30 秒Ollama 断开后 UI 不会冻结，超时后会自动恢复可操作状态并通过 Toast 弹窗通知用户。六、技术架构1. 后端架构graph TB subgraph 后端服务 API[FastAPI Server] DB[(SQLite)] Layout[PP-DocLayoutV3] Uploads[uploads/ 目录] end subgraph 外部服务 Ollama[Ollama GLM-OCR] end API --> DB API --> Layout API --> Uploads API --> Ollama2. 版面分析流程sequenceDiagram participant U as 用户 participant API as FastAPI participant L as Layout 模型 participant O as Ollama U->>API: 上传图片 API->>L: 版面分析 L-->>API: 返回区域列表 API->>API: 合并相邻区域 loop 对每个合并区域 API->>O: OCR 调用 O-->>API: 返回识别文本 end API->>U: 返回完整结果3. 数据库设计erDiagram documents ||--o{ pages : 包含 documents { string doc_id PK string filename string created_at } pages { string doc_id FK integer num string filename text ocr_text text ocr_regions real ocr_time }4. 主要依赖依赖版本用途fastapi>=0.100.0Web 框架uvicorn>=0.23.0ASGI 服务器httpx>=0.25.0异步 HTTP 客户端pymupdf>=1.23.0PDF 处理Pillow>=10.0.0图像处理transformers>=4.40.0版面分析模型torch>=2.0.0深度学习框架python-docx>=1.1.0Word 文档生成七、部署架构1. Docker Compose 配置graph LR Host[宿主机] --> LB[Nginx/Proxy] LB --> App[App 容器] LB --> Ollama[Ollama 容器] App --> DB[(SQLite 数据卷)] App --> Files[uploads 数据卷]2. GPU 加速若有 NVIDIA 显卡，可编辑 docker-compose.yml 取消 deploy 段落的注释以启用 GPU 加速。services: ollama: deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]3. 常用 Docker 命令docker compose down # 停止服务 docker compose up -d # 重新启动（数据不会丢失） docker compose logs -f app # 查看应用日志 docker compose logs -f ollama # 查看 Ollama 日志八、性能参考操作时间说明模型冷启动首次请求~50 秒需加载模型到内存后续单页识别~0.5 秒版面分析 + OCRPDF 渲染取决于页数2x 缩放矩阵渲染整体加速比2.5x相比逐区域 OCR九、常见问题1. 安装问题Ollama 未找到错误信息：Ollama not found解决方法：先安装 Ollama 并确保其在 PATH 中# macOS/Linux curl -fsSL https://ollama.com/install.sh | sh # Windows # 从 https://ollama.com/download 下载安装包模型下载失败解决方法：检查网络连接，手动执行模型拉取ollama pull glm-ocr2. 运行问题OCR 超时可能原因：图片过大或网络问题解决方法：系统已设置 180 秒超时，等待即可检查 Ollama 服务是否正常运行尝试重启服务版面分析失败可能原因：模型未正确加载解决方法：确保已安装 torch 和 transformers检查服务器日志查看具体错误3. 使用问题PDF 拆页不清晰说明：系统使用 2x 缩放矩阵渲染 PDF 以保证 OCR 质量解决方法：如需更高分辨率，可修改 server.py 中的 mat 参数导出的 Word 文档格式问题说明：DOCX 导出基于 python-docx，解析 OCR 结果中的表格和标题解决方法：识别时确保版面分析正确检测到表格区域十、项目结构Folio-OCR/ ├── server.py # FastAPI 后端（单文件） ├── index.html # HTML 页面 ├── script.js # 前端逻辑 ├── style.css # 样式 ├── latex_unicode.json # LaTeX → Unicode 映射表 ├── requirements.txt # Python 依赖 ├── Dockerfile # Docker 镜像构建 ├── docker-compose.yml # Docker Compose 编排 ├── start.bat # Windows 启动脚本 ├── folio_ocr.db # SQLite 数据库（运行时生成） └── uploads/ # 上传文件目录（运行时生成）十一、API 端点方法路径说明GET/前端页面GET/api/status服务状态、Ollama 连通性POST/api/load-model启动 Ollama 并预热模型POST/api/upload上传文件，返回 SSE 页面流GET/api/images/{doc_id}/{filename}获取页面图片POST/api/ocr/{doc_id}/{page_num}单页 OCRPOST/api/ocr/{doc_id}/all批量 OCR 全部页面GET/api/documents列出所有文档GET/api/documents/{doc_id}获取文档详情DELETE/api/documents/{doc_id}删除文档PUT/api/pages/{doc_id}/{page_num}/text保存编辑后的文本POST/api/export/{doc_id}导出 DOCX参考资料Folio-OCR GitHub 仓库GLM-OCR 模型Ollama 官方文档FastAPI 官方文档PP-DocLayoutV3 模型
Tiny Wi-Fi Analyzer 开源项目介绍一、新闻概述1. 标题Tiny Wi-Fi Analyzer：轻量级开源 macOS Wi-Fi 分析工具2. 发布时间2020 年 10 月 13 日（首次发布），最新版本 v0.6.1 于 2026 年 1 月 25 日发布3. 来源GitHub 开源项目二、核心内容1. 事件摘要A. 主要内容Tiny Wi-Fi Analyzer 是一个专为 macOS 平台设计的开源 Wi-Fi 网络分析工具，提供了简洁直观的界面来实时监控和分析 Wi-Fi 网络状态。B. 核心亮点完全开源，基于 Apache-2.0 许可证轻量级设计，专注于 Wi-Fi 分析核心功能实时监控 Wi-Fi 网络状态支持多频段 Wi-Fi 网络（2.4 GHz、5 GHz、6 GHz）2. 关键信息A. 版本号当前最新版本：v0.6.1B. 重要数据GitHub Stars：253Fork 数量：7支持平台：macOS 10.15 (Catalina) 及以上版本C. 涉及技术PyObjC：Python 与 Objective-C 桥接pywebview：跨平台 GUI 框架ApexCharts：交互式图表库PyInstaller：Python 应用打包工具3. 背景介绍A. 项目历史该项目由开发者 nolze 于 2020 年 10 月创建，持续维护更新至今。项目在 GitHub 社区获得了一定的关注度，曾被多家科技媒体和社区推荐。B. 相关上下文macOS 平台上的 Wi-Fi 分析工具相对较少，商业化工具价格昂贵。Tiny Wi-Fi Analyzer 填补了开源免费工具的市场空白。三、详细报道1. 主要功能A. 实时网络监控实时更新 Wi-Fi 网络列表显示网络信号强度自动刷新网络状态B. 多频段支持2.4 GHz 频段：覆盖范围广，穿墙能力强5 GHz 频段：速度快，干扰少6 GHz 频段：最新 Wi-Fi 6E/7 标准C. 数据可视化交互式图表展示网络分布支持按 SSID 高亮显示图表可导出为 PNG、JPEG、SVG 格式D. 数据导出支持导出图表数据为 CSV 文件便于进一步数据分析2. 技术架构A. 系统架构graph TB UI[用户界面 pywebview] --> Core[核心分析引擎] Core --> PyObjC[PyObjC 桥接层] PyObjC --> macOS[macOS Wi-Fi API] Core --> Charts[图表渲染 ApexCharts] Data[数据层] --> Core Export[导出模块] --> Core Export --> Image[图片导出] Export --> CSV[CSV 导出]B. 技术栈分析后端：Python：主要开发语言（占比 51.4%）PyObjC：与 macOS 系统 API 交互Poetry：依赖管理和打包工具前端：HTML/CSS/JavaScript：界面开发（占比 47.2%）ApexCharts：数据可视化图表库pnpm：前端包管理工具构建：PyInstaller：打包为 macOS 应用程序Makefile：自动化构建脚本3. 安装与使用A. 系统要求macOS 10.15 (Catalina) 或更高版本可能在 macOS 10.14 及更早版本上运行B. 下载方式访问 GitHub Releases 页面下载最新版本的 .app 文件C. 首次运行注意事项由于应用未进行签名，需要按以下步骤运行：右键点击应用图标选择"打开"在弹出的对话框中点击"确定"D. 权限要求在 macOS 14 Sonoma 及更高版本上，获取 Wi-Fi SSID 需要位置服务权限，用户需要在系统设置中启用位置服务授权。四、影响分析1. 行业影响A. 工具生态填补了 macOS 平台开源 Wi-Fi 分析工具的空白，为网络诊断和优化提供了新的选择。B. 技术趋势展示了使用 Python 开发原生 macOS 应用的可行性，PyObjC + pywebview 技术栈为跨平台桌面应用开发提供了新思路。2. 用户影响A. 现有用户获得了免费的开源 Wi-Fi 分析工具可以进行网络信号优化和故障排查B. 潜在用户网络管理员：可以使用该工具进行网络规划和优化普通用户：可以查看家中 Wi-Fi 覆盖情况，优化路由器位置C. 使用场景家庭 Wi-Fi 信号优化办公室网络环境诊断公共场所 Wi-Fi 质量评估3. 技术趋势A. 开源替代越来越多的商业化工具出现开源替代品，降低了用户使用门槛。B. 跨平台开发使用 Web 技术构建原生应用成为趋势，pywebview 等技术使得 Python 开发者能够快速创建跨平台桌面应用。五、各方反应1. 官方信息开发者提供了完整的开发文档持续维护更新，最近一次更新为 2026 年 1 月开源社区有 2 名贡献者参与项目维护2. 业内评价A. 媒体报道Jablíčkář.cz（捷克科技媒体）：将其列为值得关注的免费 macOS 应用之一ifun.de（德国科技媒体）：在宽带测量工具更新的报道中提到了该项目B. 社区反馈Reddit r/macapps 社区用户在讨论最喜欢的开源应用时推荐了该项目GitHub 社区持续关注，项目获得 253 个星标3. 用户反馈A. 优点评价界面简洁，操作直观实时更新，响应迅速完全免费，无广告B. 关注点应用未签名，首次运行需要额外操作macOS 14+ 需要位置服务权限，可能引发隐私顾虑仅支持 macOS 平台，Windows/Linux 用户无法使用六、相关链接1. 项目地址GitHub 仓库：https://github.com/nolze/tiny-wifi-analyzer项目主页：https://nolze.github.io/tiny-wifi-analyzer/2. 下载链接最新发布版本：https://github.com/nolze/tiny-wifi-analyzer/releases/latest/3. 技术文档PyObjC 官方文档pywebview 项目主页ApexCharts 文档参考资料Tiny Wi-Fi Analyzer GitHub Project
Squirrel LLM Gateway：企业级 LLM 统一网关发布一、新闻概述1. 标题Squirrel LLM Gateway：企业级 LLM 统一网关开源发布2. 发布时间2026 年 2 月（最新提交：2026-02-16）3. 来源GitHub 开源项目二、核心内容1. 事件摘要A. 主要内容开发者 mylxsw 开源了 Squirrel LLM Gateway，这是一个高性能、企业级的 LLM 代理服务，旨在统一和管理对 OpenAI、Anthropic 等大语言模型提供商的访问。B. 核心亮点统一 API 接口：单一接入点访问多个 LLM 提供商零代码变更：完全兼容 OpenAI 和 Anthropic SDK智能路由：支持基于规则、优先级、权重的请求路由协议转换：内置 OpenAI Chat、OpenAI Responses、Anthropic Messages 之间的协议转换全面可观测性：完整的请求/响应日志、Token 计费、延迟监控2. 关键信息A. 版本信息开源协议：MIT License最新提交：4fa62b0（2026-02-16）Python 版本：3.12+前端：Next.js 16 + TypeScript + shadcn/uiB. 重要数据GitHub Stars：20+Forks：4主要编程语言：Python 73.2%、TypeScript 25.8%C. 涉及技术后端：FastAPI、Alembic、SQLite/PostgreSQL前端：Next.js 16、shadcn/ui协议转换：自研 llm_api_converter SDK容器化：Docker、Docker Compose3. 背景介绍A. 项目定位Squirrel LLM Gateway 定位为企业级 LLM 接入中间件，解决企业在使用多个 LLM 提供商时面临的集成复杂、成本控制、故障切换等问题。B. 相关上下文随着 LLM 技术的快速发展，企业往往需要同时接入多个 LLM 提供商以实现成本优化和风险分散。Squirrel 提供了统一的接入层，简化了这一过程。三、详细报道1. 主要功能A. 统一 API 接口Squirrel 提供了统一的 API 接口，支持：OpenAI 兼容：/v1/chat/completions、/v1/completions、/v1/embeddings、/v1/audio/、/v1/images/OpenAI Responses 兼容：/v1/responses（支持流式和工具调用）Anthropic 兼容：/v1/messages 端点协议转换：OpenAI Chat ↔ OpenAI Responses ↔ Anthropic Messages 之间无缝转换B. 智能路由策略系统支持多种路由策略：轮询（Round-Robin）：均匀分配请求优先级（Priority-Based）：优先使用首选提供商权重（Weight-Based）：按自定义权重分配成本（Cost-Based）：自动选择价格最低的模型基于规则：根据模型名称、请求头、消息内容或 Token 数量路由C. 高可用性设计自动重试：可配置的重试次数（默认 3 次）提供商故障转移：无缝切换到备用提供商超时管理：可配置请求超时（默认 30 分钟）D. 全面可观测性完整请求/响应捕获：包括流式响应Token 追踪：使用 tiktoken 自动计数延迟指标：首字节延迟和总响应时间成本分析：按时间、模型、提供商、API Key 汇总统计数据脱敏：自动处理日志中的敏感信息2. 技术架构graph TB Client[客户端应用] --> Gateway[Squirrel LLM Gateway] Gateway --> Router[智能路由引擎] Router -->|基于规则/优先级/权重/成本| Provider1[OpenAI 提供商] Router --> Provider2[Anthropic 提供商] Router --> Provider3[Azure OpenAI] Router --> Provider4[本地模型] Gateway --> Dashboard[管理控制台] Gateway --> Logger[日志记录] Gateway --> Metrics[指标统计] Logger --> DB[(数据库)] Metrics --> DB Dashboard -->|查询| DB Dashboard -->|管理| Router3. 核心组件A. 后端架构（Python/FastAPI）backend/ ├── app/ │ ├── api/ # API 路由（代理、管理） │ ├── services/ # 业务逻辑 │ ├── providers/ # 协议适配器 │ ├── repositories/ # 数据访问层 │ ├── db/ # 数据库模型 │ ├── domain/ # DTO 和领域模型 │ ├── rules/ # 规则评估引擎 │ └── common/ # 工具函数 ├── migrations/ # Alembic 迁移 └── tests/ # 测试套件B. 协议转换 SDK独立的 llm_api_converter 模块提供：OpenAI ↔ Anthropic 协议转换请求、响应和流式传输支持工具调用（Tool Calls）转换C. 前端架构（Next.js 16）frontend/ └── src/ ├── app/ # Next.js App Router 页面 ├── components/ # React 组件 └── lib/ # 工具和 API 客户端4. 部署方式A. Docker Compose（推荐）git clone https://github.com/mylxsw/llm-gateway.git cd llm-gateway docker compose -f docker-compose.prod.yml up -dB. 单容器 Dockerdocker run -d \ -p 8000:8000 \ -v $(pwd)/data:/data \ --name llm-gateway \ ghcr.io/mylxsw/llm-gateway:latestC. 手动安装后端：cd backend uv sync # 或 pip install -r requirements.txt alembic upgrade head uvicorn app.main:app --host 0.0.0.0 --port 8000前端：cd frontend npm install npm run build && npm run start5. 支持的提供商提供商协议说明OpenAIOpenAI完整支持 GPT-4、GPT-3.5、Embeddings、Audio、ImagesOpenAIOpenAI Responses通过 /v1/responses 提供 Responses APIAnthropicAnthropic通过 Messages API 提供 Claude 模型Azure OpenAIOpenAI使用 Azure 端点 URL本地模型OpenAIOllama、vLLM、LocalAI 等其他提供商OpenAI/Anthropic任何兼容的 API 端点四、影响分析1. 行业影响A. 降低 LLM 接入门槛Squirrel 通过统一的 API 接口和协议转换能力，降低了企业接入多个 LLM 提供商的技术门槛。B. 促进成本优化智能路由和成本分析功能帮助企业优化 LLM 使用成本，实现按需选择最合适的模型。C. 提升系统可靠性故障转移和重试机制提高了 LLM 应用的可靠性，避免单点故障。2. 用户影响A. 开发者无需修改现有代码，直接替换 base_url 即可使用统一的管理界面简化配置和监控详细的日志和指标帮助调试和优化B. 企业用户集中管理多个 LLM 提供商的 API Key细粒度的访问控制和成本分析降低供应商锁定风险C. 迁移成本Docker 部署方式简化安装过程支持 SQLite（开发）和 PostgreSQL（生产）完整的 API 文档和迁移指南3. 技术趋势A. LLM 中间件兴起Squirrel 是 LLM 中间件领域的最新项目，与 similar projects 如 LiteLLM、Portkey 形成竞争。B. 协议标准化内置的协议转换功能反映了 LLM API 标准化的趋势，尽管各提供商的协议仍在演进中。C. 可观测性重要性完整的日志和指标功能凸显了生产环境 LLM 应用对可观测性的需求。五、各方反应1. 开发者社区GitHub 项目刚发布不久，已有 20+ Stars 和 4 Forks项目活跃度高，最近几天仍在持续更新2. 技术亮点A. 协议转换能力内置的 llm_api_converter SDK 是一大亮点，支持三种主流协议之间的无缝转换。B. 现代化技术栈FastAPI + Next.js 16 + shadcn/ui 的组合代表了当前 Python/JavaScript 全栈开发的最佳实践。C. 企业级特性完整的日志记录、成本分析、多维度过滤等功能体现了企业级产品的设计思维。六、相关链接1. 官方资源GitHub 仓库：https://github.com/mylxsw/llm-gatewayDocker 镜像：ghcr.io/mylxsw/llm-gateway:latest2. 技术文档架构设计：docs/architecture.mdAPI 参考：docs/api.md模块详情：docs/modules.md协议转换：docs/protocol_conversion.md3. 相关项目LiteLLM：另一个 LLM 统一接口项目Portkey：LLM 网关和可观测性平台参考资料Squirrel LLM Gateway - GitHub项目 README 文档
一、概述1. 简介Dify 是一个开源的 LLM 应用开发平台，当前已支持音频输入功能。但该功能需要前提条件：本地部署音频识别模型并开放对应的 API 接口。本文记录完整的部署过程，方便后续回溯。A. 是什么FunASR 是阿里巴巴达摩院开源的语音识别工具包，funasr-api 项目将其封装为 RESTful API 服务，可与 Dify 无缝集成。B. 为什么学实现 Dify 应用的语音输入功能掌握本地语音识别模型的部署方法了解 OpenAI 兼容 API 的配置流程C. 学完能做什么本地部署 FunASR 语音识别服务在 Dify 中配置自定义语音识别模型创建支持语音输入的 AI 应用2. 前置知识A. 必备技能Linux 基础操作Python 虚拟环境管理Docker 基础（可选）B. 推荐知识语音识别基本概念RESTful API 调用二、环境准备1. 系统要求操作系统：Linux（推荐 Ubuntu 20.04+）Python 版本：3.8+硬件：支持 CUDA 的 GPU（推荐）或 CPU存储空间：至少 20GB（用于模型文件）2. 硬件要求GPU：NVIDIA 显卡，显存 8GB+CPU：8 核心以上（若使用 CPU 推理）内存：16GB+3. 软件依赖ffmpeg：用于音频格式转换Python 3.8+pip 包管理器三、语音识别模型部署1. 项目获取使用 funasr-api 项目进行部署，该项目提供完整的模型加载和 API 接口功能。GitHub 地址：https://github.com/Quantatirsk/funasr-api下载项目源码：wget https://github.com/Quantatirsk/funasr-api/archive/refs/heads/main.zip unzip funasr-api-main.zip cd funasr-api-main2. 模型下载需要下载以下语音识别模型：模型名称功能说明iic/punc_ct-transformer_zh-cn-common-vad_realtime-vocab272727实时标点预测iic/punc_ct-transformer_zh-cn-common-vocab272727-pytorch标点预测模型iic/speech_fsmn_vad_zh-cn-16k-common-pytorch语音活动检测iic/speech_ngram_lm_zh-cn-ai-wesp-fst语言模型iic/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-online在线 ASR 模型iic/speech_paraformer-large-vad-punc_asr_nat-zh-cn-16k-common-vocab8404-pytorch离线 ASR 模型模型下载后，放置到本地缓存目录：/root/.cache/modelscope/hub/最终模型位置示例：/root/.cache/modelscope/hub/iic/speech_ngram_lm_zh-cn-ai-wesp-fst3. 安装 ffmpegffmpeg 用于音频格式转换，安装方式：Ubuntu/Debian：sudo apt update sudo apt install ffmpegCentOS/RHEL：sudo yum install epel-release sudo yum install ffmpeg验证安装：ffmpeg -version4. Python 环境配置创建虚拟环境并安装依赖：# 创建虚拟环境 python3 -m venv venv source venv/bin/activate # 安装依赖 pip install -r requirements.txt5. 配置文件设置复制并修改配置文件：cp .env.example .env配置文件内容：# 服务器配置 HOST=0.0.0.0 PORT=9584 DEBUG=false # 设备配置 DEVICE=cuda:0 # auto, cpu, cuda:0, npu:0 # Worker 配置 WORKERS=1 # 这里的 INFERENCE_THREAD_POOL_SIZE 不能设置为 auto，否则启动会有报错 # INFERENCE_THREAD_POOL_SIZE=auto # ASR 模型配置 # ASR 模型加载模式：realtime, offline, all ASR_MODEL_MODE=all # 启动时自动预加载的自定义 ASR 模型（逗号分隔） # 可选值：fun-asr-nano # AUTO_LOAD_CUSTOM_ASR_MODELS=fun-asr-nano # 是否启用实时标点模型（用于中间结果展示） ASR_ENABLE_REALTIME_PUNC=true # 远场过滤配置 ASR_ENABLE_NEARFIELD_FILTER=true ASR_NEARFIELD_RMS_THRESHOLD=0.01 ASR_NEARFIELD_FILTER_LOG_ENABLED=true # 鉴权配置（可选） # APPTOKEN=your_token_here # APPKEY=your_key_here # 日志配置 LOG_LEVEL=INFO LOG_FILE=logs/funasr-api.log LOG_MAX_BYTES=20971520 LOG_BACKUP_COUNT=50配置注意事项：INFERENCE_THREAD_POOL_SIZE 不能设置为 auto，否则启动会报错尝试启动 fun-asr-nano 模型可能不成功，建议使用默认的 paraformer-large6. 启动服务python start.py服务启动后，监听地址为 http://localhost:95847. 本地验证使用 curl 进行测试：curl -X POST "http://localhost:9584/v1/audio/transcriptions" \ -F "file=@/root/.cache/modelscope/hub/iic/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-online/example/asr_example.wav" \ -F "model=whisper-1" \ -F "response_format=json"成功返回示例：{ "text": "识别出的文字内容" }四、Dify 模型配置1. 添加模型供应商在 Dify 管理后台操作：点击"设置"-"模型供应商"选择"OpenAI-API-compatible"点击"添加模型"2. 配置语音识别模型选择模型类型为 Speech2Text，填写配置信息：配置项值模型名称自定义名称（如 funasr）API 端点http://your-server:9584/v1/audio/transcriptionsAPI Key（可选，若配置了鉴权）配置完成后，点击"添加"。五、创建语音识别应用1. 新建聊天应用在 Dify 中创建一个新的聊天应用点击"功能"选项卡可以看到新增的"语音转文字"选项2. 启用语音转文字打开"语音转文字"开关点击"发布"-"发布更新"重要提示：如果只打开开关，没有点击"发布更新"，直接点击预览，此时可以看到小话筒，但发送语音会提示"Speech to text is not enable"。这是因为 app_config 文件中的语音识别变量还是 false，所以必须先点击"发布更新"。3. 测试语音识别点击预览按钮点击小话筒图标靠近麦克风说话语音将识别成文字点击发送，识别结果发送给 AI六、系统架构整体架构如下：graph LR A[用户] -->|语音输入| B[Dify应用] B -->|音频数据| C[FunASR API] C -->|识别结果| B B -->|文字对话| D[LLM模型] D -->|回复| B B -->|文字/语音| A七、常见问题1. 模型加载失败问题：启动时报错模型文件不存在解决：检查模型是否下载到正确的缓存目录 /root/.cache/modelscope/hub/2. CUDA 内存不足问题：GPU 显存不够解决：将 DEVICE 配置改为 cpu，或减少 WORKERS 数量3. ffmpeg 未安装问题：音频处理失败解决：使用包管理器安装 ffmpeg4. 语音识别不准确问题：识别结果错误较多解决：确保音频质量良好检查采样率是否为 16kHz尝试调整 ASR_NEARFIELD_RMS_THRESHOLD 参数5. Dify 提示 Speech to text is not enable问题：语音转文字开关已打开但无法使用解决：必须点击"发布更新"，仅打开开关不会生效八、性能优化1. GPU 加速使用 CUDA 设备进行推理批量处理音频请求2. 模型选择实时场景：使用 online 模型离线场景：使用 offline 模型，准确率更高3. 缓存策略启动时预加载常用模型使用 Redis 缓存识别结果九、参考资料funasr-api 项目地址FunASR 官方文档Dify 官方文档
PasteMD 一键粘贴工具项目介绍一、新闻概述1. 标题PasteMD：一键将 Markdown 和 AI 对话完美粘贴到 Word、WPS、Excel 的效率工具2. 发布时间2024 年（持续更新中，最新版本 v0.1.6.8 于 2026 年 1 月 24 日发布）3. 来源GitHub 开源项目二、核心内容1. 事件摘要A. 主要内容PasteMD 是一个常驻系统托盘的效率工具，旨在解决从 ChatGPT、DeepSeek 等 AI 网站复制内容到 Word、WPS 或 Excel 时出现的格式问题，特别是数学公式乱码和表格格式错乱。B. 核心亮点全局热键一键转换 Markdown 到 DOCX智能识别 Markdown 表格并自动粘贴到 Excel支持 HTML 富文本直接转换到 Word/WPS应用扩展功能，可为不同应用配置不同粘贴模式支持自定义 Pandoc Filters 扩展转换功能自动修复 LaTeX 语法和单美元符号公式块2. 关键信息A. 版本号v0.1.6.8（最新版本）B. 重要数据GitHub Stars：约 4000开发语言：Python（95.1%）支持平台：Windows、macOS许可证：MIT LicenseC. 涉及产品目标应用：Microsoft Word、WPS Office、Microsoft Excel依赖工具：Pandoc 文档转换器3. 背景介绍A. 问题起源在日常写作和学术工作中，用户从 AI 对话网站（如 ChatGPT、DeepSeek）复制内容到 Word 时，经常遇到数学公式显示为乱码、表格格式错乱等问题。这是由于 AI 网站通常使用 Markdown 或 HTML 格式输出内容，而 Word 无法直接解析这些格式。B. 相关上下文PasteMD 通过调用 Pandoc 强大的文档转换能力，将剪贴板中的 Markdown 或 HTML 内容转换为 Word 可识别的 DOCX 格式，并自动插入到光标位置。三、详细报道1. 主要内容A. 功能特性全局热键操作：默认使用 Ctrl+Shift+B 一键粘贴，热键可自定义。智能表格识别：自动检测剪贴板内容是否为 Markdown 表格，若是则粘贴到 Excel 而非 Word。HTML 富文本支持：支持直接复制网页中的 AI 回复内容（HTML 格式），自动转换为 Word 格式。应用扩展工作流：可为特定应用（如语雀、Overleaf、QQ 等）配置不同的粘贴模式，支持按窗口标题匹配。转换增强功能：支持按转换类型配置 Pandoc Filters，自动修复部分 LaTeX 语法问题，自动转换单美元符号公式块为标准的双美元符号格式。多语言支持：界面支持简体中文、英语、日语。B. 技术架构PasteMD 基于以下核心技术构建：Python 开发：使用 Python 3.12+ 开发，采用 PyInstaller 打包为独立可执行文件。Pandoc 集成：通过 Pandoc 实现文档格式转换，支持 Markdown、HTML、LaTeX 等多种格式。剪贴板监听：实时监听系统剪贴板变化，自动识别内容类型。COM 自动化：通过 Windows COM 接口与 Office 应用交互，实现自动粘贴。graph LR A[用户复制内容] --> B[剪贴板] B --> C{PasteMD 监听} C -->|热键触发| D[内容类型识别] D -->|Markdown 表格| E[转换模式选择] D -->|普通 Markdown| E D -->|HTML 富文本| E E -->|Pandoc| F[生成 DOCX] F --> G{检测前台应用} G -->|Word/WPS| H[插入光标位置] G -->|Excel| I[粘贴表格数据] G -->|无应用| J[打开/保存/剪贴板]C. AI 网站兼容性PasteMD 对主流 AI 对话网站进行了兼容性测试：完美支持（所有格式）：DeepSeek、豆包、智谱清言/ChatGLM、Gemini、Grok、Claude基本支持（公式显示为代码）：ChatGPT（复制含公式的 Markdown 时）部分限制（网页含公式无法显示）：Kimi、通义千问2. 技术细节A. 配置文件首次运行时，PasteMD 会在用户数据目录生成 config.json 配置文件：Windows：APPDATA%\PasteMD\config.jsonmacOS：~/Library/Application Support/PasteMD/config.jsonB. 核心配置项热键配置：hotkey 字段，支持自定义全局热键，语法如 ++b。Pandoc 路径：pandoc_path 字段，指定 Pandoc 可执行文件位置。Excel 功能：enable_excel 控制是否启用智能表格识别，excel_keep_format 控制是否保留格式。转换增强：enable_latex_replacements 自动修复 LaTeX 语法，fix_single_dollar_block 转换单美元符号公式。应用扩展：extensible_workflows 配置不同应用的粘贴模式。C. 高级功能Pandoc Filters：支持配置自定义 Lua 脚本或可执行文件作为 Filter，扩展 Pandoc 转换能力。典型应用包括使用 mermaid-filter 支持 Mermaid 图表渲染。graph TD A[原始 Markdown] --> B[Pandoc Filter 1] B --> C[Pandoc Filter 2] C --> D[Pandoc Filter N] D --> E[DOCX 输出] B -.示例.-> F[mermaid-filter] F --> G[渲染 Mermaid 图表]3. 数据与事实A. 项目数据开发周期：持续开发中，已发布 12 个版本代码贡献者：6 人Fork 数量：260B. 技术栈后端语言：Python（95.1%）构建脚本：Shell（3.9%）打包工具：PyInstaller、Nuitka依赖库：pynput、keyboard、pyperclip 等四、影响分析1. 行业影响A. 提升写作效率PasteMD 解决了 AI 辅助写作中的格式转换痛点，使得用户可以更高效地将 AI 生成的内容整合到文档中，降低了格式调整的时间成本。B. 推动工具集成该项目展示了 AI 工具与传统办公软件深度集成的可能性，为类似效率工具的开发提供了参考。2. 用户影响A. 目标用户群体学术论文作者：需要频繁将 AI 生成的数学公式和表格插入 Word 的研究人员内容创作者：从 AI 获取素材并进行二次创作的自媒体作者企业办公人员：需要整理 AI 对话内容到文档的职场人士B. 使用门槛便携版需要用户自行安装 Pandoc，一体化安装包则自带 Pandoc，降低了普通用户的使用门槛。C. 迁移成本安装后即可使用，无需额外配置，热键操作符合用户直觉。3. 技术趋势A. AI 与办公软件融合PasteMD 反映了 AI 工具与传统办公软件深度融合的趋势，未来此类中间工具将有更大需求。B. 开源项目活力该项目在 GitHub 上获得近 4000 Stars，表明用户对这类实用工具的强烈需求，开源社区在解决实际生产力问题方面发挥着重要作用。五、各方反应1. 官方回应项目作者通过 GitHub Issues 与用户保持密切互动，持续修复问题并添加新功能。项目积极接受社区贡献，已有 6 名开发者参与代码贡献。2. 业内评价A. HelloGitHub 推荐PasteMD 被HelloGitHub 平台收录和推荐，作为实用工具项目向更广泛的用户群体推广。B. 社区反馈用户在 GitHub 上积极反馈使用体验，提出功能建议和 Bug 报告，形成了良好的社区氛围。3. 用户反馈A. 正面评价一键操作极大提升了写作效率，解决了长期存在的格式问题智能表格识别功能非常实用，自动判断粘贴到 Excel 还是 Word配置灵活，可适应不同使用场景B. 关注点部分 AI 网站（如 ChatGPT）复制含公式的 Markdown 时，公式仍显示为代码需要 Pandoc 依赖，对不熟悉技术工具的用户有一定门槛六、相关链接1. 项目地址GitHub 仓库：https://github.com/RICHQAQ/PasteMD项目官网：https://pastemd.richqaq.cn/2. 下载地址Releases 页面：https://github.com/RICHQAQ/PasteMD/releases3. 相关工具Pandoc 官网：https://pandoc.org/Python 官网：https://www.python.org/参考资料