AI

大语言模型（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 直接给指令，不提供任何示例： ...

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 提出了一个根本性的反转： ...

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

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年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 几个关键抽象： ...

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拒绝"] 上下文收集是关键——模型看到的上下文越好，补全质量越高： ...

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需要具备： ...