CLI Printing Press：火爆外网的 Go 开源神器！一键生成 Agent 专属 CLI 工具，45 个开箱即用

标签: Go / AI Agent / CLI / MCP / 开源 / Claude Code / SQLite / 本地优先
原文: https://mp.weixin.qq.com/s/WJCS6kq-CP6GYVp3kQgt7Q
作者: Tony Bai（程序员茄子首发）

引言

Discord 有 300 多个官方 API 端点。

按常理，一个覆盖所有端点的 CLI 工具，应该是最好用的那个。但事实恰恰相反。

OpenClaw 之父 Peter Steinberger 用 Go 写了一个叫 discrawl 的工具，只提供 11 个命令：sync、search、sql、tail、mentions、members……就这些。结果？700 多颗 GitHub Star，社区口口相传，被无数 AI Agent 开发者列为必装工具。

为什么一个「阉割版」打败了「全功能版」？

因为 Steinberger 看到了 Discord API 设计者自己都没意识到的东西：聊天记录不只是聊天，它是一个组织的知识库。

每一条消息线程，本质上都是一份可以被归档、被索引、被本地全文搜索的文档。那 11 个命令，围绕的就是这个洞察。300 个端点包装器，做不到这一点。

CLI Printing Press，就是一台把这种洞察自动化的「机器」。

一、AI Agent 的「工具饥渴」时代

在聊这个工具之前，我们需要先理解 2026 年的 AI 开发现状。

Claude Code、Codex、OpenClaw、Gemini CLI 等 AI Agent 的能力已经突飞猛进。它们可以写代码、查数据、做分析、自主决策。但有一个瓶颈正在成为所有人的噩梦：现有的 CLI 工具，根本不是为 Agent 设计的。

想象一下 Agent 在调用一个普通 CLI 时会遇到什么：

• 输出格式不稳定：有时是表格，有时是纯文本，Agent 根本无法可靠地解析
• 没有类型化退出码：出了错要去解析 stderr 的文字才能知道是认证失败还是网络超时
• 每次查询都要远程 API 调用：一个复合问题需要十几次 round-trip，token 哗哗地烧
• 遇到没有公开 API 文档的网站（比如 ESPN、Google Flights），完全束手无策

CLI Printing Press 项目 README 开篇就把这个痛点说得很直白：

「在 AI Agent 的世界里，没有什么比时间和金钱更宝贵——落到工程层面，就是速度和 token 消耗。一个设计优良的 CLI 是 Agent 的肌肉记忆：不用翻文档，不走弯路，不浪费 token。」

CLI Printing Press，就是为了解决这个问题而生的。

二、CLI Printing Press 是什么

用一句话描述：

CLI Printing Press 是一台 CLI 工厂。给它一个 API 地址（或者任意一个网站），它输出一个专门为 AI Agent 设计的 Go CLI 工具 + MCP 服务器 + Claude Code Skill。

2.1 安装方式

安装方式极其简单（Go 需要 >= 1.26 版本）：

# 安装工厂本体
go install github.com/mvanhorn/cli-printing-press/v4/cmd/printing-press@latest

# 克隆技能文件（配合 Claude Code 使用）
git clone https://github.com/mvanhorn/cli-printing-press.git

# 在 Claude Code 中启动，直接加载 skill
claude --plugin-dir .

然后在 Claude Code 中，一条命令就能启动生产流程：

/printing-press Notion           # 给 Notion API 生成 CLI
/printing-press https://espn.com/nba  # 直接指向网站，无需 API 文档

2.2 两种输出物

每次运行 Printing Press，产出的不是一个，而是两个可用工具：

一个 spec 进去
  → <api>-pp-cli    Cobra CLI，供 Claude Code / Codex / shell 调用
  → <api>-pp-mcp    MCP 服务器，供 Claude Desktop / Cursor / Windsurf 使用

两者共享同一个 internal/client、同一个 internal/store、同一套认证逻辑。零代码重复，一套实现，双场景覆盖。

三、为什么选择 Go

这是一个值得细聊的设计决策。

在这个 TypeScript、Python 等生产力语言大行其道的时代，CLI Printing Press 选择了 Go，并且坚定地把 Go 作为所有生成产物的语言。原因很现实：

3.1 分发极其简单

go install 一行命令，跨平台，无依赖。Agent 在运行时动态安装工具，最怕的就是依赖地狱。Go 的静态编译二进制文件是最优解。

3.2 Go 已经被实践证明

Peter Steinberger 用 Go 写的 gogcli（Google Workspace CLI）拥有 7000+ Star，而 Google 官方之后推出的 Rust 版本，一周冲到 1 万 Star，却在社区中败给了前者。

一个用户的评价是：

「我 100% 偏好 gogcli，因为它就是能让 Agent 做到它需要做的事。」

广度没能打败深度，Rust 没能打败 Go。

3.3 Go 的并发模型非常适合 Agent 使用场景

SQLite 批量事务、并发 sync worker、FTS5 全文索引……这些都是 Agent 高频调用场景下的性能关键路径，Go 处理起来得心应手。

四、核心机制：它如何做到的

4.1 每个 API 都有「非显见身份」（NOI）

这是整个项目最有哲学深度的设计。

Printing Press 在生成任何 CLI 之前，都要先找到这个 API 的**「非显见洞察」（Non-Obvious Insight, NOI）**，一句话的格式：

「[API] 不只是 [显而易见的功能]。它是 [非显见的东西]。每个 [数据点] 都是关于 [隐藏真相] 的信号。」

这个 NOI 是整个 CLI 的创意 DNA。如果 AI 在研究阶段写不出一个 NOI，说明研究深度不够，Phase 0 不会放行。

4.2 五层创造力梯子

大多数工具停在第 1 层。Printing Press 直接爬到第 5 层。

第 3 层以上，才是真正的价值所在。一旦数据落在本地 SQLite，compound 查询就成为可能——这是任何无状态 API 包装器永远做不到的事情。

看一个 Linear 的真实 Demo：

$ /pp-linear sql 'blocked issues whose blocker hasn't moved in 7 days'

背后执行的是：

SELECT i.identifier, i.title, age(now(), b.updated_at) AS stuck
FROM issues i 
JOIN issue_relations r ON r.issue_id = i.id
JOIN issues b ON b.id = r.related_issue_id
WHERE r.type = 'blocked_by' 
  AND b.state = 'in_progress'
  AND b.updated_at < now() - interval '7 days';

结果：

ENG-412  Crash on cold-start       blocked 11d
ENG-388  Reconnect dropped sockets  blocked 9d
ENG-301  Backfill missing rows      blocked 8d

50 毫秒。本地完成。 关键是 Linear 的官方 API 无法回答这个问题。

4.3 本地优先数据层

Printing Press 生成的每个高质量 CLI，都带有一套完整的本地数据层：

• 领域特定的 SQLite 表（不是 JSON blob，是真正的关系型结构）
• FTS5 全文搜索索引
• 带游标追踪的增量同步
• 直接 SQL 查询接口

4.4 Agent-Native 设计哲学

这是 Printing Press 和普通 CLI 生成工具最根本的区别。每一个生成出来的 CLI，都内置了以下设计：

自动 JSON 输出：终端里显示人性化表格，管道传输时自动切换为 JSON，无需 --json 标志。

--compact 模式：只返回高重力字段（id、name、status、时间戳），减少 60-80% 的 token 消耗。

--dry-run 安全探索：让 Agent 在不执行副作用的情况下验证命令逻辑。

类型化退出码：

Agent 读一个退出码就知道下一步怎么做，不需要解析错误文字，自我纠正只需一次重试。

五、无 API 文档？浏览器嗅探搞定

ESPN 没有官方 API。Google Flights 没有公开文档。Dominos 也没有。

Printing Press 的解法：启动一个浏览器，你正常点击浏览，它在后台抓取所有 HTTP 流量，逆向工程出 API 结构，自动生成 OpenAPI spec，然后继续走后面的生成流程。

三种输入模式，覆盖所有场景：

六、工厂流水线：一次生成，双接口输出

每次运行 Printing Press，整个流程分阶段进行：

七、质量不靠玄学，靠四项机械验证

生成出来的 CLI 质量如何保证？Printing Press 用了一套两层 100 分制评分系统，加四项机械化验证。

第一层（基础设施，50分）：检查骨架是否正确——输出模式、认证流程、错误处理、Agent-Native 标志、终端 UX、README、Doctor 命令、本地缓存。

第二层（领域正确性，50分）：检查代码是否真的能跑——生成的 URL 路径是否存在于 OpenAPI spec、认证格式是否和 spec 一致、SQLite 数据管道是否正确连通、是否有死代码和悬挂函数。

Grade A = 85 分以上。 两层都过，才算合格。

四项行为证明（Proof of Behavior）：

任何一项证明失败，会触发自动修复流程，重新验证。

八、已打印的 CLI 库：45 个开箱即用

不想自己生成？官方已经打印好了 45 个 CLI，覆盖主流场景：

安装方式同样极简：

# 一键安装入门四件套
npx -y @mvanhorn/printing-press install starter-pack

# 安装指定工具
npx -y @mvanhorn/printing-press install espn sentry linear

九、两个 CLI 协同工作的真实场景

Printing Press 最打动人的地方，是多个 CLI 可以在同一个 Claude 对话中协同工作。

场景：我想去看 OKC 的季后赛，怎么买最便宜的机票？

/pp-espn nba okc round 2 game 1 + /pp-flightgoat sea-okc, fly-in same day

两个 CLI，一次对话：

1. espn-pp-cli 拉取实时数据：OKC 刚以 131-122 赢了凤凰城，第二轮第一场预计在 5 月 9 日或 10 日
2. flightgoat-pp-cli 立刻查询：西雅图飞俄克拉荷马城，当天往返
3. 结果：西南航空 $437 往返，推荐 Wanna Get Away+ 可退款票，Frontier 的那班到得太晚，跳过

这不是 Demo，这是真实运行的输出。两个工具各司其职，一个 Agent 对话完成端到端决策。

十、为什么 CLI 比 MCP 更适合 Agent

作者给出了一个非常有力的论断：

CLI 的 token 消耗比 MCP tool definition 少 100 倍。

原因：

• LLM 本来就在 shell 交互上训练过
• 退出码 0 = 完成，不需要额外的完成信号
• --json | jq 是一流的管道组合模式

这套设计哲学有一句精辟的总结：

「Agent-native 设计，就是认真对待 CLI 设计的自然结果。」

十一、写在最后：Go 为什么在 AI 时代逆袭

CLI Printing Press 的出现和走红，其实折射出一个更大的趋势。

Rust 以性能和安全著称，Python 以生态和易用性著称，但在 AI Agent 工具这个细分赛道，Go 正在悄悄胜出。原因很简单：

更深层的洞察是：AI Agent 需要的不是最强的工具，而是最可靠、更可用的工具。

打 5 分的输出稳定输出，胜过偶尔打 9 分但不可预测的输出。Go 的 CLI 恰恰提供了这种可靠性。

而 CLI Printing Press，把这套哲学变成了一条流水线。

资源汇总

如果你也在构建 AI Agent，或者正在为 Agent 寻找合适的工具层，这个项目值得花半小时认真研究一下。它解决的问题，可能比你意识到的还要根本。

本文首发于「程序员茄子」博客，原文链接：https://chenxutan.com