LLM

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 一、核心源码地图 先把关键文件放在桌面上： ...

在3D球场项目 (二)中，我们梳理了视频弹幕引擎的整体架构、引擎初始化流程。现在，3D 球场部分基本已经探索完毕，我们接下来就是要解决这个项目的数据驱动部分了。 我们现在研究一下下发数据的来源：Opta，它是全球顶级的体育数据公司，1996 年创立于英国伦敦，现隶属于 Stats Perform，是行业公认的足球数据金标准。 覆盖：20+ 运动、3900+ 赛事、每年 6 万 + 场比赛 规模：7.2PB 历史数据、年采集超 10 亿数据点 精度：单场足球2 万 + 事件点，事件识别准确率 99.8% 腾讯体育采买了 Opta WTA 网球比赛的数据，我们可以通过 Opta 的 API 来获取数据。 根据他们官网的介绍，一个 MA3 网球赛事数据中 typeId 对应的意义如下： 点击展开 / 折叠 Event TypeId 完整对照表 Event TypeId Event Name Description 20 STOP_GAME Indicates that the game has finished. 41 START_SET_1 Start 1st Set 42 START_SET_2 Start 2nd Set 43 START_SET_3 Start 3rd Set 44 START_SET_4 Start 4th Set 45 START_SET_5 Start 5th Set 46 STOP_SET Stop Set 47 T_WO1 w.o. Player 1 48 T_WO2 w.o. Player 2 128 SAFE Safe (No longer used) 129 DANGER Danger (Technical/connection issue at venue) 132 INJ_BREAK Game suspended - Player injured 133 PLAYERS_COMING_OUT Players coming out 141 GAME_ABOUT_TO_START Game about to start 149 GAME_SUSPENDED Game suspended 160 PLAYERS_WARMING_UP Players warming up 162 SHAKE_HANDS_WITH_REFEREE Players shake hands with referee 163 COIN_FLIPPING_FOR_FIRST_SERVER Coin flip to choose first server 164 PLAYERS_TALKING_TO_REFEREE Player(s) talking to the referee 165 REFEREE_CHECKING_POINTMARK Referee checking pointmark 166 BOTH_PLAYERS_SEATED Both players seated 167 PLAYER1_RECEIVING_TREATMENT Player 1 receiving treatment 168 PLAYER2_RECEIVING_TREATMENT Player 2 receiving treatment 169 PLAYERS_GOING_TO_COURT Players going back to court 170 NEXT_GAME_ABOUT_TO_START Next game is about to start 180 T_MORE_THAN_5 Rally, over five shots 181 T_MORE_THAN_10 Rally over ten shots 182 T_MORE_THAN_15 Rally over fifteen shots 187 T_POINT_UNDER_INVESTIGATION Point under investigation 188 T_START_TIE_BREAK Start tie break 191 T_POINT_STOPPED_BY_REF Point stopped by referee 197 UPDATE_SCORE_START Start score update 198 UPDATE_SCORE_FINISHED Score update finished 200 SIDE_CHANGE Side change 206 SHOT_CNT Shot count 216 STATISTIC_VERIFICATION Statistics confirmation 240 NEW_BALLS New balls 241 UMPIRE_ON_COURT UMPIRE ON COURT 242 WARMING_UP_VOLLEY Warming up - volley 243 WARMING_UP_SERVICE Warming up - service 244 ONE_MINUTE One minute 245 TIME Time 246 SHOT_DETAILS Shot details 256 CLS Cancel last sent event 257 CLR Clear events 258 GCC Game conditions changed. 261 SCORER Event details for %RELATED_EVENT% in the %MIN%. minute changed 262 BP Ball position event 264 ODD Odds event (deprecated) 266 TIME_CORRECTION_EVENT Correct timestamp for a missed event 276 START_GAME_CLOCK The (stopped) game clock is (re)started the game is running 277 STOP_GAME_CLOCK The game clock is stopped. Time will not change until Start Game Clock is sent again 278 ADJUST_GAME_CLOCK Game clock value is adjusted manually 279 CSTAT A statistical value is cleared and an additional event with the correct action is sent (e.g. an invalid Ace Home event is replaced by a Service Winner Home) 280 CONF_PERIOD_SCORE Period score confirmed 282 TIME_ADAPTION Time for event %RELATED_EVENT% was adapted by %SEC% seconds 285 PLAYER_DATA_CONFIRMED Player data for %RELATED_EVENT% in the %MIN% confirmed 513 SYS_MSG System Message 514 SCOUT_IN_STADION Scout in Stadium 515 CONNECTION_PROBLEMSSCOUT_OFFLINE Connection problems Scout offline 516 CONNECTION_PROBLEMS Connection problems 517 TRANSMISSION_ONLINE Transmission online 520 LINEUP_CHANGED Line-up changed 524 JERSEY_CHANGED Jersey colors updated 782 GAME CANCELLED Automatic “Game cancelled” event after first “cancellation” System message is sent 1152 T_SERVE1 Service Player 1 1153 T_1ST_SERVICE1 1st service Player 1 1154 T_2ND_SERVICE1 2nd service Player 1 1155 T_NA1 Net approach player 1 1156 T_W_FH1 Winner (forehand) Player 1 1157 T_W_BH1 Winner (backhand) Player 1 1158 T_FE_FH1 Forced error (forehand) Player 1 1159 T_FE_BH1 Forced error (backhand) Player 1 1160 T_UE_FH1 Unforced error (forehand) Player 1 1161 T_UE_BH1 Unforced error (backhand) Player 1 1162 T_HE1 Hawkeye Player 1 1163 T_WBR1 Warning by referee Player 1 1164 T_CBR1 Cautioned by referee Player 1 1165 T_SRV_NET1 Net Player 1 1166 T_SRV_OUT1 Out Player 1 1167 T_SRV_FF1 Foot fault Player 1 1168 T_SRV_DF1 Double fault Player 1 1169 T_SRV_A1 Ace Player 1 1170 T_SRV_SW1 Service winner Player 1 1171 T_SRV_RW_FH1 Return winner (forehand) Player 1 1172 T_SRV_IN1 Serve in Player 1 1173 T_POINT1 Point Player 1 1174 T_CONF1 Confirm Point Player 1 1175 T_GAME1 Game Player 1 1176 T_SET1 Set Player 1 1177 T_BL1 Baseline Player 1 1178 T_SRV_NR1 Net/Retake Player 1 1179 T_W1 Winner Player 1 1180 T_FE1 Forced error Player 1 1181 T_UE1 Unforced error Player 1 1182 T_SRV_RW_BH1 Return winner (backhand) Player 1 1183 T_V_FH1 Volley (forehand) Player 1 1184 T_V_BH1 Volley (backhand) Player 1 1185 T_BB1 Break ball Player 1 1186 T_B1 Break Player 1 1187 T_HES1 Hawk eye successful Player 1 1188 T_ITO1 Injury Timeout Player 1 1189 T_START_SRV1 Start Service Player 1 1190 T_WARNING1 1st offence - warning Player 1 1191 T_PENALTY_POINT1 2nd offence - penalty point Player 1 1192 T_PENALTY_GAME1 3rd offence - penalty game Player 1 1193 T_DISQUALIFICATION1 Disqualification Player 1 1194 T_UE_NET1 Unforced error net Player 1 1195 T_FE_NET1 Forced error net Player 1 1196 T_SUCCESSFUL_NET_APPROACH1 Successful net approach Player 1 1197 T_TIME_VIOLATION1 Time violation Player 1 1198 T_PENALTY_POINT1 T_UNSUCCESSFUL_NET_APPROACH1 Unsuccessful net approach Player 1 1199 T_AT_NET1 At net Player 1 1200 T_AT_BASELINE1 At baseline Player 1 1201 T_SET_BALL1 Set ball Player 1 1202 T_MATCH_BALL1 Match ball Player 1 2176 T_SERVE2 Service Player 2 2177 T_1ST_SERVICE2 1st service Player 2 2178 T_2ND_SERVICE2 2nd service Player 2 2179 T_NA2 Net approach player 2 2180 T_W_FH2 Winner (forehand) Player 2 2181 T_W_BH2 Winner (backhand) Player 2 2182 T_FE_FH2 Forced error (forehand) Player 2 2183 T_FE_BH2 Forced error (backhand) Player 2 2184 T_UE_FH2 Unforced error (forehand) Player 2 2185 T_UE_BH2 Unforced error (backhand) Player 2 2186 T_HE2 Hawkeye Player 2 2187 T_WBR2 Warning by referee Player 2 2188 T_CBR2 Cautioned by referee Player 2 2189 T_SRV_NET2 Net Player 2 2190 T_SRV_OUT2 Out Player 2 2191 T_SRV_FF2 Foot fault Player 2 2192 T_SRV_DF2 Double fault Player 2 2193 T_SRV_A2 Ace Player 2 2194 T_SRV_SW2 Service winner Player 2 2195 T_SRV_RW_FH2 Return winner (forehand) Player 2 2196 T_SRV_IN2 Serve in Player 2 2197 T_POINT2 Point Player 2 2198 T_CONF2 Confirm Point Player 2 2199 T_GAME2 Game Player 2 2200 T_SET2 Set Player 2 2201 T_BL2 Baseline Player 2 2202 T_SRV_NR2 Net/Retake Player 2 2203 T_W2 Winner Player 2 2204 T_FE2 Forced error Player 2 2205 T_UE2 Unforced error Player 2 2206 T_SRV_RW_BH2 Return winner (backhand) Player 2 2207 T_V_FH2 Volley (forehand) Player 2 2208 T_V_BH2 Volley (backhand) Player 2 2209 T_BB2 Break ball Player 2 2210 T_B2 Break Player 2 2211 T_HES2 Hawk eye successful Player 2 2212 T_ITO Injury Timeout Player 2 2213 T_START_SRV2 Start Service Player 2 2214 T_WARNING2 1st offence - warning Player 2 2215 T_PENALTY_POINT2 2nd offence - penalty point Player 2 2216 T_PENALTY_GAME2 3rd offence - penalty game Player 2 2217 T_DISQUALIFICATION2 Disqualification Player 2 2218 T_UE_NET2 Unforced error net Player 2 2219 T_FE_NET2 Forced error net Player 2 2220 T_SUCCESSFUL_NET_APPROACH2 Successful net approach Player 2 2221 T_TIME_VIOLATION2 Time violation Player 2 2222 T_AT_NET2 Unsuccessful net approach Player 2 2223 At net Player 2 2224 T_AT_BASELINE2 At baseline Player 2 2225 T_SET_BALL2 Set ball Player 2 2226 T_MATCH_BALL2 Match ball Player 2 PBP = Play-by-Play（逐回合 / 逐事件数据），就是把一场比赛里每一次事件都按时间线秒级记录下来的最细粒度原始数据流。口语里也叫 “逐帧数据 / 流水账数据”。网球赛事的数据，都是以这个形式下发的，一段数据可能下发的数据是这样的： ...

项目终于来到了落地环节。 在3D球场项目 (三)里，我们用一段离线 PBP 数据 + 一次 LLM 调用，把"导演 Agent"的雏形跑了起来。Demo 阶段的脚本是离线生成、整段 导入的；那时的 LLM 既负责"想象画面"，又顺手把动作、镜头、音效、解说词都打包了。 但项目一旦从 Demo 推到线上，导演 Agent 立刻面对三件事： Opta 数据是按 Point 持续推过来的，不会一次性把一场比赛喂给大模型； 大模型 会失败、会延迟，一旦卡住，球员就只能停在 idle； 客户端会断流、会重连，需要一个"刚才那一拍发生了什么"的回放接口。 上一章末尾提到的三个坑——player 卡 idle、两人一直来回发球、长链断了客户端不知道 怎么补——本质都来自这三件事。线上版本的 livecast 服务（基于 tRPC-Go）做了一次完整的 工程化：导演 Agent 不再是单一 LLM，而是 确定性脚本层 + LLM 解说层 + 双重下发保险 的组合。本篇就讲这套组合怎么搭起来。 一、网球数据是怎么进来的 NBA 那边的 PBP 是 单条 投递：上游每发生一个篮球事件，就经 Kafka 推一条消息过来。 但网球数据天然是 按回合聚合 的——Opta 在一个 Point（一个回合）结束之后才会一次性 把这一拍涉及的所有事件下发，所以服务端也用了批量消费通道： Kafka topic: pbp_flow └─ FlowConsumer.BatchHandle(msgs []*sarama.ConsumerMessage) └─ livecastSvc.ProcessBatchPBPFlow(payloads [][]byte) 进入 ProcessBatchPBPFlow 之后，先按 mid（match id）做二级分组、过滤掉非网球的批次， 再交给真正的 pipeline。两道闸门决定一场比赛的事件能不能走 3D 流水线： ...

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 直接给指令，不提供任何示例： ...