Logo

site iconTonyBai | 白明

重复
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

TonyBai | 白明 RSS 预览

Go 性能诊断工具大变天?Race 检测有望进生产,Trace 秒开不是梦!

2026-01-31 08:02:45

本文永久链接 – https://tonybai.com/2026/01/31/go-official-updates-race-detector-trace-ui-pprof

大家好,我是Tony Bai。

近期,Go Runtime 团队公开了一系列关于性能与诊断工具链的内部会议记录(2025年末至2026年初)。从中,我们可以看到从轻量级竞态检测的探索,到 Trace 工具的交互式革命,再到 pprof 接口的现代化重构,Go 团队正在酝酿一系列深远的变革。

今天,我们就来深度解码这些前沿动向,看看 Go 1.27 及未来版本可能带给我们什么惊喜。

竞态检测 (Race Detection):寻找“轻量级”圣杯

Go 的 Race Detector (-race) 虽然强大,但其昂贵的运行时开销(通常 10x 内存和 CPU)使其难以在生产环境中常驻。Go 团队正在探索打破这一僵局的两种新路径:

  1. 纯软件方案的突围:社区贡献者 (thepudds) 提出了一种新的软件检测思路,试图将开销降低到足以在某些生产场景下运行的程度。虽然目前还处于“推测”阶段,但这种无需重新编译、动态挂载的可能性极其诱人。
  2. 硬件辅助的回归:利用现代 CPU 的硬件特性(如 Intel PT 或 AMD LBR)来实现低开销的竞态检测。虽然这需要特定硬件支持,但其“内置于每个二进制文件”的潜力不容忽视。

未来的 Go 可能会提供分级的竞态检测能力——在 CI 中使用全量 -race,在生产中使用采样的轻量级检测。

Execution Trace:交互体验与可编程性的大升级

Go 的执行追踪 (Execution Trace) 是诊断复杂并发问题的神器,但其庞大的数据量和难以解析的格式一直是痛点。会议记录透露了几个令人振奋的改进:

新一代 Trace UI:即时响应

Michael Knyszek 展示了一个全新的 cmd/trace UI 实验。通过引入索引 API (Index API),新工具可以:

  • 瞬间打开:不再需要预先解析整个 GB 级别的 Trace 文件。
  • 按需切片:用户可以选择一个时间窗口(例如 1秒),工具只解析并加载该窗口内的数据。
  • 无损切片:除了跨越边界的任务和区域状态会有语义上的微调,数据几乎是无损的。

这意味着,Gopher 们终于可以告别打开 Trace 文件时漫长的等待进度条了。

Trace 的读写 API 化

社区正在推进 x/exp/trace 包的演进,不仅支持解析(Read),更要支持生成(Write)

  • 测试场景:可以手动构造 Trace 事件来测试分析工具。
  • 脱敏与过滤:可以编写工具读取 Trace,过滤掉敏感数据,然后写回一个新的 Trace 文件。

这将为构建第三方的 Trace 分析和可视化生态打开大门。

pprof 的现代化:告别全局变量

当前的 runtime/pprof 严重依赖全局变量(如 MemProfileRate),这在多租户或库代码中是一个巨大的痛点。

Nick 提出的 pprof.Recorder 提案旨在解决这个问题。它允许创建独立的 Recorder 实例来控制采样。会议中甚至讨论了一个激进的想法:
* 废弃全局配置:在未来的 Go 版本(如 1.27)中,通过编译器检查或 go vet,禁止直接修改 runtime.MemProfileRate,强制迁移到新的 API。
* 多采样率支持:虽然 pprof 格式本身不支持变采样率,但团队正在讨论如何优雅地处理多个 Recorder 设置不同采样率的冲突(通常是“最细粒度者胜出”)。

性能优化的深水区:NUMA 与分片计数器

除了工具链,Runtime 本身的性能优化也在向深水区迈进:

  • NUMA 优化:Michael Pratt 和 Michael Knyszek 正在致力于消除 GC 中的最后一批主要缓存未命中 (Cache Misses),这通常是跨 NUMA 节点内存访问造成的。这将显著提升 Go 在超大核心数服务器上的表现。
  • Sharded Counter (分片计数器):Carlos 正在开发一种高性能的分片计数器。在高并发场景下,单一的原子计数器会成为缓存一致性流量的热点。通过分片(类似 xsync 的实现),可以大幅降低 CPU 核心间的竞争。这也暗示了 Go 标准库或 Runtime 内部可能会引入更高效的并发原语。

小结:Go 1.27 的期待

虽然 Go 1.26 尚未正式发布(RC2 刚出),但 Go 团队的目光已经投向了更远的 1.27以及后续版本。

从会议记录中,我们看到一个清晰的趋势:Go 正在从“能用”向“好用”和“极致性能”进化。无论是让诊断工具更人性化,还是对 Runtime 底层进行微秒级的压榨,都显示出这门语言旺盛的生命力。

让我们拭目以待,看看这些实验性的想法,有多少能最终落地为我们手中的工具。


你的期待清单

官方画的这些“饼”,每一个都让人心动。在你看来,哪个功能的落地最能解决你当前的痛点?是生产环境的 Race 检测,还是丝滑的 Trace 分析?

欢迎在评论区投出你的一票!让我们一起期待 Go 工具链的进化。

如果这篇文章让你对 Go 的未来充满了信心,别忘了点个【赞】和【在看】,并转发给你的 Gopher 朋友,告诉他们好消息!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


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

© 2026, bigwhite. 版权所有.

Rust 输了?在 AI Agent 的战场上,TypeScript 才是唯一的“神”

2026-01-31 08:00:03

本文永久链接 – https://tonybai.com/2026/01/31/rust-vs-typescript-ai-agent-battleground-winner

大家好,我是Tony Bai。

如果把 2025 年定义为 Coding Agent(编程智能体) 的元年,那么刚刚开启的 2026 年,毫无疑问是 Personal AI Agent(个人助理智能体) 的元年。

openclaw(曾用名Clawdbot/Moltbot)为代表的开源项目,一夜之间席卷了 GitHub,让无数开发者为之疯狂。但在这一片繁荣的景象背后,作为一名敏锐的技术观察者,我发现了一个极其有趣的现象。

请环顾四周,看看那些最顶尖、最流行、体验最好的 AI Agent 项目:

  • Claude Code (Anthropic 官方):TypeScript。
  • Gemini CLI (Google 官方):TypeScript。
  • openclaw(100k+ Star):TypeScript。
  • opencode以及配套的oh-my-opencode:TypeScript。

再看看Go语言,虽然没有占据头把交椅,但也稳稳地守住了一席之地。Gastowncrush 这些专注于并发和后端服务的 Agent 或Agent编排框架,依然拥有自己的一批拥趸。

但是,那个在过去几年呼声最高、号称“内存安全、性能无敌、将重写一切”的 Rust 去哪了?

在 AI Agent 的应用层战场上,尤其是像上述这些火出圈的AI Agent项目中,Rust 几乎“失声”了。除了 OpenAI 的 Codex 这个孤勇者之外,我们很难在主流的开源 Agent 列表中看到 Rust 的身影。

难道在 AI 时代的Agentic AI(智能体AI应用)阶段,Rust 输了吗?为什么被视作“玩具语言”的 TypeScript,反而成了 AI Agent的“母语”?

今天,我们不谈信仰,只谈架构。让我们深入剖析这场语言战争背后的第一性原理。

数据说话:统治 Agent 界的“TS 军团”

在下结论之前,我们先来看一组数据。

我统计了目前 GitHub Trending 上排名前 20 的 AI Agent 相关项目(排除单纯的模型推理框架,仅统计应用层 Agent),结果令人震惊:

  • TypeScript / JavaScript:占比约 75%。
    这是绝对的统治地位。无论是官方的 SDK,还是社区的野生项目,TS 都是默认选项。openclaw的作者 Peter Steinberger 本人就是 iOS 和 C++ 出身,但他依然选择了 TS 来构建他的个人AI助理。
  • Python:占比约 15%。
    依靠着 LangChain 和 AutoGen 的早期积累,Python 依然有存量优势,但在构建交互式 CLI全栈应用 时,Python 的体验明显不如 TS 丝滑。
  • Go:占比约 8%。
    Go 凭借其单文件分发(Single Binary)和强大的并发模型,在Agent编排框架、Coding Agent,尤其是 DevOps 类的 Agent(如 K8s 运维助手)中表现亮眼。
  • Rust:占比 < 2%。
    除了 OpenAI 这种拥有无限工程资源的巨头敢用 Rust 重写 Codex,绝大多数独立开发者和创业公司似乎都对其敬而远之。

这个数据说明了什么?

说明在 Agent 这个特定的垂直领域,开发效率(Velocity) 已经彻底压倒了 运行效率(Performance)

对于一个每秒钟只能输出 50 个 Token 的 LLM 来说,你的程序是 1ms 响应还是 10ms 响应,用户根本感觉不到区别。但你能否在 1 天内上线一个新功能,用户感知极强。

第一性原理:为什么是 TypeScript?

TypeScript 之所以能赢,绝不是因为运气,而是因为它在基因层面契合了 AI Agent 的特性。

AI 的“母语”是 JSON,而 TS 是 JSON 的亲兄弟

这是最核心的原因之一。

大模型(LLM)与外部世界交互的通用协议是什么?是 JSON

无论是 Tool Calling(函数调用),还是 Structured Output(结构化输出),LLM 吐出来的都是 JSON。

  • TypeScript: 处理 JSON 是原生的。JSON.parse() 之后,直接当作对象操作。配合 TypeScript 的 Interface 定义,你可以获得极佳的类型提示,但又保留了运行时的灵活性。

    // TS: 轻松处理
    interface ToolCall { name: string; args: any }
    const call = JSON.parse(llmOutput) as ToolCall;
    
  • Rust/Go: 你需要定义严格的 Struct。如果 LLM 发疯,多返回了一个字段,或者把 int 写成了 string,你的 serde_json 或 json.Unmarshal 就会直接报错 panic。在 AI 开发中,你需要的是“宽容”,而 Rust/Go 给你的却是“严厉”。

“Vibe Coding” 需要松弛感

openclaw 作者提到的 Vibe Coding,本质上是一种“心流状态”。我想到了一个功能,告诉 AI,AI 生成代码,我运行,成功。整个过程行云流水。

  • TS 的体验: AI 生成了一段 TS 代码,可能类型有点小问题,用了 any,但能跑。我先跑起来看看效果,以后再修类型。It works > It is correct.
  • Rust 的体验: AI 生成了一段 Rust 代码。10分钟后编译器报错:“生命周期不匹配”、“借用检查失败”、“unwrap 可能会 panic”。你被迫停下来,花 30 分钟和编译器搏斗。你的 Vibe(氛围)瞬间没了。

在探索性开发(Exploratory Development)阶段,Rust 的严格性变成了阻碍。

生态位的降维打击:全栈与浏览器

Agent 不仅仅是在终端跑。它需要操作浏览器(比如使用Playwright),需要写 Chrome 插件,需要构建 Web UI。

在这些领域,TS 是唯一的王

如果你的 Agent 需要抓取网页数据,TS 有最成熟的库;如果你的 Agent 需要提供一个可视化的 Dashboard,TS 前后端通吃。

Rust 的尴尬与反击:退守“基础设施”

那么,Rust 真的输了吗?

从应用层来看,是的。但从基础设施层来看,Rust 依然是基石。

我们必须看清一个分层结构:

  • L0 (Infrastructure): 向量数据库 (LanceDB, Qdrant)、推理引擎 (像Candle)、高性能网关。这是 Rust 的领地。
  • L1 (Application): Agent 业务逻辑、流程编排、工具调用。这是 TypeScript 的领地。

Rust 并没有输,它只是退到了幕后。 Rust 成了 AI 的“地基”之一,而 TS 成了 AI 的“胶水”。

Agent 本质上就是把 LLM、数据库(记忆)、API 粘合在一起的胶水层。在这个层面上,灵活的胶水(TS)永远比坚硬的水泥(Rust)好用。

Go 的中间路线:CLI 界的“钉子户”

在这场战争中,Go 语言处于一个非常有趣的位置。它不像 TS 那么动态,也不像 Rust 那么死板。

Go 在 Agent 领域依然有一席之地,主要得益于两点:

  1. Single Binary (单文件分发):
    如果你写一个 CLI Agent 分发给用户,Go 编译出来就是一个二进制文件,扔过去就能跑。TS 还需要用户装 Node.js,装依赖(npm install 地狱)。对于 openclaw 这种本地工具,其实 Go 也是一个极佳的选择(虽然作者选了 TS)。
  2. 并发模型 (Goroutine):
    当我们需要构建 Agent Swarm (蜂群),比如同时启动 100 个 Agent 去爬取数据、分析情报时,Go 的 Goroutine 模型比 TS 的 Promise.all 更轻量、更可控,性能也更佳。

像 Beads 和 Gastown 这样的项目选择 Go,正是看中了它在工程化和并发上的平衡。

小结:语言没有优劣,只有“生态位”

Openclaw 的爆火和 Claude Code 的选择,向我们揭示了 AI 时代的一个新真理:

在 Agent 应用层,灵活性(Flexibility)和容错性(Forgiveness)是第一生产力。

  • 如果你想快速构建一个能够“听懂人话、调用工具”的 Agent,请毫不犹豫地选择 TypeScript
  • 如果你想构建一个高性能的 llm 路由网关、MCP Server 或 并发Agent编排工具,又或是Cli Agent,Go 是你不错的好帮手。
  • 如果你想造一个新的 向量数据库推理引擎,请拥抱 Rust

不要带着旧时代的“语言鄙视链”进入新时代。

在 AI 眼里,代码只是它实现目标的工具。它写 TS 最顺手,那 TS 就是最好的语言。

Rust 没有输,它只是太“硬”了,不适合在这个充满幻觉和不确定性的 Agent 世界里跳舞。


你的“Agent 母语”

TypeScript 的统治力看似不可动摇,但技术圈永远不缺变数。在你心目中,开发 AI Agent 的最佳语言是哪一门?你愿意为了开发效率而忍受 TypeScript 的类型体操,还是为了极致性能去啃 Rust 的硬骨头?

欢迎在评论区捍卫你的“本命语言”!让我们看看谁才是真正的 Agent 之王。

如果这篇文章颠覆了你的技术选型观,别忘了点个【赞】和【在看】,并转发给还在纠结学什么的兄弟!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


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

© 2026, bigwhite. 版权所有.

“退休”大佬的 AI 复出战:为了“好玩”,他写出了火遍全网的 Moltbot

2026-01-30 08:23:38

本文永久链接 – https://tonybai.com/2026/mm/dd/clawdbot-author-peter-steinberger-full-interview

大家好,我是Tony Bai。

在硅谷,每天都有无数个 AI 项目诞生,它们大多有着精美的 Landing Page,有着宏大的融资计划,PPT 里写满了“颠覆行业”。

但最近,一个名为 Clawdbot(现已因商标原因更名为 Moltbot)的项目,却以一种完全不同的姿态闯入了大众视野。没有融资,没有团队,甚至没有商业计划书。它仅仅是一个“退休(财务自由)”的软件大佬,为了给自己“找乐子”而写的一堆代码。

然而,就是这样一个项目,在 GitHub 上一夜之间狂揽 3.2w+ Star,甚至让很多非技术圈的人都跑去 Apple Store 抢购 Mac Mini 来运行它。

它的作者是 Peter Steinberger,著名的 PDF SDK 提供商 PSPDFKit 的创始人。在卖掉公司退休四年后,他因为 AI 找回了当年的热血。

在最近的一次深度访谈中,Peter 毫无保留地分享了他开发 Moltbot 的全过程。这不仅是一个关于工具的故事,更是一份关于“在 AI 时代,个人开发者如何打破大厂垄断,重塑人机交互”的珍贵启示录。

从 Burnout 到 Addiction:找回失去的 Mojo

故事的开始并不美好。

四年前,Peter 卖掉了自己经营了 13 年的公司。长期的创业压力让他彻底 Burnout(职业倦怠)

“那感觉就像有人把我的 Mojo(魔力/精力)吸干了一样。” 他回忆道。在那之后的三年里,他对编程完全提不起兴趣,哪怕只是坐在电脑前都觉得是一种折磨。

直到 2025 年 4 月,一切改变了。

Peter 开始接触早期的 AI 工具,特别是 Claude Code 的 Beta 版。那一刻,他感到了久违的兴奋。

“如果你错过了前几年 AI 比较‘智障’的阶段,直接上手现在的工具,你会觉得——这简直太棒了(Pretty Awesome)!

这种兴奋迅速转化为了一种“成瘾(Addiction)”。

但这是一种积极的成瘾。他开始熬夜写代码,甚至会在凌晨 4 点给朋友发消息讨论 AI 的新发现。为了给自己找点乐子,他甚至搞了一些极其荒谬的实验:

比如,他做了一个“全球最贵的闹钟”

他让运行在伦敦服务器上的 AI Agent,通过 SSH 远程登录到他家里的 MacBook,然后自动调大音量来叫醒他。

“这听起来很疯狂,甚至有点杀鸡用牛刀,但这就是我的初衷——Have Fun(玩得开心)。”

Peter 认为,学习新技术的最好方式,就是把它当成玩具。当你不再为了 KPI 或融资而写代码,而是为了让 AI 帮你订一份外卖、回一条消息而折腾时,创造力才会真正涌现。

技术哲学:CLI 是 Agent 的母语

Moltbot 之所以能打败众多商业化的 AI 助理,核心在于 Peter 对软件架构有着极其深刻的第一性原理认知:

“Don’t build for humans, build for models.”(别为人构建,为模型构建。)

如果你仔细观察现在的软件世界,你会发现所有的 GUI(图形界面)、按钮、下拉菜单,本质上都是为了适应人类极其有限的带宽(Bandwidth)和注意力而设计的。我们需要视觉引导,因为我们记不住命令。

但 AI 不需要这些。

AI 读得懂 Unix 手册,AI 记得住所有参数。

因此,Moltbot 采用了极其激进的 CLI-First(命令行优先) 策略。

Peter 解释道:“你知道什么东西最能 Scale(扩展)吗?是 CLI。你可以写 1000 个小工具,只要它们都有 –help 文档,Agent 就能瞬间学会如何使用它们。”

在 Moltbot 的架构里,所有的能力都被封装成了原子化的 CLI 工具:

  • 想控制 Sonos 音箱?写个 CLI。
  • 想看家里的摄像头?写个 CLI。
  • 想查 Google 地图?写个 CLI。

Agent 就像一个万能的系统管理员,它通过组合这些 CLI,获得了在数字世界和物理世界中“行动”的能力。这比那些试图用鼠标点击模拟人类操作的 RPA(自动化流程)要高效、稳定一万倍。

打破围墙:数据的解放运动

Moltbot 最让极客们热血沸腾的,是它对 Big Tech Walled Gardens(大厂围墙花园) 的宣战。

现在的互联网巨头,都希望把你锁在他们的 App 里。WhatsApp 不开放 API,Spotify 不让你导出数据,外卖软件不让你自动化下单。

但在 Peter 看来,AI 是打破这些围墙的终极武器。

以 WhatsApp 为例。官方没有给个人开发者提供 API,如果你用商业 API 发太多消息,还会被封号。

Peter 的做法是:Hack Everything。

他直接通过 Hack 桌面端协议,让 Moltbot 能够接管他的 WhatsApp。当他在旅途中收到朋友的语音消息(比如推荐餐厅)时,Moltbot 会自动:

  1. 下载语音文件(哪怕它是 Opus 格式)。
  2. 调用 ffmpeg 转码。
  3. 调用 Whisper 识别文字。
  4. 调用 OpenAI 提取餐厅名字和地址。
  5. 自动添加到他的 Google Maps 待去清单中。

这一切都在后台静默发生。当 Peter 打开地图时,餐厅已经在那了。

“App 终将消亡(Melt away)。” Peter 在访谈中抛出了这个震聋发聩的观点。

“为什么我还需要一个专门的 Fitness Pal 来记录卡路里?我只需要拍一张汉堡的照片发给我的 Agent。它知道我在麦当劳,它知道汉堡的热量,它会自动更新我的健康数据库,并建议我晚上多跑 2 公里。”

Agentic Commerce 时代,用户不再需要在一个个孤立的 App 之间跳来跳去。所有的 App 都将退化为 Agent 可调用的 API(或被 Hack 成 API)。

本地优先:隐私与红利的博弈

Moltbot 的另一个标签是 Local-first(本地优先)

虽然 Peter 自己也用 OpenAI 和 Anthropic 的模型(因为它们目前确实最聪明),但他花了大量精力去适配本地模型(如 MiniMax 2.1)。

为此,他甚至给自己的 Mac Studio 拉满了 512GB 的内存。

为什么要这么折腾?

除了“好玩”,还有一个现实的考量:Red Tape(繁文缛节)

“如果你是一个公司,你想让 AI 访问你的 Gmail,你需要经过极其漫长的合规审核,甚至需要收购一家有牌照的公司。这太荒谬了。”

但如果你在本地运行 Agent,这一切都不复存在。

  • 数据在你的硬盘里。
  • 模型在你的显卡里。
  • 操作在你的系统里。

没有人能阻止你读取自己的邮件,没有人能禁止你分析自己的聊天记录。

Peter 甚至预言,AI Agent 的普及将直接带动高性能硬件(如 Mac Mini)的销量。“This is the liberation of data.(这是数据的解放。)”

商业与开源:为爱发电,拒绝收编

随着 Moltbot 的爆火,无数 VC 挥舞着支票找上门,甚至有大厂想直接收购整个项目(或者招安 Peter)。

对此,Peter 的态度非常潇洒:“I built this for me.(我是为我自己造的。)”

他已经财务自由,不需要再为了融资去写 PPT,不需要为了增长去牺牲用户体验。

“代码本身已经不值钱了(Code is not worth that much anymore)。在这个 AI 时代,你完全可以把我的代码删了,让 AI 几个月再写一个新的。”

真正值钱的,是Idea(想法),是Community(社区),是Brand(品牌)

他更倾向于将 Moltbot 运作成为一个非营利基金会(Foundation)。他希望这成为一个属于所有人的、开放的、可 hack 的游乐场,而不是某个大厂封闭生态的一部分。

小结:去构建你的 Loop

在访谈的最后,Peter 对所有开发者发出了呼吁:

“Don’t just watch. Build your own agentic loop.”
(别只是看,去构建你自己的智能体闭环。)

Moltbot 只是一个开始。它证明了,一个拥有长期记忆(Memory)工具使用能力(Tools)自主性(Autonomy)的个人 Agent,能爆发多么惊人的能量。

在这个时代,限制你的不再是技术门槛,而是你的想象力

去写几个 CLI,去 Hack 几个 API,去给你的 AI 装上“手脚”和“记忆”。

未来,属于那些敢于用 AI 重塑生活的人!

资料链接:https://www.youtube.com/watch?v=qyjTpzIAEkA


你的“好玩”项目

Peter 的故事告诉我们,技术最原本的动力是乐趣。如果给你无限的时间和算力,你最想用 AI 为自己做一个什么“好玩”的工具?是全自动点餐助
手,还是你的专属游戏陪练?

欢迎在评论区分享你的脑洞!别管它有没有商业价值,有趣就够了。

如果这篇文章点燃了你久违的代码热血,别忘了点个【赞】和【在看】,并转发给你的极客朋友,一起搞点事情!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


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

© 2026, bigwhite. 版权所有.

你的 CLAUDE.md 写错了:为什么指令越多,AI 越笨?

2026-01-29 07:18:17

本文永久链接 – https://tonybai.com/2026/01/29/write-a-good-claude-md

大家好,我是Tony Bai。

在使用 Claude Code、Cursor 或 Gemini Cli 等 AI 编程工具时,你是否遇到过这样的情况:

明明在项目根目录写了 CLAUDE.md(或 AGENTS.md),洋洋洒洒列了几十条项目规范:“使用 TypeScript”、“不要用 any”、“单元测试覆盖率要达标”……

但 AI 就像个叛逆的实习生,经常对这些指令视而不见,反复犯同样的低级错误。

是你写的 Prompt 不够严厉吗?还是模型不够聪明?

最近,HumanLayer 团队发布的一篇深度分析文章揭示了真相:

问题恰恰在于你写得太多了。

Claude Code 的内部机制会给模型注入一条系统级提醒:

“IMPORTANT: this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant.”
(重要:此上下文可能与您的任务无关。除非高度相关,否则请忽略。)

这意味着,你的 CLAUDE.md 越臃肿,包含的无关信息越多,它被系统判定为“噪音”并整体忽略的概率就越大。

今天,我们来聊聊如何用工程化的思维,重构你的 AI 上下文管理。

第一性原理:AI 是无状态的“新员工”

要写好 CLAUDE.md,首先要理解 LLM 的本质:它是无状态的(Stateless)

每次你开启一个新的 Session,对于 AI 来说,都是入职第一天。它对你的代码库一无所知。CLAUDE.md 是它唯一的“入职手册”和“长期记忆”。

但这并不意味着你要把公司历史全塞给它。一个优秀的入职手册应该包含什么?

HumanLayer 的文章中 总结了 “The Trinity”(三要素)

  1. WHAT(地图): 技术栈是什么?项目结构是怎样的?(特别是 Monorepo,告诉它哪里是 App,哪里是 Lib)。
  2. WHY(目标): 这个项目的核心价值是什么?核心模块的职责边界在哪里?
  3. HOW(工具): 怎么构建?怎么跑测试?用 npm 还是 bun?

除此之外的任何废话,都是在消耗 AI 宝贵的注意力。

最佳实践一:少即是多 (Less is More)

研究表明,即便是最前沿的推理模型(Thinking Models),能稳定遵循的指令上限也就在 150-200 条左右。而小模型(如 Haiku 或 GPT-4o-mini)的遵循能力随着指令数量增加呈指数级下降

更糟糕的是 “位置偏见(Position Bias)”。LLM 高度关注开头(System Prompt)和结尾(最新对话),夹在中间的 CLAUDE.md 如果过长,极易沦为“被遗忘的中间层”。

因此,请遵循以下黄金法则:

  • 不要试图涵盖所有边缘情况。
  • 将根目录的 CLAUDE.md 控制在 300 行以内,HumanLayer 的生产环境甚至控制在 60 行以内
  • 每一行都要问自己:“如果没有这句话,AI 真的干不了活吗?”

最佳实践二:渐进式披露 (Progressive Disclosure)

如果你确实有很多规范要交代,怎么办?

答案是:不要把所有鸡蛋放在一个篮子里。

想象一下,HR 会在入职第一天把 500 页的《数据库运维手册》扔给一个前端开发吗?不会。

你需要构建一套“渐进式”的文档体系:

1. 建立文档库:

在项目中创建一个 .ai/docs/ 目录,存放特定领域的指南:

  • testing.md:详细的测试编写与运行指南。
  • database.md:Schema 定义与迁移规范。
  • architecture.md:核心架构图与数据流。

2. 建立索引:

在主 CLAUDE.md 中,只保留“触发器”:

  • “编写或运行测试前,请务必阅读 .ai/docs/testing.md。”
  • “涉及数据库变更时,请参考 .ai/docs/database.md。”

这样,当 AI 只是在写一个前端组件时,它的上下文窗口就不会被无关的后端 Schema 污染。保持注意力的纯净,是提升 AI 智商的关键。

最佳实践三:别把 AI 当 Linter 用

这是最常见的资源浪费:在 CLAUDE.md 里写了 50 行关于代码风格的规定——“缩进用 2 个空格”、“花括号不换行”、“变量名用驼峰”……

请记住:LLM 是昂贵的推理引擎,不是廉价的格式化工具。

让 AI 去关注缩进,就像让法拉利去送外卖,既贵又慢。而且,AI 即使知道规则,也经常因为概率性生成而“手滑”。

正确的解法是:Tooling > Prompting。

  1. 配置工具: 使用 Prettier, Biome, ESLint, govet 等确定性工具来处理格式。
  2. 设置 Hook: 配置 Claude Code 的 Stop Hook。如果 AI 生成的代码格式不对,让 Linter 报错,把错误信息喂回给 AI。
    • AI: (生成代码)
    • System: “Lint Error: Missing semicolon.”
    • AI: “Ah, fixing it.”

AI 极其擅长修复报错,但并不擅长凭空遵守“隐形的规则”

小结:杠杆的层级

在 AI 原生开发中,CLAUDE.md 处于“杠杆层级”的顶端。

  • 写错一行代码 = 1 个 Bug。
  • 写错一行 CLAUDE.md = 成百上千次错误的规划、错误的检索、错误的代码。

不要盲目依赖 /init 自动生成的文件,那只是个起点。你需要像维护核心代码一样,精心雕琢你的 CLAUDE.md。

现在,打开你的项目,检查一下那个文件。

删掉那些废话,把长文档拆分,把格式化交给工具。

给你的数字员工减负,它才能跑得更快。

资料链接:https://www.humanlayer.dev/blog/writing-a-good-claude-md


你的 CLAUDE.md 有几行?

读完这篇文章,不妨现在就去检查一下你项目里的 CLAUDE.md。它是清爽的“入职手册”,还是臃肿的“裹脚布”?你目前的行数是多少?

欢迎在评论区晒出你的“瘦身”成果!让我们一起给 AI 减负。

如果这篇文章帮你解决了 AI “不听话”的难题,别忘了点个【赞】和【在看】,并转发给你的团队,规范大家的 Prompt 工程!


构建工程化的 AI 工作流

CLAUDE.md 只是构建 AI 原生工作流的起点。

  • 如何配置 Hooks 来实现自动化代码审查?
  • 如何编写 Sub-Agents 来处理隔离的脏活累活?
  • 如何设计 Slash Commands 来固化团队的 SOP?

如果你想深入掌握 Claude Code 的高阶玩法,不仅仅是写 Prompt,而是构建一套“自动纠错、按需加载”的工程化体系。

欢迎关注我的极客时间专栏AI 原生开发工作流实战

我们不聊虚的,只讲能在生产环境中落地的 AI 工程实践。

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


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

© 2026, bigwhite. 版权所有.

20 年 Java 老店的“背叛”:WSO2 为何高呼“Goodbye Java, Hello Go”?

2026-01-29 07:15:10

本文永久链接 – https://tonybai.com/2026/01/29/wso2-goodbye-java-hello-go-tech-stack-shift

大家好,我是Tony Bai。

“当我们 2005 年创办 WSO2 时,开发服务端企业级基础设施的正确语言毫无疑问是:Java。然而,当我们走过第 20 个年头并展望未来时,情况已经变了。”

近日,全球知名的开源中间件厂商 WSO2 发布了一篇震动技术圈的博文——《Goodbye Java, Hello Go!》。

这是企业级软件在云原生时代技术风向标的一次重要偏转。作为 Java 时代的既得利益者,WSO2 曾在 API 管理、集成中间件领域构建了庞大的 Java 帝国。为何在今天,他们会做出如此激进的转向?Java 真的不适合未来了吗?Go 到底赢在哪里?

让我们深入剖析这背后的技术逻辑、架构变迁与社区的激烈争议

时代的变迁——从“服务器”到“函数”

WSO2 的转向并非一时冲动,而是基于对过去 15 年基础设施软件形态深刻变化的洞察。其博文中极其精准地总结了这一变迁:

“服务器”概念的消亡

在 2010 年代之前,中间件是以独立“服务器”(Server)的形式交付的。

  • 应用服务器 (App Servers):如 WebLogic, WebSphere, Tomcat。
  • 企业服务总线 (ESB):集成了各种协议适配器的庞然大物。
  • 业务流程服务器 (Process Servers):管理长周期的业务状态。

那是一个“重量级”的时代。你部署一个服务器,然后把你的业务逻辑(WAR 包、JAR 包)扔进去运行。这正是 Java 和 JVM 的黄金时代——JVM 作为一个强大的运行时环境,提供了热加载、动态管理、JIT 优化等一系列高级功能,完美匹配了这种“长时间运行、多应用共享”的服务器模式。

然而,容器化时代终结了这一切。

现在的“服务器”不再是一个独立的实体,而变成了一个库 (Library)

  • 你的业务逻辑不再是“寄生”在服务器里,而是包含了服务器。
  • 整个应用打包成一个 Docker 镜像,作为一个独立的进程运行。
  • 任务完成后,容器销毁,进程结束。

在 WSO2 看来,“独立软件服务器的时代已经结束了”。这对于 Java 来说,是一个底层逻辑的打击。

生命周期:从“月”到“毫秒”

在过去,一个服务器启动慢点没关系,因为它一旦启动,可能会运行数月甚至数年。JVM 的 JIT(即时编译)机制通过预热来换取长期运行的高性能,这是一种非常合理的权衡。

但在 Kubernetes 和 Serverless 主导的今天,服务器变得极度短暂 (Ephemeral)。

  • 容器根据负载自动扩缩容,新实例必须瞬间就绪。
  • Serverless 函数可能只存活几秒钟。

在这种场景下,启动时间就是服务质量 (SLA)。

WSO2 指出:“容器应该在毫秒级内准备好起舞,而不是秒级。” Java 庞大的生态依赖(Spring 初始化、类加载、注解扫描)和 JVM 的启动开销,在云原生环境下显得格格不入。内存膨胀(Memory Bloat)也直接推高了云厂商的账单。

生态位的错位:修补 vs. 原生

面对挑战,Java 社区并非无动于衷。GraalVM Native Image 试图通过 AOT(提前编译)解决启动速度问题;Project Loom 试图通过虚拟线程解决并发资源消耗问题。

但在 WSO2 的架构师们看来,这些努力更像是一种“追赶式的修补”

“这些解决方案感觉就像是在为一个不同时代设计的语言和运行时进行翻新。”

GraalVM 虽然强大,但带来了构建时间的剧增、反射的限制以及调试的复杂性。相比之下,Go 语言在设计之初就原生 (Native) 地考虑了这些问题:编译即二进制,启动即巅峰,并发即协程。这是一种“原生契合”与“后天适配”的本质区别。

WSO2 的架构重构——前端不动,后端大换血

WSO2 并没有盲目地全盘推翻,他们对企业级软件的三层架构(前端、中间层、后端)进行了冷静的评估:

前端 (Frontend):维持现状

  • 现状:Web (JS/TS), iOS (Swift/Flutter), Android (Kotlin/Java)。
  • 未来No Change
  • 理由:前端技术栈受限于终端设备(浏览器、手机 OS),且更新换代极快(“fad-driven”,时尚驱动)。目前没有改变的必要。

中间层 (Middle Tier):Ballerina 的独角戏

  • 现状:Java, Ballerina。
  • 未来Ballerina
  • 核心逻辑:这一层通常被称为 BFF (Backend for Frontend),负责 API 聚合、编排。WSO2 自研的 Ballerina 语言正是为此而生,它将网络原语(Network Primitives)作为语言的一等公民,极其适合做集成工作。

后端 (Backend):Go 与 Python 的双雄会

  • 现状:Java, Go, NodeJS, Python。
  • 未来Go, Python
  • 核心逻辑:这是基础设施逻辑的核心。Python 将继续统治 AI/ML 领域,而 Go 将彻底接管原本属于 Java 的领地,成为构建高性能、高并发基础设施的首选。

为什么是 Go,而不是 Rust?

这是一个每个技术决策者都会面临的灵魂拷问:既然要追求性能和原生编译,为什么不选 Rust?它不是更快、更安全吗?

WSO2 的回答展现了极高的工程务实精神。他们确实评估了 Rust,但最终选择了 Go。理由如下:

抽象层级的匹配

  • Rust 的战场:操作系统内核、浏览器引擎、嵌入式设备。这些场景需要对内存布局、生命周期做极致的微操,且进程几乎永不重启。
  • Go 的战场:中间件、API 网关、编排系统。

WSO2 构建的是中间件基础设施(如 API Gateway, Identity Server)。在这个层级,“我们总是比裸金属 (Bare Metal) 高那么一点点”。Go 提供的自动垃圾回收 (GC) 和高效的并发原语,恰好处于这个“甜点”位置。

避免“过度杀伤” (Overkill)

Rust 的所有权模型 (Ownership) 和借用检查器 (Borrow Checker) 虽然保证了内存安全,但也带来了极高的学习曲线和开发摩擦。对于大多数企业级业务逻辑来说,Rust 提供的控制力是多余的,而为此付出的开发效率代价是昂贵的。

云原生生态的引力

这是一个无法忽视的因素。Go 是云原生的“普通话”。

Kubernetes、Docker、Prometheus、etcd、Terraform…… 几乎所有现代基础设施的基石都是用 Go 构建的。选择 Go,意味着:

  • 库的复用:可以直接调用 K8s 的库,而不是通过 API。
  • 人才的复用:DevOps 工程师和 SRE 通常都懂 Go,可以无缝参与开发。
  • 社区的共鸣:更容易融入 CNCF 生态,获得社区贡献。

实战验证——WSO2 的 Go 之旅

WSO2 并非纸上谈兵,他们在过去十年中已经在多个关键项目中验证了 Go 的能力:

OpenChoreo (CNCF Sandbox Project)

这是 WSO2 最具野心的项目之一,一个面向 Kubernetes 的开发者平台(IDP)。

  • 挑战:需要深度集成 K8s,处理复杂的 GitOps 流程,且自身必须轻量、快速。
  • Go 的价值:作为 K8s 原生语言,Go 让 OpenChoreo 能够像原生组件一样运行在集群中,资源占用极低。

Ballerina 编译器的彻底重写

这是一个惊人的决定。Ballerina 语言最初是基于 Java 实现的(运行在 JVM 上)。现在,WSO2 正在用 Go 完全重写 Ballerina 编译器。

  • 目标:摆脱 JVM 的束缚,实现瞬间启动。
  • 新架构:前端编译器用 Go 编写,直接生成基于 Go 的中间表示 (BIR),这让 CLI 工具的体验得到了质的飞跃。

Thunder:下一代身份认证平台

身份认证(IAM)通常处于请求链路的关键路径上,对延迟极其敏感。Thunder 利用 Go 的高并发处理能力,实现了在高负载下的低延迟认证,且在容器化环境中具备极快的冷启动能力。

社区激辩——理性的探讨与情绪的宣泄

这篇博文在 Reddit 的 r/golang 板块引发了数百条评论的激烈讨论。这不仅仅是语言之争,更是两种工程文化的碰撞。

反方阵营:Java 依然是王者

  1. “这是管理层的愚蠢决定”
    一位愤怒的网友评论道:“计算资源是廉价的,开发人员的时间才是昂贵的。” 他认为,虽然 Go 节省了内存,但在业务逻辑极其复杂的企业级应用中,Java 强大的 IDE 支持、成熟的设计模式和庞大的生态库能显著降低开发成本。强行切换到 Go,可能会导致开发效率的崩塌。

  2. “Java 并没有停滞不前”
    很多 Java 支持者指出,WSO2 对 Java 的印象似乎还停留在 Java 8 时代。现代 Java (21+) 引入了 Virtual Threads (Project Loom),在并发模型上已经可以与 Go 的 Goroutine 媲美;而 GraalVM 的成熟也让 Java 能够编译成原生镜像,启动速度不再是短板。

  3. “生态位的不可替代性”
    在处理遗留系统(如 SOAP, XML, 复杂的事务处理)方面,Java 积累了 20 年的库是 Go 无法比拟的。用 Go 去重写这些复杂的业务逻辑,无异于“重新发明轮子”,且容易引入新的 Bug。

正方阵营:Go 是未来的选择

  1. “运维友好才是真的友好”
    一位 DevOps 工程师反驳道:“在微服务架构下,运维成本是巨大的。” Go 生成的静态二进制文件(Static Binary)是运维的梦想——没有依赖地狱,没有 JVM 版本冲突,所有东西都打包在一个几 MB 的文件里。这种部署的便捷性,是 Java 永远无法达到的。

  2. “简洁是一种防御机制”
    Java 项目容易陷入“过度设计”的泥潭——层层叠叠的抽象、复杂的继承关系、魔法般的注解。Go 的强制简洁性(没有继承、显式错误处理)虽然写起来啰嗦,但读起来轻松。在人员流动频繁的大型团队中,Go 代码的可维护性往往优于 Java。

  3. “云原生的网络效应”
    正如 WSO2 所言,如果你在写 K8s Controller,如果你在写 Sidecar,如果你在写网关,Go 就是默认语言。这不仅仅是语言特性的问题,这是生态引力的问题。逆流而上使用 Java 编写这些组件,会让你失去整个社区的支持。

小结:没有终极语言,只有最适合的工具

WSO2 的声明并非要“杀死” Java。他们明确表示,现有的 Java 产品线将继续得到长期支持。但在新一代的云原生基础设施平台上,他们坚定地选择了 Go。

这一选择揭示了软件行业的一个趋势:通用编程语言的时代似乎正在结束,“领域专用语言”的时代正在到来。

  • 做前端?选 TS/JS。
  • 做 AI 模型训练?选 Python。
  • 做操作系统、浏览器或者嵌入式系统?选 C/Rust/C++。
  • 做企业级业务逻辑(尤其是遗留系统)?Java 依然稳健。
  • 做云原生基础设施、中间件、高并发服务?Go 是当之无愧的王者。

对于 Gopher 而言,WSO2 的转型是一个强有力的信号:你们选对了赛道。Go 不仅是 Google 的语言,它正在成为定义未来十年企业级基础设施的通用语。

资料链接:

  • https://wso2.com/library/blogs/goodbye-java-hello-go
  • https://www.reddit.com/r/golang/comments/1qomr6g/goodbye_java_hello_go/

你的技术栈“保卫战”

WSO2 的转身,是时代的缩影,也是个体的写照。在你的团队中,是否也发生过类似的“去 Java 化”或“拥抱 Go”的讨论?你认为在云原生时代,Java 还能守住它的江山吗?

欢迎在评论区分享你的观点或经历,无论是坚守者还是转型者,我们都想听听你的声音!

如果这篇文章引发了你的思考,别忘了点个【赞】和【在看】,并转发给你的架构师朋友,看看他们怎么选!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


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

© 2026, bigwhite. 版权所有.