文科生 AI Coding 入门：一文理清：LLM、Token、上下文、API、Agent、Claude Code、RAG 等概念

前言

1. LLM — 一切的基石

LLM（Large Language Model，大语言模型）是通过海量文本训练的神经网络，本质是一个”文本预测器”——输入一段文字（prompt），它逐 token 预测最可能的下文。

核心能力：理解、生成、推理、总结、翻译、编码。

核心局限：纯 LLM 是 stateless 的文本映射函数。它没有记忆（每次调用独立）、不知道当前时间、不能上网搜索、无法执行代码或操作文件。它只做一件事——给定文本，预测后续文本。

目前主流 LLM：

• GPT 系列（OpenAI）：GPT-4o, GPT-4.5, o3/o4
• Claude 系列（Anthropic）：Claude Opus 4, Sonnet 4.6, Haiku 4.5
• DeepSeek 系列：DeepSeek-V3, DeepSeek-R1
• Gemini 系列（Google）：Gemini 2.5 Pro/Flash
• 开源模型：Llama 系列（Meta）、Qwen 系列（阿里）、Mistral 系列

日常交流中”模型””LLM””AI”经常混用，严格来说不是一个东西，但不妨碍沟通。

2. Token 与上下文窗口 — 理解 LLM 的两个关键度量

Token

Token 是 LLM 处理文本的最小单位，不是字也不是词。英文中大约 1 token ≈ 0.75 个单词（hello world= 2 tokens），中文大约 1 token ≈ 0.5 个汉字（”你好世界” ≈ 4 tokens）。不同模型的分词器（tokenizer）不同，同一个文本在不同模型上的 token 数会有差异，但大致比例如上。

为什么 token 重要：

• 计费单位：API 按 token 计费（input + output 分别计价，output 通常更贵）
• 硬限制：每个模型的上下文窗口用 token 数定义
• 推理成本：模型每生成一个 token 就要做一次完整的前向计算

上下文窗口（Context Window）

上下文窗口 = 模型单次能”看到”的最大 token 总量（输入 + 输出）。

“百万上下文”指的就是这个窗口达到 100 万 token 级别。以中文计，约 50 万字——一本《三体》的量。

几个主流模型的上下文窗口：

上下文窗口大的实际意义：可以一次扔进去整本书、整个代码库、大量文档让模型分析，不需要拆分。但要注意——窗口越大，推理越慢，成本也越高（input 按 token 计费）。并且长上下文中问靠后的信息，模型可能关注不到（”lost in the middle” 效应），并非窗口大就万事大吉。

3. API 与 API Key — 程序化访问模型的能力

API

API（Application Programming Interface）在 LLM 语境下指的是模型提供商暴露的 HTTP 接口。你通过标准的 REST 请求（JSON in → JSON out）调用云端模型。这是最基础的”模型即服务”形态。

你的代码 → POST JSON → https://api.openai.com/v1/chat/completions → 模型推理 → JSON 响应 → 你的代码

请求体大致长这样：

{"model": "deepseek-chat","messages": [    {"role": "system", "content": "你是一个有用的助手。"},    {"role": "user", "content": "解释什么是量子纠缠"}  ],"temperature": 0.7,"max_tokens": 4096}

API Key

API Key 是你的身份凭证。它是一个长字符串（如 sk-xxxxxxxx），放在 HTTP 请求头里，用来告诉服务端”这个请求是谁发的、从哪个账户扣费”。

关键注意事项：

• API Key 是密钥，不能泄露。提交到 GitHub 上的代码里不要硬编码 Key，用环境变量或 secret manager 管理
• Key 泄露 = 别人能用你的额度随意调用（你的账单会很刺激）
• 各厂商的 Key 格式不同但不互通（OpenAI 的 Key 不能调 DeepSeek 的 API）

4. 网页端/App vs API — 最关键的区分

这是误解最重的地方。很多人以为网页版 DeepSeek/ChatGPT 和 API 只是”交互方式不同”——其实区别要大得多。

4.1 模型能力：降智版 vs 满血版

网页端/App 运行的是降智版（量化、裁剪、蒸馏后的模型），而非完整模型。原因很简单——

• 网页用户量巨大（百万级并发），且多数免费或低价订阅
• 服务商要在有限 GPU 集群上承载海量请求，必须压缩推理成本
• 手段：INT8/INT4 量化、模型蒸馏、KV cache 激进复用、减少推理计算量、用更小的模型 variant

API 运行的才是满血版——你按 token 付费，服务商给你完整模型权重和完整推理精度。大多数 API 端跑的是 BF16/FP16 精度的原始模型，没有做推理优化层面的降级。

直接表现：

• 同一道复杂的推理题，API 能做对，网页版做错——这很常见
• 网页版可能没用最顶级的模型（比如 OpenAI 把 o3 只放 API，ChatGPT Plus 默认用 GPT-4o；DeepSeek 网页版可能在不同时段切不同大小的模型）

4.2 架构本质：Agent vs 裸模型

这才是核心认知：网页端/App 本质上是预构建的 Agent，而非裸 LLM。

当你用 ChatGPT 网页版时，产品层已经集成了：

• 网络搜索工具：模型可以自主决定是否搜索
• 文件上传与解析：PDF/图片/表格自动解析为文本喂给模型
• 图片生成：DALL·E 集成
• 代码执行：ChatGPT 的 Code Interpreter 可以跑 Python
• 多轮对话管理：自动裁剪、摘要历史消息以保证不超出上下文窗口
• 安全合规层：内容过滤、合规检查、输出审查
• 系统级 Prompt：定义产品行为边界的隐藏指令

所有这些——工具调用、对话管理、安全层——是产品方替你搭好的 Agent 框架。你只需要在对话框里打字。

而 API 给你的是什么？一个裸模型，仅此而已。

你用 API 调 chat/completions，得到的就是”text in → text out”。它不会自己搜索、不会读文件、不会执行代码、不会管理对话历史——这些全都要你自己实现。

这就引出了下一个核心问题：当你通过 API 调用模型，如何让它”能动起来”？

5. Agent — 让模型拥有手脚和自主决策能力

5.1 定义

Agent = LLM + 工具集 + 自主决策循环。

• LLM：大脑，负责理解和推理
• 工具集：搜索 API、代码执行器、数据库查询、文件系统操作、其他外部 API……
• 决策循环：观察 → 思考 → 行动 → 观察结果 → 再思考 → … → 输出最终答案

5.2 循环机制

Task: "帮我拉取最近一周的 GitHub issues，汇总到一个 markdown 文件"Step 1 — 思考：需要调用 GitHub API，参数是日期范围Step 2 — 行动：调用 GitHub API 工具，传入 repo 和日期Step 3 — 观察：拿到 15 条 issue 的 JSONStep 4 — 思考：数据拿到了，需要提取标题、标签、作者，写成 markdownStep 5 — 行动：调用文件写入工具，生成 summary.mdStep 6 — 判断：任务完成，返回"已生成 summary.md"

纯 LLM 面对同样的问题，只能给你一段”你可以这样做……”的建议文本。

5.3 Agent 并不神秘

从代码层面看，Agent 就是一个 while 循环：

whilenot task_complete:    next_action = llm.think(messages, available_tools)if next_action is final_answer:break    result = execute(next_action)      # 执行工具调用    messages.append(result)            # 把结果塞回对话

关键是：

• LLM 必须支持 function calling / tool use（不是所有模型都支持，老模型不行）
• 工具描述要写清楚（模型靠描述文本来决定调哪个工具）
• 循环终止条件要设计好（否则可能死循环）

5.4 回到前面的关键认知

一句总结：网页端 = 别人给你装好了一台带自动驾驶的汽车，但你不知道发动机实际多大马力（甚至可能是个三缸机）。API = 卖给你一台裸发动机，马力写明了，但方向盘、轮胎、车架、自动驾驶系统都得你自己装。

6. Claude Code — API 侧 Agent 的标杆实现

Claude Code是 Anthropic 用自家 Claude 模型构建的编程 Agent，运行在终端中。你可以把它理解为上面 Agent 循环的一个生产级实现，只不过工具集全部围绕软件开发：

• LLM 层：Claude（Opus/Sonnet/Haiku），通过 API 调用，满血模型
• 工具层：读/写/编辑文件（Read/Write/Edit）、执行 Shell 命令（Bash）、全局搜索（Grep/Glob）、Git 操作、网络搜索、子 Agent 调度……
• Agent 逻辑：理解任务 → 分析代码库 → 改代码 → 跑测试 → 观察结果 → 修复 → 提交

和网页端编程助手的本质区别：

• 网页端 ChatGPT/DeepSeek 只能告诉你”这段代码怎么改”
• Claude Code 直接改你的代码、跑你的测试、修你的 bug——不需要你在中间当”传话筒”

Claude Code 不是另一个 LLM——它没有自己的模型权重。它是一个应用层项目，底层调 Claude API。同理，Cursor、GitHub Copilot 也都是 Agent 产品，区别在于它们接入的模型不同、工具集不同、产品形态不同。

7. RAG — 让模型能检索你的私有知识

7.1 问题

LLM 的训练数据是静态的（有截止日期），且不包含你的私有文档——你的公司内部文档、你的论文库、你的个人笔记，模型见都没见过。直接问它”根据我的项目文档，这个 API 的参数是什么？”，它只能瞎编（幻觉）。

7.2 RAG 做了什么

RAG（Retrieval-Augmented Generation，检索增强生成）在调用 LLM 之前，先从你的文档库中检索相关内容，拼到 prompt 里一起发给模型。

用户问题 → 在本地知识库中检索相关文档段落 → 拼入 prompt → 发给 LLM → LLM 基于检索结果回答

关键的组成部分：

• 文档索引（Indexing）：把 PDF/文档切片（chunking），每段用 embedding 模型转为向量，存入向量数据库
• 检索（Retrieval）：用户提问时，把问题也转为向量，在向量数据库中做相似度搜索，找出最相关的 top-k 段
• 增强生成（Generation）：把检索到的段落作为参考材料，和用户问题一起发给 LLM 生成答案

7.3 RAG vs 长上下文

“既然有百万上下文，直接把所有文档扔进去不就行了？”

理论上可行，但实际中有几个问题：

• 成本：每次提问都把全部文档发一遍，input token 开销很大
• 延迟：大量 input 意味着更长处理时间，实时对话撑不住
• 注意力衰减：模型对超长上下文中部的信息关注度天然下降
• 可扩展性：文档库可能远超上下文窗口（海量 PDF、整个公司的文档库）

所以长上下文和 RAG 不是互斥的——实践中往往是 RAG 检索 + 长上下文模型一起用：RAG 做粗筛，模型用长上下文能力深度消化检索结果。

8. 三种部署/使用方式对比

什么情况选什么：

• 普通用户日常使用→ 网页端/App，够用且省事
• 做产品/应用/自动化流水线→ API，模型好且可控
• 涉密数据/内网环境/高并发低成本→ 本地部署开源模型（如 Qwen 3 部署在内网 GPU 集群上）

9. 一个清晰的路线图

┌──────────────────────────────────────────────────────────┐│                      LLM（模型权重）                       ││             GPT / Claude / DeepSeek / Qwen / ...          ││                                                          ││        "文本 → 文本" 的神经网络，什么都不会做，只会预测      │└────────────┬─────────────────────┬───────────────────────┘             │                     │             ▼                     ▼    ┌────────────────┐   ┌────────────────────┐    │   API 满血访问   │   │  网页/App 降智访问    │    │                 │   │                      │    │ • 裸模型，按量付费 │   │ • 预构建 Agent        │    │ • 完整推理精度    │   │ • 量化/蒸馏模型        │    │ • 无任何内置工具  │   │ • 搜索、生图等已集成    │    └───────┬─────────┘   └──────────────────────┘            │            │ 开发者在此基础上构建            │            ▼    ┌─────────────────────────────────────────────┐    │              你自己搭建的 Agent               │    │                                             │    │   LLM + 工具集（搜索/数据库/文件/代码执行）     │    │   + 决策循环 + 对话管理 + 安全过滤             │    │   + RAG 检索增强（可选）                       │    └────────────────────┬────────────────────────┘                         │            ┌────────────┼────────────┐            ▼            ▼            ▼    ┌─────────────┐ ┌──────────┐ ┌──────────────┐    │  Claude Code │ │  Cursor   │ │ 你自建的应用  │    │  (编程专用)   │ │ (编程专用) │ │ (任意场景)   │    └─────────────┘ └──────────┘ └──────────────┘

核心认知链路：

1. LLM 是引擎，不是产品
2. API 是买满血引擎，网页端是租一辆简配整车
3. 网页端 = Agent（厂商搭好了），API = 裸模型（你要搭成 Agent 还是别的，全凭自己）
4. Claude Code、Cursor 等 = 别人用 API 搭好的垂直 Agent 产品
5. 本地部署 = 引擎在你家跑，数据不出门，性能靠钱包

10. FAQ

Q: 网页版的降智是真实的吗，还是玄学？A: 各家做法不同，但量化推理（用更低精度参数加快速度、省显存）是行业标准做法。DeepSeek、OpenAI 等厂商在网页侧的服务与 API 侧用的推理集群可能是同一套硬件，但 API 侧使用 FP16 精度、网页侧可能使用 INT8 甚至 INT4 的量化 checkpoint。此外网页版可能在负载高峰切到更小的模型变体——这类”降级”没有任何公告。API 受 SLA 约束，不能随便换模型。

Q: 既然网页端是 Agent，为什么它不能像 Claude Code 那样自己改代码？A: 网页端的工具集是厂商预设的，厂商没有给你开放文件系统工具和 Shell 执行工具（安全考虑）。Claude Code 的工具有读写文件、执行命令的权限——因为它在你的本地机器上运行。网页端跑在厂商的沙箱里，不可能访问你的文件。

Q: ChatGPT Plus / Claude Pro 订阅了就能用 API 吗？A: 不能。订阅和 API 是完全独立的产品线和计费体系，账户不互通。ChatGPT Plus 订阅 ≠ OpenAI API 额度，Claude Pro 订阅 ≠ Anthropic API 额度。API 需要单独注册、单独充值。

Q: 什么是 system prompt？A: 在每次对话中，你可以设一条 role: "system"的消息，用来定义模型的行为规则。网页端/App 背后有一条很长的隐藏 system prompt（你不知道内容），API 端你可以完全自定义。比如 "你是一个毒舌的代码审查员"vs "你是一个耐心的小学老师"——同样的问题，同样的模型，行为完全不同。这是 prompt engineering 里最基本也最重要的概念。

Q: Temperature / Top-p 是什么？A: 控制模型输出随机性的参数。temperature越低（接近 0），输出越确定、越可复现（适合代码、翻译）；越高，输出越有”创造性”但也越可能跑偏（适合创意写作）。top_p是另一种随机性控制方式（nucleus sampling），实践中一般调一个就够了，不需要两个都动。API 允许你调整这些参数，网页端通常不允许。

Q: 本地部署需要什么配置？A: 取决于你要跑多大参数的模型。一个粗略参考（以 Qwen 3 为例）：

• 7B 参数（INT4 量化）→ 约 4-6 GB 显存，消费级显卡可跑，甚至 MacBook 能用
• 32B 参数（INT4 量化）→ 约 20-24 GB 显存，RTX 4090 / Mac Studio 可跑
• 72B 参数（INT4 量化）→ 约 40-48 GB 显存，需要 A6000 或双卡
• 满血 671B（如 DeepSeek-R1 原版）→ 需要 8 卡 H100 集群，不是个人玩的东西

11. 一个完整的实践例子

假设你要做”每天早晨 8 点自动汇总 Slack 未读消息并输出摘要”：

• 如果用网页端：做不到。你得手动复制粘贴每条消息。
• 如果只用 API 裸调：你可以写一个 cron 脚本调 Slack API 取消息，拼好 prompt，调 LLM API 生成摘要。但你需要自己处理——Slack 取哪些频道？消息太多超出上下文窗口怎么办？多少个最近消息最合理？这需要你自己写所有逻辑。
• 如果你搭了一个 Agent：Agent 自己能决定”先取频道列表 → 对每个频道取未读消息 → 发现消息太多 → 自动分批摘要 → 最终整合”。你只需要告诉它目标。
• 如果你本地部署 + API 混合：敏感的公司消息用本地 Qwen 3 处理（不出内网），非敏感的摘要任务调 DeepSeek API（便宜）。这就是生产环境的典型做法。

12. 常用项目/工具速查