上一期,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)。

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

今天是周六，但是要上班。
比预想中，人要来的多一些，
有些人，我以为至少周一才会来上班……

以前的我，就是这样的人

观察同类

Dayfold的开发还是比较顺利，
整个产品“完全”按照我的想法💡设计，
距离完成的日子越来越近。

昨天因为一些不太开心的事情，又去翻看了其他笔记类app，
发现都很有特色，

• 有些UI设计特别，比如网格、手写字体
• 有些设计了一些特别的功能，比如倒计时、相册时间轴
• 有些交互简洁，纯纯就是记录

对比以上，Dayfold的路线完全不一样。

• 主打记录，支持markdown语法
• 记录每天的心情，关注日常小事
• 地图模式，可以在任意地点打卡
• 日历模式，可以轻松记录行程安排
• 照片流模式，可以快速回顾过往的点滴记录

当然，还有一些未开发的想法，比如旅行等等

想来想去，不想了，直接干

昨晚一直在想，
这类app的受众人群很少吗？
如何才能从这类app中脱颖而出？
现在的UI设计，是不是太俗气？

个人感觉，
受众人群不少，
脱颖而出有些难度，
UI不算俗气，中规中矩

行吧，写到这里
我的心情好多了
今天继续功能迭代
争取早点开发完成

最近的成果

Memories 往年回顾

基本的交互已经确定，但是UI可能还会变化

Table 支持对齐

对齐方式：

• 左对齐
• 居中对齐
• 右对齐

markdown工具栏优化

今天是坐班站岗的最后一天，明天就国庆了。

公司空荡荡的，没几个人，我们这层不到5个。
很多人，在中秋节前就开始请假了，再加上中秋和国庆，差不多半个月看不到人。

前段时间，公司裁员，很多工位就空了。
现在，就更加显的空旷。

本来，我也可以跟他们一样放假，
但是，原本的假期已经用完，领导说没事，可以跟他说，就可以批假，不影响工资。

在家也挺无聊，不是吃饭睡觉，就是打游戏。
现在连追剧都觉得没意思。

想到公司给的token还没用完，Dayfold也还有一些功能没做，
就没请假了，连续3天都来公司上班。
不得不说，这几天干活效率贼高，做了好几个核心功能。
原本以为要到年底才能开发完Dayfold，现在感觉10月差不多就做完了。

token 很坚挺

最开始，公司是提供 Claude Sonnet(4.6 ~ 4.8) / Opus(4.7 ~ 4.8) / Fable
后来，由于政策原因，下架了所有海外模型，只能用国产模型。

一直以来，都是使用 Claude Code，换上国产模型后，有段时间非常难受。
感觉AI是不是有点智障，后面找到原因：CC 与 国产模型不适配。

如何解？仔细去搜索，你会发现主流的国产模型（GLM / Kimi / MiniMax）都有支持 CC，根据官方文档配置，90%的功能可以使用。

虽然不能100%还原CC的全部功能，但还是能胜任绝大多数场景，不影响 vibe coding。
而且自从换了国产模型后，发觉 token 变的坚挺了，
日常功能开发、bug修复和需求文档输出，都能毫无顾忌的使用，一点都不用担心token消耗。

可能与我设置的推理程度（/effort）有关系吧？
通常都是设置，medium。

大部分情况下，都能正常工作，没有出现降智的情况。
偶尔遇到一些非常难处理的bug，或者复杂的功能设计时，
用max，也就解决了。

截止到目前，才80%。

本月做了哪些功能

侧边栏里面，除了iCloud Sync还没做，其他都做完了。

以下几项的功能需要再斟酌：

• Memories
• Emotion Wave

Markdown编辑器优化，支持：

• 双mode切换
• markdown 快捷输入工具栏

Markdown语法增强，做了以下几个：

• 支持 footnote 脚注
• 支持 Math 公式
• 支持 Mermaid 流程图

Mermaid 流程图，目前是使用 Markdown → HTML → WKWebView → Mermaid.js 的路线，后面要改成原生 SwiftUI 架构。

• Australware/swift-mermaid: A pure-Swift Mermaid diagram renderer for Apple platforms - no JavaScript engine, no WKWebView, no network access.
• braddschick/MermaidKit: SwiftUI SDK for MermaidJS
• lukilabs/beautiful-mermaid-swift: Native Mermaid diagram renderer for Swift
• lukilabs/beautiful-mermaid
• lukilabs/elk-swift: A pure Swift port of the Eclipse Layout Kernel (ELK) graph layout engine
• hggz/Mermaid-iOS: Mermaid diagram rendering for iOS
• CyberdyneCorp/swift-markdown-engine: Native IOS / MAC OS markdown engine

写在最后

除了上面写到的功能，还修复了很多bug和优化体验的东西。
幸好，不用一个个提bug，直接截图或者录个视频给AI，让它自己修，否则累死。

前三周,我们在看 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 从"一个程序"重新定义成"一个同事"。

前面说过，陆陆续续开发5个多月，现在仍在开发。
上周末，花了一天时间，完成了以下几项开发和修改：

• 添加笔记本信息设置
• 添加更换应用图标功能
• 优化笔记本切换动画
• 优化笔记编辑器UI交互

待遗留项：

1. iCloud Sync
2. 中英文国际化
3. 自定义字体

以上按照重要顺序排列，iCloud Sync 是重头，涉及数据结构和附件存储设计，另外这个功能又牵连笔记本编辑器的设计。

事实上，一开始我打算做支持markdown语法的编辑器，但做得并不完善。里面有很多瑕疵，这些瑕疵很大程度会影响到后续iCloud Sync，进而影响Sync之后，笔记文档的渲染效果。

需要花多久时间，才能搞定编辑器和iCloud Sync，我并不确定。

退而求其次，我可能会放弃支持markdown，优先搞定普通编辑器和iCloud Sync，但需要预留足够的扩展空间，否则将会给现有代码带来一场灾难。

用AI打磨细节

每一个圆角、每一个字体，可能都包含了开发者对产品细节的感悟。包括不限于，颜色、文案、交互效果等。

对于第一次准备上架App Store的我来说，不单是功能实现，还要考虑用户体验。比如，颜色对比能否提高编辑效率和阅读体验？弹窗高度是否导致操作按钮无法触及？等等诸如此类的问题。

这些问题，很容易发现，但却不容易解决。以前是团队，术业有专攻，各自负责一块，对于发现的问题，能坐下开会一起讨论协商。

现在，情况变了。一个人面对AI和屏幕。

虽然AI极大提高了工作效率，节省了人员之间的协调成本，但在面对极其复杂的系统设计和精细要求时，仍然难免会落入围谷，缺失多样性的选择和意料之外的惊喜。

“为何会这样？AI，通常会以确定性、可靠性和稳定性的方式开发和思考问题。”

面对这样的情况，那么细节打磨可能就是一次标准化生产的过程。

如果这么想，或许就有了答案。

当然，我也可以要求AI按照个性化的要求去开发，但无疑是自找麻烦。

未来编程会变成什么样子

突然想起前段时间看过的一篇文章《Nobody Argued For Your Stack》，文章中作者非常在意：

“A monoculture doesn't just kill the alternatives. It kills the pressure. An ecosystem without pressure doesn't stay good. It stays stuck.”

甚至，未来编程领域，会出现：

“Frontend converges on React. Systems converges on Rust. Scripting converges on Python. Even the sites that are just pages converge on Next, fit be damned.”

以上提到的事情，正在发生，而 “next idea” 却不知从何而来。

将你喜欢的歌曲，作为手机来电铃声

“非常负责任的告诉你，千万不要这么做。否则，你会后悔。”

刚进入IT这领域的时候，非常兴奋，每天无时无刻都在接受新的信息浪潮冲刷。但随着时间的打磨，对于技术的追求，逐渐趋向简单、稳定和可靠。

新鲜事物，往往接触一会，就失去了耐心。

现在有了AI，可以非常迅速的在项目里应用最新技术，但时间久了，也会变得厌烦。

尤其，当你发现AI不是全能的时候，会更加沮丧。比如：

• 不停优化agent配置
• 更换不同的 harness，获得更好的操控体验
• 优化prompt，提升AI输出质量
  ...

当周围的人，每天都在播放同一首歌，你还会继续喜欢吗？

当每隔一段时间，就要折腾一遍agent，你还会喜欢吗？

这段有点偏离主题，言归正传，看看目前做了哪些东西？

周末开发了什么

笔记本信息设置：

1. 支持设置封面图片
2. 支持修改笔记本名称
3. 支持笔记本单独设置密码

应用图标功能，目前设计了4个图标。

笔记本切换动画优化，原来只是个tab切换，现在改成了3D。

笔记编辑器UI交互优化，现在变得跟苹果备忘录几乎一样了😂

参考：

• DaniilL12321/customToolbar_iOS26: custom animated toolbar with new liquid glass design iOS 26

距离发布上架又近了一点，期盼早点结束开发。

• Machinarium for iPhone - Download
• Machinarium Pocket Edition (1.0.1, iOS 5.0) : Free Download, Borrow, and Streaming : Internet Archive
• Get Machinarium: Pocket Edition for your iPhone now | AppSpy

xcode 历史版本下载，不用愁。

• Xcode Releases | xcodereleases.com
• macOS 版本对应的 Xcode 版本，以及 Xcode 历史版本下载 - 阳光知道
• xcode 旧版本、历史版本下载_xcode下载

开发Dayfold的开发有一段时间了，目前主要功能都有，还在继续打磨细节。功能如下：

• 创建笔记本，增删改查
• 创建日记，增删改查
• 编辑日记，添加图片、tag、心情、视频
• 查看日记的方式有多种：图片瀑布流、日历行程和地图模式
• 删除日记时，支持一些简单的手势功能；
• 支持iCloud Sync（开发中）
• 支持Memories（开发中）
• 支持切换Theme，有三种配色
• 支持Notifications（开发中）
• 支持Privacy & Face ID（基本完成，后续需要做差异化）
• 支持Hidden Notebook（开发中）
• 支持数据统计
• 支持回收站
• 支持markdown语法（还不完善）

陆陆续续开发有5个多月，期间有蛮多收获。

为什么选择Swift

在IT行业干了10多年，专职于前端领域，对于后端编程语言基本没兴趣，不喜欢与枯燥的数据库和麻木不仁的CURD打交道，不是看不起或者有偏见，纯属喜好。

就行业发展态势、职业发展天花板和就业形势来说，做后端要活得更久一点。

但是，对于漂亮的UI和感性的交互，深深为之着迷，不愿自拔。

Swift 语言发展也有一段时间，相信在苹果的带领下，完全取代Object C不是问题。就目前来，iOS 生态中已经有很多优秀的 Swift 应用。

vibe coding 是什么

vibe coding，又被称为氛围编程。简单来说，是一种依赖AI的编程方式。不需要开发者有特别厉害的代码能力和编程技巧，只需要一点编程思维和产品设计能力即可。

vide coding 的过程，自己既是开发、产品、测试，也是用户。需要自己写产品需求和开发设计文档，也需要自己调试代码和功能测试，总之，个人即团队。

为何开发笔记应用

其实一开始，我也不知道开发什么。只是觉得vibe coding的时代需要做些有趣的事情，才不会留下遗憾。

事实上，我用过多款笔记应用：Evernote / OneNote / DayOne / Obsidian，包括代码编辑器 notepad ++ / Sublime / VS Code 都可以做笔记。差点忘了，还有 iPhone 中的备忘录，以及最新出现的无边记。

但是它们这些产品给我的感觉，不是笔记。而是记录、草稿，或者是资料库，没有一点笔记该有的样子。首先应该有笔记本，然后才有一页一页的笔记，每一页都有自己珍惜的文字和记忆，这些虽然算不上财富，但也是非常私密且有纪念意义的、不可取代的珍藏。

因此，我想做一款有质感、轻松记录和值得回忆，阅读后能会心一笑的笔记应用。

开发遇到的那些事

首先我要感谢以下这些优秀的应用：

• Hardcover
• DayOne
• 苹果备忘录

Hardcover，UI设计非常精致，整体风格别具一格。

DayOne，属于全能型，面面俱到，功能非常丰富。

苹果备忘录，非常简洁，有很多灵动的交互。

Dayfold 这个名称来自ChatGPT，翻译成中文“Dayfold（折叠一天）”。

由于应用开头是字母D，通过Google AI Studio生成icon，然后再追加了扁平化设计，变成了现在的样子。

Dayfold 的主页和侧边栏设计参考 Hardcover，精美的封面设计，让人看了爱不释手，侧边栏功能，清爽易用。

Privacy & Face ID 和回收站功能，参考 DayOne，简洁实用。

日记编辑器 大部分参考苹果备忘录，功能丰富，但不混乱。

在网络上找到以下资料和代码库：

• How to create this floating toolbar? : r/iOSProgramming
• DaniilL12321/customToolbar_iOS26: custom animated toolbar with new liquid glass design iOS 26

还有视频，

数据统计的功能，本来想简单做做，但看了 DayOne 的UI设计后，决心重新设计，
借鉴了 GitHub 的 Contribution Graph。

然后在Stitch中生成，

最终效果如下，

另外还参考了2个开源项目：

• Sharing My Contribution Graph Library, ContriBoot! : r/SwiftUI
• mazefest/ContriBoot: ContriBoot is a SwiftUI library that makes it simple and fast to create a year-style contribution chart, like the ones you see on GitHub.
• jacklv-coder/HeatmapKit: A SwiftUI calendar heatmap and contribution graph component.

情绪波（Emotion Wave）

一种模仿 GitHub 提交记录图（Contribution Graph）的视觉化情绪追踪工具。它通过不同深浅的颜色方块来代表你每天的心情指数，让你在年终或月底时，能够像程序员看代码提交量一样，一目了然地回顾自己全年的心理健康轨迹。

设计如下，

• 12 个情绪及 Energy 数值
• 0～100 能量体系
• Emotion Wave 曲线设计
• Emoji 节点设计
• 情绪分类

最开始，是参考五线谱，但觉得太复杂，改为了波浪线……

采用12个情绪也是有原因的，参考了音乐里面的“十二平均律”。

另外借鉴了：

• Mood Record Is Now Live: Track 12 Emotions, See Mood Patterns in Calendar View, and Review with Widgets

总之，Dayfold 能顺利开发，离不开整个AI生态系统、丰富的笔记类应用市场、个人实施能力和审美。

前几周,我们在看工具重新挑形态——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 就不只是"能干活"了，它开始有了一些连续性。

vi-mode: zsh & inshellisense

• Valiev/almostontop: almostontop zsh plugin
• zsh/Functions/Zle/select-bracketed at master · zsh-users/zsh
• zsh/Functions/Zle/select-quoted at master · zsh-users/zsh
• zsh/Functions/Zle/surround at master · zsh-users/zsh
• hlissner/zsh-autopair: Auto-close and delete matching delimiters in zsh
• alexpasmantier/television: A very fast, portable and hackable fuzzy finder.
• hmbldv/trmnl: Portable terminal configuration: Kitty + tmux + zsh + Starship
• Home | Zim Framework: Modular, customizable, and blazing fast Zsh framework
• Zsh Vi-more: Vi mode, but more
• What zsh plugins & shell tools do you actually use every day? : r/zsh
• microsoft/inshellisense: IDE style command line auto complete

有意思的文字工具 :D

• busyloop/lolcat: Rainbows and unicorns!
• cmatsuoka/figlet: Claudio's FIGlet tree

上周我们刚把 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"。

具体的东西才会留下来。

练习英文口语的利器，非常适合纠正口音。

f/textream: Textream is a free macOS teleprompter app for streamers, interviewers, and presenters. It highlights your script in real-time as you speak, displayed in a beautiful Dynamic Island overlay. With extensible features.

一个检测USB接口的小玩意。

• gnomeria/usbtree: Live USB device tree in your terminal. Rust TUI, no root, no libusb. Full activity metrics on Linux; device tree on macOS/Windows.

tmux恢复session，也会有痛点，不能按需，只能全部。lazy-tmux 可以解决这个问题，UI交互也蛮不错。

tmux的session可以通过rsync同步到各个设备。

• alchemmist/lazy-tmux: Lazy tmux it is a fast session manager and saver for tmux. You can save all your session and lazy restore it.
• westpoint-io/lazyrsync: 🦀 A friendly terminal UI for rsync, written in Rust. Reusable profiles, an honest dry-run diff, and live progress, even over SSH.
• rsync 用法教程
• timvw/tmux-assistant-resurrect: Persist and restore AI coding assistant sessions (Claude Code, OpenCode, Codex CLI, Pi) across tmux restarts

做个自用的、能加密的个人网盘。

• wangshengithub/staticshield: 一款安全又便捷的网页加密工具。
• AndySkaura/mifun-storage: 米饭云盘-小文件tg存储系统

前几周我们看着 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——这个故事本身比任何公式描述都更值得记。可能在某个我们看不见的角落里,有一类工具就是这样开始的:不是因为缺一个功能,是因为有人看到一种新的工作方式没人正经服务过。

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