这是百度网络监控工具 nettools 开源系列的第四篇。前三篇分别介绍了 bitflip/baize（UDP 丢包与改包检测工具和Agent）、lidar（TCP SYN 端口可达性探测），它们解决的都是「服务器之间」「点到点」的探测问题——前提是：探测机和被探测对象，至少有一端在我们手里。

但有一类设备，我们既无法在它上面装 agent，也没法在它对面的机房里放一台探测机。这就是今天的主角 evr 要解决的困境。

这也是我更深入的了解网络包的构造，把网络探测玩出花了来，对我的网络编程的功力大增的一个很好的场景。

项目地址：https://github.com/baidu/nettools
文档：https://nettools.rpcx.io

一、evr 探测的困境：探测机进不去客户机房

先说一个真实的场景。

百度有大量的云客户，我们提供的 EVR（Edge Virtual Router，边缘虚拟路由器） 设备作为客户侧网络接入百度云网络的边界节点。EVR 往上连百度的骨干/城域网络，往下连客户自己的虚拟网络（VXLAN overlay）。

EVR - 边缘虚拟路由器，通常用于在虚拟化环境中实现路由功能。EVR 位于网络的边缘，用于连接内部网络和外部网络（如客户机房）。

现在问题来了：我们需要监控「百度网络 → EVR」这一段链路的健康度——有没有丢包、延迟多大、有没有改包。按照前几个工具的套路，我们的方案应该是：

• 在 EVR 设备上装个 agent？—— 不行。EVR 是网络设备/客户侧设备，我们没有权限往里塞监控程序。
• 在 EVR 对面（客户机房内）放一台探测机，做点到点探测？—— 更不行。那是客户的机房，正常情况我们不可能在客户的物理环境里申请一台探测机常驻。

lidar 那一套「发 SYN，靠对端内核 TCP 协议栈自动回 SYN-ACK/RST」的思路，在这里也不灵——EVR 不是一台服务器，它不会帮你跑 TCP 协议栈三次握手，或者说不允许我们高频的探测。

1
2
3
4
5
6

   百度侧                          边缘设备
┌──────────┐                  ┌──────────────────────┐
│  探测机   │ ───── ??? ─────► │   EVR 设备            │
│ (我们的)  │                  │   (装不了 agent)      │
└──────────┘                  │   对面也放不了探测机    │
                              └──────────────────────┘

困境的本质是：被探测对象不可控，且它对面也无法部署探测机。 我们需要一个 「单边」 就能完成的探测方案——只在百度侧放一台机器，让 EVR 设备自己「帮我们把包送回来」。

答案藏在 EVR 设备的工作原理里：它是一个 VXLAN VTEP（VXLAN Tunnel End Point）。而 VTEP 有一个非常好用的特性——它会忠实地按照内层 IP 头转发解封后的内层帧。这就给了我们「构造一个会被反射回来的 VXLAN 包」的可能。

要理解这个技巧，得先看懂 VXLAN 的包结构。

阅读全文

我把 775 篇收藏的文章塞进一个 4MB 的向量库，然后问它："我都收藏过哪些关于 loop engineering 的资料？"三秒钟，它把散在六七篇文章里的观点拼成一段答案，每条都带出处。

这不是什么 SaaS 产品，是我自己写的一个 skill，叫 chao-rag-wiki。今天聊聊它，顺便聊聊它背后那个问题：知识库越攒越大，你到底怎么"读"它?

得先从 Karpathy 的一个想法说起。

阅读全文

"Clear is better than clever."
清晰胜于聪明。
—— Rob Pike, Go Proverbs

第 23 章把重构讲完了。嗅坏味道、套 Fowler 手法、小步施工、每步测试，这套东西对 Java、Python、Go 一视同仁。但真到 Go 上手你会发现，Fowler 的目录够不着 Go 的好几层脾气。一段能跑的 Go 代码，可能还停在 Go 1.10 的写法，不地道；可能并发原语用错了，race detector 一开就红，不安全；也可能分配没控住，cache line 在 false sharing，不快。这些坏味道扫不出来，是 Go 二十年攒下来、只有老手才摸得到的门道。

门道都散在各处。Dave Cheney 的高性能工作坊讲一套，dgryski 的 go-perfbook 讲一套，《Go 并发编程实战》讲一套，Go 团队的 modernize 分析又讲一套，再加上无数生产事故换来的风格约定。以前你得一本书一本书读、一个 pprof 一个 pprof 啃。现在有人把这些蒸成一个 Skill，Agent 调一下就能用。

本章介绍五个 Go 专属的 Skill，正好覆盖 Go 工程的四个面：现代化（/modern-go）、性能（chao-go-perf）、并发（chao-go-sync）、风格（go-style-guide），外加一个把这几样打包、还顺带做了效果评估的全家桶（cc-skills-golang）。前三个是本书作者 smallnest 写的，对，写这本书的人和写这些 Skill 的人是同一个；后两个分别来自 madflojo（Benjamin Cane）和 samber。

阅读全文

「Any fool can write code that a computer can understand. Good programmers write code that humans can understand.」
任何傻瓜都能写出计算机能看懂的代码。好程序员写的是人能看懂的代码。
—— Martin Fowler

第 22 章解决了「人怎么读懂 AI 写的代码」，用 UML 把代码画成图。

读懂之后呢？你打开 AI 生成的代码，能跑，但是一团乱麻：一个方法三百行，一个类管了八件事，同样的逻辑复制了五遍。这时候怎么办？

重构。

这件事本身不新鲜，Martin Fowler 1999 年就把它写成了一本书。变的是执行者。以前是人对着那本书一处一处手动改，现在是 AI 对着同一本书的目录自动改，人退到后面审查 diff。

阅读全文

「A picture is worth a thousand words. A diagram is worth ten thousand lines of code.」
一图胜千言。一张图胜万行代码。

第 13 章解决了一个问题：AI 写代码容易，读代码难。Understand-Anything 用知识图谱让 AI 理解现有代码。

反过来——代码写完了，作为人类你怎么理解它？毕竟，线上出了故障你还等着你背锅呢。

我前一段看到一句箴言："𝐲𝐨𝐮 𝐜𝐚𝐧 𝐨𝐮𝐭𝐬𝐨𝐮𝐫𝐜𝐞 𝐲𝐨𝐮𝐫 𝐭𝐡𝐢𝐧𝐤𝐢𝐧𝐠, 𝐛𝐮𝐭 𝐲𝐨𝐮 𝐜𝐚𝐧𝐧𝐨𝐭 𝐨𝐮𝐭𝐬𝐨𝐮𝐫𝐜𝐞 𝐲𝐨𝐮𝐫 𝐮𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝𝐢𝐧𝐠"， 翻译过来就是"你可以外包你的思考(给AI),但是你不能外包你的理解"。 这句话被 Andrej Karpathy 多次引用，以至于大家认为是他说的，其实是kache说的：

这句话非常有哲理。Dex Horthy 在 2025 AI Engineer 大会上独立提出了："Don't outsource the thinking" / "AI cannot replace thinking, it can only amplify the thinking you have done."，但是今年你看， AI已经外包了我们的思考，你只需说出的你需求，智能体就能帮助你生生成你要的程序，但是 AI 没有办法帮我们理解啊。

我最近就遇到了这样的困惑：我通过goal workflow很快的实现了一个大模型训推任务智能诊断系统，全是AI帮我生成的，但是在联调的前一个星期，我心虚了。

因为我知道，联调和上线的时候，必然有一些问题，比如当时的设计有些模糊的地方，设计上有gap, 实现上也难免有bug。如果我对生成的代码不熟悉，联调的时候出故障我都不知道啥原因咋修复，可能当时还得重新捋代码才能慢慢找根因，太影响联调的同学了。未来上线以后出现问题，想快速修复就更不可能了。

所以我专门花了两天时间，建了几个卡片，就为了学习代码理解代码。

那我是通过什么方式去理解AI生成的代码的呢？

答案藏在一个用了二十多年的老工具里：UML。区别只有一点：以前的 UML 是人画给团队的，现在是 AI 画给你的。十四种图，从类结构到部署拓扑，从序列交互到状态变迁。AI 生成代码，AI 再画图解释代码——你读图就够了。

为此，我专门创建了一个Skill，用来生成UML的十四种代码和架构图、流程图以及泳道图。此skill的介绍：https://goal.rpcx.io/index_cn.html#step-diagram， 也集成到了goal workflow套件中了。

本章分两部分：第一部分过一遍 UML 十四种正式图形，外加三种 UML 规范没有但实际很常用的图。第二部分介绍 insight-diagram——一个在 goal.rpcx.io 上发布的 Skill，给任意代码库自动生成全套 UML 图、架构图和流程图。

阅读全文

"The goal isn't a graph that wows you with how complex your codebase is — it's a graph that quietly teaches you how every piece fits together."
目标不是一张让你惊叹「代码库真复杂」的图——是一张默默教你每个部分如何协作的图。

——Yuxiang Lin, Understand-Anything 作者, 2026 年

Skills 拆能力。Spec 写合约。Ralph Loop 循环到对。gstack 角色覆盖。Goal Workflow 串流水线。autoresearch 全自动闭环。官方插件注入领域知识。每一章都在回答同一件事：让 AI 写出更好的代码。

本章不教 AI 写代码——教 AI 读懂已有的代码。

Understand-Anything 是目前「代码理解」方向上最成熟的开源项目：48.4K Stars，15 个 AI Agent 平台支持，最新版本 v2.7.3。作者 Yuxiang Lin。装上之后，Agent 不再靠 grep 和逐文件阅读理解代码库——先查知识图谱。

阅读全文

"The decisive result came not from the model alone, but from the harness around it."
决定成败的不仅是模型本身，更是其配套的外围系统。

——Anthropic Harness Engineering Team

第 2 章讲了 Skills 系统——Matt Pocock 的工程哲学：一个 Markdown 文件定义一种行为，小而可组合。第 6 章讲了 superpowers——社区级 Skills 库，十四个 Skill 覆盖十四个场景。

Anthropic 自己为 Claude Code 开发了 13 个官方插件。截至 2026 年 5 月，全部放在 Claude Code 仓库的 plugins/ 目录下。和社区 Skills 不同，这些插件是 Anthropic 工程师为 Claude Code 构建的第一方工具——通过 /plugin 安装，深度集成到 hooks、agents、skills 三层基础设施中。

安装。 所有 13 个插件通过同一命令安装：

1

/plugin install code-review

/plugin install <name> 从 Anthropic 官方源拉取插件，注册斜杠命令、hooks 和 Agent。/plugin marketplace add 可添加第三方源。安装后插件在 ~/.claude/plugins/ 下，可手动编辑配置。

阅读全文

"Process over prose — workflows over reference."
流程重于文字，工作流重于参考。

——addyosmani/agent-skills README

第 15 章讲 Compound Engineering 让每一轮工作沉淀知识，下一轮起点更高。第 14 章讲 improve 让强模型做审计、弱模型做执行。两章都在回答"怎么让 Agent 做正确的事"。

本章要回答一个更前置的问题：Agent 知道什么是正确的事吗？

回答这个问题的人叫 Addy Osmani。

如果你写过前端，大概率读过他的书。他在 Google Chrome 领导开发者体验工程团队近 14 年，主导了 Chrome DevTools、Lighthouse、PageSpeed Insights、Core Web Vitals 等工具和标准的建设。2026 年转任 Google Cloud AI 总监，负责 Gemini、Vertex AI 和 Agent Development Kit。著有《Learning JavaScript Design Patterns》《Leading Effective Engineering Teams》，博客名篇《The Cost of JavaScript》从 2017 年到 2023 年持续更新了七年，几乎定义了 web 性能优化的讨论框架。他在前端工程和 web 性能领域的影响力，塑造了一整代前端开发者的工程实践。

2026 年初，他的注意力从"人怎么写更好的代码"转向了"AI 怎么写更好的代码"。2 月 15 日，他开源了 agent-skills，定位一句话："Production-grade engineering skills for AI coding agents"——把资深工程师的工作流、质量门禁和最佳实践，编码为 Agent 不可绕过的结构化约束。 到 6 月，近 60K star。

但这不只是又一个爆款开源项目。Osmani 在这个项目里做的事，和他过去十年做的事一模一样：把隐性的工程知识显式化。《Learning JavaScript Design Patterns》是把资深工程师脑子里的设计模式写成可学习的目录。Chrome DevTools 的文档是把调试技巧写成可操作的步骤。agent-skills 是把工程纪律写成 Agent 无法自我说服跳过的约束。

用 AI 写代码的人都会碰到一种熟悉的挫败感。Agent 接到任务，跳过规格直接敲代码。你说"先写测试"，它说"好的"，然后继续敲代码。你说"这里需要安全检查"，它说"明白"，然后加了一行 // TODO: add auth。你说"代码能简化一下吗"，它说"当然"，然后把三个函数合并成一个更长的函数。

Agent 不是不听话。它是真的不知道什么叫"先写测试""安全检查""简化代码"。这些是资深工程师花了好多年才内化的纪律，而 Agent 的默认行为是用最短路径把代码写出来，能跑就行。其他的都不在它的输出分布里。

agent-skills 要反转的就是这件事。它所有的设计决策，从七阶段生命周期到反合理化表到验证门禁，都指向同一个目标：让 Agent 像资深工程师一样工作。不是写代码更快，是不跳过那些让代码值得写的东西。

阅读全文

"Each unit of engineering work should make subsequent units easier — not harder."
每一个工程工作单元都应该让后续单元更容易，而不是更难。

——everyinc/compound-engineering-plugin README

第 14 章讲 improve 把计划当作产品，让强模型做判断、弱模型做执行。省了 token。但还有一个问题没回答：省下来的 token 和时间，有没有让你的下一次工作起点更高？

大部分 AI 编程工具解决的是"这一次"。帮你写代码，跑测试，合 PR。会话结束，上下文消失。下次开新会话，Agent 从零开始重新理解这个项目。构建命令是什么来着？那个奇怪的约定是因为什么历史事故？上次修那个 bug 踩了什么坑？全忘了。Agent 学到的东西，在你关掉终端的那一刻归零。

Compound Engineering 要反转的就是这件事。核心主张不是"让 Agent 这次做得更好"，是"让 Agent 下次起点更高"。每一轮工作结束时，把学到的东西沉淀回知识库，变成下一轮 Agent 启动时自动读到的上下文。用复利的方式做工程。

这个想法来自 Every 公司（Every.to），由 @kieranklaassen 和 @tmchow 维护。他们把这套方法论打包成 compound-engineering-plugin，MIT 开源，GitHub 18.3K+ star，随插件提供 37 个 skills 和 51 个 agents。支持的编码工具覆盖 Claude Code、Cursor、Codex、GitHub Copilot、Factory Droid、Qwen Code、OpenCode、Pi、Gemini、Kiro，几乎你能叫出名字的都在。

阅读全文

"The plan is the product."
计划才是产品。

——shadcn/improve README

shadcn 是谁，不用多介绍。他创建的 shadcn/ui 是 GitHub 上 Star 数最高的 React 组件库之一，11 万+，几乎凭一己之力改变了前端组件库的交付范式——不是"装一个 npm 包"，是"把源码拷进你的项目，你拥有它，你改它，你对它负责"。这种对控制权和所有权的执念，是他所有作品的设计 DNA。

2026 年 6 月，他在这个 DNA 上又加了一层——开源了一个叫 improve 的 Agent Skill。一周之内，5000+ star。

improve 做的事情，说穿了就是一句话：用最贵的模型读代码库、找问题、写执行计划，用最便宜的模型照着计划敲代码。它自己不碰源码，产出只有一种东西——计划。

这个分工背后是一笔所有用 AI 写代码的人都在付、但很少认真算过的账。用 Opus 读代码库、找 bug、排优先级，值。用 Opus 敲每一行代码、跑每一个测试、写每一句 commit message，不值。但现在的 AI 编程工具不管这些——你给它们什么模型，它们就全程用什么模型。预算好的团队手动切模型——研究阶段用 Opus，实现了切 Sonnet，跑测试了再切 Haiku。切来切去，时间都花在模型下拉菜单上了。

improve 把这个手动切换内建成了自动分工：强模型只负责判断。执行扔给最便宜的、够用的模型。

阅读全文