AI 面试

ChatGPT能写文章、能回答问题，但你让它帮你订一张机票，它做不到。它能告诉你"你应该去携程搜一下"，但它没法真的打开网页、输入日期、比价、下单。 **AI Agent（智能体）**就是为了解决这个问题——让LLM不仅能"想"，还能"做"。Agent = LLM + 工具使用 + 自主规划 + 记忆。 一、从聊天机器人到智能体 1.1 纯LLM的局限 一个纯粹的LLM本质上是一个"无状态的文本生成器"： graph LR IN["输入文本"] --> LLM["LLM"] LLM --> OUT["输出文本"] 它有几个根本性的限制： 限制 表现 无法执行动作 不能调API、不能操作文件、不能访问数据库 无持久记忆 每次对话结束后就"忘了" 知识过时 无法获取训练数据之后的信息 无法自主规划 不能将复杂任务分解并逐步执行 单轮思考 一次生成就结束，不能自我检查和修正 1.2 Agent的定义 AI Agent是一个以LLM为"大脑"的自主系统，能够： 感知：理解用户的意图和当前环境状态 规划：将复杂目标分解为可执行的步骤 行动：调用外部工具完成具体操作 观察：获取行动的结果 反思：根据结果调整策略 graph TD USER["用户目标"] --> PERCEIVE["感知理解意图"] PERCEIVE --> PLAN["规划分解任务"] PLAN --> ACT["行动调用工具"] ACT --> OBSERVE["观察获取结果"] OBSERVE --> REFLECT["反思是否完成？"] REFLECT -->|未完成| PLAN REFLECT -->|已完成| RESULT["返回结果"] 二、Agent的核心组件 2.1 架构总览 graph TB subgraph Agent ["AI Agent"] LLM["LLM（大脑）"] PLAN["规划模块"] MEM["记忆系统"] TOOL["工具集"] end USER["用户"] --> LLM LLM --> PLAN PLAN --> LLM LLM --> MEM MEM --> LLM LLM --> TOOL TOOL --> LLM LLM --> USER 2.2 LLM：Agent的大脑 LLM负责理解、推理和决策。作为Agent大脑的LLM需要具备： ...

AI编程工具正在重塑软件开发的工作方式。从简单的代码补全到自主完成复杂任务的编程Agent，这个领域在短短两三年内经历了巨大的变化。本文梳理AI编程工具的核心概念、工作原理和实践方法。 一、AI编程工具的演进 1.1 三代AI编程工具 graph LR G1["第一代代码补全Copilot (2021)"] --> G2["第二代对话式编程ChatGPT (2022)"] G2 --> G3["第三代编程AgentCursor/Devin (2024+)"] 代际 交互方式 能力范围 代表产品 第一代 行内补全，按Tab接受 单行/单函数级别 GitHub Copilot 第二代 对话框问答 代码片段级别 ChatGPT、Claude 第三代 Agent模式，自主执行 跨文件/跨系统级别 Cursor、Windsurf、Devin 1.2 当前主流工具对比 工具 类型 核心特点 GitHub Copilot IDE插件 最早的AI编程助手，集成在VS Code/JetBrains等主流IDE中 Cursor 独立IDE 基于VS Code深度定制，Agent模式、多文件编辑 Windsurf 独立IDE Codeium推出，强调"Flow"模式的流畅体验 Claude Code CLI工具 终端中运行的编程Agent，适合命令行工作流 Devin 云端Agent 全自主编程Agent，自带开发环境 Amazon Q Developer IDE插件 AWS深度集成，擅长云原生开发 二、AI编程工具的工作原理 2.1 代码补全的原理 代码补全是最基础的能力。以Copilot为例： graph LR CTX["上下文收集当前文件内容打开的相关文件光标位置"] --> PROMPT["构造Prompt"] PROMPT --> LLM["LLM（Codex/GPT-4）"] LLM --> SUGGEST["补全建议"] SUGGEST --> USER["用户Tab接受 / Esc拒绝"] 上下文收集是关键——模型看到的上下文越好，补全质量越高： ...

Claude Code 的 agent 到底是怎么被设计成一个能长时间工作、能分派子 agent、能记忆、能压缩上下文、也能可靠停下来的系统的？ Claude Code 最值得研究的地方，不是它“能调用工具”，而是它把模型、工具、记忆、上下文、后台任务、hook 和权限系统编成了一个稳定的 agent harness。 一句话概括：Claude Code 的 agent 不是一个模型循环，而是三层循环叠在一起：主 query 循环负责推理和工具回灌；工具循环负责受控执行和并发；任务循环负责子 agent、后台 agent、记忆整理和长任务生命周期。 flowchart TD User["用户输入 / 队列消息"] --> Query["query.ts 主循环"] Query --> Model["流式模型调用"] Model -->|没有 tool_use| StopPath["停止路径stop hooks / token budget / completed"] Model -->|产生 tool_use| ToolLoop["工具执行循环"] ToolLoop --> Attach["附件注入记忆 / 变更文件 / 任务通知 / 技能"] Attach --> Query Query --> Compact["上下文治理tool budget / microcompact / autocompact / reactive compact"] Query --> Memory["记忆系统CLAUDE.md / AutoMem / Session Memory"] Query --> AgentTool["AgentTool"] AgentTool --> SubAgent["runAgent 子循环"] SubAgent --> LocalTask["LocalAgentTask前台 / 后台 / 可恢复"] LocalTask --> Attach 一、核心源码地图 先把关键文件放在桌面上： ...

2025年WWDC上，Apple把Apple Intelligence背后的那个"设备端基础模型"第一次对开发者开放——这就是FoundationModels框架。过去要在App里接入LLM，基本只有两条路：调OpenAI/Claude这类云端API，或者自己在端上集成llama.cpp、MLC、Core ML等推理框架。前者有隐私和成本问题，后者有工程门槛和包体积问题。FoundationModels试图提供第三条路：一个系统级的、免费的、离线可用的、原生Swift的LLM API。 本文从框架定位开始，一路讲到Guided Generation、Tool Calling、Streaming、Adapter微调等细节，目标是让你在读完后能直接上手用它写出一个生产可用的功能。 一、FoundationModels是什么 1.1 一句话定义 FoundationModels是iOS 26 / macOS 26及之后的系统框架，提供对设备端Apple Intelligence语言模型的编程访问能力。模型本身约3B参数，经过4-bit量化，常驻系统，不计入App包体积，所有推理在设备上完成。 1.2 能做什么 / 不能做什么 能做 不能做 文本生成、摘要、分类、抽取、改写、翻译 世界知识问答（模型太小，不适合当"百科") 结构化输出（生成指定Swift类型） 图像生成 / 视频生成 工具调用（Function Calling） 嵌入向量生成（Embedding） 短对话、小规模推理 长上下文的复杂推理（窗口有限） 完全离线、无需联网 替代GPT-4这类前沿大模型 定位非常清楚：它是一个"端侧小而美"的模型，负责那些没必要上云、对延迟/隐私/成本敏感的任务。 1.3 为什么值得iOS开发者关注 零成本：不像调OpenAI API，每token都花钱。 零延迟网络层：首token延迟可以做到100ms级。 隐私合规：输入不出设备，符合医疗、金融、教育场景的合规要求。 离线可用：地铁、飞机、隧道里也能跑。 原生Swift DSL：宏驱动的@Generable、Tool协议，跟SwiftUI一样"声明式"。 与系统深度集成：可直接访问Apple Intelligence上下文（比如屏幕识别、个人数据等，受权限约束）。 二、整体架构 graph TB subgraph APP ["应用层"] UI["SwiftUI / UIKit"] VM["ViewModel"] end subgraph FM ["FoundationModels Framework"] SLM["SystemLanguageModel模型句柄 + 可用性"] SESSION["LanguageModelSession会话对象 / 上下文"] GEN["Generable宏结构化输出"] TOOL["Tool协议工具调用"] STREAM["ResponseStream流式输出"] GUARD["Guardrails安全过滤"] end subgraph SYSTEM ["系统层"] ANE["Apple Neural Engine"] GPU["GPU"] MODEL["On-device Foundation Model≈3B params, 4-bit quant"] ADAPTER["LoRA Adapters"] end UI --> VM VM --> SESSION SESSION --> SLM SESSION --> GEN SESSION --> TOOL SESSION --> STREAM SESSION --> GUARD SLM --> MODEL MODEL --> ANE MODEL --> GPU ADAPTER --> MODEL 几个关键抽象： ...

LLM很聪明，但它被困在一个"文本沙箱"里——它只能接收文本、输出文本。要让LLM调用API、查数据库、操作文件，就需要一个"桥梁"协议来连接LLM与外部世界。 Function Calling和**MCP（Model Context Protocol）**就是这样的桥梁。它们的目标相同——让LLM能调用外部工具——但设计理念和使用场景有很大不同。本文将详细对比这两种方案。 一、Function Calling：LLM原生的工具调用 1.1 基本原理 Function Calling是LLM提供商（OpenAI、Anthropic、Google等）在模型层面支持的工具调用能力。核心思路是： 你告诉LLM有哪些函数可用（函数名、参数定义、功能描述） LLM根据用户的问题判断是否需要调用函数 如果需要，LLM输出一个结构化的函数调用请求（而不是自然语言） 你的代码执行这个函数，把结果返回给LLM LLM基于结果生成最终回答 sequenceDiagram participant U as 用户 participant App as 应用程序 participant LLM as LLM API participant Tool as 外部工具/API U->>App: "北京今天天气怎么样？" App->>LLM: 用户消息 + 可用函数定义 LLM->>App: 函数调用请求get_weather(city="北京") App->>Tool: 调用天气API Tool->>App: {"temp": 22, "weather": "晴"} App->>LLM: 函数执行结果 LLM->>App: "北京今天天气晴朗，气温22°C" App->>U: 最终回答 关键点：LLM自身并不执行函数，它只是生成"我想调用这个函数"的结构化指令，真正的执行由应用程序完成。 1.2 函数定义 以OpenAI的格式为例，开发者需要用JSON Schema描述每个可用的函数： { "tools": [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的当前天气信息", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，如'北京'、'上海'" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "description": "温度单位" } }, "required": ["city"] } } } ] } LLM通过阅读这个定义来理解：这个函数叫什么、干什么用、需要什么参数。description字段的质量直接影响LLM能否正确选择和调用函数。 ...

基于 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”。 ...

2026 年 4 月，Andrej Karpathy 在 GitHub Gist 上发布了一份名为 llm-wiki.md 的"想法文档"（idea file），短短几天收获了 5000+ 星和 5000+ fork。这篇文档篇幅不长，却被评价为"后 RAG 时代"个人知识管理的一个**分类定义性（category-defining）**框架。 原文地址：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f Karpathy 写这篇文档的风格非常有意思：它不是一份实现规范，而是一份"可以复制粘贴给你自己的 LLM Agent（Claude Code、Codex、OpenCode/Pi 等）“的模式描述。它告诉 Agent 模式的核心是什么，剩下的细节（目录结构、schema 约定、页面格式、工具链）交给用户和 Agent 一起协同演化。 本文将详细拆解这份文档的核心思想，并结合社区讨论（scale 极限、Zettelkasten 替代方案、反对派观点等）给出一个完整解读。 一、问题起点：RAG 的"每次从零开始” 大多数人今天使用 LLM 处理文档的方式是 RAG（检索增强生成）： 把一堆文档上传到系统 查询时 LLM 从原文中检索相关片段 基于片段合成答案 NotebookLM、ChatGPT 文件上传、绝大多数 RAG 系统都是这个模式。 1.1 RAG 的根本局限：没有累积 Karpathy 点出了 RAG 的一个关键问题：LLM 每次都在从零开始重新发现知识。 问一个需要综合 5 篇文档的微妙问题 → LLM 每次都要重新找出相关片段，重新拼接，重新推理 上一次你问过的关键问题的答案，下一次再问时不会被保留 跨源的矛盾、交叉引用、细微的关联 —— 每次都要重新建立 什么都没有被"沉淀"下来。 这就像每次考试都重新读一遍教科书，却从不做笔记、从不整理知识卡片、从不画思维导图。 1.2 LLM Wiki 的核心差异 LLM Wiki 提出了一个根本性的反转： ...

大语言模型（LLM）的能力边界很大程度上取决于你怎么跟它说话。同样的模型，一个精心设计的Prompt可以得到专业级的回答，一个随意的Prompt可能只得到平庸甚至错误的结果。Prompt Engineering就是研究如何有效地与LLM沟通的技术。 一、Prompt的基本构成 1.1 一个Prompt的解剖 一个高质量的Prompt通常包含以下要素： graph TD P["完整的Prompt"] --> R["角色Role"] P --> C["上下文Context"] P --> I["指令Instruction"] P --> E["示例Examples"] P --> F["格式要求Format"] P --> CO["约束Constraints"] 要素 作用 示例 角色 设定模型的身份和专业背景 “你是一位有10年经验的iOS架构师” 上下文 提供背景信息 “我们的项目使用MVVM架构，Swift语言” 指令 明确说明任务 “请review以下代码并指出问题” 示例 展示期望的输入输出格式 给出一个输入-输出样例 格式要求 指定输出的结构 “以Markdown表格形式输出” 约束 限制条件 “不超过500字"“只使用Swift标准库” 1.2 System Prompt vs User Prompt 在API调用中，消息分为不同的角色： { "messages": [ { "role": "system", "content": "你是一位资深iOS开发工程师，擅长性能优化。回答时给出具体的代码示例。" }, { "role": "user", "content": "如何优化UITableView的滚动性能？" } ] } System Prompt：设定模型的整体行为、角色和约束，贯穿整个对话 User Prompt：具体的问题或指令 Assistant：模型的历史回复，提供对话上下文 二、核心Prompt技术 2.1 Zero-Shot Prompting 直接给指令，不提供任何示例： ...

大语言模型（LLM）能流畅地写文章、回答问题、编写代码，但它有一个根本性的局限：它的知识被冻结在训练数据截止的那一刻。问它昨天发生了什么新闻？不知道。问它你公司内部的技术文档？更不知道。 更棘手的是，LLM有时候会"一本正经地胡说八道"——这就是所谓的**幻觉（Hallucination）**问题。模型会自信满满地编造一个不存在的论文引用、一个错误的API参数、甚至一个虚构的历史事件。 **RAG（Retrieval-Augmented Generation，检索增强生成）**正是为解决这些问题而生。它的核心思想简单而有效：在让LLM回答之前，先从外部知识库中检索相关信息，把这些信息塞到提示词（Prompt）里，让LLM基于真实资料来回答。 一、RAG的核心思想 1.1 一个直觉的类比 想象你是一个闭卷考试的学生（这就是纯LLM）——只能靠记忆作答，记不清的地方就只能猜。 现在允许你带一本参考书（这就是RAG）——遇到不确定的问题，先翻书找到相关段落，然后基于书中的内容来组织答案。 显然，开卷考试的准确率会高得多。 1.2 RAG的核心价值 LLM的局限 RAG的解决方案 知识过期，无法获取训练截止后的信息 随时更新知识库，实时生效 幻觉问题，生成不存在的信息 基于真实文档生成，可追溯来源 垂直领域知识不足 接入专业知识库，提供领域专业回答 更新成本高，Fine-tuning代价大 只需更新知识库，成本低且灵活 1.3 RAG的基本流程 graph LR Q["用户提问"] --> R["检索器Retriever"] KB["知识库"] --> R R --> C["相关文档片段"] C --> P["构造Prompt问题 + 相关文档"] P --> LLM["大语言模型"] LLM --> A["生成回答"] 三个核心步骤： 检索（Retrieve）：根据用户的问题，从知识库中找到最相关的文档片段 增强（Augment）：将检索到的信息与原始问题一起构造成Prompt 生成（Generate）：LLM基于增强后的Prompt生成回答 二、从关键词到语义：检索方式的演进 2.1 传统关键词搜索的局限 最简单的检索方式是关键词匹配。比如用户问"如何购买商品？"，搜索引擎会提取关键词"购买"、“商品”，然后去匹配包含这些词的文档。 问题很明显： 文档中写的是"下单流程说明"——语义完全一致，但没有任何关键词重合 无法理解同义词：“购买"vs"下单"vs"采购"vs"买” 必须精确匹配关键词，用词不同就检索不到 我们需要一种理解语义的检索方式。 2.2 文本嵌入（Text Embedding） 文本嵌入模型（如OpenAI的text-embedding-3-small、BGE等）将文本转换为高维向量（通常512/768/1024/1536维），使得语义相近的文本在向量空间中距离相近： "如何购买商品？" → [0.23, -0.15, 0.82, ...] (768维向量) "下单流程说明" → [0.21, -0.12, 0.79, ...] ← 向量很近，语义匹配! "今天天气真好" → [-0.65, 0.43, -0.21, ...] ← 向量很远 在高维向量空间中，每个维度代表不同的语义特征（如情感倾向、主题领域、动作类型等）。语义相似的文本会在空间中聚集在一起——“购买”、“下单”、“采购"形成一个语义簇，而"天气预报"则远离这个簇。 ...

ChatGPT、Claude、Gemini——这些模型的核心都是同一个架构：Transformer。它在2017年由Google的论文"Attention Is All You Need"提出，彻底改变了自然语言处理（NLP）领域，随后席卷了计算机视觉、语音、蛋白质折叠等几乎所有AI领域。 我们从最直觉的角度出发，一步步搞清楚Transformer到底在做什么。 一、从序列到序列：Transformer要解决什么问题 1.1 语言的本质是序列 一句话是一个词的序列： "我 今天 很 开心" → [我, 今天, 很, 开心] 语言模型的核心任务是：给定前面的词，预测下一个词。 "我 今天 很" → ?（开心？难过？忙碌？） 但词与词之间的关系非常复杂。“它"指代谁？“银行"是河岸还是金融机构？这取决于上下文中其他词的信息。 1.2 RNN的困境 在Transformer之前，处理序列的主流方法是循环神经网络（RNN）。RNN像一个人从左到右逐词阅读，用一个"记忆状态"来记住看过的内容： graph LR X1["我"] --> H1["h₁"] H1 --> H2["h₂"] X2["今天"] --> H2 H2 --> H3["h₃"] X3["很"] --> H3 H3 --> H4["h₄"] X4["开心"] --> H4 问题在于： 长距离依赖困难：信息需要经过很多步才能从序列开头传到末尾，容易丢失 无法并行：必须逐步处理，前一步完成才能开始后一步，训练很慢 Transformer的核心洞察是：不需要逐步处理，让序列中的每个位置直接与所有其他位置交互。这就是"注意力（Attention）“机制。 二、词嵌入：给词语一个数学身份 2.1 从独热编码到词向量 计算机不认识"猫”、“狗"这样的文字。我们需要把词转换成数字。 最朴素的方式是独热编码（One-Hot Encoding）：假设词汇表有50,000个词，每个词用一个50,000维的向量表示，只有对应位置是1，其余全是0。 "猫" → [0, 0, ..., 1, ..., 0, 0] (第3721个位置是1) "狗" → [0, 0, ..., 0, 1, ..., 0, 0] (第5042个位置是1) 问题：在这种表示下，“猫"和"狗"的距离与"猫"和"经济学"的距离一样远——完全丢失了语义信息。 ...