Enivia Google 工程师 Addy Osmani 前天将他在 2025 年 11 月 29 日发布的文章《现代浏览器的工作原理（How modern browsers work）》发到了推特上，意外再度引爆讨论。
看这个标题，感觉自己一秒回到了面试被问“从输入 URL 到页面展示，到底发生了什么？“的时代。
在当下被 AI 生成内容和各种 Agent、Skill 充斥的技术圈，像这样深入底层原理的老派技术文章确实太少见了，反而成了一种稀缺的清醒。
这篇古早味的文章，在今天不仅不过时，反而是定义 Agent 前端开发能力的分水岭。
如果 Agent 不懂浏览器底层的网络栈、渲染机制与合成流程，它永远只能写出看似正确的盲目代码，却永远无法解决真实业务中的顽疾。
原文核心内容
- 浏览器不是黑盒 现代浏览器内部实际上协调了多个子系统，同时处理网络请求、资源加载、HTML/CSS/JS 解析、渲染、GPU 合成、安全沙箱、多进程隔离和开发者工具。
- 页面加载从网络栈开始 用户输入 URL 后，浏览器会做 URL 解析、安全检查、DNS 查询、TCP/TLS 连接、HTTP 请求、重定向处理、MIME 类型判断等。Chromium 中网络通常由独立 Network Service 处理，Renderer 不直接访问网络，这也是安全设计的一部分。
- 浏览器会提前优化资源加载 现代浏览器会使用 preload scanner、HTTP 缓存、DNS prefetch、preconnect、Early Hints、Speculation Rules API、HTTP/2、HTTP/3、资源优先级等机制，让关键资源更早、更快被获取。
- HTML、CSS、JS 会进入解析和构建阶段 HTML 被解析成 DOM，CSS 被解析成 CSSOM，然后浏览器计算每个节点的最终样式。普通 script 会阻塞 HTML 解析，async、defer 和 module script 可以改变阻塞行为。CSS 通常会阻塞首次渲染，因为浏览器要避免先显示未样式化页面。
- 布局、绘制、合成是性能优化的关键 浏览器会根据 DOM 和 CSSOM 构建布局树，计算每个元素的位置和尺寸，然后生成绘制记录。现代浏览器还会把页面拆成多个图层，通过 compositor thread、raster worker、GPU process 等机制完成最终显示。滚动、动画、transform、opacity 等操作之所以可能更流畅，是因为它们可以在合成层面处理，而不必每次都重新布局和重绘。
- JavaScript 引擎负责交互和执行性能 V8 负责解析、编译、执行 JavaScript 和 WebAssembly，并通过 JIT、不同编译层级、内存管理和垃圾回收来提升运行效率。JavaScript 运行在主线程时，可能阻塞渲染、输入响应和动画，所以长任务、频繁 DOM 操作、低效循环、过度同步计算都会影响页面流畅度。
- 多进程架构是性能和安全的基础 现代浏览器通常把浏览器 UI、不同网站内容、GPU、网络、扩展、插件或媒体处理放到不同进程中。这样做有三个目的：安全隔离、性能隔离、内存隔离。Chrome 从早期的每标签页进程，演进到更严格的 Site Isolation，不同站点和跨站 iframe 可能运行在不同渲染进程中。
如何利用这些基础知识？
过去很多 AI 或 Agent 工具的问题在于，它们主要基于源码进行推理。
AI 能通过代码看到组件、样式、接口调用、构建配置，却看不到浏览器内部真实发生了什么。
一个按钮点不了，可能是事件没绑定、元素被遮挡、hydration 出错，也可能是 CSS stacking context、z-index、pointer-events、异步脚本加载顺序或网络请求失败等等。
只读代码，Agent 很容易给出看起来合理的解释，但却无法必命中真实问题。
Addy 这篇文章看似在介绍一个可能 AI 时代可能不需要接触到的底层知识，但实际对于 Agent 开发过程很有用。
浏览器不是黑盒
浏览器就是 Agent 必须理解的一套运行系统：网络、解析、样式计算、布局、绘制、合成、JS 执行、安全隔离和 DevTools。
Agent 若要真正参与开发，就不能只会修改 React 组件或生成 CSS，它还需要能进入浏览器现场，观察 DOM、CSSOM、Console、Network、Performance trace 和渲染路径。这也解释了为什么浏览器会成为 AI Agent 的关键工作环境。
一个成熟的开发 Agent 应该具备闭环能力：先根据需求改代码，再打开真实页面，观察控制台错误，检查网络请求，定位 DOM 状态，读取 computed style，分析 layout 和 paint 成本，最后验证修复是否有效。
它的工作方式不应是“一次性生成答案”，而应是“生成，运行，观察，修正，再验证”。
举个例子，关于常见的首屏加载速度慢的问题，AI 就不能只提出压缩 bundle 这种泛化建议。
Agent 应该检查关键资源加载顺序，确认 CSS 是否阻塞渲染，查看图片和字体是否抢占带宽，判断是否需要 preload、fetchpriority、代码拆分或 Early Hints。动画卡顿也不能只说“用 transform 替代 top left”，而要看是否触发布局、是否频繁读取布局信息、是否造成 layout thrashing、是否有过多合成层导致内存压力。
总结一下
浏览器知识会成为 Agent 前端开发能力的分水岭。
低阶 Agent 只会写代码，高阶 Agent 会理解代码进入浏览器后的生命周期。
它知道普通 script 为什么阻塞解析，知道 CSS 为什么影响首次渲染，知道 DOM 改动可能触发 style recalculation、layout、paint 和 composite，知道某些动画可以交给 compositor，知道 Network 面板里的失败请求比源码猜测更可靠。
未来的前端开发经验总结，应该着力于人如何训练 Agent 使用浏览器。
开发者要给 Agent 明确的观察目标和验收条件，比如“修复后 Console 无错误”，“登录接口返回 200 且页面跳转成功”，“LCP 降到 2.5 秒以内”，“点击按钮后 DOM 状态变化符合预期”这类确切的，可以通过浏览器确认的目标。浏览器不只是页面预览器，而是 Agent 的反馈系统。
谁能让 Agent 更好地利用浏览器，谁就能把 AI 前端编程从代码生成推进到真正的工程化验证。
