面试

基于 2025.11 — 2026.03 期间 Anthropic、OpenAI、LangChain、Google DeepMind、Stanford 发布的九篇核心文章的精读整理。 目标：理解 Harness Engineering 是什么，以及大公司和学术机构在实践中做了哪些探索。 一、什么是 Harness Engineering？ 1.1 Harness 的定义 LangChain 给出了最清晰的公式化定义： Agent = Model + Harness “If you’re not the model, you’re the harness.” “A harness is every piece of code, configuration, and execution logic that isn’t the model itself.” 具体来说，Harness 包括： System Prompts — 系统提示词，定义 Agent 的行为边界 Tools / Skills / MCPs — 工具集及其描述（文件读写、代码执行、浏览器操作等） Bundled Infrastructure — 捆绑基础设施（文件系统、沙箱、浏览器） Orchestration Logic — 编排逻辑（子 Agent 派生、任务交接、模型路由） Hooks / Middleware — 确定性执行逻辑（压缩、续行、lint 检查等） Anthropic 不给 Harness 下抽象定义，而是通过实践来展示：他们用 “harness design” 和 “harnesses for long-running agents” 来描述围绕 Agent 执行循环的编排层。Anthropic 在博客中明确说：“harness design is key to performance at the frontier of agentic coding”。 ...

前言 打开 iPhone 的"设置 → 辅助功能 → 旁白（VoiceOver）"，再用三指在屏幕上滑动，iPhone 就会逐个读出当前界面上的每个控件："登录按钮，双击以激活"、"用户名，文本框，已填写 ancheng"、"价格，¥99"。这背后支撑 VoiceOver、开关控制（Switch Control）、语音控制（Voice Control）、全键盘访问（Full Keyboard Access）、Xcode UITest、AI Agent 识屏 等一系列能力的，是一棵并行于 UIView 视图树的 无障碍树（Accessibility Tree，AX Tree）。 对大多数 iOS 工程师来说，无障碍树是"黑盒"：设了 isAccessibilityElement = true、填了 accessibilityLabel，然后就不管了。但一旦遇到以下问题，就不得不深入理解它的工作机制： 为什么 UITest 里用 XCUIElement 定位不到某个按钮？ 为什么打开 VoiceOver 后 App 明显变卡？ 为什么一个自绘的 CALayer 按钮在 VoiceOver 下无法被朗读？ 为什么 UILabel 嵌在 UIStackView 里焦点顺序是乱的？ SwiftUI 的 .accessibilityElement(children: .combine) 到底合并了什么？ Accessibility Inspector 里看到的树结构从哪儿来？ AI Agent（如 iOS 上的 Claude、ChatGPT Mac 客户端）是如何"看到"屏幕的？ 本文从操作系统层的 AX 架构讲起，逐层拆解：AX Server 守护进程、UIKit 中的 UIAccessibility 协议、UIAccessibilityElement 类、UIAccessibilityContainer 协议、焦点排序算法、SwiftUI 的 AX 实现、辅助技术的工作原理、性能优化、UITest 与 AI 识屏原理、调试工具与最佳实践。 ...

本文深入介绍iOS/macOS开发中的Mach-O文件格式、动态库与静态库，帮助理解程序的链接、装载过程，以及Rebase/Bind的底层原理。 一、基础概念 在深入学习之前，先了解几个核心概念。 1.0 从源代码到可执行文件 一段源代码要变成可执行文件，需要经历以下几个阶段： flowchart TB A["源代码 (.m/.swift)"] --> B["预处理展开宏、处理#import/#include"] B --> C["编译源代码 → 汇编代码"] C --> D["汇编汇编代码 → 目标文件(.o)"] D --> E["链接目标文件 + 库 → 可执行文件"] E --> F["可执行文件"] 1.1 什么是符号（Symbol） 符号是程序中函数、变量、类等实体的名称标识。当你写下一个函数调用时，编译器需要知道这个函数在哪里，符号就是用来定位它的。 // 这段代码中包含多个符号 void myFunction(void) { // 定义了符号 _myFunction NSLog(@"Hello"); // 引用了外部符号 _NSLog } int globalVar = 10; // 定义了符号 _globalVar 符号分为两类： 已定义符号：在当前编译单元（即当前源文件编译生成的.o文件）中有具体代码或数据定义的符号（如上例中的 _myFunction 和 _globalVar） 未定义符号：当前编译单元只是引用，实际定义在其他编译单元或库中的符号（如上例中的 _NSLog），需要在链接时解析 1.2 什么是链接（Linking） 链接是将多个编译后的目标文件（.o）组合成一个可执行文件的过程。链接器的核心工作是符号解析——把所有"未定义符号"与其他编译单元中的"已定义符号"关联起来。 flowchart LR subgraph 输入 A["main.o已定义: _main未定义: _foo"] B["foo.o已定义: _foo未定义: _NSLog"] C["Foundation已定义: _NSLog"] end A --> D["链接器符号解析"] B --> D C --> D D --> E["可执行文件所有符号已解析"] 符号解析的过程 链接器会遍历所有输入的目标文件和库，执行以下步骤： ...

定义 建造者模式（Builder Pattern）是一种创建型设计模式，它将复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示。建造者模式特别适用于创建包含多个可选参数的对象。 建造者模式的核心思想是：将一个复杂对象的构建过程分解为多个简单的步骤，通过一步一步地构建，最终得到完整的对象。 为什么需要建造者模式 建造者模式要解决的核心问题是：简化复杂对象的创建过程，特别是当对象有很多可选参数时。 问题场景：假设我们需要创建一个网络请求配置对象，它有很多可选参数。 使用构造函数的方式： struct NetworkConfig { let baseURL: URL let timeout: TimeInterval let retryCount: Int let cachePolicy: CachePolicy let headers: [String: String] let enableLogging: Bool let certificatePinning: Bool // 构造函数参数太多！ init(baseURL: URL, timeout: TimeInterval = 30, retryCount: Int = 3, cachePolicy: CachePolicy = .default, headers: [String: String] = [:], enableLogging: Bool = false, certificatePinning: Bool = false) { // ... } } // 使用时 - 参数太多，难以阅读 let config = NetworkConfig( baseURL: URL(string: "https://api.example.com")!, timeout: 60, retryCount: 5, cachePolicy: .reloadIgnoringCache, headers: ["Authorization": "Bearer token"], enableLogging: true, certificatePinning: true ) 这种方式有什么问题？ ...

规范化是前端工程化的一个重要部分。现在，有许多工具能够辅助我们实行代码的规范化,比如你一定知道的 ESLint 和 Prettier。 今天，来聊聊这些工具的工作原理和基本使用，了解它们是如何发挥作用的，以及如何更好地利用这些工具去规范项目的代码。 1. ESlint - 检查你的 JavaScript 代码 让我们先从知名度最高的 ESLint 开始。 1.1. ESLint 及其作用 Lint 是一类专门用于检查代码的工具软件， 也称 linter。ESLint ，即 JavaScript （ECMAScript）代码的检查工具。 正如官网的介绍 —— “Find and fix problems in your JavaScript code”，ESLint 能够辅助查找出你的 JavaScript 代码中的问题，包括： 代码风格问题（styles）。比如，运算符两边的空格、语句末尾的分号。 不好的写法。比如，使用 == 进行比较而不是 ===。 可能存在逻辑问题的代码模式。比如，定义了一个变量，但没有使用到它。 此外，ESLint 还能够帮你自动修复一些简单的问题。 我们将在下一小结学习如何使用 ESLint 检查我们的 JavaScript 代码，并修复其中的一些问题。 1.2. ESLint 快速上手 为了在项目中使用 ESLint，需要先安装它。 # 初始化一个 npm 项目 mkdir eslint-test cd eslint-test npm init -y # 安装 eslint npm init @eslint/config 回答一系列问题后，你可以看目录中的配置文件 .eslintrc.js，这个配置文件告诉 ESLint 如何去解析项目，这个项目采用了哪些规范和规则。 ...

Cookie 和 Session HTTP 协议是一种无状态协议，即每次服务端接收到客户端的请求时，都是一个全新的请求，服务器并不知道客户端的历史请求记录；Session 和 Cookie 的主要目的就是为了弥补 HTTP 的无状态特性。 Session 是什么 客户端请求服务端，服务端会为这次请求开辟一块内存空间，这个对象便是 Session 对象，存储结构为 ConcurrentHashMap。Session 弥补了 HTTP 无状态特性，服务器可以利用 Session 存储客户端在同一个会话期间的一些操作记录。 Session 如何判断是否是同一会话 服务器第一次接收到请求时，开辟了一块 Session 空间（创建了Session对象），同时生成一个 sessionId ，并通过响应头的 **Set-Cookie：JSESSIONID=XXXXXXX **命令，向客户端发送要求设置 Cookie 的响应； 客户端收到响应后，在本机客户端设置了一个 JSESSIONID=XXXXXXX 的 Cookie 信息，该 Cookie 的过期时间为浏览器会话结束； 接下来客户端每次向同一个网站发送请求时，请求头都会带上该 Cookie信息（包含 sessionId ）， 然后，服务器通过读取请求头中的 Cookie 信息，获取名称为 JSESSIONID 的值，得到此次请求的 sessionId。 Session 的缺点 Session 机制有个缺点，比如 A 服务器存储了 Session，就是做了负载均衡后，假如一段时间内 A 的访问量激增，会转发到 B 进行访问，但是 B 服务器并没有存储 A 的 Session，会导致 Session 的失效。 Cookies 是什么 HTTP 协议中的 Cookie 包括 Web Cookie 和浏览器 Cookie，它是服务器发送到 Web 浏览器的一小块数据。服务器发送到浏览器的 Cookie，浏览器会进行存储，并与下一个请求一起发送到服务器。通常，它用于判断两个请求是否来自于同一个浏览器，例如用户保持登录状态。 ...

先看看React官网对于Context的介绍 Context 提供了一个无需为每层组件手动添加 props，就能在组件树间进行数据传递的方法。在一个典型的 React 应用中，数据是通过 props 属性自上而下（由父及子）进行传递的，但这种做法对于某些类型的属性而言是极其繁琐的（例如：地区偏好，UI 主题），这些属性是应用程序中许多组件都需要的。Context 提供了一种在组件之间共享此类值的方式，而不必显式地通过组件树的逐层传递 props。 个人理解转成大白话：Context提供了一个局部的全局作用域，使用Context则无需再手动的逐层传递props。 本文主要介绍3种Context的使用方式： React.createContext提供的Provider和Consumer 函数组件：React.createContext提供的Provider和useContext钩子 Class组件：React.createContext提供的Provider和class的contextType属性 第一种：React.createContext提供的Provider和Consumer 先写好使用Context的基础环境条件，后续的代码都是基于此环境 //创建一个文件，暂且命名为context.js，导出createContext()的返回值 import { createContext } from "react"; export default createContext(); 在根组件App.jsx中，导入上面写的context，并使用context提供的Provider组件进行包裹，圈定局部的全局作用域，传值后可以提供给子组件进行消费 当 Provider 的 value 值发生变化时，它内部的所有消费组件都会重新渲染。Provider 及其内部 consumer 组件都不受制于 shouldComponentUpdate 函数，因此当 consumer 组件在其祖先组件退出更新的情况下也能更新。 import React, { createContext } from "react"; import MyContext from "./context"; import GeneralC from "./GeneralC"; import FnC from "./FnC"; import ClassC from "./ClassC"; export default function App() { return ( //Provider组件接收一个value属性，此处传入一个带有name属性的对象 <MyContext.Provider value={{ name: `context's value is string!` }}> {/*这里写后面要进行包裹的子组件,此处先行导入后续需要消费context的3个组件*/} <GeneralC/> <hr/> <FnC/> <hr/> <ClassC/> </MyContext.Provider> ); } 在GeneralC组件中,导入context,使用其提供的Consumer组件来订阅Context的变更,需要一个函数作为子元素,函数的第一个形参便是Provider组件提供的value值 import React, { useReducer } from "react"; import MyContext from "./context"; const GeneralC = () => { return ( // <MyContext.Consumer> {(value) => { return ( <div> 第一种使用Context方式获取的值：{JSON.stringify(value)} </div> ); }} </MyContext.Consumer> ); }; export default GeneralC; 此时页面中应该出现json格式的value值 ...

这篇文章要给大家介绍的是变量对象。 在JavaScript中，我们肯定不可避免的需要声明变量和函数，可是JS解析器是如何找到这些变量的呢？我们还得对执行上下文有一个进一步的了解。 在知识点《执行上下文》中，我们已经知道，当调用一个函数时（激活），一个新的执行上下文就会被创建。而一个执行上下文的生命周期可以分为两个阶段。 创建阶段 在这个阶段中，执行上下文会分别创建变量对象，建立作用域链，以及确定this的指向。 代码执行阶段 创建完成之后，就会开始执行代码，这个时候，会完成变量赋值，函数引用，以及执行其他代码。 从这里我们就可以看出详细了解执行上下文极为重要，因为其中涉及到了变量对象，作用域链，this等很多人没有怎么弄明白，但是却极为重要的概念，它关系到我们能不能真正理解JavaScript。在后面的文章中我们会一一详细总结，这里我们先重点了解变量对象。 变量对象（Variable Object） 变量对象的创建，依次经历了以下几个过程。 建立arguments对象。检查当前上下文中的参数，建立该对象下的属性与属性值。 检查当前上下文的函数声明，也就是使用function关键字声明的函数。在变量对象中以函数名建立一个属性，属性值为指向该函数所在内存地址的引用。如果函数名的属性已经存在，那么该属性将会被新的引用所覆盖。 检查当前上下文中的变量声明，每找到一个变量声明，就在变量对象中以变量名建立一个属性，属性值为undefined。如果该变量名的属性已经存在，为了防止同名的函数被修改为undefined，则会直接跳过，原属性值不会被修改。 许多读者在阅读到这的时候会因为下面的这样场景对于“跳过”一词产生疑问。既然变量声明的foo遇到函数声明的foo会跳过，可是为什么最后foo的输出结果仍然是被覆盖了？ function foo() { console.log('function foo') } var foo = 20; console.log(foo); // 20 其实只是大家在阅读的时候不够仔细，因为上面的三条规则仅仅适用于变量对象的创建过程。也就是执行上下文的创建过程。而foo = 20是在执行上下文的执行过程中运行的，输出结果自然会是20。对比下例。 console.log(foo); // function foo function foo() { console.log('function foo') } var foo = 20; // 上栗的执行顺序为 // 首先将所有函数声明放入变量对象中 function foo() { console.log('function foo') } // 其次将所有变量声明放入变量对象中，但是因为foo已经存在同名函数，因此此时会跳过undefined的赋值 // var foo = undefined; // 然后开始执行阶段代码的执行 console.log(foo); // function foo foo = 20; 根据这个规则，理解变量提升就变得十分简单了。在很多文章中虽然提到了变量提升，但是具体是怎么回事还真的很多人都说不出来，以后在面试中用变量对象的创建过程跟面试官解释变量提升，保证瞬间提升逼格。 在上面的规则中我们看出，function声明会比var声明优先级更高一点。为了帮助大家更好的理解变量对象，我们结合一些简单的例子来进行探讨。 // demo01 function test() { console.log(a); console.log(foo()); var a = 1; function foo() { return 2; } } test(); 在上例中，我们直接从test()的执行上下文开始理解。全局作用域中运行test()时，test()的执行上下文开始创建。为了便于理解，我们用如下的形式来表示 ...

引言 在日常前端开发中，经常需要进行背景或背景图的处理。但是大多数前端er并未真正清楚背景的正确使用方式。经过本章的学习，相信你一定可以解决99%的背景处理问题。 一：简单使用 背景颜色和背景图片是可以共同出现的 div { width: 300px; height: 300px; background-color: red; background-image: url(./imgs/1.jpg); background-repeat: no-repeat; } 页面展示 一：background-repeat background-repeat决定背景图片的平铺方式 属性值 background-repeat:repeat (默认值) background-repeat:no-repeat (不平铺) background-repeat:repeat-x （水平方向平铺） background-repeat:repeat-y （垂直方向平铺） 1. repeat 默认情况下，如果背景图片不能铺满整个盒子时，系统会在水平和垂直方向同时平铺直到覆盖整个盒子 div { width: 300px; height: 300px; background-color: red; background-image: url(./imgs/1.jpg); background-repeat: repeat; } 2.repeat-x 如果背景图片不能将盒子的水平方向铺满，则在水平方向采取平铺处理直到铺满盒子的水平方向。 div { width: 300px; height: 300px; background-color: red; background-image: url(./imgs/1.jpg); background-repeat: repeat-x; } 3.repeat-y 如果背景图片不能将盒子的垂直方向铺满，则在垂直方向采取平铺处理直到铺满盒子的垂直方向。 div { width: 300px; height: 300px; background-color: red; background-image: url(./imgs/1.jpg); background-repeat: repeat-y; } 二：background-position background-positiont决定背景图片在盒子区域的定位位置。其方位由水平和垂直决定 1.px设置 px决定了背景图片在盒子水平和垂直方向偏移指定px的距离。 div { width: 300px; height: 300px; background-color: red; background-image: url(./imgs/1.jpg); background-repeat: no-repeat; background-position: 100px 100px; } ...

Methods 的初始化 在 Vue.js 中，每个组件实例（vm）都会有一个 methods 属性，这个属性包含了组件中定义的所有方法。这些方法需要被初始化到实例上，以便可以在模板和生命周期钩子中被调用。初始化过程如下： function initMethods(vm, methods) { for (var key in methods) { vm[key] = methods[key] == null ? noop : bind(methods[key], vm); } } 这段代码遍历 methods 对象中的每个属性，并将其复制到 Vue 实例（vm）上。如果方法不存在（methods[key] == null），则赋值为一个空函数（noop），以避免对 undefined 的调用。否则，使用 bind 方法将每个方法的 this 绑定到 Vue 实例上。 Methods 作用域的固定 在 JavaScript 中，函数的 this 值是在函数被调用时确定的，而不是在定义时。这可能导致在 Vue 实例的方法中 this 并不指向实例本身，尤其是在方法被传递给其他函数或作为回调函数时。Vue 使用 bind 来解决这个问题，确保 this 总是指向 Vue 实例。 原生和兼容性 bind 实现 Vue.js 提供了两种 bind 的实现：原生的和兼容性的。兼容性实现是为了兼容那些不支持 Function.prototype.bind 的旧浏览器。 function polyfillBind(fn, ctx) { function boundFn(a) { var l = arguments.length; return l ? (l > 1 ? fn.apply(ctx, arguments) : fn.call(ctx, a)) : fn.call(ctx); } boundFn._length = fn.length; return boundFn; } function nativeBind(fn, ctx) { return fn.bind(ctx); } var bind = Function.prototype.bind ? nativeBind : polyfillBind; polyfillBind 函数创建了一个新的函数 boundFn，它在调用时使用 call 或 apply 将 fn 的 this 绑定到 ctx 上。 nativeBind 函数直接使用原生的 bind 方法。 bind 变量根据浏览器是否支持原生 bind 来选择使用哪种实现。 使用 bind 的好处 使用 bind 后，我们可以在组件的方法中直接使用 this 来访问实例的属性和方法，而不用担心 this 的指向问题。这使得代码更加简洁和安全。 ...