Context Engineering,一篇就够了
✨ “多数 AI Agent 的失败,并非模型能力的失败,而是上下文工程的失败。” Context Engineering(上下文工程),这个术语在前段时间突然流行起来。起初我也质疑这是否又是一次炒概念?它与我们熟知的 Prompt Engineering、RAG 甚至 MCP (Model Context Protocol) 之间,存在着怎样的关联? Context Engineering 的概念主要源自 Tobi Lütke 和 Andrej Karpathy 的推特:“It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.” (提供所有上下文的艺术,以使任务能够被 LLM 合理地解决) && "When in every industrial-strength LLM app, context engineering is the delicate art ...
模型上下文协议(MCP)
为什么 MCP 是一个突破 我先来画一个饼,我认为未来的 AI 是这个样子的,以我熟悉的软件工程领域举例: 未来,AI 可以完全自动化应用开发流程,例如: 设计阶段:可以连接设计工具,基于用户需求生成 UI 和功能设计。 编码和测试:AI 编写代码,期间可以随时在浏览器或者各类模拟器中运行应用并获取运行日志来帮助自己 debug 开发过程中的各种错误。以及检查编写的 UI 是否和设计稿一致。并根据业务需求生成各类自动化测试。 部署: 自动 push 代码,持续集成部署,并根据 CI 平台的测试反馈自动触发 bug fix,再次提交部署。 维护和更新:自动监控应用,自动修复错误,并根据需求更新功能。 ...... 这个饼现在看来可能画的有点大,可能其中的部分功能单独拉出来很好实现,但是当他们组成一个系统提供能力时,你能想象用起来多爽吗? 当然,上面谈到的这些功能,通过 MCP 目前正在逐步变成现实,就比如第二步中的从浏览器获取日志来 debug 应用的例子,你可以试试用 Cursor MCP + browsertools 插件来体验一下在 Cursor 中自动获取 Chrome...
LLM Best Practice:LLM Accuracy Optimization (上) - 思维模型与优化起点
LLM Accuracy Optimization 是一个如此复杂的议题,怎么可能一篇就讲清楚?我也是这样认为的。 考虑到内容的丰富性和读者的认知负荷,我决定将这个主题拆分为几篇阅读时间在 30 分钟左右的博客。无论是 Prompt Engineering 还是 RAG,每个领域都有大量精细的优化技术。与其深入技术细节,我认为更重要的是帮助读者快速找准优化方向 - 因为一旦方向明确,具体的优化执行反而相对简单。 在经历多次思考清楚优化方向后轻松解决问题后,我认为在优化之前心中得有优化之道。在看了 OpneAI 的 Dev Talk 和阅读了对应博客后,我觉得它们讲述的内容就是某种“优化之道”,在我们对 AI 应用的优化时中颇有用处。 优化 LLM 的困境 优化 LLM 并非易事,优化工作之所以困难,这里借 OpenAI 的说法,归结为以下几点原因: 如何开始优化准确性(Knowing how to start optimizing accuracy) 在何时选择何种优化方法(When to use what optimization method) 生产环境中需要达到何种准确性...
浏览器渲染原理
什么是渲染 浏览器中的 “渲染” 指的是将 HTML 字符串转化为屏幕上的像素信息的过程。 我们可以将渲染想象成一个 render 函数,函数接收一个 html 字符串,将其经过一系列处理得出若干像素点的颜色。 function render(html) { // 一系列处理得出像素信息... return pixels;} 渲染时间点 了解什么是渲染之后,我们不由得好奇发问:渲染是在什么时候发生的呢? 当我们在浏览器键入一个 URL 时,网络线程会通过网络通信拿到 HTML,但网络线程自身并不会处理 HTML,它会将其生成一个渲染任务交给消息队列,在合适的时机渲染主线程会从消息队列中取出渲染任务执行,启动渲染的流程。 渲染流水线 接下来我们重点来讲解渲染的流程,整个过程如下图: 解析 HTML 解析过程中遇到 CSS 解析 CSS,遇到 JS 执行 JS。为了提高解析效率,浏览器在开始解析前,会启动一个预解析的线程,率先下载 HTML 中的外部 CSS 文件和 外部的 JS 文件。 如果主线程解析到 link 位置,此时外部的 CSS 文件还没有下...
浏览器中的js事件循环
浏览器进程模型 何为进程 进程是操作系统资源分配的最小单元, 程序运行需要有它自己专属的内存空间,可以把这块内存空间简单理解为进程 每个应用至少有一个进程,进程之间相互独立,即使要通信,也需要双方同意。 何为线程 线程是操作系统能够进行运算调度的最小单元,是进程中实际运行的单位。 有了进程之后,就可以运行程序的代码了,运行代码的「人」称之为「线程」。一个进程至少有一个线程,所以在进程开启后会自动创建一个线程来运行代码,该线程称之为主线程。 如果程序需要同时执行多块代码,主线程就会启动更多的线程来执行代码,所以一个进程中可以包含多个线程。 浏览器有哪些进程和线程 浏览器是一个多进程多线程的应用程序,浏览器内部工作极其复杂。 为了避免相互影响,为了减少连环崩溃的几率,当启动浏览器后,它会自动启动多个进程。 可在浏览器的任务管理器中查看当前的所有进程 其中,最主要的进程有: 浏览器进程 主要负责界面显示、用户交互、子进程管理等,浏览器进程内部会启动多个线程处理不同的任务。 网络进程 负责加载网络资源。网络进程内部会启动多个线程来处理不同的网络任务。 渲...
CSS3 - Grid 布局
Grid 布局是什么? Grid 布局即网格布局,是一种新的 CSS 布局模型,比较擅长将一个页面划分为几个主要区域,以及定义这些区域的大小、位置、层次等关系。号称是最强大的的 CSS 布局方案,是目前唯一一种 CSS 二维布局。利用 Grid 布局,我们可以轻松实现类似下图布局,演示地址 Grid 布局和 flex 布局 讲到布局,我们就会想到 flex 布局,甚至有人认为竟然有 flex 布局了,似乎没有必要去了解 Grid 布局。但 flex 布局和 Grid 布局有实质的区别,那就是 flex 布局是一维布局,Grid 布局是二维布局。flex 布局一次只能处理一个维度上的元素布局,一行或者一列。Grid 布局是将容器划分成了“行”和“列”,产生了一个个的网格,我们可以将网格元素放在与这些行和列相关的位置上,从而达到我们布局的目的。 Grid 布局远比 flex 布局强大! flex 布局示例: Grid 布局示例: Grid 的一些基础概念 我们使用 Grid 实现一个小例子,演示 Grid 的一些基础概念,演示地址 <div class="wra...
ES6中的Reflect
前言 很多同学在学习es6的时候都会产生这么一个疑问, 就是个 Reflect 到底是个啥, 它到底有什么作用, 其实要说明它的作用只需要一句话, 就是调用对象的基本方法, 或者叫基本操作或者内部方法都是一个意思 一句话结束了, 那剩下的事情就是要解释一下什么叫基本方法, 以及它的作用. 对象基本方法 这是ES官方文档里面的描述: 这是什么意思呢, 就是说作为一个js开发者, 无论你怎么操作一个对象, 最终都要对应到这里面的内部方法, 比如我们使用这么一个语法: const obj = {};obj.a = 1; // 最终访问了一个内部方法 [[Set]]console.log(obj.a); // [[Get]] 也就是说, 我们书写的语法层面的代码, 它最终运行的时候, 实际上运行的是这个对象的内部方法, 对一个对象的所有操作, 都不能避免这一点. Reflect 是什么 它是一个包含了与所有内部方法对应的静态方法的类, 它不能创建对象, 就和Math一样, 所有方法都是静态的, 它可以直接访问对象的内部方法, 上面的语法使用Reflect就是这...
一些有用的web知识
前言 作为一名前端er,日常工作打交道最多(之一)的莫过于熟悉而又陌生的浏览器了,熟悉是每天都会基于浏览器的应用层面之上码业务,陌生是很多人可能跟我一样不熟悉其内部运行原理,比如js是怎样运行的呢?精美样式页面是怎样渲染到电脑屏幕的呢?在开放的互联网它又是怎样保证我们个人信息安全的呢?下面就(非常非常)简单总结一下。 Chrome 架构:仅仅打开了 1 个页面,为什么有 4 个进程 线程和进程区别:多线程可以并行处理任务,线程不能单独存在,它是由进程来启动和管理的。一个进程是一个程序的运行实例。 线程和进程的关系:1、进程中任意一线程执行出错,都会导致整个进程的崩溃。2、线程之间共享进程中的数据。3、当一个进程关闭后,操作系统会回收进程所占用的内存。4、进程之间的内容相互隔离。 单进程 浏览器:1、不稳定。单进程中的插件、渲染线程崩溃导致整个浏览器崩溃。2、不流畅。脚本(死循环)或插件会使浏览器卡顿。3、不安全。插件和脚本可以获取到操作系统任意资源。 多进程浏览器:1、解决不稳定。进程相互隔离,一个页面或者插件崩溃时,影响仅仅时当前插件或者页面,不会影响到其他页面。2、解决不流畅...
ES6中的迭代器与生成器
前言 JS 提供了很多迭代集合的方法,从简单的for循环到map()、filter()等方法。ES6 规范还新增了两个高级特性:迭代器和生成器,并且还新增了for...of...结构支持这两个特性。使用这两个特性,能够更清晰、高效、方便地实现迭代。 什么是迭代 在 JS 中循环是迭代机制的基础,这是因为循环可以设置迭代的次数,同时还可以指定每次迭代的具体操作。每次循环都会在下一次迭代之前就完成,并且迭代的顺序事先就定义好了。 迭代会在一个有序集合上进行。这里的有序,可以理解为集合中所有项都可以按照既定的顺序被遍历到,特别是开始和结束项有明确的定义。 区分 for of 和 for in for of 是遍历迭代器的,可遍历的对象是一个含有迭代器的对象,一般定义的 object 是没有自带迭代协议的也就是@@iterator方法,后面详细讲解此属性,Array、string、map 等类型自带有这个属性,也就是本身就是可以被迭代的对象。 for in 是遍历可枚举属性的,基本包装类型如 Object,Array,Object 的原型属性是不可以被枚举的,也就是说必须要自己定义的属性...
Java日志框架历史演进及最佳实践
Java日志框架历史演进 日志作为逻辑追踪、线上问题排查、监控报警的有效基础利器被开发人员所熟知。问题发现、定位到解决都离不开它,而且从它的演进过程也能看到现代互联网发展的一个缩影。 print、alert、echo 互联网发展的早期,不管是C/S模式(客户端+服务端模式)还是B/S模式(浏览器+服务端模式),因为只有前端和后端交互这一层,验证逻辑基本上用的是前端alert,后台用System.out.print,服务器用echo命令回显。链路短,基本上够用。 JUL Java Util Logging简称JUL,是JDK 中自带的log功能。虽然是官方自带的log lib,JUL的使用确不广泛。主要原因: JUL从JDK1.4 才开始加入(2002年),当时各种第三方log lib已经被广泛使用了。Java Logging API提供了七个日志级别用来控制输出。这七个级别分别是:SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST。 JUL早期存在性能问题,到JDK1.5上才有了不错的进步,但现在和Logback/Log4j2相比还是有所不如...









