博客

项目：aurelio-labs/semantic-router

Stars: 3,893 | License: MIT | 语言: Python | 版本: 0.1.2

Semantic Router 是一个超高速语义决策层，通过向量空间的语义相似度替代 LLM 推理来做出路由决策。其核心理念是：与其等待缓慢的 LLM 生成来决定调用哪个工具，不如用语义向量的余弦相似度在毫秒级完成决策。

1. 整体架构与模块划分

项目采用清晰的四层分层架构：

semantic_router/
├── route.py          # Route 模型定义
├── schema.py         # 核心数据结构（Message、SparseEmbedding、Metric、Utterance 等）
├── linear.py         # 底层向量相似度计算（纯 numpy）
├── routers/          # 路由器层（核心决策引擎）
│   ├── base.py       # BaseRouter — 所有路由器的基类
│   ├── semantic.py   # SemanticRouter — 纯密集向量路由
│   └── hybrid.py     # HybridRouter — 稠密+稀疏混合路由
├── encoders/         # 编码器层（22+ 种实现）
│   ├── base.py       # DenseEncoder / SparseEncoder 基类
│   ├── openai.py, cohere.py, huggingface.py, clip.py, vit.py ...
│   └── bm25.py, tfidf.py, fastembed.py ...
├── index/            # 索引存储层（向量数据库适配）
│   ├── base.py       # BaseIndex 接口
│   ├── local.py      # LocalIndex — 内存 numpy 索引
│   ├── hybrid_local.py # HybridLocalIndex — 混合本地索引
│   ├── pinecone.py   # PineconeIndex
│   ├── qdrant.py     # QdrantIndex
│   └── postgres.py   # PostgresIndex（pgvector）
├── llms/             # LLM 层（用于动态路由）
│   ├── base.py       # BaseLLM
│   ├── openai.py, cohere.py, llamacpp.py, mistral.py ...
│   └── openrouter.py, zure.py
└── utils/            # 工具函数
    ├── defaults.py   # 默认编码器配置
    ├── function_call.py # 函数调用工具
    └── logger.py     # 日志

这种分层设计的核心思想是策略模式：路由器（Router）是不变的决策框架，编码器（Encoder）、索引（Index）、LLM 是可替换的策略组件。

（更多…）

数据库里躺着 20 条价格记录，可”最便宜的3个””最新的一条””第2页翻出来看看”这些问题，数据库不会自动懂你。今天配齐查询的最后一块基础零件：ORDER BY 负责排队（谁前谁后），LIMIT 负责限量（只要前几名），俩人一搭档——排行榜、翻页浏览、”每个商品只看最新”全搞定。外加一个数据世界的经典暗坑：翻页时同一行出现两次，或者总有一行怎么都翻不到。

一、真实场景：排行榜、翻页，和”只看最新一条”

接着价格监控工具的故事讲。数据库上线之后，你发现自己问的问题悄悄变了——不再是”机械键盘现在多少钱”，而是这种：

1. 排行榜：”全部记录里最便宜的3条是哪些？”——等打折时你想盯的就是这些；
2. 追新：”每个商品各自最新的一条记录是什么？”——画价格走势图前得先拿到”当前价”；
3. 翻页：”20 条记录一页显示 5 条，第2页翻出来看看”——记录涨到 2000 条时，你不可能让程序把 2000 行全打印到屏幕上。

这三个需求，恰好就是今天两位主角的分工：

• ORDER BY：给查询结果排队——按价格从低到高、按时间从新到旧，规则你定；
• LIMIT（+OFFSET）：排队之后限量端上——只要前 3 条、一次只看一页。

先说个好消息：这两句 SQL 是整个 SQL 世界里最好学的部分之一，没有任何新概念，全是”在已有查询后面加半句”。再说个预警：它们有个非常隐蔽的坑，藏在”翻页”里——同值并列时，翻页会重复或漏行。第一次撞上的人几乎都以为程序闹鬼了。今天把疫苗也一起打了。

（更多…）

仓库: moltbot/moltbot (重定向至 openclaw/openclaw)

定位: 个人 AI 助手网关 — 跨平台、多通道、可扩展

主语言: TypeScript (91.5%) | 许可证: MIT

规模: 377K+ Stars, 370+ 贡献者, 200+ 发布版本

最后更新: 2026-06-08

1. 项目定位与核心理念

OpenClaw（原 Moltbot）是一个自托管的个人 AI 助手平台。其核心理念是”Your own personal AI assistant. Any OS. Any Platform.”——用户在自己的设备上运行 Gateway 控制面，通过已有的聊天通道（WhatsApp、Telegram、Slack、Discord、WeChat、Signal 等 20+ 平台）与 AI 交互。

与 ChatGPT/Claude 等 SaaS 产品不同，OpenClaw 强调 “own your data”——所有数据、会话、记忆都存储在用户自己的机器上。Gateway 只是控制面，产品本身就是助手体验。

关键设计决策：

（更多…）

上一篇让数据库学会了”答题”，今天给它配齐另一半本事：改错（UPDATE）和清理（DELETE）。价格录错了怎么改、测试垃圾怎么清，听起来都是小事——但一条没带 WHERE 的 DELETE，能让整张表瞬间清空。今天既学这两句 SQL，更学”给猛兽拴绳子”的安全流程。

一、真实场景：录错的 2990，和越堆越多的垃圾数据

接着价格监控工具的故事讲。数据库上线一个月，新问题来了，而且都是”改”出来的麻烦：

1. 录错了：10月25日查机械键盘，299 块的价，手滑多打一个 0，录成了 2990。2000 条记录里混着一条错数据，报表全被它搅黄——怎么改？
2. 堆垃圾：每次调试脚本都往表里塞几条测试数据，”测试商品””test123″越堆越多，查询结果里全是噪音——怎么清？

放在一个月前，这俩活儿是这样的：改 CSV 用 Excel 打开，小心翼翼改那一格，顺手把整列格式吃掉；删数据是”整行选中、右键删除、祈祷没删错行”。而数据库世界里，这两件事各只要一句 SQL：

• UPDATE：指名道姓地”把哪行的哪个值，改成什么”；
• DELETE：指名道姓地”把哪些行，请出去”。

注意我反复说”指名道姓”。这两句 SQL 和上一篇的 SELECT 共享同一个 WHERE——你会挑行，就等于会改行、删行。但反过来，它们也共享 SELECT 没有的风险：SELECT 写错条件，大不了查出来的东西不对；UPDATE、DELETE 写错条件（或者干脆忘了写），数据当场物理消失，没有 Ctrl+Z。所以今天的真正主菜不是语法，是”给猛兽拴绳子”的安全流程。先打个预防针，后面细说。

（更多…）

项目: BrainBlend-AI/Atomic Agents（现维护者 Eigenwise）

定位: 基于 Instructor + Pydantic 的模块化 AI Agent 框架

核心理念: 用软件工程原则构建 AI 应用——Schema 驱动、类型安全、组件可替换

分析日期: 2026-09-13

一、整体架构概览

Atomic Agents 采用“原子化”设计哲学——将 Agent 系统拆解为最小可组合单元。与 LangChain 等”重量级框架”不同，它不提供预构建的 Chain/Agent 模板，而是提供一组低层原语（primitives），开发者像搭乐高一样组合。

核心包结构：

atomic-agents/
├── atomic_agents/
│   ├── agents/          # AtomicAgent 核心类
│   ├── base/            # BaseIOSchema, BaseTool, BaseResource, BasePrompt
│   ├── connectors/      # 外部服务连接器
│   ├── context/         # ChatHistory, SystemPromptGenerator, ContextProvider
│   └── utils/           # Token 计数等工具
├── atomic-forge/        # 社区工具集合（非包，可单独下载）
└── atomic-examples/     # 示例项目集

二、核心设计模式：Schema-First（Schema 优先）

Atomic Agents 最显著的特征是所有交互都通过 Pydantic Schema 定义。这是整个框架的基石。

（更多…）

上一篇把2000条价格历史搬进了SQLite新家，今天开始享受”图书馆”的待遇：把”上周三到今天机械键盘降了几次价”这种人话，翻译成 SELECT … WHERE …，让数据库替你翻完2000条记录、只把答案端给你。查询是数据库的看家本领——从今天起，你问问题，程序答问题。

一、真实场景：2000条历史里，藏着你想知道的答案

接着价格监控工具的故事讲。第50篇你把 price_history.csv 里的2000多条记录搬进了 prices.db，房子建好了、东西归位了。现在老板（或者你自己）开始问问题了：

• “机械键盘现在什么价？”
• “哪些商品跌破过100块？”
• “10月20号那天，都查了哪些商品的价格？”

放在一个月前，这些问题意味着：打开CSV、拖动滚动条、肉眼扫描2000行，或者写一段Python循环逐行判断。而数据库的本职工作就是回答这种问题——你负责把问题说清楚（SELECT），它负责翻完整张表（哪怕20万条），把答案端上来。

今天的武器就两句SQL，但它们覆盖了你未来80%的查询需求：

（更多…）

协议全称: Agent2Agent (A2A) Protocol

版本: v1.0.0（2025年正式发布，Linux Foundation 托管）

GitHub: https://github.com/a2aproject/A2A （25.5k stars，2.6k forks，617 commits）

官网: https://a2a-protocol.org

许可证: Apache License 2.0

发起者: Google，由 Linux Foundation Agentic AI Foundation 管理

官方SDK: Python、Go、JS、Java、.NET、Rust（六语言全覆盖）

一、协议定位与设计哲学

A2A 是业界首个专门为 Agent 间对等通信 设计的开放协议。它解决的核心问题是：不同框架（LangGraph、CrewAI、ADK）、不同厂商、不同服务器上运行的 AI Agent，如何像”同事”一样协作，而非仅仅作为”工具”被调用。

A2A 的五大设计原则：

1. 简洁性（Simple）：复用既有标准——HTTP、JSON-RPC 2.0、Server-Sent Events（SSE），不发明新的传输层。
2. 企业就绪（Enterprise Ready）：认证、授权、安全、隐私、追踪、监控均对齐企业既有实践。
3. 异步优先（Async First）：原生支持长时间运行任务（LRO）和 human-in-the-loop 场景。
4. 模态无关（Modality Agnostic）：文本、音频、视频、表单、iframe、结构化 JSON 均可交换。
5. 不透明执行（Opaque Execution）：Agent 协作时无需暴露内部记忆、逻辑或工具实现——保护知识产权。

A2A 与 MCP 的本质区别：MCP 连接 LLM 与工具/数据源（纵向集成），A2A 连接 Agent 与 Agent（横向协同）。两者互补而非竞争——复杂 Agent 系统同时需要两者。

（更多…）

上一篇把”为什么要数据库”讲透了，今天正式动手：用Python自带的SQLite建一张表（CREATE TABLE）、把价格监控一个月的历史数据搬进去（INSERT）、再取出来看一眼（SELECT）。SQL的第一组动作，比你想象的好上手——因为你只是”把想干的事说清楚”。

一、真实场景：2000条价格历史，该搬新家了

接着第48、49篇的故事讲。你的价格监控工具勤勤恳恳跑了一个月，price_history.csv 里攒了2000多条价格记录。第49篇你已经用实验证明了：数据库查询比CSV快几十倍，而且不怕手滑删行、不怕价格被存成字符串。道理都懂了，今天干一件实实在在的事——给这批数据搬个新家。

搬家清单很简单，就三件事：

1. 建房子：在数据库里建一张 prices 表，规定好”每条价格记录长什么样”；
2. 搬东西：把CSV里的2000多条历史一条条搬进表里；
3. 验收：随便取几条出来看看，确认搬进去了、搬对了。

别小看这三件事。它们正好是SQL世界里最基础、最常用的三个动作——CREATE TABLE（建表）、INSERT（插入）、SELECT（查询）。今天主攻前两个，SELECT先学个”取出来看一眼”的最小用法（正餐在第51篇）。学完今天，你就正式跨进了”会用数据库”的门槛。

（更多…）

基于 modelcontextprotocol/python-sdk v2 源码分析，协议版本 2026-07-28

概述

MCP Python SDK 是 Model Context Protocol 的官方 Python 实现，当前为 v2 版本——一次重大的架构重写，既支持 2026-07-28 规范及所有早期版本，也修复了长期存在的架构问题。SDK 同时提供 Server 和 Client 两套完整能力，支持 stdio、Streamable HTTP、SSE 三种标准传输方式。

1. 分层架构：四层分离

SDK 采用清晰的四层分层设计，每层职责明确、边界严格：

┌─────────────────────────────────────────┐
│  FastMCP 层 (MCPServer)                 │  装饰器 API，开发者面向
├─────────────────────────────────────────┤
│  Lowlevel Server 层 (Server)            │  构造函数 handler 注册
├─────────────────────────────────────────┤
│  Dispatcher 层 (JSONRPCDispatcher)      │  请求-响应关联、并发调度
├─────────────────────────────────────────┤
│  Transport 层 (stdio / StreamableHTTP)  │  字节流 ↔ 消息流
└─────────────────────────────────────────┘

FastMCP 层（MCPServer）提供最高级抽象——@mcp.tool()、@mcp.resource()、@mcp.prompt() 装饰器，开发者只需写带类型注解的 Python 函数，SDK 自动推导 JSON Schema、处理参数校验和协议交互。15 行代码即可构建完整 MCP Server。

（更多…）

前面48篇，你把数据装进过变量、装进过文件、装进过CSV和Excel。今天开门迎接编程路上第三个新台阶——数据库。这一篇不急着写SQL，先把一个根本问题掰开揉碎：CSV用得好好的，为什么全世界的软件都在用数据库？想通了这个问题，后面11篇学起来才不迷路。

一、真实场景：一个被自己数据”噎住”的价格监控

接着第48篇的故事讲。你的价格监控工具勤勤恳恳跑了一个月，price_history.csv 从2行长到了2000多行，每天30分钟一轮，机械键盘和无线鼠标的价格历史一条不落。你很满意——直到某天你想问它几个问题：

1. “上周三到今天，机械键盘降了几次？”
2. “现在把无线鼠标的目标价从90改成120，顺便告诉我：按新目标价，历史里有几天是’该提醒我’的？”
3. “把两个商品按’每降价10元记一次’重新统计一份月报。”

用CSV做这三件事，你得：把2000行全部读进内存、写循环逐行比对字符串时间、自己处理”价格是字符串”的老坑（第48篇坑2）、按条件重新拼一份文件……三个问题写三段几乎重复的代码。更要命的是第四件事——

1. 你手滑用Excel打开了 price_history.csv，随手删了两行”看起来重复”的记录，保存。第二天监控工具追加新数据时，文件里混进了两种格式的行尾，csv.DictReader 直接读乱了。

这就是CSV的天花板：它只负责”存”，不负责”管”。数据一多、问题一复杂、或者多一只手来碰它，纯文件就开始散架。是时候请专业选手出场了。

（更多…）