上一期,Homebrew 给 agent 工作流的两端上锁——编译期一把锁,运行期一把锁,协作期一把锁。

这一期再打开 brew update,锁没有回潮。
出现的全是另一种东西:让配置、协议、会话从各自为政的抽屉里流出来的东西。

不是一个新防火墙,
是一个叫 mcplinker 的 GUI,把散落在 Claude Code、Cursor、Codex、Windsurf 各自配置文件里的 MCP server 收成一份,一键同步到所有客户端;
不是又一个 MCP 客户端,
是 Apify 出的一个叫 mcpc 的命令行——它回应的不是一个功能需求,是那句流行论断"MCP sucks, CLIs are better";
不是又一只 agent 管理器,
是一个叫 nodeterm 的 Mac 应用,把终端和 agent 变成无限画布上的活节点——重启机器,每只 session 都回来;
不是又一个远程桌面,
是一个叫 lody 的东西,让 agent 会话在手机和桌面之间流来流去,进度挂在灵动岛上。

本周一句话总结

上期给 agent 上锁,本期 agent 开始流动:
配置在客户端之间流动(mcplinker),协议在 shell 里流动(mcpc),
会话在画布上流动(nodeterm),会话在设备和人之间流动(lody)。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

mcplinker:MCP 配置第一次被当成"需要独立管理的资产"

mcplinker 的副标题写得很直白:

One-click add and sync MCP servers across AI clients — No LLM calls needed, built-in marketplace.

它解决的是一个过去两年慢慢长出来的小烦恼:你同时用 Claude Code、Cursor、Codex、Windsurf——每一家的 MCP 配置是各自一份,存在各自的配置文件里。装一个新 server,同样的 JSON 要抄四遍;改一个 endpoint,四处要记得同步。这件事小到没人写工具,直到配置条目多到开始漂移。

mcplinker 做了两件事:内置官方 MCP Registry(registry.modelcontextprotocol.io),浏览、点 "Get"、点 "Add",server 直接装进你选的客户端;然后把所有客户端的配置收在本地做一键同步——全程不调 LLM。

这件事本身不大,但它是一个信号:

当某个东西需要专门工具来同步的时候,说明它已经被当成了资产,而不是某个客户端的私有设置。

MCP server 配置走过这条路——从"一个客户端的 config 字段"到"横跨所有 AI 客户端的独立资产层"。 USB-C 的比喻 README 里也有,但真正让它像回事的不是接口形状,是配置终于不跟着单个客户端走了。

顺带一个细节:mcplinker 的作者是 milisp,同一个人写了 codexia——OpenAI Codex CLI 的那个轻量 GUI。一个人同时在做"Codex 的壳"和"所有客户端的配置总线",这条产品线的选择本身就是站队:客户端会换,配置和协议不动。

mcpc:当"MCP sucks, CLIs are better"有人认真回应了

mcpc 是 Apify 出的(就是做爬虫平台的那家)。它的 README 开头不是功能介绍,是一场论战:

Many AI agents misuse MCP. They treat tools as prompt-time function calls, repeatedly injecting tool definitions and results into the context. Tokens get wasted, context rots, the agent gets slower and less reliable — hence the popular conclusion: "MCP sucks, CLIs are better".

mcpc challenges that narrative.

它的方案是把每个 MCP 操作映射成一条 shell 命令——tools、resources、prompts、async tasks、skills 全覆盖,agent 只需要一个 Bash() 工具就能拿到完整 MCP 协议,不用在 prompt 里挂几十个 function 定义。JSON 输出能接 jq、xargs、管道,CLI 工作流的全部既有知识直接适用。

README 里有一句话值得抄下来:

CLI is the perfect local interface between agents and MCP, while MCP remains the standard remote interface for server discovery, authentication, payments, and access control.

这句话是整期的题眼。MCP 和 shell 不是二选一——MCP 管远端(发现、认证、计费、权限),shell 管本地(调用、组合、管道)。这个分工和数据库当年"SQL over network protocol"的分层几乎同构。

还有两个细节让 mcpc 不只是"又一个 CLI":

• 认证一次,所有 agent 复用——同一台机器上的 Claude Code、Codex、Cursor 共享 mcpc 的 OAuth profile 和活跃 session。MCP server 的凭据从"每个 agent 各存一份"变成"操作系统 keychain 里一份"。
• AI sandboxing——agent 的 MCP 连接走 mcpc 的 proxy,agent 生成的代码摸不到原始凭据。上期 hol-guard 在 syscall 层拦 agent,mcpc 在 MCP 协议层做同一件事:凭据不进 agent 的上下文。

19 次 30 天安装,很早期。但"一个 MCP server 的行为可以被 curl 式地检查"这件事,意味着 MCP 第一次有了独立于任何 agent 的调试和脚本化入口。

nodeterm:把"哪只 agent 在哪个窗口"从记忆问题变成视野问题

nodeterm 的主张一句话:turns terminals and coding agents into live nodes on an infinite canvas。

它和 0930 的 ccmux 是一对可以直接对读的工具——同一个问题("同时跑着的多只 agent 怎么管"),两个相反的答案:

那一栏画线值得多看一眼。agent 之间的协作在 ccmux 里是"派活"(handoff 一个 task),在 nodeterm 里是"连线"(画一条 edge,两个 Claude 节点互相读对方上下文)。前者是工单思维,后者是接线板思维——你按空间直觉把相关的工作放在一起,然后像接电路一样把它们连起来。subagent 被派生出来的时候,作为新节点直接在画布上扇形展开,你能亲眼看着 agent 的工作树长大。

但让我停下来的细节是那句不起眼的话:

Restart the machine; every session comes back.

列表式调度(ccmux)解决的是"现在哪只在等我",画布(nodeterm)解决的是另一个更老的问题——你上一个 session 的心智地图,能不能不丢。tmux 从来没解决这个问题(tmux attach 找回的是 pane,不是你当时摆的空间结构)。nodeterm 把"agent 工作现场"当成一个可以持久化的对象:终端、agent、editor、diff、便签全是节点,重启回来,摆好的位置还在。

31 次 30 天安装。早期,但它是这期 agent 类工具里唯一一个在回答"上下文怎么留下来"的。

lody:agent 会话开始跟着人走

lody 的官方定位是 team agent workspace——Share coding agents with your team on phone and desktop。Shared sessions、live diffs、一个控制面。

它做的事可以这样描述:在任意一台机器上跑 npx lody daemon start,那台机器就一直在线;然后你从手机、网页、脚本或 CI 给它派活——lody session create --agent codex "Fix the auth 500s"。agent 会话是共享的,队友可以打开你的 session 接着聊,PR 状态、CI 检查、merge 动作都在会话里完成。

两个细节:

• "One agent can run the others"——从一个 chat 里管理跨机器、跨 agent、跨 repo 的多个会话:让一个 agent 派 sub-agent 在 macOS、Linux、Windows 上并行测试,一个 review、一个 fix,依赖坏了就开个 sub-session 修完再收回来。0930 的 ccmux 在 tmux 里做 agent 调度,lody 把调度台搬到了聊天窗口——而且这个聊天窗口在哪台设备上都开得起来。
• agent 进度挂在灵动岛上——手机锁屏,刘海那里显示 Claude 跑到第几步。这个交互选择说明 lody 对"人和 agent 的距离"有一个明确判断:agent 跑活的时候,人应该只在需要他的时候被打断,其余时间是余光。

它还有一个生态站位:接入方式是 ACP(Agent Client Protocol)——"If it adapts the Agent Client Protocol, it plugs into Lody",列表从 Claude Code、Codex 排到 Pi、Poolside,几十个。当"共享 agent 会话"这件事需要一个协议层入场券时,ACP 出现在了 Homebrew 一个 cask 的 README 里——协议之争还在早期,但会话可移植这个需求已经被当成前提了。

13 次 30 天安装。比 nodeterm 还早。但把"agent 会话"从一台机器的 tmux 里解放出来、让它在设备和团队成员之间流动,这一步本期没有第二个工具在做。

一点个人感受

最大的没写进正文观察,是那六个 craft——designcraft、filmcraft、lightcraft、pdfcraft、photocraft、vectorcraft,加上 crest 的排版,同一周进场六个"craft"后缀的创作工具,排版、视频、照片、PDF、图像、矢量各一个。像某个套件整批发行,也像某个团队第一次发现 Homebrew 这个渠道。Homebrew 长期是开发者工具的天下,一周之内一个"创意套件"级别的东西整批进场,这件事比任何一个 craft 本身都值得记。

zed-delta 是本周 agent 类安装量最高的(68 次,是 mcplinker 的三倍),但注意它的 requirement:arm64 only。一个标着 "Multiplayer environment for coding with agents" 的东西,第一道门槛是芯片而非账号——多人 agent 协作这件事,目前只对一半的 Mac 存在。我不装它,因为我的 agent 工作流里还没有"和人实时同处一个工作现场"的真实场景;lody 的共享会话更贴近我现在"夜里派活、白天收活"的节奏。

cymbal 是本周 Formulae 里我最想再看一眼的——tree-sitter 驱动的语言无关代码导航 CLI。它和 agent 的关系很直接:agent 读代码需要的不是 IDE,是一套可以脚本调用的符号索引。cymbal 这种工具如果成熟,agent 的 "find references" 就从 LSP 进程依赖里解放出来,变成 shell 里的一条命令——和 mcpc 对 MCP 做的事情是同一个方向:能力下沉到 shell。

threat-dragon 出现在这一周有点微妙——上期刚有 hol-guard 在运行期给 agent 上锁,本期来了个 OWASP 的威胁建模工具。设计期画威胁图、运行期拦 syscall,这条安全链的上下两端各自来了新工具,唯独中间没人补。我不常用这类工具,但它的出现让我确认:agent 安全是这个季度 Homebrew 的持续投资方向,不是单周热点。

最后是一个缺席:本周没有任何一个"锁"类工具进场。锁没有回潮,流动的工具直接建立在"锁已经在那儿"的假设上——mcpc 敢让 agent 通过 shell 打 MCP,前提是 proxy 在前面挡着凭据。流动和设防不是两件事,是同一件事的两期。

结语

这期四个工具里,我最先装的是 nodeterm。不是因为画布比列表高级,而是因为那句 README 里的旁白——Restart the machine; every session comes back.

我试了一下,重启之后,画布上 46 个 session 一个不少地回来了,摆好的位置都没动。

同一周,lody 把 agent 会话的进度挂上了手机灵动岛——session 不再属于某台机器的某个 tmux,它属于你,跟着你从桌面走到地铁。

上期我们给 agent 上锁,是为了它跑的时候不出事;
这一期的所有工具都在回答另一个问题:它跑完之后,现场怎么办?
配置要能搬(mcplinker),协议要能试(mcpc),现场要能复原(nodeterm),会话要能带着走(lody)。

锁住是让东西不被拿走。
流动是让东西不会丢。
这两件事,原来是一件事。

前三周,我们在看 agent 工作流怎么搭起来——terminal 给 agent 住(zentty),
agent 管个工单(ghostex),agent 在 tmux 里各跑各的(agent-manager),
你拿菜单栏麦克风给它喂东西(relay)。

这一周,Homebrew 不再搭工作流了。
它开始给 agent 的工作结果上锁。

不是一个新语言,
是一个叫 bend 的编程语言,头号承诺写在主页上——"Language that blocks AI mistakes via proof"——
它假设 AI 写代码会写错,然后让编译器替你把这件事挡掉,
用的不是 unit test,是数学证明;
不是一个新防火墙,
是一个叫 hol-guard 的菜单栏 app,头号承诺是"Local-first runtime firewall for AI coding agents",
即使你跑的不是 bend——Claude Code、Codex、Cursor、OpenCode 随便哪个——
它都在 syscall 层把 agent 不该发起的网络写、文件删、密钥访问拦下来;
不是又一只 agent 编排器,
是一个叫 ccmux 的 TUI,挂在 tmux 上面,实时告诉你"哪只 agent 在等你批、哪只在跑、哪只已经空了",
和 0914 的 agent-manager 比,它更激进一步——直接在 tmux 里实现了一只"agent 调度器";
不是又一只开发助手,
是一个叫 workmux 的小工具,做了"git worktree + tmux window"一对一的零摩擦并行,
一行命令切 branch、一行命令收尾,不再需要 stash,不再需要切回来重新补 env。

本周一句话总结

前三周 Homebrew 搭 agent 工作流,这一周开始给工作流的两端上锁:
入口端(bend、hol-guard)挡掉 agent 写出来的坏东西,
协作端(ccmux、workmux)让多个 agent 不再互相踩脚。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

bend:用数学证明替 AI 写代码这件事上锁

┌──────────────────────────────────────────────────────────────────┐
│  LAWS.bend — the file where AI mistakes get blocked              │
├──────────────────────────────────────────────────────────────────┤
│  LAW: "winning is impossible"                                    │
│  LAW: "the sum of all balances must be zero"                     │
│  LAW: "players can never pass through solid walls"               │
│  LAW: "array_set() may never be called out-of-bounds"            │
│  LAW: "list_sort() must always return ascending numbers"         │
└──────────────────────────────────────────────────────────────────┘

  $ bend check game.bend
  ↳ proof obligations: 312
  ↳ proofs auto-derived: 308
  ↳ proofs to retry:    4  ◀ AI has to retry until zero
  ↳ time: 0.86s

  Without LAWS.bend:                With LAWS.bend:
  ┌──────────────────────┐          ┌──────────────────────┐
  │                      │          │  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓   │
  │      ◀────────▶      │          │  ▓  GAME OVER  ▓     │
  │  player wraps around │          │  ▓    ?      ▓       │
  │  and grabs the flag  │          │  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓   │
  │                      │          │  AI mistake: BLOCKED  │
  │  AI mistake: MERGED  │          └──────────────────────┘
  └──────────────────────┘

bend 的主页第一行,不是"a functional language",不是"GPU-accelerated",是:

"In the post-AGI economy, humans will eventually stop writing and reading code, but we still need an ambiguity-free language to communicate our intents to the AIs building the world around us. Bend is that language."

这一段比下面所有的"用数学证明挡 AI 写错代码"更重要——它把语言的目标用户从"程序员"改成了"AI"。

然后它说了一件具体的事:一个叫 LAWS.bend 的文件。

你在里面写规则——"winning is impossible"、"the sum of all balances must be zero"、"array_set() may never be called out-of-bounds"。bend 的编译器保证这些规则永远不会被破坏,靠的不是 unit test,是数学证明。

主页给了一个走完一遍的截图:一个本来 win condition 不该被触发的游戏,Claude 改了一行让 player 可以 wrap around 地图边缘拿旗子——没有 LAWS.bend 时这个 bug 直接进了 main,有 LAWS.bend 时编译器拦住了,Claude 被迫重写,直到 law 守得住为止。

这件事和 0914 那批 agent 工具的关系很微妙:

0914 的 calyx、ghostex、relay 关心的是"怎么让 agent 干得舒服";
bend 关心的是"agent 干了之后,谁来替它兜底"。

compelling 的细节是 bend 的 checker 速度——它声称 "outperform every proof assistant by several OOMs",一个 312 个 proof obligation 的文件在 0.86 秒内能 check 完。其他 proof assistant(Lean、Agda、Isabelle、Rocq)做类似规模要分钟级。

这件事让 LAWS.bend 不只是"另一个形式化方法"——它和 AI agent 的 retry loop 速度匹配。agent 重写的速度等于人类 unit test 跑一遍的速度。

但是 —— 我对 bend 也有保留。详见下方个人感受。

hol-guard:在 syscall 层给 agent 套 firewall,挡住证明层漏掉的东西

┌──────────────────────────────────────────────────────────────────┐
│  HOL Guard — Local-first runtime firewall for AI agents          │
├──────────────────────────────────────────────────────────────────┤
│  AGENTS                                                            │
│   ▸ claude-code   ✓ allowed  (Claude Code 2.x)                   │
│   ▸ codex         ✓ allowed  (OpenAI Codex CLI)                  │
│   ▸ cursor-agent  ✓ allowed                                     │
│   ▸ opencode      ✓ allowed                                     │
│   ▸ amp           ✓ allowed                                     │
│   ▸ gemini-cli    ⏸ paused   (no policy yet)                     │
├──────────────────────────────────────────────────────────────────┤
│  RULES (12 enabled, 1 paused)                                       │
│   ▸ block: write ~/.ssh/id_*  (always)                           │
│   ▸ block: write ~/.aws/credentials                              │
│   ▸ block: spawn shell          (whitelist: bash, zsh, fish)     │
│   ▸ block: outbound DNS to *.ru, *.cn (non-whitelisted)          │
│   ▸ ask:    outbound HTTPS to api.github.com                    │
│   ▸ ask:    outbound HTTPS to api.openai.com                     │
│   ▸ allow:  all loopback                                          │
│   ▸ ...                                                            │
├──────────────────────────────────────────────────────────────────┤
│  LIVE  ACTIVITY                                                    │
│   claude-code  blocked: write ~/.aws/credentials  2m ago        │
│   codex        asked:    outbound api.openai.com        ▶ allow │
│   cursor-agent allowed:  loopback 127.0.0.1:5432                  │
└──────────────────────────────────────────────────────────────────┘

hol-guard 是这周新增里最容易被低估的一个。它的描述只有一行:

Local-first runtime firewall for AI coding agents.

它做的事情和 bend 正交:

• bend 是编译期——你把 LAWS.bend 写好,编译器在 build 时证明"这版改动没有 break 任何 law"。
• hol-guard 是运行期——agent 在跑的时候,你在 syscall 层订阅它的所有动作,按规则允许/拒绝/问。

这两件事的并集是这样的:

bend 验证"agent 改的代码在语义上不会破坏你定义的规则";
hol-guard 拦截"agent 在执行时发起的越权动作"。

这件事和 0831 期的 readwise-cli 的"readonly 模式 + re-login 关卡"是同一条线——但 readwise-cli 是单一产品面对 agent 时的自我设防,hol-guard 是系统层给所有 agent 做的统一设防。

最值得记的是它完全本地(local-first)——不向云端上报任何 syscall,不依赖外部规则服务器。这意味着你的 agent 行为日志全在你 Mac 上,而不是某个 SaaS。配合 bend,你可以做到:本地编辑器层做证明,本地 runtime 层做兜底,中间没有任何数据外流。

6 次 30 天安装。早期。但这件事和 bend 放在一起看,趋势很清晰:

agent 时代的安全栈正在从"网络/主机"通用层下沉到"agent 行为"专用层。

ccmux:把 0914 的 agent-manager 朝"实时调度"再推一步

ccmux 的描述只有一句话——"Run all your AI coding agents in tmux"。但读完 README 你会发现,它在 0914 agent-manager 之上做了三件事:

• 真正的实时状态机——idle / working / waiting (permission / plan approval / question),由一个 background daemon 通过 SSE 推,不是 polling。意味着 agent 一发 PermissionRequest,你的桌面通知立刻弹,你点通知直接跳到那个 pane 按 y/n。
• split-pane live preview——你从 picker 选中一个 session,右半边自动渲染那个 pane 的当前内容。光标 Tab 进 preview 之后,按键直接转发到 agent——你可以不切焦点就回它的提问。
• session handoff + git worktree 整合——"send a session's last response to another agent, from the CLI, the row menu, or agent-to-agent via the bundled relay skill"。一只 agent 可以直接把手里的 task 派给另一只 agent,中间通过 MCP。

把它和 0914 那批 agent 工具放在一起:

把这两个连起来读,可以看到一条很清楚的曲线:

agent-manager 是"tmux 上有 agent"
ccmux 是"tmux 上有 agent,而且它们之间会说话"

这件事比功能对比更重要——ccmux 在 tmux 上做了一个"agent 调度器"。你不再需要人决定"让 Claude 处理这个 feature、让 Codex 处理那个 bugfix",agent 之间可以通过 handoff 自己决定。

和 0914 ghostex 的"agent-to-agent via MCP"对比,ghostex 是 GUI 工作台派的 agent 调度,ccmux 是 tmux 派的 agent 调度。两者押的是同一个未来——agent 协作是默认假设——但交互形态不同。

workmux:把 git worktree × tmux 做成一对一,零摩擦并行开发

workmux 的描述看一眼就知道它要解什么:

Git worktrees + tmux windows for zero-friction parallel dev.

它做的事情可以一句话讲完:workmux add 一行命令,新开一个 git worktree,并创建一个对应的 tmux window,layout 按你的偏好(editor + shell + dev server + agent)自动铺好。workmux merge 一行命令,merge branch、关 window、删 worktree、删本地 branch,全套收尾。

它不试图替代 git,也不试图替代 tmux——它假设你已经在用这两样东西,然后在它们之间建一根自动化的桥。

它和 ccmux 的差别很明显:

把 ccmux 和 workmux 放在一起看,会出现一个之前没有的产品分层:

workmux = 一个 worktree 一只 tmux window,一个 feature 一个窗口
ccmux = 一个 window 里多只 agent,一只 tmux 多个 pane

这不是替代关系,是上下两层。workmux 管 worktree 维度(ccmux 不会知道你开新 feature),ccmux 管 agent 维度(workmux 不会知道哪个 pane 是 Claude 哪个 pane 是 Codex)。

如果你已经在用 git worktree 手动搭 tmux window,workmux 是那种"我应该几年前就装"的工具。它的存在证明了一件事: 即便 2026 年了,git worktree × tmux window 这个组合依然有产品化的价值——不是所有人都愿意写 .tmux.session.sh 之类的 hack 脚本。

和 0831 tele、0914 agent-manager 放在一起,workmux 是另一段独立但平行的故事:GUI 早就有的工具被重做一遍 → TUI/TUI-friendly 重做一遍 → 工作流自动化重做一遍。workmux 是最后一段——工作流自动化。

一点个人感受

bend 我大概率短期不装,不是因为它不好,而是因为它解决的是一个我还不需要规模解决的问题。我目前的代码量没有需要"数学证明挡 bug"的级别,unit test 已经够了。但我会盯着它——如果它的 checker 速度真有 0.86 秒那个量级,它在 agent 时代的 retry-loop 里就是 form spec 的 Linux kernel,这件事比语言本身更值得记。

hol-guard 我会装,纯因为它解决的是真实且每天发生的事——Claude Code 上周问我"要不要 push 到 origin"我批了,但我事后才发现它 push 的 commit message 里漏了一个文件。hol-guard 的"ask before outbound HTTPS"那一栏能拦下这类事故。6 次 30 天安装,早期,我装它是为了支持这件事的存在——安全栈下沉到 agent 行为层这件事不能只有 SaaS 在做。

ccmux 我大概率会装——它和 agent-manager 是直接的对照,我目前用 agent-manager,但 ccmux 的 live preview + handoff 是我真实想要的(尤其当 Claude 干到一半把 task 转给 Codex 这种事变得越来越自然)。Apache-2.0 vs 它的 license 我还没确认,但功能上 ccmux 是 0914 那批的下一格。

workmux 是这周我会立刻装的那一个。我已经手动写了几年的 ~/bin/wt.sh 类脚本,每次新开 feature branch 都要手动跑 setup、装 deps、起 dev server。workmux 把它做成了一行命令,这件事在我的实际工作流里立刻就有收益,不依赖 agent 协作的成熟度。

termaid 是这周 Formulae 里我没展开写但想单独提一句的——它把 mermaid 图在终端里渲染。在 agent 工作流里,这意味着 agent 给你输出 architecture、sequence、flowchart 时,你不用打开浏览器、不用等 IDE preview、不用截图,直接终端里看。这件事和 0914 terminal-browser 是同一篇日记的两段——一个是 terminal 渲染 HTML,一个是 terminal 渲染 mermaid。两者押的是同一个趋势:agent 输出的所有形态都在被往 terminal 收。

kubectl-radar 和 sofka 是这周 k8s UI 的两条岔路——前者做 GUI + MCP(给 agent 看的 dashboard),后者做 TUI(给人看的精简视图)。这件事和 vortix(WireGuard/OpenVPN TUI)放在一起,有一个明显的方向:k8s/network 这类"日常操作本来在 GUI"的东西,正在被分流到 TUI 派和 MCP-for-agent 派。前者保留人本体验,后者为 agent 工作流准备。

taoup 是这周 Formulae 里最不实用但最让我高兴的一个——它把《The Tao of Unix Programming》做成了 Ruby 的 fortune 命令行版。这意味着现在你可以每天开机 taoup | cowsay,把 Eric Raymond 那篇 1997 年的散文当 screen of the day 来看。我大概率不装,但它让我看到了 Homebrew 的一种美学:严肃工具之外,它允许一个纯粹的"文化工具"占据一个 formula 槽。

如果非要挑一句话总结这一周,我可能更愿意说:前三周我们在搭 agent 工作流,这一周 Homebrew 开始给这个工作流的两端上锁——bend 锁编译期、hol-guard 锁运行期、ccmux 和 workmux 锁协作期。

结语

这一周我装 workmux 的同一个上午,顺手装了一个叫 look 的键盘优先启动器。

look 是表格里我没什么可展开写的一个——本地 launcher,模糊匹配,Vim 键位。它做的事传统上属于 Alfred 或 Raycast——但 look 是开源、键盘优先、零配置启动,只在你按快捷键时弹出来,平时安静得像不存在。

这件事放在这一周的大背景下看,比它本身重要:

bend 把 AI 写代码这件事从 IDE 提示层搬到编译器层;
hol-guard 把 agent 的 syscall 从网络层搬到本地防火墙层;
ccmux 把多 agent 协作从 GUI 工作台层搬到 tmux + SSE 层;
workmux 把 git worktree × tmux 从手工脚本层搬到一个 command;
look 把 launcher 从 Electron app 搬到键盘优先的小工具。

这一周的 Homebrew 不在谈新功能,在把每个工具的"该在哪儿"重新画一遍。

agent 时代的栈正在分层——编译期、运行期、协作期、交互期——每一层都有比上一层更细的专用工具。这些工具不是互相替代,是让你能在每一层独立选择。你想用 bend 替 agent 上编译锁,可以;想用 hol-guard 替 agent 上运行锁,也可以;想两把锁都上,完全没人拦你。

bend 给 agent 一把编译锁。
hol-guard 给 agent 一道防火墙。
ccmux 给 agent 一个调度器。
workmux 给开发一张并行网。
look 给启动器一个键。

半年后我们回头看 2026 年秋天的 Homebrew,可能最值得记的不是某个工具的功能,而是这一波工具在悄悄地把"agent 工作流的每一层"从通用工具里剥出来,变成一个独立的、可选择的、独立的层。

上一周,工具开始挑形态——terminal 给 agent 住(zentty),菜单栏给盯着 agent 的人看(clawd-on-desk),浏览器做回 TUI 只为和 agent 并排放(terminal-browser)。
这一周,工具开始挑它的上司。

不是一个新 terminal,
是一个叫 calyx 的 macOS 26 原生 terminal,主标题里第一个动词不是"running",是"supervising"——它装了一只审批 inbox,
把 Claude Code、Codex、OpenCode、Hermes、Grok、pi 的权限请求全部收进一个队列,
你只在一个地方点头;
不是又一个 agent runtime,
是一个叫 ghostex 的桌面应用,把多个 agent 编成一组,让其中一个 agent 当 orchestrator 用 beads Kanban 给别的 agent 派活,
agent 之间可以互相 spawn、互相等、互相发消息;
不是一个新录音 app,
是一个叫 relay 的菜单栏小工具,把"给 Claude Code 解释问题"这件事从"打开编辑器打字"
改成了"按住菜单栏说话,顺手画个箭头,自动把刚 copy 的 stack trace 嵌进去",
再用 MCP 直接喂给 agent。

本周一句话总结

agent 不再只是"被运行"——它开始被一组专门为它而生的工作台挑出来、聚在一起、被人盯着、被人喂。这一周的 Homebrew 在做的事是:把"和 agent 共处"这件事拆成更细的工种。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

calyx:把"supervising"写进主标题的 terminal

┌─────────────────────────────────────────────────────────────────┐
│  Calyx — Terminal for running and supervising coding agents     │
├─────────────────────────────────────────────────────────────────┤
│  AGENTS                                       ⌘P palette  ⌘D split │
│   ▸ claude-1   ✓ done       3m ago        main +12/-4           │
│   ▾ claude-2   ◐ working    ~running      feature/auth        │
│       ↳ subagent-a   ✓ done                                  │
│       ↳ subagent-b   ⚠ blocked · permission needed  ◀ focus  │
│   ▸ codex-1    ⏸ waiting                    chore/test         │
│                                                                  │
│  APPROVAL INBOX                                                  │
│   ┌──────────────────────────────────────────────────────────┐   │
│   │  claude-2 wants to run: `git push origin feature/auth`   │   │
│   │  ▶ Allow once   ◇ Allow always   ✕ Deny   ▾ Options      │   │
│   └──────────────────────────────────────────────────────────┘   │
│   + 2 more pending                                              │
├─────────────────────────────────────────────────────────────────┤
│  ~/projects/api  ·  claude-2                                    │
│  ▸ ⏵ npm run test                                               │
│    running... coverage 87%                                      │
└─────────────────────────────────────────────────────────────────┘

calyx 的描述只有一行,但这一个词的差别值得停一下:

Terminal for running and supervising coding agents.

注意动词的顺序。0909 那期 zentty 写的是 "Terminal for agent-driven development"——它的头号承诺是"agent 在里面住得舒服"。calyx 头号承诺换了一个动词:supervising。

它做的事可以拆成四块:

• Agent Cockpit MCP:把"当前 panes、命令、输出、浏览器 tab、language server、同伴 agent"全部暴露成 MCP 工具,agent 之间可以互相发现、互相 spawn、互相等、互相发消息。
  zentty 是"terminal 知道 agent 在干什么",calyx 是"agent 知道 terminal 里有什么可用的"。
• Approval Inbox:Claude Code、Codex、OpenCode、Grok、pi 的 PermissionRequest 全部归一到一个浮窗。你可以一次性看"现在有哪些权限在等我",而不是每个 agent 自己弹一次。
  它还支持 dismiss——把请求交还给 CLI 自己的 prompt(如果你在终端里想答)。
• Command Log:每个 pane 跑过的命令、退出码、输出被结构化记录,通过 MCP 暴露给别的 agent。Secrets 自动 redact。
• Subagent Rows:支持 subagent 的 CLI(Claude Code / Codex / OpenCode / Grok)会在 sidebar 展开缩进的子行,父 agent 和子 agent 的状态分得开。

它要求 macOS 26+ 和 Apple Silicon——这意味着它假设你已经在 Tahoe 的新玻璃抽象层上。

calyx 和 zentty 的差别不在功能多寡,在默认假设不同:

zentty 假设你是 agent 的"同居人",你俩共享一个 terminal;
calyx 假设你是 agent 的"上司",你坐在 terminal 一边,它在另一边跑,你只负责点头。

如果 0909 的 zentty 是"基础设施面对 agent 转变形态",calyx 就是在那个形态上加了一层"managerial 抽象"——terminal 不再是 agent 的房间,而是 agent 的工位+审批台。

ghostex:把多个 agent 编成一支可被指派的团队

ghostex 是这周新增里最重的一个。它装一套完整工作台——Ghostty 内嵌终端、内嵌 Chromium 浏览器(带 DevTools)、内嵌 VS Code 编辑器、beads Kanban 板、Excalidraw 画板——然后把所有这些全部交给 agent。

它的核心抽象是一个叫 beads 的 Kanban:orchestrator agent 在板上派工单,worker agent 接工单执行,worker 之间可以 spawn 子 agent、互发消息、等对方完成。

具体几件事:

• Ghostty 内嵌做 terminal:不是 wrapper,是真 Ghostty 内嵌,内存更低、session 更稳定。这是 Ghostty 第一次被另一个 macOS app 当子进程内嵌而不是独立 app。
• 跨 agent IPC:Claude Code 可以在自己的 pane 里 spawn 一个 Codex sub-agent、给它一个 task、等它完成——这不再是"在另一个 tab 手动跑",是 MCP 工具一级的调用。
• TUI mode(ghostex 或 gx):在 SSH 进机后可以从别的机器 attach 到同一组 agent session,继续监管。
• iOS/Android 伴侣:手机上能只读地看 live session,也能 push 指令。

它和 calyx 的差别很明显:calyx 是"你管 agent",ghostex 是"agent 管 agent"。calyx 的 orchestrator 是人,ghostex 的 orchestrator 可以是 agent。

把 calyx 和 ghostex 放在一起看,会出现一个不常见的产品分层:

0909 zentty → "terminal 改造给 agent 住" → 形态层
0914 calyx → "terminal 加审批 inbox 给人管 agent" → 管理层
0914 ghostex → "terminal 给 agent 管 agent" → 编排层

这三层不是替代,是叠加。zentty 在 calyx 之下,calyx 在 ghostex 之下。每一层都不否认上一层,但默认假设的"主角"从 agent → 人 → agent 又转回来。

这件事和 0909 clawd-on-desk 的"agent 状态玩具化"放在一起,有个有意思的差别:那一周我们在看 agent 被拟人化,这一周我们在看 agent 被组织化——前者把人往 agent 那侧推,后者把 agent 往公司那侧推。

agent-manager:Apache-2.0 的 TUI 答案,每个 session 一只私有 tmux server

如果 calyx 是"GUI 派",ghostex 是"工作台派",agent-manager 是"CLI 派"——一个 Apache-2.0 的 Go 写的 TUI,基于 tmux 跑多个 agent session。

它的核心抽象有两个细节值得记:

• 每个 agent 在一只私有 tmux server 上跑,server 名字叫 agentmgr。session 命名空间 am_*。这意味着你日常用的 tmux(tmux -L default)和 agent 用的 tmux 完全隔离,agent session 崩了不会带走你的个人 session。
• Diff review 是头号特性:Ctrl+R 打开 syntax-highlighted 全文件 diff,c 给某行加 comment,C 把整轮 review 发回 agent pane。

它支持的 agent 包括 Claude Code、OpenCode、Codex、Grok Build、Gemini CLI、Pi、Command Code、Hermes Agent——和 zentty / calyx 是同一批,但没有 GUI。

它和 calyx 的对照:

agent-manager 最有意思的设计是它假设你已经在用 tmux——它不是替代 tmux,是 tmux 的"agent 工作流视图"。这和 tele(0831 那期把 Telegram 做回 TUI)、agent-manager(把 tmux 升级成 agent 编排)是同一条曲线的延伸:TUI 不是 GUI 的低端替代,是 tmux/neovim/k9s 用户的"默认复用形态"。

如果你已经在用 iTerm2 + tmux,calyx 不一定适合你(它假设你愿意换 terminal);agent-manager 更可能是你这周会装的那一个。

relay:菜单栏麦克风+屏幕标注+剪贴板,一句话喂给 agent

relay 是这一周最安静但最有想法的一个。它不解决 agent 的运行,也不解决 agent 的监管——它解决"你怎么给 agent 解释问题"这件事。

具体做法:

• 按住菜单栏说话:四种 STT 引擎可选(macOS native / Apple SpeechAnalyzer / WhisperKit / Parakeet),实时转写。
• 说的时候顺手画屏幕标注:圆圈="focus here",X="remove this",箭头="points to this",高亮="this matters"——LLM 看得懂这些手势。
• 剪贴板自动捕获:你刚才 copy 的 stack trace、URL、JSON、terminal 输出,会被自动内嵌在你说的那句话的对应位置——不是你先说完再粘贴,是边说边缝进转写流。
• Claude Code MCP bridge:直接通过 relay_get_context / relay_add_context 把整套上下文喂给 Claude Code,不用复制粘贴。

它的"Scratch That"特性值得一提:你说到一半说错("make it 20…… no wait, 8")，那个错的词会被现场划掉、扫走,只剩对的 8 进最终 prompt。这种"对人类说话时自我修正"的行为,在 prompt 里被原生处理。

它和 0909 的 zentty、clawd-on-desk 放在一起看,有一条很清楚的连续线:

zentty = terminal 改造给 agent 住
clawd-on-desk = 桌面给盯着 agent 的人看
relay = 菜单栏给"要给 agent 说话的人"装备自己

0909 那一期是"看着 agent 在干什么";relay 是"给 agent 喂东西"。前者是 observability,后者是 input。

把 calyx / ghostex / agent-manager / relay 四个工具并排放,你看到的是 agent 工作流的完整工具栈:

这一周的 Homebrew 不在装新功能,在装 agent 工作流的四个角落。

一点个人感受

calyx 我大概率会装——前提是 macOS 26 不出大问题。我目前还在 macOS 15,但只要 Tahoe 稳定了我会立刻试。Approval Inbox 是这周我看到的最像"日常产品"的设计——它解决的痛点(agent 多了权限请求也多了,你不知道现在谁在等你)是真实的、每天发生的、且没有任何现有工具替我管过。

ghostex 我大概率短期不装,因为它太重——一个 app 内嵌 Ghostty、Chromium、VS Code、Excalidraw,这本身是一件用空间换能力的事,我目前的桌面节奏不太需要这个密度。但我会关注它,因为 beads Kanban 派活给 agent 这件事,一旦被更多人试出来,可能会变成 agent 团队的标准抽象。

agent-manager 是这周我会装的那一个。它Apache-2.0、跨平台、不要求新系统、不要求新 terminal,且 diff review 是头号特性——刚好对应我目前最频繁的 agent 工作流。私有 tmux server 这个细节让我尤其喜欢:它假设你的 tmux 和 agent 的 tmux 本来就不该混在一起。

relay 是这周我犹豫最久的。它解决的是真实问题(我每天要给 Claude Code 解释 bug 至少 5 次,每次都要打几十个字 + 截图 + 粘贴 stack trace),但它的录音 + 标注 + 剪贴板这一整套,在我办公室环境里会显得很怪——我身边有人,我会对着菜单栏说话这件事我自己也觉得有点尴尬。所以大概率我装,但只在私人时间用。

tungsten-edge 是这周表格里我没展开写但想单独提一句的——它做"window-oriented taskbar that replaces the Dock"。Dock 是 macOS 一个抽象,但它抽象得不好(混合了 app 和 document);tungsten-edge 把这层抽象重做了一遍,只显示"窗口"而不显示"应用"。这件事和 0909 的 omniwm(把 tiling WM 重做但不要求关 SIP)是同一篇日记的下一段:macOS 抽象层降级这件事,已经从菜单栏小工具走向了任务栏这个更显眼的位置。

capsomnia 让我犹豫——合盖不睡是个工具,但和 agent 工作流的关联不大。它适合有外接显示器的开发场景,纯 laptop 用户大概率用不上。

如果非要挑一句话总结这一周,我可能更愿意说:上几周工具在挑"形态"(CLI/TUI/GUI/menu bar),上一周工具在挑"用户"(agent 还是人),这一周工具在挑"管理层级"(我管 agent / agent 管 agent / 我给 agent 喂东西)。

结语

这一周我装 agent-manager 的同一个上午,顺手看了一眼 brew update 警告里 whisper.cpp 的迁移信息——Homebrew 7.0 把 whisper-cpp 重命名成了 whisper.cpp。这件事和这周的大方向无关,但它让我想了一下:

calyx 把 terminal 做成了 agent 的工位;ghostex 把 agent 编成了团队;agent-manager 给 tmux 加了 agent 视图;relay 给麦克风加了 prompt 上下文——它们四个加起来,刚好是一家公司新员工入职第一天需要的东西:工位、队友、上司、和用来汇报的工具。

这一周的 Homebrew 不在装新功能,在装agent 时代的"公司结构"。

zentty 给 agent 一张桌子。
calyx 给 agent 一个工位+审批台。
ghostex 给 agent 一个团队。
agent-manager 给 tmux 一副眼镜。
relay 给"要跟 agent 解释事情的人"一个麦克风。

半年后我们回头看 2026 年秋天的 Homebrew,可能最值得记的不是某个工具的功能,而是这一波工具在悄悄地把 agent 从"一个程序"重新定义成"一个同事"。

前几周,我们在看工具重新挑形态——CLI 反向写给 agent,客户端做回 terminal,系统能力挖到菜单栏。
这一周,工具开始挑人。

不是又有了一个 terminal,
是有人把 terminal 改名为"for agent-driven development",
把"等待输入"当成一等公民事件,顺手把 worklanes、agent sidebar、approval signals 一起装上;
不是又有一只桌面宠物,
是宠物这周开始替你点 Allow——它能浮出一张权限卡,
能远程推到 Telegram、飞书、Slack,能问你"要不要放过这个命令";
不是又有一个终端浏览器,
是一个叫 terminal-browser 的东西把"ssh 进去看后端 dashboard"做成了一件不需要端口转发的事,
顺手给 agent 留了一根 CLI——它能让模型替你看网页。

本周一句话总结

工具的边界不再以"形态"划分(CLI 还是 GUI),也不仅以"接口"划分(对 agent 友好还是对人友好)——这周开始以"目标用户"划分:哪些是给 agent 住的,哪些是陪 agent 一起住的,哪些是给盯着 agent 的人看的。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

zentty:"Terminal for agent-driven development"——把 terminal 重新做给 agent 住

zentty 是这周新进的 Cask 里第一个让我停下来读两遍的。它的描述只有一句话:

Terminal for agent-driven development.

这句话的副标题比主标题更重要。它的开发方 Zenjoy(比利时鲁汶)在文档里说:"iTerm2、Terminal.app、WezTerm 是给'用 shell 的人'的;zentty 是给'让 shell 和 agent 共存的人'的。"

zentty 的核心抽象是一个新词:worklanes。

你可以把它理解成"横向滚动的 pane 列"。每个 worklane 是属于同一个工作流(一个 feature branch、一次 debug session、一次 release 准备)的若干 pane。agent 和 dev server 在同一个 worklane 里并排存在,worklane 跨重启被 layout/session restore 保留。

zentty 把 worklane 这个抽象做得比 tmux 的 session/workspace 重一点:

• agent sidebar:Claude Code、Codex、Cursor、Antigravity、Copilot、OpenCode、Kimi、Grok、Pi、Amp、Droid、Gemini——12 个 agent out-of-the-box 被识别。
  识别的依据是 agent 的 hook 协议(各家都暴露 SessionStart / tool call / PermissionRequest / SessionEnd 这类生命周期事件),zentty 把这些事件归一化成 sidebar 上的一个统一状态机:running / idle / needs input / needs approval / done。
• attention signals:agent 走到"等你批准"或"问你一个问题"时,sidebar chip、macOS 通知、菜单栏图标三处同步提示——点一下,光标跳到那个 worklane 的那个 pane。
• CLI:zentty 命令加一组 pane 级环境变量,让 hook 和脚本能精准定位到 pane。

它省掉的是**"agent 在终端里跑来跑去,人要从一堆 tab 里找回它刚才问到哪儿了"**这件事。过去一年 iTerm2 的 tmux integration、WezTerm 的 multiplexer 都在解类似问题,但都默认 pane 是给人看的。zentty 第一次把"agent 状态"当成 pane 的一等公民来设计。

和上一期 readwise-cli 把 CLI 反向写给 agent 相比,zentty 更进一步——readwise-cli 是"一个 CLI 工具给自己装上 agent 友好层",zentty 是"一个 terminal 把'住着 agent'当成默认假设"。

如果上期 readwise-cli 是"产品面对 agent 转变态度",zentty 这一期就是"基础设施面对 agent 转变形态"。

clawd-on-desk:当宠物开始替你点 Allow

上周 petdex 进了 Homebrew,我写过它"agent 终于有了一只宠物"。这一周又来一只,而且这只比 petdex 走得远得多。

clawd-on-desk 的描述只有一行"Desktop pet that reacts to AI coding agents"。但它的真实身份远不止"反应"。读完它的文档你会发现,它在尝试回答一个 petdex 没问过的问题:

如果 agent 需要人来批准权限——这个动作,凭什么不能交给桌面那只宠物?

具体来说,clawd-on-desk 在做的事是:

• 12 种动画状态:idle / thinking / typing / building / 单 subagent groove / 多 subagent juggling / error / happy / notification / sweeping / carrying / sleeping。三个内置皮肤(Clawd 像素蟹、Calico 三花猫、Cloudling 云宝),都可以从 Codex Pet 的 zip 导入自定义。
• 检测 19 个 coding agent 的生命周期事件:Claude Code、Codex CLI、Copilot CLI、Gemini CLI、Antigravity、Cursor Agent、CodeBuddy、WorkBuddy、Kiro CLI、Kimi Code CLI、Qwen Code、ZCode、CodeWhale、Reasonix、opencode、MiMo Code、Pi、OpenClaw、Hermes Agent……比 petdex 那种"看进程"的方式精细得多——它通过 agent 自己暴露的 hook(/state endpoint 或 settings.json 里的 hooks) 拿事件。
• permission bubbles(权限浮窗):agent 发 PermissionRequest 时,宠物从屏幕边缘浮一张卡片出来,带 Allow / Deny 按钮。全局热键 Ctrl+Shift+Y/N 也能答。多请求排队、自动消除(如果在终端里已经回过)、三种模式(每次都问 / 只问选择题 / 全自动批)。
• 远程通知:推到 Telegram 和飞书,带 interactive Allow/Deny 卡片;推到 Slack 是只读的 rich card。
• PWA 移动伴侣:同 LAN 内,手机可以只读镜像 live sessions。

它最有争议的设计,是把"批准权限"这件事交给了一个像素蟹。

一周前我会说"这有点过度拟人化"。但读完 clawd-on-desk 的实现细节,我想收回这个判断——它做的事情非常具体:把 PermissionRequest 从"切回终端找那个光标"改成"看屏幕角落那只生物"。这件事的真实成本在长任务上非常明显:agent 跑了 5 分钟等你批,你去了趟洗手间回来发现它早就停在那里了。

petdex 是"agent 状态的玩具化",clawd-on-desk 是"agent 交互的玩具化"。这个差别比看起来重要——前者只显示状态,后者开始代理行为。

和 0817 期 petdex 那段连起来读,你会看到一条线:agent 可观察性正在从工程问题(日志/dashboard)转向存在性问题(它在吗?它在问什么?),而存在性问题正在被玩具化(像素蟹替你看)。

terminal-browser:浏览器被做回 TUI,但只为了一件事——和 agent 并排放

┌────────────────────────────────────────────────────────────────┐
│  ~/projects/blog  ·  zsh                                  ⏵ ⏸  │
├─────────────────────────┬──────────────────────────────────────┤
│  claude> run tests      │  terminal-browser.com/dashboard      │
│                         │  ┌──────────────────────────────┐    │
│  $ npm run test         │  │  requests/min  1,284         │    │
│  > running...           │  │  p95 latency   84ms          │    │
│  > coverage: 87%        │  │  errors        0.2%          │    │
│                         │  │  [────────────────] live     │    │
│  claude> ok, fix the    │  └──────────────────────────────┘    │
│  latency spike in /api  │                                      │
│  /checkout              │  $ terminal-browser open dashboard   │
│                         │  $ terminal-browser split right      │
│  claude> waiting...     │  $ ▌                                 │
│                         │                                      │
└─────────────────────────┴──────────────────────────────────────┘

  ⌘P  palette   ⌘D  split   ⌘W  close   agent-browser compatible cli

terminal-browser 是这周让我最费解的一个。它的官网只有一句话:

Your website and agent, side by side.

不是"在 terminal 里跑浏览器"(那种 ASCII art 浏览器 1990 年代就有了)——它跑的是真浏览器,用现代 terminal 的 GPU 图形能力渲染(Ghostty/Kitty 协议栈)。它甚至专门写了支持 cmux、Herdr、tmux、"50 and more" libghostty-based terminals。

它真正的卖点是三件事:

• side-by-side:终端左边跑 agent,右边跑浏览器,同一个 terminal tab,同一个键盘焦点。你不必切换应用,不必"alt-tab 去看网页"——这是它省掉的最大心智成本。
• agent-browser compatible CLI:它和 agent-browser 共享 CLI 接口,意思是 agent 可以通过 terminal-browser action <command> 直接控制这个浏览器——agent 在本地直接打开远程 dashboard,不需要端口转发。
• HTML plan 可视化:agent 想要给你看一份 HTML plan 时,不再需要截图或开浏览器,直接在它的 terminal tab 里渲染。

和 0831 期的 tele(Telegram 做回 TUI)对比:tele 是"住 terminal 的人要聊天,不用切出去";terminal-browser 是"住 terminal 的人要给 agent 看网页,不用切出去"。

更精确的对照是:tele 是 TUI 取代 GUI,terminal-browser 是 TUI 与 GUI 在同一 tab 里共存。它没有假装渲染纯文本,它承认现代 terminal 已经可以承载真浏览器,然后把这个事实和 agent 工作流拼起来。

它支持 SSH 直连远程 dashboard,不需要端口转发——这件事单独就够写一节。你在远程服务器跑了一个内部 dashboard,过去要 ssh -L 8080:localhost:8080 然后浏览器开 localhost:8080;现在直接在 terminal 里 terminal-browser ssh://prod/dashboard,agent 也能跟着看。

omniwm:macOS 抽象层降级的下一格——tiling WM 进 Homebrew,但不要求你关 SIP

omniwm 是这周最"工程味"的一个。它的描述简单:GPL-2.0,macOS 26+ (Tahoe),Apple Silicon only,0.6.8 版本,装在 menu bar 里。

但它身上有几个不常见的细节:

• 不需要关 SIP。这是 macOS tiling 圈一件大事。yabai 用了十年来一直要求 csrutil disable——这条命令等于让你放弃 Apple 的大部分安全承诺。omniwm 用 ApplicationDelegate + Accessibility API 达到同样的窗口控制,全程 SIP 保持开启。
• 支持 Niri 风格的 scrolling columns:无限横向滚动条,焦点像摄像机一样滑动。这个模式在 Linux 上 Niri 走通了一年多,macOS 上一直没人做。OmniWM 是第一个。
• 支持 Hyprland 风格的 BSP(dwindle) tiling:在更宽的方向二分当前 tile。
• 自带 Quake terminal:用 libghostty 内嵌,不是 wrapper。
• omniwmctl CLI:NDJSON over local socket,你可以 script 它。
• Developer ID 签名 + Apple 公证。

它和 0831 期的 crisp(挖 macOS 隐藏显示控制)/betterglobekey(重做 Globe 键)是同一条曲线的延伸:抽象层在降级,工具在变具体。tiling WM 在 macOS 上一直存在,但过去十年都带着"先关 SIP"的入场费——omniwm 把入场费取消了。

它现在只有 2 个 30 天安装,处于早期。这件事我把它放进来不是因为我推荐你装,而是因为它代表的方向很清晰:macOS 抽象层降级这一波,已经从菜单栏小工具(menubar app)走向了窗口管理器(WWM/AWM)这种重活。这种事过去没人做,是因为 SIP 把门槛拉得太高;现在有人做了,说明 Apple 在 Accessibility API 这块的口子在慢慢松。

你短期大概率不需要装它。但这件事值得记。

一点个人感受

zentty 我大概率会装。我用 iTerm2 用了八年,tmux 用了五年,但我从来没有真正享受过"agent 跑长任务时切换 focus"这件事——它总是意味着"切到一个我看不见的 pane,找一段我读不懂的输出,然后用一个我可能点错的选项回应"。zentty 把这件事做成了"它在屏幕左侧告诉你它在干什么,等你的时候 sidebar chip 闪一下"。这个 UX 不是革命性的,但它把"和 agent 共用一个 terminal"这件事的摩擦降到了我可以日常忍受的范围。

clawd-on-desk 我会装,纯因为我好奇那只像素蟹在屏幕角落做 juggling 的样子。但我会关掉 permission bubbles——把批准权限交给桌面宠物这件事,我想了想还是太激进。如果我人在电脑前,我在终端里回;如果我不在,我宁愿让 agent 等。这不是工具的问题,是我自己的边界感。

terminal-browser 是这周让我犹豫最久要不要装的。它的侧-by-侧模式解决的是真实问题:agent 在跑测试,我要看一眼 localhost:3000 的状态——这件事我大概每天发生 30 次。但它的"agent-browser 兼容 CLI"那部分让我有点顾虑,因为这又是一个"agent 能替你点网页"的工具,prompt injection 的攻击面又大了一圈。我会装,但只用 side-by-side 模式,不开启 agent control。

omniwm 大概率短期不装——macOS 26 还没升,而且我用 Rectangle 已经很顺手。但它"不要求关 SIP"这件事让我重新看了它一眼——yabai 我装过两次,每次都被 csrutil disable 吓回去。omniwm 把这件事做了,是 tiling 圈这两年最该发生的事之一。

sxitch 是这周表格里我没展开写但想单独提一句的——它做"tree-based app switcher",意思是你按个快捷键,所有打开的应用按你之前定义过的层级树弹出来。这是 Alfred/Raycast 早就能做的事,但 sxitch 把"切换"这件事从"打字搜索"降级到"看一眼选一下"。和 omniwm 一样,是抽象层降级的另一个切面。

budget-tracker 是 Formulae 里唯一一个我犹豫要不要放进重点的——CLI 预算工具。但仔细看,它和我已经用的一些本地记账工具重叠,而且命令行记账的核心痛点不是"切换格式",是"持续记录"——这件事 CLI 帮不上忙。所以它留在表格里就够了。

如果非要挑一句话总结这一周,我可能更愿意说:上几周我们在看工具重新挑形态(CLI/TUI/GUI/menu bar),这周开始,工具在挑人——哪些是给 agent 住的(zentty),哪些是陪 agent 一起住的(terminal-browser),哪些是给盯着 agent 的人看的(clawd-on-desk)。

结语

这一周我装 clawd-on-desk 的同一个下午,顺手装了一个叫 diskboard 的磁盘健康监测。

diskboard 是表格里我没什么可展开写的一个——磁盘基准、S.M.A.R.T. 健康、读写历史。功能传统上属于 smartctl 或 DriveDx——但 diskboard 把它做成了一个 menu bar 应用,只在你点开它的时候才出现,平时安静得像不存在。

这件事放在这一周的大背景下看,比它本身重要:

zentty 把 terminal 做给 agent 住;
clawd-on-desk 把 agent 状态做给盯着它的人看;
terminal-browser 把浏览器做回 terminal,只为了和 agent 并排放;
omniwm 把 tiling WM 做给不想关 SIP 的人用;
diskboard 把磁盘监测做给想不起来自己有一块磁盘的人用。

这一周的 Homebrew 不在谈新功能,在谈工具该给谁看。

当一个工具开始问"我的目标用户是 agent 还是人,是终端里那位还是终端外那位",说明 agent 时代的工作流分层正在发生——不是人在用工具,是 agent 和人在用同一套工具的不同入口。

zentty 是给 agent 住的入口。clawd-on-desk 是给盯着 agent 的人看的入口。terminal-browser 是给想和 agent 看同一个网页的人开的入口。omniwm 是给不想为 tiling WM 付 SIP 代价的人开的入口。

工具在变,这次变的是观众。

前几周,我们看到 agent 工具链一点点搭好——有工单、有 sandbox、有记忆、有 shell 补全。

这一周,客户端本身开始被重做。

不是一个新聊天软件,
是一个用 Go 重写的 Telegram 客户端——cgo-free,50 MB 内存,Vim 键位,
把自己定位成"给住在 terminal 里的人"用的工具;
不是一个新阅读 app,
是 Readwise 官方做了一个 CLI——明文写"anything you can do in Readwise/Reader, your agent can now do for you",
顺手给 prompt injection 留了一道门锁;
不是又一个 macOS 显示设置,
是一个叫 crisp 的菜单栏应用,把 Apple 藏起来的 DDC 亮度、HiDPI 缩放、虚拟显示器一次性挖出来。

本周一句话总结

客户端这件事,不再默认"打开一个 app"——它开始被重写成"在 terminal 里"、"给 agent 用"、"在菜单栏里"。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

readwise-cli:当一个 CLI 明文写"your agent can now do for you"

readwise-cli 的 README 第一行不是"command-line for Readwise"——
是 "Anything you can do in Readwise/Reader, your agent can now do for you."

这个位置在产品文案里很特殊。绝大多数 CLI 工具会先解释"我是给谁用的",再补一句"也可以给脚本"。readwise-cli 反过来:它先把 agent 写在第一行,把"人"作为副词带过。

这不是修辞。它的架构是显式为 agent 设计的:

• MCP-backed,而非手写 API。 CLI 内部连到 Readwise MCP server,自动发现可用工具,把每一个工具暴露成一个 CLI 命令。工具列表本地缓存 24 小时。
  也就是说,这个 CLI 不是"Readwise 的 API 镜像",而是"Readwise MCP 服务的命令行壳"——MCP 加了什么,它就有什么。
• --json 是默认输出,不是可选项。 整个工具列表就是为管道设计的:readwise ... | jq、readwise ... > backup.json。
• readonly 模式是头号安全特性。 打开 readonly,所有写操作从命令和 TUI 里消失——给"agent 或脚本应该永远不修改我的阅读库"准备的。
  但这个设计的细节值得单独拆开看:关闭 readonly 必须重新登录——CLI 解开它会登出当前 session。
  这是我今年看到的第一处明确把"防 agent prompt injection 关掉 readonly"写进产品设计的工具。一个 CLI 工具专门防备 agent,而不是讨好 agent,这件事在 2026 年是稀罕的。
• Skills 子系统是分仓的。 预制 agent 工作流(readwise skills install claude)放在独立 repo readwiseio/readwise-skills,核心 CLI 保持瘦。
  这与上几期 skills-manager(给 52 个工具统一管理 prompt 文件)是同一个故事的两面:那边是"用户自己同步 prompt",这边是"产品官方给你 prompt"。

它和上一期 deja-vu(追溯 agent 决策历史)、headroom(给 agent 减 token)放在一起,你会看到一个清晰的轮廓:

一年前,产品面对 agent 是"我可以被你用";现在,有的产品开始面对 agent 是"你可以用我,但这把锁我替你守着"。

readwise-cli 选的是后一种。

tele:50 MB 内存的 Telegram 客户端,Vim 键位,不调 C++

tele 的描述只有一段话,但里面有三个不常见的数字:cgo-free、Go、单静态二进制、~50 MB RSS。

对比一下:Telegram Desktop 在 macOS 上常驻 300-500 MB;Telegram 在 Linux 上是 Electron 包装。tele 是 50 MB。 它做到这件事的方式很硬:

• 自己说 MTProto。 不用 TDLib(那个 C++ 库)。它通过 gotd/td 自己实现协议,完全 cgo-free——意味着没有 C++ 编译器,没有运行时,单二进制静态链接。
• 键位是 Vim 的,但不止 Vim。 gg/G 跳首跳尾,j/k 在消息之间单条移动,光标停在那条消息上,所有上下文菜单都基于光标位置触发。
  关键差异是**"per-message cursor"**——你的光标在某条消息上时,滚动不再移动光标(用 ctrl+j/ctrl+k 滚动),这样你可以滚着看完一条长消息,但操作目标不变。
• 主题跟着终端背景自动切。 8 套内置调色板,light/dark 自动检测。
• 现代 Telegram 功能覆盖率: Reactions、Chat folders、Album 发送、视频/GIF/圆形视频(кружочки)内嵌预览、语音消息直接 app 内放(自带 Opus 解码,不用外挂播放器)。

它也坦白说做不到:没有语音/视频通话,没有圆形视频录制。 终端原生 + cgo-free 的架构没有麦克风/摄像头捕获栈。Secret chat 在 backlog。Full-text search 也还在 roadmap。

它省掉的是"住 terminal 的人不需要为聊天切出去"。neovim、yazi、k9s、tmux 用户,过去要聊天必须切到浏览器或桌面 app——tele 把这件事做成了"再开一个 tab"。

这与上一期 b4n(k9s 的 Rust 重写)、bluetuith(蓝牙 TUI)是同一条曲线的延伸:GUI 早就有了的工具,被 cgo-free + TUI 形式重做一遍。 但 tele 多走了一步——它把"客户端"这件事从"打开一个 app"重新翻译成"在 terminal 里和 chat 共存"。

crisp:把 macOS 藏起来的显示器控制一次性挖出来

┌──────────────────────────────────────────────────────────────┐
│  Crisp — Display Manager                                     │
├──────────────────────────────────────────────────────────────┤
│  📺 External Monitor (DELL U2723QE)                          │
│     ▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░  DDC Brightness  62%  →           │
│     ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  HiDPI Scaling   2.0x (Retina)    │
│     ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  ICC Profile     Display P3       │
│                                                              │
│  💡 Virtual Display                                          │
│     [Enable]  [2560×1440]  [ProMotion 120Hz]                 │
│                                                              │
│  ⌨️  Shortcuts: ⌃⌥⇧↑ Brightness+  ⌃⌥⇧↓ Brightness-         │
│  🌙  Night Shift: ON    ☀️  True Tone: OFF                   │
└──────────────────────────────────────────────────────────────┘

crisp 是一个 MIT 许可的免费 macOS 菜单栏应用。它的产品定位一句话讲完:Apple 隐藏了第三方显示器的控制能力,crisp 一次性把它们挖出来。

具体藏了什么:

• HiDPI 缩放——外接显示器在 macOS 上不能选 Retina 缩放,文字发虚或很小。crisp 强制开启。
• DDC 亮度——非 Apple 显示器的亮度键是死的,macOS 系统设置根本不发 DDC 命令。crisp 通过软件发。
• XDR/HDR 显示器超 100% 亮度——Apple 把这扇门关着,crisp 打开。
• DDC 音量——显示器自带音箱的话,macOS 没有暴露控制。
• ICC profile、HDR、Gamma、夜览、True Tone、Dark Mode 切换——菜单栏里一排入口。
• 虚拟显示器——给外接显示器用户开启 2560×1440、ProMotion 120Hz 这种"Apple 本来不让你用"的模式。
• 预设保存——"白天"、"夜间"、"看电影"三个按钮。

它和 BetterDisplay、Lunar 是同品类。但 BetterDisplay 是付费(约 100 元),Lunar 是付费。这周进来的 crisp 是 MIT 免费——这件事本身就是一个"这件事本来不该花钱"的判断。

它和上一期 b4n(k9s TUI 补 K8s 多集群)、bluetuith(蓝牙 TUI 补系统设置)是同一篇日记的下一段:macOS 在第三方硬件这块留的口子,正在被一批免费、开源的菜单栏应用一个一个填上。

betterglobekey:macOS 自带的 Globe 键,被一个小工具换了实现

┌────────────────────────────────────────────────────────────┐
│  betterglobekey — Globe Key Modes                           │
├────────────────────────────────────────────────────────────┤
│  Mode:        ● Single Press   ○ Double Press              │
│                                                            │
│  Collections:                                                │
│    Work:   [English] → [Chinese Pinyin] → [English]        │
│    Code:   [English] → [Colemak]      → [English]          │
│                                                            │
│  Modifier:  ⇧ Shift = previous collection                  │
│  HUD:       ✅ Show input source on switch                  │
│                                                            │
│  $ bglobe list        # list all sources                   │
│  $ bglobe current     # show current source                │
│  $ bglobe doctor      # diagnostics                        │
└────────────────────────────────────────────────────────────┘

betterglobekey 是一个 4.0 版的 macOS 小工具。它的目标非常窄——重做 Globe 键(Fn 键)切换输入源的逻辑。

macOS 内置的 Globe 键行为作者的评价是:"coded in a very intrusive and impractical way."——按一下循环切换所有输入源,中文、英文、日文混在一起轮。如果你双语工作,经常按两次才到想去的那个。

betterglobekey 提供两件事:

• Collection 概念。 你可以把输入源分组:"工作"(英文 → 中文拼音 → 英文)、"代码"(英文 → Colemak → 英文)。单按 Globe 在当前 collection 里循环,双按跨 collection。
• HUD 反馈。 切换瞬间弹一个小标识告诉你现在在哪个输入源。

它要 Accessibility 权限,需要把系统设置的 Globe 键设成"No Action"(不然 macOS 自己也会切)。

这件事几乎不性感——一个键盘按键的工具。但它正好对应最近几期反复出现的那条线:抽象层在降级,工具在变具体。 Globe 键是 macOS 一个抽象,但它抽象得不好;betterglobekey 不重新发明输入切换这件事,只是把那个抽象重新做一遍。

这一周这种"把 macOS 抽象做得更细"的小工具同时进来两个——crisp 管显示器,betterglobekey 管键盘。同一周,同一个方向,只是角落不同。

一点个人感受

readwise-cli 是这一周我会真的装的一个。不是因为我要让 agent 读我的 Readwise——我目前的阅读流不需要这个——而是因为它让我看到"产品方对 agent 的态度"在变化。一年前,产品对 agent 是"我可以被你调用";现在是"你可以用我,但我有 readonly 锁,有 re-login 关卡,有分仓的 skills 子系统"。 这件事比任何一个工具本身更值得记。

tele 我大概率不会装,因为我不重度用 Telegram。但 50 MB 这个数字我会记很久——Telegram Desktop 几百 MB,Slack Electron 应用常驻 1 GB+,tele 把这件事做成了"go 写的单二进制",这件事本身是给所有重客户端留的一道注释。

crisp 我会装,因为我外接显示器被 Apple 的 HiDPI 限制折磨了很久。BetterDisplay 我一直没买,价格不是问题,是觉得"这不该花钱"——crisp 帮我把这件事说出来了。

betterglobekey 我大概率不装,因为我只切一种语言。但我欣赏它存在——它证明了"macOS 内置的某个功能,被一个人花时间重做一遍,可以做成产品级体验"。这件事对所有还在被 macOS 不合理抽象折磨的人是种鼓励。

afterglow 是这周让我最犹豫的——一个跑原始 After Dark 68k 模块的屏保模拟器。Flying Toasters、Fish、Starry Skylines——这些 1990 年代的屏保通过 Musashi 68k CPU 模拟器在现代 Mac 上复活。这种工具在 2026 年还有人选,说明软件文物的保护,已经开始走完工具化的路(单独的 app、单独的 tap、单独的 brew formula)。和上一期 deja-vu 那种"给过去做一个 index"是同一篇故事的不同角色。

droppy 我没展开写,但它把刘海当生产力中心这件事(文件篮、剪贴板、Claude/Codex 进度、实时翻译)——和上一期 ping-island 是同一条曲线。如果非要挑一句话总结这一周,我可能更愿意说:客户端这件事不再默认"打开一个 app"——它开始在 terminal 里、在菜单栏里、在刘海里、在键盘里。

结语

这一周我装了 readwise-cli 的同一天,顺手装了一个叫 tcp-viewer 的抓包 GUI。

tcp-viewer 是 Proxyman 的小兄弟,2026.8.29 进了 cask。它做的事传统上属于 tcpdump 或者 Wireshark——但 Proxyman 把它做成 macOS 公民:证书一键装、应用流量过滤、按 domain 分组。

Proxyman 我用了三年。它做的事本质上是"tcpdump 的 GUI 化"——一个完全可以用 CLI 解决的需求,但 GUI 化之后我多救回了无数次"为啥这个 app 没收到响应"的下午。

tcp-viewer 进 Homebrew 这件事,放在这一周的大背景下看,比它本身重要:

readwise-cli 把 CLI 反向写给 agent;tele 把客户端做回 CLI;crisp 把隐藏控制挖到菜单栏;betterglobekey 把系统抽象换了一个实现。

这一周的 Homebrew 不在谈新功能,在谈客户端的边界该画在哪。

CLI 和 GUI 不再是一道非此即彼的选择题——它们变成了同一道工具的不同角度。readwise-cli 是 CLI 但默认对 agent 友好;tele 是 TUI 但兼容现代 Telegram;crisp 是菜单栏 app 但解决的是 CLI 暴露的命令;betterglobekey 是 GUI 但重新实现了 macOS 内置的逻辑。

工具在变,但变的不是形态,是接口。

前几周，agent 工具链在问"能不能跑"；上周，我们看到有人在问"谁替我盯着它"。
这一周，有人开始问另一件事：agent 那么多决策，都存哪了？

不是又一个 agent runtime，
是一个叫 deja-vu 的东西，追溯你过去八个月在任何一个 coding agent 里做过的所有决策，
把它们拼成一张可以搜索的本地索引；
不是又一个 AI 助手管理面板，
是一个叫 skills-manager 的东西，把分散在 52 个工具里的 prompt 文件
统一放进一个有版本、有预设、可以一键同步的仓库；
不是又一个聊天框，
是一个把"哪些消息会被发给模型"这件事
变成一张可以用鼠标剪线的有向图。

本周一句话总结

agent 的工作状态上周有人在盯，这一周有人开始问：它做过的那些决策，能不能找回来。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

deja-vu：agent 做过的决策，不应该只存在于压缩摘要里

Claude Code 在压缩对话时会保留摘要，但根据 deja-vu README 里的一个数字：43 次压缩下来，摘要保住了约 77% 的决策，却只保住了 0.2% 的命令。那些被丢弃的"当时用的是这个参数"、"上次这样做是因为……"——deja-vu 在安装之前就已经替你追溯索引好了。

它的设计路线有一个不常见的地方：不需要 LLM，只用词法倒排索引。1551 个 session，中位数查询耗时 0.4ms。它不试图理解你做过什么，只是让你找得到。

更奇的是"跨 agent"。Claude Code 里解决过的一个 bug，在 Cursor 新开 session 时，deja-vu 的 MCP hook 会在会话开始前把相关历史送进去。这不是"AI 记忆"，更接近一个开发者自己的版本控制——只是版本控制的对象变成了"过去做过的决定"。

skills-manager：当 prompt 文件多到需要一个包管理器

如果你用了不止一个 coding 工具，你大概有过这样的经历：在 Claude Code 里写好了一份 prompt 文件，换到 Cursor 发现要重新放一遍，换到 Copilot 又要一次。skills-manager 做的事很具体——把这些分散的 markdown 文件统一放进一个仓库，然后一键同步到你选择的任意工具。

它支持的工具列表现在是 52 个，包括 Claude Code、Codex、Cursor、GitHub Copilot、Gemini CLI、Windsurf 等。每张 skill 卡会显示当前在哪些 agent 里是"已同步"状态，哪些还没有。

这件事之所以值得关注，不只是因为功能本身——而是因为它的存在说明，prompt 文件这个东西，现在多到开始需要被管理了。几年前，"prompt engineering"还是一件你随手写随手丢的事。现在它开始有了仓库、版本、预设和跨设备同步。工具生态成熟有一个标志，就是出现"包管理器"。

thoughtdag：把你看不见的 context window，变成可以剪线的图

┌─────────────────────────────────────────────────────────────┐
│  ThoughtDAG — LLM Context Graph                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  [Document A] ──────────────────────▶ [Question]            │
│                                                             │
│  [Code snippet] ──  (pruned) ──────▶  ✗                     │
│                                                             │
│  [Research note] ───────────────────▶ [Question]            │
│                                                             │
│  "wires are context" — 剪一条线，这个节点的内容             │
│   就不会出现在下一次请求里。                                │
│                                                             │
│  当前 token 预计：2,341 (-47 if cut)                        │
└─────────────────────────────────────────────────────────────┘

标准聊天界面里，你不知道"这条消息会不会被发给模型"——超出窗口的会被截掉，但截掉哪些是隐形的。ThoughtDAG 把这件事翻出来了：每一条历史消息是一个节点，连线决定它会不会出现在下一次请求里。你可以在发送前剪掉一根线，把某个节点从 context 里排除，然后预览 token 数变化。

他们做了一个实验：162 个"聊天走偏"的案例，用"删掉整个污染子图"的方式全部修复，而"只删污染来源"只修复了 152 个。这说明上下文污染经常是沿着节点传播的——剪线的地方不只是"坏节点"，而是"连接坏节点和好节点的那根线"。

这个工具目前是小众的，但它回答的问题不小：如果 context window 是你和模型合作的工作台，那这个工作台应该长什么样？ 一个线性的聊天框，还是一张可以手动布线的图？

一点个人感受

deja-vu 有一个细节让我觉得它想得很清楚：它特意强调"不是从安装那天开始记录，而是追溯历史"。这个选择说明它的作者理解用户的真实处境——你不会在第一天就开始用记忆工具，那时候没有什么可以记；你会在某天发现"我之前解决过这个问题"的时候，才意识到需要它。等你意识到需要它，历史已经积累了很多了。

skills-manager 支持 52 个工具这个数字有点荒诞——说明 coding 工具领域的碎片化已经严重到需要一个专门工具来整合 prompt 文件了。这是好消息也是坏消息。好消息是 agent 工具链在成熟，坏消息是它成熟得太分散。

thoughtdag 我可能不会日常使用，但它是那种会改变你对某个概念理解的工具。用过一次之后，你会开始想"我和 Claude 的这段对话，如果是一张图，现在是什么形状"——即使你不再打开这个应用，这个问题本身已经在你那里留下了。

atlas-app 进了 Cask 但我没有展开写它——它和 deja-vu 想解决的问题有重叠，但 atlas 更重（桌面应用），deja-vu 更轻（单 Go binary + MCP hook）。两个工具同时进 Homebrew 这件事本身倒是有意思：agent 的记忆问题，现在至少有三种不同的答法了。

结语

deja-vu 在文档里写了一个比喻，大意是：coding agent 的 session 历史就像日记，但没有人读日记，除非他们想找一件之前发生过的事。

它没有说错。日记不是给每天看的，是给"我记得我做过这件事，但忘了细节"的那个时刻准备的。

现在 agent 工具链有了日记——一个本地的、可搜索的、不需要任何云端服务的日记。你在任何一个 agent 里做过的决定，可以在另一个 agent 开始工作之前被它读到。

这一步走完，agent 就不只是"能干活"了，它开始有了一些连续性。

上周我们刚把 agent 工具链拼成了一桌。
这一周,有人开始给这桌上的每一道菜挂名牌。

不是一个 IDE 出来了,
是一个叫 inshellisense 的东西——Microsoft 出的——给 bash、zsh、fish 同时装上 IDE 风格的补全;
不是一个模型面板又出现了,
是一份菜单栏把"DeepSeek V4 Pro"和"V4 Flash"作为两个可选项摆给你,RAM 够不够它替你算好;
不是又一只桌面宠物,
是宠物会看你的 agent 在不在干活——你不动,它也不动。

本周一句话总结

agent 工具链上周把"能不能用"的问题答完了,这一周回答的是"谁替我盯着它"——用补全、用菜单栏、用宠物。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

inshellisense:Microsoft 来给 shell 装 IDE 补全了

inshellisense 这个名字有点拗口,但它背后是 Microsoft 维护了 4 年、10629 stars 的 withfig/autocomplete 生态。它做的事情一句话能讲完:给 shell 提供 IDE 风格的实时补全,支持 600+ 命令行工具——不仅 bash、zsh、fish,powershell、nushell、xonsh 都能挂上。

它的关键不是"又一个补全"——fish shell 的 autosuggestions 早就有了。关键在于三件事:

第一,它不需要你换 shell。 用法是 is init zsh >> ~/.zshrc,在你现有 zsh 上挂一个补全层,所有按键都透传给原 shell。这意味着一个二十年 zsh 老用户可以零成本试。

第二,它认得每条命令的 flag。 不是只补最近用过的路径,而是 600+ 工具的子命令、参数、合法值都在本地 spec 里。比如 docker run -<TAB> 出来的是 -d、--rm、-p、--name 这种结构化提示,而不是 grep 过的历史命令。

第三,它的运行时是 terminal native,不是 GUI 套壳。 没有 tmux pop-up,没有外置窗口,补全就在命令行里——这是 inshellisense 区别于 warp、fig(曾经的)那种"重新发明终端"路线的根本。

它省掉的是 shell 用户最隐秘的"半记忆":kubectl 那一长串 flag、ffmpeg 的编码选项、aws s3 几十个子命令的合法组合。每次按 Tab 都是一次小型 IDE 提示,但你仍然住在自己那个二十年没换过的 shell 里。

cliphist 进的是 Wayland 剪贴板,b4n 是 k9s 的 Rust 复刻——这周 Formulae 的整体气质其实是"补全旧工具的隐藏角落"。inshellisense 是最显眼的一格,因为它补的是 shell 本身,而不是某个工具的某个方面。

ds4-control:把一个具体模型版本号塞进 macOS 菜单栏

DS4 Control 是一个菜单栏 app。看起来平淡——但它身上有几个细节值得拆开看。

第一,它不抽象"模型"这个概念。 菜单栏里不是"Local LLM"、"AI Chat"这种伞状入口,而是明确写着 V4 Pro 和 V4 Flash (0731) 两种选择——具体到发布日期、显存占用、上下文窗口。

第二,它替你算 RAM 可行性。 V4 Pro 要 512 GiB,V4 Flash q4 要 256 GiB,Flash q2 最低 96 GiB。你的 Mac 内存不够,菜单直接禁用 Start,弹一个 Metal wired limit 的具体 sudo 命令。不够就告诉你不够,不假装能跑。

第三,它把"启动 agent 编程"做成了菜单栏里一个 Launch 按钮。 不是泛泛的"Chat with AI",而是 Launch Pi / Launch Claude Code / BYOC(自带 CLI)三个具体入口,让菜单栏从"模型开关"变成"模型 + agent 入口面板"。

它背后依赖的是 dwarfstar4(antirez/ds4)——antirez 这次是单干,没走 Redis 那条企业路。DS4 Control 也没走 Ollama、LM Studio 那种"模型市场"路径,而是把"开/关/切换一个具体模型版本"这件事做成了 macOS 公民。

这与上几期 headroom(token 路由器)、lm-studio-bionic(本地 agent)是同一条曲线的不同切面:模型经济开始有专门工具来管"怎么用、怎么省、怎么换",而不是默认在终端里敲 curl。菜单栏成为模型运行时的容器——这件事一两年前是不存在的。

petdex:agent 终于有了一只宠物

petdex 的描述只有一行:"Desktop pet that reflects coding agent activity." 没有第二句。

它的产品页面却透露了更多信息:宠物会看你的 coding agent 是不是在跑。agent 写代码时它在动,agent 停下来时它也停。宠物是 boba、doraemon、shinchan、tiko、lulu-capybara、usagi——一堆亚文化图标的合集,你养哪一只看你口味。

这和 headroom(token 仪表盘)、mcpsnoop(MCP 流量抓包)、kata(任务列表)看起来是同一种东西的不同形态:agent 时代的可观察性产品。但 petdex 选择了最不严肃的一种表达。

以前"agent 在干什么"这件事的答案,是看日志、看 dashboard、看终端里的进度条。这些是给开发者看的。petdex 假设你的同事、家人、你自己那个不太懂 agent 的部分,也想问"它在干活吗"——答案从屏幕角落的一只生物那里来。

它省掉的是"端详状态"这个动作。不必打开 CLI,不必等日志刷新,不必看一个代表"agent 正在思考"的旋转图标——只要瞥一眼桌面右下角。

这是这一期让我最犹豫要不要放进重点的一个:月安装 27,公式刚进,产品名读起来像"宠物大全"而不是技术工具。但它做对的事比它看起来更深——它把"agent 状态"从工程问题改写成了存在性问题(它在那儿吗)。这个改写可能比很多正经 agent 工具更重要。

b4n / bluetuith:TUI 终于开始覆盖基础设施最后一公里

b4n 是 Kubernetes API 的 Rust TUI,直接说自己"heavily based on k9s"。bluetuith 是蓝牙适配器与设备的 TUI 管理器,目标替代 blueman。两者都不性感——K8s 和蓝牙在 2026 年都是"早就有 GUI"的东西。

但 TUI 重做它们这件事,和过去两年的 TUI 风潮是两件不同的事。

过去 TUI 重做,是为了脱离图形界面——lazygit 替代 Sourcetree,lf 替代 Finder,btop 替代 iStat Menus。本质是"图形不是必需的"。

这一周进来的 TUI,补的是 GUI 一直没做好的那部分:

• b4n 解决的问题是 K8s dashboard 在多集群、namespace 嵌套、CRD 爆炸之后的可读性崩盘。kubectl + jq 仍然是最可靠的,k9s 用 TUI 形式重新组织了这套信息。
• bluetuith 解决的问题是 macOS/Linux 蓝牙栈在 GUI 层多年没有认真做过——系统设置里的蓝牙面板是 2010 年水平的 UI。

这种 TUI 不是 GUI 的替代品,而是 GUI 没做好的基础设施的兜底。当 GraphQL IDE、Postman、Tableau 都开始有桌面应用,但 K8s 多集群管理、蓝牙文件传输、systemd unit 编辑这些角落仍然停留在 web 控制台或 CLI,说明 GUI 这一波还没真正到底。

systemd-lsp 上周就进了 Formulae,做的是 systemd unit 文件的 LSP。b4n/bluetuith 是这条线的延伸:基础设施的最后一公里,正在被一批不声不响的 TUI 工具慢慢补齐。

一点个人感受

inshellisense 是这周我会真的装的。10629 stars、Microsoft 维护、4 年沉淀——这种体量的项目进 Homebrew 通常意味着它已经解决了"装上能用、装上不冲突"的问题。我对 shell 补全的容忍度其实很高(fish 用了五年,现在用 zsh 也是手动 history search),但 600+ 工具的 spec 本地匹配确实是我自己攒不全的东西。

ds4-control 我大概率短期不会装——V4 Pro 要 512 GiB,我的 M4 Max 跑 Flash q2 都得手动抬 Metal wired limit。但它那个"RAM 不够直接禁用 Start"的诚实,比很多假装能跑的本地 LLM 工具更让我尊重。 一个工具明说"你这台机器跑不动",反而比那些跑五分钟崩一次的工具更值得用。

petdex 我会装,纯因为想看。lulu-capybara 蹲在右下角、Claude Code 写代码时它跟着摇头,这件事本身没生产力,但我猜它解决的是"agent 跑长任务时,人会陷入无意义刷新终端"这种心理动作。给一个动画看,比反复 ps aux | grep claude 健康。

grok-bot 是这周让我最犹豫的。xAI 出品、153 月安装、明确写"AI teammates"——产品形态比 diversion 更激进(它直接说自己是"团队",不是工具)。但 xAI 的产品路线这两年反复换,我不愿意把工作流交给一个可能下个月改产品名的产品。等它有 1000+ 月安装、且接口稳定两个季度再说。

owlocr 是表格里我特别想单挑出来说一个的工具。设备端 OCR 已经不稀奇了,但它强调"on-device"——音频不离开设备、图像不离开设备——是上一期 lm-studio-bionic、koe、openwhispr 那条"本地化优先"曲线的延续。On-device 不再是隐私爱好者的偏好,而是默认假设。

结语

这一周我盯着 ds4-control 的 README 看了一会儿——"V4 Pro" 和 "V4 Flash (0731)" 这种带具体日期的版本号,出现在一个菜单栏 app 的下拉选项里。

一两年前,一个本地 LLM 工具会把"模型选择"藏在一行配置或者 ollama pull 后面。现在它直接写进 macOS 菜单栏,RAM 够不够替你算,版本号几号替你查。模型开始有产品形态,就像编译器、数据库、容器曾经有过的那样。

inshellisense 给 shell 装 IDE,petdex 给 agent 装宠物,b4n/bluetuith 给基础设施补 TUI,ds4-control 给模型版本号一个家——这周的 Homebrew 看起来没什么惊天大事,但如果你把它们放在一张图上,会看到一个共同点:抽象层在降级,工具在变具体。 不再是"AI 助手",而是"一只蹲在那儿的宠物";不再是"本地 LLM",而是"V4 Pro / V4 Flash";不再是"shell 增强",而是"600+ 工具的本地 spec"。

具体的东西才会留下来。

前几周我们看着 agent 一点点拥有自己的语言、包管理、沙箱和观察工具。

这一周,它有了第一张可以挂在墙上的任务列表。

不是又一个 agent runtime。
是一个叫 kata 的东西,由 pandas 的作者 Wes McKinney 写的 issue tracker,
明文写在产品描述里:给 agent 和"看着 agent 干活的人"用。
它把 agent 工程剩下的最后一块拼图补齐,顺手把它做成了一个本地优先的 SQLite。

本周一句话总结

Agent 工程的工具链不再是"让 agent 跑得起来"——这一周进 Homebrew 的几样东西,把"agent 的工作流该长什么样"摆上了台面。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

kata:agent 的第一张任务账本

$ kata create "修复登录竞态"     # 一次性、可幂等
$ kata list                       # 列出当前打开的 issue
$ kata show abc4                  # 用稳定短引用查看
$ kata close abc4 --done --commit a8c2f1 --message "已修复"

┌─ kata tui ─────────────────────────────────────┐
│ OPEN  ◇ abc4  修复登录竞态       agent-1   1d    │
│       ◇ e21a  补 e2e 测试       human     2h    │
│       ◇ 9bf2  重构 auth 模块    idle      3d    │
│ CLOSED ☑ 712c  旧版 GET 404     human    1w    │
└────────────────────────────────────────────────┘
  j/k 选择   Enter 详情   C close   q 退出

Wes McKinney 在 2026 年写了一个 issue tracker,这件事本身就值得停下来。

pandas、Arrow、DuckDB——他在过去十年里最关心的都是"让数据处理这件事变得可以放下来、重启而不丢上下文"。kata 是同一思路的延伸,只是落点从数据移到了任务。

它的产品描述一上来就把两件事写在一起:"给 agent 跑任务的 CLI,和给人盯进度的 TUI。" agent 通过 --json、--agent 和幂等的 create/close 流动任务;人通过 kata tui 看同一个 SQLite 里的同一份账本。任务有 reason、有 message、有 commit hash、有 actor 字段——谁关的、按什么理由、贴了哪个 commit,都能回放。

默认状态存在本地 SQLite,仓库里只多一个 .kata.toml,不会因为用一个 issue tracker 把仓库弄脏。需要协作时可以用 KATA_DSN 走 Postgres 或自己起的 daemon,再加点 federation。

它省掉的是 agent 工作中最隐秘的成本:任务和决策的连续性。一个 agent session 跑了 30 分钟改了三件事,如果中间崩了,你以前得回去翻日志、git reflog、Slack 截图拼它到底改了什么。kata 把这件事做成了结构化字段——"close 时必须带 commit 和 reason"不是审查,是防御性快照。

baml 给 agent 一门语言,apm 给 agent 一个包管理器,arcbox 给 agent 一间隔离房间,openlore 给 agent 一张代码地图,treehouse 给 agent 一个独立工作区。kata 给 agent 一张可追责的任务列表。 这次的作者还是 pandas 那一档的人,所以"数据放在本地 SQLite、可以跨实例联邦、但默认不污染仓库"这套约束,看起来不像灵光一现,更像押注。

opencrabs:一个二进制里的"自我进化" agent

opencrabs 的描述第一段比较长,但里面有三个词值得拆开看:all-in-one、self-improving、single Rust binary。

它把 TUI、CLI、daemon 三种入口塞进同一个二进制。功能列表读起来像是一个团队愿意自己用的 agent:写 landing page、做后端、管理文件、研究、调度任务和事件,还能挂上 favorite 的 channel(理解为不同 agent 之间的协作通道)。896 stars,Rust Edition 2024,基于 Ratatui。

baml、apm 是把人往外推的工程基础设施;arcbox 给 agent 一个边界;lm-studio-bionic 让本地模型直接以 agent 形态出现。opencrabs 走在另一侧——它在试图把"打开一个 terminal,一个二进制,一个 agent 全包"这件事变成产品形态。

brew info 显示它有一个 build-error 9/30,是这一期我看到的几个较新公式里 build-error 较高的一个。如果有人装它,值得用 brew info opencrabs --json 之类先看一下当前状态。

它省掉的成本有点不同:不是省"调试"或"协调",是省"决定"。一个二进制、一种心智模型、一组固定的入口——换工具意味着重新训练,不是重新配置。对于刚开始把 agent 当日常工具、但还没准备好搭一套 baml+apm+arcbox 的人来说,这种"先全在一个里,等哪天真的需要再拆"的设计,本身就是一种产品态度。

headroom:给 Claude Code 装上一层 token 路由器

Headroom 的产品描述非常直接:把 Claude Code 或 Codex 里的 build log、JSON blob、shell 输出、HTML 样板,压缩到一半左右再喂给模型。 模型需要原文的时候可以拉回,自带"可逆压缩"。

头号指标写在了宣传里:在噪音输入上 ~50%,在真实 agentic coding session 上 15–25%。他们有自己的 benchmark——HTML 抽取 F1 0.919,JSON 寻针测试 4/4,multi-tool agent 任务 61% 更少 token 但结论一致。

它跑在一个本地 proxy 里。Claude Code 看到的是压缩后的内容,你看到的是 dashboard:总成本、节省的 token、当日节省曲线、按项目学到的压缩模式。换句话说,它把"这一次 agent 跑的 token 是怎么花的"这件事从账单变成了仪表盘。

这与上几期 lm-studio-bionic(把 agent 留在本地)、flite、koe、openwhispr(把语音留在本地)是同一方向的不同切面:Token 经济开始有专用工具来管理,而不是默默花在账单里。 以前这是一个只有大公司在乎的事;现在一个 macOS 菜单栏应用在处理它,意味着这件事的门槛降到了个人开发者的桌面。

有一个不应该忽略的细节:它的官方页面把"188 happy developers,3,086 installs,44.3B tokens saved"放在了首页。不是技术指标在前面——是社区量在前面。token 优化作为一类工具,正在用 SaaS 经典的方式扩张:先攒量,再让数据反哺产品。

diversion:当 VCS 自己写"agent"进产品定位

$ diversion checkin --message "data sync worker" --trajectory
$ diversion sync --repo megamax
$ diversion activity --since 1h

diversion 把自己定位为"现代协作平台,专为巨型仓库和大规模并行 agent 工作流"。在产品页面上,你会看到一行字:"fleets of thousands of AI agents working in parallel。"

这是一个 VCS,主动把自己写进 agent 时代产品定位,而不是被时代裹着走。

它做的事情听上去像 Perforce:超大 monorepo(上千万文件、几百 TB,单文件最大 2.4 TB——明确包括 AI 模型 checkpoint 和训练数据)。但它把"agent 友好"做成了头号差异化:1,000+ commits/分钟无降速,Partial & shallow checkout 让 laptop 也能进 5000 万文件的仓库,还有一个叫 Trajectory 的插件,负责捕获每次 AI 生成代码提交时的"为什么"。

这个叙事变化比工具本身更值得记:版本控制——一个理论上最古老、最不需要重新发明的品类——也开始在产品定位里默认 agent 是第一类公民。 上周 mcp-inspector 到了 1.0,几个产品正在不声不响地把"agent-first"写进自己的安装文档。diversion 是其中走得最显眼的,因为它选择了一个本可以只服务游戏工作室的位置,也选了把 agent 写进产品第一句。

Diversion 不是给大多数人准备的(diversion-app 的 30 天安装量只有 11),但它能把这件事放进产品页这件事本身,是一个值得记的信号。

一点个人感受

kata 是这一周让我最想认真看 repo 的一个。不是因为我马上会用——30 天安装 57,公式刚进——而是因为它落在一张我已经在用一张纸记的清单上:baml、apm、arcbox、openlore、treehouse 现在都在写"agent 该怎么工作"的某一格。kata 把"任务追踪"这一格填上了,作者是那种不会随便填的人。我想把它加上 watch,过几个月再看。

opencrabs 我短期不会装。brew info 里那个 9/30 的 build-error 在新 formula 里偏高的;896 stars 不算多,我更想等它到 0.5.x,或者看到 Rust Edition 2024 那些特性稳定下来。但我想认真看它的架构图——把 TUI、CLI、daemon 塞进一个 binary,这件事本身就是一种产品态度,和 baml 的"我重写一切"是反向的。

headroom 是这周我会认真考虑付费的那一个。我现在每月给 Claude Code / Codex 花的 token,已经到了一个我不再想用"反正不贵"糊弄自己的程度。把它装上做一个月的仪表盘,比读三篇 token optimization 文章有用。

meetingrecorder 让我没法继续无视这件事了。这是连续第三周或第四周出现"本地会议录音"工具(配合 koe、openwhispr、flite 那一串)。我到现在还是没用语音类工具,但这个密度本身在告诉我:大概率某个产品已经做对了某个我没意识到的场景,只是我还不知道是哪一个。

至于 diversion——它做对的事我没法直接受益,我没有百万文件 monorepo,我也不带 agent 集群干活。但它把"agent-first"明文写进 VCS 产品描述这件事,和上周 mcp-inspector 进 1.0、arcbox 把 agent 沙箱写进产品第一句,合在一起构成了一条同样的曲线:基础设施品类(版本控制、容器、调试器)开始默认用户里有 agent 这一类。 这条曲线一旦明显到不必说出来,就意味着 agent 经济已经走完了上半场。

结语

kata 的官网描述里有一句不起眼的话——"for humans and coding agents"。前几个月 Homebrew 里陆续进来的 baml、apm、humanbound、openlore、treehouse 也都写过类似的措辞,但它们大多是"我顺便能服务 agent"。kata 是第一样东西,把"agent"放进了产品名字以外、更早的位置。

一个写 pandas 的人,在 2026 年重新做了一个 issue tracker——这个故事本身比任何公式描述都更值得记。可能在某个我们看不见的角落里,有一类工具就是这样开始的:不是因为缺一个功能,是因为有人看到一种新的工作方式没人正经服务过。

也许下期我们可以问另一个问题:这些工具里第一个真正有人留下来长期用的,会是哪一个?

最近几周，agent 的工程层在加速成形；这周更像是有人开始给它装上眼睛。

不是又一个会替你写代码的工具。
是那些让你看见它在做什么、记住它为什么这么做、并且把并行工作隔离开的东西。

本周一句话总结

这一周的 Homebrew 列表，把 agent 生态从“能不能运行”往“能不能观察、复现和收拾残局”推了一步。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

mcpsnoop：MCP 终于不必靠猜来调试

上个月我们先后看到 smithery-cli、toolhive-studio 和 mcp-inspector：安装、管理、调试，MCP 的工具链一层层补齐。mcpsnoop 接上的，是更靠近现场的一层——真实流量到底发生了什么。

它可以作为透明 shim 放在客户端和 MCP server 之间，把每一帧 JSON-RPC 复制到 hub；也可以作为 streamable HTTP 的反向代理，把 401、202、502 这些原本容易被吞掉的状态直接摆到眼前。你可以过滤、重放、导出，也可以对比两次会话之间的工具定义漂移。

这省掉的不是“敲几条命令”的成本，而是那种最磨人的判断：模型究竟有没有发起调用？是参数错了，还是 server 卡住了？工具 schema 是什么时候悄悄变的？以前这些问题通常靠日志碎片拼出来，现在有一块专门的观察面板。

MCP 从配置文件里的几行 JSON，变成了一种值得拥有网络抓包器的协议。这个变化本身，比 TUI 长什么样更重要。

openlore：给 agent 一张不会每次重画的代码地图

openlore 的描述里有两个词很准确：architectural memory 和 structural cognition。它不是再塞一段“请记住这个项目”的 prompt，而是先对仓库做静态分析，建立包含调用关系、类型、测试、架构决策和规范漂移的知识图谱。

之后 agent 可以用 orient 先找到与任务相关的函数、调用者、测试和插入点；改动前用 certify 判断公共接口是否破坏了消费者，或某个 diff 是否新打开了通往敏感边界的路径。它的热路径不依赖 LLM，查询结果也强调确定性。

这里真正被省掉的是“重新建立方向感”。一个长时间没人碰的仓库，最昂贵的往往不是写代码，而是确认自己现在站在哪儿：这个函数谁在调用，那个约束有没有测试，某个看似局部的改动会不会沿着调用图传出去。

它把“记忆”从 agent 的性格问题，改写成了代码库的结构问题。这个方向和上周的 BAML、APM 接得上：agent 工程开始把过去靠经验维持的东西，逐项变成可检查的对象。

treehouse：worktree 不再是 Git 老手的暗号

Git worktree 很好用，但它一直有一点像 Git 的隐藏机关：知道的人用得很顺，不知道的人只会复制目录、切分支，然后在某个周五下午忘记清理。

treehouse 的做法是维护一个可复用的 worktree pool。执行时它会同步远程，找到空闲且干净的 worktree，重置到最新默认分支，然后在里面启动子 shell；退出时清理残留进程、重置工作区，再把它放回池里。还可以用 lease 持久占用，不靠分支名协调，也不需要后台 daemon。

它省掉的是一整串微小但持续的管理动作：这个 worktree 谁在用、哪个已经 dirty、并行任务结束后该删哪个、build cache 能不能留下。对于 agent 并行工作尤其自然——每次拿到的是一块干净、可回收的空间，而不是让多个任务共享同一个目录然后祈祷它们别碰到彼此。

codexia 上周把 worktree 管理写进了 GUI 工作台；这周 treehouse 以更朴素的 CLI 方式把同一个问题落地。一个在做入口，一个在做底层秩序。

lm-studio-bionic：本地模型应用开始直接承认自己是 agent

LM Studio 的新 Cask 名为 lm-studio-bionic，官方定位也换了一个更直白的说法：“An Agent made for Open Models.” 它不是在桌面应用里顺便加一个 agent 模式，而是把 agent 写进产品的第一句话。

Bionic 面向开源模型，支持本地下载和运行模型，能创建、编辑文档，做自动化、编码和计算机控制；语音转写也强调本地处理，音频不离开设备。它由 LM Studio runtime 驱动，底层使用 MLX 和 llama.cpp。

这让“本地模型”不再只是一个聊天窗口的选择。真正有分量的是：当 agent 可以改文件、控制电脑、连续完成工作时，本地运行开始从隐私偏好变成架构选择——数据在哪里、模型在哪里、失败时谁能看到过程，都要重新回答。

arcbox 上期把 agent 沙箱当成产品卖点；lm-studio-bionic 则把开源模型和 agent 工作方式绑在一起。一个在说“给它一间隔离的房间”，另一个在说“这间房里的模型可以留在本地”。

一点个人感受

这周我反而不太想立刻安装所有 agent 工具。openlore 的 49 次月安装量和一次 build error 说明它还在很早的位置；但这类项目一旦把“证明自己知道什么”做稳，价值不会只停留在 coding agent 上。

flite 没有 agent 标签，却和最近连续出现的本地语音工具形成了另一条安静的线：语音合成和语音输入都在被拆成可组合的基础部件。比起一个包办一切的助手，我更信任这种可以单独替换的零件。

tuicr 也很有意思。代码审查开始拥有自己的 Vim TUI，说明审查不一定要被吸进 IDE 或网页；在终端里看 diff、移动、留下判断，仍然是一种完整的工作姿势。

至于 lm-studio-bionic，我会等它的 preview 再成熟一点。agent 能在本地跑是一回事，值得长期把工作交给它是另一回事，中间隔着的不是模型下载速度，而是可控性。

结语

mcpsnoop 的屏幕里，最值得看的不一定是某一帧 JSON-RPC，而是那些以前只能从沉默里猜出来的失败：401、超时、漂移、没有发生的调用。

这周的 Homebrew 像是在给 agent 补几种基本感官：看见流量，记住结构，拥有自己的房间。

等这些东西都不再需要特别解释时，agent 工程大概才算真正进入日常。

前几周我们看到的是 MCP 的工具链在一块一块补齐。这一周的列表告诉我的是另一件事：agent 开发本身，开始有了自己的语言、包管理器和安全框架。

新的语言往往比新的 CLI 工具更难在 Homebrew 里露面。
这一周 baml 进了，旁边还有 apm 和 humanbound。
当一个领域开始有专属语言和包管理器的时候，通常是某件事从"实验阶段"走向"工程阶段"的信号。

本周一句话总结

Agent 开发不再只是"把 LLM API 包一层"——这一周进 Homebrew 的三个工具，各自对应了一种软件工程的基础设施：语言、依赖管理、安全测试。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

baml：第一次有工具在说"TypeScript 不是给 agent 设计的"

BAML 是 BoundaryML 做的一门语言，描述是"给 agent 和人类共同编写的图灵完备编程语言"。这句话需要停一下。

传统语言是为了让人写出可运行的代码而设计的——可以有 any，可以有 unchecked cast，可以有"先跑起来再说"的逃生舱口。人写代码出了问题，人可以调试、可以权衡。Agent 写的代码不一样：它会找到每一个逃生舱口，而且不会回来告诉你它用了。

BAML 的设计出发点是：让无效状态更难被表示出来。运行时类型不能有 any，错误是有类型的并且必须被穷举处理，LLM 函数、测试、测试集是内置到语言里的，而不是外挂的框架。还有一个 baml describe 命令，专门给 agent 用来结构化地理解代码库。

它还能生成 Python 和 TypeScript 的 SDK，这意味着你不必完全迁移——先在 agent 写的部分用 baml，人写的部分继续用你熟悉的语言。

目前版本 0.2.2，installAnalytics 只有 29 次，刚进 Homebrew。还很早。但"给 agent 写的语言"这件事本身，第一次以一个具体的工具的形式出现在 Homebrew 里了。

apm：npm 解决过的那个问题，现在在 agent 配置层重新出现了

APM 来自微软，它的定位是"AI agent 的依赖管理器，就像 npm 管代码依赖那样，它管 agent 的 context"。

你在一个项目里工作，用的是 Claude Code、Copilot、Cursor，每个工具有各自的配置文件，各自的 prompt、skills、MCP server 列表。当你换了机器，或者新同事加入，这些 agent 配置不会随代码一起复现——它们散在不同地方，版本不一定对齐，谁都不知道"你的 claude code 和我的 claude code 是不是同一个 claude code"。

APM 用一个 apm.yml 把这些统一声明，一个 lockfile 锁定精确版本和内容哈希，apm install 之后，新机器或新成员拿到的 agent 配置和你的字节一致。还有安全扫描：每次安装自动检查隐藏 Unicode 字符，拦截未声明的 MCP 服务器。

这个问题——"怎么让 agent 的行为在不同环境里可复现"——到 2026 年中才第一次有一个专门的工具来解决，比代码依赖管理晚了将近三十年。

humanbound：当 agent 可以用工具、可以访问数据，"越界"这件事需要被认真对待了

Humanbound 是针对 AI agent 的对抗性安全测试框架。OWASP 对齐，覆盖 prompt injection、jailbreak、工具滥用、数据泄露。它还有一个叫"进化式红队"的模式：攻击会根据上一次结果自动迭代，用 score-guided 的方式找到更有效的攻击路径。

这类工具以前叫"AI 安全研究"，是学术论文和红队演练里的内容。现在它进了 Homebrew 的 Formula，版本号已经是 2.7.0，可以 brew install humanbound 然后指向你的 agent endpoint 跑测试。

它的出现暗示了一件事：agent 的攻击面已经大到需要一个专门的测试框架来覆盖。一个只会回答问题的 chatbot 不需要 humanbound，一个可以调用工具、读写文件、访问外部服务的 agent 才需要。

clarc 和 codexia：Claude Code 和 Codex 同一周有了两个 GUI

这两个工具进同一期不是巧合，放在一起说更有意思。

Clarc 是 SwiftUI 做的 macOS 原生应用，只有 6MB，包着真实的 claude CLI，加了 permission UI（有 diff 的审批弹窗）、对话分叉、文件树、内嵌终端。要求 macOS 15。它的 tagline 是"终端是少数人的，Clarc 是所有人的"——做的是把 Claude Code 的门槛降低这件事。

Codexia 是 Tauri/Rust + React 做的，同时覆盖 Codex CLI 和 Claude Code，功能更宽：任务调度、headless 模式、MCP market、agent skills market、Git worktree 管理。像一个 workstation，不只是 GUI 壳子。

两者指向的是同一个现象：Claude Code 和 Codex CLI 已经足够被认真对待，值得有人专门去做它们的 GUI 层。这件事在六个月前不会发生，因为这两个工具自己也没到那个阶段。

一点个人感受

baml 我短期不会用——0.2.2，还早，而且我现在写 agent 的比例没高到值得迁移一门语言。但我把它的仓库加到了关注列表。这类工具到 0.x 通常进展很快，等它到 1.0 的时候会是一个值得重新看的时间点。

apm 反而是我觉得更接近可以用的那个。我已经有用多个 AI coding 工具的习惯，配置散在各处这件事确实烦——不是大问题，但每次换机器都要重新捋一遍。如果 apm.yml 能真正成为这些工具的单一配置源，我愿意试。

humanbound 让我想到的是：现在写 agent 的人，有几个人在认真想过自己的 agent 能被怎么攻击？这个问题以前只有部署到生产环境、处理真实用户数据的团队才会问。现在工具进 Homebrew 了，意味着这个问题在往更早的开发阶段移。

这周的 Casks 里有好几个语音类工具（koe、openwhispr、willow-voice 上期、hermes-desktop 也有语音功能）。这是连续第三周出现这类工具了。我现在基本不用语音输入，但这个密度让我开始想：是不是在某个使用场景里，这件事已经在悄悄变好用了？

结语

baml 是第一门专门为 agent 设计的语言，apm 是第一个管 agent 配置的包管理器。软件工程为人类建立这一套基础设施花了几十年。为 agent 建的这套，在 2026 年 7 月同一周进了 Homebrew。

时间线在压缩，但问题本身没变：你写的东西能不能在别人的机器上复现，能不能被测试，会不会在意想不到的地方越界。这些问题以前属于软件工程，现在也属于 agent 工程。

下期关注：hermes-desktop（Nous Research 出品）能做什么，kiesel（Zig 写的 JS 引擎）为什么在 2026 年还有人做新的 JS 引擎。

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

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、保活、本地化、安全。你不必每个都装,但看着它们按这个速度补齐,本身就是一件让人安心的事。

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

这一周，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 列表像一条安静的河。
新工具是河面上的小船，镜像清理是河底的泥沙在重新分布。

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

这周 brew update 比平时多了几行字。

从 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 让语音处理不出本地。

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

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

这周 brew update 之后，有一行描述让我停了一下。

"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 都更值得记下来。

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

这一周的工具列表，像是在给"AI 在哪里工作"写一份新答案。

上一周大家还在补 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 不是又往云上漂走了一点，而是悄悄往本地、往边缘、往"我手边这台机器"再回了一点。

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

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

这周打开 brew update，像是看到一座基础设施小镇在悄悄建起来。

五月底的列表里，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 本身，而是它需要的那一切日常基础设施。

这周新进来的工具，很多都在干同一件事：把 AI 编程的过去和未来都搭一遍脚手架。

有些工具是为了跑得更快；有些工具是为了记住跑过哪里。
这周的新增偏向后者——不是 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 这类工具。

结语

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

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

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

AI agent 也需要一张地图。

五月的工具列表里，有几个名字值得停一下。一个 hex 编辑器带了颜色，一个数据目录开始接 MCP，还有一个 Elixir 的 LSP 悄悄更名上线。不是什么大事，但每一件都指向同一个方向：开发者的工作台正在变得更可感知、更可查询。

本周一句话总结

工具越来越懂得如何把自己的内部状态暴露出来——不管是字节、元数据，还是代码语义。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

hexapoda：终端 hex 编辑，终于不再灰蒙蒙

用过 xxd 的人大概都知道那种感觉——屏幕上全是十六进制字符，没有颜色，没有选区概念，想改一个字节要先查怎么跟 vim 配合。

hexapoda 换了一套思路。它跟 Helix 学了"选择优先"的 modal 模式：先选中一段字节区间，再决定对它做什么。ijkl 移动（或者 hjkl，可以配置），1/2/3 拆分字节块，m 标记偏移量，J 跳转。操作逻辑和普通文本编辑器接近了很多。

最重要的是：它有颜色。不同类型的字节用不同颜色区分，阅读二进制文件的心智成本一下子低了一大截。

对于偶尔需要检查固件、协议包或者序列化格式的开发者，这个工具值得装着备用。

brew install hexapoda

marmot：让 AI 知道数据在哪

有一类问题，AI 助手回答起来特别吃力：「这个字段的 owner 是谁？」「负责用户订单的表叫什么？」不是因为 AI 不聪明，是因为它根本不知道你们公司的数据长什么样。

marmot 要解决的就是这件事。它是一个轻量级开源数据目录，把你的数据库表、消息队列、API、看板统一索引起来，然后内置一个 MCP server——Claude、Cursor 这类工具可以直接向它查询，拿到的是来自数据目录的权威元数据，不是 AI 自己猜的。

和 DataHub、Amundsen 这类企业级数据目录比，marmot 的门槛低得多：单二进制文件，Docker 五分钟跑起来，支持 500k+ 资产，平均响应不到 50ms。MIT 协议，数据也不出自己的环境。

这不是一个"等团队大了再用"的工具。三个人的小团队，如果 AI agent 开始进入你的开发流程，数据目录这件事现在就值得想一想。

brew install marmot

dexter-lsp：Elixir 的大项目问题

Elixir 的语言服务器（ElixirLS）在大型代码库里一直有卡顿问题——项目一大，补全变慢，索引常常超时。dexter-lsp 是 remote.com 工程团队针对这个问题重新做的 LSP 实现，专门为大型单仓库优化。

它不是要替代 ElixirLS，而是在"大到 ElixirLS 已经不够用"这个场景下的一个选项。如果你的 Elixir 项目超过了某个规模，值得试试看。

brew install dexter-lsp

趋势观察：工具在学会"开口说话"

这周的几个工具有个共同的隐线：它们都在替某种"不透明"省成本。

hexapoda 让二进制文件变得可读；marmot 让数据资产变得可查询；dexter-lsp 让大型代码库的语义变得可感知；openchamber 让 AI agent 的行为有了可视化界面。

这不是巧合。当 AI 工具越来越深入开发流程，「让工具的内部状态对外可见」这件事就变得越来越重要。不是为了展示，是为了被查询、被理解、被协作。

一点个人感受

marmot 是这周让我想得最久的一个。不是因为它做了什么复杂的事，恰恰相反——它做的事情很简单：把数据在哪这件事说清楚。但这件事在 AI agent 开始进入工作流之后，突然变得不那么简单了。

hexapoda 也让我想起，好的 CLI 工具未必要发明新概念，有时候只是把一件早就该做好的事认真做一遍——加个颜色、借用一套成熟的操作模型——就能好用很多。

committed 我没有专门写，但放在那里也挺应景。在 AI 辅助提交越来越普及的时代，一个检查 commit message 规范的工具，某种程度上是在帮你确认：这条记录是你写的，还是机器写的，有没有差别。

结语

工具总是先于方法论出现。marmot 出现在 MCP 变得普及之前，hexapoda 出现在终端开发体验被重新重视的当下。

不一定每个都要装，但值得知道它们在解决什么。

工具在变，但问题意识不必跟着变。

这一周的 brew update，像是给 AI Agent 做了一次集体亮相。

不是某个 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、有了用量监控、有了数据清洗器，它就从"实验"变成了"生产"。

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

这周的新工具列表，像是在替开发者清理桌面。

那些曾经散落在 /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 省掉了担心数据锁定的负担。

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

下周见。

四月的第四周，工具列表突然变得拥挤。

brew update 之后跳出来一长串新增，
不是那种零星的点缀，而是成批的工具在找自己的位置。
有些是为了连接消息平台，有些是为了给 AI 代码助手加个壳，
还有一些，是 Apple Intelligence 落地后的余波。

本周一句话总结

AI 不再是单一工具，而是变成了需要被"连接"、"管理"、"编排"的基础设施——这周的更新像是在搭建一层中间件。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一周的新增很多，
但有几个工具指向同一个趋势：
AI 代理正在从"工具"变成"需要被管理的对象"。

cc-connect：把 Claude Code 接到你的聊天软件里

一个公式，连上了 9 个 AI 代理和 11 个聊天平台。

cc-connect 做的事情很简单：让你在 Telegram、Slack、钉钉、飞书甚至微信里，直接调用本地的 Claude Code、Cursor、Gemini CLI 或其他 AI 编码助手。不需要公网 IP，不需要自己搭服务器，装完就能用。

它解决的不是"怎么用 AI 写代码"这个问题，而是"怎么在不离开聊天软件的情况下用 AI 写代码"。对于很多人来说，聊天软件已经是工作流的中心——团队讨论在那里，任务分配在那里，现在 AI 代理也要去那里。

43 个安装量说明它还很小众，但这种"桥接"本身是一个信号：AI 代理不再是单独打开的应用，而是要被嵌入到现有工作流里的服务。

Web 管理界面可以配置多个项目，支持多代理编排、会话管理、模型切换——这些功能出现在一个 Homebrew formula 里，有点意外，也有点合理。

t3-code@nightly：给 AI 代码助手加个壳

T3 Code 是一个"minimal GUI for AI code agents"。它的逻辑更直接：既然 AI 代理已经在后台跑了（Claude Code、Cursor、Aider 等），那给它套个简单的图形界面会不会更好用？

界面确实简单：左边是文件树，右边是对话框，底部是终端输出。没有 VS Code 那么重的插件系统，没有 JetBrains 那么复杂的配置菜单，就是一个能让你和 AI 对话、看它改代码的窗口。

这种"精简"背后有个隐含判断：当 AI 能处理大部分编码任务时，IDE 的复杂度就变成了负担。你不需要那么多快捷键，不需要那么多面板，只需要一个能让 AI 展示它工作的地方。

nightly 版本的存在说明这个项目还在快速迭代中。43 个安装量和 cc-connect 一样，都是早期采用者的数量级。

google-gemini：Apple Intelligence 缺席后的替代方案

Google Gemini 桌面应用在四月登陆 macOS，要求 arm64 架构和 macOS 15+。2380 个安装量是这周所有新增里最高的。

它的出现有个背景：Apple Intelligence 在国内用不了，而 Google 的 Gemini 应用刚好填补了这个空白。不是所有人都愿意折腾区号、换账号，但所有人都想要一个能在桌面上随时唤起的 AI 助手。

FluidVoice（离线语音转文字，170 安装量）也是同样的逻辑：当系统自带的听写功能不够好或者不可用时，第三方的 AI 增强方案就成了刚需。

这两个工具的共同点是"补位"。它们不是创新，而是在现有生态的空缺处填上自己的形状。

趋势观察：AI 代理中间件化

如果把 cc-connect、t3-code、pocket-id（身份认证）、renameclick（AI 文件重命名）放在一起看，能看到一个模式：

AI 不再是单一工具，而是变成了需要被连接、管理、认证、封装的基础设施。

• cc-connect 负责把代理接到聊天平台
• t3-code 负责给代理套个轻量 GUI
• pocket-id 负责管理谁可以访问这些代理
• renameclick 负责把 AI 能力应用到具体场景（文件命名）

这和十年前的"云服务中间件化"很像。当时出现了 Kubernetes、Docker Swarm、Consul 这些工具来管理微服务；现在出现了类似的工具来管理 AI 代理。

区别在于，这次的速度更快。从"AI 助手能用"到"需要管理 AI 助手"，只用了不到两年。

其他值得提一下的

Odin 语言工具链成熟：odinfmt（格式化）和 ols（Language Server）的同时出现，说明这个自称"为稳健性、最优性和清晰度设计"的系统编程语言正在形成完整的开发体验。Zig 0.15 的独立分支也是同一件事的另一面。

paneru：窗口管理器的长尾需求：macOS 上的平铺窗口管理器一直有小众但稳定的需求（Amethyst、yabai、Rectangle 各有拥趸）。paneru 的出现说明这个细分市场还有空间。

OpenSSL@4：版本号的惯性：OpenSSL 跳到第 4 版主分支，但绝大多数人还在用 1.x 或 3.x。keg-only 的打包方式说明了 Homebrew 的态度：给你装，但不主动 symlink，让你自己决定要不要用。

一点个人感受

这周的新增列表读起来有点像在翻某家创业公司的产品目录。不是那种"又多了个 XXX 工具"的平淡，而是"原来这个环节已经有人在做产品了"的惊讶。

cc-connect 和 t3-code 这类工具的出现，说明 AI 编码助手已经从"尝鲜阶段"进入了"需要被整合进工作流"的阶段。这不是技术突破，而是工程化。

我注意到两个细节：

1. 安装量都很低：43、43、170……这些数字说明还在早期。但对于 Homebrew 这种分发渠道来说，早期采用者的选择往往预示着下一步的主流。

2. 夜间构建版本的增多：t3-code@nightly、vlc@nightly（虽然即将被废弃）……这说明有些项目正处于快速变化期，稳定版跟不上节奏。

还有一点主观的感受：当"管理 AI 代理"变成一个独立的需求类别时，有点讽刺。我们本来指望 AI 能简化管理工作，结果反过来要管理 AI 本身。但这可能就是技术演进的路径——每一层抽象都会带来新的复杂度，然后再催生下一层抽象来处理它。

结语

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

这周新增了 7 个 Formula 和 15 个 Cask，是近几个月最热闹的一周。但真正值得记住的不是数量，而是方向：AI 正在从"用来做什么"变成"怎么被组织起来"。

有时候，brew update 之后看到的不只是新工具，还有工具之间的空隙——以及填补那些空隙的新工具。

四月中旬,苹果的系统能力开始以工具的形态外溢。

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 402，一个等了二十多年的状态码，终于有人把它当真了。

三月末的更新列表里，有一种"不想等"的感觉。
不是那种急躁，是那种"既然要做，就不等标准完善了"的态度。
从终端里直接处理视频，到把付费写进 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 伴侣工具，我觉得方向很明确，但可能还早。现在装一堆小工具，不如等它们合并成一个。

结语

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

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

下期见。

开发工具的边界正在从“代码编辑器”向“上下文与代理”扩散。

这一期看起来是常规的 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；
但它们一旦被框架或数据库采用，就会悄悄进入你的日常工作流。

结语

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

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

很多新工具，并不是为了增加能力，而是减少摩擦。

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

本周一句话总结

这周新增工具明显围绕 构建效率、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 的更新记录，其实也是一份开发工具生态的变化日志。

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

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

越来越多工具正在离开桌面，走向系统深处。

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

本周一句话总结

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

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

• 容器运行环境
• 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 的更新列表有时像一份技术世界的地下水位报告。

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

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

真正重要的工具，往往不在桌面上，而在底层。

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

本周一句话总结

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

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

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

• 开发环境结构
• 容器运行方式
• 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 的更新列表，
有时像一份技术世界的地下水位报告。

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

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

真正的变化，往往发生在“看不见的底层”。

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

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

本周一句话总结

本周最明显的趋势不是“新能力”，
而是：围绕 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 正在从“插件式能力”
走向“独立运行环境”。