本文永久链接 – https://tonybai.com/2026/05/09/cli-printing-press-intro

大家好，我是Tony Bai。

近日，一个名叫 cli-printing-press 的开源项目冲上了 X.com 热搜。它用 Go 写成，解决的是 AI Agent 时代最隐秘、也最致命的痛点——工具不够用，更不好用。

先说一个反常识的故事

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 工厂。给它一个 API 地址（或者任意一个网站），它输出一个专门为 AI Agent 设计的 Go CLI 工具 + MCP 服务器 + Claude Code Skill。

安装方式极其简单（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 文档

为什么选 Go？

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

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

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

第二，Go 已经被实践证明。 Peter Steinberger 用 Go 写的 gogcli（Google Workspace CLI）拥有 7000+ Star，而 Google 官方之后推出的 Rust 版本，一周冲到 1 万 Star，却在社区中败给了前者。一个用户的评价是：”我 100% 偏好 gogcli，因为它就是能让 Agent 做到它需要做的事。”广度没能打败深度，Rust 没能打败 Go。

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

核心机制：它如何做到的？

每个 API 都有非显见身份（Non-Obvious Insight）

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

Printing Press 在生成任何 CLI 之前，都要先找到这个 API 的”非显见洞察”（NOI），一句话的格式：

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

几个例子，读完你可能会有点震撼：

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

五层创造力梯子

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

第 1 层：API 端点包装命令         ← 99% 的生成工具止步于此
第 2 层：输出格式 (--json, --csv)
第 3 层：本地持久化 (sync, search, SQLite)
第 4 层：领域分析 (stale, orphans, load)    ← discrawl 的水准
第 5 层：行为洞察 (health 综合评分, similar 重复检测)  ← 目前无人到达

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

本地优先数据层

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

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

这意味着什么？看一个 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 无法回答这个问题。

Agent-Native 设计哲学

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

• 自动 JSON 输出：终端里显示人性化表格，管道传输时自动切换为 JSON，无需 –json 标志。
• –compact 模式：只返回高重力字段（id、name、status、时间戳），减少 60-80% 的 token 消耗。
• –dry-run 安全探索：让 Agent 在不执行副作用的情况下验证命令逻辑。
• 类型化退出码：

- 0 = 成功
- 2 = 用法错误
- 3 = 资源未找到
- 4 = 认证失败
- 5 = API 错误
- 7 = 速率限制

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

为什么 CLI 比 MCP 更适合 Agent？

CLI 的 token 消耗比 MCP tool definition 少 100 倍。LLM 本来就在 shell 交互上训练过。退出码 0 = 完成。–json | jq 是一流的组合模式。

这套设计哲学有一句精辟的总结：“Agent-native 设计，就是认真对待 CLI 设计 的结果。”

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

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

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

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

• –spec：直接提供 OpenAPI spec 文件
• –har：DevTools 导出的 HAR 流量包
• 直接 URL：交给浏览器嗅探

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

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

• Phase 0：解析 & 复用（1-3 分钟）
• Phase 1：研究简报 — API 身份、竞争对手、数据层、产品论点（5-10 分钟）
• Phase 1.5：生态吸收门 — 目录化每个 MCP/skill/CLI 的功能，生成吸收清单（5-10 分钟）
• Phase 1.7：浏览器嗅探门（2-5 分钟）
• Phase 2：生成 Go CLI + MCP 服务器（1-2 分钟）
• Phase 3：构建 GOAT — 吸收所有功能 + 超越命令（10-20 分钟）
• Phase 4：发货检查 — Dogfood + 验证 + 质量评分（3-8 分钟）
• Phase 5：Live Smoke Test（可选）（2-5 分钟）

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

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

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

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

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

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

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

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

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

• 路径证明：所有生成的命令 URL 都存在于 OpenAPI spec
• 标志证明：所有注册的 flag 都被至少一个命令引用
• 管道证明：每个 SQLite 表都有 WRITE 路径（sync）和 READ 路径（search/query）
• 认证证明：认证头格式和 spec 的 securitySchemes 匹配

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

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

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

• 旅行：flight-goat（Kayak + Google Flights 双数据源，一条命令搞定长途航班搜索）
• 体育：espn-pp-cli（17 个体育项目，实时比分、系列赛状态、伤病报告）
• 生产力：linear-pp-cli（50ms 复合查询）、slack-pp-cli、cal-com-pp-cli
• 电商：ebay-pp-cli（真正的狙击竞价）、craigslist-pp-cli（历史价格对比、骗局评分）
• 房产：redfin-pp-cli（内部 Stingray API 嗅探，$/sqft 净 HOA 排名）
• 美食：dominos-pp-cli（本地最优套餐叠加，这是 Dominos 官网没有的功能）

安装方式同样极简：

# 一键安装入门四件套
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，一次对话：

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

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

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

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

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

1. 分发成本最低：单一静态二进制，go install 一行，Agent 可以动态自安装。
2. 并发模型刚好够用：协程 + channel 处理并发 sync 任务，不过度设计。
3. SQLite 生态成熟：go-sqlite3、modernc/sqlite，本地优先架构的标准搭档。
4. 工程师接受度高：Agent 调用的工具，背后的人类也要维护，Go 的可读性是优势。

更深层的洞察是：AI Agent 需要的不是最强的工具，而是最可靠、更好用的工具。 打 5 分的输出稳定输出，胜过偶尔打 9 分但不可预测的输出。Go 的 CLI 恰恰提供了这种可靠性。

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

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

参考资料

• 项目地址：github.com/mvanhorn/cli-printing-press
• 官网：printingpress.dev
• CLI 库仓库：github.com/mvanhorn/printing-press-library
• X热搜：https://x.com/i/trending/2052445800421015770

今日互动探讨：

看完这款“CLI 印刷机”，你觉得在 AI 时代，传统的 RESTful API 是否已经走到了尽头？你最想为哪个原本没有 API 的网站“打印”一个专属工具
？

欢迎在评论区分享你的脑洞！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/05/07/aws-guru-slams-go-concurrency-as-a-joke-vs-jvm

大家好，我是Tony Bai。

过去十年，如果要在后端技术圈选出一个“金字招牌”，那无疑是 Go 语言的并发。

凭借其极简的 go 关键字和优雅的 channel，Go 将并发编程的门槛从“博士级”拉到了“入门级”。在云原生和微服务的浪潮中，Go 几乎就是“高并发”的代名词。

但就在前几天，AWS 的资深布道师 James Ward，在 X 平台上突然向 Go 语言的这个“优势高地”发起了猛烈炮轰：

“开发者普遍认为 Go 在并发方面很出色。但事实并非如此。JVM 的方案要优越得多。当你把虚拟线程、结构化并发和 Effects 加进来时，它甚至是全行业最好的方案之一。”

为了证明自己的观点，他还引用了前 Google 工程师 Ahmetb（以其在 K8s 社区的贡献而闻名）设计的一道极其刁钻的并发编程“考题”——实现一个工业级的、线程安全的网络连接池。

这道题，像一块试金石，炸出了 Go 并发模型背后那些被“易用性”所掩盖的无数“天坑”。

这场由大神发起的“语言战争”，瞬间引爆了技术圈。从前 Uber 工程师到 Victoria Metrics 的核心开发者，无数 Gopher 下场“护驾”。

今天，我们就来复盘这场神仙打架，看看当 Go 的“平民法拉利”遭遇现代 JVM 的“德系重装甲”时，到底谁才是真正的并发之王？

战火的点燃：一道价值千金的“并发考题”

让我们先来看看点燃这场战争的导火索，Ahmetb 设计的这道“连接池”考题：

你需要实现一个线程安全的、有界连接池。
1. Acquire()：当池中无可用连接时，必须阻塞。必须响应 context 的超时和取消。
2. Release()：归还连接。如果池已满或连接已损坏，则关闭连接而不是泄漏。
3. Close()：必须干净利落地关闭整个池。停止接受新请求，立即关闭所有空闲连接，并等待所有正在被使用的连接被归还后，再关闭它们。
4. IdleTimeout：自动清理超过空闲时长的连接。

这道题，看似简单，实则布满了“杀机”。

它几乎涵盖了并发编程中所有最令人头疼的场景：资源限制、优雅启停、生命周期管理、超时与取消、后台清理……

Ahmetb 坦言：

“如果你享受 Go 的并发原语，那就挑战一下自己去实现它。这里面的边缘情况，比我最初想象的要多得多。”

而 James Ward 正是借着这道题，打出了他的第一炮：用 Go 的原生 channel 和 select 去完美地解决所有这些问题，其代码量和心智负担，将远超现代 JVM 的解决方案。

两派的交锋：Go 的“野路子” vs JVM 的“正规军”

面对 James 的炮轰，评论区迅速分裂成两大阵营。

Go 阵营（以实战派为首）的反击：

前 Uber 工程师 Ovais Tariq 现身说法：

“Go 在高并发工作负载下更优越——这是我在 Uber 运营大规模 Go 服务的实践经验。”

另一位开发者则指出了 Go 的核心优势：

“我完全同意（Go 更优）。这个工具（Go）被创造出来，就是为了无缝处理成千上万个大部分时间都在‘等待’I/O 的任务。在这个角色上，Go 至今仍然表现卓越。”

Go 阵营的核心观点是：Go 的并发模型（Goroutine + Channel），就像一把简单、锋利的匕首。它足够轻、足够快，虽然需要使用者自己具备高超的技巧，但在真实的、海量的 I/O 密集型场景下，它的实战表现就是最好的证明。

JVM 阵营（以理论派为首）的降维打击：

James Ward 则对这些“实践经验”嗤之以鼻：

“真的吗？像 Scala ZIO 这样的 Effect 调度器和虚拟线程，在安全处理非阻塞任务时，看起来比 Goroutine 要容易得多。”

JVM 阵营的核心观点是：Go 的并发原语太“低级”了。 它把所有关于取消、超时、错误传播、资源清理的复杂性，全部甩给了开发者。而现代 JVM 生态，通过虚拟线程、结构化并发（Structured Concurrency）和函数式 Effect 系统（如 ZIO, Arrow Fx），已经从语言和框架层面，为你提供了一套“三位一体”的、体系化的解决方案。

• 虚拟线程：让 JVM 拥有了和 Goroutine 一样廉价的“百万级”并发能力。
• 结构化并发：强制所有并发任务拥有清晰的父子关系和生命周期，彻底消灭“野 Goroutine”和资源泄漏。
• Effect 系统：用类型系统来管理异步任务的副作用，让并发代码像写同步代码一样清晰和安全。

这场争论的本质，是“游击队”与“正规军”的对决。Go 提供了最灵活的单兵作战武器，而 JVM 则提供了一整套陆海空协同作战的军事体系。

Go 的“平民化”哲学 vs JVM 的“专家级”哲学

在这场混乱的口水战中，Victoria Metrics 的工程师 Phuong Le 的一篇复盘长文，将整个讨论提升到了哲学的高度。

他没有去争论谁快谁慢，而是深刻地剖析了两种技术路线背后的设计哲学差异：

“Go 在并发方面并不差。一个更真实的说法是：Go 擅长让并发变得廉价、显式和易于上手，尤其是在常见的后端模式中。”

Phuong Le 指出，Go 的核心优势在于“平民化（Approachable）”。

它用极其简单的原语，让一个普通的开发者，也能快速地写出“看起来能用”的并发代码。但这种“简单”的代价是，它把大量的“正确性”责任，下放给了开发者自己。

“Go 给了你相对低级的原语。大量关于取消、任务生命周期、清理、错误传播和背压的正确性保证，都留给了我们程序员自己去处理。”

而现代 JVM 生态，则走向了另一个极端——“专家系统”。

它试图在框架和语言层面，构建一个极其复杂、但理论上绝对安全的“象牙塔”。开发者需要学习大量的概念（Monad, Functor, Fiber…），但一旦学会，就能获得极高的安全性保障。

Phuong Le 的结论是：

“所以，公平的比较不是‘Go vs JVM，谁赢？’，而是：Go 优化的是简单的、实用的并发；而现代 JVM 生态，拥有更强大的工具来处理结构化的、资源安全的并发。 到底哪个更好，取决于你面临的并发问题有多复杂。”

你的团队，需要匕首还是航母？

这场神仙打架，最终没有赢家。但它为我们所有后端架构师，提供了一次极其宝贵的“架构选型”公开课。

1. 承认 Go 的“天花板”

我们必须承认，Go 的原生并发原语，在处理极其复杂的、需要精细化资源管理的场景时，确实存在“天花板”。Ahmetb 的那道“连接池”考题，就是一个完美的试金石。如果你团队的业务复杂到这种程度，直接引入一个成熟的第三方库（或者评估 JVM 生态），可能比自己手搓 Channel 要明智得多。

2. 警惕 JVM 的“学习曲线”

虚拟线程虽然抹平了 JVM 在并发“数量”上与 Go 的差距，但结构化并发和 Effect 系统，依然是较为陡峭的学习曲线。在一个追求快速迭代、人员流动频繁的团队里，引入这些“重型武器”的培训成本和心智负担，是必须被严肃评估的。(注：不知道有多少Java开发至今也没有使用过虚拟线程)

3. “足够好”也许就是最好的

评论区里，Jacob Voytko 的观点极具代表性：

“Go 的并发原语并非在所有方面都理想，但对于终端用户（业务开发者）大多数时候写的那些东西来说，它们是完美的。管理 fan-in/fan-out、处理带超时的异步任务……对于这些 80% 的场景，Go 的‘足够好’方案已经足够了。”

小结：没有银弹，只有权衡

这场由 James Ward 发起的“Go 并发之战”，最终以一场关于“架构权衡（Trade-offs）”的深刻反思而告终。

它像一面镜子，照出了我们这个行业最真实的底色：从来没有“最好的”语言，只有“最适合的”场景。

Go 的成功，在于它用最简单的武器，解决了云原生时代最大多数的并发问题。它的哲学，是牺牲一部分理论上的“完美”，去换取工程上的“极致效率”。

而现代 JVM 的进化，则代表了另一种可能：通过不断叠加更高级的抽象，去追求一个理论上“绝对安全”的并发乌托邦。

作为架构师，我们的终极使命，不是去争论哪条路更高贵，而是在理解了所有路径的代价之后，为我们的团队、我们的业务，选择那条最务实的、能活着走到终点的路。

资料链接：

• https://x.com/JamesWard/status/2049498133013344285
• https://x.com/func25/status/2050243999123009662
• https://x.com/ahmetb/status/2049341220707844340

今日互动探讨：

你如何看待 James Ward“Go 并发不行”的观点？在你的实战中，Goroutine+Channel 是否真的“够用”？或者你更期待 Go 能引入类似 JVM 的“结构化并发”？

欢迎在评论区分享你的看法！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。