不是 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 这一侧靠拢。

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

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

不是新模型,也不是新框架,就是补那一个动作:让 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，后续出现更诡异的事情。🤦

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

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

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

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

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带来的泡沫

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

新公式只来了两位——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、scala@2.12、scala@2.13、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 列表像一条安静的河。
新工具是河面上的小船，镜像清理是河底的泥沙在重新分布。

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

推荐安装方式：

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 — 对某项目深挖
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 消耗

从 5.1 跳到 6.0，Homebrew 悄悄加了一个叫 tap trust 的东西。
你装了很久的那些 tap，现在需要你主动"信任"才行。
基础设施在变，而工具列表里，Agent 还在继续进场。
只是这次，有人开始为 Agent 建隔离间了。

本周一句话总结

Agent 越来越多，隔离成了新的基础设施需求。

Homebrew 6.0：tap trust 来了

这周 Homebrew 从 5.1.14 升到了 6.0.1，最显眼的变化是 tap trust 机制。

以前 brew tap user/repo 之后，那个 tap 里的公式就直接能用。
现在，未经信任的 tap 会被忽略——brew 升级后会看到大量这类警告：

Warning: Skipping buo/cask-upgrade because it is not trusted.
Run `brew trust buo/cask-upgrade` to trust it.

信任单个公式、cask 或命令：

brew trust --formula user/tap/formula
brew trust --cask user/tap/cask

信任整个 tap：

brew trust user/tap

这是一个供应链安全向的变化。Homebrew 官方公式是可信的，
但第三方 tap 历来是盲区——任何人都能发布，你装了就装了。
tap trust 把这个决策显式化：你需要告诉 brew，你信任谁。

如果你有在用第三方 tap（比如 buo/cask-upgrade、iina/mpv-iina），
升级后记得手动跑一遍信任命令，否则它们会静默失效。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

container-use：给 Agent 建隔离间，而不是盼它自觉

让多个编码 Agent 并行工作，一直存在一个隐患：
它们会互相踩脚——共享文件系统、共享 git 状态、某个 Agent 的操作污染了另一个的上下文。

container-use 的答案是：每个 Agent 给它一个干净的容器，跑在独立的 git branch 里。
底层是 Dagger（容器化工作流）+ git worktree，两者组合解决了隔离的两个维度：
文件系统和代码状态。

┌─────────────────────────────────────────────────────┐
│  container-use — isolated envs for coding agents    │
├──────────────┬──────────────┬───────────────────────┤
│  Agent A     │  Agent B     │  Agent C              │
│  branch-a    │  branch-b    │  branch-c             │
│  container   │  container   │  container            │
│  [running]   │  [running]   │  [idle]               │
├──────────────┴──────────────┴───────────────────────┤
│  git worktrees + Dagger containers                  │
│  Complete isolation · Full logs · Drop-in terminal  │
└─────────────────────────────────────────────────────┘

更值得关注的是它的可见性设计：
完整的命令历史和日志，你可以随时 git checkout <branch> 看结果，
出问题的容器直接丢掉重开，也可以 drop into 那个环境直接调试。

它省掉的是"Agent 在跑，但我不知道它在哪儿搞了什么"的不安全感。

concord：Discord 住进了终端

Discord 有官方客户端，但官方客户端需要 Electron，要内存，要 GPU，
在一台只挂着 SSH 的服务器上或者注意力高度集中的终端会话里，它格格不入。

concord 是 Rust + ratatui 写的 Discord TUI——
频道列表、消息历史、发送消息、@提及自动补全、自定义表情、文件上传下载、
线程、论坛频道、Kitty/iTerm2/Sixel 图片渲染、语音频道……
内存通常在 20–40 MB。

它有点令人意外的精致。不只是"能用"，是真的在认真还原 Discord 体验，
包括语法高亮的代码块渲染和 vim 风格键位。

如果你日常工作都在终端里，这是一个你可能不知道自己想要的东西。

speech：Apple Silicon 的本地语音工具包，终于能用了

Apple Silicon 有 Neural Engine，有 CoreML，有原生语音框架——
但要把这些能力拼成一条完整的"语音输入 → 文字 → 说话人 → 输出语音"的管道，
一直需要自己写胶水代码。

speech 这个工具包把它打包好了：

• ASR（自动语音识别）：支持 52 种语言的 Qwen3-ASR、25 种语言的 Parakeet TDT、支持 1,672 种语言的 Omnilingual
• TTS（文字转语音）：Kokoro（82M 参数）、CosyVoice（声音克隆）、最长 90 分钟播客合成
• VAD（语音活动检测）：Silero 流式检测、Pyannote 离线
• Diarization（说话人分离）：回答"谁什么时候说话"

全部跑在本地，不需要 API key，数据不出设备。
Swift 6 写的，需要 Apple Silicon（M1–M4）。

macparakeet 和 buzz 上周出现，macOS 26 来了本地语音转写的 API 改进——
这个品类今年扎堆出现不是巧合，是 Apple Silicon 的算力终于跑到这条线上了。

wx-cli：微信数据 CLI，这个有点意思

一行描述：WeChat 4.x local data CLI with daemon architecture。

微信 4.x 把消息和数据存在本地，但没有任何官方的 CLI 或 API 接口供开发者访问。
wx-cli 把这个缺口补了——可以用命令行读取本地微信数据，
守护进程架构意味着它能在后台持续运行、响应查询。

用途想象一下：备份聊天记录、搜索历史消息、把微信数据导出给其他工具处理。
不是所有人都需要，但需要的人会很需要。

一点个人感受

Homebrew 6.0 的 tap trust 我第一反应是麻烦，
但想一想，这其实是它应该做的事：
把"我信任这个来源"的决定还给用户，而不是默认全信。
装完 brew 升级之后花 2 分钟跑一遍 brew trust，值得。

container-use 和 splitrail 同时出现——
一个是给 Agent 建隔离环境，一个是监控 Agent 的 token 消耗。
加上上上周的 codeburn、上周的 gnhf，
这条"Agent 基础设施"的产品线正在快速变得完整。

speech 是那种"迟早会成为标配"的工具。
Apple Silicon 的语音能力一直在这里，只是没有统一的 CLI 接口。
现在有了，接下来就是等它被各种工具集成。

concord 让我想起 mutt——
有人坚持在终端里读邮件，有人会坚持在终端里上 Discord，
理由一样：注意力不被打断。

结语

这周的关键词是"隔离"——
Homebrew 在 tap 层面要求显式信任，
container-use 给 Agent 加了容器隔壁，
speech 让语音处理不出本地。

边界在收紧，不是因为不信任，而是因为信任需要被明确。

越来越多的东西在本地跑，这不是退步，是一种选择。

"Vim 8 long term support version with no LLM-generated code"

这不是功能描述，是一种表态。
就好像某家餐厅在门口挂出"不用味精"的牌子——
这家餐厅要传达的，不只是关于味精。

本周一句话总结

工具还在进场，但边界开始出现了。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这周有一个我从没见过的措辞出现在 Homebrew 里。
它让其他几个工具都显得更值得一看了。

vim-classic：一行描述，一种立场

brew info vim-classic 只有一行核心描述：
"Vim 8 long term support version with no LLM-generated code"

"no LLM-generated code"——这在工具的官方元数据里出现，是我第一次见到。

这不是在说 LLM 生成的代码质量不好。
它说的是一种可追溯性：每一行代码，作者都清楚它从哪儿来、为什么在这里。
Vim 8 已经是功能意义上的成品，它不需要新功能，只需要有人认真维护。
vim-classic 的选择是用人的判断来做这件事，而不是借助辅助生成。

你可能不需要 vim-classic。Neovim 更好、vim 够用。
但它的出现本身是一个信号：
当 LLM-assisted 成为默认时，"手写"开始变成一种需要声明的特性，就像"有机"或"手工"一样。

这种逻辑早晚会蔓延到更多地方。

ec：终于有人把三路 merge 做成 TUI 了

三路 merge 是 git 里最让人头疼的一环。
git mergetool 默认弹出 vimdiff 或者你随便配的编辑器，
多数人要么不知道怎么用，要么每次都要重新想"左边是我的还是他的"。

┌─────────────────────────────────────────────┐
│  ec — TUI 3-way git mergetool               │
├───────────────┬───────────┬─────────────────┤
│   LOCAL       │   BASE    │   REMOTE        │
│               │           │                 │
│ func foo() {  │ func foo  │ func foo() {    │
│   return 1    │  () {     │   return 2      │
│ }             │   return  │ }               │
│               │   0       │                 │
│               │ }         │                 │
├───────────────┴───────────┴─────────────────┤
│  MERGED OUTPUT                              │
│  func foo() {                               │
│    return ▌                                 │
│  }                                          │
└─────────────────────────────────────────────┘
  ← → 切换块   Space 选择   Enter 应用   q 退出

ec 做的事很简单：把 LOCAL / BASE / REMOTE 三路放在 TUI 里并排，
让你用键盘选择每个冲突块应该用哪个版本，然后输出 MERGED。
它省掉的，是"看着 <<< === >>> 手动对齐"那种脑力消耗。

rura：shell 管道的草稿本

很多人不知道自己其实需要一个"管道调试器"——
直到他们写出了 cat file | grep foo | awk '{print $2}' | sort | uniq -c | sort -rn 这样一条命令，
然后发现根本不知道哪一步开始出错了。

rura 是个 TUI 便签本：你在里面一段一段地搭 pipeline，
每加一步都能即时看到那一步的输出，
错了就改那一步，不用每次都重跑整条命令。

┌─────────────────────────────────────────────┐
│  rura — shell pipeline scratchpad           │
├─────────────────────────────────────────────┤
│  INPUT                                      │
│  cat access.log                             │
├─────────────────────────────────────────────┤
│  STEP 1  grep "404"          [42 lines]     │
│  STEP 2  awk '{print $7}'    [42 lines] ▲   │
│  STEP 3▌ sort | uniq -c      [editing...]   │
├─────────────────────────────────────────────┤
│  PREVIEW                                    │
│    128 /api/missing                         │
│     43 /favicon.ico                         │
│      7 /admin/login                         │
└─────────────────────────────────────────────┘

它不是 shell 的替代品，是 shell 的草稿纸。
它省掉的是那种"我不确定这一步对不对，但也不想重跑一遍"的犹豫。

rmux：tmux 的精简重写，带守护进程运行时

tmux 很好，但配置文件那几百行、插件生态、偶尔出问题时的调试——
对于"我只是需要一个会话持久化的终端分窗"来说，有点重了。

rmux 的定位是：tmux 的 CLI 风格，更简单的守护进程模型。
你依然用 rmux new -s myproject、rmux attach -t myproject 这种命令，
但它的守护进程从设计上更轻，更容易推理。

这不是要取代 tmux 的项目。
它是"我知道 tmux 能做到，但我只需要 20% 的那个人"的选项。

一点个人感受

bun 终于进了 homebrew/core，而不是只在 tap 里。
这件事本身不大，但标志着它已经不是"新东西"了。

kimi-code 进场了——Moonshot AI 的编码 Agent 加入了 Claude Code、Codex、Gemini CLI 的行列。
现在 Homebrew 里的 AI 编码 Agent 已经有七八个了，
我有点好奇大家到底在用哪几个、或者全都在用。

vim-classic 是这周我想得最久的。
不是因为我会用它，而是因为它的描述方式让我意识到：
"这段代码是人写的"正在从隐含假设变成需要被声明的事。
这个转变发生得比我想象的快。

macparakeet 和 buzz——本地语音转录这个品类今年明显多了。
不知道是 M4 芯片快到了足够跑的程度，还是大家开始认真对待隐私。
或者两者都有。

结语

这一周没有爆炸性的工具，但有一行描述让我觉得这期值得写。

"no LLM-generated code"——四个词，一条隐形的分界线。
它出现在一个 Vim 的 fork 里，出现在 2026 年，
这件事本身比任何新 AI Agent 都更值得记下来。

当默认值发生变化，反其道而行就变成了一种声明。

但是，由于Claude/ChatGPT对国内ip封锁非常严厉，需要开启TUN模式和fakeip功能。

在公司内部需要兼顾内外2套网络，因此必须配置DNS。

有一说一，Clash的配置文档太长了，实在不想读。

到现在才稍微明白一些配置项的含义。

有时候感觉 Clash Verge Rev 的GUI非常难懂，感觉与自己写yaml有很大区别。

一些网络上看到的简易配置，根本无法使用。

下面记录一下配置的关键。

DNS覆写

1. 打开“DNS覆写”

2. 打开“启用DNS”

点击“高级”，将下面的配置粘贴进去：

# Clash Verge DNS 配置
# 企业内网 + 公网 DoH 混合解析方案
dns:
  # 启用 Clash 内置 DNS 服务
  enable: true
  # 监听本机 53 端口
  listen: ':53'
  # Fake-IP 模式，便于域名规则匹配
  enhanced-mode: 'fake-ip'
  # Fake-IP 地址池
  fake-ip-range: '198.18.0.1/16'
  # 黑名单中的域名不使用 Fake-IP
  fake-ip-filter-mode: 'blacklist'
  # 是否优先使用 HTTP/3
  prefer-h3: true
  # DNS 查询遵循 Clash 规则
  respect-rules: true
  # 使用配置中的 hosts
  use-hosts: true
  # 不读取系统 hosts 文件
  use-system-hosts: true
  # 启用 IPv6 DNS 解析
  ipv6: true
  # 以下域名返回真实 IP，避免 Fake-IP 导致异常
  fake-ip-filter:
    # 局域网、本地服务、网络探测等域名不走 Fake-IP
    - '*.lan'
    - '*.local'
    - '*.arpa'
    - 'time.*.com'
    - 'ntp.*.com'
    - 'time.*.com'
    - '+.market.xiaomi.com'
    - 'localhost.ptlogin2.qq.com'
    - '*.msftncsi.com'
    - 'www.msftconnecttest.com'
  # 用于解析 DNS 服务器自身域名
  default-nameserver:
    # system 表示使用系统 DNS，其余为备用解析器
    - 'system'
    - '223.6.6.6'
    - '10.139.1.142'
    - '10.139.1.143'
    - '114.114.114.114'
    - '8.8.8.8'
    - '2400:3200::1'
    - '2001:4860:4860::8888'
  # 默认公网 DNS（代理流量）
  nameserver:
    # Google DNS + 腾讯 DoH + 阿里 DoH
    - '8.8.8.8'
    - 'https://doh.pub/dns-query'
    - 'https://dns.alidns.com/dns-query'
  # direct-nameserver 是否跟随 nameserver-policy
  direct-nameserver-follow-policy: false
  # fallback DNS 过滤规则（当前未启用 fallback）
  fallback-filter:
    geoip: true
    geoip-code: 'CN'
    ipcidr:
      - '240.0.0.0/4'
      - '0.0.0.0/32'
    domain:
      - '+.google.com'
      - '+.facebook.com'
      - '+.youtube.com'
  # 备用 DNS，留空表示关闭
  fallback: []
  # 用于解析代理节点服务器域名
  proxy-server-nameserver:
    - 'https://doh.pub/dns-query'
    - 'https://dns.alidns.com/dns-query'
    - 'tls://223.5.5.5'
  # DIRECT 流量专用 DNS（企业内网 DNS）
  direct-nameserver: 
    # VPN/办公网络下可访问的企业 DNS
    - 10.139.1.142
    - 10.139.1.143
  # 企业域名强制使用内部 DNS 解析
  nameserver-policy:
    '+.zhongan.com':
      - 10.139.1.142
      - 10.139.1.143
    '+.zhonganonline.com':
      - 10.139.1.142
      - 10.139.1.143
    '+.zhonganinfo.com':
      - 10.139.1.142
      - 10.139.1.143
    '+.za.biz':
      - 10.139.1.142
      - 10.139.1.143
    '+.za-tech.net':
      - 10.139.1.142
      - 10.139.1.143

编辑规则

点击“高级”，将将下面的配置粘贴进去：

prepend:
  - 'IP-CIDR,10.0.0.0/8,DIRECT,no-resolve'
  - 'IP-CIDR,172.16.0.0/12,DIRECT,no-resolve'
  - 'IP-CIDR,192.168.0.0/16,DIRECT,no-resolve'
  - 'DOMAIN-SUFFIX,za-tech.net,DIRECT'
  - 'DOMAIN-SUFFIX,za.biz,DIRECT'
  - 'DOMAIN-SUFFIX,zhonganinfo.com,DIRECT'
  - 'DOMAIN-SUFFIX,zhonganonline.com,DIRECT'
  - 'DOMAIN-SUFFIX,zhongan.com,DIRECT'
append: []
delete: []

Ref

• 在线订阅转换
• SubBoost - Clash 订阅转换与管理服务
• 关于"DNS 覆写" 和其内的 "启用DNS"
• [BUG] clash-verge-rev 会自动定时覆盖系统的DNS为223.5.5.5
• MacOS - Clash Verge Rev Docs
• 自定义脚本 - Clash Verge Rev Docs
• 请教下 clash 的 DNS 是这么配置么？ - V2EX
• mihomo/docs/config.yaml at Meta · MetaCubeX/mihomo
• 配置 - 虚空终端 Docs
• [BUG] DNS覆写，使用系统 Hosts 无效 · Issue #3608 · clash-verge-rev/clash-verge-rev

Error Message：

“You do not appear to be connected to Wi-Fi and/or LocalDevVPN!
SideStore cannot install or refresh applications without Wi-Fi and LocalDevVPN. If both are connected, replace your pairing with iloader.”

“Make sure LocalDevVPN is connected and that you are connected to any Wi-Fi network!”

Error Code：

“SideStore.OperationError 1414”

遂，网上查找解决方法。

SideStore issues 里面有许多人反馈这个问题，大概在3月份的时候，就有人遇到这个问题，大都是iOS26.4beta版本。

评论区中提到#1174有临时解决方案。

打开1174的帖子看了下，或许能解决，但是挺玄学，不太靠谱。而且依赖“Adguard VPN”、“VPN Super”这些支持 IKEv2/IPSec 的 VPN。

有人不认可这个方式，提出了质疑。

就算没人质疑，我也不打算用这么戳的方式。😜

事情到这里，似乎被卡住了。

仔细想想🤔，其实有2个路径解决这个问题：

1. 如上面所说，使用支持 IKEv2/IPSec 的 VPN；
2. 根据报错信息可知，是LocalDevVPN未连接成功导致；

然后我想到了idevice_pair。

记得在我初次使用SideStore时，就是使用idevice_pair管理iOS设备配对。依稀记得SideStore与iOS配对成功后，再打开LocalDevVPN，就可以刷新应用。

由于我安装的是LiveContainer+SideStore(内嵌)版本，所以又去LiveContainer issues找了下相关问题，果不其然，也有人反馈了。iOS 26.4 compatibility & App Refreshing

在评论中有人提到了 rppairing，

但是怎么操作，还是让人一头雾水。

最后参考这个评论，去b站看了下视频，就完美解决了。✌️

最后弄好后，

Ref

• Refresh not working on ios 26.4 · Issue #1295 · LiveContainer/LiveContainer
• iOS 26.4+｜LiveContainer 现已支持 RPPairing 使用教程_哔哩哔哩_bilibili
• [BUG] · Issue #1223 · SideStore/SideStore
• [BUG] 26.4 beta 2 can't refresh, update or deactivate. · Issue #1194 · SideStore/SideStore
  iOS 26.4 compatibility & App Refreshing · Issue #1152 · LiveContainer/LiveContainer
• [BUG] ios26.4 can't refresh apps · Issue #1174 · SideStore/SideStore
• [BUG] Bug with iOS 26.4 · Issue #1222 · SideStore/SideStore
• Releases · jkcoxson/idevice_pair

上一周大家还在补 Agent 的水电煤，
这一周开始有人琢磨：Agent 到底应该住在哪里、
模型到底应该跑在哪里。

答案变得不太一样了——
Agent 跑去了刘海下面，模型住进了 Mac 自己。

本周一句话总结

Agent 不再只在终端里抢注意力，模型也不再默认住在云端。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一周值得停下来看的东西不少。
选四个：一个是终端长出眼睛，一个是 Agent 长出表情，
一个是老 whois 终于不再难看，一个是趋势——Mac 自己开始跑模型了。

ratty：终端模拟器开始往里塞 3D 了

ratty 是 Orhun（写过 ratatui、tui-rs 的那位）做的新东西，定义很大胆：
GPU 渲染的终端模拟器，支持在终端里 inline 显示 3D 内容。

听上去像噱头，但 demo 里它真的就能在 cat 文档的中间嵌一个会转的 3D 模型，
也能左边一个 2D 画布、右边一个实时 3D 预览，全都还在你那块终端窗口里。
甚至有人在它上面写了个 endless runner 小游戏，跑在终端里。

它解决的不是什么生产力问题。
它解决的是"终端从 1970 年代起就只会显示字符"这个隐含假设——
当 GPU 已经能干得起所有事，终端没理由继续假装自己是一台 VT100。

值不值得用是另一回事。但作为一种姿态它很有意思：
终端是不是该升级一下定义了。

ping-island：把 Agent 状态搬进 macOS 的刘海

如果你同时挂着两三个 Claude Code、再加一个 Codex 在跑，
你大概率经历过这种情况：切回去看一眼，发现某个 Agent 在十分钟前就停下来等你确认了。

ping-island 直接把 macOS 刘海（Dynamic Island）那一小块拿来当 Agent 的状态栏。
平时它静悄悄缩在那儿，
某个 Agent 需要批准、需要输入、需要 review，它就在刘海下面展开。
你可以直接在那个小弹层里同意 / 拒绝工具调用，
不用切换终端、不用翻 IDE 标签页。

更妙的是它给每个 Agent 都配了一个 mascot——
Claude、Codex、Gemini、Hermes、Qwen、Cursor、Copilot 各自一个像素小动物。
这听上去像玩笑，但当你脑子里同时有三个会话时，
"哪个动物在叫"比"哪个 PID 在等"更容易认。

它替你省的，是那种"我以为它在干活其实它在等我"的尴尬。

quien：whois 终于不再是一坨纯文本了

很多人不知道 RDAP 已经基本取代了 WHOIS。
新协议返回的是结构化 JSON，而不是 80 年代的自由格式文本。
但大多数人手里的 whois 命令还是那个老 whois，
查出来一坨参差不齐的字段，自己拿眼看。

quien 把这件事重做了一遍。
它是个 TUI，开起来一组标签页：
WHOIS、DNS（A/AAAA/CNAME/MX/NS/TXT/PTR/SOA + DNSSEC）、
Mail（SPF / DMARC / DKIM / BIMI 与 VMC 链）、
SSL/TLS（证书、SAN、过期）、HTTP（响应头，安全相关的优先）、
SEO（含可选的 Core Web Vitals）、Stack（CMS、WordPress 插件、JS/CSS 框架探测）。

更贴心的是 ssh quien.sh 就能直接在线试，不装也行。

它不是某种"提效工具"。它是把"查个域名"这件本来就不该是体力活的事，
还原回它该有的样子：一次查询，一组完整的画像。

趋势观察：Mac 这周开始正经当推理服务器了

把 cask 列表里这几个连起来看就很有意思：

• exo：把本机几台 Apple Silicon 拼成一个本地推理集群，
  自动发现拓扑、按内存和带宽切模型。文档里提了一句
  "8 µs latency with RDMA over Thunderbolt 5"——
  你那条没在用的雷电 5 线突然变成了模型并行的总线。
• mirai：本地推理引擎，需要 macOS 26+。
• vmlx：在 Apple Silicon 上跑本地 AI 模型，基于 MLX。

加上之前的 Ollama、LM Studio，这周终于能感觉到一个变化：
Apple Silicon 不只是被动地能跑模型，是开始有人专门为它做基础设施。

集群、引擎、调度、调用 API 兼容层（exo 兼容 OpenAI/Claude/Responses/Ollama）。
这套以前是 Linux GPU 服务器的专属形态。
现在你那台不开机的 Mac mini，可能比一张 4090 更值得保留。

云端推理还会是主流，但"我家这几台 Mac 就够用"
开始从极客的浪漫变成可以装出来的工程方案。

一点个人感受

ratty 我大概率不会换，但我会去看那个 3D demo 视频几遍——
它让我重新意识到终端这个东西其实挺旧的。

ping-island 是这周我最想试的。
不是因为多花哨，而是它把"Agent 在等我"这件事
从"我得记得切回去看"变成"它会自己叫我"。
这种从 pull 到 push 的小变化，看上去无聊，用过就回不去。

quien 我会替换掉系统自带的 whois。
没什么戏剧性，纯粹是 90 年代工具被认真重做了一次。

exo 让我有点恍惚。
两年前你跟人说"我家几台 Mac 拼起来跑 70B"，对方会觉得你在表演。
现在它已经是一个有官网、有 API 兼容层、有 Thunderbolt 5 RDMA 优化的产品。

结语

这一周看下来有种隐隐的感觉：
AI 不是又往云上漂走了一点，而是悄悄往本地、往边缘、往"我手边这台机器"再回了一点。

工具会替你打开新世界，也会替你重新发现旧设备。

真正的本地化，是连刘海都开始派上用场。

五月底的列表里，AI 已经不再是新东西。
真正变新的，是它周围那一圈"配套设施"——
计费的、调度的、围墙的、防扒手的。

本周一句话总结

Agent 已经过了"造出来就行"的阶段，进入了"得有人管它"的阶段。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一周的关键词不是"AI 又出了什么"，而是"AI 周围又长出了什么"。
挑四个停下来看一下。

codeburn：替你回答"我那张 AI 账单到底烧在哪儿了"

如果你同时挂着 Claude Code、Codex、Cursor、Copilot、Gemini CLI——这是 2026 年很多人的真实状态——
那你大概率已经放弃搞清楚每个月那笔 AI 开销到底花到哪了。

codeburn 的角度很务实：它不当 proxy，也不要 API key，
就是个本地的 CLI/TUI 仪表盘，从你磁盘上各家 Agent 的会话记录里读数据，
按任务、模型、工具、项目把 token 和费用切开给你看。

更狠的是 optimize 子命令——
它会指出"这个文件你在不同 session 里被读了 11 次"、"这个 MCP server 你装了但从没调用"、
"这个项目的 Read:Edit 比例失衡"这种你自己绝对不会注意到的浪费点。
它替你省的不是钱，是那种"我隐约觉得在烧钱但说不出在哪"的焦虑。

herdr：tmux 和 Agent 桌面端中间那一层，终于有人补上了

Desktop agent terminals give you app UI. tmux gives you persistence. Herdr sits between them.

这个 slogan 已经把它的位置说清楚了。

过去几个月，Agent 在终端里跑成了一种新工作流，
但你会发现 tmux 不知道哪个 pane 里的 Agent 在工作、哪个卡住了、哪个其实早就跑完了；
而 Cursor、Antigravity 这种桌面 IDE 又把你整套终端环境（shell、SSH、字体、键位）替换掉了。

herdr 的取舍是：保留你的终端，加一层 Agent 感知。
它能识别每个 pane 里跑的 Agent 处于 blocked / working / done / idle / unknown 哪种状态，
能在 workspace 维度做汇总，
能让 Agent 通过 newline-delimited JSON socket API 自己开 pane、跑命令、读输出。
甚至支持从手机 SSH 进来一个 thin client（herdr --remote workbox）继续盯着进度。

它替人省的是"我开了八个 Claude Code 现在到底哪个该看"的认知负载——
这听上去琐碎，但任何用过多 Agent 并行的人都知道这其实是真痛点。

miasma：当反 AI 抓取从抗议变成代码

robots.txt 这几年其实已经形同虚设。
有的爬虫不读，有的读了不当回事，有的干脆改 UA 装成浏览器。
普通博客作者的选择不多：要么挂 Cloudflare，要么认命。

miasma 给了第三种答案：喂毒。

机制很巧——你在页面里塞一些用户看不见、屏幕阅读器也会跳过的隐藏链接（display:none、aria-hidden、tabindex="-1"）；
正常人不会点，但抓取器会无脑跟进；
你的 nginx 把这些链接的请求反代到 miasma；
miasma 就开始无限喷投毒的训练语料，链接全是自指的，让爬虫掉进一个无穷循环。

你可以配 max-in-flight、link-count、max-depth，避免反 DDoS 自己；
也支持 --force-gzip 控制带宽成本。
作者的态度也直白："你不该花算力去对抗互联网上的水蛭。"

它代表的不是一个工具，是一种从"被动忍着"到"主动恶心回去"的姿态变化。
2026 年看这个会更明显。

rustnet：在 netstat 和 Wireshark 中间找到了一个新位置

这周 Rust TUI 工具仍然在持续涌现，rustnet 是其中比较扎实的一个。

它解决的问题是"per-process 网络连接观测"——
netstat 和 ss 能看到连接但不知道哪个进程，看不到实时流量；
Wireshark 和 tcpdump 能抓包但不告诉你是哪个进程在发；
rustnet 用 Linux eBPF、macOS PKTAP、Windows 原生 API，把每条 TCP/UDP/QUIC 流绑回它的进程。

它内置了 HTTPS（带 SNI）、DNS、SSH、QUIC、MQTT、BitTorrent、mDNS、DHCP 的解析，
不靠外部 dissector 就能看到协议层级；
默认走 sandbox（Linux 用 Landlock，macOS 用 Seatbelt），
libpcap 初始化完就放权限。
还支持 port: process: sni: 这种 vim/fzf 风格过滤。

它替人省的是"为了排查一个网络问题反复在 lsof、netstat、tcpdump 之间换工具"那种碎片感。

趋势观察：Agent 的"周边产业链"开始齐活了

把这周列表拉远一点看就很清楚——

• Agent 的 IDE：antigravity-ide（Google）、atomcode、grok-build（xAI）
• Agent 的运行时与多路复用：herdr
• Agent 的编排画布：maestri
• Agent 的工具层：executor
• Agent 的成本观测：codeburn
• Agent 的语言：zerolang（显式副作用、可预测内存）
• Agent 的反面：miasma（不让 AI 抓我）
• Agent 的伴侣化：airi（VTuber）

一周内同时出现"开发它的 IDE / 跑它的 runtime / 编排它的画布 / 算它账的仪表盘 / 给它专门设计的语言 / 拒绝它的反扒墙"，
这种密度本身就是一个信号：
Agent 已经不是 demo，是一个有上下游的生态了。

一点个人感受

我大概不会装 airi，也用不上 maestri 那种 macOS 26 才能跑的画布。
但 codeburn 和 herdr 我会留个印象——
前者是那种"现在还不痛但迟早会痛"的工具，
后者是那种"等我开第三个 Claude Code 窗口的时候就会想起来"的工具。

miasma 让我有点意外。
不是因为技术，是因为它出现在 Homebrew core，
而不是某个 self-hosted 圈子的小项目。
当一个反 AI 工具被打包进主流仓库，
你能感觉到大家对"无差别抓取"的耐心已经到底了。

zerolang 我没有展开讲——它太早，还没有定论。
但"为 Agent 设计一门语言"这句话本身值得记一下，
就像十年前有人开始说"为 GPU 设计一门语言"一样。

结语

工具列表越来越长，但有意思的部分变了。
以前有意思的是"又有一个新 AI 出来了"，
现在有意思的是"AI 周围有人开始修水管、装电表、围篱笆"。

这是一种健康的信号：水电煤齐了，热闹才刚开始。

真正成熟的不是 Agent 本身，而是它需要的那一切日常基础设施。

有些工具是为了跑得更快；有些工具是为了记住跑过哪里。
这周的新增偏向后者——不是 CLI 工具突然变多了，
是 AI 编程的上下文管理开始有了自己的工具链。

本周一句话总结

AI 编程从"写"进入了"观察与编排"的阶段——这周入库的工具，超过一半在帮你理解已经发生的事。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一节不求全，
只挑 3 个 值得停下来看的点。

agentsview：AI 编程的"回放键"终于来了

用 Claude Code、Cursor、Codex 写了几个月代码——你记得上周三用 agent 干了什么吗？

大概率不记得。这不是记性问题，是 AI 编程产生了一种新的历史：不是 git log，不是 IDE 历史记录，而是"我跟 agent 说过什么、agent 做了什么"。这段历史一直散落在各工具的本地缓存里，没有人帮你整理。

agentsview 做的就是这件事。它把 Claude Code、Codex、Gemini、Copilot、Cursor 等 20 个 agent 的会话历史统一读进来，全文索引，可以按项目、按工具、按时间筛，支持 token 用量和费用报表，号称比同类工具快 80-220 倍。

真正让我觉得有意思的是它的定位：local-first，SQLite，不联网，不注册账号。它没有试图成为一个 SaaS，而是选择把你的历史还给你自己。这在满地"云端同步"的工具里显得有点反常，但可能是对的。

gascity：多 Agent 编排，从玩具变成水管

以前协调多个 AI agent 同时工作，基本靠自己写 shell 脚本拼凑。gascity 想干的事情是把这层"水管"标准化——用一个 city.toml 声明你想跑哪些 agent、用什么运行时（tmux、子进程、Kubernetes），剩下的路由、状态同步、健康监控交给它。

底层依赖 beads（自家的任务跟踪）、dolt（可版本控制的数据库）、tmux、jq，整个项目用 Go 写，CLI 叫 gc。设计上走"原语优先"——不提供高层抽象，提供足够小的积木让你自己组。

这个工具现在刚进 Homebrew，安装量还是两位数。但它试图解决的问题——多 agent 编排的可复现性和可观测性——是真实存在的。随着 agent 场景从单机变成集群，这类基础设施迟早会有人需要。

fallow：代码库的"体检报告"

TypeScript/JavaScript 项目用久了之后，总会有一些"可能没人用了但谁也不敢删"的代码。fallow 的核心主张是：静态分析告诉你"什么可以删"，运行时数据告诉你"什么安全删"。

npx fallow dead-code 扫出没用到的文件和导出；npx fallow dupes 找重复逻辑；npx fallow health 给复杂度热力图。静态能力开源免费，运行时那层是付费的。

有趣的是它支持 MCP，可以接入 Claude Code 或 Cursor 的 agent 流程——这意味着它不只是一个跑完就算的 CLI，而是可以嵌进 AI 编程的工作循环里。

趋势小结：Agent 编程开始需要"配套设施"了

这周的三个 formulae/casks 指向同一件事——

agentsview 管历史，gascity 管协作，fallow 管代码质量。
这不是工具的堆叠，是 AI 编程从"我让 agent 写了一些代码"变成了"我需要管理 agent 做的事情"的信号。

以前 CLI 工具大量涌现是因为开发者在搭工作台；现在 agent 工具大量涌现，是因为 agent 本身开始需要一张工作台。

一点个人感受

gascity 和 agentsview 在同一周进入 Homebrew，我不确定是巧合还是某种时机。

agentsview 我可能会用——之前一直想找个办法回顾和 Claude Code 的对话历史，虽然现在有 /cost 和各种日志，但搜索还是很麻烦。local-first 的设计打消了我最大的顾虑。

gascity 和 github-copilot-app 都在 agent 编排这个方向，但路子完全不同：一个是工程师手搓的 Go CLI，一个是 GitHub 官方出的桌面应用。我对后者更好奇，尤其是它声称能"跨 agent 并行管理多个工作流"，但目前公开的细节还很少。

fallow 倒是让我想到了一个问题：AI agent 越来越擅长写代码之后，谁来负责清理 agent 留下的技术债？也许就是 fallow 这类工具。

结语

有些工具是锤子，看见钉子就用。
这周进来的工具更像是量尺——帮你看清楚已经发生了什么，才好决定下一步。

观察工具和使用工具，是两种不同的习惯。
但也许，后者越来越需要前者打底。

工具在变，但看懂工具在干什么，始终是你自己的事。

在Cline中使用Claude，享受GUI的乐趣。

随着时间的推移，发生了很多事情：

• Claude审查变得更加严苛
• Cline中使用Claude，频繁报错
  ...

然后，我开始逐渐适应在CLI工具中使用Claude。

自从开始使用AI Coding，总感觉设备的内存不够用，一直维持在80%以上的使用率。

日常基本就是，

• Chrome，非常吃内存
• iTerm，可接受
• VSCode，跟Chrome有得一拼

Chrome 重度使用，一时半会没有找到合适的平替，想迁移过去有点困难。

VSCode 基于Electron开发，多开几个tab，就能赶上Chrome了。

VSCode中，一些场景下会使用VI模式，例如：Code Review。

古法编程，看情况用，加上macOS上，触控板太好用了，没有很迫切转Vim。但，现在开始非常想使用nvim替代vscode，即装13又可节省内存。

况且，都使用AI Coding了，Review 和思考的时间居多，GUI没那么有趣了。

配置后的样子，

iTerm 配置

tmux 配置

# 安装 tmux
brew install tmux

# 配置 .tmux
git clone --single-branch https://github.com/gpakosz/.tmux.git "/path/to/oh-my-tmux"
mkdir -p ~/.config/tmux
ln -s /path/to/oh-my-tmux/.tmux.conf ~/.config/tmux/tmux.conf
cp /path/to/oh-my-tmux/.tmux.conf.local ~/.config/tmux/tmux.conf.local

配置完成后，执行：

tmux source-file ~/.config/tmux/tmux.conf

常用的快捷方式

• <prefix> e， 打开 .local 自定义文件
• <prefix> r，重新加载配置
• <prefix> m，开关鼠标模式
• <prefix> C-c，创建一个新会话
• <prefix> C-f，允许你按名称切换到另一个会话
• <prefix> Tab，进入最后一个活跃窗口
• <prefix> -，将当前窗格垂直分割
• <prefix> _，将当前窗格水平分割
• <prefix> h, <prefix> j, <prefix> k, <prefix> l，像 Vim 那样导航面板

“以上是 oh my tmux 提供的快捷方式”，其他快捷参考 tmux 官网。

这个视频挺不错👇

nvim 配置

略

Ref

• razeencheng/.tmux: Oh My Tmux! 我的tmux配置，以及相关设置。
• 我在 MacOS 上的完美 ghostty + tmux + nvim 配置 : r/Ghostty
• (5 封私信) macOS Tmux安装及配置（复制粘贴，保存工作区） - 知乎
• tmux安装及使用（macos） - pd_liu - 博客园
• .tmux/README.md at master · gpakosz/.tmux
• 【iTerm2 实用技巧】解决两大顽疾：历史记录看不全 & 鼠标滚轮失灵作为 Mac 上的终端利器，iTerm2 的强大 - 掘金
• Installing · tmux/tmux Wiki
• Tmux 使用教程 - 阮一峰的网络日志

不是某个 IDE 插件、某个 chatbot 包装，
而是连"自我成长"、"使用监控"、"代码评审"都各自有了独立工具。

Agent 不再是某个产品里的一个功能，
它正在变成一个生态。

本周一句话总结

当一个领域同时出现了"做事的人"、"看着做事的人"和"统计做事人花了多少钱的人"，这个领域就不再是趋势，是产业了。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一节不求全，
只挑几个"我看到时停了一下"的东西。

crit：替你看 Agent 写的那堆"看起来都对"的代码

Agent 写代码的速度已经超过了人类阅读代码的速度。这不是夸张。当 Cursor 或者 Claude Code 一次给你 300 行 diff，你下意识做的事是滚动到底，看一眼测试通过没有，然后点 accept。

crit 想做的事很朴素——让 review 这一步重新变成"事"，而不是"形式"。它把 agent 生成的 plan 和 code 平铺在一个本地界面里，你可以画出某几行，留一条评论，然后点 finish review，agent 自动按你的评论改。

它没有解决"agent 怎么写得更好"，
它解决的是"我怎么不再假装我看过了"。

本地优先、一键分享、支持 190 种语言高亮、Vim 键位——这些都只是配料。真正的判断是：当 agent 越来越快，慢这一步反而成了奢侈品。

hermes-agent：把"经验"做成 Agent 的可持续资产

Nous Research 出的，定位有点克制——它不是 copilot，不是聊天机器人壳，而是"在你服务器上跑的自治 agent"。

但真正的彩蛋藏在描述里那一句：self-improving。它会从你的项目里持续学习，把解决过的问题留存为"技能"，下一次遇到同类问题直接调用。

这个想法不新，新的是它落地的方式：跨 Telegram、Discord、Slack、WhatsApp、邮件、CLI 操作；五种沙箱后端（local / Docker / SSH / Singularity / Modal）；并行子 agent 各跑各的对话和终端；自然语言 cron。它在赌的是——agent 真正的护城河不是模型，而是记住自己解决过什么。

它跟 Claude Code 的 skill 机制几乎是同一个方向。只是 hermes 更激进：技能不是人写好的，是它自己长出来的。

factory：当 IDE 厂商和 Slack 同时变成 Agent 的入口

Factory.ai 这周有了 Cask。1.5B 估值、150M C 轮、agent 能直接进 VS Code / JetBrains / Vim / 浏览器 / CLI / Slack / Teams 甚至 issue tracker。

它的口号是 "agents that work everywhere you do"，听上去像营销，但拆开看其实是个判断：Agent 不应该绑定 IDE，agent 应该绑定工作流。你在哪儿干活，它就在哪儿出现。

这跟同周出现的 jetbrains-air（JetBrains 的"agent 原生开发环境"）形成了一种微妙对照——一个想让 agent 跟着人走，另一个想给 agent 造一个自己的家。两条路都还没分出胜负，但桌面级 agent 应用这件事，已经从一两个先锋变成了一片小浪潮。

defuddle：替 Readability 写一个温柔点的版本

Obsidian Web Clipper 的副产品，结果反过来比主产品更值得记一笔。

它做的事就一件：从乱七八糟的网页里把正文抠出来，输出干净的 HTML 或 Markdown，顺手把元数据（标题、作者、发布时间、favicon、schema.org）也提取了。

跟 Mozilla Readability 比，它更"宽容"——不确定的元素倾向保留而不是删除，因为很多时候 Readability 删得太狠，把脚注和图注也一起带走了。它还会用移动端样式来识别"装饰性"元素，这个思路挺机灵的。

为什么值得停一下：在"AI 把网页喂给模型"成为日常的今天，预处理这一步的质量直接决定了下游的智商。defuddle 做的是那种默默改善整个生态的事。

趋势观察：AI Agent 正在长出"配套产业"

把这周的新增放在一起看，AI agent 这个领域出现了一种新的拓扑：

• 做事的层：hermes-agent、factory、manus、jetbrains-air
• 看着做事的层：crit（review agent 写的代码）
• 数着钱的层：openusage（统计 Cursor / Claude Code / Codex / Copilot 的用量与花销）
• 喂数据的层：defuddle（清洗网页给模型）
• 驱动模型的层：open-webui（本地模型的桌面前端）

一个领域开始出现"周边工具"，意味着它过了草莽期。当有人开始专门做"用量监控"、"代码审计"、"数据清洗"的时候，agent 就不再是某个 IDE 里的一个 panel，它开始有自己的供应链。

也就是说——Agent 终于不是单飞了。

一点个人感受

老实说，这周新增的科研工具不少（alevin-fry、cutadapt、hyphy、paml、iqtree3 一整套生物信息学工具链），但我没办法假装它们跟我有关系。这是 Homebrew 有意思的地方——它从来不只是"开发者商店"，它还是某些科研社区的发行渠道。

让我留意的是 zapp。ZSA 给自己的键盘做了个 brew install 的刷固件 CLI。这事很小，但很温柔——硬件厂商认真对待终端用户，是这个时代越来越稀缺的事。

至于 AI agent 那一堆，老实说，我未必会都装。openusage 我大概率装，因为我已经被某个月的 token 账单吓过一次；crit 我会观望，看它跟现有 review 习惯能不能对上；hermes-agent 现在还有点重，但方向我赞同——agent 的未来不在模型里，在它的"经验积累"里。

结语

一周之内，Homebrew 同时收下了"做事的 agent"、"审 agent 的工具"、"统计 agent 花销的应用"。这种多层次出现，本身就是一个信号。

工具不再是孤立的功能点，而是开始彼此咬合。当 agent 有了 reviewer、有了用量监控、有了数据清洗器，它就从"实验"变成了"生产"。

一个赛道开始有"配角"，才说明它真的成了。

大部分情况下，SideStore & LiveContainer 官方文档和Issues足矣解决99.99%的问题。

老鸟可以略过，新人可以继续阅读。

下面我简单说一下，我对这个项目的理解，以及如何正确使用。

SideStores 是什么？

“SideStore is a fork of AltStore that doesn't require an AltServer.”

“SideStore is an untethered, community driven alternative app store for non-jailbroken iOS devices”

上面两段话意思，SideStore 是一个替代应用商店的应用，不需要用户越狱即可安装应用。

“🍎越狱（iOS Jailbreaking）是指通过技术手段，利用iOS系统的漏洞，获取iPhone、iPad等苹果设备操作系统的最高权限（Root权限），从而打破苹果公司所设定的封闭式生态环境限制。”

越狱手机后的手机，可以安装任何应用，没有任何限制🚫。但是，并不是所有人都希望越狱，但又想安装其他非🍎官方上架的应用，怎么办？

SideStore 就可以做到，完美解决非越狱用户即可安装应用的需求。

在 SideStore 出现之前，AltStore 一直是这项需求这个领域的首选方案。但是 AltStore 有一个非常麻烦的问题：每隔7天需要刷新一次，否则通过 AltStore 安装的应用就会不可使用。

SideStore 并没有解决这个问题：需要每隔7天刷新一次。

但是，SideStore 可以较方便的在Wi-Fi环境下刷新应用，而 AltStore 只能在电脑上刷新。

“这里强调一点，AltStore 只能在电脑上刷新，是因为依赖 AltServer，只要设备和电脑在同一网络，也可以通过Wi-Fi自动刷新。”

在使用 SideStore 之前，必须了解官方提供了：

• SideStore.ipa
• iloader
• LocalDevVPN

具体如何安装，本文不赘述，建议查看官方文档。

安装 SideStore.ipa，还可以通过以下几种方式：

• AltStore
• Sideloadly
• Impactor

当然，仍然希望大家遵循 SideStore 官方文档。

“为什么要说这件事情？因为 SideStore 迭代很快，之前确实推荐使用 AltStore / Sideloadly 安装 SideStore，后面有了 iloader，才开始成为主要安装方式。”

也许若干时间，还有其他变化。😊

说完 SideStore，现在聊聊 LiveContainer。

SideStore 最多只能装3个App，而 LiveContainer，能突破这个限制，变成近乎无限。

这就是 LiveContainer 最大的魅力，其他玩法(多个 LiveContainer)，可以查看官方文档或社区。

最后，分享一些 SideStore & LiveContainer 的使用心得：

1. SideStore 安装主力常用App；
2. LiveContainer 安装放“可折腾”的App;
3. 依赖通知和后端推送的App，不可使用 LiveContainer；
4. 游戏模拟器类，需要 JIT，建议使用 LiveContainer；
5. 用小号 Apple ID，不要用主号，避免被封号；
6. 使用捷径和定时任务更新SideStore，保持每天至少打开一次；
7. 使用Clash Mi，即便没有Wi-Fi也可以刷新，【参考】；

如果不小心掉签了，别急，可以在电脑上通过iloader恢复。

Ref

• LiveContainer 简介
• claration/Impactor: Feature rich iOS/tvOS sideloading application written in Rust.
• - [BUG] IOS development cert or pending cert request bug (7460) · Issue #795
• SideStore/SideStore: SideStore is a fork of AltStore that doesn't require an AltServer.
• LiveContainer + SideStore (LC+SS): Complete Guide
• LiveContainer现在有一个内置sidestore的版本 : r/sideloaded
• 我正在尝试登录 sidestore，但它说“您已经拥有当前的 iOS 开发证书或待处理的证书请求 (7460)”。 : r/sideloaded
• JIT是干嘛用的？？ : r/AltStore
• 启用JIT | SideStore Docs
• StephenDev0/StikDebug: An on-device debugger/JIT enabler for iOS versions 17.4+, powered by idevice.

添加DSOrganize后，重新加载DSTWO时，
发现会多出一个“._DSOrganize”的黄色问号图标，感觉非常丑。

由于刚接触DSTWO，对它不熟悉，
也不知道是什么原因产生的,
所以一直不敢动。

今天在网上找到一个中文版的bak（备份文档），非常开心。

然后立马解决这个问题。

问题产生的根源是，Mac 系统会在 FAT32 文件系统上创建的元数据文件。类似“._ ”。
使用“dot_clean”命令可以解决。

“2>/dev/null” 可以屏蔽错误信息。

使用下面的命令禁止产生.DS_Store文件

defaults write com.apple.desktopservices DSDontWriteUSBStores -bool true

使用下面的命令，禁止在网络共享上生成.DS_Store

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

保险起见，可以再加上，禁止生成 .DS_Store（U盘）

mac系统下将U盘格式化FAT32：

diskutil eraseDisk FAT32 NDS MBRFormat /dev/disk16

Ref

• Duplicate Grey Icons in DS pico menu : r/flashcarts
• DSTWO Displaying 'Broken' ROM Duplicates? | GBAtemp.net - The Independent Video Game Community
• Mac Users - ? icon plugin fix | GBAtemp.net - The Independent Video Game Community

那些曾经散落在 /tmp、命名为 test/test2/actually-final 的目录，
那些永远配不好的 Makefile 环境，
那些需要记住"这个知识在哪个笔记里"的心理成本。

这周的工具们在说：别记了，让工具来记。

本周一句话总结

新增不算多，但方向很明确——开发者开始为"减少心智负担"付费，而不是为功能付费。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一节不求全，
只挑 3 个 值得停下来看的点。

try：省掉"这个目录叫什么来着"的记忆成本

你有多少个叫 test、test2、new-test、actually-final 的目录？

它们散落在你的 filesystem 各处，有些在 /tmp，有些在 ~/projects/experiments，还有些在你自己都记不清的位置。过了一周再想找某个实验，只能靠 find . -name "*redis*" 碰运气。

try 解决的就是这个看似微小但持续消耗心力的问题。它给每个实验一个带日期的名字（比如 2025-08-17-redis-experiment），然后用智能模糊搜索让你瞬间找到——不是简单的字符串匹配，而是根据最近访问时间排序。

最妙的是它的哲学："Your brain doesn't work in neat folders. You have ideas, you try things, you context-switch like a caffeinated squirrel."

它没有试图教你整理文件夹的正确方式，而是承认了你的混乱，然后让它变得可用。

lazymake：让 Makefile 不再是个黑盒

Makefile 的问题从来不是语法难，而是你永远不知道里面定义了什么 target。

你打开一个项目，看到几十个 target，但不知道哪些是常用的，哪些之间有依赖关系，哪些会触发耗时很长的重建。要么硬着头皮读 Makefile，要么凭记忆猜 make build 还是 make compile。

lazymake 提供了一个漂亮的 TUI 界面，把所有 target 摊开来给你看。它能显示 target 之间的依赖关系，标记出常用的命令，甚至能预览执行结果。

对于那些不常接触但偶尔需要修改的项目，这种可视化的价值在于：你不需要重新理解整个构建系统，只需要在界面上找到你想要的那个按钮。

tolaria & cavalry：工具的分化

这周的两个 Cask 指向了两个不同的方向。

cavalry 是一个专业的 2D 动画软件，实时渲染、数据导入、rigging 系统——它是那种"把一件事做到极致"的工具。你需要学习它的专业术语，理解它的工作流，但一旦掌握，就能做出专业级别的作品。

tolaria 则完全相反。它是一个 Markdown 知识库管理器，但它的设计哲学是"不要学习新东西"。你的笔记就是普通的 .md 文件，用任何编辑器都能打开；版本控制就是 Git，你可以用命令行查看历史；甚至 AI 集成也是通过标准的 MCP 协议。

一个是封闭的专业系统，一个是开放的通用工具集。

两者都有价值，但趋势是：当工具的复杂度超过某个阈值时，用户开始偏好"只是文件"的可携带性。tolaria 的安装量（242次/30天）比 cavalry（105次/30天）高出一倍多，这可能不是巧合。

一点个人感受

try 和 lazymake 都是那种"装了之后不会卸载"的工具——它们解决的问题太小太日常，以至于一旦习惯就回不去。

相比之下，cavalry 这类专业工具更像是"有一天我会需要"的存在。它的功能很强大，但学习曲线意味着你必须在某个时间点集中投入精力。而现代开发者的时间碎片化程度，可能已经不支持这种深度学习了。

tolaria 的出现时机很有趣。它强调"笔记只是文件"、"Git 就是同步"、"MCP 标准接口"——这些都是在回应 Notion 等云端工具带来的焦虑：我的数据在哪里？我能带走吗？如果服务关闭怎么办？

也许下一代的工具不是功能更强的那个，而是让你最安心的那个。

结语

这周的工具列表里没有改变世界的东西。

但它们都在做同一件事：把开发者从"我需要记住什么"解放到"我只需要创造什么"。

try 省掉了目录命名的心理负担，lazymake 省掉了理解构建系统的负担，tolaria 省掉了担心数据锁定的负担。

工具在变，但好的节奏应该是：负担在消失，而创造力在增加。

下周见。

Apple Intelligence 有了命令行入口,Apple Containers 有了原生 GUI,终端里甚至多了一个电子表格。与此同时,一个六万星的 AWS 模拟器被标记 deprecated,依赖链在同一天被清理干净。这一周的列表,一半在打开新入口,一半在关闭旧通道。

本周一句话总结

系统能力在变成命令行工具,旧工具在变成历史注脚。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

本周重大更新与变化

📦 Major Updates (Casks)

⚠️ Notable Changes (Formulae)

值得留意的几个方向

apfel：Apple Intelligence 的命令行入口

Apple Intelligence 一直藏在系统设置和 Siri 后面。apfel 做的事情很简单:给它开了一扇终端的门。

brew install apfel,不需要 API key,不需要下载模型,不需要配置。macOS Tahoe 自带一个约 30 亿参数的语言模型,跑在 Apple Silicon 的 Neural Engine 上。apfel 把这个模型通过 Apple 的 FoundationModels 框架暴露出来,提供三种模式:命令行工具、交互式聊天、OpenAI 兼容的 HTTP 服务器。

最后一点是关键。OpenAI 兼容意味着你现有的任何用 OpenAI SDK 写的脚本,只要把 base URL 改成 localhost,就能接上苹果的本地模型。零成本,完全离线,数据不出设备。

但 4096 token 的上下文窗口决定了它的定位:快速的文本处理、shell 脚本里的胶水层、commit message 生成这类短任务。不是用来替代 Claude 或 GPT 的,是用来替代"这个小任务值不值得调一次 API"这个纠结的。

它还支持 MCP。这意味着你可以把本地文件系统、数据库、甚至其他 API 作为工具接进来。一个免费的、完全本地的、支持 tool use 的 AI——虽然能力有限,但对于自动化脚本来说,够了。

orchard：Apple Containers 有了自己的 GUI

Apple Containers 是苹果在 macOS 26 上的原生容器方案。orchard 是它的第一个第三方 GUI。

要求 macOS 26 以上,这说明它完全依赖苹果的原生虚拟化框架,没有绕道 Docker Desktop 那套。对于那些"想在 Mac 上跑容器但不想装 Docker Desktop"的人来说,这条路终于开始有工具了。

目前安装量只有 107,说明 macOS 26 的用户基数还很小。但它进了 Homebrew Cask,意味着苹果的容器生态正在从"技术预览"走向"有人在上面写工具"的阶段。

localstack：六万星项目的体面退场

LocalStack 是本地模拟 AWS 服务的工具。S3、DynamoDB、Lambda、SQS——你能想到的 AWS 服务,它都能在你的笔记本上跑一个假的出来。64,900 颗星,是很多团队本地开发和 CI 流程里不可或缺的一环。

三月底,上游仓库被标记为 archived。官方的说法是"合并到统一镜像",提供一个"更可靠和精简的体验"。翻译一下:开源版和商业版要合并了,以后只有一个入口——那个带 Hobby 免费计划的统一版本。

Homebrew 这边的反应很快。4 月 12 日,localstack 被标记 deprecated,同一天 awscli-local 移除了对它的依赖。依赖链的清理比项目归档还要干脆。

这是一个典型的"开源项目商业化收编"的故事。免费版没有消失,只是搬了个地方,换了个名字,加了个注册页面。对于那些在 CI 脚本里写死了 brew install localstack 的团队来说,这周要改一行命令了。

趋势观察：AI 代理的基础设施在成型

这周的 Cask 列表里,AI 相关的工具密度很高:

• cc-switch: AI coding agents 的配置管理器——当你同时用 Claude Code、Cursor、Copilot,每个都有自己的配置文件,cc-switch 在管这件事
• hive-app: 跨项目并行编码的 AI 代理编排器
• rowboat: 带记忆的 AI 协作助手
• vibe-island: 灵动岛里的 AI 代理
• copilot-language-server: Copilot 的 LSP 实现,上期在 Formula 里出现过,这次 Cask 也有了

这些工具不是 AI 模型本身,是 AI 模型的"水电煤"——配置管理、任务编排、记忆持久化、界面集成。当围绕 AI 代理的基础设施开始密集出现,说明这个领域正在从"尝鲜"进入"日常使用"。

一点个人感受

apfel 让我意识到一件事:macOS 自带的那个语言模型,我从来没主动用过。不是因为它不好,是因为它没有入口——或者说,它的入口是 Siri,而我已经很久不和 Siri 说话了。apfel 给了它一个我愿意用的入口。

localstack 的退场让我想起一个模式:开源项目做大,商业化收编,免费版变成"免费计划"。这不是坏事,但每次看到都有点微妙的不适感——像是你常去的公园突然加了个扫码入口,里面的东西没变,但感觉变了。

这周的 Cask 列表里有 8 个字体。字体包进 Homebrew 这件事,说明开发者对字体的态度变了——以前是"系统默认就行",现在是"我的终端要用 JetBrains Mono,我的编辑器要用 Fira Code"。字体成了开发环境的一部分。

cc-switch 的存在让我觉得,AI 编码工具的碎片化程度,已经到了需要一个"配置管理器"来管配置管理器的地步了。

结语

苹果的系统能力正在被拆解成一个个命令行工具和独立应用。Apple Intelligence 不再只是 Siri 的后端,Apple Containers 不再只是 WWDC 的演示。当这些能力出现在 brew install 的列表里,它们就从"平台特性"变成了"开发者工具"。

与此同时,旧工具在退场,新的基础设施在铺设。这一周的 Homebrew 不安静,只是变化的方式不一样了。

系统能力变成工具的那一刻,才是它真正被接受的时候。

不是新想法，是旧思路在换场景。Swift 想去 Android，Python 想用 Rust 重写，AI 订阅想借给编辑器用。看起来我们进入了"不是造新轮子，是把轮子装到别的车上"的时期。

本周一句话总结

一批关于"如何把 A 搬到 B"的工具。

四月初的工具箱，越来越多的是"怎么把这套路子移到那边去"

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

skip：把 Swift 搬到 Android 这件事

Swift 本来只活在苹果生态里。skip 想做的是：让你用 Swift 写一套代码，同时编译出 iOS 和 Android 应用。

不是跨平台框架那种"写一次，到处丑"的方案。是"写 Swift，编译出真的 Kotlin"。它在编译层动了手脚，不是在运行时做兼容。

这省掉的是"又要学 Kotlin 又要学 Swift"这件事。但代价是你得接受 skip 对 Swift 的理解——它能翻译的只是 Swift 的子集。

rustpython：用 Rust 重写 Python 解释器

Python 慢是因为解释器用 C 写的，Rust 重写能快多少？rustpython 在试这个问题。

它不是要替代 CPython，是在做"如果我想嵌入一个 Python 解释器到 Rust 项目里，我能不能不依赖 CPython"。这解决的是 FFI（Foreign Function Interface）的心智负担——不用管内存怎么在 Rust 和 C 之间传，直接在 Rust 里跑 Python 代码。

但这意味着很多 CPython 的扩展不能用。如果你的代码依赖 numpy、pandas 这些，rustpython 暂时帮不了你。

vibeproxy：让 AI 订阅共享给多个工具

你订阅了 Claude Pro，想在 VSCode、Cursor、终端里都用。vibeproxy 做的是：它假装自己是 OpenAI API，把请求转给你的 AI 订阅。

省掉的是"每个编辑器都要配一遍 API key"这件事。也省掉"买多个订阅"的钱。

但它是个代理层，所以延迟会多一点。而且它要一直跑在后台。适合那种"我就是想把 Claude 用在所有地方"的人。

git-format-staged：只格式化你改过的代码

你在一个老项目里改了三行代码，prettier 想把整个文件重新格式化一遍。git commit 的时候 diff 一团糟，reviewer 看不出你到底改了什么。

git-format-staged 做的是：只对你这次暂存的那几行代码跑格式化工具，其他地方不碰。

这省掉的是"要不要先提一个纯格式化的 commit"这种纠结。也省掉"手动选中要格式化的行"的操作。

一点个人感受

graalvm 进 Homebrew 了，这是个信号——Native Image 的编译时间从"能忍"变成"可以接受"了吗？还是大家放弃了等它再快一点？

skip 的思路很聪明，但我不确定会有多少人愿意把 Android 的生命周期交给一个编译层。万一哪天 Kotlin 出了新特性，skip 跟不上怎么办？

vibeproxy 让我想起以前用 SS 的时候，那种"把一个订阅分给所有设备用"的感觉。工具本身没问题，但我隐约觉得这类需求的存在，说明现在 AI 订阅的定价模式还没稳定下来。

结语

迁移永远比重新开始便宜，但只在你知道终点不会变的时候。

这周的工具都在省一个成本：学习新东西的成本。但它们的代价是你得相信这条迁移路径会一直有人维护。

工具在变，但节奏不必跟着变。

下期预告
继续观察 Homebrew 的动向，看看四月中还会出现哪些"省心智成本"的工具。

三月末的更新列表里，有一种"不想等"的感觉。
不是那种急躁，是那种"既然要做，就不等标准完善了"的态度。
从终端里直接处理视频，到把付费写进 HTTP 客户端，都在说同一件事。

本周一句话总结

工具开始不再假装自己很"通用"。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

lazycut：省掉"导出了再看"这一步

终端里直接剪视频，听起来像是在秀肌肉。但它在省的心智成本其实是：你不用再"打开 Finder → 找到文件 → 拖进剪辑软件 → 等预览加载"。

很多时候你只是想"把这段视频前面三秒切掉"，但完整的流程让你觉得"算了，就这样吧"。lazycut 把这个门槛降到了"cd 进目录就能干"的级别。

它不是在替代专业剪辑软件。它是在替你省掉"为了一个三秒操作而打开一个三分钟启动的软件"这件事。

pay：当 HTTP 402 不再是笑话

HTTP 状态码 402 Payment Required，从 1997 年就写在 RFC 里，但二十多年来都只是个"保留字段"。所有人都知道它存在，但没人真的用它。

pay 这个工具的出现，不是在说"我们终于能用 402 了"，而是在说"我们不想等标准完善了"。它自己定义了一套规则，让 HTTP 客户端可以直接处理付费请求——基于 Solana 的链上支付。

这种态度挺有意思的：与其等一个"所有人都同意"的标准，不如先做一个"能跑"的实现。它可能不会成为主流，但它在证明"这件事是可以做的"。

一个趋势：AI 工具开始"搬家"

这次更新里出现了三个跟 Claude Code 相关的 cask：claude-code@latest、nimbalyst、notchi。

这不是说 AI 工具变多了，而是说它们开始"离开浏览器"了。以前你要用 Claude，你就打开网页；现在你可以装个命令行工具，或者装个桌面伴侣。

工具的形态在变，从"通用界面"变成"专用场景"。这种变化的底层逻辑是：当一个工具被频繁使用时，人们会希望它"更近一点"。不是功能上的近，是物理距离上的近——少开一个标签页，少切一次窗口。

一点个人感受

jsongrep 我可能会装，因为 jq 的语法我永远记不住，而"grep"这个词能让我少查一次文档。

pay 我不会装，不是因为它不好，而是因为我不觉得现在"用 HTTP 付费"是个刚需。但我会记住它，因为它在证明一件事：标准可以是"先做出来"再慢慢达成共识的。

至于那些 AI 伴侣工具，我觉得方向很明确，但可能还早。现在装一堆小工具，不如等它们合并成一个。

结语

三月的最后一天，工具列表还是那么长。
但越来越少有工具会说"我什么都能干"。
它们都在说"我只干一件事，但我干得比你想象的近"。

工具在变，但节奏不必跟着变。

下期见。

Uncaught Exception:
Error: spawn iina ENOENT
at ChildProcess._handle.onexit (node:internal/child_process:285:19)
at onErrorNT (node:internal/child_process:483:16)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)

A JavaScript error occurred in the main process

步骤1：先设置 Invidious API

通过 Invidious Instances 获取开源的地址，然后点击【将当前实例设为默认】即可。

步骤2: 不要配置外部播放器

理论上，FreeTube 支持外部播放器，但是由于技术原因，需要一些配置。

如果配置不合理，体验会很差。所以，当前推荐【不要配置外部播放器】。

项目组有个专门讨论的 Discussions。

Ref

• IINA does not open youtube videos for some reason : r/macapps
• [Bug]: IINA won't open: giving javascript error
• [Bug]: Invidious API Error: SyntaxError: Unexpected end of JSON input
• 用IINA无广告观看YouTube : r/mac
• 一款开源桌面 YouTube 播放器FreeTube —— 一款开源桌面 YouTube 播放器，基于 Electron

• Cline Kanban - Orchestrate Coding Agents With a Kanban Board
• Announcing Cline Kanban: a CLI-agnostic app for multi-agent orchestration.

今天在 v2 再次刷到 此次 ApiFox 是否中招自查命令。

【包括不限于: SSH 私钥、Git 凭证和命令行历史】，这段话让我有了后怕。

接着，迅速检查电脑和采取修复以及防御手段。

检查电脑

下列涉及的命令都是 macOS 支持的，其他平台参考。

1. 检查 Electron localStorage 中是否存在 _rl_headers、_rl_mc 键

grep -arlE "rl_mc|rl_headers" ~/Library/Application\ Support/apifox/Local\ Storage/leveldb

2. 检查 dns 历史中是否存在 apifox.it.com 的解析记录

sudo dscacheutil -q host -a name apifox.it.com

3. 检查历史 HTTP 请求头中是否包含 af_uuid、af_os 等异常字段，

这个事情处理有点难度，建议使用 AI 工具来执行。

修复和防御

特别说明，本次事件受影响范围：受影响用户为“公网 SaaS 版 Apifox 桌面客户端”用户。SaaS Web 版用户不受影响；私有化部署版用户不受影响。

立即采取的行动:

1. 立即升级： 请尽快将 Apifox 客户端升级至 2.8.19 或最新版本。

2. 重置凭证： 若您在上述风险时间段内使用过受影响版本，请务必联系您的团队，全面排查并重置在设备里 ~/.ssh/、~/.zsh_history、~/.bash_history、~/.git-credentials 等处存储过的敏感凭证（包括但不限于 Git 密钥、鉴权密钥、数据库密码、云服务 Access Key 及环境变量等）。

3. 阻断恶意域名：apifox.it.com ，可以在 host 文件里增加配置：127.0.0.1 apifox.it.com

为什么会发生这样的事情？

供应链攻击，本质不是漏洞，而是“信任链被利用”。

为了防范此类事情再次发生，作为开发者，有必要列一个自检清单。

本地开发环境

• 是否开启自动更新？
• 是否验证安装包来源（hash / 签名）？
• 是否区分“工作环境 / 测试环境”？

👉 建议：

• 关键工具关闭自动更新
• 下载后的安装包做 hash 校验（哪怕是关键工具）
• 严格区分“工作环境 / 测试环境”

依赖管理

• 是否锁版本（package-lock.json / go.sum 等）
• 是否盲目 latest
• 是否使用第三方镜像源（npm mirror / pip 源）

👉 建议：

• 关键依赖锁定版本
• 建立私有化仓库，减少第三方镜像源依赖

CI/CD 与自动化

• CI 是否每次重新拉依赖？
• 是否有缓存污染风险？
• 构建流程是否可追溯？

👉 建议：

• 固定依赖版本
• 构建环境可复现（Docker / lockfile）

权限与隔离

• 是否在开发机使用高权限运行工具？
• 是否把敏感 token 放在本地明文？
• 是否做最小权限控制？

👉 建议：

• 为开发机创建非高权限的特定账户
• 敏感数据加密

Ref

• 关于 Apifox 公网 SaaS 版外部 JS 文件受篡改的风险提示与升级公告
• Apifox 供应链投毒攻击 — 完整技术分析

• Kazumi
• SameBoy
• Asspp
• Tachimanga
• Mangayomi
• YouTube
• VCMI
• Aidoku
• iPA 商店
• 源阅读
• Venera

为何会有这些app？难度 Apple Store 还不够多？

个人理解，需求难以满足😌，懂？！

Ref

• 不能用巨魔的你们都自签了哪些 app - V2EX
• Playcover 安装小红书 - V2EX
• bggRGjQaUbCoE/PiliPlus: PiliPlus
• NeoFreeBird/app: A modified Twitter app, with branding reverts, BHTwitter and other QoL modifications.
• leminlimez/Pocket-Poster
• feathericons/feather: Simply beautiful open-source icons

通常可以用 Apple Configurator 2 获得。

如果是非 macOS 系统，需要略懂一点技术。

ipatool

• 支持的操作系统（Windows、Linux 或 macOS）
• 有 Apple ID 可以使用 App Store

同时满足上面👆2个 条件，就能愉快玩耍。

运行时报错不要慌，在官方issues上有答案。

# 登录账户
ipatool auth login -e your-account -p your-password
# 搜索 app
ipatool search --limit 1 app-name
# 购买 app
ipatool purchase -b bundle-id
# 下载 ipa
ipatool download -i app-id -b bundle-id

Asspp

如果想在手机上操作，也可以使用 Asspp。

具体操作方式，参考README。

使用 Asspp 的优势，可以同时切换多个 Apple ID

另外也可以使用 App Store IPA 在线下载工具。

Ref

• iOS 旧版 APP 推荐与降级方法（持续更新） | 千灵
• 通过 iTunes 官方途径下载 iOS 旧版本应用 | Joseph's Blog
• 给 WeChat 无痛降级，解决服务号折叠带来的麻烦 - V2EX
• 不用愁签名问题了， Asspp 发布网页版，免切账号 AppStore 换区/下载旧版本 - V2EX
• 砍砍.ᐟ on X: "玩的开心～ 找你身边的大佬给你部署吧（ 一定要是你信任的人哦，虽然软件开源并且做了各种安全设计，但顶不住人家给你改代码用假的后台。🤡 docker pull ghcr-io/lakr233/assppweb:latest https://t.co/fZHHx4YFeW" / X
• Releases · Lakr233/Asspp
• majd/ipatool: Command-line tool that allows searching and downloading app packages (known as ipa files) from the iOS App Store
• Lakr233/AssppWeb --- Lakr233/AssppWeb- 苹果ipa合辑🍎 – APP喵：资源
• IPA下载网站，需要iosgods网站登录 – APP喵：资源

这一期看起来是常规的 CLI 与数据库工具更新，
但仔细看，会发现多个项目都在解决同一个问题：
如何让 AI 与开发环境协同工作。

本周一句话总结

开发工具链正在为 AI 代理准备新的接口层。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

cline：AI 编程代理开始走向“复杂任务执行”

cline 并不是一个简单的代码生成工具，而是一个可以持续执行任务的 AI 编码代理。它的价值在于把“生成代码”升级为“管理开发流程”，例如跨文件修改、测试修复和任务拆解。这类工具的意义不在于写代码更快，而是降低人类维护上下文与状态的心智负担，让开发者从指挥者变成监督者。

apache-arrow-adbc：数据库访问正在被重新标准化

ADBC 试图把数据库访问统一到 Apache Arrow 的内存格式之上，让不同语言与数据库之间共享同一套数据接口。这意味着数据分析、机器学习与应用程序之间的数据复制和序列化成本会显著下降。对需要跨语言或高性能数据处理的系统来说，这是一种从根层提升效率的基础设施。

portless：本地开发环境正在向“可读化网络”演进

portless 通过为本地服务分配稳定、可读的 URL（如 api.local）来替代随机端口号。这不仅提升人类可读性，也让 AI Agent 能更稳定地调用本地服务。随着本地服务数量增加，这种命名层实际上是在给开发环境补上一层“DNS”，减少记忆端口与修改配置的认知成本。

一点个人感受

这一期的工具并没有特别“炫技”的项目，但多个工具都在围绕同一件事：
让开发环境对 AI 更友好。

有些工具你可能永远不会直接安装，比如 ADBC；
但它们一旦被框架或数据库采用，就会悄悄进入你的日常工作流。

结语

开发工具的演进往往不是通过一个明星项目完成的，
而是通过一组看似分散的小工具慢慢重构生态。

工具在变，但节奏不必跟着变。

The data couldn’t be read because it isn’t in the correct format.

最近一直被这个问题困扰😕，非常影响使用体验：我几乎每天都要计算时间，以确保不会过期掉签。

在网上找了大量资料，总结了2个方案解决。

在说解决方案之前，需要先对这个问题产生的原因有所了解。

大致情况就是：

gsa.apple.com 域名的访问被限制🚫

如果在使用 SideStore / LocalDevVPN / iLoader 过程中，访问不了，就会导致刷新失败。

方案一

找一台挂梯子🪜的电脑，手机和电脑在同一局域网，在手机网络中配置代理，连接电脑。

具体可【参考】。

方案二

使用VPN工具自带的TUN模式，目前已知具有这个功能的VPN如下：

• Clash Mi
• sing-box

使用 Clash Mi 项目【自带的配置工具】可以比较快速的解决。

然后在生成的文件中加入：

tun:
  loopback-address:
    - 10.7.0.1

具体参考

sing-box 有点麻烦👿

apple store 上架的版本，目前是1.11.4，已经有一年时间未更新。

然而，sing-box 的TUN模式下支持 loopback_address 功能，需要 1.12.0 起。

所以，通过加入 sing-box 项目的 TestFlight 获得app是比较快速🔜的方式。

另外，就只能通过自行编译获得。
但似乎有其他问题，即使构建了ipa文件，也安装不上。

感觉 sing-box 的开发者也挺难，在自己的blog中写道：

多说一句，Shadowrocket 支持 TUN 模式，但类似 loopback_address 的功能不知道如何配置，需要去社区找资料。

Ref

• 求一份在 macOS 上能用的 sing-box 1.12 的 tun 配置 - V2EX
• clash 配置文件转 sing-box 模板 - V2EX
• xmdhs/clash2singbox: 将 clash.meta 格式的配置文件或链接转换为 sing-box 格式
• xmdhs/clash2sfa: 将 Clash.Meta 格式 / 原始格式的订阅链接转换为 sing-box 格式的订阅，用于 SFA
• clash 订阅链接转 sing-box
• The data couldn’t be read because it isn’t in the correct format. · Issue #1146 · SideStore/SideStore
• KaringX/clashmi: Clash Mihomo for iOS/MacOS/Android/Windows/Linux
• 参考配置 | Clash Mi Project
• Kwisma/cf-worker-mihomo: 快速生成mihomo（clash meta）配置文件, 适用于软路由 mihomo 内核，clash meta 客户端等
• DuckerX/Clash-Mi: Clash Mi 使用教程｜小火箭免费平替｜最简单的 iOS 图文教程
• 折腾啥 – Telegram
• Telegram: View @zhetengsha_group
• Tun - sing-box
• - [BUG] NSCocoaErrorDomain 3840; can’t refresh the apps · Issue #1143 · SideStore/SideStore
• - [Q&A]常见问题解答 · Issue #5 · tom-snow/Sidestore-ClashMi
• tom-snow/Sidestore-ClashMi: 使用 ClashMi 替代 LocalDevVPN / StosVPN 。解决部分运营商对 gsa.apple.com 不友好的问题。
• 解决altstore、sidestore不能刷新的问题 – 环顾四周
• 数据格式不正确，无法读取。· 问题 #1146 · SideStore/SideStore --- The data couldn’t be read because it isn’t in the correct format. · Issue #1146 · SideStore/SideStore
• SideStore iOS 侧载教程 - 晴雨技术笔记
• Quick configuration - mihomo docs
• 最近sidestore无法刷新续签的解决办法（无需用LocalDevVPN） - 开发调优 - LINUX DO
• Sub-Store Sing-box配置生成及简单分流
• 三年后的 sing-box | 世界
• (17) 世界 on X: "sing-box 的 TUN 现在实现了 SideStore 的 StosVPN。在 iPhone 上可以代替 StosVPN，作为网关时也可以对局域网设备生效。 https://t.co/4cu5HdM3BA" / X
• sing-box for Apple platforms - sing-box
• 建议：发布 iOS 版 IPA 包 · 问题 #409 · SagerNet/sing-box --- Suggestion: release IPA package for iOS · Issue #409 · SagerNet/sing-box
• 建议：提供 iOS 平台 IPA 安装包 · 问题 #3242 · SagerNet/sing-box --- Suggestion: provide iOS platform IPA installation package · Issue #3242 · SagerNet/sing-box

当项目规模变大，
真正消耗注意力的往往不是功能实现，
而是构建、协作和隔离这些基础环节。

本周一句话总结

这周新增工具明显围绕 构建效率、AI Agent 安全运行、协作开发体验 三个方向展开。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

buildkitd：构建系统正在变成“基础设施”

Docker 生态真正影响效率的，其实并不是容器运行，而是镜像构建过程。

buildkitd 提供并发构建、缓存复用和 Dockerfile 解耦能力，让镜像构建更像一个可以优化的流水线，而不是一次性脚本。当 CI/CD 规模扩大时，构建时间往往成为开发效率瓶颈，而 BuildKit 的价值就在这里：它把构建过程从“黑盒步骤”变成可调优的工程组件。

nono：AI Agent 需要新的安全边界

随着 AI Agent 开始参与自动化开发流程，
Shell 权限问题也变得越来越敏感。

nono 通过能力模型与系统级隔离，为 AI Agent 提供一个受控运行环境。Agent 可以执行命令，但只能在被授权的能力范围内活动。这类工具的意义并不是功能多少，而是为未来的自动化开发提供一个更安全的默认运行方式。

upterm：终端协作正在变得像分享链接

远程调试 CLI 程序通常需要 SSH、VPN 或屏幕共享。

upterm 将终端共享简化为生成一个会话链接，其他人即可加入同一个终端会话。对远程排查问题、结对编程或教学来说，这种方式比传统远程桌面轻得多，也让终端第一次拥有类似在线文档的实时协作体验。

一点个人感受

这一期新增的工具里，有不少看起来并不“耀眼”。

但仔细看会发现，它们解决的往往是开发流程里那些不起眼却长期存在的问题：构建速度、远程协作、自动化安全。

这些工具可能不会每天使用，但当工程规模变大时，它们往往会突然变得非常重要。

结语

Homebrew 的更新记录，其实也是一份开发工具生态的变化日志。

当新的开发方式出现时，总会有人先写出一个小工具，把问题解决掉。

工具在变，但节奏不必跟着变。

用了很长时间的虚拟机。

以前做web开发的时候，需要考虑界面适配，会安装多个虚拟机。

虽然，IETest，IETab 这些工具也可以模拟，但是仍然会有一些特别情况。

这时，虚拟机是不二选择。

过了这么多年，终于不用适配IE，但烦心的事情并没有减少。

PC端，Windows 和 Mac 的用户群体很多，为了获得相对较好的UI体验，需要在2个系统上调试。

目前，前端主流使用 Mac 开发，所以 Windows 的UI体验有时候很难被发现。

Mac 上比较主流的虚拟机是：

• VMware Fusion （免费）
• Parallels Desktop （商业）
• VirtualBox (开源)

通常来说，对于小白用户，上手容易程度：商业 > 免费 > 开源。

付费的通常都比较好用，功能也多，性能也好。

免费的功能支持一般不及时，或者性能差，或者功能少。

开源的不适合小白。

UTM 这个项目，是在我玩 SideStore 的过程中接触到的。

一直没怎么用，感觉不会在手机上用，所以仅停留在“知道这个项目”的程度。

最近在玩 Pokémon 游戏，需要用到 Windows 运行一些汉化工具。

所以在 Mac 上安装了 UTM。

安装很顺利，UTM 官方文档写的很清晰。

体验上比 Parallels Desktop 和 VMware Fusion 要简单很多。

UTM 支持 Intel / Apple Silicon，能跑一些较老的 Windows 版本。

Ref

• Home | UTM Documentation
• Download Windows 11 Arm64
• Windows Product Keys

游戏介绍

游戏平台：NDS
模拟器：Delta
游戏版本：

• 口袋妖怪(精灵宝可梦) 心灵之金 官译修正版v2.1.1(简)(JP)(ACG汉化组+Xzonn)(1024Mb)
• 口袋妖怪(精灵宝可梦) 金心(JP)(ACG汉化组)(1024Mb)

宝可梦心灵之金发布时间表

• 2009年9月12日 心灵之金／灵魂之银 官方发布
• 2010年7月2日 原版汉化 by @ACG汉化组
• 2020年2月28日 原版汉化优化 by @ACG汉化组、@Xzonn

事实上，还有很多其他衍生版本。例如：493/免通讯。493，即全部493只宝可梦。免通讯，即不需要联机通讯，进化宝可梦。

基于《原版汉化 by @ACG汉化组》的存档，可以被 @Xzonn 优化版本读取

剧情发现

挑战道馆

技能机

道具秘技

精灵性格

隐藏道具

通关组合

通关技巧

如何练级

如何刷钱

如何制作精灵球

常用术语

Ref

• NDS 口袋妖怪 宝可梦 心金／魂银 - 午后少年
• 老男人游戏网
• 《宝可梦 心金／魂银》汉化修正 - Xzonn
• 《宝可梦》系列游戏汉化时间表 - Xzonn

• Bulbagarden
• 《心金》策略 : r/nuzlocke
• 金魂银魂（HeartGold 和 Soulsilver） : r/pokemon --- 金魂银魂（HeartGold 和 Soulsilver） : r/pokemon
• 每一代里，谁是最好的HM苦力（们）？ : r/pokemon
• 在金心银魂里怎么快速赚钱：(不知道在金银里是不是也这样) : r/pokemon
• 口袋妖怪心金 图文攻略（2） - 哔哩哔哩
• 神奇世界官方網站-神奇寶貝
• HG/SS 里的学习装置 : r/pokemon
  - [口袋妖怪心金魂银]来热血吧!PM运动会解析
• 如何在模拟器上绕过交换进化？ : r/PokemonFireRed
• 口袋妖怪心金 图文攻略（2） - 哔哩哔哩
• 『口袋妖怪心金魂银』原创图文攻略【一周目+二、三周目】 - 心金|魂银资料库 - 口袋大学城 - Powered by Discuz!
• 宝可梦 心金／魂银 - 神奇宝贝百科，关于宝可梦的百科全书
• 心灵金/灵魂银专区 - Pokemon Center | 口袋中心 以口袋妖怪为主题并带有其他动漫游戏的讨论 - Powered by Discuz!
• 《宝可梦 心金／魂银》汉化修正补丁 - 《宝可梦》第四世代汉化修正
• 心金: r/pokemon --- 心金 : r/pokemon
• 《宝可梦》系列游戏汉化时间表 - Xzonn 的小站
• 【口袋中心出品】魂银·壹式改点壹（全493） - 心灵金/灵魂银专区 - Pokemon Center | 口袋中心 以口袋妖怪为主题并带有其他动漫游戏的讨论 - Powered by Discuz!
• 宝可梦 心金／魂银 - 神奇宝贝百科，关于宝可梦的百科全书
• 被誉为交通工具的宝可梦！每个版本的最佳工具宠，都有哪一些？ - 哔哩哔哩
• 桧皮镇头槌树地图 : r/pokemon

这一期没有特别“吸睛”的应用。
但多了不少你可能永远不会直接运行的工具。
它们更像基础设施的一部分，在系统背后慢慢改变开发方式。

本周一句话总结

这是一组明显面向“开发环境基础设施”的更新。

很多新增项目并不是给用户使用的应用，
而是构成：

• 容器运行环境
• AI 编程工作流
• 权限系统
• CLI 自动化生态

的一部分。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一节不求全，
只挑几个真正值得停下来看的技术信号。

containerd：容器世界真正的运行核心

容器技术通常被理解为：Docker。

但在现代云原生架构中，
真正负责运行容器的其实是 containerd。

技术栈结构大致是：

Docker
   ↓
containerd
   ↓
runc
   ↓
Linux kernel

containerd 负责：

• 镜像管理
• 容器生命周期
• 资源隔离
• runtime 调度

Kubernetes、Docker、许多 PaaS 平台
实际上都依赖它。

Homebrew 收录 containerd 的意义是：

开发环境正在变得更接近生产环境。

越来越多开发者开始在本地直接运行完整容器栈，
而不是依赖一层封装好的 Docker Desktop。

这也是一个明显趋势：

开发机正在变成一个“小型云平台”。

SpiceDB：权限系统正在数据库化

spicedb 是本期最值得关注的基础设施项目之一。

它的设计灵感来自 Google 的著名权限系统：

Zanzibar

Zanzibar 支撑着：

• Google Drive
• YouTube
• Google Docs

的权限关系。

为什么权限系统这么难

传统权限模型通常是：

user → role → resource

但现代 SaaS 的权限关系会变成：

用户
团队
组织
资源
共享
继承
协作

权限关系会形成复杂图结构。

SpiceDB 的做法是：

把权限关系当作图数据库处理。

例如：

user:alice
   member_of
team:design

team:design
   owns
doc:proposal

这样就可以动态计算权限。

为什么重要

未来复杂应用几乎都需要：

• 协作权限
• 多组织结构
• 细粒度授权

SpiceDB 这类系统正在成为：

权限基础设施。

OpenSpec：AI 编程开始进入“规范驱动”

AI 编程工具越来越多，
但一个问题也越来越明显：

AI 很擅长写代码，
却很难保持系统结构一致。

OpenSpec 的目标是：

让开发流程变成：

Spec → AI → Code

而不是：

Prompt → Code

Spec 可能包括：

• API 规范
• 数据结构
• 行为约束
• 架构约定

AI 只负责生成实现。

这其实是一种新的开发模式：

Spec Driven Development（SDD）

它解决的不是代码问题，而是：

AI 如何参与系统工程。

kubectl-tree：理解 Kubernetes 的结构

Kubernetes 对新手来说最大的困难之一是：

对象关系。

例如：

Deployment
   ↓
ReplicaSet
   ↓
Pod

同时还有：

• Service
• Ingress
• ConfigMap
• Secret

关系复杂且分散。

kubectl-tree 的做法非常简单：

把对象关系变成一棵树。

示例：

deployment/web
 └─ replicaset/web-123
     └─ pod/web-abc

这种视图对调试问题非常有用。

当 Kubernetes 规模变大时，
理解对象结构本身就是一种成本。

这个工具正是在减少这种心智负担。

pet：命令行时代的“代码片段库”

很多开发者都有这样的文件：

commands.txt
cheatsheet.md
notes.md

里面记录各种：

• docker 命令
• kubectl 命令
• ffmpeg 命令

pet 做的事情很简单：

把这些命令变成可搜索、可执行的片段库。

例如：

pet search docker
pet run kubectl-restart

当 CLI 工具越来越多时，
“记住命令”本身就变成负担。

pet 的价值是：

把记忆成本转化为工具能力。

cloudflare-speed-cli：测速工具的另一个方向

测速工具很多，但大多数使用：

Speedtest 网络。

Cloudflare-speed-cli 的特点是：

直接测试 Cloudflare 网络路径。

这对于很多开发者其实更真实：

因为大量服务现在都在 Cloudflare CDN 上。

如果你经常访问：

• GitHub
• npm
• Cloudflare Workers
• 各类 CDN

这个测速结果可能比传统 Speedtest 更有意义。

一点个人感受

这一期让我印象最深的是一种“基础设施感”。

很多新增项目：

• 不提供 GUI
• 不解决日常效率
• 不直接面对用户

却在悄悄改变开发环境。

像 containerd、spicedb 这样的工具，
你可能永远不会直接运行。

但未来的软件系统很可能就建立在这些组件之上。

结语

Homebrew 的更新列表有时像一份技术世界的地下水位报告。

你未必能看见它，
却能感觉到环境正在慢慢改变。

工具在变，但节奏不必跟着变。

1. 创建一个裸仓库

git clone --bare https://github.com/your-org/your-monorepo.git your-monorepo
cd your-monorepo

2. 为每个分支创建工作树

# 主开发工作树
git worktree add ./main main

# 代理 A 的功能分支
git worktree add ./feature-auth feat/auth

# 代理 B 的 bug 修复分支
git worktree add ./fix-api fix/api-error

每个工作树都是一个完整的检出，拥有自己的文件，但它们都共享同一个 .git 对象存储。

3. 启用全局虚拟存储

在你的仓库中的 pnpm-workspace.yaml 文件中添加 enableGlobalVirtualStore: true：

packages:
  - 'packages/*'

enableGlobalVirtualStore: true

4. 在每个工作树中安装依赖项

cd main && pnpm install
cd ../feature-auth && pnpm install
cd ../fix-api && pnpm install

第一次执行 pnpm install 会将软件包下载到全局存储中。 在其他工作树中进行后续安装几乎是瞬间完成的，因为它们只会创建指向同一存储的符号链接。

Ref

• pnpm + Git 工作树用于多代理开发 | pnpm
• 随笔档案「2026年1月」 - gyc567 - 博客园
• # GitHub Fork + git worktree 的标准工作流 - gyc567 - 博客园
• Git Worktree 与cursor workTree完全指南1. 引言：那个让你抓狂的“突发需求” 想象一下这个场 - 掘金
• git worktree 依赖隔离、多分支开发图文详解-CSDN博客

1. 首先让AI去更新接口，review时发现接口更新不对；
2. 反复与AI沟通，期望AI能正确识别接口，并更新代码；
3. 沟通无效，AI无法理解；

经历上面的阶段，个人感觉是MCP工具问题。

或许优化 Prompt 能解决问题，但是当时我已经想不出更好的语句😓

后面联系到官方技术群，在群里咨询了自己遇到的问题。

这个问题似乎其他人也有遇到，有解决该问题的办法。

配置的过程遇到报错：

[apifox-filter-mcp] [ERROR] Cannot determine a valid project directory (got: "/", resolved: "/"). Please set the CACHE_DIR environment variable to specify the cache location. MCP error -32000: Connection closed

这个报错是因为 CACHE_DIR 配置错误。

完整配置：

    "apifox-filter": {
      "timeout": 60,
      "command": "npx",
      "args": [
        "-y",
        "apifox-filter-mcp-server@latest",
        "--project-id=your-project-id"
      ],
      "env": {
        "APIFOX_ACCESS_TOKEN": "your-token",
        "LOG_LEVEL": "error",
        "CACHE_DIR": "your-path"
      },
      "type": "stdio"
    },

Ref

• xiaou66/apifox-filter-mcp-server

这一期没有让人眼前一亮的“新玩具”，
却多了不少你可能永远不会直接使用，
但每天都会间接受益的底层工具。

本周一句话总结

这一期新增工具的气质非常统一：

越来越多工具不再面向用户，而是面向系统本身。

它们不解决“操作问题”，
而是在悄悄重塑：

• 开发环境结构
• 容器运行方式
• AI 能力组织形式
• 系统安全模型

换句话说：

这一期更新的是“地基”，不是“房子”。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个关键方向

这一期真正值得关注的，不是单个工具，
而是几个非常清晰的技术趋势信号。

🧠 一、容器底层正在进入“无 Root 时代”

这一期最重磅的其实是一整条技术链：

• rootlesskit
• runc
• cni-plugins

它们共同指向同一个趋势：

容器正在从“工具”变成“操作系统级基础设施”。

rootlesskit —— 容器安全的未来方向

传统容器必须依赖 root 权限：

这意味着一旦容器逃逸，
风险几乎等同于系统被攻破。

rootlesskit 的核心价值在于：

让容器完全以普通用户权限运行。

它通过用户态能力模拟：

• user namespace
• network proxy
• mount proxy

把 root 能力转译成安全可控的机制。

为什么重要

未来几年会成为默认趋势：

• 企业安全策略会强制 rootless
• CI/CD 环境必须无 root
• 云开发环境全面去特权化

它是：

下一代容器安全架构的基石。

runc —— 容器世界真正的执行核心

很多人以为 Docker 在运行容器，
实际上真正执行容器的是 runc。

技术链路是：

Docker → containerd → runc → Linux kernel

Homebrew 收录 runc 的意义在于：

本地开发环境正在变得“原生化”。

未来趋势：

• 不再依赖 Docker Desktop
• 运行时可自由替换
• 更接近 Linux 原生能力

这就是所谓的：

后 Docker 时代。

cni-plugins —— Kubernetes 网络的根基

容器最复杂的部分并不是运行，
而是网络。

CNI 插件负责：

• IP 分配
• NAT
• Overlay 网络
• Service 通信

它们的出现意味着：

本地开发环境正在趋近生产环境。

未来开发机将越来越像：

一个可随时重建的小型数据中心。

🤖 二、AI Agent 正在进入“生态时代”

skills —— AI 能力开始模块化

这是本期最具未来信号的工具。

它代表 AI 正从：

“模型能力”

转向：

能力生态系统。

技术本质

它类似于：

未来 AI 竞争的关键将不是：

模型参数规模，

而是：

能力模块的可复用性。

重要趋势

AI 正在发生结构性转变：

从：单次调用 → 持续能力系统

从：回答问题 → 执行任务

从：工具 → 协作者

🔐 三、安全模型正在从“容器隔离”转向“微沙箱”

landrun —— Linux 安全的新方向

这是一个非常硬核但意义深远的工具。

基于 Landlock LSM 的特点：

• 无需 root 即可创建沙箱
• 内核级权限控制
• 比容器更轻量

它代表的趋势是：

未来安全将依赖微隔离，而不是重量级容器。

典型应用场景：

• 执行不可信代码
• 安全 CI 运行环境
• CLI 沙箱执行

这是“零信任计算”的重要拼图。

🎨 四、终端正在成为内容生产媒介

termframe —— CLI 进入表达时代

这个工具虽然很小，但信号很明显。

它的作用：

将终端输出转成 SVG 截图。

背后的变化

终端不再只是执行环境，
而开始成为：

• 技术内容资产
• 文档生成来源
• 可视化表达媒介

随着 CLI 工作越来越多：

“如何展示命令行成果”成为新需求。

🧭 本期最重要的三大技术信号

如果必须用一句话总结这一期：

这是一次基础设施层的集体升级。

🚩 信号 1：容器彻底走向无特权化

关键词：

• rootless
• 最小权限
• 可组合运行时

未来容器将更安全、更透明。

🚩 信号 2：AI 进入能力生态竞争阶段

重点不再是模型，而是：

• 技能模块
• 能力复用
• 任务编排

🚩 信号 3：开发环境正在系统化

本地开发环境越来越像：

• 可重建系统
• 微型生产环境
• 自包含基础设施

一点个人感受

这一期让我印象最深的不是某个具体工具，
而是一种明显的“隐形化趋势”。

越来越多新增项目：

• 不直接面向用户
• 不提供界面
• 不解决表层问题

却在悄悄改变：

系统运行方式、开发环境结构和安全模型。

它们不会立刻提升效率，
却会在长期使用中：

让系统变得更可靠、更安全、更可重建。

结语

Homebrew 的更新列表，
有时像一份技术世界的地下水位报告。

你未必能看见它，
却能感觉到整个环境正在慢慢改变。

工具在变，但节奏不必跟着变。

CPU:i7 ， 内存：16G, 硬盘：1TB，

当前系统 13.7.6。

Ventura 系统使用有一段时间了。

升级系统，主要原因是 brew 不支持之前的系统(macOS Catalina)，

导致很多软件无法更新和使用。

自从苹果推出M芯片之后，系统发展速度越来越快。

“Big Sur 开始不支持 intel 的 MBP”

我直接从 Catalina 升级到 Ventura。

为什么选择 Ventura？

因为 brew 对这个版本的支持还有一段时间，

Big Sur / Monterey 相对而言有点落后，有些 App 不支持。

并且 Ventura 运行起来还算流畅。

早在2014年的时候，MBP运行起来就有点吃力😰

因为没有配置SSD， 电脑运行速度非常慢🐌

根据网上教程，自己动手DIY，改造了硬盘：移除光驱，在原位置上添加了三星的 512G SSD，再通过苹果的 fusion drive 技术创建了 1T 融合硬盘。

另外，加购了 16G 内存。

使用 Disk Speed Test 测试，

读写速度从不到50MB/s，提升到平均500MB/s， 对于这点，相当满意👍。

随着AI的高速发展，Ventura 也有一些力不从心了。

后面应该要换台MBP，但是如何选择又是一道考验。

Ref

• MacBook Pro (13 英寸, 2012 年中) - 技术规格 - 官方 Apple 支持 (中国)
• Fusion Drive - Wikipedia

很多工具的出现，并不会立刻改变你的工作方式。
但它们会悄悄改变：
未来工具应该长成什么样。

这一期新增的项目，大多属于这一类。

本周一句话总结

本周最明显的趋势不是“新能力”，
而是：围绕 AI Agent 的基础设施开始成体系出现。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一期最值得看的，
不是某一个工具，
而是几个非常清晰的“演化信号”。

🥇 AoE: AI Agent 会话基础设施的诞生逻辑

AI 编程进入「多 Agent 并行时代」后，人类已经管理不了工作流了。

使用场景

• 多 AI Agent 并行运行的开发环境
• 需要在同一终端窗口下管理多个会话
• 实验、调试或快速迭代 AI 任务时
• 远程服务器或本地开发环境均可使用

背景需求

• 随着 AI Agent 越来越多，单一命令行会话难以管理
• 手动切换、记忆会话状态容易出错
• 团队或个人需要可重复、可记录的会话流程

核心价值

• 提供稳定、可复用的会话管理基础设施
• 减少管理多个 Agent 会话的心智负担
• 为后续自动化、监控或日志分析打下基础
• 让开发者可以专注于 AI 任务逻辑，而非终端管理

🥈 letta-code — Memory-first 编程模式

工具类型：面向 AI Agent 的编程辅助工具（Memory-first 编程）

使用场景

• 编写或调试依赖上下文的 AI 代码
• 需要 AI Agent “记忆”历史上下文、变量状态
• 快速迭代复杂逻辑，尤其是多步骤决策任务
• 与其他 AI Agent 或自动化工具结合使用

背景需求

• 传统 AI 编程环境常忽略上下文连续性
• 开发者在多轮交互或复杂任务时容易重复信息
• “记忆优先”的工作模式可提高 AI 输出一致性和效率

核心价值

• 将 AI Agent 的记忆管理作为核心功能
• 减少重复输入和上下文切换成本
• 提升长期、多轮任务的执行效率
• 形成可复用的 AI 编程工作流模式

🥉 likec4 — 架构可视化趋势

工具类型：架构建模与可视化工具

使用场景

• 将代码结构转化为可视化架构图
• 支持实时更新与交互式设计
• 在设计、开发、代码审查阶段使用
• 团队协作时快速理解系统复杂性

背景需求

• 随着系统复杂度增加，代码架构难以直观理解
• 文档与架构图容易过时
• 开发者需要实时可视化工具来降低认知负荷

核心价值

• 将架构与代码同步，保证图表真实反映系统状态
• 提供动态、可交互的架构视角
• 帮助团队快速理解、评审和优化系统设计
• 降低大型系统开发中的认知成本

以上总结

AI Agent 不再是单个工具，
而是完整生态，
这个生态，需要可观测与治理。

AI Agent 基础设施：从单点工具到完整生态

这一期几乎形成了一整条链路：

• Agent 会话管理
• 运行时框架
• 记忆系统
• Token 优化
• 沙箱安全

这些工具共同指向一个趋势：

AI Agent 正在从“插件式能力”
走向“独立运行环境”。

它们不再依附 IDE，
而开始拥有自己的操作层。

可观测性与治理：自动化世界的副作用

另一个显著变化是：

• 使用监控工具变多
• 安全审计工具变多
• 行为分析工具变多

这意味着工程世界开始接受一个现实：

自动化越强，
管理成本就越重要。

架构与系统建模：复杂度的另一种应对方式

像架构建模、实时图生成、结构化分析
这一类工具越来越多。

这不是为了文档漂亮，
而是为了让复杂系统
变得可以被人理解。

一点个人感受

这一期让我最强烈的感受是：

AI 工具已经不再处于
“能不能用”的阶段。

它们正在进入一个新的问题域：

• 如何协作
• 如何管理
• 如何被信任

也许真正的拐点，
并不在模型本身，
而在围绕它的工具生态。

结语

Homebrew 的新增列表，
越来越像一份技术趋势的年鉴。

它不会告诉你未来是什么，
但会悄悄标注：

下一阶段的工作方式，正在成形。

工具在进化，
但真正变化的，是我们与工具的关系。

公司马年开工红包，第一次收到这种形式：邮票。🤭

早期的工具，只关心能不能跑。
这一期的工具，开始关心：
谁在用、怎么用、是否可控。

Homebrew 的这些新增，更像是在为下一阶段的工作流打地基。

本周一句话总结

这一期没有爆炸式的新能力，
但出现了大量：
围绕 AI、自动化与工程规范的“管理型工具”。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

不挑“最强的”，
只挑 最能反映趋势变化的几个点。

actions-up：当自动化开始反过来要求“可审计”

GitHub Actions 早已无处不在，
但它们长期处于一种
“能跑就行” 的状态。

actions-up 做的不是帮你写更多 CI，
而是帮你把依赖升级这件事
变得可追踪、可复现、可回滚。

这意味着自动化，
也开始被当作供应链的一部分来管理。

skillshare：AI 工具，不再各学各的

随着 AI CLI 工具变多，
一个现实问题开始出现：

我教会了这个 Agent，
为什么另一个完全不懂？

skillshare 的思路很直接：
把“技能”本身变成可同步的资源，
而不是绑定在某一个工具里。

这是 AI 工具走向体系化的一个明显信号。

agent-browser / playwright-cli

当“操作浏览器”不再只属于人

Playwright 早就不只是测试工具了。
而 agent-browser 更是直接假设：
浏览器的操作者，可能是 AI。

这一组工具的共同点在于：
它们不再强调“自动化有多强”，
而是强调接口是否足够清晰、行为是否可控。

yap：输入，正在回到“本地可信”

yap 选择了一个很明确的方向：
不走云端、不做平台，
而是基于系统级 Speech.framework。

这不是能力不足，
而是一种取舍：

有些输入，
不值得离开你的设备。

一点个人感受

这一期的更新，
让我强烈感觉到一个变化：

AI 与自动化，
正在从“工具层”，
进入“系统层”。

开始有人关心：

• 版本是否可控
• 行为是否可审计
• 能力是否可复用

当工具开始被系统化管理，
人反而可以更轻松地使用它们。

结语

Homebrew 的更新，
已经不只是“多了什么工具”。

而是在悄悄记录：
工程世界的默认假设，正在改变。

AI 发展太快，有点焦虑。

但是 GPT-Image-1 非开源模型，没办法本地部署。

查了很多资料，发现 Stable Diffusion 开源模型和配套工具，部署有点麻烦，遂放弃了.

今天心血来潮，又去问了ChatGPT：

仍然提示“Stable Diffusion”。

同时，也看到了“Z-Image”，感觉命名风格与“GPT-Image-1”很像。于是，就去查了一下这是什么？看看是哪家公司制作的模型。

发现 github 上有 9.8k 个star，应该不简单。

再仔细一看，“造相”？我还以为开了沉浸式翻译。😅

仔细看完 README，大致了解了它的能力，决定试一下。

中途发生了一个小插曲：我发现了 Ultra Fast Image Gen 项目，使用下来感觉还不错，速度还能接受，生成的图片与之前使用 nano-banana 差不多，当然速度相差很大。

• 如何在Mac电脑上使用Z-Image模型：完整安装与优化指南 | Z-Image - 真实免费，快如闪电，无限量，无限制的在线AI图像生成
• newideas99/ultra-fast-image-gen: 4B parameter image gen that actually runs fast on your Mac. 14 seconds. No cloud. No GPU rental.

原本打算直接 Clone 官方源码，直接启动 Z-Image，结果运行时报错：

RuntimeError: MPS backend out of memory (MPS allocated: 18.11 GiB, other allocations: 384.00 KiB, max allowed: 18.13 GiB). Tried to allocate 47.50 MiB on private pool. Use PYTORCH_MPS_HIGH_WATERMARK_RATIO=0.0 to disable upper limit for memory allocations (may cause system failure).

为了跑起 Z-Image，下载了 32.9G 的文件，现在出现这个问题，我差点emo😈。

后面在网上查资料，发现 ComfyUI 这个项目。

ComfyUI 可以配置 Z-Image，并且支持很多图像生成模型，是个非常成熟和主流的使用方式。

立马安装 ComfyUI，然后下载了“Z-Image-Turbo”模版。

老实说，第一次在本地玩图像生成模型，对 ComfyUI 很陌生。

又去油管看了相关视频，才知道如何运行。😅

前后一共跑了2个任务，生成2张图片，花了半个多小时，平均一张 15min。

可能电脑配置问题：MacBook Pro M1，16G。

油管主播表示，20G显存，大概不到几秒钟。

以上就是今天 Z-Image 图像生成模型的全部内容了。

感觉 ComfyUI 还有很多玩法，需要深度发掘。

Ref

ComfyUI & Z-Image

• Z-Image-Turbo几种本地部署的主流方式 | 猫普的精神世界 | 一个独立开发者的精神自留地
• 我用电脑跑AI生图大模型——记折腾ComfyUI的全过程 | 猫普的精神世界 | 一个独立开发者的精神自留地
• Tongyi-MAI/Z-Image
• Z-Image Turbo 本地安装教程！最近非常火的文生图AI模型，到底怎么样？ – 零度博客
• Z-Image-Turbo ComfyUI 工作流示例 - ComfyUI
• ComfyUI 文生图教程，进行第一次的图片生成 | ComfyUI Wiki
• MacOS Desktop Version - ComfyUI
• Qwen又出好东西了！Z-Image又轻又快又好又准！
• 使用ComfyUI本地部署Z-Image实现生图自由
• Z-Image 新手完全指南：阿里开源 6B 图像模型从入门到精通 - Apiyi.com Blog

Stable Diffusion

• 在男朋友的 Mac 上部署 Stable Diffusion（超详细，含踩坑点，AI 绘画入门保姆级教程）终于实现 - 掘金
• 在本地跑一个AI模型(5) - Stable Diffusion在之前的文章中，我们使用ollama在本地运行了大语言模 - 掘金
• Stable Diffusion web UI
• Installation on Apple Silicon · Stable-diffusion-webui Wiki

越来越多的工具，
不再假设环境是安全的、用户是单一的、代码是可控的。

这一期的 Homebrew 更新，
明显在讨论一件事：
哪些事情，应该被隔离、被限制、被显式管理。

本周一句话总结

这一期没有炫目的新能力，
但多了不少：
帮你把“该隔离的隔离、该约束的约束”的工具。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一节不求全，
只挑 几个明显在“重画边界”的工具。

fence：命令行，也需要“权限意识”

在终端里执行命令，
长期以来都是一种全信任模型。

fence 的思路很直接：
在执行命令之前，
先决定它能不能访问网络、能不能碰文件系统。

这不是为了防黑客，
而是为了防自己、
防脚本、
防那些你已经不完全理解的工具链。

radicle：当代码协作不再默认“有中心”

radicle 再次提醒了一个老问题：
代码一定要托管在某个中心平台上吗？

它并不追求替代 GitHub，
而是提供一种选择：
当你不想把信任完全交出去时，
依然可以协作。

这是一个慢工具，
但方向非常明确。

infinidesk：桌面，本身就是一种隔离

大多数系统的“多桌面”，
只是窗口分组。

infinidesk 把这个概念推进了一步：
不同桌面，
拥有不同文件、壁纸、组件，
像是多个轻量工作环境。

它解决的不是效率问题，
而是上下文污染。

codex-acp / codexbar / commander

当 AI 工具开始被“运维化”

这一期出现了不止一个 Codex / Agent 相关工具，
但它们关注的都不是“更聪明”，
而是：

• 能不能被接入到不同客户端
• 使用情况能不能被监控
• Agent 能不能被调度和约束

这意味着，
AI 已经开始被当作系统组件，
而不是单一应用。

一点个人感受

这一期的工具，
很少在谈“能力扩展”。

更多是在问：

• 什么东西应该被限制？
• 什么操作值得被隔离？
• 什么系统不该再是默认全信任？

这不是悲观，
而是一种成熟。

当工具开始替你守住边界，
人才能更安心地把注意力，
放回真正需要判断的地方。

结语

Homebrew 的更新，
越来越像一组工程态度的集合。

它不告诉你该怎么用工具，
只是悄悄补齐那些
以前只能靠自觉维护的边界。

我们下期见

Ref

• Build an MCP server - Model Context Protocol

后面得知是 nano-banana 生成的，立马想体验一把。

今天闲来无事，登录 Goole AI Studio，试玩了几把，感觉还不错。

比 ChatGPT 简单多了，即便没有精心雕琢的 Prompts，也可以获得不错的图片效果。

直接丢给 nano-banana 一个 Markdown 文档，然后说将这个文档转成信息图，就得到了一个设计友好、信息准确的图片。

生成的信息图：

如果想尝试不同风格，只需这样：

生成的信息图：

毕竟是免费的模型，文字有很多错误，如果使用中文，会乱码。

如果使用 nano-banana pro，可能就没这些问题了。

Ref

• 看了太多 nano banana 套壳，我做了一个真的能解决科研绘图的网站 - V2EX
• 免费体验 Google AI 图片生成神器：Nano Banana Pro 完整教程 – silenceper
• Nano Banana Pro三个免费渠道，最后一个真香！ - 知乎
• Nano Banana Pro保姆级指南！全网最火玩法+官方7大技巧+免费渠道，都在这了 | 爱范儿
• Nano Banana Pro 完全指南！ - 知乎
• 我的 nano-banana 创意玩法大合集！ 持续更新中！
• Nano-banana 完整使用指南：教程、案例、白嫖网站，看这一篇就够了！ - 知乎

但还是之前说的那样：

“老实说，我没有完全理解它的“价值”。”

“个人预计，很快就没人会讨论它，Clawdbot。”

突然间，我想起 IFTTT，

If This Then That ——「如果发生了这件事，就执行那件事」

IFTTT 大概可以算是「自动化工具的祖师爷」之一。

IFTTT 刚出现的时候，也引发了很多人的期待，但最终情况就像现在这样，无人问津。

在我看来，clawdbot = 自动化工具 + AI：

虽然，AI 很强，但是仍然有许多事情无法完成：

1. 人类没有参考方案的事情；
2. 没有训练过的案例；
   ...

诸如此类，很多的场景。归根结底，AI 只能运行在人类设计的认知范畴里，一旦超出了人类的认知，它什么都干不了。

说个笑话，假如停电了，AI会去交电费吗？

直白点说，科技圈只是又多出一个玩具，clawdbot。

但问题来了：火爆全网的 Skills，普通人到底该怎么用？

食用指南：

• 首先安装 Skill，打开 The Agent Skills Directory；
• AI 中使用 Skill；
• 创建自己的 Skill；

一共安装3个Skill：

• frontend-design: 创建高质量的前端界面和组件，包括网站、落地页、仪表板、React组件等
• mcp-builder: 创建MCP (Model Context Protocol) 服务器的指南
• skill-creator: 创建新技能的指南

👇下面以 Claude Code 为例，讲讲 Skill 的使用和创建：

首先检查安装好的 Skill。

当前有哪些skill？

然后，使用 “skill-creator” 创建了 “ImageMagick Skill”。

请帮我把开源项目https://github.com/lmageMagick/lmageMagick,打包成一个Skill，方便我以后直接调用它来对我的图片素材进行处理，可以比如格式转换，分辨率修改、压缩等等

接着，用自己刚创建的 “ImageMagick Skill”，压缩图片。

请将2026-01-26_18-43.png图片转换成webp，图片大小压缩一下，并保存在原始图片同目录下。

看到这里，发现很简单是不是？

“任何可以复用的能力，都建议抽象成技能，一定要Skill化。”

大家可以动手了。

note：使用 npx skills add <owner/repo> 安装的 Skill 可以给电脑上任何 AI 工具使用。自己创建的 Skill 只限于当前的 AI 工具，但是你可以复制到一个公共目录，然后通过软连接共享给其他AI工具。

Ref

• 火爆全网的Agent Skills，普通人到底该怎么用？

刚用AI写了篇 Homebrew 周报，发现里面竟然有 Clawdbot😺。

老实说，我没有完全理解它的“价值“。

在 ChatGPT 4.0 发布没多久的时候，我发现了一个非常热门的开源项目：AutoGPT。

一开始，我感觉很神奇：AutoGPT 可以根据任务自己搜索网页、下载文件等等，一切都是自动化操作。

我被它这套动作折服，但很快被现实打脸👊，它未解决任何任务‼️。

迄今为止，AutoGPT并没有给我解决任何问题，它就像个玩具。

“后面开始接触 Cursor，是它让我感受到 AI 不是骗人的把戏。”

自从使用 Cursor 辅助编程，工作效率提升了很多，原来半天或者一天的工作，可能1～2个小时就完成了。

Cursor，值得付费。

回到 Clawdbot，去它的主页看了看，跟 AutoGPT 很像。

我完全没理解它能做什么？如果抛开 AI，它只剩下壳，如同它的logo，小龙虾🦞。

个人预计，很快就没人会讨论它，Clawdbot。

Ref

• AI 開源代理 Clawdbot 爆紅！橫掃 GitHub 9,000 星，和 ChatGPT 有何不同？
• 这里还有谁在用 ClawBot 吗？ : r/selfhosted
• ClawdBot 是我這輩子用過最強大的 AI 工具
• Clawdbot是什麼？5步驟簡單安裝教學：使用前必看資安設定指南
• [讨论] 我还是不明白 Clawdbot 的核心价值在哪里？ - V2EX

Web 端的 UI 设计师，主流都是使用 Figma，但 Figma 是商业软件，对于资金有限的 team 来说，是一笔不小的开销💰。

Penpot 是 Figma 的 free 平替，开源程度高，支持自有部署。

如果有较高要求，也可以购买他们的商业许可，获取更多功能。

在 AI Coding 的年代，Penpot 有很大缺憾、缺乏 MCP 支持，显得有点脱节。

现在官方支持 MCP，是个令人振奋的好消息。

Ref

• penpot/penpot-mcp: Penpot's official MCP Server

真正有分量的工具更新，
往往不是多给你几个按钮，
而是让你少记几件本该交给系统的事。

这一期 Homebrew 的新增，更像是在底层悄悄铺路。

本周一句话总结

没有明星级工具，
但多了一整批：
当工作流变复杂时，你会开始庆幸它们存在的选项。

本周新增工具速览

🧪 New Formulae

🧩 New Casks