2025-08-03 07:15:02
本文永久链接 – https://tonybai.com/2025/08/03/choose-boring-technology
大家好，我是Tony Bai。
大约十年前，Dan McKinley 的一篇经典雄文《选择无聊的技术》（Choose Boring Technology）在工程师圈子里广为流传。它的核心观点简单而深刻：一家公司的“创新代币”（innovation tokens）是有限的，应该用在刀刃上，而不是随意挥霍在那些闪亮但未经证实的新技术上。
“无聊”的技术，比如 Postgres、Python、PHP，它们的优势不在于新潮，而在于其故障模式和能力边界是众所周知的。当系统在凌晨三点崩溃时，你需要的是一个有大量 Stack Overflow 答案可以求助的领域，而不是一片你必须独自开拓的未知“无人区”。
这个原则，在过去十年里，成为了无数资深工程师的技术选型座右铭。然而，十年后的今天，随着 LLMs 和 Agentic AI 编程工具的崛起，业界仍然认为：这个原则不仅没有过时，反而比以往任何时候都更加重要，甚至更加致命。
AI 编程助手带来了一个全新的变数。这个变数既有趣，又极其危险。
这里的“有趣”在于，现代 AI 工具（无论是 Claude 还是 Copilot）已经非常擅长为几乎任何你能想到的技术栈，生成“看起来非常专业”的代码。你给它一个 prompt，让它用最新的 JavaScript 框架、GraphQL federation 和 Kubernetes 来实现一套微服务，它会迅速给你返回一堆代码——这些代码可能遵循了所有社区惯例，命名规范无可挑剔，错误处理看起来也像模像样，甚至，它可能真的能运行。
这就是 AI 的“诱惑”。它让你感觉，掌握任何新技术都不过是弹指一挥间的事。
而“危险”也恰恰源于此。当你在一个你不熟悉的技术领域里使用 AI 时，一个致命的问题出现了：
你根本无法验证，AI 是不是在“一本正经地胡说八道”（bullshitting you）。
我亲眼见过，有工程师接受了 AI 生成的代码，而这些代码里：
为什么会这样？因为这些代码“看起来是对的”。但它的错误，是深植于技术细节中的，只有真正熟悉这门技术的人才能一眼看穿。
过去，我们说选择一门新技术是增加了一个“未知数”。而在 AI 时代，当你将不熟悉的技术与 AI 生成的代码结合时，你不再是简单地增加未知数，而是在乘以未知数。
你不知道这个框架是否是解决你问题的最佳选择；你不知道 AI 的实现是否遵循了最佳实践；你不知道生成的代码中，哪些是无伤大雅的模板，哪些是核心业务逻辑；你更不知道，这套组合拳将会以何种奇特的方式在未来失效。
这已经不是简单的“货物崇拜”（cargo-culting）了，这是指数级的货物崇拜。
注：“货物崇拜”（cargo culting）是一个源自太平洋岛屿的概念，最早用于描述一些岛屿居民对西方物资和技术的崇拜现象。在二战期间，许多西方士兵在这些岛屿上驻扎，带来了大量的物资和现代技术。当地人对这些物品产生了强烈的向往，认为这些物品是神灵的恩赐。
那么，我们该怎么办？答案出奇地简单，它让我们回归到了那个最朴素的原则：
AI 是你所理解技术的“力量倍增器”，却是你不理解技术的“脆弱拐杖”。
当你选择“无聊”的技术，也就是你真正精通的技术时，AI 会变得无比强大。你可以让 Claude 帮你生成 Rails 代码，因为你对 Rails 了如指掌，能轻易发现它何时提出了可疑的建议。你可以让 Copilot 辅助你写 JavaScript，因为你理解这门语言的怪癖，能对它的产出进行事实核查。
在这种模式下，AI 是你的副驾驶，为你处理繁琐的路线，而你始终掌握着方向盘。
那么，在一个充满 AI 编程助手的世界里，我们该如何应用“选择无聊的技术”这一原则呢？这里有三条黄金法则：
评估新技术时先自问：“如果 AI 为它生成了代码，我有能力审查吗？” 如果答案是否定的，那么这项技术或许不应该用于任何对你而言是任务关键型（mission-critical）的项目。
学习新技术时（当你决定用掉一个“创新代币”时）： 请务必花时间深入理解它，达到能对 AI 的建议进行独立事实核查的程度。不要只是复制、粘贴，然后祈祷好运。
抵制诱惑： 不要把 AI 工具当作一个借口，让你能同时拥抱一门新语言、一个新框架和一套新基础设施。AI 可能会给你一种“我能搞定一切”的错觉，但你无法真正验证其中任何一环。
“选择无聊的技术”这个论点的初衷，是为了降低系统的运维复杂性和团队的认知开销。在 AI 时代，这些理由依然成立，但我们又增加了一个更重大的风险：对抗由 AI 带来的、致命的虚假自信。
如今的风险更高了，因为 AI 生成的代码质量越来越好，使得发现问题变得更加困难。过去，坏代码通常看起来就很糟糕。现在，有问题的代码可能看起来相当不错，直到你对该领域足够了解，才能注意到那些微妙的致命伤。
所以，我的建议始终不变：当你要解决一个问题时，请使用你已经了解的技术。当你想要学习新东西时，那就专心去学习。不要将 AI 生成的代码，误认为是真正的理解。
在一个 AI 可以自信地为你从未用过的技术生成数千行代码的世界里，你自己的、深刻的理解，比以往任何时候都更有价值。
资料链接：
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-08-02 06:58:34
本文永久链接 – https://tonybai.com/2025/08/02/proposal-http3
大家好，我是Tony Bai。
在社区长达数年的热切期盼之后，Go 官方终于迈出了支持 HTTP/3 的关键一步。一项编号为#70914的新提案，正式建议在 x/net/http3 中添加一个实验性的 HTTP/3 实现。这一进展建立在另一项更基础的提案 #58547(x/net/quic) 之上，该提案的实现已取得重大进展，并已从内部包移至公开的 x/net/quic。这意味着 Go 的网络栈即将迎来一次基于 UDP 的、彻底的现代化升级。本文将带您回顾 Go 社区对 HTTP/3 的漫长期待，深入解读官方 QUIC 和 HTTP/3 的实现策略，并探讨其对未来 Go 网络编程的深远影响。
对 HTTP/3 的支持，可以说是 Go 社区近年来呼声最高的功能之一。早在 2019 年，issue #32204 就被创建，用于追踪在标准库中支持 HTTP/3 的进展。在随后的五年里，随着 Chrome、Firefox 等主流浏览器以及 Cloudflare 等基础设施提供商纷纷拥抱 HTTP/3，社区的期待也日益高涨。
在此期间，由 Marten Seemann 维护的第三方库 quic-go 成为了 Go 生态中事实上的标准，为 Caddy 等项目提供了生产级的 QUIC 和 HTTP/3 支持。然而，许多开发者仍然期盼一个“电池内置”的官方解决方案，以保证与 Go 标准库（特别是 net/http 和 crypto/tls）的最佳集成和长期维护。
Go 团队对此一直持谨慎态度，主要原因在于：
现在，随着协议的标准化和 crypto/tls 中 QUIC 支持的落地，Go 团队终于启动了官方的实现计划，并采取了清晰的“两步走”战略。
提案 #58547 旨在 golang.org/x/net/quic 中提供一个 QUIC 协议的实现。这是支持 HTTP/3 的必要前提。经过一段时间的开发，该包的实现已取得重大进展。
Go 团队的核心成员 neild 最近宣布，该 QUIC 实现已从内部包 (internal/quic) 移至公开的 x/net/quic，虽然仍处于实验阶段且 API 可能变化，但这标志着它已足够成熟，可以供社区“尝鲜”和提供反馈。
x/net/quic 的核心 API 概念：
// 客户端发起连接
conn, err := quic.Dial(ctx, "udp", "127.0.0.1:8000", &quic.Config{})
// 服务器接受连接
endpoint, err := quic.Listen("udp", "127.0.0.1:8000", &quic.Config{})
conn, err := endpoint.Accept(ctx)
// 在连接上创建和接受流
stream, err := conn.NewStream(ctx)
stream, err := conn.AcceptStream(ctx)
// 对流进行读写操作
n, err = stream.Read(buf)
n, err = stream.Write(buf)
stream.Close()
值得注意的是，官方实现并未直接采用 quic-go 的代码，rsc 在讨论中解释了原因，包括 API 设计理念的差异、代码风格、测试框架依赖以及从零开始实现可能更易于维护等。
在 x/net/quic 的基础上，提案 #70914 正式启动了 x/net/http3 的开发。与 QUIC 一样，它将首先在内部包 (x/net/internal/http3) 中进行开发，待 API 稳定后再移至公开包，并提交最终的 API 审查提案。
从 gopherbot 自动发布的 CL（代码变更）列表中，我们可以看到 HTTP/3 的实现正在紧锣密鼓地进行中，涵盖了 QPACK（HTTP/3 的头部压缩算法）、Transport、Server、请求/响应体传输等核心组件。
官方 QUIC 和 HTTP/3 的到来，将为 Go 开发者带来革命性的变化：
透明的协议升级：可以预见，未来的 net/http 包将能够像当年无缝支持 HTTP/2 一样，透明地支持 HTTP/3。开发者可能无需修改现有代码，http.Get(“https://example.com/”) 就可能自动通过 UDP 下的 QUIC 协议执行，正如 ianlancetaylor 在讨论中确认的那样。
解决队头阻塞 (Head-of-Line Blocking)：HTTP/3 最大的优势之一是解决了 TCP 队头阻塞问题。对于需要处理大量并发请求的 Go 微服务，这意味着更低的延迟和更高的吞吐量，尤其是在网络不稳定的情况下。
更快的连接建立：QUIC 支持 0-RTT 连接建立，对于需要频繁建立新连接的应用场景，可以显著降低握手延迟。
原生多路复用传输层：QUIC 本身就是一个多路复用的传输协议。虽然提案的初期重点是支持 HTTP/3，但一个标准化的 QUIC API 将为 gRPC over QUIC、WebTransport 以及其他需要多流、低延迟通信的自定义协议打开大门。
尽管 x/net/quic 的开发标志着 Go 官方在用户空间迈出了重要一步，但关于 QUIC 协议的终极愿景，则指向了更深的层次：Linux 内核原生支持。最近，由 Xin Long 提交的一系列补丁，首次将内核态 QUIC 的实现提上了 mainline 的议程。
为什么要将 QUIC 移入内核？
将 QUIC 从用户空间库（如 x/net/quic 或 quic-go）下沉到内核，主要有以下几个核心动机：
当前的实现与挑战
Xin Long 的补丁集展示了一个高度集成化的设计：
不过，预计内核态 QUIC 的合入可能要到 2026 年甚至更晚。
尽管距离在 Go 标准库中稳定地使用 http.Server{…}.ListenAndServeQUIC() 可能还有一段时间，但 x/net/quic 的公开和 x/net/http3 提案的启动，标志着 Go 官方已经吹响了向下一代网络协议进军的号角。
对于 Go 社区而言，这是一个令人振奋的信号。它不仅回应了开发者们长久以来的期待，也确保了 Go 在未来依然是构建高性能、现代化网络服务的首选语言。我们期待着 x/net/http3 的成熟，并最终看到它被无缝地集成到 net/http 标准库中，为所有 Go 开发者带来更快、更可靠的网络体验。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-08-01 08:05:09
本文永久链接 – https://tonybai.com/2025/08/01/proposal-purego
大家好，我是Tony Bai。
对于许多 Go 开发者来说，purego 构建标签一直是一个模糊的存在。它到底意味着“没有 Cgo”、“没有 unsafe”，还是“没有汇编”？这个问题的答案在社区中众说纷纭，甚至连标准库中的使用也不尽统一。最近，一项历时六年、编号为#23172 的提案终于尘埃落定，Go 团队正式接受 (accepted) 了关于 purego 含义的共识。本文将带大家一起回顾这场漫长而精彩的社区辩论，深入探讨其背后的技术权衡，并阐明这个小小的标签对于 Go 的跨实现（如 TinyGo）和可移植性生态的深远意义。
purego 标签的诞生，源于 Go 生态系统日益增长的多样性。除了官方的 gc 编译器，还涌现出了 GopherJS、TinyGo、gccgo 等多种 Go 实现。在这些非标准环境中，对 unsafe 包的指针操作、Cgo 的支持以及 Go 汇编的兼容性各不相同。
最初，protobuf 等库为了兼容Google App Engine 等不允许 unsafe 的环境，开始使用 safe 标签。这个概念逐渐演变为 purego，但其确切含义从未被正式定义。这导致了混乱：
这种模糊性给库作者和不同 Go 实现的维护者带来了困扰。
提案的讨论过程充满了精彩的技术思辨，核心矛盾在于试图用一个标签来承载多个正交（orthogonal）的概念：
noasm vs. nounsafe vs. nocgo：来自 TinyGo 团队的开发者明确指出，TinyGo 支持 unsafe 和 cgo，但不支持 Go 汇编。如果 purego 同时禁止这三者，那么 TinyGo 将被迫禁用它本可以支持的功能。!cgo 标签已经很好地解决了 Cgo 的问题，因此将 cgo 捆绑进来显得多余。
unsafe 的多重“不安全”：Go 安全负责人 Filippo Valsorda (@FiloSottile) 进一步指出，unsafe 包本身也包含了不同层次的“不安全”：
用一个 nounsafe 标签一概而论，过于粗暴，可能会“误伤”许多可移植的 unsafe 用法。
生态现状：seankhliao 通过 GitHub 搜索发现，社区中 //go:build !purego 与 import “unsafe” 的组合（表示非 purego 版本才使用 unsafe）远多于 //go:build purego 与 import “unsafe” 的组合。这表明，社区的主流用法倾向于将 purego 视为不使用 unsafe 和汇编的版本。
在长达数年的讨论后，Filippo Valsorda 的一段评论为这场辩论指明了方向，他主张“不要让完美成为优秀的敌人”：
最终，在 aclements 等核心成员的推动下，社区达成了清晰的共识。
Go 团队最终接受 (accepted) 了该提案，并明确了其最终方向：将在 go help buildconstraint 中正式文档化 purego 构建标签的约定：
这个决议对于 Go 生态系统意义重大：
purego 标签的标准化之路，是 Go 社区在实践中不断探索、辩论并最终达成务实共识的又一个经典案例。它表明，一个健康的语言生态不仅需要顶层设计，更需要在真实世界的需求碰撞中，不断澄清和完善其约定。通过为 purego 赋予一个清晰、专注的定义，Go 语言再次为其跨平台、跨实现的承诺，奠定了一块坚实的基石。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-07-31 08:32:13
本文永久链接 – https://tonybai.com/2025/07/31/periodic-table-of-system-design
大家好，我是Tony Bai。
近日，一篇名为《系统设计的元素》（Elements of System Design）的论文引发社区热议。它的目标宏大且吸睛：通过梳理上百篇横跨操作系统、数据库、分布式系统等领域的经典论文，提炼出一套通用的系统设计原则“元素周期表”。
这份“周期表”的价值，不在于提供一套死板的规则，而在于为我们提供一套共享的词汇和心智模型。它能帮助我们更清晰地思考、更精确地沟通、更深刻地理解不同系统设计背后的内在联系。
下面便是该论文的中译版，希望能给大家带去启发。
系统设计通常通过特定领域的解决方案来传授，例如数据库、操作系统或计算机体系结构，每个领域都有其自成一派的方法和术语。虽然这种多样性是一种优势，但它也可能掩盖了跨领域反复出现的共通原则。本文提出了一个从计算机系统多个领域中提炼出的系统设计原则的初步分类法。其目标是提供一套共享、简洁的词汇，以帮助学生、研究人员和实践者对系统结构和权衡进行推理，跨领域比较设计，并更清晰地沟通设计选择。
投身于计算机系统领域的一大乐趣在于其纯粹的多样性，它涵盖了操作系统、数据库、计算机体系结构、分布式系统、编程语言、网络等众多分支，每个分支都有着丰富的历史。对于初学者来说，由于传统和词汇的多样性，要发现不同领域之间的联系可能颇具挑战：相同的设计原则可能会以不同的面貌出现在不同的领域中。
例如，思考一下 Jim Gray 等人关于数据库隔离级别的经典论文。它仔细阐述了并发控制机制以及在正确性和性能之间的权衡。然而，如果没有在操作系统或计算机体系结构领域接触过类似问题，这些思想可能看起来仅仅是狭隘地“关于数据库”的。实际上，相同的设计原则，“放宽一致性”，以不同的形式在各种系统中反复出现，从弱顺序内存层次结构到分布式系统中的最终一致性协议。当每个社区都使用自己的术语和范例时，初学者可能很难识别出底层的设计原则。这种碎片化增加了认知开销，因为同一个权衡必须在每个上下文中重新学习。
这是一个更广泛的模式：系统研究富含实践洞见，但在共享的概念性支架上则较为薄弱。在各个领域中，类似的挑战反复出现，如管理并发、确保一致性和适应变化，而其框架和词汇却常常不同。因此，看似毫不相关的领域之间的深层联系可能仍然相对模糊。
本文是朝着弥合这些差距迈出的一小步。借用门捷列夫的比喻，我们提出了一个反复出现的系统设计原则的“元素周期表”。其目标并非一个僵化的分类法，而是一个可用的词汇表：一种用以标注论文、讲座和设计文档中所采用的基本原则的简洁方式。其目的是揭示计算机系统中已经存在的结构，以便学生能形成更连贯的心理地图，研究人员能精确定位其贡献，而实践者能以更高的清晰度跨领域讨论设计选择。
我们通过回顾操作系统、计算机体系结构、数据库、网络、编程语言、安全以及计算机系统其他领域的 100 多篇有影响力的论文来识别这些原则。这些论文因其历史意义和持续的相关性而被选中，例如关于并发控制 和共识 的经典论文，以及关于在系统内部使用机器学习 和为云设计系统 的近期工作。
对于每篇论文，我们都问：其底层的高层设计原则是什么？在不同领域中，独立的系统常常不是在机制上趋于一致，而是在共享的设计原则上：例如，通过放宽一致性来提高性能，或通过提升抽象来增强可用性。
要被认定为一条系统设计原则，它必须满足两个条件：
本分析旨在梳理出许多具有持久、通用价值的原则，而非对所有原则进行编目。
我们整理了一套结构化的、包含 40 多个从系统文献中提炼出的通用设计原则。如下图所示，它们被组织成反映了系统设计中常见维度的不同主题组。
图例： Code = 唯一短符号, Name = 原则名称, Intent = 简短描述。
每个原则都带有一个简短的符号（例如，Co 代表可组合性，Op 代表乐观设计）以便快速参考。我们强调设计意图而非规定具体机制：这些原则阐述的是诸如“在并发下保持正确性”或“优先处理普遍情况”等目标，而不是“使用此锁定协议”或“优化此查询计划”，具体的实现则留给特定领域。
Si – Simplicity (简单性)
选择满足当前需求的最简单的系统设计；抵制复杂性，例如“以防万一”而增加的额外层次、服务或通用性，直到有证据表明其有益。
示例： 避免对系统进行过早的架构优化。
Mo – Modularity (模块化)
将系统划分为具有最小化接口的高内聚单元，以便每个单元都可以被独立地推理、替换或演进。该原则专注于分解：选择边界以促进关注点的清晰分离，使每个职责都位于一个模块内。
示例： OSI 模型将通信分解为具有明确边界的标准化层次，允许独立开发和替换。
Co – Composability (可组合性)
设计可被安全、灵活地重新组合的组件；依赖显式的合约和类型约束的接口，以使每个合法的组合都保持正确，让组件能像可互换的积木一样被组装。与模块化不同，该原则专注于重新组合：确保组件可以安全、灵活地结合。
示例： Unix 程序（如 grep, sort, uniq）从标准输入读取并写入到标准输出，让用户可以组合复杂的文本处理管道。
Ex – Extensibility (可扩展性)
设计系统以允许安全的用户自定义扩展，例如插件，而无需修改系统核心。当扩展来自不受信任方时，通过沙箱进行隔离以保护安全。
示例： Unix 也体现了可扩展性：用户可以添加新程序而无需更改内核。
Pm – Policy/Mechanism Separation (策略与机制分离)
通过暴露一个通用接口，将“应该做什么”（策略）与“如何执行”（机制）分离开来，使得多种策略可以插入到同一个机制中。
示例： Hydra 拥有一个通用机制的内核（调度、分页、保护），并将资源分配策略移至用户级模块。
Gr – Generalized Design (通用化设计)
设计一个具有明确变化点（如类型、可调参数或插件）的单一核心，使其可以在不产生重复的情况下服务于多种用例，但当特化能带来性能、准确性或清晰度的显著提升时，则进行特化。
示例： C++ 标准模板库是一组通过模板参数化的容器、迭代器和算法的集合。Postgres 允许用户向核心数据库系统添加类型和操作符。
Sc – Scalability (可伸缩性)
设计系统以应对数据、流量或节点的增长，同时保持成本或延迟的近线性增长。
示例： MapReduce 通过将工作分解为并行任务并以最小的协调来聚合结果，从而在节点间进行扩展。
Rc – Reuse of Computation (计算复用)
通过缓存、物化中间结果（例如索引），或在重复或稍作修改的输入上增量更新输出来避免冗余工作，从而节省计算。
示例： B+树复用其已排序的键顺序：查找遵循现有的搜索路径，而不是每次重新扫描整个数据集，从而复用了计算。
Wv – Work Avoidance (工作规避)
跳过不会改变外部可观察结果的计算。例子包括惰性求值和谓词短路。
示例： 惰性求值将工作推迟到值被需要时才执行，从而消除了无用的计算。
Cc – Common-Case Specialization (普遍情况特化)
检测主导运行时的执行路径或数据项（“热点”），并专门为它们创建一个精简的快速路径，同时用一个较慢的通用路径来正确处理所有情况。
示例： 在首次调用时缓存接收者类的目标方法，这样后续对该普遍接收者的调用将命中快速路径；不常见的类则回退到完整的方法查找例程。
Bo – Bottleneck-Oriented Optimisation (瓶颈导向优化)
对端到端性能进行剖析，定位最紧张的资源约束，并在此处集中改进，直到另一个阶段成为限制因素。
示例： 罕见的第99百分位延迟的长尾请求是延迟瓶颈，而复制请求有助于削减尾部响应时间。
Ha – Hardware-Aware Design (硬件感知设计)
根据底层硬件的延迟、带宽、并行性和持久性特性（例如缓存层次、NUMA、SSD、GPU）来塑造算法和数据结构。
示例： BLAS 定义了经过缓存和向量优化的内核，使线性代数代码能高效利用硬件。
Op – Optimistic Design (乐观设计)
假设普遍情况会成功并继续执行，跳过协调，仅在假设被证明错误时才依赖一个（可能昂贵的）恢复路径。
示例： 乐观并发控制无锁地运行事务，然后在提交时进行验证，仅在检测到冲突时才回滚。
La – Learned Approximation (学习式近似)
用在数据上训练的模型替换手工制作的算法，以牺牲有界的不精确性来换取效率或灵活性。
示例： 感知器分支预测器在线学习权重以预测分支结果，其性能优于固定的两位计数器，且无需扩大表的大小。
Al – Abstraction Lifting (抽象提升)
将底层操作封装在一个更高层的接口或领域特定语言之后，该接口表达的是意图而非步骤。这使得内部优化成为可能，也允许单一的定义能针对不同的后端。
示例： SQL 查询声明要检索的结果；DBMS 自动选择访问路径、连接顺序和物理操作符。
Lu – Language Homogeneity (语言同质性)
在核心组件和扩展中采用单一、良定义的中间表示（或语言），从而使语义对齐、工具可组合，并以最小的努力实现跨层优化和复用。
示例： LLVM 暴露了一个基于类型和SSA的IR，许多前端以此为目标，许多后端也共享它，从而实现了跨语言优化和相同中间端遍的复用。
Se – Semantically Explicit Interfaces (语义明确的接口)
精确地指定一个接口（涵盖效果可见性、顺序、持久性等），以便用户可以对调用的真实外部可观察状态进行推理，而无需猜测隐藏的缓冲或复制。
示例： SQL 隔离级别指定了精确的异常语义，并明确了可见性保证。
Fs – Formal Specification (形式化规约)
使用数学模型或逻辑来描述系统行为，以支持严格的推理、验证或综合。实现此原则的机制包括时序逻辑、状态机以及其他使系统属性可分析的形式化方法。
示例： TLA+展示了如何使用逻辑和集合论来规约和检查系统，以便在编码前捕获设计错误。
Ig – Invariant-Guided Transformation (不变量驱动转换)
使用形式化声明的不变量来驱动安全的重构、优化或重新配置。
示例： 在编译器中，SSA 将“每个名称只有一个定义”视为 IR 不变量；各个遍在重写代码时保持语义，然后重新建立 SSA。在查询优化器中，关系代数等价（例如，选择/投影下推）保持结果的语义。
Lt – Location Transparency (位置透明)
隐藏资源的物理位置，以便客户端通过统一的名称或句柄进行交互。
示例： 程序可以像调用本地过程一样调用远程过程，从而掩盖了主机的地理位置。
Dc – Decentralised Control (去中心化控制)
将决策权分散到多个节点，以避免单点故障或瓶颈。
示例： Dynamo 通过一致性哈希对数据进行分区，并使用基于 gossip 的成员关系，从而避免了任何中央协调器。
Fp – Function Placement (功能放置)
将功能放置在拥有必要上下文和资源的地方，以实现正确性和效率，避免在别处进行冗余工作。
示例： 端到端论证表明，像可靠性检查这样的功能只有在端点才能实现其正确性。
Lo – Locality of Reference (引用局部性)
将相关的数据和操作在时间和空间上彼此靠近，以保持访问模式并最小化计算与状态之间的分离。
示例： 工作集模型形式化了时间局部性，以将热点页面保留在内存中。
Ep – Equivalence-based Planning (等价规划)
在保持语义等价的通用IR上应用代数/逻辑重写规则；将最终选择推迟到后续的成本/约束阶段。
示例： Starburst 的基于规则的重写系统应用关系等价（例如，谓词下推）来生成逻辑上等价的查询。
Cm – Cost-based Planning (成本规划)
当系统必须在备选的设计、配置或执行策略中做出选择时，使用成本模型来指导搜索，以找到低成本的解决方案（能源、金钱等），而无需枚举整个空间。
示例： Selinger 查询优化器在一个成本模型下选择成本最低的计划。
Cp – Constraint-based Planning (约束规划)
将决策和硬性或软性约束进行编码，并依赖一个求解器（ILP/SMT等）来找到一个可行或最优的分配方案。
示例： Quincy 将集群调度问题建模为带有局部性和公平性约束的最小成本流问题，并求解以获得分配方案。
Gd – Goal-Directed Planning (目标导向规划)
接受对期望最终状态的声明性描述，并自动合成一个具体的操作序列来达到它，从而将用户与实现细节隔离开来。
示例： Cascades 查询优化器通过基于规则的转换和成本引导的搜索，将一个 SQL 查询（目标）转化为一个可执行的计划。
Bb – Black-Box Tuning (黑盒调优)
当分析性的成本模型不可用时，通过在目标系统上测量候选方案来搜索计划/配置空间，迭代地选择更好的方案（例如，启发式或贝叶斯搜索），并缓存胜出者。
示例： ATLAS 在目标 CPU 上凭经验对候选的 BLAS 内核配置进行计时，并固定性能最佳的参数，而无需分析性的成本模型。
Ah – Advisory Hinting (建议性提示)
提供非强制性的提示，系统可以利用这些提示来提高性能，但不会改变正确性或需要强制执行。
示例： Lampson 提倡使用可选的“提示”，这些提示有助于提高性能，但如果被忽略，绝不能影响正确性。
Ad – Adaptive Processing (自适应处理)
监控运行时条件，并自动调整参数或策略。
示例： Eddies 根据反馈在运行时持续地对查询操作符进行重新排序，在不停止执行的情况下进行适应。
Ec – Elasticity (弹性)
根据不断变化的需求和成本目标，自动调整资源分配。例子包括预测性自动伸缩和负载整形。
示例： Chase 等人根据负载和效用动态地配置服务器，体现了弹性资源管理。
Wa – Workload-Aware Optimisation (负载感知优化)
持续观察工作负载的形态（倾斜、局部性、访问频率等），并调整数据布局、算法选择或资源分配以匹配当前模式。
示例： 数据库“cracking”技术根据查询谓词增量地重组列数据，从而使数据布局持续地适应观察到的工作负载。
Au – Automation and Autonomy (自动化与自治)
让系统无需人工干预即可执行常规或响应式任务，通常通过从追踪或用户提供的示例中学习来实现。
示例： AutoAdmin 从工作负载追踪中自动推荐索引/物化视图 [7]。通过示例编程的系统通过从少数用户提供的示例中进行泛化来自动化任务。
Ho – Human Observability (人类可观测性)
暴露系统的内部状态，如指标、追踪、计划，以使系统有意地变得透明；这种透明度提高了可观测性、调试、内省和控制能力。
示例： Paxson 的端到端互联网数据包动态分析展示了丰富的测量和追踪如何实现有根据的调试和调优。
Ev – Evolvability (可演进性)
设计系统使其能在最小化停机时间或重写成本的情况下进行变更，且不破坏现有客户端的外部合约或可观察行为。与让外部人员通过定义的钩子点添加新行为而不触及核心的可扩展性不同，可演进性让系统内部随时间变化而不会破坏现有的外部合约。
示例： Parnas 展示了模块化设计如何使系统更容易在不进行颠覆性重写的情况下进行扩展。
Ft – Fault Tolerance (容错性)
设计系统使其在组件故障时仍能继续运行，尽管可能以一种降级的形式。
示例： Gray 对计算机为何停止运行的分析表明，复制和自动重启让服务能够在硬件和软件故障中持续运行。
Is – Isolation for Correctness (隔离以保正确)
防止组件间的意外干扰，从而使局部推理保持有效。
示例： 两阶段行级锁定阻止一个事务读取或覆盖另一个事务未提交的数据，从而保持隔离保证。
At – Atomic Execution (原子执行)
将多个操作组合在一起，使其表现为不可分割的，要么全部生效，要么全不生效。
示例： 使用事务性内存，事务内的内存操作会进行推测性执行，然后原子性地提交；如果发生任何冲突或故障，整个块将中止，不留下任何部分状态。
Cr – Consistency Relaxation (一致性松弛)
为提高性能、可用性或并发性，在有文档记录的边界内，刻意放宽强一致性或顺序约束。
示例： Bayou 允许移动客户端在断开连接时更新副本，并保证在副本重新连接时最终会趋于一致，这是用严格的一致性换取离线可用性。
Sy – Security via Isolation (隔离以保安全)
强制执行严格的边界，使故障或恶意代码无法影响其他组件。
示例： 一个正确的虚拟机监视器为每个客户机呈现一个完整、隔离的机器，并拦截特权操作，防止一个客户机危及其他客户机或宿主机。
Ac – Access Control and Auditing (访问控制与审计)
定义权限，并记录每次访问以备问责。
示例： Lampson 对访问控制列表、能力（capabilities）和审计追踪的分类法是现代安全机制的基础。
Lp – Least Privilege (最小权限)
只授予完成任务所必需的最小权限，以缩小爆炸半径。
示例： 对1988年互联网蠕虫的尸检报告显示，过度的权限让蠕虫得以传播，并促使了最小权限守护进程的广泛采用。
Tq – Trust via Quorum (法定人数信任)
依赖多个独立参与者的一致同意，而非单一权威。
示例： Paxos 算法将状态复制到一个多数法定人数中，这样即使少数节点崩溃或行为恶意，服务也能保持正确。
Cf – Conservative Defaults (保守默认值)
发布时采用限制性的、安全的设置；让专家选择性地进入风险更高、速度更快的模式。
示例： 采用“默认无访问”策略，每个保护机制都应只在明确授予时才允许访问。
Sa – Safety by Construction (构造即安全)
通过代码或数据的结构设计，使整类错误变得不可能发生，而不仅仅是被检测到。
示例： Rust 的所有权和借用检查器在编译时就防止了数据竞争和悬垂指针。
为了说明多个设计原则在实践中如何交织在一起，我们以关系数据库系统中从逻辑操作符计划到物理操作符计划的映射为例。
因此，数据库系统中从逻辑到物理操作符的映射，体现了多个设计原则如何共同作用，以高效处理声明性的SQL查询。
任何试图组织像计算机系统这样广泛的领域的尝试都涉及到权衡。此表不是一份检查清单或一个普适的理论；它是一个共享的词汇表，旨在突出反复出现的原则并鼓励进行结构性反思。话虽如此，仍有几个局限性：
最终，此表是一种帮助学生更清晰地看到反复出现的设计原则，协助系统设计师更精确地沟通权衡，并帮助研究人员认识到他们的思想在更广阔的系统设计蓝图中所处位置的手段。
系统设计横跨不同的领域和词汇，这可能使共享讨论变得更加困难。我们继承机制，研究权衡，并建立直觉，然而用于描述底层思想的简洁术语并不总是唾手可得。这里提供的设计原则“元素周期表”旨在提供一种适度的通用语言，通过命名反复出现的思想，使其更容易被传授、比较和在其上进行构建。
[1] Ron Avnur and Joseph M. Hellerstein. Eddies: Continuously Adaptive Query Processing. In SIGMOD, 2000.
[2] Rudolf Bayer and Edward McCreight. Organization and Maintenance of Large Ordered Indexes. Acta Informatica, 1972.
… (请参考原文中的详细参考文献列表) …
[48] Hubert Zimmermann. OSI Reference Model – The ISO Model of Architecture for Open Systems Interconnection. IEEE Transactions on Communications, 1980.
如果您觉得本分析有用，请按如下方式引用：
Joy Arulraj. Elements of System Design arXiv preprint arXiv:TBD, 2025.
论文地址：https://github.com/jarulraj/periodic-table
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-07-30 12:32:32
本文永久链接 – https://tonybai.com/2025/07/30/six-principles-production-ai-agents
大家好，我是Tony Bai。
随着 AI Agent 技术的兴起，许多开发者都投入到构建智能体的浪潮中，但很快就会发现，让 Agent 稳定、可靠地工作远非想象中容易。它们时而产生幻觉，时而偏离轨道，时而做出一些令人费解的“愚蠢”行为。最近，来自 app.build 的 Arseni Kravchenko 分享了他们在构建生产级 AI Agent 过程中总结出的六大核心工程原则。这些原则摒弃了虚无缥缈的“提示词黑魔法”，回归到坚实的软件工程基础。对于正在或计划使用 Go 构建 AI Agent 的开发者来说，这是一份宝贵的实践指南。
许多人对“提示词工程”持怀疑态度，认为它充满了“我奶奶快不行了，请帮帮我”之类的奇技淫巧。然而，作者指出，现代 LLM 真正需要的是直接、详细、清晰且无矛盾的上下文，而非情感操控。
对于开发者而言，你要做的就是不要耍小聪明，要把系统提示当作给 Agent 的API 文档来写。
当你为 Agent 提供一个通过 os/exec 调用的工具时，不要只告诉它工具的名字。在系统提示中清晰地说明：
一个详尽的系统提示是 Agent 可靠行为的基石。
“上下文工程”是比“提示词工程”更重要的概念。巨大的、单一的上下文不仅成本高、延迟大，还会导致模型出现“注意力衰减”，忽略掉关键信息。
作者建议大家：默认只提供最少必要知识，并通过工具让 Agent 在需要时主动获取更多上下文。
与其在初始提示中塞入整个项目的源代码，不如：
如上图所示，将一个庞大的任务分解为多个具有专注上下文的、可编排的子任务，是构建高效 Agent 的关键。
工具是 AI Agent 的核心。设计给 Agent 用的工具，比设计给人用的 API 更具挑战性，因为 LLM 不会“读心术”，它们会毫不留情地滥用你留下的任何漏洞。
作者建议：把你的 Agent 当成一个聪明但容易分心的初级开发者，为它设计 API：
一个没有验证和反馈的 Agent 是不可靠的。优秀的 Agent 系统总是将 LLM 的创造力与传统软件的严格性结合起来，形成一个“演员-评论家”（Actor-Critic）模型：让 LLM Actor 自由创造，让严格的 Critic 程序来验证。
对于开发者来说，这是一个天然的优势领域！
这个反馈循环不仅能过滤掉错误的输出，更是 Agent 学习和改进的基础。
当 Agent 失败时，手动排查海量的日志是不现实的。我们可以构建一个“meta Agent”来解决这个问题，即让另一个 LLM 来分析失败 Agent 的日志，找出问题的根源。
流程：
这个元循环能高效地发现我们自己可能忽略的系统性问题。
当 Agent 做出一些“愚蠢”的行为，比如忽略你的明确指令，或者用一种奇怪的方式绕过问题时，我们的第一反应通常是“这个模型真笨”。
但作者建议：先调试你自己的系统，再怪罪模型。
作者分享了一个亲身经历：他明确要求 Agent 使用一个集成工具来获取数据，但 Agent 却固执地使用模拟的随机数据。在愤怒地检查日志后，他发现自己忘了给 Agent 配置正确的 API 密钥。Agent 尝试调用工具，连续失败，最后只能选择一个它能走的通的、但却是错误的路径。
因此，当你的 Agent 行为异常时，请检查一下：
构建有效的 AI Agent，关键不在于寻找一个能解决所有问题的“银弹”提示或高级框架。它回归到了系统设计和严谨的软件工程。
作为开发者，我们应该聚焦于：
当你被 Agent 的行为所困扰时，记住，问题很可能出在缺失的工具、模糊的提示或不足的上下文，而不是模型本身的局限性。将错误分析视为开发过程中的一等公民，我们的目标不是构建一个从不犯错的完美 Agent，而是构建一个可靠的、可恢复的、能够优雅地失败并被我们迭代改进的Agent。
资料链接：https://www.app.build/blog/six-principles-production-ai-agents
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-07-29 08:48:44
本文永久链接 – https://tonybai.com/2025/07/29/slog-multihandler
大家好，我是Tony Bai。
自 log/slog 在 Go 1.21 中引入以来，一个常见的需求始终困扰着开发者：如何将日志同时发送到多个目的地，并为每个目的地设置不同的日志级别？尽管社区已涌现出 samber/slog-multi 等优秀的三方库，但关于“标准库是否应原生支持”的讨论从未停止。最近，一项编号为#65954 的提案，建议在 log/slog 中加入 MultiHandler，获得了 Go 官方的 [likely accept] 评级。本文将带您回顾该提案从被质疑到被接受的全过程，深入探讨其背后的设计权衡。
在实际生产环境中，日志往往需要被送往多个地方：
* 控制台（stdout）：用于开发和调试，通常需要 DEBUG 级别的详细信息。
* 本地文件：用于归档和追溯，可能需要 INFO 级别以上的日志。
* 远端日志服务（如 ELK, Loki,VictoriaLogs等）：用于聚合和告警，可能只关心 ERROR 级别的日志。
然而，log/slog 的核心设计是一个 Logger 对应一个 Handler。虽然 io.MultiWriter 可以将相同格式、相同级别的日志写入多个 io.Writer，但它无法满足不同目的地、不同级别这一核心需求。
这导致许多开发者不得不自行实现 slog.Handler 来“扇出”（fan-out）日志，或者引入第三方依赖。正如提案者 lxl-renren 和多位评论者所指出的，这是一个非常普遍的场景。
提案初期，Go 团队成员 jba (Jonathan Amsterdam) 和 seankhliao 对其必要性提出了质疑，核心论点是：
1. 社区已有解决方案：像 samber/slog-multi 这样的库已经很好地解决了问题。
2. 实现相对简单：开发者可以自己编写一个 multiHandler 来实现。
3. 避免增加标准库维护负担：Go 团队对向标准库添加新 API 持非常谨慎的态度。
然而，随着讨论的深入，社区的声音和更多场景的出现，逐渐改变了 Go 团队的看法。
在讨论中，Go 安全负责人、核心开发者 Filippo Valsorda (@FiloSottile) 的评论成为了一个重要的转折点。他分享了自己在三个不同项目中都复制粘贴了的 multiHandler 实现，并直言：“代码量太少，不值得为此增加一个依赖。”
这段代码堪称 slog.Handler 实现的典范，简洁而完整：
type multiHandler []slog.Handler
func MultiHandler(handlers ...slog.Handler) slog.Handler {
return multiHandler(handlers)
}
func (h multiHandler) Enabled(ctx context.Context, l slog.Level) bool {
for i := range h {
if h[i].Enabled(ctx, l) {
return true // 只要有一个 handler 需要，就启用
}
}
return false
}
func (h multiHandler) Handle(ctx context.Context, r slog.Record) error {
var errs []error
for i := range h {
// 在 Handle 内部再次检查 Enabled，确保日志只发给需要的 handler
if h[i].Enabled(ctx, r.Level) {
// 克隆 Record 以防 handler 修改，影响后续 handler
if err := h[i].Handle(ctx, r.Clone()); err != nil {
errs = append(errs, err)
}
}
}
return errors.Join(errs...) // 合并所有 handler 的错误
}
func (h multiHandler) WithAttrs(attrs []slog.Attr) slog.Handler {
handlers := make([]slog.Handler, 0, len(h))
for i := range h {
handlers = append(handlers, h[i].WithAttrs(attrs))
}
return multiHandler(handlers)
}
func (h multiHandler) WithGroup(name string) slog.Handler {
handlers := make([]slog.Handler, 0, len(h))
for i := range h {
handlers = append(handlers, h[i].WithGroup(name))
}
return multiHandler(handlers)
}
Filippo 的分享有力地证明了：这确实是一个普遍存在、实现固定、但自己写又有点麻烦的“最佳实践”代码片段。将其标准化，可以避免社区无数次地“重复造轮子”。
最终，在充分吸取了社区的意见后，jba 转变了看法，并亲自提出了最终的 API 提案，该提案目前已被标记为 [likely accept]：
// MultiHandler returns a handler that invokes all the given Handlers.
// Its Enable method reports whether any of the handlers' Enabled methods return true.
// Its Handle, WithAttr and WithGroup methods call the corresponding method on each of the enabled handlers.
func MultiHandler(handlers ...Handler) Handler
在讨论中，团队还明确了几个重要的行为特性：
slog.MultiHandler 的提案演进过程，是 Go 标准库发展哲学的一次完美体现。它始于一个看似“社区可以自己解决”的问题，但通过社区的广泛反馈和真实场景的展示，最终证明了将其标准化的价值：为最普遍的需求提供一个简单、可靠、零依赖的解决方案，同时为更复杂的需求留出空间，让社区生态去创新。
对于广大的 Go 开发者而言，这无疑是个好消息。在不久的将来，我们或许就能告别为多目标日志而编写的那些重复代码或引入的微小依赖，享受到标准库带来的便利和统一。这正是 Go 语言持续改进、不断提升开发者体验的魅力所在。
资料链接：https://github.com/golang/go/issues/65954
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
