ctx-wire - 给编码代理看的命令输出压缩器

让编码代理跑测试、lint、构建命令时，最浪费上下文的经常不是错误本身，而是铺满屏幕的重复日志。一次 npm test、go test ./... 或 monorepo 构建可能输出几千行，真正需要模型看的只有失败摘要、相关 stack trace、退出码和少量上下文。

今天推荐的 pivanov/ctx-wire 就是为这类场景准备的工具。它是一个 Go 写的本地 CLI，可以运行你的命令，用 YAML 声明的过滤器压缩 stdout/stderr，按规则脱敏敏感片段，然后把短结果交给代理，同时把完整日志保存在磁盘上。

发布时 GitHub 搜索结果显示项目约 46 stars、0 forks，主要语言是 Go，许可为 MIT。项目创建于 2026-06-05，最近仍在更新；release 页面显示最新版本为 v0.1.22，发布时间为 2026-06-13。

项目概览

属性	详情
仓库	pivanov/ctx-wire
定位	面向编码代理的命令输出压缩与脱敏 CLI
Stars	约 46
Forks	0
主要语言	Go
许可	MIT
Latest release	v0.1.22

它解决的是“日志太多”而不是“日志不存在”

很多 agent 工具都能执行 shell 命令，但执行后的输出处理通常很粗糙：要么把全部日志塞进上下文，要么只截断前几百行。前者浪费 token，后者容易把真正的失败信息截掉。

ctx-wire 的思路更接近“给代理一份短报告”。你用它包装原本要执行的命令：

ctx-wire run -- npm test

命令仍然正常运行，退出码仍然保留；不同的是，工具会把原始输出写入本地 run 目录，再根据配置抽取适合交给模型看的部分。代理看到的是压缩后的摘要，开发者需要追细节时还能打开完整日志。

这比简单截断更稳。构建日志的噪音常常在开头，失败原因可能在中间或末尾；如果只保留前后固定行数，很容易漏掉关键线索。ctx-wire 通过 filter pipeline 明确告诉工具“哪些行有价值、哪些行应该丢弃、哪些内容要替换”。

Filter pipeline 是核心

README 和 FILTERS.md 里列出的过滤器覆盖了几类常见需求：按正则匹配保留或排除内容，截取 head/tail，抽取错误窗口，压缩重复行，处理 JSON，限制 token 或字符预算，以及对敏感信息做 redaction。

这套模型的重点在于声明式。与其让每个项目都写一段临时脚本清洗日志，不如把“测试失败时保留什么”写进配置文件。团队可以为不同命令准备不同 profile，例如：

1. 单元测试保留 failed test name、assertion、stack trace 和 summary。
2. TypeScript 编译保留 diagnostic、文件路径和错误代码。
3. Docker build 保留失败 step 附近的窗口。
4. 长时间运行的脚本保留末尾摘要和 warning/error。

这类配置一旦稳定下来，就可以被人和代理重复使用。对 AI 编码工作流来说，这比每次提示模型“请忽略无关日志”更可靠。

脱敏放在默认工作流里

编码代理拿到命令输出时，日志里可能混入 token、URL、环境变量、cookie、数据库连接串或云服务 key。即使模型本身不主动外传，最小暴露原则也要求先过滤再交给代理。

ctx-wire 把 redaction 放进过滤链，文档里也把 secret scrubbing 作为核心能力之一。它适合处理“日志要给模型看，但不能原样给”的场景。比如 CI 失败日志里有带签名的下载地址，本地 .env 被测试框架误打印，或某个 SDK 在 debug 模式下吐出了认证头。

当然，这不意味着可以放心把任何敏感输出都交给工具。更稳妥的做法仍然是：上游命令不要打印 secret，ctx-wire 作为第二道防线，配置里再显式写出团队关心的模式。

完整日志留在本地，短结果给代理

ctx-wire 有一个很实用的边界：它不是日志系统，也不试图替代测试报告平台。它只负责本地一次命令运行的输入输出整理。

完整日志仍然落盘，这点对排错很重要。代理拿到压缩摘要后可能会提出修复方向，但如果方向不对，人仍然要回到原始 stdout/stderr。保留原始日志可以避免“摘要写得太短，后来无法复盘”的问题。

这种分层也适合多人协作。你可以把压缩输出贴给代理，让它先定位问题；如果需要人工 review，再把本地 run 目录里的完整日志拿出来对照，而不是重新跑一次耗时命令。

配置文件让它进入项目习惯

CONFIG.md 显示 ctx-wire 使用 YAML 配置。它支持把命令、过滤器、预算、输出目录等行为写成可复用 profile。对日常开发来说，这比记一长串 CLI 参数更有价值。

一个项目可以把常用命令约定成几个入口：

ctx-wire run test
ctx-wire run lint
ctx-wire run build

每个入口背后对应不同的过滤器。测试命令关心失败上下文，lint 命令关心文件和规则名，构建命令关心退出阶段和错误窗口。代理只需要调用同一个稳定接口，不必理解每个工具的输出格式。

这也能减少 prompt 里的操作说明。与其在 AGENTS.md 里写“运行测试后只复制失败部分”，不如让命令本身生成适合模型阅读的结果。人类规范容易被忘，工具边界更容易保持一致。

适合本地 agent 工作台

我觉得 ctx-wire 最适合放在本地 AI 编码工作台里，而不是作为大型平台组件。它的优势是轻：一个 CLI 包住任意命令，对 stdout/stderr 做处理，再把结果交回调用方。

适合先试的场景包括：

1. 代理经常被长测试日志挤爆上下文。
2. monorepo 构建失败时，真正错误埋在大量 warning 之后。
3. 团队希望把命令输出先脱敏再交给 AI 工具。
4. 需要保留完整日志，但给模型只看短摘要。
5. 已经在 AGENTS.md、Makefile 或 task runner 里维护固定命令入口。

不太适合的场景也很明确。如果项目命令输出本来就很短，或者你已经有成熟的 CI artifact 和测试报告解析，ctx-wire 带来的收益不会太大。它更像是“本地代理执行命令时的输出闸门”。

和普通日志截断的区别

普通截断解决的是长度，ctx-wire 试图解决的是信息密度。它把一段命令输出拆成三层：

1. 原始日志：完整保留，供人类或后续工具复盘。
2. 过滤结果：按项目配置提取高价值片段。
3. 代理上下文：控制预算后交给模型的短文本。

这三层分开以后，工程上会清楚很多。你不需要在“全部贴给模型”和“只贴最后 100 行”之间二选一，也不需要每次手动清理敏感信息。配置好的 pipeline 可以稳定地产出同一种形状的报告。

对多代理工作流来说，这点尤其重要。不同代理都能拿到同样格式的失败摘要，handoff 时不会因为某一次复制日志的范围不同而丢上下文。

小结

pivanov/ctx-wire 不是一个炫技型代理框架，而是一个很窄、很工程化的命令行工具：运行命令，保存完整日志，压缩输出，脱敏敏感内容，把短结果交给编码代理。

如果你正在把 Codex、Claude Code、OpenCode 或其他 CLI agent 接到真实项目里，迟早会遇到“命令输出太长、太乱、还有敏感信息”的问题。ctx-wire 的价值就在这里：它让命令输出先经过一层可审计、可配置的整理，再进入模型上下文。

这个方向很适合小团队先试。它不要求替换现有测试或构建工具，只是在命令和代理之间加一条清晰的 wire：完整事实留在本地，高密度摘要交给模型。