前端变天了?20年前端老兵眼中的前端技术演进与AI革命

图片

图片

👉目录

1 序言

2 前端的“青铜时代”:标准缺失与浏览器兼容性噩梦

3 黄金十年的技术跃迁

4 AI时代前端的机遇与变革

5 砥砺前行:前端生态的无限可能

从IE6的“兼容性噩梦”到AI驱动的智能开发,前端技术二十年间完成了史诗级进化。AI技术革命不仅改变了开发方式,更重新定义了前端的可能性。未来,人与AI如何协作?前端又将走向何方?让我们回溯历程,展望未来。

关注腾讯云开发者,一手技术干货提前解锁👇

01

序言

我在 2000 年前后接触到互联网,它像一扇突然打开的新世界大门。那种知识平权的感受给我带来了极大的震撼,也让我对 Web 产生了浓厚的兴趣。而后在 2005 年左右,我开始系统的学习 Web 开发。作为一名前端开发的老兵,我有幸见证了前端技术从“刀耕火种”到“智能时代”的完整演进历程。近二十年来,前端技术发生了翻天覆地的变化。特别是近两年,AI 技术的突飞猛进,正在以前所未有的速度重塑我们的工作方式。当年用四张背景图拼圆角的执着,如今成了向 AI 描述“帮我生成一个毛玻璃效果” 的轻松。技术代际的跨越,总让老开发者有种时空错位的恍惚。这种对比不禁让人感慨万千,就好比蒸汽火车司机开上了高铁,虽然不用再铲煤了,但咱也得学会跟自动驾驶系统打交道。

那么,AI 究竟给前端开发领域带来了哪些挑战和机遇呢?在这篇文章中,我将结合自身的亲身经历,对前端技术的发展脉络进行回顾与梳理,探讨并分享我对这一问题的一些思考与见解。

02

前端的“青铜时代”:标准缺失与浏览器兼容性噩梦

2005 年前后的前端开发环境,用“混乱”二字形容毫不为过。当时 IE6 占据着超过 90% 的浏览器市场份额, Firefox 刚刚崭露头角,Chrome 还未诞生。这种一家独大的市场格局导致开发者不得不围绕 IE6 的特性进行开发,可 IE6 对 W3C 标准的支持度极低,这为前端开发埋下了无数隐患。

除了上文提到的圆角问题,还有令人抓狂的 IE6 的 PNG 透明问题——它无法正确渲染 32 位带 Alpha 通道的 PNG 图片,要使用微软专有的 AlphaImageLoader 滤镜来“曲线救国”。

那时候布局也是个大问题,IE 的 hasLayout 机制导致 inline-block 行为异常,只能依靠 float 来模拟行内块级元素,浮动布局是那个时代唯一能实现复杂布局的布局方式。而浮动又带来了脱离文档流的副作用,还需要通过“清除浮动”进行修复。一个简单的三栏布局(圣杯和双飞翼),往往要写几十行 CSS,还要为不同浏览器准备不同的 hack 代码。

事件处理是另一个重灾区。IE 使用 attachEvent ,而其他浏览器使用 addEventListener;获取事件对象在 IE 中是通过 window.event ,而标准浏览器则是作为参数传递。这些差异使我们不得不编写大量的浏览器兼容代码和条件分支,一个简单的事件委托实现往往要写上几十行。

当时的开发工具也极其简陋。没有 Chrome,更不用提 DevTools 了。Firebug 的出现已经是 2006 年之后的事了,在相当长的时间内,我们调试 JavaScript 主要靠 alert,调试 CSS 则要反复修改、刷新页面。没有源代码映射,没有实时重载,更没有现在习以为常的组件热更新。

Windows XP 在国内的普及程度极高,叠加盗版泛滥等因素,导致其内置的 IE6 浏览器在国内的使用时间远超预期,甚至在微软官方停止支持后仍“超期服役”。这一现象迟滞了国内前端技术进步,大幅增加了开发成本,造成了诸多用户体验与安全问题,形成了明显“技术代差”,直到移动互联网时代才得以缓解。国内前端开发者相较国外同行被 IE6 多“摧残”了很多年。

03

黄金十年的技术跃迁

   3.1 HTML5的革命性影响


H5 本是 HTML5 的缩写,可你知道移动 Web 为什么也会被称为 H5 吗?

2010 年代初期,HTML5 的横空出世彻底改变了 Web 开发的格局。HTML5 的影响远远超出 HTML 标准本身,它不仅解决了一批长期困扰开发者的问题,更成为推动移动互联网爆发的关键引擎。

HTML5 带来了一系列革命性特性:原生多媒体(video/audio)支持让网页告别了 Flash 插件,Canvas 开创了网页图形新纪元,本地存储实现了离线应用的可能,语义化标签让代码结构更加清晰,设备 API 则打通了网页与硬件的连接通道……这些特性共同掀起了一场 Web 技术的范式革命。

HTML5 标准虽然在 2014 年才正式定稿,但它的很多早期特性在标准定稿前就已被浏览器部分支持。

另一方面,这场革命适逢智能手机普及的关键时期,移动浏览器对 HTML5 新特性的支持度远超 PC 浏览器,微信生态的爆发更是让 HTML5 页面成为移动营销标配。

结合上述特性和时代背景,HTML5 名正言顺成为移动互联网的基石技术,以至于“H5”这个 HTML5 的简称在很多场景下直接成了 “移动 Web”的代名词,直到今天。从技术标准到行业术语的转变,正是 HTML5 深远影响力的最佳印证。

   3.2 CSS3带来的设计革命


CSS3 的横空出世彻底解放了前端开发者的设计桎梏。曾经需要复杂切图的圆角效果,如今只需一行 border-radius 即可实现;盒阴影和渐变背景不再依赖图片资源,通过 CSS 代码就能轻松搞定。更令人振奋的是,动画效果不再完全依赖 JavaScript —— transition 和 animation 属性让流畅的交互效果变得触手可及。

Flexbox 和 Grid 布局系统的出现,则从根本上改变了页面的排版方式。这些新技术让响应式设计从理论变为现实,对后来的移动互联网时代产生了深远影响。我们也终于可以告别浮动布局的“清除浮动”噩梦,用更直观的方式构建适应各种设备的页面结构。

   3.3 JavaScript的现代化演进


ES6 标准的发布堪称 JavaScript 发展史上的里程碑。类语法、模块化、箭头函数等新特性,让这门原本被视为“玩具”的语言焕发新生。TypeScript 强大的类型系统将 JavaScript 的开发体验提升到全新高度。

这些变革不仅提升了代码质量,更重塑了开发者的编程思维。现代 JavaScript 已经完全可以胜任大型复杂应用的开发,这在十几年前是难以想象的。

   3.4 Node.js与全栈革命


Node.js 的出现让 JavaScript 突破了浏览器的限制。它基于谷歌的 V8 引擎,采用非阻塞 I/O 模型,使得 JavaScript 也能高效地运行在服务器端。它还实现了一个重大突破:使用同一种语言编写前后端代码成为现实。

Node.js 的意义远不止于此,它彻底改变了前端开发的工具链。现在我们常用的构建工具如 Webpack、Rollup、Vite 等,都是运行在 Node.js 环境下的。我们平时使用的开发服务器,也大多基于 Node.js 搭建。

npm 包管理器的快速发展为这一变革提供了强大支持。现在有数百万个现成的模块可以直接使用,开发者不需要重复造轮子,可以像搭积木一样快速构建应用,大大提高了开发效率。

   3.5 工程化工具的成熟


前端工程化工具的发展让开发变得更高效。以前需要手动处理的模块打包、代码转换等工作,现在通过 Vite、 Webpack、Babel 这些工具就能自动完成。特别是热更新功能,修改代码后页面会自动刷新,省去了手动刷新的麻烦。

这些工具不仅提高了个人开发效率,也让团队协作更加顺畅。统一的工程化配置让多人合作开发大型项目变得更加容易管理。

   3.6 前端框架的范式转移


过去用 jQuery/JavaScript 直接操作 DOM 的方式,在开发复杂应用时越来越难以维护。React、Vue这些现代框架采用了组件化开发的思想,让开发者可以更专注于业务逻辑。虚拟 DOM 技术也让页面渲染更加高效。

为了解决组件之间的数据共享问题,Redux、Vuex等状态管理工具应运而生。它们让大型应用的状态管理变得井井有条。

   3.7 移动互联网的冲击


智能手机普及后,前端开发也发生了很大变化。响应式设计让网页能自动适应不同尺寸的屏幕;React Native、Weex 这样的框架让前端开发者也能开发原生 App;小程序则开创了新的应用形式。2015 年移动页面流量首超 PC。

这些新技术不仅拓展了前端开发的应用范围,也改变了开发者的工作方式。现在做前端开发,必须要考虑移动端适配和跨平台方案。

这一时期,微前端、低代码、Serverless 等技术也在前端领域崭露头角。

这些技术积累为 AI 时代的质变奠定了基础。

2005 - 2024 前端领域关键技术事件时间轴

04

AI时代前端的机遇与变革

与近两年 AI 技术的爆发式发展相比,上面提到的这些变迁和演进都是“弟弟”,我们可能正在经历这个行业最具颠覆性的变革。

2018 年,当我第一次体验 VS Code 的 IntelliSense 代码补全功能时,那种“智能提示”的体验已经让我眼前一亮。但谁能想到,短短几年后,GPT 的横空出世彻底颠覆了我们对“智能辅助”的认知边界。如今,Cursor/Trae/Zed 等智能 IDE,V0/Bolt 等 AI 代码生成工具、GitHub Copilot 等 AI 编程助手早已超越了简单的语法补全,它们能够真正理解开发者的编程意图,自动生成完整的业务逻辑代码。GitHub 的调研显示,97% 的开发者已经在工作中使用 AI 编程工具,且 AI 在提高代码质量、生成测试用例等方面效果显著[1]。在我的日常开发中,AI 工具已经能高效处理超过 30% 的常规编码任务。在状态管理、表单验证、生成文档、生成类型、单元测试等模式化场景中,AI 的表现甚至超越了大多数初级开发者。上周我用 AI 生成了一个复杂的状态管理模块,结果生成的代码不仅结构清晰,还自动考虑了性能优化和异常处理。

根据 METR 研究,AI 在 2 小时内的编程任务中表现优于人类专家,甚至在某些任务中,AI 的解决方案比人类专家更优。

现在的 AI 工具已经不只是简单的代码补全了,它们正在变成真正的开发助手。比如 Cursor 这样的智能编辑器,不仅能看懂项目结构,还能实时查看运行日志。当代码报错时,AI 不仅能找到错误位置,还能分析出错原因,给出具体的修改建议。重构代码时,它能发现代码中的问题,告诉你该怎么优化。就连代码审查这种需要经验的工作,AI 也能给出不错的改进意见。Vercel 的 V0 平台甚至能实现从需求描述到部署的全流程自动化。这些功能覆盖了整个开发流程,帮我们省去了很多重复性的工作,让我们能把更多精力放在真正需要思考的地方。

最近经常有人问我:“AI 这么厉害,前端开发是不是要被取代了?”作为一名前端老兵,就这个问题,我也来谈谈自己的看法。

一方面,AI 对前端某些细分领域的冲击非常明显,比如低代码开发。我认为原因有三:

  1. 低代码聚焦的本来就是那些重复性高、标准化程度高的业务场景,像表单、流程、报表、看板这类应用。它的核心就是把业务需求转化为可视化配置,而这种高度结构化的开发模式正是 AI 所擅长的。

  2. 传统低代码平台的一大痛点就是不够智能,现在 AI 正好补上了这块短板。

  3. 低代码技术架构本身就将传统前端开发里的状态管理、性能优化等复杂问题封装成了标准化模块,让 AI 吃上了现成的。

现在的情况是,低代码平台传统那套打法可能已经玩不转了。像 V0、Bolt 这些新一代 AI 开发平台正在改变游戏规则。以前需要拖拽配置的工作,现在用自然语言描述就能自动生成,效率提升了不止一个量级。

另一方面,现代前端开发的范畴很广,并非所有的前端细分领域受 AI 影响都像低代码那么大,特别是一些高阶技术领域,AI 的作用更多的是赋能而非替代。即便对于低代码平台来说,也不会简单的被 AI 取代,而是在 AI 加持下转型升级,以更智能的方式实现突破。

我认为甚嚣尘上的“前端消失论”存在严重认知偏差,它忽视了前端开发中最核心的价值——对用户体验的深刻理解和提出创造性解决方案的能力。

这些论调往往暴露了其对现代前端开发的认知局限或断层——将基础的页面搭建工作简单的等同于前端开发的全部,却忽视了前端领域在经历二三十年发展数次跃迁之后作为数字体验核心载体的技术纵深。

不可否认,AI 确实能高效处理不少重复性工作(如基础代码生成、布局调整等),但其局限性也同样明显:

  • 准确性问题。AI 的“幻觉”等问题对生成文章/PRD等创意型内容时影响较小,但对代码生成的影响可能就是致命的了。错误的代码可能引发连锁问题,调试纠错成本比文本修正可大多了。

  • 认知盲区。AI 缺乏对业务背景、技术债务和团队协作规范的了解,知识更新也滞后于前端技术的快速迭代。

  • 环境适配难点。前端开发相较于其他研发领域有个比较大的差异点就是前端代码运行在用户的客户端环境中,开发者不可控。因此前端开发中常需要考虑各种运行时的用户差异/环境差异/基础设施依赖/安全边界等问题,而这些常被 AI 忽视。

  • 上下文局限问题。Token 限制等因素导致 AI 的上下文理解存在碎片化问题,对复杂业务流的理解更是支离破碎。

  • 创新不足。 AI 的解决方案更趋于套路化模式化,针对一些非常规问题,很少能给出一些令人眼前一亮的创新方案。

根据 2024 年 Gartner 报告显示,虽然基础页面搭建工作的自动化率已达 70%,但用户体验设计、复杂状态管理等高阶任务的 AI 辅助率仍低于 20%。现实情况是,AI 正在重构而非消除前端开发的技术门槛,它把技术栈的难度曲线整体下移:

  • 原本需要手动完成的那些基础性/重复性/模式化的工作,现在借助 AI 基本能实现自动化。

  • 中等复杂度的任务,通过 AI 辅助能够实现半自动化,开发者只需要进行部分调整和优化。

  • 以往只有资深开发者才能涉足的高阶技术领域,现在因为 AI 的助力,变得更易触及了。

所以,我觉得 AI 带来的最大惊喜不是那些自动化功能,而是让更多开发者有机会接触那些曾经遥不可及的高端技术。

以前想玩转 WebAssembly 或者 WebGL?没几年功力根本不敢碰。现在不一样了,有了 AI 这个“外挂”,普通开发者也能尝试这些前沿技术。就像当年照相机让普通人也能“画画”一样,AI 正在让更多人有能力实现自己的创意。创新的可能性变多了。AI 没有抢走我们的饭碗,反而给我们打开了新世界的大门。

WebAssembly

WebAssembly 就像是给网页装上了涡轮增压引擎。这个神奇的二进制格式能让浏览器以接近原生应用的速度运行复杂程序,彻底打破了 JavaScript 的性能天花板。

WebAssembly(WASM)是面向 Web 的二进制格式,2017 年起主流浏览器逐步支持。它能把 C/C++、Rust 等编译为字节码,通过堆栈虚拟机在沙箱内执行,启动快、体积小、速度近原生。模块支持导入导出函数和线性内存,可与 JavaScript 互调共享数据。已广泛用于图形渲染、音视频编解码、在线 IDE、云游戏等应用场景。

Photoshop 网页版通过 WebAssembly 将桌面版 C++ 代码库直接移植到 Web 端,避免重写核心逻辑,大幅降低开发成本,向用户提供轻量化、无需安装的云端设计工具。

过去的 Figma 使用 Asm.js 来加快文件读取速度,现在改用 WebAssembly 技术后,这套多功能 UI 设计工具的运行速度又再飙升 3 倍。

知名游戏引擎 Egret Engine 利用 WebAssembly,可以将 HTML 5 代码编译为机器码运行,让游戏运行性能提升 300%。

Autodesk & Blender 通过 WebAssembly 将桌面级CAD/3D工具(如Blender)移植到浏览器,提供高性能在线建模和渲染能力。

在边缘计算场景中,Rust 编译的 WASM 模块使机器学习推理速度提升 10 倍。

……

这些曾被认为不可能的任务,现在都因 WebAssembly 成为现实。特别是在处理海量数据计算、实时图像处理等“重活”时,WebAssembly 的表现堪比专业桌面软件。不过要想驾驭这只“性能野兽”,需要先掌握:系统级语言基础、内存管理诀窍、指针操作技巧……这对传统前端开发者来说挑战很大。好在 AI 助手的出现,让这些门槛不再高不可攀。

几年前,我在开发一个大数据表格组件时,尝试用 WebAssembly 实现实时数字盲水印功能。那时候对 C++ 和指针操作一知半解,光是配置 Emscripten 编译环境就折腾了好几天。调试更是痛苦,经常因为内存访问越界导致整个页面崩溃,却找不到问题出在哪里。要是当时有 AI 工具帮忙解释编译错误、优化内存管理,至少能省下一半的开发时间。

可以预见的是,随着 WebAssembly 2.0 和 WASI 的完善,在 AI 助力下浏览器将逐步取代部分原生开发场景。

WebGL/WebGPU

WebGL 和 WebGPU 技术让网页拥有了强大的 3D 图形处理能力,就像给浏览器装上了专业显卡,实现硬件级加速。这项技术正在彻底改变网页内容的呈现方式,从简单的图文展示升级到沉浸式的 3D 体验。

WebGL 基于 OpenGL ES 2.0,将 GPU 渲染能力暴露给 JavaScript。开发者上传顶点、纹理并用 GLSL 编写顶点与片元着色器,经 gl.drawArrays() 或 gl.drawElements() 在 Canvas 实时绘制。广泛用于 Web 游戏、数据可视化与地图。

WebGPU 借鉴 Vulkan/Metal/DX12,提供显式命令缓冲、管线对象与绑定组,除高级渲染外还原生支持计算着色器。着色语言 WGSL 语法现代易分析。2023 年起主流浏览器已基本支持,可精细控制显存与同步,性能接近原生,适合机器学习推理、物理仿真与次世代 Web 游戏,被视为未来 Web 高性能基石。

借助这些技术,我们可以在网页上实现很多令人惊叹的效果。比如数据平台的实时 3D 可视化,可以直观呈现复杂的数据关系、电商平台可以用 3D 展示商品细节、网页游戏能达到主机级别的画面效果、在线教育可以创建虚拟实验场景……这些过去需要专业团队开发的效果,现在都能在浏览器中流畅运行。

WebGL 2.0 及 WebGPU 等新技术逐步支持光线追踪等高级渲染效果,Three.js 与 Babylon.js 实现浏览器端电影级渲染,元宇宙项目 3D 场景加载效率提升 300%。

Clipchamp 使用 WebGPU 后,4K 视频导出速度提升 3 倍。

……

随着 AR/VR 时代的到来,WebGL/WebGPU 的重要性更加凸显。它们将成为构建下一代互联网体验的关键技术。但对于传统前端开发者来说,要掌握这些技术需要突破原有的知识边界——不仅要学习图形学基础、着色器编程、渲染管线优化等全新领域,还要理解 AR/VR 特有的交互设计和性能优化方法。这些知识体系与传统前端开发有着本质区别。

AI 工具的出现大大降低了这些技能的学习门槛。现在,开发者只需要画个草图就能生成 3D 场景,用日常语言描述就能创建着色器代码,还能实时获取优化建议,轻松应对 AR/VR 设备的特殊需求。这些智能辅助让普通开发者也能开发出专业的 3D 网页应用。

编译原理

编译原理技术就像一把神奇的钥匙,能够打开现代前端开发的无限可能。这项基础技术支撑着许多我们日常开发中不可或缺的能力,比如让老旧浏览器也能运行最新语法(Babel 转译ES6+ 代码为 ES5、Polyfill 实现 API 兼容等),为团队量身定制开发语法糖,自动化检测代码质量,以及创建特定领域的专用语言。

无论是开发内部提效工具,还是解决特定业务场景的问题,编译技术都是实现代码变形的核心所在。但要真正掌握这项技术,需要突破几道难关:理解抽象语法树的操作逻辑,掌握词法分析和语法分析的原理,熟悉代码生成的优化策略等。

AI 工具的出现让这些复杂技术变得更容易掌握。现在的 AI 可以通过示例自动推导转换规则,智能修复兼容性问题,推荐最优的语法设计方案,就像身边随时有一位编译专家在指导工作。

AI 不仅推动前端技术向纵深发展,也在帮助开发者横向拓展能力的边界。

全栈开发

全栈能力曾是开发者的终极梦想,如今在 AI 的帮助下,这一梦想正逐渐变为现实。全栈开发者能够独立打造从用户界面到后台服务的完整系统,这种能力在实际开发中具有巨大优势:

  • 创业公司快速验证产品原型。

  • 中小企业高效构建完整应用。

  • 个人开发者实现全流程掌控。

  • 团队协作打破前后端壁垒。

但要成为真正的全栈开发者,至少需要跨越三道分水岭:同时驾驭前后端技术栈、掌握系统架构设计精髓、精通数据库优化之道。AI 正在让这一过程变得更顺畅——智能生成 API 接口规范、推荐最优数据模型、提供全链路调试支持,助力快速成长为全能型开发者。

跨平台开发

跨平台技术如同神奇的“语言翻译器”,让同一套代码能在不同设备上完美运行。这种“编写一次,处处运行”的能力正在改变移动开发格局:

  • 用 Web 技术开发原生级 App。

  • 同时覆盖 iOS/Android/Web 三端。

  • 保持多平台体验一致性。

  • 大幅降低维护成本。

Taro3 等国产框架深度整合云开发能力,使跨境电商项目人力成本降低 40%。

但要实现真正的跨平台卓越体验,需要解决三大核心挑战:处理各平台特性差异、优化不同环境性能、确保交互体验一致。如今,AI 工具正在化身为智能“平台适配专家”——自动生成平台特定代码、提前预警兼容性问题、针对性优化性能表现,让多端开发不再是令人头疼的难题,而成为提升效率的利器。

技术

2015年局限

2024年突破

跨平台开发

性能损失>40%

WebAssembly使差距<5%

3D渲染

依赖Unity WebGL

原生WebGPU逼近桌面级

05

砥砺前行:前端生态的无限可能

回顾前端技术近二十年的发展,从用滤镜 hack PNG 透明,到用 AI 生成着色器代码;从 alert 调试到智能错误自愈……每一次技术跃迁都带来了开发体验的质的飞跃。AI 不是前端开发的终结,而是一个新的开始。

AI 帮我们处理重复劳动,让我们能把更多精力放在创造性的工作上,比如提升用户体验、探索新技术方案。这才是前端开发真正的价值所在。

当 WebGPU 让浏览器能本地运行 AI 大模型,当 WASI 允许 WebAssembly 直接调用系统接口,当 WebNN 为神经网络推理打开大门,前端开发者站在了 AI 原生应用的最前沿——这不是威胁,而是史无前例的机遇。

-End-

原创作者|fransli

感谢你读到这里,不如关注一下?👇

图片

📢📢来领开发者专属福利!点击下方图片直达👇

图片

图片

你认为前端开发中哪些领域最容易被AI取代?欢迎评论留言补充。我们将选取1则优质的评论,送出腾讯云定制文件袋套装1个(见下图)。6月11日中午12点开奖。

图片

图片

图片

图片

图片

图片

相关推荐

大模型的Agent Skill功能,在LLM HTTP底层交互流中是怎么承载的?

网络文章文本的 skill,昨天我实现了之后也就开始好奇起 Skills 的底层原理了——相比起各种花里胡哨的 agrnt 应用,我一直以来都很对大模型在纯粹的 HTTP 交互层面是如何交互的更感兴趣。Skill 的全部"魔法"都发生在 system prompt 的措辞和 SKILL.md 文件的编写质量上——本质上是一种 prompt engineering + 文件系统的组合。但是各种天花乱坠的 skills,是如何在底层的 HTTP 中,与大模型——这个只会嘴遁的工具交互的呢?

QcloudCommunity的博客 407

万字入门AI Infra:深入理解大模型中的数学与Infra优化

关注腾讯云开发者,一手技术干货提前解锁👇AI Infra科普、入门或者进阶 ~~ 不到 5 万字,带你融会贯通理解大模型的数学、算法、硬件到系统工程。任何问题欢迎沟通交流。可怕,我竟然有点认同这句话。当然大概率是因为姚顺宇太懂AI了,而我则是因为无知者无畏。不过仔细想想,大模型推理中的数学逻辑确实不复杂,很多原理只需要高中数学知识就能看懂。但是为什么像 vLLM 这种推理系统这么复杂呢?本文将拆解大模型中几个核心操作(RMSNorm、Softmax、Causal Mask、Sampling)背后的数学与

QcloudCommunity的博客 1168

平平无奇的源码,竟藏着Agent的核心秘密?

System Prompt 是剧本,Skill 是剧本的扩展包,Agent Loop 是演员按剧本行动。欢迎留言,我们将邀请作者针对性回复你的评论,我们将选取1则优质的评论,送出腾讯云定制文件袋套装。,让 Agent 能主动"巡逻",而不只是被动等待用户消息。OpenClaw 的 System Prompt 分层结构。的"行为底线",任何 Skill 或用户命令都无法覆盖它。精华 2:Skill 的"按需加载"避免 token 浪费。精华 1:System Prompt 是"分层乐高积木"

QcloudCommunity的博客 426

QQ音乐Harness Engineering实践

一个看似简单的需求,背后可能牵动服务调用链、配置、灰度、埋点、错误码、接口契约和历史兼容性。当 AI 开始快速生成大量代码,真正的瓶颈就不再是"写不出来",而是"看不完、想不清、管不住"。在对话式编码阶段,一种典型的工作模式逐渐流行:开发者把需求丢给 AI,扫一眼输出"看起来对"就直接采纳,不审 diff、不追问逻辑、不验证边界。以音乐商业化业务为例,一个需求可能从 TAPD 单开始,经过需求评审、技术方案、服务影响面分析、IDL 契约变更、业务代码实现、测试验证、CR、灰度上线,最后才进入稳定运行。

QcloudCommunity的博客 715

从Prompt、Context到Harness,工程的三次进化与终局之战

同时,强制要求散落各处的决策记录(Slack、邮件、文档)全部迁移至代码仓库,确保 Agent 的唯一信息来源是可信的、版本受控的仓库。更坑爹的是,研究表明,当上下文过长时,模型会出现"中间遗忘(Lost in the Middle)"现象:它对开头和结尾的内容记忆较好,对中间大段内容的关注度大幅下降。这篇文章,我想带你完整走一遍这三次进化的逻辑:它们分别解决了什么问题,它们之间是什么关系,它们的边界在哪里,以及:当三者融合,AI 工程师的终极形态究竟是什么?大语言模型的本质,就是这位金鱼助理。

QcloudCommunity的博客 719

让Skill自己训练自己:8阶段Loop、3层评测、5维AND门控,从此实现自进化

所以每一轮改动都是有据可查的,不是「感觉这里可以优化」,而是「Case 41 挂了,因为 agent 把离职问题路由到了邮箱分类,但正确答案在通讯录,所以我改 root_index.md 加个易混淆提示」。但让我最后决定把它记录下来的,不是这的个「吸收」过程,而是它真的在替我探索我不想费脑力触达的边界,这看起来更像是一个机器智能应该有的样子。不准跨层,每轮只改一层的东西。但我经过这 19 轮之后觉得,更准确的描述是互补——你在明处看着,AI 在暗处替你试错,你看不见的那一半就是 AI 能贡献的地方。

QcloudCommunity的博客 1127

只加两行代码,为什么要两天?一文深度理解业务系统的复杂性

关注腾讯云开发者,一手技术干货提前解锁👇业务系统复杂性一直是令开发者头痛的问题。复杂的不是增加一个需求需要耗费多少时间,而是在增加一个需求后带来的蝴蝶效应:其它功能会不会受到影响、要如何去找到这些影响,最终如何实现系统正常运行......功能之间隐秘增加的耦合、不可避免的代码腐化在导致业务复杂性增加。大家都在说的软件开发提效到底在提什么?程序员日常工作中应该如何提升开发效率?敏捷开发、瀑布流式开发孰是孰非?欢迎阅读。业务背景与目标我依然非常清晰地记得某个时候,我所在团队 Leader 曾讲过一段话:“我担

QcloudCommunity的博客 713

从零设计生产级 Multi-Agent Harness:架构、评估、记忆、成本与 MCP 工具接入全拆解

在 AI Agent 领域,Multi-Agent Harness 指的是把多个 Agent 的能力、工具、状态、通信、编排、监控统一收束在一个运行时之内的框架。第三,Agent 路由。一个输入框,一个大模型,几个工具,一段写得很漂亮的 System Prompt,再配上一个炫酷的前端,看起来就像一个能干活的“数字员工”。Multi-Agent 完全不一样——它有计划、有中间步骤、有工具调用、有 Agent 协作、有重试、有反思、有最终合成。增加 Budget、权限、重试、压缩、轨迹评估、审计、回归测试。

QcloudCommunity的博客 710

拆完Hermes源码,我发现Agent的“自我进化“根本不需要训练模型

两个月 5.2 万 Star,Hermes Agent 用一个"LLM 审判官"机制实现了 Agent 的自我进化——不改模型权重,只改"怎么用模型"的策略。OpenClaw(社区昵称"龙虾"🦞)是 2025-2026 年最火的开源 Agent 框架,30 万+ Star,插件市场 ClawHub 里有数千个插件,能接入 Telegram、WhatsApp、Slack、飞书、企业微信——几乎是一个"个人 AI 操作系统"。Skill 是英语写的,Memory 是英语写的,审查 Prompt 也是英语写的。

QcloudCommunity的博客 910

AI Infra 其实没有多少新东西

传统 Infra 追求横向扩展,而 AI Infra 呈现 “AI 大型机”特性,是因为传统后台服务的可以容忍毫秒级延迟,但 AI 集群不行,GPU 的算力是 CPU 的数百倍,微秒级的延时等待也会造成很大的算力损耗,需要硬件的高度集成。在可预见的1-3年的未来,这样的专用硬件+网络的集中式架构很难发生比较大的改变。与之相似,模型推理的批处理就是将多个输入样本打包(batch),将原本串行的 N 次轻量的推理计算,合并为 1 次重量的计算,实现单位时间内处理更多的请求,提高了 GPU 利用率。

QcloudCommunity的博客 826

程序员越早想通这些越好

永远没有正确架构,你永远无法偿还完所有的技术债务,如同你永远不会设计出完美的界面,请避开完美主义的陷阱,永远没有完美的代码,能够满足当前需求,又为未来不管是自己还是他人留有扩展空间,就很好了。我们努力的方向就是将现实世界映射到有限的数据结构中,这就需要用户自定义类型,如果你的代码中包含类似 trader portfolio 这样的概念,你就可以使用他们的名称来建模,而不是使用基本数据类型复杂嵌套表述你的目的。从另一个角度看,代码里的注释都是补丁,是碎片化的,局部的注释很难推导模块整体的顺序及耦合关系。

QcloudCommunity的博客 466

RAG已死?不,是Grep回归了!

这样一来可以直接复用已有的计算缓存,只为新增的增量部分付全价,前面累积的大头按约 1/10 的缓存价计费。所以实际的工具组合方式是灵活的:Grep(默认模式)→ Read 是最常见的路径,但 Grep(content 模式)可以独立使用,LLM 也可以直接调 Read(如果已经知道文件路径),或者一次同时发起多个 Grep 并行搜索。它从零开始构建自己的对话历史,不继承主对话的消息,这意味着它搜索过程中产生的大量 grep 结果、代码片段都留在自己的 context 里,主对话只收到一段总结性的文本结论。

QcloudCommunity的博客 576

深入浅出Harness Engineerring之核心模式与理念

在智能体生命周期的关键节点(如会话开始、工具调用后)自动触发预设动作(如代码格式化),由系统确保关键流程被执行,不依赖可能被模型遗忘的指令。简单讲就是利用向量存储这个技术,来实现模糊检索,原理是:即使字面不同,但语义相近的文本,其向量在数学空间中的位置也很接近。根据命令类型、参数和影响,自动评估其风险等级(安全、有风险、危险),并采取自动执行、请求确认或直接拦截等不同策略。关键特性是可隔离、可重建、可扩展。不是一次判断就定终身,允许你改变、允许情况复杂,通过不断观察、思考、调整,越来越懂真实的你。

QcloudCommunity的博客 624

Harness Engineering实践心得:如何高效驾驭AI?

但如果这些经验被拆成一条条 Rule、一个个 Skill、一项项 Script 检查——"XAML 不能有中文"、"编译要用这个路径的 MSBuild"、"SVN 命令必须带认证参数"——AI 就能在秒级时间里"吸收"十年的踩坑经验。然后可以看到下方的图,我的PM会很顺利的调度其他agent分别负责不同的事项,遇到问题的时候也能准确的找到合适的agent。MCP 本质上是在扩展 AI 的"感知范围"——Rule 管"该怎么做",Skill 管"怎么操作",MCP 管"能看到什么、能碰到什么"。

QcloudCommunity的博客 842

从第一性原理思考 Agentic Engineering

需要注意的是,这一结论是有条件的:如果 AI 缺乏领域知识,过早介入反而可能引入 1.2 节所述的"似是而非"损耗——因此上下文供给(实践 1)是 AI 全链条参与的前提,而非结果。通过一个专门的自迭代 Skill 实现——当 AI 在协作过程中识别到自己被纠正(用户否定了 AI 的输出并给出了正确方向),它自动评估这个错误的根因,搜索现有的 Rules 和 Skills 中是否已有针对该类问题的处理规则。事实上,越是复杂的项目,工程师的认知负担越重(公理 3),AI 分担认知负担的潜在边际价值也越大。

QcloudCommunity的博客 757

万字干货!Harness Engineering如何工程化落地?

关注腾讯云开发者,一手技术干货提前解锁👇Harness Engineering 的概念已经火了有一阵了,全网很多文章基本都是在讲理念,讲为什么今天做 AI 开发,不能只靠一段提示词,也不能把模型当一个“更聪明的代码补全”。但与此同时,一个问题也在持续地发酵:这个问题特别重要。因为 Harness 这个词听上去很大,很像一个抽象的方法论,但它如果不能落到工程、目录、文档、脚本、工作流里,那它最后就只是一句漂亮的话。事实上,不同项目落地出来的 Harness,表面上可能完全不一样。有的项目是 CI 很强,有的

QcloudCommunity的博客 1170

全方位对比:Hermes VS OpenClaw

多账号矩阵运营 如果你的业务涉及同时管理多个社交媒体账号、多个平台的内容分发、多渠道的客户互动——OpenClaw是目前市场上的"无可替代的底座"。一个有专业背景的个人,现在可以快速构建一个垂直领域的AI助手:比如"财务分析Hermes"、"法律咨询Hermes"、"技术架构Hermes",直接通过微信提供服务,积累自己的专业IP。跨平台生态融合 如果你的工作流涉及飞书、Slack、Discord等多个平台的深度集成,需要这些平台之间的数据流转和联动——OpenClaw的生态支持是强大的。

QcloudCommunity的博客 1217

一文讲透:Harness Engineering即控制论!

而研发模式的升级我认为将会是一个飞跃的过程,之所以现在我们仍然需要需要参与编码,一个非常大的原因就是缺乏传感器和基建,仍然需要人来串流程,比如需要人来验证UI是否正确、需要人来告诉AI代码不符合代码规范,因此在有些场景我们仍然感觉 AI 完成的很吃力,但这不是 AI 能力不行,而是我们并没有为 AI 提供友好的环境……控制论中的突变理论介绍了矫枉过正和飞跃现象之间的矛盾,如果质变中经历的中间过渡态是不稳定的,那么他就是一个飞跃的过程,如果中间过渡态是稳定的,那么他就是一个渐变的过程。但是这些阶段要解决的。

QcloudCommunity的博客 1204

神级开源插件!一句话让QClaw变3D小镇,Agent工作可视化,赛博云监工

这个架构是翻了几次车才想通的—原有AI的实现机制是用 setTimeout 猜动画时长导致了幽灵 NPC、工位撞车、越改越崩,后面我停下来换了思路,推翻原有的架构,按照“意图+回传”的架构进行重构,之前的问题一次性全部解决。15 天,我和 AI 吵了 185 次架, 4.5 万行代码,开发了一款 QClaw / OpenClaw 的UGC游戏插件,这可能是人类跟 Agents 交互的新范式,插件已完全开源,有需要的欢迎自取~我天天用,用着用着我就在思考,Agent 产品现在的交互体验,基本都一个样。

QcloudCommunity的博客 1197

一文搞懂Hermes:新顶流Agent如何从经验中自我进化

Voyager 是一个能在 Minecraft 中自主探索、学习技能、无限积累能力的 AI Agent,它提出了 "Skill Library"(技能库)的概念——Agent 将成功的行为序列编码为可复用的技能函数,存储在一个持续增长的代码库中。如果 Skill 的名称和描述不够精准,或者用户的任务描述与 Skill 的触发条件有语义差距,Agent 可能会错过相关的 Skill。如果进程在写入过程中崩溃,目标文件要么是旧内容(还没被替换),要么是新内容(替换已完成),绝不会出现写了一半的损坏文件。

QcloudCommunity的博客 2636

自掏腰包一万元,拥抱AI这一年,我的工具、实践和思考

其实也很好理解,过往的每个领域(比如前端、后端、设计、测试等等)都主要是这个领域的从业者在为它添砖加瓦,但是大模型时代的 AI 应用领域却几乎是所有使用 AI 的人类一起在迭代,无分领域,无分文理,无分老少。因为每个时期的 AI 都有着不同的特点,很多时候当我费尽心思去钻研,自以为有点弄明白 AI 应该怎么玩的时候,基座模型和行业范式常常就会迎来颠覆式的变革,很多过往的经验都会倾覆,然后只能从头再来。过去一年多,被热议的 AI 范式大概是沿着四个阶段递进演化,每一个阶段其实都在解决前一个阶段的核心问题。

QcloudCommunity的博客 627

办公Agent的CI/CD时刻到来了

核心观点是:企业给员工配了一堆 AI 工具,试点跑了几百个,但真正拖慢 AI 转型速度的瓶颈不在模型能力,在"最后一公里":AI 输出和实际工作流之间的那道鸿沟。代码写完,打个 tar 包,开 FTP 传到服务器上,SSH 进去解压,改配置文件,重启服务,刷一下页面祈祷别 500。你复制,切窗口,粘贴到腾讯文档里,发现 Markdown 格式全乱了,手动调标题层级,代码块重新标记语言类型,表格散架了重排一遍。模型是越来越聪明了,但"生成"到"落地"之间那段路,还是你自己在走,一步一步,手动搬运。

QcloudCommunity的博客 608

4亿token买来5个教训:让6个AI Agent连写4天代码发生了什么?

Watchdog 检测到崩溃 → 启动诊断 Agent 分析原因 → 诊断 Agent 跑满 20 轮没搞定 → Watchdog 判定“已修复”,重启系统 → 重启的系统因为诊断 Agent 留下的环境变量被继承,连续 3 次拒绝启动 → 触发连续失败保护退出 → Watchdog 第 3 次巡检,发现进程和记录文件都没了,尝试手动重启,自己也停了。启动前我翻了论文、做了架构设计、写了监控+修复异常的脚本。这个发现让我的情绪从沮丧变成了兴奋——不是那种"终于修好了"的释然,是"我找到根因了"的快感。

QcloudCommunity的博客 584

赛博斗蛐蛐:9大模型决战三国志,天命在谁?

我猜是这样的,当Gemini面临决策的时候,一系列关键词比如 守城,劣势,粮草,三国等等,在语义层面的关联性中LLM发现了竖壁清野这个关键词概率非常高,所以以此为策略,然后再根据这个策略完美执行操作。MiMo 的外交是三方中最精明的。Kimi作为国产模型,也同样颠覆了我对他的看法,最后的比赛他甚至一度是优势者,存在很多夺冠的可能性,要知道他的对手可是claude和gemini,而他经常出兵慢,回过头来想想或许正是他的策略,毕竟中后期他的优势都来自于稳健的发展和较少的战斗频率(和claude比).

QcloudCommunity的博客 874

Claude Code是怎么知道你在骂他的?这 12 条发现值得关注

确实存在——5,500+ 行,集成了消息队列、工具装配、MCP 编排、会话状态、权限、分析、文件持久化和优雅关闭,基本上一个文件干了所有事。对抗虚假声明——"不要在输出显示失败时声称所有测试通过,不要压缩或简化失败的检查来制造绿色结果"。完整的 KAIROS 是一个持续驻留的守护进程,能感知你在不在电脑前、主动寻找有用的工作做,更像是住在终端里的全职同事。源码里藏着一个叫 "Buddy" 的电子宠物系统,完整度令人惊讶——这不是一个 TODO,而是一个从数值系统到 ASCII 动画都实现了的完整功能。

QcloudCommunity的博客 701

逆向深扒Claude Code源码,我发现了什么!?

Anthropic 内部用户获得更严格的质量控制 prompt、更好的验证机制(独立 Verification Agent)、以及针对 model 弱点的专门对策(如 Capybara v8 的 29-30% 错误声明率对策)。这不是代码混乱的标志——它是整个 Agent Loop 的心脏,所有的流式处理、工具调度、上下文压缩、子代理管理都在这个文件中协调。这种"胖核心"设计是刻意的:保持核心循环的原子性,避免分散到多个模块导致的协调复杂度。核心价值:Fork 代理的工具输出不会回到主代理的上下文窗口。

QcloudCommunity的博客 892

一文讲透如何构建Harness——六大组件全解析

本文将从"裸模型的四个硬伤"出发,逐一拆解 Harness 的六大组件——文件系统、Bash + 沙箱、记忆(AGENTS.md)、Web Search + MCP、上下文工程、编排 + Hooks——带你看清 AI Agent 真正的竞争壁垒,不在模型层,而在 Harness 层。如果你用过 Agent 做复杂任务,你一定有过这样的体验:一开始 Agent 的表现很好,但随着对话变长,它开始"变笨"——遗忘之前的约定,重复之前犯过的错误,甚至对同一个问题给出前后矛盾的回答。对于简单的问答场景,这无所谓。

QcloudCommunity的博客 761

Harness Engineering 来了,SDD 还有意义吗?

他们的解法是把「品味」编码进规则,然后用一个定期运行的「doc-gardening」Agent 自动扫描漂移、发起修复 PR——「技术债务就像一笔高息贷款,不断地以小额贷款的方式偿还,总比让债务不断累积要好」。代码仓库本地的、已版本化的工件,才是 Agent 所能看到的全部。在 Vibe Coding 模式下(即不做规划、随意向 AI 提需求的开发方式),大量设计决策、跨服务约定、「为什么不选另一个方案」的讨论,全部停留在一次性的 AI 对话里——下一个人,或者下一次 AI 会话,完全无从获取。

QcloudCommunity的博客 419

零废话!一文讲透从0构建AI Agent

每个工具都要写一套"定义→解析→执行"的胶水代码。上下文管理就是在"记住足够多"和"别超标"之间找平衡,常见策略包括滑动窗口、摘要压缩、RAG 检索增强。上下文窗口是 Agent 的"工作记忆",但它有硬性限制。LLM 负责"动脑"决策,代码负责"动手"执行。这是从"聊天机器人"进化到"Agent"的关键一步。每次调 API 都把完整对话历史发过去,LLM 本身是无状态的,"记忆"完全靠客户端的数组模拟。这样 Agent 一开始就知道自己"在哪里"、"手头有什么",不需要先花一轮工具调用去探索环境。

QcloudCommunity的博客 711

距离AI把小编我裁掉还有72小时

这是一个基于 OpenClaw 开源生态打造的本地化 AI Agent 助手,已于上周开启全量公测,无需复杂配置,三步即可上手,自带安全防护,支持微信直连绑定,内置多款优质国产大模型,现阶段也是完全免费使用,基本上前面提到过的痛点都可以靠它解决。对了,这里特别强调一点,上面的截图让产品同事汗流浃背,再三找我确认 QClaw 思考过程中优美的“草”字说法,不会是默认出现的吧?AI 好,AI 得学,但更重要的是,在你的工作和生活里,哪些东西是能结构化地被 AI 所接入的,不要死守着那些脏活累活不放。

QcloudCommunity的博客 674
上一篇: 万字总结:腾讯会议后台告警治理实践——如何才能避免“事后诸葛亮”
下一篇: 我认识最优秀却默默无闻的程序员
腾讯云开发者
腾讯云开发者 企业官方账号 企业官方账号
博客等级 码龄10年 6291粉丝 1962原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值