这周有几件事放在一起看，会比单独看更有意思。

mcp-inspector 1.0.0 进了 formula，这是 MCP 官方的调试工具。 Logseq 在去年圣诞夜另起了一个叫 og 的仓库，本周 1.0 进了 Cask。 arcbox 在官网的产品描述里，把"给 AI agent 跑的隔离沙箱"当做头号卖点。 三件事，三种方式，都在回答同一个问题：这个生态正在往哪里分。

本周一句话总结

工具在打标签——哪些是给 agent 的，哪些是留在本地文件的，哪些是"调试用的"。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

mcp-inspector 1.0.0：MCP 生态的"调试工具"到位了

上周写 smithery-cli 和 toolhive-studio 同时进 Homebrew，说的是"MCP server 的安装体验被认真对待了"。这周 mcp-inspector 到 1.0，是这条线的下一段。

mcp-inspector 是 MCP 协议官方出的调试工具——一个 React Web UI + Node.js 代理的组合，你本地起一个 MCP server，用它来连、测、看请求响应、检查 tool 列表、验证 prompt 模板。10k+ stars，是 MCP 生态里目前最被引用的开发工具之一。

到 1.0 这件事值得记的不是功能变化（版本 notes 就四个字"OG rocks!"），而是时间点。三周内，homebrew 里先进了安装器（smithery-cli）、管理器（toolhive-studio）、agent 专用终端（otty），现在是官方调试工具的 1.0。MCP 的开发者工具链，正在按顺序补齐。

写第一个 MCP server 的人，以前得自己 console.log 调试。现在有了一个带界面的工具。

logseq-og：Logseq 在自己家里另起了一条线

Logseq 的主线在走向数据库模式——把笔记从 Markdown 文件迁移到结构化数据库，支持更复杂的查询和同步。这件事不是秘密，但也不是所有人都愿意跟。

2025 年 12 月 25 日，logseq/og 这个仓库出现了。仓库名叫 og，描述是"Logseq og (file version)"——"og"通常是"original"的缩写。简单说：这是 Logseq 官方维护的、坚持基于本地 Markdown 文件的那条线，和主线数据库版本分开走。

本周，logseq-og 1.0.0 进了 Homebrew Cask。

这件事让我想的不是该装哪个版本。我想的是：一个产品同时维护"现代化路线"和"给不想跟的人留的入口"，这是一种什么状态？ Vim 和 Neovim、Python 2 和 Python 3、现在是 logseq 和 logseq-og。每次这种分叉出现，都意味着原来那条路积累了足够多不愿意走新路的人。

1.0 进 Homebrew，说明这条线有人认真对待，不是放着慢慢死的。

arcbox：把 AI agent 沙箱写进产品定位

arcbox 是 Docker Desktop 的 Apple Silicon 替代品——容器、Firecracker 微虚拟机、完全开源，macOS 15+ 专属。光是这几点，放两年前就可以写一节了。

但它的产品页头号卖点不是"比 Docker Desktop 快"，是：**"AI agents are powerful — and unpredictable. ArcBox Desktop runs your local agents in fully isolated Firecracker microVMs."**

这是第一次我在一个容器工具的官方文档里，看到"AI agent 是危险的，所以我们给它造了一个笼子"被写成产品核心功能。不是"支持运行 AI 应用"，是"我们假设你跑的 agent 会做不可预测的事，所以每个 agent session 有独立 microVM，你能看到它的每一个 syscall、网络请求和文件写入"。

这个叙事变化比工具本身有意思。**agent 沙箱从"偏执用户的自选配置"变成了"负责任的工具该有的默认设计"**，这个转变正在发生。

utiluti：改默认应用，终于有了 CLI

# 查询当前默认浏览器
utiluti get browser

# 设置默认 PDF 阅读器
utiluti set com.apple.Preview pdf

# 列出某种文件类型的所有可用应用
utiluti list html

这个问题比看起来麻烦：macOS 的"默认应用"管理散在 LaunchServices 框架里，没有官方 CLI，要改就要去 System Settings 点，或者写十几行 Swift 调用私有 API。

utiluti 是 scriptingosx（macOS 脚本圈的老人，写过《Shell Scripting with Zsh》）写的。它把这件事包了一层，给出了可以在终端里用的命令。用途不花哨，就是**"我想在脚本里切换默认浏览器"这个具体需求，现在有工具了**。

一点个人感受

perplexity 的 cask 描述写的是"AI-powered answer engine with Personal Computer agent"——Perplexity 把 PC agent 功能放进桌面客户端，这件事今年发生，但进 Homebrew 比我想象的要快。它的 formula 名字叫 perplexity，没有加 ai 后缀，这种命名置信度很高，代表他们认为产品本身就是品牌。

willow-voice 是这周第四个或第五个进 Homebrew 的本地语音工具（上两期有 muesli、macparakeet、subtitle-studio）。每周都有，但它们不一样：muesli 做的是"会议记录"，subtitle-studio 做的是"视频字幕"，willow-voice 做的是"写作时的语音输入"。本地语音这个品类在分化，不是在重复——每个工具找到了不同的"这段声音不该上传"的具体场景。

siliconscope 监控 ANE（Apple Neural Engine）使用率，这个指标我以前看不到。以前 Activity Monitor 里没有 ANE。现在有了工具，才发现自己不知道那块芯片在什么时候、被谁用。

btcli（Bittensor CLI）这周被标记 deprecated——理由是"repo archived"。Bittensor 11.0.0 这周也进了，但 CLI 工具就这么退场了。

结语

mcp-inspector 到 1.0 的同一周，logseq 在自己家里给"不想跟"的人留了一扇门，arcbox 在卖 AI agent 的笼子。这三件事不是同一件事，但它们都在说：某些方向已经走远了，走得够远才需要有人站出来说"我不走那条路"或者"走那条路要装防护"。

不是浪潮，是分叉出现了。

这一周的新增列表没有特别眩目的东西,但有一条线很清晰:MCP 生态开始在 Homebrew 里占位了。

不是 MCP 协议本身,是围着它的那一圈 — 安装器、管理器、专用终端。 工具基础设施长出来,通常意味着这件事要进下一个阶段了。

本周一句话总结

MCP 不再只是"大厂的实验",这周 Homebrew 里同时进了两个围绕它生长的工具,安装器和管理器各一个。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一节只挑 4 个值得停下来多看两眼的点。 它们的共同主题是:MCP 的基础设施正在补齐,AI agent 的终端正在成形。

smithery-cli + toolhive-studio:同一周进,不是巧合

这两个工具同时出现在这周的新增里 — 一个 CLI,一个 GUI,目标都是一件事:替你管 MCP 服务器。

smithery-cli 的定位是"从 Smithery 市场直接装 MCP server",命令行操作,背后是 Smithery 这个 MCP 工具集中列表平台。toolhive-studio 是 Stacklok 出的桌面版,用容器跑每一个 MCP server,自动帮你配好 Claude Code / Cursor / GitHub Copilot 的客户端集成,还做了 secret 隔离和最小权限设置。

以前装一个 MCP server 需要自己找 GitHub、改配置文件、手动重启客户端 — 整个过程散在好几个地方。这两个工具各自选了一个入口把这件事包起来。

真正值得记的不是某一个工具,而是这件事同时出现了两种形态:marketplace CLI 和 GUI 管理器。说明 MCP server 的"安装体验"已经成了一个被人认真对待的问题,不是配置项,是产品。

otty:终端在往"agent 工作台"这个方向拐

传统终端是"你打命令、它输出",这件事在 agent 出现之前一直是对的。但 agent 不"打命令" — 它是在跑,你在看,偶尔介入。这是完全不同的使用姿势。

otty 把这个区别当成了设计出发点。它不只是渲染文字更漂亮 — 它加了"并排监控多个 agent session"、"prompt 队列"、"把终端输出直接发送给 agent"这类功能。屏幕不再是一行一行的命令,而是几个 agent 同时在工作、你在旁边做决策的工作面板。

它是免费的,macOS 原生,不需要账号。现在装它的人大多数是"看一下是什么感觉",但它指向的那个方向 — 终端从"输入设备"变成"agent 监控台" — 这条线不会消失。

librefang:AI agent 的"操作系统"这个说法第一次进 Homebrew

librefang 的描述是"自托管的、面向自主 AI agent 的操作系统"。这件事怎么理解因人而异,但单纯从"这个词组进了 homebrew/core 的正式描述"这件事来说,值得记一笔。

前几年 AI agent 的配套基础设施都在 Python 包生态里转,进 Homebrew formula 的路径是:项目足够稳定、有明确的二进制分发、团队认真对待"可以被干净卸载"这件事。librefang 今天版本号是 2026.7.11,走的是日期版本,说明它在快速迭代但也在认真维护。

不一定要现在就装,但**"自主 AI agent 的运行时"开始被当成一个可以 brew install 的东西**,这件事本身是一个信号。

vicinae:Raycast 这片水里,又进来一条鱼

vicinae 是一个 macOS 应用启动器 + 命令面板。Spotlight 做过,Alfred 做过,Raycast 现在把持着,vicinae 进来了。

这条赛道看起来饱和了,但它每一两年都会有新入场者,理由也总是类似的:"更快"、"更 native"、"更懂现在的工作流"。vicinae 要求 Apple Silicon + macOS 14,这个姿态更像是"我不做兼容性,我只做最新设备上最好的体验"。

装不装是另一件事。但 Raycast 已经"产品化"得越来越重,总有人在找替代品 — vicinae 在的位置是**"如果有一天你受够了 Raycast 的商业化,它可能是下一个值得看的"**。

一点个人感受

这周让我记下来的是 otty 和 toolhive-studio 这两个方向一起出现这件事。前者在回答"agent 出现之后终端应该是什么形状",后者在回答"MCP server 该怎么装和管"。两个都是基础设施层面的补课,不是功能堆砌。

chatgpt-classic 单独进了 Cask,名字带"classic",这种命名通常意味着**"我们已经承认旧版本是一个独立产品"**了。不知道是因为太多人回退,还是 OpenAI 自己留一条后路,总之值得注意一下。

soar 是这周新增里我最可能装的一个 — 静态二进制的包管理器,不需要 root,不依赖 libc,在受限环境里很有用。但它目前还有 3 个 build error,等一等。

游戏网络那一组(libyojimbo / netcode / reliable / serialize)同时进来,像是某个游戏基础库的配套分拆。不是主流工具,但说明 Homebrew 的覆盖面还在往专业垂直方向延伸。

结语

这一周的工具没有一个会让你"哇原来还能这样"。但 smithery-cli 和 toolhive-studio 同时进来,otty 出现在 Cask 里,librefang 用"自主 AI agent 操作系统"这个描述进了正式仓库 — 这些事放一起,你能看到 AI agent 的日常工具链在向 brew 这一侧靠拢。

不是浪潮,是沉降。工具开始落地了。

你不必每个都装,但能看到它们在哪儿补课,比跟着装要值钱。

这一周的新增列表里,有一类东西明显在堆 — 围着"AI agent"和"本地 AI"长出来的小工具。

不是新模型,也不是新框架,就是补那一个动作:让 agent 跑得更顺、让语音留在本机、让供应链有眼睛。

本周一句话总结

新增列表很热闹,但真正的主题只有一个:AI 工具链开始补"周边"了 — review 工具、保活工具、本地语音、本地安全扫描,从四面围过来。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一节只挑 4 个我觉得能停下来多看两眼的方向。 它们彼此不是一类,但都在回答同一道题:"agent 已经在这里了,我还要不要把别的东西也搬过来?"

hunk:替 agent 写的 diff 找一个看得下去的姿势

不是 hunk 自己,是它想接的那个东西 — agent 写代码越来越快,但 review 那一步还是原来那一套。git diff 滚一屏、左右对照、再开 IDE 看一遍,这一套流程在 agent 一晚上能交 50 个 patch 的时候直接崩。

hunk 的回答是:把 diff 当成"待审阅的稿子"来看。它在终端里给了一份侧边栏 — 文件列表、变更数、还能挂上 agent 的"注解"(为什么改、改了哪条思路),屏幕中间是带语法高亮和主题的 diff 视图,布局可切 split / stack / auto,支持 watch 模式跟着文件变,甚至能直接 cat patch.diff | hunk 喂进去。

它在替人省的不是"看 diff"这件事,而是 "理解 agent 改了什么" 那一段心智成本 — 把 review 从"翻 diff"变成"读批注"。

bbrew:Homebrew 自己长出来了一个 TUI

bbrew(Bold Brew)这件事有意思的点在于 — Homebrew 这个项目一直坚持"CLI 是最对的",但市场显然没听进去,所以社区里已经长出好几个 TUI 包装了。bbrew 是相对完整的那一档:Homebrew、Flatpak、Mac App Store 在一个界面里管,支持模糊搜索、过滤已装/过期/孤包、还能按下载量排序,顺手把 brew vulns 的扫描也接了进来(v 键),最绝的是可以一键导出选中的包到 Brewfile。

它甚至被 Bluefin/Universal Blue 收为默认 TUI(在 Linux 那一侧)。换句话说,这是个已经被某条发行线正式收编的工具,不是一个人在玩。

为什么在意它:因为它把 Homebrew 从"我每次都得想命令"变成"我滑一下就行"。这种"我替你管理命令"的中间件,后面只会越来越多。

adrafinil:在 agent 跑的时候才把 Mac 叫醒

这个名字借的是那个真实存在的"促醒药" adrafinil — 吃下去是惰性的,被代谢了才生效。工具本身借的是这个意思:Mac 默认是睡的,只有当某个 agent session 真的握着"我在跑"的句柄时,才阻止它入睡;session 结束,句柄释放,Mac 恢复正常睡眠。

caffeinate / Amphetamine 的老问题不是"保活",而是**"我忘了关"** — 笔记本在外头撑一宿、屏幕在包里烫手、合盖的逻辑被绕过。adrafinil 把"要不要保活"从用户手里拿走,交给 agent 自己声明。Claude Code、Codex、Hermes 都有 hook,合盖时还会响一声确认"我在替你 hold 住"。

它解决的不是性能问题,是生活形态问题 — 那些"agent 在后台跑、我出门 / 睡觉 / 走了"的真实场景。

muesli / subtitle-studio / harper-desktop:本地 AI 这一档的"小而不必送云"

这三个放一起说。muesli 是本地语音转写 + 会议记录,模型可以选 Parakeet / Whisper / Cohere / Qwen,装好之后完全离线,按 Right Cmd 就开始听写,把文本直接塞进当前应用。subtitle-studio 是离线 AI 字幕生成,arm64 原生。harper-desktop 是个本地语法检查器,目标用户是写代码注释和 PR 描述的人。

它们都共享一个姿态:**"我的语音 / 文字 / 语法,不租给任何云"**。这是 2025 年之后才慢慢显形的一类需求 — 之前大家默认"语音转写 = 走云 API = 上传音频",现在 Apple Silicon 给得起,模型小得下,于是每个细分动作都可以"本地化"。

它替人省的不是时间,是决定"这一段要不要上传" 时的那一点犹豫。

一点个人感受

cve-bin-tool / bomctl / sbom-utility 这一组工具同时进,值得记一笔 — SBOM 不再是合规文件,它开始长成"日常工具"了。前两年大家还在讨论"我们公司要不要生成 SBOM",现在 brew 仓库里就同时有三个相关的 formula,说明这事下沉到开发者桌面了。

zero 这个我装的可能性不大 — "你拥有的 terminal coding agent"这个定位,跟 Claude Code / Codex / Gemini CLI 已经重叠太多了。但它的名字起得有意思,关键词是 "you own",赌的是 "本地模型 + 自托管 agent" 这条线。

kotofetch 这种工具我大概率永远不会装,但每次看到都觉得这才是社区该有的样子 — 一个为"我喜欢在终端里看到一句日语"而存在的小工具,brew 里就是该有它。

结语

工具在变,但这次变的方向不是"哪个更快",而是"哪一块开始有人接得住"。agent 是新的中心,周边一圈正在被填上 — review、保活、本地化、安全。你不必每个都装,但看着它们按这个速度补齐,本身就是一件让人安心的事。

工具在变,节奏不必跟着变 — 挑能省掉你那一类犹豫的就好。

标题的后半句是：

存储涨价，限制了你的脑容量

【来自 - 科技爱好者周刊（第 402 期）】

【来自 - ChatGPT的回答】

【来自 - X上面Financial Times的评论】

早上去公司，电脑开机后，发现网络不能联通， 估计是CVR代理Timeout，需要重新手动连接一次才能用。

手动更新订阅后，想切换一下代理，改成“自动选择”。 结果发现切换不了。

然后就“强制退出”CVR，后续出现更诡异的事情。🤦

再次启动时，代理界面空白😑

不论刷新多少次订阅，代理界面依旧空白， 然后，发现本地的配置也无法更新😭

做为一个有尊严的程序员🧑‍💻，这点问题能难倒我？！

反复重启，并开始检查配置🧐，步骤如下：

1. 点击“订阅更新”，记录时间；
2. 检查配置目录，“订阅更新”时都有哪些文件修改；
3. 检查clash-verge.yaml配置文件；

“订阅更新”时，上面几个文件有修改

对比clash-verge.yaml，发现配置yaml缩进不对

初步断定：clash-verge.yaml文件格式有问题，导致代理界面空白。

为了验证想法，直接修改clash-verge.yaml文件格式 但似乎没有效果，clash-verge.yaml文件会被CVR重写😓

然后去网上搜了一下这个问题，发现蛮多人遇到：

• [BUG] 复杂配置文件代理规则页面显示空白 · Issue #1915 · clash-verge-rev/clash-verge-rev
• [BUG] 日志等级在info会导致代理组一片空白 · Issue #7049 · clash-verge-rev/clash-verge-rev
• [BUG] V2.4.6 安装完重启电脑后代理页一片空白 · Issue #6444 · clash-verge-rev/clash-verge-rev
• [BUG] 2.4.1重大问题导致无法使用：代理界面空白（Mac&Win） · Issue #4579 · clash-verge-rev/clash-verge-rev
• [BUG] ACL4SSR 似乎会导致 Clash-verge 无法与内核（？）通信？ · Issue #124 · clash-verge-rev/clash-verge-rev

简而言之，【Clash Verge Rev 代理界面空白】的问题，一直存在，从未被解决。

打算换个思路，刚好有一条评论引起了我的注意：

于是，进行以下几步操作 【恢复】：

1. 备份 io.github.clash-verge-rev.clash-verge-rev;
2. brew reinstall clash-verge-rev 重新安装 clash-verge-rev；
3. 进入 【备份设置】，点击 【查看记录】->【恢复备份】

经过以上操作，【Clash Verge Rev 代理界面空白】的问题解决。

事后，再次确认了一下CVR的配置文件，发现以下问题：

clash-verge.yaml与clash-verge-check.yaml 文件中，【proxies】【proxy-groups】【rules】节点下的缩进有问题；

另外，在出现【代理界面空白】的问题时，进入 【备份设置】，点击 【查看记录】->【恢复备份】，是没有作用的。

当 CVR 重新安装后，【恢复备份】才有用。 真是有点不可思议。

新发现，【升级内核】会报错，并导致代理界面空白。

或许这才是【元凶】。

以下仅个人观点，不指引任何事物

6月25日，苹果官网macbook等产品全线涨价。理由：存储涨了。

听到这个消息的时候，我脑袋有点懵圈。

苹果什么时候响应这么快了？

是不是早就谋划好了涨价？

熟知苹果供应链的人，应该知道，苹果的供应商与其之间是有长期合约，

不可能因为市场变化，而随便修改定价

况且，苹果产品本身就是高溢价，怎么卖都不会亏

这波涨上去之后，再想降价，就根本没指望了

年初Macbook Neo，就卖的很好，原因无他，价格便宜

现在Neo也涨上去了

感觉这就是饥饿营销，可耻！

刚刚看了新闻，

“三星、海力士、美光涉嫌操纵存储价格、供应遭诉讼：三家不在乎 没竞争对手”

报道来源，

• Major Chipmakers Sued For Price-Fixing Amid 'RAMpocalypse' - Law360
• Samsung, SK hynix, and Micron sued over alleged DRAM price fixing amid record memory costs — lawsuit claims coordinated HBM shift was cover to curtail DDR3 and DDR4 production | Tom's Hardware
• Samsung, SK Hynix, Micron face antitrust class action lawsuit
• Samsung, SK Hynix, and Micron are facing an antitrust class action over memory price-fixing
• Samsung, SK Hynix and Micron Sued in New DRAM Price-Fixing Class Action Lawsuit | ThePCEnthusiast

援引外媒报道以及国内报道，苹果以及海外存储厂商涨价，是早有预谋、坑瀣一气。

AI对存储的占用导致电子产品涨价，像是一场收割

裹夹着普通消费者，去抵冲AI带来的泡沫

坚决抵制苹果这种无序涨价的行为

这一周，commit 标题里出现最多的词是 mirror。

新公式只来了两位——tpack 和 slint-cpp。 Cask 一边有 openhuman、dockspace、atoll 这种"刘海 + 桌面"的新面孔， 也有 geolibre、libifd-cyberjack 这样的"小而专"。 但在引擎盖下，Homebrew 在做一件安静的事： 它在把十年前留着的镜像源一个一个关掉。 工具越来越轻，基础设施越来越紧。

本周一句话总结

新工具少，但都在认真解释"我为什么存在"。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

tpack：tpm 的现代替身，登录 tmux 时不再"黑屏等"

tpm（tmux-plugin-manager）是 tmux 圈的隐形基础设施——每个用 tmux 的人大概都 set -g @plugin '…' 过几次。 但它的痛点大家都熟悉：

• 装插件要 prefix + I，记不住快捷键
• 启动时静默 git clone，网络不好就是几秒黑屏
• 想知道"我现在到底装了什么"得翻 ~/.tmux/plugins/

tpack 的解法是把它做成一个 Go 写的二进制，带 TUI 界面。 完全兼容 tpm 的配置和插件——你 ~/.tmux.conf 里那行 set -g @plugin '…' 不用动， 但启动时多了进度条、多了可见列表、多了更新提示。

配方里有句自嘲的注脚：Full Documentation - Mostly AI-generated。 工具好用就行，文档是不是 AI 写的，已经不是重点。

它接入了 brew，意味着"你装 tmux，插件管理器就有了"这件事， 离"开箱即用"近了一步。

slint-cpp：C++ 写 UI 终于不用和 Qt 谈十年恋爱

slint-cpp 1.17.0 进了 core，这意味着 Rust 写的 Slint 工具包， 现在原生支持 C++ 头文件和库。 不需要走 Qt 的 moc，不需要等 CMake 找包， #include <slint.h> 直接就能用。

Slint 的设计思路一直是"为嵌入式、为工具、为跨平台 UI 写 DSL"—— .slint 文件声明 UI，C++/Rust 写逻辑，分工清楚。 1.17.0 这次的 feature：

• Skia + OpenGL 后端在 macOS / Linux 上稳定
• C++ 共享库 + 头文件可以直接 link
• 构建优化（LTO、Codegen units）进了公式默认值

Qt 的问题是"为我的简单工具引入一个 200MB 的框架"， Slint 的方向是"我的应用主二进制 + 几个 MB 的运行时"。 在 Apple Silicon 上尤其明显——brew install slint-cpp 之后， 一个 hello world 的窗口程序可以瘦到 5MB 以内。

slint-cpp 和 tpack 是这周的两个新公式， 都做的是"把以前很重的依赖，降成随手一装就能用的东西"。

atoll / dockspace：刘海成了新桌面，dock 成了新画布

┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  ░░░░░░░░░░░░░░░ NOTCH ░░░░░░░░░░░░░░░░░                     │
│  ░  ⏱ 10:32  |  🎵 Now Playing  |  ⏰ 14:00  ░               │
│  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░                    │
│                                                              │
│              Your normal macOS desktop                       │
│                                                              │
│  ┌────┐  ┌────┐  ┌────┐  ┌────┐  ┌────┐                     │
│  │📅  │  │🎵  │  │💬  │  │⏰  │  │🌤  │ ← Dockspace widgets   │
│  └────┘  └────┘  └────┘  └────┘  └────┘                     │
│   Dock not replaced — augmented                              │
└──────────────────────────────────────────────────────────────┘

两个工具，一周内同时进 cask，都在做同一件事： 把 macOS 默认"留白"的位置，改成可编程的表面。

atoll——把 MacBook 那个被吐槽很多年的刘海，变成 iPhone 风格的 Dynamic Island。 时钟、正在播放、日程提醒，可以放进去。本地原生应用，不是 Bartender 那种"藏起来"的逻辑。

dockspace——往 Dock 里塞 widget。官方截图展示了日历、播放器、时钟、计算器等小组件， Dock 从"应用启动器"变成"信息面板"。

两个工具都依赖 macOS :sonoma 及以上，都借助 SwiftUI / AppKit 那种新框架的能力。 普通用户大概率用不上——但它们在试探一件事： "操作系统留下的视觉空白，是不是可以变成有 API 的产品？" Jellyfish、Useless Apps 一类的小工具曾经填过这个生态位， 现在这个赛道被正经工程化了。

openhuman：又一个"个人 AI 助手"进场，这次强调"local memory"

┌────────────────────────────────────────────┐
│  OpenHuman                                 │
├────────────────────────────────────────────┤
│  • Local memory (no cloud sync required)   │
│  • Integrations: Calendar / Mail / Files   │
│  • Mac + Linux (AppImage / DMG)            │
│  • 0.58.0 — first stable line              │
└────────────────────────────────────────────┘

openhuman 0.58.0 在本周进 cask。 描述是 "Personal AI assistant with local memory and integrations"——

和上周的 maestri、vibeproxy 一样，属于"私人 AI 工作台"赛道。 但 openhuman 的差异化点是"local memory"——把上下文和偏好存在本地， 不让它去云端做训练。

这和上上周的 speech（本地语音工具包）， 和上上周的 mimo-code（带跨会话记忆的编码 Agent）是同一条线： Agent 越来越私人化、越来越本地化。 openhuman 走的是"日常助理"那条路，不是"编码 Agent"。

0.58 是第一个稳定线版本， 意味着它已经过了"个人项目"的早期阶段， 正式进 brew 那个"每周可装"的位置了。

趋势观察：Mirror 清理是这周的暗线

这次没拉几个 commit message， 但本周 homebrew-core 的 commit 里， 出现频率最高的动词不是 "bump"， 是 "remove mirror"。

涉及的工具包括：

• apache-drill、sbt、erlang@27、popt、yasm、fortune、caca、libstatgrab、ffms2、libcaca、libpng、tcl-tk@8、unixodbc、nghttp2、snort、aerc、icarus-verilog、cxxtest、scrub、[email protected]、[email protected]、reop (deprecated)
• 大量 mysql 时代之前的工具：proftpd、daq、oath-toolkit、s-lang、mpich、xrootd、libpq (用 readline)、vamp-plugin-sdk (改 url)

这是 2026 年中一个很具体的趋势： 十年前 brew 的镜像系统是为了"避开 GitHub 限速 / 跨区域断网"， 现在 GitHub Actions + ghcr + Apple Silicon 的存在让这个逻辑过时了。 镜像在变成"一个过期了的间接层"。

reop 干脆被标记 deprecated，理由是"use alternative urls"—— 以前 brew 会替你维护"fallback"， 现在 brew 直接告诉你"去找上游"。

这是 brew 在收紧"我替你处理了什么"这件事。 Homebrew 6.0 引入 tap trust 是上半年的标志事件， 这一周的 mirror 清理是同一逻辑的延续： 不再替你假设你信任哪个源，不再替你做 fallback 决策。

一点个人感受

新公式只有两位，反而让我对 brew 的"入口价值"重新有了感受—— 每周成百上千的 PR，真正"值得为它写一段描述"的，不到十个。 这十个里又有大半是"替换某个旧工具"而不是"从无到有"。 从无到有的新工具，越来越少了；把旧工具拆掉重做的，越来越多了。

tpack 是"tpm 的现代版"， slint-cpp 是"Qt 的轻量替代"， atoll 是"刘海本来是浪费，我们来用上"， dockspace 是"dock 本来是启动器，我们来做画布"。

每个新工具都在说同一句话：**"我比它好，因为我更懂 2026 年的电脑。"**

openhuman 那一类本地 AI 助手的出现频率在加快。 上上周 mimo-code、上周 maestri、本周 openhuman—— 私人 AI 助手的"基础设施期"正在收尾， 接下来应该会看到合并潮：能撑过 1.0 的、会被留下来。 撑不过的，会变成 github.com 上那些 archive 的仓库。

我这一周最希望装的大概是 tpack—— 因为我每天 prefix + I 的速度，说明我真需要它。

结语

这周 brew 的 commit 列表像一条安静的河。 新工具是河面上的小船，镜像清理是河底的泥沙在重新分布。

工具在变轻，信任在收紧，本地化在变重。 一周只有两个新公式，也是一种信号—— 也许该让旧东西先回家，新东西不用那么着急。

1. 首先安装Obsidian Wiki

推荐安装方式：

pip install obsidian-wiki
obsidian-wiki setup --vault /path/to/your/digital/brain

安装完成后，在Obsidian目录执行：

obsidian-wiki setup --project .

然后提示🔔：

Where is your Obsidian vault? (absolute path):

输入Obsidian目录的绝对路径。

2. AI Agent 初始化项目

再启动AI Agent，直接输入：“set up my wiki”

这样，就会在AI Agent里面安装一系列Skills，以及在项目根目录初始化文档。

3. Obsidian 安装插件

上面的工作完成，就可以安装推荐的社区插件：

1. Dataview - 查询页面元数据、动态表格
2. Graph Analysis - 增强图表视图
3. Templater--手动页面模板
4. Obsidian Git - 自动备份

然后在 Obsidian 中打开项目。

4. AI Agent 操作

1. 运行 /wiki-status，查看可用内容和状态
2. 运行 /wiki-ingest，添加第一个源文件（使用 raw/ 目录）
3. 运行 /claude-history-ingest 挖掘你的对话历史
4. 运行 /wiki-lint — 验证刚种子化的 vault 是否有链接/前置元数据问题
5. 可选:运行 /wiki-dedup — 寻找可能的近重复页(此批为全新创建,可能无重复)
6. 可选:运行 /wiki-research <topic> — 对某项目深挖
7. 配置 QMD — 启用语义搜索,QMD_WIKI_COLLECTION 当前未设置

需要我安装可选的 "停止 "钩子吗？它会在你写文件或运行shell命令的会话结束时自动执行/wiki-capture--quick--方便你捕捉发现，而无需手动操作。

除了 obsidian-wiki，本身官方还推荐配合一套 Obsidian Skills 使用。

Ref

• sdyckjq-lab/llm-wiki-skill: 基于 Karpathy llm-wiki 方法论的个人知识库构建 Skill，支持多平台！
• 用Obsidian打造LLM-Wiki经验分享 - 知乎
• 我用Obsidian + Codex 搭了一个会持续进化的AI知识库，保姆级教程来了 - 知乎
• nashsu/llm_wiki: LLM Wiki is a cross-platform desktop application that turns your documents into an organized, interlinked knowledge base — automatically. Instead of traditional RAG (retrieve-and-answer from scratch every time), the LLM incrementally builds and maintains a persistent wiki from your sources。
• llm-wiki
• 深度解析 LLM Wiki / Obsidian-Wiki / GBrain：Agent 时代知识的“自组织”与“自进化” - 老纪的技术唠嗑局 - 博客园
• Ar9av/obsidian-wiki: Framework for AI agents to build and maintain a digital brain through Obsidian wiki using Karpathy's LLM Wiki pattern
• InfraNodus AI Graph View - Obsidian Plugin
• noduslabs/infranodus-obsidian-plugin: Advanced graph view for Obsidian: text analysis, topic modeling, and AI with InfraNodus AI text analysis tool: https://infranodus.com

⚠️ Suggestions 提醒

大量冗余的MCP

毫无作用的Agent

以及用不上的Skills

Skills 实在太多就不一一截图。

核心优化以下几条：

• /compact 不要盲目压缩，带参数。Claude 会把冗长繁琐的聊天、报错日志、排错过程打包压缩成一段极简的结构化摘要，删掉废话，仅保留当前任务的上下文状态，瞬间释放几十 KB 的空间。
• /skills 关闭不用的skills
• /mcp 关闭不用的mcp
• /memory 编辑CLAUDE.md文件，写好当前的会话要求、运行时建议和一些特殊处理的注意事项。e.g. Suggestions 中提到Bash操作占用了大量的token，那么可以限制Bash操作或者使用子代理进行
• /clean 开启新的会话
• /btw 创建一个一次性的临时分支对话，Claude 回答完后，这个对话不会被存入主干的上下文 history 中，减少Token 消耗

最开始很喜欢Cursor的开发体验，感觉所见即所得：

• 可以非常快速的选中代码，然后扔给它解决；
• 也可以截图，然后交给它生成UI；
• 每一个步骤都可以反复修改，不用记命令，直接GUI上操作；
• ...

看着Cursor自动化操作，有一种赏心悦目的感觉。

不过，体验Claude Code之后，这些发生变化。

我不再纠结是否拥有GUI，只看重结果和推理过程中产出的东西是否有价值。

Claude Code做得很好，至少目前看来很强。

我主要做前端开发，经常需要与UI界面打交道，

如果AI不能自主识别UI，会给我造成非常大的困扰。

所以，普通的文本模型基本对我没啥用。

至少是，多模态模型，支持文本/图像/视频，并且还能推理和编程。

不得不说，开源大模型与商业模型还有差一段路。

绝大多数开源大模型仅仅是文本模型，或者是某种单一模型，只支持图像或视频，无法支持多模态工作。

零星有一些支持多模态的开源模型，性能较普通，根本不能用来工作生产。

并且，这些模型的部署条件，对硬件要求颇高，不是普通开发者能消费。

回到Claude Code这里来，这是目前验证过，能支持工作生产的AI工具。

Claude Code严格意义上说，是一个Agent。其背后的官方大模型有：

• claude-sonnet
• claude-opus

以上是经常用的，4.6/4.7都不错。绝大部分情况下优先使用sonnet，遇到复杂问题要么opus，要么自己思考。

Claude Code也支持其他厂商的模型，具体有什么要求，暂时不得而知。

总之，那些性能低、不具备多模态的模型，是不能接入到Claude Code。

...

先聊这么多，我再想想有什么可说的。