猿来如此

Graph Engineering，白话说就是“执行图工程”：把多个 Agent、普通函数、工具和人工检查点，组织成一张可执行、可恢复、可观察的工作图。它解决的不是“怎样再加一个 Agent”，而是谁先做、结果交给谁、失败退回哪里，以及什么时候必须停下来等人。本文会用一张假设的内容生产图讲清它的五个部分、六类风险，以及哪些任务根本不该用 Graph。 设想一个团队已经有调研 Agent、写作 Agent 和审核 Agent：三个执行者都会干活，但仍要有人复制上一步的结果，决定下一个调谁，失败后再凭经验判断重跑哪段。表面上自动化了三个动作，实际上只是多了三个需要人工盯着的执行者。问题不一定是 Agent 不够聪明，而是协作关系还藏在聊天记录、Prompt 和操作人的脑子里。

大家盯着 Gemini 3.5 Pro 等了半天，Google 先端上来的却是 Gemini 3.6 Flash 和 Gemini 3.5 Flash-Lite。先把最容易传歪的地方说清楚：3.5 Pro 没有取消，Google 的官方说法仍是“正在与合作伙伴测试”，只是没有公布新的开放日期。 真正值得追新的，不是型号又多了两个，而是 Google 把高频 AI 工作拆成了两层：3.6 Flash 是更高效的主力工作层，负责复杂编码、多步骤 Agent、多模态理解和界面操作；3.5 Flash-Lite 是低成本、高吞吐的执行层，适合分类、抽取、翻译、路由和大批量文档处理。一个处理不确定性，一个处理规模，这比争论“Flash 能不能代替 Pro”更接近真实工作。

GPT‑Live厉害的，不是嗓子像人，而是AI边说边听，能被打断。它让语音助手从“对讲机”变成“电话”，可自然不等于可靠。截至7月16日，API未开放，旧Realtime案例不是新模型成绩。客服要用，补确认、接管和回滚。

Google I/O 2026 上，Chrome 团队推了一个很容易被低估的新 Web 平台特性：HTML-in-Canvas。 很多人第一眼看到这个名字，脑子里会冒出一句话：哦，不就是终于可以在 canvas 里写 HTML 了吗？ 这理解不能说错，但太浅了。 HTML-in-Canvas 真正重要的地方，不是“Canvas 能不能塞一个 div”。它动的是前端一条存在了很多年的边界：DOM 负责语义、交互和浏览器能力，Canvas / WebGL / WebGPU 负责像素、图形和 GPU 管线。过去这两套世界像两个国家，边境线画得很硬。你要 DOM 的可访问性、复制、查找、翻译、表单和 DevTools，就老老实实待在 DOM 里。你要 shader、3D、游戏、复杂画布和极致视觉控制，就进 canvas，但很多浏览器能力要自己重造，或者直接放弃。 HTML-in-Canvas 的变化是：浏览器开始给这两个国家修桥。 说白了，它不是让 Canvas 变成 DOM，也不是让 DOM 消失。它更像是让真实 DOM 变成图形管线的一种输入。 这就有意思了。 先说它到底是什么 按 Chrome 官方介绍，HTML-in-Canvas 是一个实验性 API，目前已经进入 origin trial。它允许你把 DOM 内容直接绘制进 2D canvas，或者作为 WebGL / WebGPU texture 使用，同时保留交互、可访问性和浏览器内建能力。 人话版是： 你可以写一个真实的 HTML 组件，比如一个表单、一段富文本、一个设置面板、一个复杂卡片。它不是截图，不是手搓像素，不是用 JS 模拟 CSS。它仍然是 DOM。然后你可以把这个 DOM 的渲染结果画进 canvas，甚至贴到一个 3D 物体表面上。 更关键的是，它还尽量保留浏览器能力。 文本可以被选中，内容可以被复制，页面查找能找到，屏幕阅读器能读，浏览器翻译能处理，DevTools 能检查，扩展也可能继续工作。 以前 canvas 应用最尴尬的地方就在这里：画面看起来很高级，但对浏览器来说经常只是一张大图。用户看到的是文字，浏览器看到的是像素。用户以为这是界面，辅助技术可能只看到一块空白。 这就像你开了一家装修很豪华的店，但门口没有门牌，消防图也没有，导盲系统也进不去。普通人看着炫，真到基础能力上，全是坑。 HTML-in-Canvas 要补的，就是这个坑。 过去为什么这么难？ 前端一直有两套 UI 世界。 第一套是 DOM 世界。 DOM 的好处不是“能写 div”这么简单。它真正值钱的是浏览器几十年积累下来的能力：文本布局、换行、国际化、双向文字、表单控件、焦点管理、选择复制、右键菜单、无障碍树、页面查找、浏览器翻译、自动填充、缩放、暗色模式、扩展、DevTools。 这些东西你平时不觉得牛，是因为浏览器替你兜底太久了。 第二套是 Canvas / WebGL / WebGPU 世界。 它的好处也很明显：你可以直接控制像素，进 GPU，做 3D，跑 shader，做游戏，做白板，做设计工具，做复杂可视化。Figma、Miro、Google Docs 这类复杂应用，很多地方都离不开这种底层图形能力。 问题是，这两套世界以前很难同时拿。 你用 DOM，就很难把一个真实按钮贴到 3D 模型上，然后让它被玻璃折射、被 shader 扭曲、跟着模型旋转。 你用 Canvas，就要开始重造很多浏览器已经做好的东西。比如文本换行、光标、输入框、复制粘贴、焦点、可访问性。重造到最后，你会怀疑人生：我不是做一个 3D 面板吗，怎么突然在写半个浏览器？ 这就是 HTML-in-Canvas 的背景。 大多数人以为前端缺的是更炫的渲染 API。但真相是，前端真正缺的是一条能把“语义 UI”和“图形管线”接起来的路。 它怎么工作？ HTML-in-Canvas 的核心设计可以拆成几个部分。 第一，在 <canvas> 上加 layoutsubtree。 这一步的意思是：让 canvas 里面的子元素参与布局和 hit testing。也就是说，你可以把 DOM 子节点放到 canvas 里，它们会像真实 DOM 一样被浏览器布局、参与可访问性和交互计算。但它们不会自动显示出来。想显示，必须显式绘制。 第二，用 drawElementImage() 把 DOM 画进 2D canvas。 比如你有一个 <div>，里面是文本、按钮、输入框、CSS 样式。你在 canvas 的 paint event 里调用 ctx.drawElementImage(element, x, y)，浏览器就会把这个元素的渲染结果画到 canvas 上。 第三，如果你在 WebGL 里，可以用 texElementImage2D；如果在 WebGPU 里，可以用 copyElementImageToTexture。 这一步才是很多 3D 开发者眼睛一亮的地方。因为 HTML 不只是画到 2D canvas，它还可以成为 texture。texture 意味着它可以贴到 3D 物体上，可以进 shader，可以被 post-processing 处理，可以成为沉浸式场景的一部分。 第四，要同步 transform。 这是最容易被忽略、但最关键的一步。 你看到的 HTML 已经被画到 canvas 里了，但真实 DOM 仍然要知道自己“在屏幕的哪里”。不然用户点击画面上的按钮，浏览器不知道该把这个点击交给哪个真实 DOM 元素；屏幕阅读器、hover、focus、选中文本也会错位。 所以 drawElementImage() 会返回一个 transform。你要把这个 transform 应用到元素的 CSS transform 上。3D 场景里则可以用 getElementTransform() 辅助计算。说白了，视觉位置和真实 DOM 位置必须对齐。 这也是为什么它不是“截一张图塞进 canvas”。截图不会有焦点，不会有输入，不会有可访问性，不会有浏览器查找。HTML-in-Canvas 玩的是活的 DOM。 这和 html2canvas 有什么区别？ 很多人会问：这不就是官方版 html2canvas 吗？ 不是。 html2canvas 文档自己说得很清楚，它会遍历 DOM，读取元素信息，然后构建一个页面表示。它不是浏览器截图。它能画对多少，取决于它理解多少 CSS、多少布局细节、多少边界情况。 这就像你照着网页临摹一幅画。画得再像，也还是临摹。 HTML-in-Canvas 更接近浏览器自己把那层真实 HTML 渲染结果交给你当素材。它不是第三方库猜浏览器怎么画，而是浏览器平台提供“把 DOM 绘制进 canvas / texture”的能力。 还有一种老办法是 DOM overlay。 比如你在 WebGL canvas 上面盖一个绝对定位的 div，看起来像在 3D 场景里。但它本质上是贴在画面外面的透明贴纸。它可以交互，但它没有真正进入 3D 管线。它不能自然被 shader 处理，不能真实贴在一个旋转的 3D 屏幕上，也很难和复杂后处理融在一起。 DOM overlay 像把字幕贴在电视屏幕外面。 HTML-in-Canvas 是把字幕送进画面信号里。 差别就在这。 它带来的第一个变化：Canvas 应用不用再那么“装瞎” Canvas 应用有个老问题：用户看得到，浏览器看不懂。 你在 canvas 里画了一个图表，用户看到坐标轴、图例、tooltip、按钮。但对浏览器来说，那可能就是一堆像素。你要想支持无障碍、搜索、复制、翻译、右键、自动填充，就得自己额外维护一套 fallback DOM 或自定义逻辑。 很多团队不是不知道该做，而是成本太高。 结果就是大量 canvas 应用变成“视觉上很强，浏览器能力很弱”。尤其是复杂白板、设计工具、图表工具、游戏 UI、3D 场景，一旦进入 canvas，很多普通网页里默认免费的能力突然都变成工程债。 HTML-in-Canvas 的价值，是让真实 DOM 可以继续存在于浏览器语义系统里，同时又能被画进 canvas。 这对大型 canvas-based 应用很重要。比如官方提到 Google Docs、Miro、Figma 这类重量级 Web 应用。它们不一定会马上把所有 UI 改掉，但某些复杂组件、嵌入式面板、文本区域、可访问内容，未来有机会少写很多自研逻辑。 你以为这只是省几行代码。 不，这是把“可访问性”和“浏览器能力”从补丁变回地基。 第二个变化：3D 和 WebXR 终于能吃上真实 Web UI 做过 WebGL / Three.js / WebXR 的人都知道，3D 里的 UI 很折磨。 你想在 3D 场景里的一个电脑屏幕上放一个网页界面。简单做法是贴一张图片，不能交互。高级一点，用 canvas texture，自己画内容。再高级，用 DOM overlay，让一个 HTML 面板跟着 3D 位置走。但它经常有遮挡、透视、事件、深度关系和真实嵌入感的问题。 所以很多 3D UI 最后都变成手搓。 按钮自己画，输入框自己写，布局自己算，hover 自己做，focus 自己接，事件自己 raycast。写着写着，你不是在做产品，你是在复刻浏览器。 HTML-in-Canvas 的想象空间就在这里：你可以用 HTML / CSS 写 UI，再把它作为 texture 放进 3D 场景。 Three.js r184 已经加了 HTMLTexture。PlayCanvas 也有 HTML-in-Canvas 文档，讲如何把 live HTML / CSS 渲染成 WebGL texture，并保留 hit testing、focus 和 accessibility。 这说明生态已经开始接线了。 对游戏、WebXR、沉浸式官网、3D 产品展示来说，这不是小改动。以前你要在“网页 UI 的成熟能力”和“3D 世界的真实嵌入感”之间选一个。现在至少有机会两个都要。 当然，别激动过头。 3D transform、hit testing、texture 更新、fallback、浏览器兼容，还是工程活。HTML-in-Canvas 不是仙丹，它只是把最底层那堵墙打开了一扇门。 门开了，不等于路铺好了。 第三个变化：AI Agent 更容易读懂“视觉应用” 这个点很多人会忽略，但我觉得很关键。 Google 在 I/O 2026 的语境里，不只是讲 Web UI，还在讲 agentic web。HTML-in-Canvas 官方介绍里也提到，内容如果仍然是 DOM，爬虫和 AI agent 可以更容易索引和读取 2D / 3D 场景里的文本。 这句话背后其实很重。 AI agent 要操作网页，最怕什么？怕界面只有像素，没有语义。 如果一个按钮只是 canvas 上的一块蓝色矩形，agent 要理解它，只能靠视觉识别、坐标推断、截图 OCR。能做，但脆。像让人隔着毛玻璃修电路。 如果那个按钮背后仍是 DOM，里面有真实文本、真实 role、真实 input、真实 form、真实可访问性信息，那 agent 操作它就稳定得多。 这也是为什么我说 HTML-in-Canvas 不是单纯视觉特性。它和 AI 原生 Web 是有关系的。未来的 UI 可能既要被人看，也要被 agent 读；既要能进 GPU 管线，也要保留语义；既要炫，也要能被浏览器工具理解。 很多人以为 AI 时代的 UI 会变成一堆生成出来的炫酷画面。 但真相是，AI 时代更需要结构化 UI。 没有结构，agent 就只能猜。猜得越多，系统越不可靠。 第四个变化：前端分工会重新洗牌 过去前端经常有一种隐形分工： 做业务页面的人在 DOM / CSS / React 里打转。 做创意视觉、游戏、3D、白板、设计工具的人在 Canvas / WebGL / WebGPU 里打转。 两边互相看不上也互相羡慕。DOM 这边觉得 canvas 那边炫但不好维护；canvas 那边觉得 DOM 这边啰嗦但能力成熟。 HTML-in-Canvas 会让这个分界变薄。 未来一个前端工程师可能不能只懂“组件怎么写”，也不能只懂“shader 怎么跑”。更值钱的是你能不能理解 UI 的三层： 语义层：这个界面对用户、浏览器、辅助技术、agent 来说是什么。 交互层：用户如何点击、输入、选中、复制、聚焦。 图形层：它如何被绘制、变形、合成、进入 2D / 3D / GPU 管线。 以前这三层经常绑在一起。DOM 页面三层都交给浏览器。Canvas 应用三层很多要自己写。 HTML-in-Canvas 的意义，是让这三层有机会重新组合。 这才是真正的变化。 但现在别把它吹成生产神技 这里要泼一盆冷水。 HTML-in-Canvas 现在还很早。 Chrome 官方写得很清楚，Chrome 148 到 150 是 origin trial。要本地测试，需要 Chrome Canary 149+，还要打开 chrome://flags/#canvas-draw-element。WICG explainer 也还在持续更新。TAG、Mozilla、WebKit 的相关讨论还没完全收束。 所以别看几个 demo 很炸，就开始喊“前端未来已来，马上重构所有项目”。 这事儿没那么简单。 第一，浏览器兼容是现实问题。你不能指望所有用户立刻支持。 第二，性能不是白送的。HTML-in-Canvas 通过 JS 驱动绘制，滚动、动画、频繁 texture 更新都要评估。把一大坨复杂 DOM 塞进 canvas，不会自动变快。 第三，安全和隐私有限制。跨源 iframe、跨源资源、用户敏感状态，不可能让你随便画进 canvas 再读像素。 第四，工程复杂度还在。特别是 3D 场景里的 transform 同步，想做得稳定，需要框架和引擎继续封装。 所以正确姿势是什么？ 如果你是普通业务前端，现在不用焦虑，也不用为了跟风硬学。 如果你做 3D、游戏、WebXR、数据可视化、白板、设计工具、富文档编辑器，建议第一时间跟踪。不是马上上生产，而是做 demo、测边界、看生态封装。 如果你在做 AI 生成 UI 或 agent 可操作界面，那更要关注。因为这类技术会影响未来“界面如何既给人看，也给机器读”。 我真正看重的是什么 我看重的不是 API 名字。 前端这几年不缺新 API。很多 API 出来，热闹两天，然后消失在兼容性、复杂度和真实需求里。 HTML-in-Canvas 真正值得看的，是它背后的方向：浏览器正在承认，Web App 已经不是传统文档页面了。 现在的 Web 上有设计工具、视频编辑器、3D 展厅、AI coding IDE、白板、游戏、数据大屏、沉浸式课程、agent 操作界面。它们既需要 DOM 的语义和浏览器能力，也需要 GPU 的图形能力。 过去我们总在两边来回横跳。 要么在 DOM 里装作自己是原生应用。 要么在 canvas 里装作自己是浏览器。 HTML-in-Canvas 的出现，说明平台层开始补这块拼图。 这才是变革。 不是“Canvas 可以写 HTML 了”。 而是 Web UI 终于开始从二维页面，走向一个更混合的渲染模型：语义是语义，交互是交互，图形是图形，它们可以被组合，而不是被迫绑定在一套技术里。 最后说句实话 很多技术热点都喜欢用一句话把人骗进去： “这会改变前端。” 大多数时候，这句话是空的。因为真正改变前端的，不是某个 API 多酷，而是它有没有改变开发者做选择的方式。 HTML-in-Canvas 这次有这个苗头。 以前你的选择是：要 DOM，还是要 Canvas？ 以后可能变成：哪一层用 DOM，哪一层进 Canvas，哪一层交给 GPU，哪一层保留给浏览器和 AI agent？ 这就是从“选阵营”变成“做架构”。 对普通人来说，这不是明天就能变现的新技能。 但对前端开发者来说，这是一个非常好的信号：浏览器平台还在进化，而且进化方向不是让你背更多黑话，而是把过去那些别扭的边界慢慢拆掉。 说白了，HTML-in-Canvas 不是终点。 它只是告诉你：Web UI 的墙，已经开始松了。 墙一松，新的东西就会长出来。