herdr 一个窗口调度多个 Coding Agent

什么是 Herdr Herdr 是一个运行在终端里的 AI 编码 agent 多路复用器（agent multiplexer）。官方用一句话概括它的定位：Herdr 之于编码 agent，就像 [[tmux]] 之于终端。它运行在你的 agent 运行的地方——本地机器、服务器，或任何可以 ssh 进去的环境，让你在一个终端里同时观察和操作多个正在工作的 agent。 随着 [[Claude Code]]、[[Codex]]、[[OpenCode]] 这类终端原生的编码 agent 流行起来，开发者常常会同时跑好几个 agent 处理不同的任务或仓库 Read more ...

2026-07-01 coding-agent , tmux , zellij , multiplexer , terminal-multiplexer , terminal

Claude Code 第三方 API 代理配置 Headroom

最近在给自己的 AI 编程工作流加入 [[Headroom]] 上下文压缩工具时，遇到了一个需要特别注意的配置问题。相信有不少人和我一样，为了降低成本或者改善访问体验，已经在 [[Claude Code]] 或 [[Codex]] 里配置了第三方 API 代理，比如一些第三方聚合平台或者自建的转发服务。这时候想再套上一层 Headroom 做 Token 压缩，就需要特别注意配置细节，不然两层代理会打架。 为什么要用第三方代理 先简单说一下背景。使用 Claude Code 或 Codex 的时候，默认走的是 Anthropic 或 OpenAI 的 Read more ...

2026-06-30 claude-code , headroom , api-proxy , token-optimization , llm , codex

Headroom：让 AI Agent 少花冤枉钱的上下文压缩工具

最近一段时间我在深度使用 [[Claude Code]] 做开发工作，用得越多，账单就越触目惊心。一次稍微复杂一点的任务，比如让它读取几个文件、搜索一下代码、跑一下测试，轻轻松松就能烧掉超过 100K 的 Token。更让人无奈的是，这 100K 里面有相当大一部分是重复冗余的内容——工具调用的输出、日志、搜索结果，它们被原封不动地塞进上下文，再一次次地发给模型，而模型其实只需要其中很小一部分关键信息。 直到我发现了 [[Headroom]] 这个工具，才意识到这个问题其实有解。 上下文膨胀是 AI 开发成本的隐形黑洞 在聊 Headroom Read more ...

2026-06-26 ai , claude-code , token , context-window , headroom , mcp

用 Harbor 搭建私有 Docker Registry：从安装到日常使用的完整实践

我维护过几个跑在自己服务器上的小项目，构建出来的 [[Docker]] 镜像最早都是直接推到 [[Docker Hub]] 上的。用了一段时间之后开始觉得别扭：一些只在内网跑的服务镜像，没必要也不应该传到公开的仓库；Docker Hub 对匿名拉取做了限流之后，CI 流水线偶尔会因为触发了速率限制而失败；再加上想给不同的项目、不同的同事分配不同的访问权限时，公共仓库这套体系根本满足不了。折腾到后来我意识到，是时候在自己的机器上搭一个真正能用的私有镜像仓库了。 最朴素的做法当然是直接跑官方的 registry:2 镜像，几行命令就能起一个 [[Docke Read more ...

2026-06-10 harbor , docker , registry , devops , self-hosted , kubernetes , helm

用 New API 打造个人 AI 网关：统一管理所有大语言模型接口

这段时间我同时用着好几个大语言模型服务：日常写作和代码靠 [[Claude]]，轻量任务交给 [[Codex]]，搜索增强用 [[Antigravity]]，还有几个本地跑着 [[Ollama]] 的小模型供离线场景使用。每个平台各自的 API Key 散落在项目环境变量里，月底要去好几个后台分别对账，想横向对比两个模型的输出还得打开不同的网页或客户端来回切换，很费事。 用这种方式折腾了一段时间之后，我开始认真找一个能统一管理这些 API 的工具。最终落在了 [[New API]] 上，用下来解决了不少痛点，今天把使用心得记录一下。 什么是 Ne Read more ...

2026-06-09 ai , llm , api , new-api , open-source

Surfingkeys：比 Vimium 更强大的浏览器键盘控制扩展

最早接触 [[Vimium]] 是在学习 Vim 编辑器之后，那种能用键盘完全控制浏览器的感觉确实让人着迷。不用频繁移手到鼠标，链接跳转、页面滚动、标签切换全用键盘搞定，效率提升的体验是实实在在的。用了几年 Vimium 之后，我开始接触到 [[Surfingkeys]]，起初以为不过是另一个同类扩展，但深入用下来才发现这两者的差距远比我想象的大。 为什么要用键盘控制浏览器 对于长期使用 [[Vim]] 的人来说，键盘操作的肌肉记忆已经根深蒂固。在编辑器里习惯了 hjkl 导航，切换到浏览器还要去抓鼠标总觉得很割裂。更重要的是，对于程序员、研究者 Read more ...

2026-06-02 chrome-extension , vim , keyboard , browser , productivity , surfingkeys

Denote 介绍 Emacs 下基于文件名的笔记系统

最近在 GitHub 上闲逛的时候，我发现了 [[李继刚]] 整理的一批 [[Claude Skills]]，出于好奇就 clone 下来翻了翻仓库。打开目录一眼扫过去，几乎所有 Skill 输出的文档文件名都长得很特别，大致是这样的形式: 20260527162000==z--投资分析-ajinomoto-2802。这种带着长串数字时间戳、夹杂 == 和 – 分隔符的写法，一眼看上去既不像我熟悉的 [[Jekyll]] 那种 YYYY-MM-DD-title.md，也不像 [[Obsidian]] 里常见的中文标题直接做文件名，反而有种”工程化”过头的 Read more ...

2026-05-28 denote , emacs , zettelkasten , obsidian , note-taking , knowledge-management

Ghostty 和 xterm-ghostty 是什么

最近我在 macOS 上重新整理终端工具链的时候，又一次认真看了 [[Ghostty]]。很多人第一次接触 Ghostty，会先被它的界面、速度或者作者背景吸引，但只要打开 Shell 跑一个 echo $TERM，很快就会看到一个更陌生的名字：xterm-ghostty。这个名字看起来像是传统 xterm 的变种，实际上它背后代表的是 Ghostty 对终端兼容性的一整套设计思路。很多人把它当成一个无关紧要的环境变量，但如果你经常使用 [[SSH]]、[[tmux]]、[[Vim]]、[[Neovim]]、[[less]] 或者各种 TUI 工具，理解 Read more ...

2026-05-23 ghostty , terminal , xterm-ghostty , terminfo , shell

终端开发的新范式：从 Gemini CLI 到 Antigravity CLI

终端智能体的新旅程 作为一个长期泡在终端里的开发者，我的工作流几乎完全是由命令行和各类快捷键支撑起来的。从早期的命令行自动补全，到后来各种基于大模型的命令行聊天助手，AI 在终端里的角色一直在发生改变。然而，大多数时候我依然觉得有些割裂。当我们需要 AI 帮我们重构一个复杂的跨文件模块、运行构建命令并根据报错自动迭代时，传统的聊天式工具就显得力不从心了。 我最近一直在深度使用 Google 推出的新一代命令行开发工具 [[Antigravity CLI]]。在实际体验了一段时间之后，我深刻地感受到，它不仅仅是又一个命令行 AI 助手，而是代表了一种全 Read more ...

2026-05-22 developer-tools , command-line , ai-agent , google-gemini , sandboxing

Antigravity CLI：Google 推出的下一代终端 AI 编程智能体

最近在关注 Google I/O 2026 的动态时，看到了一个让我颇感兴趣的发布——[[Antigravity CLI]]，Google 官方宣布用它来取代已经积累了超过 10 万 GitHub Stars 的 [[Gemini CLI]]。这个时机有点微妙：个人版 Gemini CLI 用户必须在 2026 年 6 月 18 日前完成迁移，否则将失去模型访问权限。作为一个长期在终端里工作、也在持续关注 AI 编程工具演进的开发者，我觉得有必要认真研究一下这个新工具到底带来了什么改变。 Gemini CLI 为什么需要被替代 要理解 Antig Read more ...

2026-05-22 ai , cli , terminal , google , gemini , antigravity , ai-agent

电子书

本站提供服务

文章分类

最近文章

  • herdr 一个窗口调度多个 Coding Agent 什么是 Herdr
  • Claude Code 第三方 API 代理配置 Headroom 最近在给自己的 AI 编程工作流加入 [[Headroom]] 上下文压缩工具时，遇到了一个需要特别注意的配置问题。相信有不少人和我一样，为了降低成本或者改善访问体验，已经在 [[Claude Code]] 或 [[Codex]] 里配置了第三方 API 代理，比如一些第三方聚合平台或者自建的转发服务。这时候想再套上一层 Headroom 做 Token 压缩，就需要特别注意配置细节，不然两层代理会打架。
  • Headroom：让 AI Agent 少花冤枉钱的上下文压缩工具 最近一段时间我在深度使用 [[Claude Code]] 做开发工作，用得越多，账单就越触目惊心。一次稍微复杂一点的任务，比如让它读取几个文件、搜索一下代码、跑一下测试，轻轻松松就能烧掉超过 100K 的 Token。更让人无奈的是，这 100K 里面有相当大一部分是重复冗余的内容——工具调用的输出、日志、搜索结果，它们被原封不动地塞进上下文，再一次次地发给模型，而模型其实只需要其中很小一部分关键信息。
  • 用 Harbor 搭建私有 Docker Registry：从安装到日常使用的完整实践 我维护过几个跑在自己服务器上的小项目，构建出来的 [[Docker]] 镜像最早都是直接推到 [[Docker Hub]] 上的。用了一段时间之后开始觉得别扭：一些只在内网跑的服务镜像，没必要也不应该传到公开的仓库；Docker Hub 对匿名拉取做了限流之后，CI 流水线偶尔会因为触发了速率限制而失败；再加上想给不同的项目、不同的同事分配不同的访问权限时，公共仓库这套体系根本满足不了。折腾到后来我意识到，是时候在自己的机器上搭一个真正能用的私有镜像仓库了。
  • 用 New API 打造个人 AI 网关：统一管理所有大语言模型接口 这段时间我同时用着好几个大语言模型服务：日常写作和代码靠 [[Claude]]，轻量任务交给 [[Codex]]，搜索增强用 [[Antigravity]]，还有几个本地跑着 [[Ollama]] 的小模型供离线场景使用。每个平台各自的 API Key 散落在项目环境变量里，月底要去好几个后台分别对账，想横向对比两个模型的输出还得打开不同的网页或客户端来回切换，很费事。