MacOS on 小盒子的技术分享

OpenClaw 爆火背后：它不是聊天机器人，而是一套真正会做事的 AI 系统

Wed, 11 Mar 2026 10:14:30 +0000

如果你最近在 GitHub 上关注过 AI Agent 领域，大概率已经看到过 OpenClaw。到 2026 年 3 月 10 日，它的 GitHub 仓库已经来到约 297k stars，超过了 React 的约 244k 和 Linux 的约 222k。更重要的不是数字本身，而是它火起来的方式：它不是靠一个漂亮网页，也不是靠一个“会聊天的套壳”，而是靠一整套把大模型接入真实消息渠道、真实设备、真实浏览器、真实文件系统的系统架构，硬生生把“AI 助手”做成了一个长期在线的工程系统。

但如果你只把 OpenClaw 理解成“接了很多 IM 的机器人”，你会完全错过它最有价值的部分。OpenClaw 官方 README 写得很直白：“The Gateway is just the control plane — the product is the assistant.” 这句话几乎就是读懂整个项目的钥匙。它的重点从来不是“有多少入口”，而是：有没有一个统一控制面，把消息、状态、路由、模型、工具、节点、权限和安全边界收在一起。 README、架构文档和 Vision 文档都在强调同一件事：OpenClaw 想做的是“真正会做事的 AI”，运行在你的设备、你的渠道、你的规则之内。

这篇文章，我想尽量回答七个问题：

1.它到底是什么？

2.它为什么会采用现在这套架构？

3.Gateway 到底在系统里扮演什么角色？

4.Agent 是怎么运行起来的？

5.Memory、Workspace、Session 为什么是它的关键设计？

6.多 Agent、节点、工具体系是怎么拼到一起的？

7.以及最后，为什么它值得被看作下一代 AI 助手的典型系统样本。

在回答这些问题之前，我不得不说，现在龙虾有些过热了，对于想 “卖铲子” 的公司当然觉得这是好事，于是他们推波助澜，但对于专业人士不能人云亦云。openClaw 有它优秀的一面，也有被炒作夸大的一面，应该客观地看。

一、OpenClaw 的本质，不是聊天机器人，而是“个人 AI 助手控制面”

一句话定义 OpenClaw，我会这样说：

OpenClaw = 一个以 Gateway 为中心的个人 AI 助手控制平面，下面挂着嵌入式 agent runtime、会话系统、工具系统、消息渠道、节点设备和安全边界。

这个定义不是我自己拔高出来的，而是官方文档本身就在往这个方向写。

●README 说它是“你运行在自己设备上的 personal AI assistant”；

●架构文档说它是一个 single long-lived Gateway，拥有所有 messaging surfaces；

●Vision 文档则把它描述为“the AI that actually does things”，运行在你的设备、你的渠道、你的规则里。

把这些信息放在一起看，你会发现 OpenClaw 的设计起点根本不是一个“聊天 UI”，而是一个长期在线、可被多入口触发、可调用工具、可连接设备、可持续维护状态的 AI 系统。

这也是为什么我认为 OpenClaw 更接近“控制面”而不是“应用层”。在很多 AI 产品里，用户打开网页，输入问题，后端调一下模型，返回一段文本，交互就结束了。OpenClaw 则完全不是这种形态。它默认有一个长期运行的 Gateway 进程，消息渠道接到这个 Gateway，上层的 CLI、Control UI、WebChat 接这个 Gateway，macOS/iOS/Android/headless 节点也接这个 Gateway，甚至定时任务、exec approvals、pairing 和 health 事件都围绕 Gateway 展开。也就是说，Gateway 不是一个消息转发器，而是系统中枢。

二、Gateway 为什么是 OpenClaw 最关键的设计

OpenClaw 官方架构文档里最重要的一句话，是它把 Gateway 明确成 single control plane。一个长期运行的 Gateway 拥有所有 messaging surfaces；control-plane clients 通过 WebSocket 连进来；nodes 也通过 WebSocket 连进来，但会声明自己是 role: node；Canvas host 也由 Gateway 的 HTTP server 提供，而且默认和 Gateway 共用 127.0.0.1:18789 这个端口。

这意味着什么？意味着 OpenClaw 的系统设计不是“每个端各做一套逻辑”，而是“先做一个统一控制面，再让所有端接入它”。这在工程上有三个非常大的好处。

第一，状态是统一的。

会话在哪里维护？在 Gateway。

路由在哪里决策？在 Gateway。

设备配对、认证 token、事件广播、健康状态、cron、工具审批在哪里收敛？还是在 Gateway。

这让系统不会因为前端入口变多而出现多套状态、多个事实来源。

第二，协议是统一的。

Gateway protocol 文档明确写了：OpenClaw 不是“随便传一段 JSON”，而是有明确握手流程和版本约束的 WebSocket 协议。服务端先发 connect.challenge，客户端再带着 device identity、role、scopes、caps、auth、签名等参数发起 connect，通过后才返回 hello-ok。协议版本有 minProtocol/maxProtocol 协商，协议 schema 由 TypeBox 定义，再生成 JSON Schema 以及 Swift model。对一个跨 CLI、网页、桌面、移动端、节点设备的系统来说，这种 typed protocol 的价值非常高。

第三，能力是统一暴露的。

比如 Control UI 不是一个独立后端，而是 Gateway 在同一端口上提供的浏览器管理界面；WebChat 直接连 Gateway WebSocket；nodes 也不是第二套服务，而是带 role:node 的外围设备。也就是说，OpenClaw 并不是“一个 App + 一堆外挂”，而是“一个控制面 + 多个表面”。

很多人第一次看 OpenClaw，会把注意力放在“它居然支持这么多渠道”。但真正懂架构的人，会先看 Gateway。因为能不能把多个入口、多种设备、多条事件流、多种工具执行方式，全都压到一个长期运行的控制面里，决定了它到底是“一个功能”还是“一个系统”。OpenClaw 的做法很明确：先有控制面，再有助手。

三、它最强的抽象，不是对话框，而是 Agent、Session 和 Route

很多 AI 产品最基础的抽象单位是“聊天窗口”。OpenClaw 不是。

OpenClaw 的真正基础模型，是：

●谁来回复（Agent）

●回复落在哪段连续上下文里（Session）

●一条消息应该被路由到哪个 agent 和哪个 session（Route）

Agent：一颗完整隔离的大脑

Multi-Agent 文档里写得很清楚：一个 agent 是一个 fully scoped brain，拥有

●自己的 workspace

●自己的 agentDir

●自己的 auth profiles

●自己的 session store

它的文件、人格、配置、认证信息和会话历史都是围绕这个 agent 单独组织的。默认路径也很清晰：

●workspace 在 ~/.openclaw/workspace 或 workspace-<agentId>

●session 存在 ~/.openclaw/agents/<agentId>/sessions

●auth profile 在 ~/.openclaw/agents/<agentId>/agent/auth-profiles.json

这件事非常重要。因为这说明 OpenClaw 的多 Agent，不是“在一个上下文里换不同 system prompt 假装多人格”，而是真的把状态、身份、凭证和工作目录做成了隔离单元。但要注意，这种独立是为了让系统跑得更有条理，属于“防君子不防小人”的内部隔离。官方的意思很明确：同一个网关（Gateway）里的 Agent 默认都是“自己人”，不能把互不信任、甚至带有敌意的任务强行塞进同一个网关里，它并没有提供那种级别的安全防御。

Session：上下文连续性的主键

Session 文档里有一句特别关键的话：

OpenClaw treats one direct-chat session per agent as primary.

这句话可以理解成：对每一个 agent，OpenClaw 都认为它有一个“主私聊会话”

OpenClaw 默认会将一个 Agent 接收到的所有私聊（Direct Message, DM）都汇聚到一个主会话里（即 agent:<agentId>:<mainKey>）。对于群聊、频道或特定的话题（Thread），则会自动拆分独立处理。

对于 direct chat， agent 有一个规范意义上的主会话；默认所有 DM 都往这里归并，以保证连续性。

假设你有一个 agent 叫 main。默认情况下：

●你在 Web UI 私聊它一次

●之后又在 CLI 私聊它

●再后来在手机端私聊它

如果这些都被识别为 direct chat，而且你没有改 session.dmScope，那么这些私聊会折叠进同一个主 session,这样做的好处是：agent 会把这些私聊视为同一条连续对话，而不是三个彼此割裂的会话。

默认的主会话机制在单用户场景下很完美，但在多用户场景下就是一个巨大的安全漏洞。

如果 Alice 和 Bob 都去私聊同一个 Agent，在默认配置下，他们实际上是在向同一个“上下文沙箱”里写入数据。这就好比两个人共用一个日记本：

●Alice 刚和 Agent 聊完财务密码。

●Bob 接着去问 Agent“我们刚才聊了什么？”

●Agent 就会直接把 Alice 的密码复述给 Bob，造成严重的信息泄露。

为了应对多用户场景，OpenClaw 提供了 session.dmScope 配置，允许你在架构层面把私聊的上下文切分成更安全的细粒度：

●按发信人隔离（per-peer）。

●按频道+发信人隔离。(per-channel-peer)

●按账号+频道+发信人隔离(per-account-channel-peer)。

⚠️ 如果你在开发面向多用户的 AI Agent，绝对不能盲目使用默认的私聊配置。必须根据业务需求，通过调整 dmScope 将用户的对话状态彻底隔离开，防止你的 Agent 变成一个没有隐私边界的“大喇叭”。

Route：决定消息进入哪颗大脑

Channel Routing 文档把消息路由规则写得非常明确，一条消息发过来，绝对不是“哪个 Agent 闲着就扔给谁”，而是像网关（Gateway）匹配规则一样，必须严格按照优先级一层层往下筛，直到找到唯一确定的接收者。

我们可以用**“公司收发室分拣快递”**来打个比方，看一下这 5 层降级（Fallback）匹配规则：

1.精准单聊 (Exact peer match)：快递单上写着“直接交到张三本人手里”。

○明确的点对点直接交互，优先级最高。

2.跟帖/线程继承 (Parent peer match)：快递单没写名字，但备注了“这是昨天那个加急件的补充材料”。收发室一查昨天是李四负责的，直接给李四。

○识别 Thread 或上下文，让同一个 Agent 连贯处理同一个话题。

3.平台级群组与角色 (Discord guild+roles / Slack team)：快递写着“给财务部经理”或“给核心开发组”。

○根据外部平台（如 Discord/Slack）的特定权限组或大团队来分配对应的 Agent。

4.账号与频道 (Account / Channel)：快递写着“送到 3 楼会议室”或“交给官方客服号”。

○匹配特定的聊天频道或绑定的公共账号。

5.默认兜底 (Default agent)：啥也没写清楚的无主件，统统扔给“前台总机”处理。

○如果上面所有条件都未命中，最后由默认的 Agent 统一接管。

这意味着 OpenClaw 的“消息归属”不是模糊的。一条消息不是“谁在线谁回”，而是经过一套确定性规则，先判定该由哪个 agent 接管，再决定落到哪个 session 里。

所以 OpenClaw 能天然处理这些现实世界场景：

●同一个 Gateway 托管多个 agent；

●一个 Telegram 群给 work agent；

●一个 WhatsApp 家庭群给 family agent；

●一个 Slack team 给 support agent；

四、Agent 不是外挂调用，而是嵌入式运行时

很多人对 OpenClaw 最大的误解，是把它当成了一个简单的“任务调度员”——以为它只是在收到消息时，拉起一个外部的子进程（Subprocess）去跑一下，或者通过接口（RPC）远程调一下就完事了。

但架构文档明确指出：OpenClaw 是将 Agent 运行时“原生内嵌”到自己的网关里的。它不是把 Agent 当作一个不可控的外部黑盒，而是直接在内部实例化 Agent 的核心会话（AgentSession）。

Pi Integration Architecture 文档写得非常明确：OpenClaw 不是把 pi 作为 subprocess 或 RPC mode 的外部黑盒去调用，而是直接导入并实例化 pi 的 AgentSession，通过 createAgentSession() 把 agent runtime 嵌入到自己的消息网关架构里。

这种“深度内嵌”的架构设计，直接赋予了系统 6 大核心优势：

1.全局生命周期掌控：从对话的创建、挂起、恢复到销毁，网关层拥有绝对的控制权。

2.动态能力扩展：可以在运行时，随时把自定义的外部工具“塞”给 Agent 使用。

3.“看人下菜碟”的人设：能够根据消息来源（不同的平台渠道或上下文），动态切换 Agent 的系统提示词。

4.强悍的记忆管理：不仅能持久化保存对话，还支持高级的“记忆压缩（Compaction）”防止上下文爆满，甚至支持像 Git 一样对对话“开分支（Branching）”。

5.智能凭证轮询：在多个账号或 API Key 之间自动无缝切换，轻松应对并发和限流问题。

6.模型厂商解绑：底层的大模型想换就换，完全不受单一服务商（如 OpenAI、Anthropic）的绑架。

简单来说，OpenClaw 走的是“直接收编”的路线，它把 Agent 的核心大脑直接“拔”过来，原生种植在了自己的神经中枢里。这就好比你不再是打电话咨询外部专家，而是直接把这位专家招进了自家的核心指挥部。正因为“人”彻底成了内部员工，你才能拥有上帝视角般的掌控力：你可以全面接管他的作息安排（会话生命周期），随时往他手里塞各种定制兵器（动态注入工具），根据不同场合要求他扮演不同的角色（按渠道切换提示词），像操作代码仓库一样去整理甚至分叉他的记忆（支持压缩与分支的持久化），甚至连他背后的“脑力供应商”（随时无缝切换各家大模型）和权限账号，都能在底层悄无声息地替他自动轮换。说白了，OpenClaw 不是在和 Agent “跨部门合作”，而是直接把 Agent 融为了自己身体的一部分。换句话说，OpenClaw 不是“在用一个 agent”，而是“在拥有一个 agent runtime，并把它纳入自己的控制面”。这也是它跟很多“外接 Agent SDK 的应用层产品”最大的差别之一。别人只是调用，OpenClaw 是接管。

五、Agent Loop：一条消息的"真实旅程"

前面我们讲了 Gateway 如何把消息路由到正确的 Agent。现在让我们跟随一条消息，看看它进入 OpenClaw 后，到底经历了什么。

不是"一次请求"，而是一个完整生命周期

如果你习惯了网页聊天框的"发消息→等回复"模式，OpenClaw 的处理方式会让你有点意外。

传统模式：

⚡ 代码片段用户发消息 → 后端调用模型 → 返回文本 → 结束

OpenClaw 模式：

⚡ 代码片段用户发消息 → 分配 runId → 解析 session → 装配上下文 → 运行 agent → 流式返回事件 → 持久化 session → 结束

这一条链路，实际上就是你给 OpenClaw 发一句话之后，系统内部真实发生的事情。它不是“一次 HTTP 请求”，而是一个完整的运行生命周期。

OpenClaw 把你的消息视为一个进程而非请求。它会给这个进程分配ID、监控生命周期、管理并发、持久化状态。

并发控制：为什么同一聊天窗口的消息要"排队"？

想象一下这个场景：你在 Telegram 连续发了三条消息：

●“帮我查一下明天天气”

●“顺便看看日程”

●“把第一封邮件标为已读”

如果这三条消息并发执行，会发生什么？

●Agent 可能先处理了邮件，再处理天气

●Session 历史会乱序写入

●工具调用可能互相冲突

OpenClaw 的解决方案很简单：每个 session 串行化执行。这不是性能问题，而是状态一致性问题。长期在线的助手，必须保证"记忆"不会被乱序操作搞乱。是防止工具竞争和状态污染的工程必要选择。

流式事件：你看到的不是"打字动画"，而是真实的工作过程

OpenClaw 的流式输出，不是简单的"逐字显示"，而是三种事件流：

为什么要这样设计？因为这让用户能真正"看到 AI 在工作"。不是动画，不是假进度条，而是系统内部真实发生的事件被推送到前端。它的体验更像一个"正在办公的助手"而非"死寂的输入框"

六、真正让它“像一个人”的，不是模型，而是 Workspace、System Prompt 和 Memory

很多人体验 OpenClaw 后会有一种明显感觉：它比普通网页聊天更像一个“持续存在的助手”。这种感觉，核心不是来自模型，而是来自它对工作区、提示词和记忆的系统化设计

Workspace：AI 的家，而不是一个临时目录

简单说，Workspace 就是 AI 的"家"：

●它有固定的位置（~/.openclaw/workspace/）

●它有固定的文件结构

●它是 AI 长期工作的地方，不是临时落脚点

OpenClaw 在 Workspace 里约定了一整套"说明书文件"：

这个设计特别妙。因为它把很多系统会偷偷塞进 prompt 模板或数据库里的东西，变成了用户可见、可读、可改、可备份的文件系统资产。你不是在“配一个人设”，而是在维护一个 AI 的长期工作环境。

这里有一个非常重要的提醒：workspace 是默认工作目录，但不是硬沙箱（hard sandbox）；相对路径默认在 workspace 内解析，但绝对路径仍可能访问宿主机其它位置，除非你开启 sandbox。

System Prompt：每次运行都在"编译上下文"

OpenClaw 不是把用户的问题直接扔给模型，而是每次都重新构建一份完整的上下文：

1⚡ 代码片段System Prompt 结构：
2├── Tooling（可用工具列表）
3├── Safety（安全规则）
4├── Skills（技能列表）
5├── Workspace Context（工作区文件）
6├── Documentation（相关文档）
7├── Current Date & Time（当前时间）
8└── Runtime（运行环境信息）

Context 文档还补充了细节：默认会把 AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.md、BOOTSTRAP.md 等文件作为 Project Context 注入系统提示；技能本身只会注入“技能列表和描述”，真正的 SKILL.md 需要模型按需读取。

类比：

●传统聊天：像"临时起意打电话"

●OpenClaw：像"开会前先发会议议程和背景资料"

Memory：真正写到磁盘，才算记住

Memory 文档里我最喜欢的一句话是：

The files are the source of truth; the model only “remembers” what gets written to disk.

OpenClaw 默认的记忆结构非常简单，但非常工程化:

1⚡ 代码片段workspace/
2 ├── memory/
3 │ ├── 2026-03-10.md ← 今天的日志
4 │ ├── 2026-03-09.md ← 昨天的日志
5 │ └── ...
6 └── MEMORY.md ← 长期、精炼的永久记忆

两种记忆的区别：

检索机制：不是"只有文件"，也不是"只有向量"

OpenClaw 使用混合检索,它明确暴露了两个 agent-facing tools：

●memory_search 负责检索

●memory_get 负责精确读取某个 Markdown 文件或行段

1⚡ 代码片段用户问"我上次出差去哪了？"
2 ↓
3 BM25 关键词检索 ← 精确匹配"出差"
4 +
5 向量语义检索 ← 理解"去哪了"是问目的地
6 ↓
7 MMR 重排序 ← 去重、多样化
8 ↓
9 返回最相关的几条记忆片段

记忆刷新：在"遗忘"前先"存档"

OpenClaw 有一个很巧妙的设计：pre-compaction memory flush

当 session 接近上下文上限（比如对话太长，快塞不进模型窗口了），OpenClaw 会：

●触发一次"静默回合"（用户看不到）

●提醒模型：“把值得记住的信息写入记忆文件”

●然后再压缩上下文

七、工具体系：分层设计，不是堆砌功能

如果说 Gateway 是控制面，Session 是状态骨架，那么 Tools / Plugins / Skills 就是 OpenClaw 的执行肌肉。

OpenClaw 的工具体系有三个层次，很多人会混淆。让我们分清楚：

Tools：第一等公民

OpenClaw 暴露的是 first-class agent tools，不是外挂脚本。包括 browser、canvas、nodes、cron、gateway、session 相关工具、agents_list、image、pdf、message、exec 等。

OpenClaw 没有把“能力调用”做成 prompt 技巧，而是做成了运行时契约。Tool list 和 tool schema 会进入模型上下文；tool allow/deny、tool profiles、per-agent 工具策略、provider-specific 工具策略和 sandbox 工具策略共同决定模型实际能拿到哪些工具

Plugins：扩展系统本身

插件是运行在 Gateway 内部的代码模块，可以：

●注册新的 RPC 方法

●添加新的 HTTP 路由

●注册新的工具

●启动后台服务

类比：

●Skills：像"使用说明书"

●Tools：像"内置功能"

●Plugins：像"给系统装新器官"

Skills：教 AI 如何做事

每个 Skill 就是一个目录，核心是 SKILL.md——一份详细的操作指南。Skill 的三个来源（优先级从高到低）：

●<workspace>/skills/：当前工作区专属

●~/.openclaw/skills/：用户私有技能

●Bundled skills：系统内置技能

与Plugins的本质区别:Plugins是给手机增加新硬件（如外接摄像头）；Skills是相机APP里的"夜景模式"说明书。

八、Node：让 AI “有手有眼”

OpenClaw 严格区分了两个概念：

为什么这样设计？

如果把它们混在一起：

●Telegram Bot 只能干 Telegram 允许的事

●WhatsApp Bot 只能干 WhatsApp 允许的事

每个渠道都要重新实现一遍"控制电脑"的能力

OpenClaw 的设计：

●所有消息渠道都汇聚到 Gateway

●所有设备能力也汇聚到 Gateway

Gateway 负责调度：“这个 Telegram 消息需要控制 iPhone，我来协调”

Node 是什么？

node 是 companion device，可以是 macOS、iOS、Android 或 headless 设备；它通过和 operator 一样的 Gateway WebSocket 接入，但使用 role: “node”，向 Gateway 暴露一组命令面，比如 canvas.、camera.、device.、notifications.、system.*，再由 node.invoke 触发。官方还特别强调：nodes are peripherals, not gateways。消息还是落在 Gateway，不是落在 node

Node 是一台"伴侣设备"，它：

●通过 WebSocket 连接到 Gateway

●向 Gateway 暴露一组能力（camera、notifications、system…）

●等待 Gateway 的指令

类比：

●Gateway：大脑

●消息渠道：耳朵和嘴

●Node：手和脚

没有 Node 的话：

●Telegram Bot 无法直接控制你的 iPhone

●需要你自己手动截图,再发给 Bot

●AI 无法真正"替你做事"

有了 Node：

●AI 可以跨设备协同工作

●你在 Telegram 发指令,它在你的 Mac 上执行

●真正的"个人助手"体验

九、安全边界：诚实比承诺更重要

OpenClaw 的安全模型假设的是 one trusted operator boundary per gateway

OpenClaw 的安全文档非常诚实，这句话翻译成人话是：

这意味着：如果你把Gateway密码给朋友，让他也连进来，你们的对话历史、文件访问、记忆内容默认不隔离。这不是漏洞，是设计选择——为了简化架构，OpenClaw牺牲了多租户隔离，换取单用户场景下的极致能力。

安全层次

 1⚡ 代码片段外层：公网/外部消息源
 2 ↓
 3第一道门：Gateway 入口保护
 4 - token/password 认证
 5 - challenge 签名验证
 6 - device identity 校验
 7 - pairing 审批
 8 ↓
 9第二道门：权限控制
10 - operator / node 角色
11 - scopes 权限范围
12 ↓
13第三道门：执行保护
14 - tool policy（工具策略）
15 - exec approvals（执行审批）
16 - sandbox（沙箱隔离）
17 - allowlist（白名单）
18 ↓
19内层：高风险边界
20 - plugins = trusted code
21 - 插件和 Gateway 同等权限

Sandbox：可以隔离，也可以放行

OpenClaw 的沙箱设计非常灵活：

配置维度：

●mode：off / non-main / all（是否启用沙箱）

●scope：session / agent / shared（沙箱范围）

●workspaceAccess：none / ro / rw（工作区访问权限）

实际用法举例：

浏览器隔离：不是接管你的 Chrome

OpenClaw不会接管你的日常Chrome（那里面可能有银行登录态），而是拉起独立的Chrome Profile：

●独立的Cookie、缓存、扩展

●Agent专用，与你的个人浏览数据隔离

●支持截图、点击、PDF生成，但无法访问你个人的浏览器历史

这是"能力"与"安全"的折中：AI需要浏览器自动化，但不能拥有你的全部数字生活。

十、为什么这是"个人AI操作系统"的雏形？

OpenClaw 之所以值得研究，不是因为它 GitHub stars 多，而是因为它回答了一个未来会越来越重要的问题：

如果 AI 不再是网页对话框，而是一个长期在线、能操作设备、能记住一切的助手，它的系统架构应该长什么样？

OpenClaw 的答案是：

这套答案不一定是终局，也还远没到“完美”。Vision 文档自己都说，项目还很早，当前重点依然是 security、safe defaults、bug fixes、stability 和 setup reliability。也就是说，它依然在快速迭代，仍然带着实验性。

但它已经足够有代表性。因为它第一次比较完整地把“个人 AI 助手”这件事，从概念拉成了系统工程：

●消息不再只是消息，而是事件入口；

●模型不再只是回答器，而是运行时里的推理核心；

●工具不再只是 function calling 演示，而是被策略、审批和沙箱约束的系统调用；

●记忆不再只是“模型好像记得”，而是落到磁盘、可检索、可审计、可 Git 备份的工作区资产

它具备了"操作系统"的味道

不是说它替代 Windows 或 macOS，而是说它有那种系统级的感觉：

1⚡ 代码片段传统应用：打开 → 用 → 关闭
2操作系统：开机 → 长期运行 → 管理所有应用 → 关机
3
4传统 AI：聊天 → 结束
5OpenClaw：启动 Gateway → 长期在线 → 管理所有 Agent → 关闭

最后，再强调一次：OpenClaw 的本质，不是一个接了很多渠道的聊天 Bot，而是一套以 Gateway 为控制面、以 Agent/Session/Memory 为状态骨架、以工具与节点为执行面，把大模型真正接入现实世界的个人 AI 助手系统。

如何在 mac 的 chrome 中开启 gemini 侧边栏

Sat, 31 Jan 2026 02:03:30 +0000

昨天折腾了半天，厕所都没上，没搞定，今天一分钟搞定了，其实非常简单。

前提条件什么的自不用说，主要是两步，我是 mac 系统，windows 的不知道。

第一步

把语言设置一下，注意是在操作系统中设置chrome 的自定义语言

第二步

打开终端，输入以后命令后回车

⚡ 代码片段open -n -a "Google Chrome" --args --variations-override-country=us

也可以用这个项目设置一下：https://github.com/lcandy2/enable-chrome-ai

然后重启 chrome 就可以了，location 如果不支持，你应该知道怎么办吧，哈哈。

Kimi K2.5 模型接入 Claude Code 完全指南

Wed, 28 Jan 2026 08:20:02 +0000

Kimi K2.5 模型接入 Claude Code 完全指南

Claude Code 是 Anthropic 推出的官方命令行工具，让开发者能够在终端中与 Claude AI 进行交互式编程。通过简单的环境变量配置，你可以将 Claude Code 的后端从默认的 Claude 模型切换到 Kimi K2.5 模型，享受更强大的中文理解和代码生成能力。

本文将详细介绍如何在 macOS、Linux 和 Windows 系统上完成配置，让你能够快速开始使用 Kimi K2.5 驱动 Claude Code。

准备工作

在开始配置之前，请确保你已经完成以下准备工作：

1.安装 Claude Code：如果尚未安装，请参考 Anthropic 官方文档进行安装

2.获取 Kimi API Key：前往 Kimi 开放平台注册账号并获取 API Key

3.确认终端环境：确保你使用的是 bash、zsh 或 PowerShell 等常见 shell

核心配置项

将 Kimi K2.5 接入 Claude Code 需要配置三个关键环境变量：

环境变量	说明	值
`ANTHROPIC_BASE_URL`	API 基础地址	`https://api.kimi.com/coding/`
`ANTHROPIC_API_KEY`	你的 Kimi API 密钥	`sk-kimi-xxxxxxxx`
`ANTHROPIC_MODEL`	使用的模型名称	`kimi-for-coding`

macOS / Linux 配置方法

方法一：临时配置（当前终端会话）

如果你只想在当前终端会话中使用 Kimi K2.5，可以直接执行以下命令：

1⚡ bash片段export ANTHROPIC_BASE_URL=https://api.kimi.com/coding/
2export ANTHROPIC_API_KEY=sk-kimi-*************************
3export ANTHROPIC_MODEL=kimi-for-coding

配置完成后，启动 Claude Code：

⚡ bash片段claude

注意：这种方式只在当前终端窗口有效，关闭窗口后配置会失效。

方法二：永久配置（推荐）

为了让配置在每次打开终端时自动生效，你需要将环境变量添加到 shell 配置文件中。

1. 确定你的 shell 类型

⚡ bash片段echo $SHELL

●如果输出 /bin/zsh，使用 ~/.zshrc

●如果输出 /bin/bash，使用 ~/.bashrc 或 ~/.bash_profile

2. 编辑配置文件

使用你喜欢的编辑器打开配置文件：

1⚡ bash片段# 对于 zsh 用户
2nano ~/.zshrc
3
4# 对于 bash 用户
5nano ~/.bashrc

3. 添加环境变量

在文件末尾添加以下内容：

1⚡ bash片段# Kimi K2.5 for Claude Code
2export ANTHROPIC_BASE_URL=https://api.kimi.com/coding/
3export ANTHROPIC_API_KEY=sk-kimi-**********************************
4export ANTHROPIC_MODEL=kimi-for-coding

4. 保存并生效

保存文件后，运行以下命令使配置生效：

1⚡ bash片段# 对于 zsh 用户
2source ~/.zshrc
3
4# 对于 bash 用户
5source ~/.bashrc

5. 验证配置

⚡ bash片段echo $ANTHROPIC_MODEL

如果输出 kimi-for-coding，说明配置成功。

Windows 配置方法

方法一：PowerShell 临时配置

1⚡ powershell片段$env:ANTHROPIC_BASE_URL = "https://api.kimi.com/coding/"
2$env:ANTHROPIC_API_KEY = "sk-kimi-*************************"
3$env:ANTHROPIC_MODEL = "kimi-for-coding"

方法二：系统环境变量（永久配置）

1.按 Win + R，输入 sysdm.cpl 打开系统属性

2.点击高级 → 环境变量

3.在 用户变量 区域点击新建，添加以下三个变量：

变量名	变量值
`ANTHROPIC_BASE_URL`	`https://api.kimi.com/coding/`
`ANTHROPIC_API_KEY`	`sk-kimi-*********************`
`ANTHROPIC_MODEL`	`kimi-for-coding`

1.点击确定保存

2.重启终端使配置生效

方法三：PowerShell 配置文件

在 PowerShell 中执行：

1⚡ powershell片段# 创建配置文件（如果不存在）
2if (!(Test-Path $PROFILE)) {
3 New-Item -Path $PROFILE -Type File -Force
4}
5
6# 添加环境变量
7Add-Content $PROFILE "`n$env:ANTHROPIC_BASE_URL = 'https://api.kimi.com/coding/'"
8Add-Content $PROFILE "`n$env:ANTHROPIC_API_KEY = 'sk-kimi-*************************'"
9Add-Content $PROFILE "`n$env:ANTHROPIC_MODEL = 'kimi-for-coding'"

验证连接

配置完成后，启动 Claude Code 并验证是否成功连接到 Kimi K2.5：

⚡ bash片段claude

在 Claude Code 中，输入 /model 查看当前使用的模型：

如果返回的信息中包含 Kimi 或 kimi-for-coding，说明配置成功。

Gemini 3 介绍

Wed, 19 Nov 2025 13:22:13 +0000

Gemini应用每月用户超过6.5亿，超过70%的云服务客户在使用我们的人工智能，1300万开发者基于我们的生成式模型进行了开发，而这仅仅是我们所看到的影响的一小部分。 – Google CEO Sundar Pichai

每一代 Gemini 都在以往的基础上不断发展，让你能够做更多事情。

●Gemini 1 在原生多模态和长上下文窗口方面的突破，拓展了可处理信息的种类以及数量。

●Gemini 2为智能体能力奠定了基础，并在推理与思考方面突破了前沿，助力完成更复杂的任务和构想，使 Gemini 2.5 Pro在LMArena上占据榜首超过六个月。

今天，Google 终于憋出了大招，正式发布了 Gemini 3 系列。Google 这次明显是想通过 “Agentic（代理化）” 和 “Generative UI（生成式 UI）” 这两张牌，彻底改变我们开发和使用 AI 的方式。

一、核心模型：不再只是 “陪聊”，而是 “干活” 的

这次发布的重头戏有两个模型版本：

1.Gemini 3 Pro

○定位：这是新的主力模型，Google 称之为 “最智能的模型”。

○最大亮点 ——“Vibe Coding”：你不需要写精确的 prompt 或者伪代码，只需要用自然语言描述你想要的 “感觉（vibe）” 或功能，它就能生成全栈应用。比如 “做一个复古风格的太空射击游戏，障碍物要随着合成波音乐跳动”，它能直接给你生成带 UI 和交互的成品。

○能力提升：推理能力大幅增强，官方数据说在 LMArena 上 Elo 分数飙到了 1501（目前榜首）。

○适用场景：日常高频任务、代码生成、多模态理解（视频/图像/音频）。

2.Gemini 3 Deep Think

○定位：专门用来 “死磕” 难题的推理模型，仅面向 Google AI Ultra 订阅用户。

○对标对象：显然是 OpenAI 的 o1 / o3 系列。

○恐怖的数据：在 Humanity’s Last Exam（人类终极考试）这个测试集上，Gemini 3 Pro 得分 37.5%，而 Deep Think 版本能干到 41.0%（作为对比，上一代 Gemini 2.5 Pro 只有 21.6%）。这意味着在数学、科学研究等需要深度思考的领域，它的可靠性会有质的飞跃。

二、 AI IDE ：Google Antigravity (反重力)

Google 推出了一个全新的 Agentic IDE，叫 Google Antigravity

●这是什么？别把它想成 VS Code 的插件。这是一个独立的 IDE，专门为 “AI 代理开发” 设计的。

●核心逻辑变了：以前我们是用 Copilot 写代码（AI 辅助你），现在你是 “架构师”，你定义任务，Antigravity 里的 Agents（代理）去执行。

●它能干嘛？

○全自主干活：代理可以在编辑器写代码、在终端跑命令、在浏览器里预览调试，三者打通。

○Artifacts（产物）：代理不仅仅是吐代码，还会生成任务清单、实施计划、甚至截图，让你像验收工作一样去 Check 它的产出。

○模型任选：这一点很良心，除了 Gemini 3，它居然支持 Anthropic 的 Claude Sonnet 4.5 和 OpenAI 的 GPT - OSS。Google 这次格局打开了，意思是 “用最好的工具解决问题”。

这玩意儿就是冲着 Cursor 来的，而且试图在 “自主性” 上更进一步。建议大家赶紧去下个 Preview 版试试，特别是 Mac/Windows/Linux 都支持。

三、用户体验革命：Generative UI (生成式 UI)

Google 认为：“最好的 UI 是不需要设计的，是生成的。”

Google 认为，AI 的回答不应该只是一堆文字。Gemini 3 引入了 Generative UI（生成式用户界面）

●动态生成组件：当用户问 “帮我规划去罗马的旅行” 时，它不再只是列个文字清单，而是可能会直接生成一个 “交互式的行程卡片”，或者当你问房贷时，直接生成一个 “房贷计算器组件”。

●底层技术：依靠 Gemini 3 强大的代码生成能力，即时生成前端代码并在客户端渲染。

●Dynamic View：在 Gemini App 里，这被称为 “Dynamic View”。它能根据你的意图，现场 “手搓” 一个最适合当前场景的 UI 界面给你。

未来的 AI 应用，界面可能不再是写死的，而是 “流式生成” 的。

四、实战与性能 (Benchmarks)

如果不看跑分就不是科技圈了。简单列几个吓人的数据：

●LMArena Elo: 1501 (目前世界第一)。

●MathArena Apex: 23.4% (这是个新出的超难数学竞赛基准，其他模型基本是个位数，Claude 4.5 是 1.6%，GPT-5.1 是 1.0%… Gemini 3 这个分数有点断层领先的意思)。

●SWE-bench Verified (代码能力): 76.2%。虽然比 Claude 的 77.2% 略低一点点，但在 Antigravity 环境下的综合表现（Agentic coding）可能会更强。

●多模态: 视频理解 (Video-MMMU) 达到了 87.6%，以后扔给它一段长视频让它总结或者找细节，应该会非常准。

五、生态整合（这才是 Google 恐怖的地方）

Google 把 Gemini 3 塞进了所有角落：

●Search: 搜索里加了 “AI Mode”，而且支持 “Thinking” 开关。以后搜复杂问题（比如做攻略、查论文），搜索体验会完全不同。

●Android Studio: 安卓开发的同事注意了，Gemini 3 已经进驻，不仅是补全代码，还能帮你写 UI、查 Bug。

●Gemini CLI: 对于运维和后端同事，新的 CLI 允许你在终端里直接用自然语言让 Gemini 3 帮你执行复杂的 Shell 命令组合，甚至排查云端服务的 Log。

●Firebase: 推出了 “Firebase AI Logic”，后端逻辑也能由 AI 驱动了。

六、总结与建议

Gemini 3 无疑是一次 “能力的平权”

Gemini 3 不仅仅是 “更快更强”，它在尝试定义 AI 的下一阶段：

1.从 Chat 到 Agent: 不再是 “一问一答”，而是 “通过代理解决多步骤复杂任务”。

2.从 Text 到 UI: 输出形式从文本扩展到了动态界面。

给产研内部的建议：

●开发同学：务必尝试 Google Antigravity 和 Gemini CLI。如果它真能像宣传那样自主改 Bug、重构代码，我们的开发效率可能会有质变。

●产品同学：关注 Generative UI 的交互模式。我们的 AI 产品是否也可以不仅仅吐文字，而是根据用户需求动态生成交互组件？

●模型同学：重点关注 Deep Think 的推理模式，看看 Google 是如何通过增加推理时间（Test-time compute）来换取高质量输出的。

目前 Gemini 3 Pro 已经在 Gemini App 和 AI Studio 里能用了，Deep Think 还要等几周。大家可以先去玩玩 Pro 版的 “Vibe Coding”

Milvus 向量数据库快速入门

Sat, 31 May 2025 07:47:05 +0000

一、什么是 Milvus？

Milvus 是一款开源的向量数据库，用于存储、管理和检索高维向量数据。它适合构建各种 AI 场景下的向量检索系统，如推荐、图像搜索、问答系统等。

概念关系图（逻辑结构）

1Milvus数据库
2├── Collection集合
3│ ├── Partition分区
4│ │ └── Entity实体
5│ │ └── Fields字段（向量 + 元数据）
6│ ├── Schema结构
7│ └── Index索引
8├── 查询操作（Search / Query）
9└── 数据一致性机制

二、Milvus 核心概念速查表

实体 Entity 示例

1{
2 "id": 1,
3 "embedding": [0.1, 0.2, 0.3, ...],
4 "title": "iPhone",
5 "price": 999.0
6}

三、核心操作流程

四、一致性模型与数据安全保障

Milvus 提供以下一致性保证：

五、索引类型选择指南

六、进阶知识点补充

七、实战：使用 Python SDK 完整示例（基于 Milvus 2.x）

环境准备

1pip install pymilvus

初始化连接

1from pymilvus import connections
2connections.connect(alias="default", host="localhost", port="19530")

创建 Collection

1from pymilvus import FieldSchema, CollectionSchema, DataType, Collection
2fields = [
3 FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
4 FieldSchema(name="title", dtype=DataType.VARCHAR, max_length=200),
5 FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=128)
6]
7schema = CollectionSchema(fields, description="商品向量集合")
8collection = Collection(name="product_vectors", schema=schema)

插入数据

1import numpy as np
2titles = ["iPhone", "MacBook", "AirPods"]
3vectors = [np.random.rand(128).tolist() for _ in range(3)]
4collection.insert([titles, vectors])
5collection.flush()

创建索引 & 加载数据

1index_params = {
2 "index_type": "IVF_FLAT",
3 "metric_type": "L2",
4 "params": {"nlist": 128}
5}
6collection.create_index(field_name="embedding", index_params=index_params)
7collection.load()

向量搜索 + 条件过滤（Hybrid Search）

 1query_vector = [np.random.rand(128).tolist()]
 2search_params = {"metric_type": "L2", "params": {"nprobe": 10}}
 3results = collection.search(
 4 data=query_vector,
 5 anns_field="embedding",
 6 param=search_params,
 7 limit=5,
 8 expr="title like 'Mac%'"
 9)
10for hits in results:
11 for hit in hits:
12 print(f"id: {hit.id}, distance: {hit.distance}")

八、常见踩坑提醒

九、真实应用场景参考：电商推荐系统

十、快速上手建议

✅ 推荐

从创建 Collection 开始，理解字段与向量的对应关系
一步步插入数据、构建索引、执行搜索
多关注向量维度、索引类型和内存管理

❌ 避免

向量维度不统一
未加载数据就开始搜索

从初始化一个现代 python 项目中学习到的东西

Sun, 27 Apr 2025 06:57:05 +0000

uv

我准备用 uv 初始化一个 python 项目

环境

我用的是苹果笔记本 MacBookPro ，具体的操作系统及硬件参数如下：

uv 的介绍与安装

“

uv 是一个使用 Rust 编写的工具，可以用来替代 pip、pipenv、pipx、poetry、virtualenv 等工具的使用，甚至还可以用来管理系统中所安装的 Python 发行版。uv 借鉴了很多现代语言中对于项目依赖的管理方式，项目中对于依赖的管理要远远优于使用 pip 和requirements.txt的方式。

我之前用过 pip 、pipx 等工具，发现 uv 确实要快不少。具体有多快呢？ github 上有个图：

🚀速度比传统 pip 快 10-100倍。

根据官网的介绍，uv 主要支持以下功能：

支持版本锁定的项目依赖管理。
支持直接运行 Python 脚本。
支持对系统中安装的 Python 进行管理，支持多版本 Python 共存。
支持 Python 包的发布和安装。
支持兼容 pip 的应用接口。
支持 Cargo 模式的项目工作区管理。
更优化的全局支持库缓存。
运行无需 Rust 或者 Python 支持。
支持 Windows、macOS 和 Linux 系统

uv 对多 python 版本和环境的管理很不错，这样你就可以一个项目指定一个特定的 Python 版本，放心使用，想怎么折腾怎么折腾，不会影响全局。

最近比较火的 MCP 很多也是用 uv 运行的，因为用 uv 命令可以直接运行 python 脚本。

uv 的安装非常简单：

1# macOS和Linux
2curl -LsSf https://astral.sh/uv/install.sh | sh
3
4# Windows PowerShell
5powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

uv 对 Python 的环境管理

首先用 uv 管理一下我们本机安装的 Python 环境。即到底安装了几个、哪些版本的 python。

可以用 uv python list 查看，像这样：

可以看到我已经安装了多个版本的 python。在后面建项目的时候，我选用 3.13 这个版本。当然你也可以根据你的情况下载新的需要使用的版本。这里给出一组相关命令：

1uv python install，安装指定版本的 Python。
2uv python list，列出系统中当前已经安装的 Python 版本。
3uv python find，查找一个已经安装的 Python 版本。
4uv python pin，固定当前项目使用指定的 Python 版本。
5uv python uninstall，卸载指定版本的 Python。

比如我要安装 3.12 这个版本，我就可以这样：

1uv python install 3.13

装好了不想要了，就可以这样卸载掉它：

1uv python uninstall 3.13

uv 进行项目管理

python 的环境有了以后，我们就可以新建项目了，建项目的时候也要用 uv 来进行初始化。

“

uv 的项目管理功能更多的借鉴了 Rust 中 Cargo 工具的项目管理理念。但主要区别是 uv 是通过项目目录中的pyproject.toml文件来完成项目管理的。

1uv init myproject

初始化后会生成以下几个文件：

虽然 uv init myproject 会帮你创建项目目录和 pyproject.toml，但默认不会自动创建虚拟环境（env），所以我们需要手动创建。

1# 手动创建虚拟环境
2uv venv --python 3.13
3# 激活虚拟环境
4source .venv/bin/activate

虚拟环境激活后，项目中会多一个.venv 文件夹。

接下来我们要自己创建一下源码目录和测试目录：

1mkdir -p src tests

到这里工程的相关目录我们就先到此为止，基本上创建完了，然后我们来编辑

pyproject.toml 配置文件。

toml 配置文件

我们先介绍一下 toml 文件，可能有些朋友不怎么了解它，比如搞 java 开发的。

TOML（Tom’s Obvious, Minimal Language）是一种配置文件格式，设计目标是易读、易写、易于解析，非常适合作为程序的配置语言，尤其是在现代的跨平台开发中被广泛采用。

你看这名字是不是觉得肯定跟 Tom 大哥有关系？

对，因为 TOML 由 GitHub 联合创始人 Tom Preston-Werner 在 2013 年发起，用以替代 JSON、INI 等配置格式在可读性和灵活性上的不足。

不过吧，后来这大哥（和她媳妇）不在 GitHub 干了，因为他们的一些不光彩的行为。具体是什么就不多说了，想八卦一下的可以去查查。

toml 配置文件用途广泛，常用于以下场景：

应用程序运行时配置
包管理工具（如 Python 的 pyproject.toml、Rust 的 Cargo.toml）
构建工具配置（如 poetry.toml, uv.toml）
数据库或服务连接信息等环境参数配置

举个例子吧：

 1# 数据库配置
 2[database]
 3server = "192.168.1.1"
 4ports = [ 8001, 8001, 8002 ]
 5enabled = true
 6
 7# 应用信息
 8[app]
 9name = "MyApp"
10version = "1.0.0"
11release_date = 2025-04-25T12:00:00Z

TOML 的特点可以总结为：

“

“比 JSON 更适合人读，比 YAML 更适合程序解析。”

它已经成为现代软件开发中最流行的配置文件格式之一，特别是在需要 清晰结构 + 丰富类型 + 可维护性 的场景中表现出色。

常见语言的支持情况：

Python：tomli / toml / pytoml / tomllib（Python 3.11 原生支持）
Rust：官方包管理工具 Cargo 就使用 TOML 格式的 Cargo.toml
Go：支持 BurntSushi/toml 库
Node.js：支持 @iarna/toml 等多个库

常见用途：

Python 包管理：pyproject.toml（PEP 518 标准）
Rust 项目管理：Cargo.toml
Web 项目配置：netlify.toml
DevOps 工具：例如 uv 的配置也是用 toml 文件

TOML 与其他格式的对比：

特性	TOML	JSON	YAML	INI
可读性	✅ 高	中	中高（但复杂）	中
注释支持	✅ 支持	❌ 不支持	✅ 支持	✅ 支持
数据类型支持	✅ 多	✅ 多	✅ 多	❌ 有限
库支持	✅ 常见语言皆支持	✅ 全面	✅ 全面	✅ 较好
学习曲线	✅ 低	✅ 低	❌ 偏高	✅ 极低

你看，TOML 作为配置文件感觉很不错对吧。

我们关于 TOML 的介绍就到此为止，现在来说一下我们这个初始化的新项目中的 pyproject.toml 文件要写成什么样。

就这样：

 1[build-system]
 2requires = ["hatchling"]
 3build-backend = "hatchling.build"
 4
 5[project]
 6name = "myproject"
 7version = "0.1.0"
 8description = "一个基于Python 3.13.3的项目"
 9readme = "README.md"
10requires-python = ">=3.13"
11authors = [
12 {name = "xiaobox", email = "xiaobox@gmail.com"}
13]
14dependencies = [
15 "pytest>=7.4.3",
16 "fastapi>=0.110.0",
17 "uvicorn>=0.27.0",
18 "httpx>=0.27.0",
19]
20classifiers = [
21 "Programming Language :: Python :: 3.13",
22 "License :: OSI Approved :: MIT License",
23 "Operating System :: OS Independent",
24]
25
26[project.scripts]
27myproject = "src.main:main"
28
29[project.urls]
30"Homepage" = "https://github.com/yourusername/myproject"
31"Bug Tracker" = "https://github.com/yourusername/myproject/issues"
32
33[project.optional-dependencies]
34dev = [
35 "black>=23.1.0",
36 "isort>=5.12.0",
37 "mypy>=1.5.1",
38]
39
40[tool.pytest]
41testpaths = ["tests"]
42
43[tool.black]
44line-length = 88
45target-version = ["py313"]
46
47[tool.isort]
48profile = "black"
49line_length = 88
50
51[tool.hatch.build.targets.wheel]
52packages = ["src"]

别小看了这个文件，它可是一个使用了 Hatch 构建工具、遵循 PEP 621 和现代 Python 项目结构规范的项目配置，涵盖了运行依赖、开发依赖、CLI 脚本、格式化工具配置、测试路径和打包目标，非常完整规范。

所以我们得逐行解释一下这个重要的文件。

toml 配置文件的逐行解释

我们上面的配置文件是一个标准的 Python 项目使用 pyproject.toml 来管理构建系统、依赖、工具配置的典型示例。下面我们来拆解和解释一下。

✅ [build-system]：构建系统配置（PEP 517 标准）

1[build-system]
2requires = ["hatchling"]
3build-backend = "hatchling.build"

requires：构建该项目所需的构建工具，这里是 hatchling，必须先安装。
build-backend：指定用哪个构建后端来执行打包任务，这里是 hatchling.build。

hatchling 有点儿类似 java 中的 Maven 或 Gradle，都是用来执行自动化构建流程的。

Maven 是把 java 代码编译、构建成 jar 包，方便管理依赖、分发、版本控制
hatchling 是把 python 代码构建成 Wheel（.whl 文件）或 Source Distribution（.tar.gz 或 .zip 文件），也是为了做依赖管理、分发和版本控制。

总结来说：Python 的构建是将代码和依赖打包成 .whl 或 .tar.gz，类似于 Java 打包成 .jar。核心目的是简化分发、确保环境一致性、自动化依赖管理。

✅ [project]：项目的核心元信息（PEP 621 标准）

1[project]
2name = "myproject"

项目名称，最终发布到 PyPI 时会用这个名字。

1version = "0.1.0"

当前版本号。

1description = "一个基于Python 3.13.3的项目"

简短的项目说明。

1readme = "README.md"

指定项目的 README 文件，将作为 PyPI 上项目首页的介绍内容。

1requires-python = ">=3.13"

要求的 Python 版本最低为 3.13。

1authors = [
2 {name = "xiaobox", email = "xiaobox@gmail.com"}
3]

作者信息，支持多个，用列表表示。

1dependencies = [
2 "pytest>=7.4.3",
3 "fastapi>=0.110.0",
4 "uvicorn>=0.27.0",
5 "httpx>=0.27.0",
6]

项目的运行时依赖库，在安装时会自动安装这些包。这里我加入了 pytest、fastapi 的依赖，因为我想把这个项目作为一个 api 服务提供出去。

1classifiers = [
2 "Programming Language :: Python :: 3.13",
3 "License :: OSI Approved :: MIT License",
4 "Operating System :: OS Independent",
5]

用于 PyPI 分类（帮助搜索和筛选）。

✅ `[project.scripts]`：定义可执行命令（如 CLI）

1[project.scripts]
2myproject = "src.main:main"

安装后运行 myproject 命令会调用 src/main.py 中的 main() 函数。（我们需要提前把之前的 main.py 文件要先移动到 /src 目录下）

✅ `[project.urls]`：项目的相关链接（非必须）

1[project.urls]
2"Homepage" = "https://github.com/yourusername/myproject"
3"Bug Tracker" = "https://github.com/yourusername/myproject/issues"

为项目指定一些有用的链接，如主页、问题反馈页等。

✅ `[project.optional-dependencies]`：可选依赖（比如开发环境）

1[project.optional-dependencies]
2dev = [
3 "black>=23.1.0",
4 "isort>=5.12.0",
5 "mypy>=1.5.1",
6]

我们为开发环境安装了三个库：black、isort 和 mypy

介绍一下这三个工具

black：是一个 Python 代码格式化工具。自动把你的 Python 代码排版成统一风格，比如：缩进、换行、空格都按标准格式处理，让你的 Python 代码看起来更整齐、统一，无需自己动手排版。
isort：是一个 Python 导入（import）语句自动排序工具。自动整理文件顶部的 import 语句，比如按字母顺序排列，分组标准库、第三方库、自定义模块，保持导入部分有序且规范。
mypy：是一个 Python 静态类型检查工具。检查你的代码里的类型注解（type hints）是不是正确，比如函数参数和返回值类型对不对，帮你在写代码时发现类型出错的地方，提前避免 bug。

✅ `[tool.pytest]`：Pytest 配置

1[tool.pytest]
2testpaths = ["tests"]

指定测试用例所在路径，pytest 会从 tests/ 目录开始查找测试文件。

✅ `[tool.black]`：代码格式化工具 Black 的配置

1[tool.black]
2line-length = 88
3target-version = ["py313"]

设置代码的行最大长度为 88（默认值），目标 Python 版本是 3.13。

✅ `[tool.isort]`：import 排序工具 isort 的配置

1[tool.isort]
2profile = "black"
3line_length = 88

使用 black 的风格对 import 排序。
设置行长度为 88，与 black 保持一致。

✅ `[tool.hatch.build.targets.wheel]`：Hatchling 打包配置

1[tool.hatch.build.targets.wheel]
2packages = ["src"]

指定打包时要包含的代码目录为 src。

用一句话总结下这个 pyproject.toml 配置文件：

“这是一个使用 Hatch 构建工具、遵循 PEP 621 和现代 Python 项目结构规范的项目配置，涵盖了运行依赖、开发依赖、CLI 脚本、格式化工具配置、测试路径和打包目标，非常完整规范。”

安装和更新依赖

上面这个文件编辑完成后，我们就可以安装项目和开发依赖了：

1uv pip install -e ".[dev]"

如果后面你更新了 pyproject.toml 文件可以执行以下命令来 “手动刷新” 一个依赖库：

1uv sync --extra dev

加入 --extra dev 参数是因为 uv sync 默认只安装 [project.dependencies] 中列出的正式依赖。

不会自动安装 [project.optional-dependencies]（比如 dev 里面的 black、isort、mypy）

uv sync --extra dev 的意思是：除了正式依赖，还要把 [project.optional-dependencies.dev] 里的东西也同步上

uv.lock

当执行完 uv sync --extra dev ，安装好依赖好， uv 会在项目根路径生成一个 uv.lock 文件。uv.lock 是锁定依赖版本的文件。

它的作用是：把 pyproject.toml 里描述的依赖（比如 “fastapi>=0.110.0” 这样比较宽松的范围），具体锁定成明确、唯一的版本（比如 “fastapi==0.110.1”）。

这样，每次安装时，不管谁来安装（你自己、你的同事、你的服务器），大家安装的依赖版本都是一模一样的，不会因为小版本不同导致奇怪的 bug。

uv.lock 是自动生成、自动管理的。不需手动编辑。

其他

其他的，如 fastapi 相关的、打 docker 镜像部署什么的相对本文主题超纲了，就不在本文中过多描述了。

总结

本文我们分享了用 uv 初始化和管理 Python 项目的完整流程。

从安装 uv 开始，我介绍了它为什么比传统工具（pip、pipx、poetry 等）更快更好用，以及 uv 在多 Python 版本管理、依赖锁定、项目初始化方面带来的便利。

随后，详细讲了如何用 uv 管理本地 Python 环境、新建项目、创建虚拟环境、编辑 pyproject.toml 配置，并逐步解释了各个配置项的作用

整体来看，uv 提供了一套现代、规范、高效的 Python 项目管理方案，非常适合用来打基础，后续无论是开发 API、打包 Docker 镜像，还是部署上线，都能有条不紊地进行。

同时我们通过在项目创建的过程中看到各语言（java、nodejs…）都相通或类似的工程 “最佳实践”，真是应了那句话：“大道至简，真理趋同”

如何用 30秒和 5 行代码写个 RAG 应用？

Mon, 30 Sep 2024 16:17:06 +0000

花 30 秒用 5 行代码写个 RAG 应用

这个点子不是我想出来的，是 llamaindex 想出来的。llamaindex 是啥？

LlamaIndex 是一个框架，用于使用 llm（包括 agents 和 workflows）构建上下文增强的生成式人工智能应用程序。

当然也包括创建 RAG 应用，因为最流行的上下文增强示例就是 RAG（Retrieval-Augmented Generation， RAG），也就是在推理时将上下文与 llm 结合起来的检索增强。

如果是对 RAG 还不了解的朋友，那么可以参考之前几篇文章中的相关介绍：

RAG 实践-Ollama+AnythingLLM 搭建本地知识库

RAG（检索增强生成）系统的问题及解决思路

简单来说：RAG（Retrieval-Augmented Generation）是一种结合检索和生成技术的人工智能方法，通过从外部知识源检索相关信息，增强语言模型的生成能力，提高输出的准确性和相关性。

LlamaIndex

在进入正题前，关于 LlamaIndex 我还是要再多说几句。

LlamaIndex 是一个开源框架：https://github.com/run-llama/llama_index

它是用 Python 写的
最新版本是：0.11.14
官网地址是：https://www.llamaindex.ai/

在今年夏天的某个会议上，从 LlamaIndex 团队成员那儿得知，他们是一个规模很小的创业公司，当时团队成员大概 15 人左右。

30 秒 5 行代码

前文说了 30 秒 5 行代码的主意不是我想到的，而是来源于 LlamaIndex ，具体说是 LlamaIndex 的文档中写的：

事实也的确如此，但是，这里有一些前提条件。

首先，从字面上你也能看出来，运行这 5 行代码需要 OpenAI 的 API key。

其次，无论你懂不懂编程，我告诉你这 5 行代码是 Python 语言写的。那么你要有一个 Python 语言的运行环境，以及你最好懂得如何用 Python 编程。关于这一点，对于不懂编程的朋友确实不太友好了。不过值得庆幸的是，Python 语言本身很强大，很好上手，容易学习。门槛并不算太高。虽然我们要开发的应用是跟人工智能（AI）相关的，但也不要被吓到了，以为会多么难。其实有很大一部分所谓的 AI 产品也只是 AI、大模型的应用产品。开发那些产品的工程师甚至也只是能算是大模型应用开发工程师，还用不到多么艰深的技术呢。（这里并没有拉踩的意思，只是客观表述。能把技术应用的很好，做出满足用户需求的创新性产品也是非常有价值的，做出这样产品的人也当然值得尊重）

安装 Python

我们先解决 Python 的问题，对于已经熟练掌握 Python 开发的就可以跳过了。对于编程小白或其他语言开发者（如 Java）可以看看。

我们得搭建一个 Python 的开发和运行环境。关于 Python 的安装网上教程一大堆，无论你的操作系统是 Windows、Mac 还是 Linux 都很容易。我就不罗嗦了。

我的操作系统是 MacOS, 后文的具体操作细节都是基于我本地的 Mac 电脑，所以请大家注意，下图是我的的电脑系统情况：

Python 比较常见的大版本有 Python2 和 Python3 , 我使用的版本是 Python3，具体来说是 3.12.4 算是个比较新的版本了

关于 Python 的安装，我更建议用 Conda ，它可以创建多个不同 Python 版本的环境，相当于一个 Python 环境和版本管理工具。这样你就可以创建多个不同 Python 版本的环境，相互之间隔离，互不影响。因为有时候不同的项目用到不同的 Python 版本，混在一起比较麻烦，有了 Conda 就方便多了。

Conda 可以到这里下载安装：https://docs.anaconda.com/free/miniconda/

安装好以后记得设置一下镜像源，不然下载比较慢：

1conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/
2conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/
3conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud/conda-forge/
4conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud/pytorch/
5conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/pro/ 
6conda config --set show_channel_urls yes

以下是一些基础命令：

 1//创建虚拟环境
 2conda create -n xinference python=3.11.0
 3
 4//激活虚拟环境
 5conda activate xinference
 6
 7//退出虚拟环境
 8conda deactivate
 9
10//删除虚拟环境
11conda remove -n xinference --all
12
13//查看虚拟环境
14conda env list

Python 安装好以后，我们还需要一个开发工具，即 IDE，你可以选择 VSCode,PyCharm,Cursor,Zed 等等。这里我推荐 Cursor，因为借用 claude 及 gpt 等大模型的能力，你可以一边快速开发一边快速学习，高效产出的同时高效吸收，简直太爽啦。

学习 Python

关于 Python 的学习，我这里对于特别小白的，尤其是从来没有接触过编程的朋友没有什么具体的建议，因为我从未指导过类似情况的朋友，所以没有经验，不能乱说，怕误人子弟。因为我既不知道用什么样的方式也不知道用什么样的资料指导有用。不过我觉得对于小白，能持续学习下去是最重要的，不要找太难的资料，可以找一些你容易上手，容易看懂的资料来学习，有持续的正反馈，计算机相关的知识很多，有些确实难懂，有持续的正反馈你才不至于半途而废。

而对于其他语言的开发者，其实已经具备了基础的计算机知识，甚至也已经是某些编程语言的专家了。那么学习 Python 对于你来说就比较容易了，一理通百理明。都大差不差的。

我这里把之前收藏的一些学习资料分享一下：

认认真真把其中一个资料看完。一般来说，用 2 个星期，每天 1-2 个小时左右，快的话甚至一个星期你就能基本掌握这门语言了。

我知道很多朋友不满足只是基本掌握，想更精进，那么就需要再加码了，这里我推荐系统地看一些书，因为书籍会相对系统地讲解知识，这样你对 Python 以及 Python 相关的技术就会有一个全面而深入的了解了。

说实话我看的书并不多，也不好意思过多推荐，这里推荐一本我最喜欢的，豆瓣 9.1 分。

写得确实很好，很实用，不讲虚的。读起来也很流畅、舒服。是市面上难得的原创 Python 进阶图书。

编程

现在我们假设你已经有了一个 Python 的运行环境及开发工具。那么接下来我们就要正式开始编写这 5 行代码了（铺垫这么多终于要写代码了～）

首先我们要建一个工程，这很简单，不多说。

然后根据文档所示，我们要安装 llama-index 的依赖包，在项目根路径下执行

1pip install llama-index

当然，如果你使用的是 Python3 ，可以这样安装：

1pip3 install llama-index

安装好依赖包以后我们创建 main.py 文件，并编写程序：

1from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
2
3documents = SimpleDirectoryReader("data").load_data()
4index = VectorStoreIndex.from_documents(documents)
5query_engine = index.as_query_engine()
6response = query_engine.query("Some question about the data should go here")
7print(response)

别看这段只有几行代码，却有好几个问题，我们一个一个地说。

第一个问题是：如果你直接运行 main.py 这个文件会报错，错误总结来说就是你没有 OpenAI 的 Api Key 。是啊，我们压根就没有设置，其实我也不想设置，因为这个 key 是要花钱的，我不想花钱，那怎么办？

用 OPENAI_API_KEY 的目的就是要通过 OpenAI 的 API 调用 OpenAI 的大语言模型。我们知道那是收费的，所以我们要用开源免费的模型，将模型安装到本地使用，这样就不用花钱了。所以我们要用 Ollama 安装开源模型到本地进行调用。关于 Ollama 以及模型的安装我在之前的文章中有详细说明，这里就不赘述了。大家可以参考。RAG 实践-Ollama+AnythingLLM 搭建本地知识库

我这里下载使用的是 Qwen2:7b 的模型

第二个问题是：代码中的 data 在哪里

1documents = SimpleDirectoryReader("data").load_data()

data 是一个文件夹，需要我们在项目的根路径下创建，名字就叫 data。而在 data 文件夹中我们是要下载测试文本的，通过这个地址下载测试文本：

https://raw.githubusercontent.com/run-llama/llama_index/main/docs/docs/examples/data/paul_graham/paul_graham_essay.txt

文件类型当然就是 .txt 文件。原文是英文的，但因为我想做中文的测试，所以，我把内容全部翻译成了中文并保存。（如果你看过《黑客与画家》这本书，你一定会对文本内容感兴趣的！）这个文件的文件名你可以随意取。

第三个问题是：用哪个 embedding 模型？

前面我们说了，我们不用 OpenAI 的 API 了，这样的话，其实整个代码结构会发生变化，就不是原始的那 5 行代码了，而会变成下面这样（别担心，只多了一行）

 1from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
 2from llama_index.embeddings.huggingface import HuggingFaceEmbedding
 3from llama_index.llms.ollama import Ollama
 4
 5documents = SimpleDirectoryReader("data").load_data()
 6
 7# bge-base embedding model
 8Settings.embed_model = HuggingFaceEmbedding(model_name="BAAI/bge-base-en-v1.5")
 9
10# ollama
11Settings.llm = Ollama(model="llama3", request_timeout=360.0)
12
13index = VectorStoreIndex.from_documents(documents,)

可以看到代码中写的 embedding 模型是 BAAI/bge-base-en-v1.5

接触过 RAG 的朋友对 embedding 模型比较熟悉，这里简单地为不了解的朋友解释一下：

Embedding 模型是将离散的输入（如单词或文档）转换为连续向量表示的模型，在 RAG 中用于将查询和检索到的文档片段映射到同一向量空间，以便计算相似度和生成相关响应。

它和 RAG 的关系，可以参考下图：

我们这 5 行代码想实现的就是 RAG，所以一定少不了 embedding 模型。embedding 模型也分收费的和开源免费的，另外上文中提到的 BAAI/bge-base-en-v1.5 是一个处理英文的模型，我想处理的是中文，所以不适用。我们要找一个免费开源且支持中文的 embedding 模型。到哪里找呢？Hugging Face!（Hugging Face 你可以把它理解成大模型领域的 GitHub）

从 Hugging Face 上可以找到大量的开源免费的 embedding 模型，数量很多，选哪一个呢？我们可以从 https://huggingface.co/spaces/mteb/leaderboard 这个大规模文本嵌入基准（MTEB）排行榜中，根据你的需求来挑选。

比如我选择的是支持中文的，模型大小不是特别大的

最终我选择的模型是：BAAI/bge-base-zh-v1.5

以上三个问题都解决了以后，我们看一下最终的代码成品：

 1from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
 2from llama_index.embeddings.huggingface import HuggingFaceEmbedding
 3from llama_index.llms.ollama import Ollama
 4
 5documents = SimpleDirectoryReader("data").load_data()
 6
 7Settings.embed_model = HuggingFaceEmbedding(model_name="BAAI/bge-base-zh-v1.5")
 8
 9Settings.llm = Ollama(model="qwen2:7b", request_timeout=360.0)
10index = VectorStoreIndex.from_documents(documents,)
11query_engine = index.as_query_engine()
12response = query_engine.query("作者学习过的编程语言有哪些？")
13print(response)

实话实说，是比 5 行多了 2 行。但也已经很精练了，因为这是 LlamaIndex 做过高级别封装以后的 API，如果想做具体而细致的编程控制，可以使用低级别封装的 API。

代码我没有写注释，因为是想让读者看看它有多精练。用 LlamaIndex 就这么简单，几行代码就可以实现 RAG 了。

以下是我加入注释以后的，方便你理解它：

 1from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
 2from llama_index.embeddings.huggingface import HuggingFaceEmbedding
 3from llama_index.llms.ollama import Ollama
 4
 5# 从指定目录加载文档数据
 6documents = SimpleDirectoryReader("data").load_data()
 7
 8# 设置嵌入模型，使用北京智源人工智能研究院的中文嵌入模型
 9Settings.embed_model = HuggingFaceEmbedding(model_name="BAAI/bge-base-zh-v1.5")
10
11# 设置语言模型，使用 Ollama 提供的 Qwen2 7B 模型，并设置请求超时时间
12Settings.llm = Ollama(model="qwen2:7b", request_timeout=360.0)
13
14# 使用加载的文档创建向量存储索引
15index = VectorStoreIndex.from_documents(documents)
16
17# 从索引创建查询引擎
18query_engine = index.as_query_engine()
19
20# 使用查询引擎执行特定查询
21response = query_engine.query("作者学习过的编程语言有哪些？")
22
23# 打印查询结果
24print(response)

运行这段代码会自动下载 embedding 模型，你可能会关心模型下载到哪里了，在我电脑上是这个路径：～/Library/Caches/llama_index

代码第一次执行时间比较长，大概有个几十秒。

但再次执行应该是有缓存了，就会比较快了，下图就只执行了 10 秒左右。

当然，你还可以基于测试文本进行其他查询，看看它分析的是否准确。

以上图片中的输出每一步都有时间，是因为我对程序做了重构，用装饰器加上了每一步执行时间的打印输出，代码如下：

 1import time
 2from functools import wraps
 3from typing import Callable, Any
 4from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings, Document
 5from llama_index.embeddings.huggingface import HuggingFaceEmbedding
 6from llama_index.llms.ollama import Ollama
 7
 8def time_it(func: Callable[..., Any]) -> Callable[..., Any]:
 9 @wraps(func)
10 def wrapper(*args: Any, **kwargs: Any) -> Any:
11 start_time = time.time()
12 result = func(*args, **kwargs)
13 end_time = time.time()
14 print(f"{func.__name__} 耗时：{end_time - start_time:.2f} 秒")
15 return result
16 return wrapper
17
18class IndexBuilder:
19 @time_it
20 def load_documents(self) -> list[Document]:
21 return SimpleDirectoryReader("data").load_data()
22
23 @time_it
24 def set_embed_model(self) -> None:
25 Settings.embed_model = HuggingFaceEmbedding(model_name="BAAI/bge-base-zh-v1.5")
26
27 @time_it
28 def set_llm_model(self) -> None:
29 Settings.llm = Ollama(model="qwen2:7b", request_timeout=360.0)
30
31 @time_it
32 def create_index(self, documents: list[Document]) -> VectorStoreIndex:
33 return VectorStoreIndex.from_documents(documents)
34
35 @time_it
36 def perform_query(self, index: VectorStoreIndex, query: str) -> str:
37 query_engine = index.as_query_engine()
38 return query_engine.query(query)
39
40@time_it
41def main() -> None:
42 builder = IndexBuilder()
43 
44 documents = builder.load_documents()
45 builder.set_embed_model()
46 builder.set_llm_model()
47 
48 index = builder.create_index(documents)
49 
50 response = builder.perform_query(index, "作者跟 Sam 的关系是怎样的？")
51 
52 print("查询结果：")
53 print(response)
54
55if __name__ == "__main__":
56 main()

由于后续除了 LlamaIndex 又安装了几个依赖库，所以在项目根路径下创建了 requirements.txt 文件，文件内容如下：

1llama-index
2python-dotenv
3llama-index-llms-ollama
4llama-index-embeddings-huggingface

执行以下命令一次性安装所有依赖：pip3 install -r requirements.txt 这样方便一些。

RAG 应用创建完成

有了以上的代码基础，其实一个小型的 RAG 应用的核心就完成了，我可以基于本地知识库结合大语言模型进行自然语言的查询了。

比如我问：“作者跟 Sam 的关系是怎样的？”

回答是：“作者与 Sam Altman 的关系是在 2013 年决定让他成为 YC（Y Combinator）的总裁。在那之前，他们可能有某种工作或业务上的联系，因为他们讨论了重组 YC 并让 Sam 接任总裁职位的事情。通过这个决策，可以看出作者认为 Sam 适合领导 YC，并且在 Sam 最初拒绝后，作者坚持不懈地说服他接受这一角色。最终，在 2013 年 10 月，Sam 同意从 2014 年冬季开始接管 YC。这表明两人之间有某种程度的合作和信任关系。”

你看，基于本地知识库的回答比单纯用 LLM 靠谱多了吧。

然后呢？ 是的，我们只有一个内核还远远不够，我们还需要漂亮的 UI，更加易用和丰富的功能，程序性能还要强，把它做成一个产品。然后产品还要宣传、推广、积累用户、产品迭代。我们还要赚钱，还要考虑如何盈利。…..

差不多了，真的。想到这里，你再看看市面上那些 AI 产品是不是相似的配方？

最后

行文至此，关于这 5 行代码的事情我觉得已经说清楚了。最后感慨一下：AI 赛道真是越来越卷了，但无论无何，感谢 Python , 感谢 LlamaIndex ，感谢开源和为开源做出贡献的人们。有了他们我们才能够如此享受技术带来的红利。

还在用 top htop? 赶紧换 btop 吧，真香！

Tue, 17 Sep 2024 03:35:33 +0000

top

在 Linux 服务器上，或类 Unix 的机器上，一般我们想查看每个进程的 CPU 使用率、内存使用情况以及其他相关信息时会使用 top 命令。

top 是一个标准的 Linux/Unix 工具，实际上我从一开始接触 Linux 就一直使用 top , 一般是两种场景：

Linux 服务器上用
自己的 Mac 电脑上用

top 有一些常用的功能，比如可以动态的显示进程的情况，按照 CPU 、内存使用率排序等。说实话，这么多年了，使用最多的还就是 top ，一来是因为习惯了，工具用惯了很多操作都是肌肉记忆。二来是 top 一般系统自带不用安装，省事儿。

htop

top 挺好的，但 top 对于初学者和小白用户不太友好，尤其是它的用户界面和操作。于是后来有了 htop

htop 是 top 的一个增强替代品，提供了更加友好的用户界面和更多的功能。与 top 相比，htop 默认以颜色区分不同的信息，并且支持水平滚动查看更多的进程信息。htop 还允许用户使用方向键来选择进程，并可以直接发送信号给进程（如 SIGKILL）。htop 支持多种视图和配置选项，使得用户可以根据自己的喜好定制显示的内容。

htop 我也用了几年，确实舒服一些，但由于需要安装和我对 top 的肌肉记忆，htop 在我的使用中并未完全替代 top。直到 btop 的出现

btop

现在，我本机使用的是 btop，有了 btop，top 和 htop 一点儿都不想用了，哈哈。

在服务器上有时候因为懒不想安装，一部分时间还是 top，一部分用 btop。

第一印象是真漂亮啊，然而它不止好看，功能也是很实用，操作还很简单，你说能不喜欢它吗？

说是 btop ，实际上人家真正的名字是 btop++ , 用 C++ 开发的

安装

btop 支持各种类 Unix 系统，你可以在它的文档中找到对应系统的安装方法 https://github.com/aristocratos/btop

本文演示，我是用我自己的 Mac 笔记本电脑，用 Mac 安装很简单，用 brew 一行搞定

brew install btop

我的系统情况是这样的：

安装完成后，直接运行 btop 就可以看到如上图的界面了。

功能界面

打开 btop 后不要被它的界面唬住了，其实非常的简单，我们来介绍一下。

打开 btop 后，其实显示的是它给你的 “预置” 界面。默认有 4 个预置界面，你可以按 p 键进行切换。命令行界面上会分别显示：

preset 0
preset 1
preset 2
preset 3

你可能注意到了，这 4 个预置界面中有很多内容是重复的，没错，其实 btop 一共就 4 个模块，预置界面只是把不同的模块拼在一起显示罢了。这 4 个模块分别是：

CPU 模块
存储模块
网络模块
进程模块

这 4 个模块对应的快捷键分别就是 1，2，3，4 你按一下模块显示，再按一下模块隐藏。

所以如果你对预置界面的内容想立刻调整，就可以按快捷键来显示/隐藏你想要的模块，当然预置界面也是可以通过配置文件调整的，这个我们后面说。

CPU 模块

CPU 模块可以显示 CPU 型号、各内核的使用率、温度，CPU 整体的负载，以及一个直观的图象，所有数据都是实时显示的。

存储模块

存储模块包括两部分，一个是内存使用情况，一个是磁盘使用情况：

因为比较直观，具体内容我就不解释了。

网络模块

网络模块可以看下网络的整体负载和吞吐情况，主要包括上行和下行数据汇总，你可以通过按快捷键 b和n 来切换看不同的网卡。

进程模块

初始的进程模块可以看到：

pid
Program: 进程名称
Command: 执行命令的路径
Threads: 进程包含的线程数
User: 启动进程的用户
MemB: 进程所占用内存
Cpu%: 进程所占用 CPU 百分比

你可以按快捷键 e 显示树状视图：

可以按快捷键 r 对进行排序，按一下是倒序，再按一下是正序。具体排序列可以按左右箭头，根据界面显示进行选择，比如我要按照内存使用排序，那么右上角就是这样的：

按 f 键输入你想过滤的内容然后回车，可以过滤一下界面显示的内容，比如我只想看 chrome 的进程情况：

还可以通过上下箭头选中某一个进程按回车查看进程详情，再次按回车可以隐藏详情：

显示进程详情后可以对进程进行操作，比如 Kill 只需要按快捷键 k 就可以了，然后会弹出提示：

主题

怎么样，是不是很方便，操作简单，上手容易，还好看。关于 btop 的主要操作就这些了，剩下的可以参考 help 和 menu 中显示的内容自行操作和设置都很简单。

btop 的配置文件默认在这里：$HOME/.config/btop ，你可以直接修改配置文件中的详细参数，如我们前文提到的 “预置” 界面以及预置界面内容都可以在配置文件中设置：

此外 btop 还有很多好看的主题配色，但默认安装的情况下只带了一个 Default 的，如果你想切换用其他的主题，需要先下载这些主题，主题文件在这里：https://github.com/aristocratos/btop/tree/main/themes

下载好以后放到本地对应的文件夹中 ~/.config/btop/themes

然后你就可以要界面上进行主题的切换了，具体流程是先按快捷键 m ，然后选 OPTIONS

接着在 Color theme 中就能看到你当前拥有的 theme 数据，按方向键就可以切换主题配色了：

主题有很多，我这里给大家一个完整的预览：

我目前使用的就是 Default 我觉得最符合我的审美。

最后

用了 btop 后你就再也回不去了，一般情况下再也不会想用 htop 和 top 了，大家没有换的可以直接换了

上周 AI 大事记- 苹果智能、SB 1047 法案通过、OpenAI 芯片、SSI 获 10 亿美元融资

Thu, 12 Sep 2024 23:00:00 +0000

一、苹果智能新动向

近日，苹果公司正式发布了 iPhone 16 系列，包括 iPhone 16、iPhone 16 Plus、iPhone 16 Pro 和 iPhone 16 Pro Max。这一系列手机均融入了苹果最新的智能技术——苹果智能（Apple Intelligence）。然而，苹果智能并不会在下个月随着 iOS 18.1、iPadOS 18.1 和 macOS Sequoia 15.1 的更新而全面推出，而是将在未来几个月内逐步推出更多功能。

苹果智能的核心功能包括：

系统级写作工具：用户可以在 Mail、Notes、Pages 等应用以及第三方平台中重写、校对和总结文本。
照片搜索与编辑：在 Photos 应用中，用户可以使用自然语言搜索特定图片，利用清理工具去除不需要的物体，并通过简单输入描述来创建个性化电影。
音频记录与转录：在 Notes 和 Phone 等应用中，用户可以录制、转录和总结音频，帮助捕捉和回忆对话和通话中的重要信息。

所有这些功能都强调了对用户隐私的保护。苹果智能最初将以美国英语推出，并随着时间的推移扩展到其他英语方言和语言。

二、SB 1047 法案引发热议

备受争议的加州法案 SB 1047 已经通过了州参议院的审议，目前正等待州长加文·纽森（Gavin Newsom）的决策。该法案由州参议员斯科特·维纳（Scott Wiener）提出，旨在防止 AI 灾难的发生。法案针对的是那些可能引发灾难性事件的大型 AI 模型，如造成人员伤亡或价值超过 5 亿美元的网络攻击。法案提议让 AI 开发者对其模型造成的任何伤害负责，类似于枪械制造商需对大规模枪击事件负责一样。此外，法案还赋予加州总检察长起诉 AI 公司的权力，如果他们的科技被用于灾难性事件，将面临巨额罚款。

尽管包括埃隆·马斯克（Elon Musk）在内的一些行业人士对该法案持谨慎乐观态度，但其他人担心这可能会阻碍加州蓬勃发展的 AI 产业的创新。纽森州长必须在 9 月 30 日之前签署或否决该法案。

三、OpenAI 自研芯片计划

据《联合报》报道，OpenAI 计划使用台积电（TSMC）即将推出的 1.6nm A16 工艺节点构建自己的 AI 芯片。这一举措意味着 OpenAI 可能有意制造自己的计算芯片，这将是对他们战略的重大转变，也是降低在英伟达（Nvidia）AI 服务器上运行 ChatGPT 所带来高昂成本的一种手段。A16 工艺节点仍在开发中，将是 TSMC 首个使用背面电源传输技术的节点，被称为超级电源轨（Super Power Rail）。然而，该项目的未来仍充满不确定性。

四、SSI 获 10 亿美元融资

由前 OpenAI 首席科学家伊利亚·苏茨克弗（Ilya Sutskever）共同创立的 AI 初创公司 Safe Superintelligence（SSI）成功筹集了超过 10 亿美元的融资。主要投资者包括 NFDG、a16z、红杉资本（Sequoia）、DST Global 和 SV Angel，使 SSI 的估值达到约 50 亿美元。这些资金将用于购买计算能力和扩大位于帕洛阿尔托和特拉维夫的研究人员和工程师团队。苏茨克弗此前曾领导 OpenAI 的 Superalignment 团队，但在与几位董事会成员和 CEO 萨姆·奥特曼（Sam Altman）发生公开分歧后离开了该公司。

五、其他新闻

Adobe Firefly 视频生成：Adobe 的 AI 视频生成模型 Firefly 将在今年引入生成扩展、文本转视频和图片转视频等功能，旨在补充或加速现有工作流程，同时实施限制某些内容的保护措施。
DeepSeek-V2.5 崭露头角：开源 AI 模型 DeepSeek-V2.5 因其增强的语言处理和编码能力而受到赞誉，在各种基准测试中表现优于其前辈和其他模型，并可用于商业用途。
Reflection AI 模型表现优异：HyperWrite 开发的开源 AI 模型 Reflection 70B 引入了一种新颖的“反射”机制，提高了推理能力和准确性，在各种基准测试中超越了 GPT-4o，表现出色。
Yi-Coder 代码生成表现强劲：01.AI 推出的 Yi-Coder 是一款小型代码 LLM 系列，在代码生成、编辑和长上下文理解方面表现出色，超越了更大的模型，在竞争性编程和标准代码生成基准测试中表现优异。
OLMoE 开源语言模型：OLMoE 是一个完全开放的最先进的语言模型，拥有 70 亿参数，在 5 万亿令牌上进行了预训练，并在类似的活跃参数模型中表现优异。
Open-MAGVIT2 推动自回归视觉生成民主化：Open-MAGVIT2 是一个开源项目，旨在通过提供 Google 的 MAGVIT-v2 分词器的复制并探索其在普通自回归模型中的应用来民主化自回归视觉生成。
Replit AI 代理实现应用自动编码部署：Replit 推出了一款 AI 代理，能够从头开始构建整个应用程序，具有更高的独立性，并能够在无需用户持续输入的情况下做出决策和执行复杂任务。
Google 测试“Ask Photos”AI 助手：Google 正在测试一项新的“Ask Photos”功能，该功能使用 AI 理解照片内容，并允许用户以新的方式探索照片库。
Roblox 开发开源 3D AI 模型：Roblox 正在开发一个开源的生成式 AI 工具——3D 基础模型，该模型可以理解各种提示并旨在加速游戏开发，同时为更快的游戏加载进行技术改进。
You.com 转型聚焦生产力代理：You.com 正在从 AI 搜索转向更深层次的生产力代理，旨在更好地回答复杂问题并为知识工作提供生产力引擎。
Musk 的 xAI 超级计算机上线：埃隆·马斯克在短短四个月内组装了一台运行 10 万台 Nvidia GPU 的新超级计算机，旨在加速 AI 项目的训练并解锁新能力。
Anthropic 推出 Claude AI 企业版：亚马逊支持的 AI 初创公司 Anthropic 推出了面向企业的 Claude Enterprise 新产品，旨在整合 Anthropic 的人工智能，具有更大的上下文窗口、活动源和公司隐私等功能。
Canva AI 功能引争议：Canva 积极推出的生成式 AI 功能导致部分订阅价格上涨了 300%，引发了用户的强烈反响。
Oracle 股价飙升：由于其在云服务领域的 AI 推动，Oracle 的股价飙升超过 10%，云产品收入增长了 21%，与市场领导者的差距缩小。
Intel 赢得重要 AI 芯片客户：英特尔的 Gaudi 3 AI 芯片因 IBM 合作将其集成到其云数据中心而受到关注，这标志着英特尔在 AI 加速器市场上的重大胜利。
OpenAI 商业版 ChatGPT 付费用户破百万：OpenAI 的企业版 ChatG2PT 已突破 100 万付费用户，表明企业对其聊天机器人的需求不断增长。
SambaNova 推出最快 AI 推理服务：SambaNova Systems 推出了世界上最快的 AI 推理服务，使开发人员能够以无与伦比的速度和低延迟运行 AI 模型，超过了 OpenAI、Anthropic 和 Google 等供应商的系统推理速度。
Glean 融资 2.6 亿美元：Glean 在 E 轮融资中筹集了 2.6 亿美元，以加速其 AI 创新和全球扩展其企业工作 AI 平台，估值翻倍至 46 亿美元。
Sakana AI 与 Nvidia 合作：日本的 Sakana AI 与 Nvidia 合作开发 AI 社区，并筹集了 1 亿美元用于人才和基础设施发展。
Audible 将生成 AI 配音：Audible 将使用 AI 复制选定的有声书叙述者的声音，旨在快速且经济地扩大其有声书产品，并将有传统叙述者整合到不断发展的有声书自动化世界中。

六、研究进展

Google DeepMind 推出 AlphaProteo：Google DeepMind 推出了 AlphaProteo，这是一个生成新蛋白质的 AI 系统，旨在加速药物设计、疾病理解和健康应用的研究，可能会带来治疗和诊断方面的突破。
LLMs 能否生成新颖研究想法？：一项涉及 100 多名 NLP 研究人员的大规模人类研究表明，LLMs 能够生成比人类专家更多新颖的研究想法，但在可行性方面略逊一筹，这引发了对其能力进一步研究的需要。
Fire-Flyer AI-HPC：一种成本效益高的深度学习软硬件协同设计——Fire-Flyer AI-HPC 架构将建设成本降低了一半，能耗降低了 40%，同时实现了与 DGX-A100 相似的性能。
Hermes 边缘设备大模型推理：通过 Hermes 系统实现了边缘设备上大型 AI 模型的高效管道推理，优化了内存使用。

七、社会关注

音乐制作人因使用 AI 被捕：一名音乐制作人因使用 AI 和机器人提升其在平台上的流量并生成 AI 音乐而被捕，面临洗钱和电汇欺诈的指控。
泰勒·斯威夫特对 AI 版本表示担忧：泰勒·斯威夫特对一个虚假宣传特朗普的 AI 版本表示担忧，并正式支持卡玛拉·哈里斯（Kamala Harris）和蒂姆·瓦尔兹（Tim Walz）参加 2024 年总统大选。

八、政策动态

美欧英签署首个国际 AI 条约：美国、欧盟和英国签署了世界上第一个国际 AI 条约，强调人权和民主价值是监管公共和私营部门 AI 模型的关键，条约要求各签署方对其 AI 系统造成的任何伤害或歧视负责。
Grok AI 被禁止使用欧盟公民推文：在爱尔兰数据保护专员采取法律行动后，Grok AI 被永久禁止使用欧盟公民的推文，该问题已被提交至欧洲数据保护委员会进一步裁定。

以上就是上周 AI 领域的重大新闻和研究进展。随着 AI 技术的不断发展，我们期待未来能看到更多创新和突破。感谢您的关注，我们下期再见！

IP地址的多种书写方式

Fri, 30 Aug 2024 02:36:04 +0000

当我们提及 IP 地址，大多数人首先想到的是那种我们习以为常的形式：如 127.0.0.1、10.0.2.1 等。这些由数字和点组成的串，在日复一日的使用中，或许已经变得有些单调乏味。但你是否知道，IP 地址并非只能以这种方式呈现？事实上，它拥有多种书写方式，这些不同的形式不仅可以为我们带来乐趣，更能在某些特定场合发挥出意想不到的作用。

一、IP 地址的常规书写与潜在变化

在大多数情况下，我们使用的 IP 地址都是点分十进制格式，即由四个 0-255 之间的数字组成，数字之间用点号分隔。这种格式简单明了，易于理解和记忆。然而，这种常规的书写方式背后，其实隐藏着一些不为人知的秘密。

二、零的可选性

首先，让我们来看一个有趣的例子。

在 Linux 系统中，输入ping 0，你会发现它实际上被解析为127.0.0.1。

1$ ping 0
2PING 0 (127.0.0.1) 56(84) bytes of data.
364 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.053 ms
464 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.037 ms

但在 Mac 系统中，同样的命令却会返回一个错误，提示无法找到目标主机。

1$ ping 0
2PING 0 (0.0.0.0): 56 data bytes
3ping: sendto: No route to host

这是因为，在不同的操作系统中，对于 IP 地址中零的处理方式可能存在差异。

再来看另一个例子：ping 127.1。这个命令在大多数系统中会被解析为127.0.0.1，系统会自动在数字前补零。

1$ ping 127.1
2PING 127.1 (127.0.0.1): 56 data bytes
364 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.033 ms
464 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.085 ms

但请注意，这并不意味着计算机可以随意猜测并填充零。例如，ping 10.50.1会被解析为10.50.0.1，而不是10.50.1.0或其他形式。

1$ ping 10.50.1
2PING 10.50.1 (10.50.0.1): 56 data bytes
3Request timeout for icmp_seq 0

这是因为 IP 地址的结构是固定的，每个部分都有其特定的含义和范围。

三、IP 地址的“溢出”技巧

除了零的可选性外，我们还可以利用 IP 地址的“溢出”特性来玩一些小把戏。例如，ping 10.0.513这个命令，在大多数系统中会被解析为10.0.2.1。这是因为 IP 地址的每个部分都是一个 8 位的二进制数，最大值为 255。当超过这个值时，它会自动“溢出”并从零开始重新计数。在这个例子中，513 被解析为 2x256+1，即 257，但由于 IP 地址每部分的取值范围是 0-255，所以它实际上被解析为 2，再加上前面的 10.0.0，就得到了 10.0.2.1。

1$ ping 10.0.513
2PING 10.0.513 (10.0.2.1): 56 data bytes
364 bytes from 10.0.2.1: icmp_seq=0 ttl=61 time=10.189 ms
464 bytes from 10.0.2.1: icmp_seq=1 ttl=61 time=58.119 ms

这种“溢出”技巧不仅可以用于娱乐和恶作剧，还可以在某些特定场合发挥出实际作用。例如，在网络安全领域，攻击者可能会利用这种技巧来绕过一些基于 IP 地址的过滤和限制。

四、十进制、十六进制与八进制的 IP 表示

除了我们常见的点分十进制格式外，IP 地址还可以用其他进制来表示。例如，我们可以使用十进制数来表示一个 IP 地址。

1$ ping 167772673
2PING 167772673 (10.0.2.1): 56 data bytes
364 bytes from 10.0.2.1: icmp_seq=0 ttl=61 time=15.441 ms
464 bytes from 10.0.2.1: icmp_seq=1 ttl=61 time=4.627 ms

如上文提到的ping 167772673，这个十进制数实际上就是10.0.2.1的另一种表现形式。这种表示方法在某些编程和网络调试场景中可能会更加方便。

具体来说：167772673 在十进制下转换为二进制是 00001010000000000000001000000001

这个二进制数可以按照每 8 位一组分割为：

00001010
00000000
00000010
00000001

分别转换为十进制数为：

同样地，十六进制也是 IP 地址的一种常见表示方式。例如，ping 0xA000201这个命令中的0xA000201就是一个十六进制数，它同样表示的是10.0.2.1。在计算机科学中，十六进制是一种常用的表示方式，因为它可以更紧凑地表示较大的数字，并且与二进制之间的转换相对简单。

1$ ping 0xA000201
2PING 0xA000201 (10.0.2.1): 56 data bytes
364 bytes from 10.0.2.1: icmp_seq=0 ttl=61 time=7.329 ms
464 bytes from 10.0.2.1: icmp_seq=1 ttl=61 time=18.350 ms

此外，我们还可以使用八进制来表示 IP 地址。虽然这种方式在实际应用中相对较少见，但它同样具有一定的理论和实际意义。例如，ping 10.0.2.010这个命令中的.010实际上就是八进制数 8，所以这个命令最终会被解析为10.0.2.8。

1$ ping 10.0.2.010
2PING 10.0.2.010 (10.0.2.8): 56 data bytes

五、使用 Sipcalc 工具进行 IP 地址转换

对于需要进行大量 IP 地址转换的场景，我们可以借助一些工具来简化操作。其中，sipcalc （https://github.com/sii/sipcalc）就是一个非常实用的命令行 IP 地址计算器。它可以方便地进行十进制、十六进制等不同进制之间的转换，并且提供了丰富的输出格式和选项。

使用sipcalc工具，我们可以轻松地将一个 IP 地址从一种格式转换为另一种格式。例如，要将十进制数167772673转换为点分十进制格式，我们可以输入相应的命令并得到结果10.0.2.1。同样地，我们也可以将一个点分十进制格式的 IP 地址转换为其他进制表示形式。

六、IP 地址书写方式的多样性与应用场景

除了上述提到的几种 IP 地址书写方式外，还有一些其他不太常见但同样有趣的表示方法。这些方法或许在日常使用中并不常见，但在某些特定场合却能发挥出意想不到的作用。

例如，在网络安全领域，攻击者可能会利用 IP 地址的不同书写方式来绕过一些基于规则的过滤和检测系统。他们可能会使用一些特殊格式的 IP 地址来隐藏真实的攻击目标或规避安全策略。

此外，在网络编程和调试过程中，灵活运用 IP 地址的不同书写方式也可以为我们带来便利。例如，在编写网络应用程序时，我们可能需要根据不同的需求和环境选择最合适的 IP 地址表示形式。

七、如何防范 IP 地址欺骗与攻击

虽然 IP 地址的不同书写方式为我们带来了乐趣和便利，但与此同时也带来了一定的安全风险。特别是当攻击者利用这些技巧进行 IP 地址欺骗和攻击时，后果将不堪设想。

为了防范这些潜在的安全威胁，我们可以采取以下措施：

使用防火墙和安全策略：配置防火墙和安全策略来限制对特定 IP 地址或 IP 地址范围的访问。这样可以有效防止未经授权的访问和攻击。
验证 IP 地址来源：在进行网络通信和数据交换时，务必验证对方的 IP 地址来源和真实性。不要轻易相信来自未知或可疑来源的 IP 地址信息。
定期更新系统和软件：及时更新操作系统、应用程序和安全补丁以修复可能存在的安全漏洞。这样可以降低被攻击的风险并提高系统的安全性。
加强网络安全培训：提高员工和用户的网络安全意识培训，让他们了解常见的网络攻击手段和防范措施。这样可以形成一道坚实的网络安全防线。

八、结语

通过本文的介绍和分析，我们可以看到 IP 地址并非只能以常规的点分十进制格式呈现。除了这种常见形式外，它还可以用其他多种方式来表示和书写。这些不同的书写方式不仅为我们带来了乐趣和便利，更在某些特定场合发挥出意想不到的作用。

然而，与此同时我们也需要注意防范这些不同书写方式可能带来的安全风险。通过采取适当的安全措施和策略，我们可以有效降低潜在的安全威胁并保障网络安全。

最后，希望这篇文章能为你带来一些新的启示和思考。如果你对 IP 地址或其他网络安全话题感兴趣，欢迎继续关注和探索更多有趣的内容！

MacOS on 小盒子的技术分享

OpenClaw 爆火背后：它不是聊天机器人，而是一套真正会做事的 AI 系统

一、OpenClaw 的本质，不是聊天机器人，而是“个人 AI 助手控制面”

二、Gateway 为什么是 OpenClaw 最关键的设计

三、它最强的抽象，不是对话框，而是 Agent、Session 和 Route

Agent：一颗完整隔离的大脑

Session：上下文连续性的主键

Route：决定消息进入哪颗大脑

四、Agent 不是外挂调用，而是嵌入式运行时

五、Agent Loop：一条消息的"真实旅程"

不是"一次请求"，而是一个完整生命周期

并发控制：为什么同一聊天窗口的消息要"排队"？

流式事件：你看到的不是"打字动画"，而是真实的工作过程

六、真正让它“像一个人”的，不是模型，而是 Workspace、System Prompt 和 Memory

Workspace：AI 的家，而不是一个临时目录

System Prompt：每次运行都在"编译上下文"

Memory：真正写到磁盘，才算记住

检索机制：不是"只有文件"，也不是"只有向量"

记忆刷新：在"遗忘"前先"存档"

七、工具体系：分层设计，不是堆砌功能

Tools：第一等公民

Plugins：扩展系统本身

Skills：教 AI 如何做事

八、Node：让 AI “有手有眼”

Node 是什么？

九、安全边界：诚实比承诺更重要

安全层次

Sandbox：可以隔离，也可以放行

浏览器隔离：不是接管你的 Chrome

十、为什么这是"个人AI操作系统"的雏形？

它具备了"操作系统"的味道

如何在 mac 的 chrome 中开启 gemini 侧边栏

第一步

第二步

Kimi K2.5 模型接入 Claude Code 完全指南

Kimi K2.5 模型接入 Claude Code 完全指南

准备工作

核心配置项

macOS / Linux 配置方法

方法一：临时配置（当前终端会话）

方法二：永久配置（推荐）

1. 确定你的 shell 类型

2. 编辑配置文件

3. 添加环境变量

4. 保存并生效

5. 验证配置

Windows 配置方法

方法一：PowerShell 临时配置

方法二：系统环境变量（永久配置）

方法三：PowerShell 配置文件

验证连接

Gemini 3 介绍

一、核心模型：不再只是 “陪聊”，而是 “干活” 的

二、 AI IDE ：Google Antigravity (反重力)

三、 用户体验革命：Generative UI (生成式 UI)

四、 实战与性能 (Benchmarks)

五、 生态整合（这才是 Google 恐怖的地方）

六、 总结与建议

Milvus 向量数据库快速入门

一、什么是 Milvus？

概念关系图（逻辑结构）

二、Milvus 核心概念速查表

实体 Entity 示例

三、核心操作流程

四、一致性模型与数据安全保障

五、索引类型选择指南

六、进阶知识点补充

七、实战：使用 Python SDK 完整示例（基于 Milvus 2.x）

环境准备

初始化连接

创建 Collection

插入数据

创建索引 & 加载数据

向量搜索 + 条件过滤（Hybrid Search）

八、常见踩坑提醒

九、真实应用场景参考：电商推荐系统

十、快速上手建议

从初始化一个现代 python 项目中学习到的东西

uv

环境

三、用户体验革命：Generative UI (生成式 UI)

四、实战与性能 (Benchmarks)

五、生态整合（这才是 Google 恐怖的地方）

六、总结与建议

✅ `[project.scripts]`：定义可执行命令（如 CLI）

✅ `[project.urls]`：项目的相关链接（非必须）

✅ `[project.optional-dependencies]`：可选依赖（比如开发环境）

✅ `[tool.pytest]`：Pytest 配置

✅ `[tool.black]`：代码格式化工具 Black 的配置

✅ `[tool.isort]`：import 排序工具 isort 的配置

✅ `[tool.hatch.build.targets.wheel]`：Hatchling 打包配置

存储模块