命令行工具 on KnightLi的博客

RTK：给 AI 编程代理省 token 的命令行代理工具

Wed, 27 May 2026 13:52:01 +0800

rtk-ai/rtk 是一个面向 AI 编程代理的命令行代理工具。它的思路很直接：很多 agent 在开发过程中会频繁调用 ls、cat、grep、git status、git diff、测试命令和构建命令，而这些命令的原始输出经常又长又重复。RTK 会在命令输出进入 LLM 上下文之前先做过滤和压缩，让模型看到更短、更有用的结果。

项目地址：rtk-ai/rtk

它解决的是什么问题

AI 编程工具真正贵的不只是模型调用次数，还有上下文里被塞进去的无效信息。

例如：

ls -la 可能输出大量权限、时间和无关文件。
git diff 可能夹杂很多重复上下文。
pytest、cargo test、npm test 失败时，最重要的是失败用例和错误栈，而不是所有通过项。
docker ps、kubectl pods、aws 命令往往字段很多，但 agent 只需要少数关键信息。

这些输出如果原样进入模型上下文，会快速消耗 token。RTK 的目标不是替代这些命令，而是在它们和 AI 编程代理之间加一层“压缩代理”。

RTK 的基本工作方式

RTK README 里给出的定位是：它会在命令输出到达 LLM context 之前，对结果做过滤和压缩。它是一个 Rust 单文件二进制程序，支持大量常见开发命令，并强调低额外开销。

它主要做四类处理：

Smart Filtering：去掉注释、空白、样板内容和低价值噪音。
Grouping：把相似项目聚合起来，例如按目录、错误类型或状态分组。
Truncation：保留关键上下文，截断重复或不重要的部分。
Deduplication：把重复日志折叠成更短的计数表达。

从 agent 的角度看，命令仍然是熟悉的开发命令；变化在于返回给模型的结果更短。

支持哪些命令

RTK 覆盖的命令范围比较偏“日常开发现场”：

文件查看：rtk ls、rtk read、rtk find、rtk grep
Git：rtk git status、rtk git log、rtk git diff
GitHub CLI：rtk gh pr list、rtk gh pr view、rtk gh issue list
测试命令：rtk pytest、rtk go test、rtk cargo test、rtk vitest、rtk playwright test
构建和 lint：rtk lint、rtk tsc、rtk next build、rtk cargo clippy
容器和云命令：rtk docker ps、rtk docker logs、rtk kubectl pods、rtk aws sts get-caller-identity
数据和日志：rtk json、rtk deps、rtk env、rtk log

这类工具最适合 agent 高频读命令输出的场景。它不负责替你写代码，而是让 agent 少读废话。

安装和接入方式

README 给了几种安装方式。

Homebrew：

`1`	`brew install rtk`

Linux/macOS 快速安装：

`1`	`curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh \| sh`

Cargo：

`1`	`cargo install --git https://github.com/rtk-ai/rtk`

安装后可以先检查版本和统计信息：

1
2

rtk --version
rtk gain

接入 AI 编程工具时，可以用初始化命令：

rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor
rtk init --agent windsurf
rtk init --agent cline

初始化后需要重启对应的 AI 工具。对于支持 hook 的 agent，Bash 命令会在执行前被重写，例如把 git status 变成 rtk git status，让 agent 收到压缩后的输出。

使用时要注意什么

RTK 的收益取决于 agent 是否真的通过 shell 命令读取信息。

README 里特别提醒：像 Claude Code 的内置 Read、Grep、Glob 这类工具不经过 Bash hook，因此不会自动被 RTK 改写。要让 RTK 介入，需要使用 shell 命令，例如 cat、head、tail、rg、grep、find，或者直接调用 rtk read、rtk grep、rtk find。

这点很关键。RTK 不是全局透明地压缩所有 agent I/O，它更像是 shell 命令层面的代理。

Windows 用户也要注意，README 建议不要直接双击 rtk.exe，而是把它放到 PATH 里，通过 Command Prompt、PowerShell 或 Windows Terminal 使用。它也提到，如果想获得完整 hook 体验，WSL 会更自然。

适合谁用

RTK 适合三类人：

重度 AI 编程用户：每天让 agent 跑很多 git、rg、测试和构建命令。
大仓库用户：命令输出动辄几百行，agent 经常被无关上下文淹没。
关心 token 成本和上下文窗口的人：希望模型把注意力放在失败、变更和关键文件上。

如果你的项目很小，或者 agent 主要通过 IDE 内置工具读取文件，RTK 的体感收益可能没那么明显。它真正发力的地方，是命令行输出又长又频繁的开发流。

我的判断

RTK 的方向很实用。现在很多 AI 编程工作流都在强调更强的模型、更大的上下文、更长的任务，但开发现场还有一个朴素问题：agent 经常读了太多没必要读的东西。

把命令输出先压缩，再交给模型，能减少 token 消耗，也能降低模型被噪音带偏的概率。

不过它不是魔法开关。要用好 RTK，需要把 agent 的工作方式往 shell 命令靠一靠，并确认当前工具的 hook 是否真的生效。对 Codex、Claude Code、Gemini CLI、Cursor、Windsurf 这类场景来说，它更像一个值得测试的“上下文节流器”：不改变开发命令本身，但让 agent 读到更干净的结果。

wx-cli 项目解读：用命令行查询本地微信聊天记录

Mon, 18 May 2026 21:02:21 +0800

wx-cli 是一个用 Rust 编写的本地微信数据命令行工具，目标是在命令行里查询自己的微信会话、聊天记录、联系人、群成员、收藏、朋友圈、公众号文章、附件和统计信息。

它不是一个云端微信同步服务，也不是聊天机器人。它更像一个本地只读数据检索层：微信仍然在本机运行，数据仍然留在本机，wx-cli 负责按需解密、缓存和查询本地数据库，然后把结果以 YAML 或 JSON 形式输出给人或 Agent 使用。

这个项目有两个值得关注的点：一是它把微信本地数据查询做成了跨平台 CLI；二是它专门考虑了 Claude Code、Cursor、Codex 这类 AI Agent 的使用场景，提供了 SKILL.md 和带 meta 的结构化输出。

wx-cli 能做什么

按项目 README 的描述，wx-cli 覆盖的功能很完整：

查看最近会话和未读会话。
查询某个联系人或群的聊天历史。
全库搜索关键词。
查看新增消息。
查询联系人、群成员和群昵称。
查询收藏。
查询朋友圈通知、朋友圈时间线和朋友圈正文。
查询公众号文章推送。
列出和提取聊天图片附件。
做聊天统计。
导出聊天记录为 Markdown 或 JSON。

这些能力让它不只是“查聊天记录”，而是把微信本地数据变成了可搜索、可统计、可导出的本地资料库。

为什么适合 AI Agent

很多命令行工具只是给人看的，输出是一段文本。wx-cli 则明显考虑了 Agent 读取。

README 提到，history、search、sessions、unread、new-messages、stats、attachments 等命令会附带 meta 信息。meta 里包含结果状态、未知分片、命中数据的最新时间、session 记录的最新时间等信息。

这对 Agent 很有用。因为 AI 不只需要“查到了什么”，还需要知道“结果新不新”“有没有可能漏消息”“是不是需要重新 init”。例如：

status 可以提示结果是否 ok 或 possibly_stale。
unknown_shards 可以提示是否存在 daemon 当前没有 key 的数据库分片。
chat_latest_timestamp 可以告诉 Agent 当前命中数据里的最新消息时间。
session_last_timestamp 可以帮助判断本地 session 记录是否明显领先于查询结果。

这类元信息可以减少 AI 误判，让 Claude Code、Cursor、Codex 这类工具在处理微信数据时更稳。

安装方式

项目推荐通过 npm 全平台安装：

`1`	`npm install -g @jackwener/wx-cli`

也支持 macOS / Linux 的 curl 安装：

`1`	`curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh \| bash`

Windows 可以在管理员 PowerShell 中运行：

`1`	`irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 \| iex`

如果要从源码构建，也可以直接用 Rust：

1
2

git clone git@github.com:jackwener/wx-cli.git && cd wx-cli
cargo build --release

构建产物是 target/release/wx，Windows 下是 wx.exe。

和 Agent Skill 的关系

wx-cli 还提供了面向 AI Agent 的 Skill。可以通过 skills CLI 一键安装到 Claude Code、Cursor、Codex 等支持 Skills 的环境：

`1`	`npx skills add jackwener/wx-cli`

全局安装：

`1`	`npx skills add jackwener/wx-cli -g`

安装后，Agent 会读取仓库里的 SKILL.md，知道如何安装、初始化和调用 wx-cli。

这意味着你可以让 Agent 帮你做一些本地信息整理任务，例如：

找某段时间某个群聊里讨论过的关键词。
汇总最近未读消息。
从某个会话里导出最近聊天记录。
搜索公众号文章推送链接。
分析某个群聊里的发言统计。

前提仍然是：这些数据必须是你本机、你自己的微信数据。

基本使用方式

初始化前需要保持微信正在运行。不同平台要求不同。

Linux 上可以执行：

`1`	`sudo wx init`

Windows 上需要用管理员 PowerShell：

wx init

macOS 上更复杂。README 说明，默认路径需要先对 WeChat 做 ad-hoc 签名，才能扫描进程内存；重签名后还要清理旧 TCC 授权记录，否则截图、视频通话、麦克风等权限可能出现“看起来已开启但实际拒绝”的问题。项目文档也提醒，重签名会带来 macOS 频繁弹出访问其他 App 数据提示的副作用。

初始化后，可以用下面的命令验证：

`1`	`wx sessions`

能看到最近会话，说明基本链路已经可用。daemon 会在首次调用时自动启动。

常用命令示例

查看最近会话：

`1`	`wx sessions`

查看未读会话：

`1`	`wx unread`

只看真人未读，过滤公众号和折叠入口：

`1`	`wx unread --filter private,group`

查看某个会话最近聊天记录：

`1`	`wx history "张三"`

拉取更多历史消息：

`1`	`wx history "张三" -n 2000`

按时间范围查询群聊：

`1`	`wx history "AI群" --since 2026-04-01 --until 2026-04-15`

全库搜索：

`1`	`wx search "关键词"`

搜索某个群中的关键词：

`1`	`wx search "会议" --in "工作群" --since 2026-01-01`

导出聊天记录：

1
2

wx export "张三" --format markdown -o chat.md
wx export "AI群" --since 2026-01-01 --format json

这些命令都比较适合被脚本或 Agent 调用，尤其是加上 --json 后。

朋友圈和公众号文章

wx-cli 不只查聊天。

朋友圈相关命令分成通知和帖子：

1
2
3

wx sns-notifications
wx sns-feed
wx sns-search "关键词"

需要注意，朋友圈数据只覆盖你本地刷到过的内容。微信客户端按需下载，没在本地出现过的数据，工具也不会凭空拿到。

公众号文章则通过独立命令查询：

wx biz-articles
wx biz-articles --account "返朴"
wx biz-articles --since 2026-05-01 --until 2026-05-10
wx biz-articles --json | jq '.[].url'

它会返回公众号名称、标题、URL、摘要、封面、时间等字段。对做资料整理、文章收集和本地知识库的人来说，这个功能很实用。

附件提取

微信聊天里的图片附件通常不是直接可读的普通图片文件，而是存在 xwechat_files/<wxid>/msg/attach/... 下的 .dat 文件。

wx-cli 提供了两步流程：

1
2

wx attachments "张三"
wx attachments "AI群" --kind image -n 100

先拿到 attachment_id 后，再提取：

`1`	`wx extract <attachment_id> -o ~/Desktop/photo.jpg`

输出报告里会带 md5、dat_path、dat_size、output、format、decoder 等信息。README 中说明它支持 legacy XOR、V1 fixed-AES、V2 AES + XOR 等解码档位，不同平台的 image key 提取方式也不同。

这部分能力很强，但也更需要谨慎使用：只处理自己的数据，不要把它用于未经授权的数据访问。

daemon 架构为什么重要

wx-cli 的性能点在 daemon。

README 中给出的结构大致是：

wx (CLI) ──Unix socket──▶ wx-daemon (后台进程)
                              │
                    ┌─────────┴──────────┐
               DBCache               联系人缓存
           (mtime 感知复用)

daemon 首次解密后，会把数据库和 mtime 信息持久化到 ~/.wx-cli/cache/。如果数据库文件 mtime 没变，后续调用就可以复用缓存，不需要每次重新解密。

这对命令行查询和 Agent 循环都很关键。Agent 可能会连续查询多个会话、搜索多个关键词、再做统计和导出。如果每次都重新扫描和解密，体验会很差；daemon 缓存让它更接近一个本地查询服务。

原理简述

项目 README 对原理有直接说明：微信 4.x 使用 SQLCipher 4 加密本地数据库，WCDB 会在进程内存中缓存派生后的 raw key。

wx-cli 会根据平台使用不同方式扫描微信进程内存，匹配 key 模式后提取密钥，再由 daemon 按需解密和缓存数据库。

不同平台的底层机制不同：

macOS 使用 Mach VM API。
Linux 使用 /proc/<pid>/mem。
Windows 使用 VirtualQueryEx 和 ReadProcessMemory。

这些能力解释了为什么初始化通常需要较高权限，也解释了为什么 macOS 上会涉及签名和隐私授权。

使用边界和风险

这类工具必须先讲边界。

wx-cli README 的免责声明写得很明确：工具仅用于学习和研究目的，用于解密自己的微信数据，并要求遵守相关法律法规，不得用于未经授权的数据访问。

实际使用时也建议注意：

只在自己的电脑、自己的微信账号上使用。
不要把导出的聊天记录随意上传到云端模型。
用 Agent 分析聊天记录时，先确认 API 供应商和数据出境风险。
导出 Markdown / JSON 后要注意文件权限和备份位置。
公司或多人设备上使用前，先确认合规和授权。

本地工具不等于没有隐私风险。它减少了数据离开本机的默认路径，但如果你把输出交给云端模型、网盘或第三方脚本，风险又会回来。

适合谁使用

wx-cli 适合这些场景：

想在本地快速搜索自己的微信历史消息。
需要把某个会话导出为 Markdown 或 JSON。
想统计某个群聊在一段时间内的发言情况。
想让 Claude Code、Cursor、Codex 等 Agent 帮忙整理本地微信资料。
想把公众号文章推送链接整理进本地知识库。
想研究微信本地数据库结构和解密流程。

不太适合这些场景：

想做云端微信同步。
想绕过他人设备或账号权限。
想无脑图形界面操作，不接触命令行。
不愿意处理 macOS 权限、Windows 管理员权限或 Linux sudo 的用户。

小结

wx-cli 的价值，不只是“命令行查微信聊天记录”。更准确地说，它把本地微信数据变成了一个可查询、可导出、可被 Agent 消费的本地数据源。

它的 daemon 架构解决了反复解密和查询性能问题；meta wrapper 让 AI Agent 更容易判断结果是否新鲜；SKILL.md 则把安装和使用方式交给 Claude Code、Cursor、Codex 这类工具理解。

如果你经常需要从微信里找信息、整理群聊、导出记录或构建个人资料库，wx-cli 很值得关注。但使用它时也要始终记住一条底线：只处理自己的数据，并且谨慎管理导出结果。

参考资料

jackwener/wx-cli GitHub 仓库

自动剪掉静音空白，再导出到 Premiere 和 Resolve, auto-editor功能介绍

Thu, 23 Apr 2026 13:31:27 +0800

很多视频真正耗时间的地方，不是加转场、调颜色或者修字幕，而是先把一大段素材从头看到尾，然后手动删掉那些没人说话、没有动作、没有信息量的空白段。

auto-editor 解决的就是这件事。它不是传统意义上的可视化剪辑软件，而是一个命令行工具，先分析视频或音频，再把静音段、低运动段这类“死区”自动切掉，帮你做第一遍粗剪。

如果你手上常常有下面这些素材，这类工具会特别顺手：

录屏讲解
教程视频
播客或口播
长时间直播回放
需要先粗剪再精修的访谈素材

它最核心的能力是什么

auto-editor 的核心思路可以压成一句话：

先自动完成 boring 的第一遍剪辑，再把结果交给你继续处理。

官方 README 里最强调的点，就是它会先切掉常见的“dead space”，最典型的是静音。对很长的视频来说，这一步往往最耗时，也最机械。

最基础的用法非常直接：

`1`	`auto-editor path/to/your/video.mp4`

跑完之后，你可以把它理解成已经帮你做完一轮初筛。它不是在替你做最终审美判断，而是在先把明显没信息量的段落筛掉。

它不只是按静音剪，也能按运动剪

很多人看到“自动剪辑”，第一反应会以为它只能识别静音。

但 auto-editor 的规则不只一套。官方文档里比较常见的两类自动判断方式是：

audio：按音量或响度判断
motion：按画面运动变化判断

例如：

`1`	`auto-editor example.mp4 --edit motion:threshold=0.02`

这类规则的意义在于，它不只是适合“没人说话就删掉”的素材，也适合某些主要靠画面变化推动内容的视频。

官方还支持把不同规则组合起来，比如把音频和运动条件一起用。这样做的好处是，你可以把“什么时候该保留、什么时候该切掉”变得更接近真实需求，而不是死靠单一阈值。

`--margin` 很关键，它决定剪出来像不像人剪的

自动粗剪最容易翻车的地方，不是“有没有剪掉空白”，而是剪得太狠。

一句话刚开头就被切掉，或者一句话说完立刻断开，都会让视频看起来很机械。auto-editor 在这里有一个很实用的参数：--margin。

它的作用可以理解成，在原本要切掉的边界前后，稍微留一点缓冲。官方示例里默认值是 0.2s，也就是前后各留一点点空白，让节奏更自然。

例如：

1
2

auto-editor example.mp4 --margin 0.2sec
auto-editor example.mp4 --margin 0.3s,1.5sec

这个参数很值得注意，因为它往往决定成片看起来像“自动裁断”，还是像“有人先做过一轮顺手的粗剪”。

它适合做第一遍，不一定适合替代整套 NLE 工作流

这是理解 auto-editor 时最重要的一点。

它更像一个自动化粗剪器，而不是一个完整的非线性编辑器。它的优势在于：

快速处理长素材
批量完成重复性的删空白工作
把明显无效的时间段先压掉

但真正涉及这些事情时，你大概率还是会回到传统编辑器：

精细调整节奏
手动挑重点片段
加字幕、转场和 B-roll
调色、混音和最终包装

所以更现实的定位不是“以后不用 Premiere / Resolve 了”，而是“先让 auto-editor 做机械劳动，再去编辑器里做精修”。

它可以直接导出成片，也可以导出时间线给编辑器

这也是 auto-editor 比较实用的一点。

如果你只是想快速出一个已经删掉空白段的版本，它可以直接渲染媒体文件。
但如果你后面还要继续精修，官方也支持把时间线导出到常见编辑器。

README 里列出的导出目标包括：

Adobe Premiere Pro：--export premiere
DaVinci Resolve：--export resolve
Final Cut Pro：--export final-cut-pro
Shotcut：--export shotcut
Kdenlive：--export kdenlive
独立片段序列：--export clip-sequence

例如：

`1`	`auto-editor example.mp4 --export premiere`

这类设计很实用，因为它让 auto-editor 更像是前处理工具，而不是把你锁死在自己的封闭工作流里。

它也支持手动补规则，不是只能全自动

很多自动工具一旦判断错了，就会让人很难救。

auto-editor 在这方面还算灵活，它允许你显式指定某些片段一定删掉，或者一定保留。官方示例里常见的是：

--cut-out：无论如何都切掉
--add-in：无论如何都保留

例如：

1
2

auto-editor example.mp4 --cut-out 0,30sec
auto-editor example.mp4 --add-in 0,30sec

这意味着它不是“把判断权全部交给程序”，而是你可以先用自动规则做主体，再用手动规则兜底，减少整条时间线来回返工。

安装方式里，官方现在更推荐直接下二进制

从官方安装页看，现在最推荐的安装方式不是 pip，而是直接下载 GitHub Releases 里的二进制文件。

安装说明大致是：

到 Releases 页面下载对应平台的二进制
重命名为 auto-editor 或 Windows 下的 auto-editor.exe
在终端里直接运行
用 auto-editor --help 确认是否安装成功

如果是平台包管理器，官方也提到了这些方式：

macOS 可用 brew install auto-editor
Ubuntu / Debian 系可用 apt
Arch 系可用 yay -S auto-editor

值得注意的是，官方安装页明确提到：新版本已经不再持续发布到 pip，所以 pip install auto-editor 仍然能看到，但已经不是首选安装路径。

还有一个小细节：装了 `yt-dlp` 之后可以直接吃 URL

安装页里还有一个挺实用的可选依赖说明：如果系统里已经装了 yt-dlp，auto-editor 可以直接把 URL 当输入。

这对某些先抓线上素材、再自动粗剪的人会很方便。也就是说，它不只是吃本地文件，在某些工作流里还可以直接接在线视频地址做前处理。

不过更实际的用法仍然是：先确认素材来源和版权没问题，再把它放进自己的剪辑流程。

这类工具最适合什么人

如果你平时做的是强叙事、强镜头语言、需要大量人工节奏设计的视频，auto-editor 不会替你做最难的部分。

但如果你经常碰到的是下面这些任务，它很可能能明显省时间：

一小时录屏里删掉大量停顿
播客口播先去静音再进编辑器
课程视频先做粗剪再加字幕
批量处理结构相似的长素材

它的价值不在于“剪得比人更有审美”，而在于先把最重复、最机械、最容易耗掉耐心的第一步自动化。

结语

auto-editor 值得关注的地方，不是它把剪辑变成了一个神奇的 AI 黑盒，而是它老老实实解决了一个很具体的问题：怎么更快做完第一遍粗剪。

如果你把它当成自动删静音、删空白、导出时间线的前处理工具，它的定位其实很清楚：

不负责最后的精修审美
很适合长素材的第一遍处理
和 Premiere、Resolve 这类传统编辑器不是替代关系，而是配合关系

对很多教程、录屏、口播和长视频工作流来说，这种工具往往不是“炫技型神器”，而是能真正在重复劳动上省时间的那一种。