AI Agent 完整入门指南：从 LLM 到生产落地的 30+ 个核心概念

从"调 Prompt"到"搭 Agent"，中间隔着一整套你没听说过的概念。Token、Context、RAG、CoT、MCP、ReAct、Harness......每个词单独看都懂，串起来就晕。

这篇文章把 34 个核心概念按一条主线排好：LLM 本质 → Prompt → Agent 循环 → 记忆与检索 → 多 Agent 协议 → 工程化与生产落地 → 安全红线。每个概念不只给定义，还给"为什么重要"和"实际用的时候要小心什么"。文末附 FAQ 和一条验证过的学习路径。

一、先把最底层的认知钉死：LLM 是个纯函数

1.1 LLM：给文字、回文字，仅此而已

GPT、Claude、Gemini 这些大模型，本质是同一个东西：一个接收文字、输出文字的函数。

input prompt → output text

这句话看着像废话，但它是在 Agent 领域少走弯路的最重要认知。

因为它意味着：LLM 不会自己上网，不会记住上次的对话，不会知道今天是几号。你问"帮我查下上海天气"，它给你的"25 度、晴"是编的，除非你把天气数据放进 Prompt 里。你上次跟它说过"我叫小明"，这次它照样不记得，除非你每次把这句话重新塞进上下文。

所有"让 AI 有记性""让 AI 能查资料"的方案------RAG、Memory、Tool Use------本质都是在函数外面包壳子，而不是模型自己长出了这些能力。记住这一点，后面一半概念都通了。

1.2 Token：AI 世界的货币

LLM 看的不是"字"，是 token（次字单位）。它是所有计费、上下文窗口、延迟的数字基础：

• 中文 1 个字 ≈ 1.5~2 token
• 英文 1 个 word ≈ 1.3 token

所以"100 万 token 的上下文窗口"换算过来大约是 75 万中文字。写 Prompt 时能用英文缩写就别堆长中文------token 少了，响应更快、账单更薄，这个习惯在跑生产时一年能省出不小一笔。

1.3 Context Window：能看多少，与"中间迷失"

Context Window（上下文窗口）就是 LLM 一次调用里能"看"到的最大 token 数。2026 年主流模型的量级：

模型系列	上下文窗口
Claude Sonnet 5 / Opus 5	1M
GPT-5.6	1.05M
Gemini 3.5 Flash	1M（Pro 到 2M）
xAI Grok 4.5	500K

但窗口大不等于能用好。超过一定长度后，LLM 会出现 Lost in the Middle（中间迷失）：开头和结尾的内容记得牢，中间的内容被"遗忘"。

实践原则：最重要的指令放 Prompt 开头和结尾，辅助材料放中间。这个细节在长上下文场景（比如把整份代码库塞进窗口）里，直接决定回答质量。

二、Prompt 工程：和模型说话的方式，是第一门手艺

2.1 System Prompt 与 User Prompt

一次 LLM 调用通常分两层：

• System Prompt：角色与规则设定（"你是一位资深后端工程师，回答必须简洁"）
• User Prompt：这一轮具体的任务（"请 review 下面这段代码"）

System Prompt 的优先级设计是安全与质量的根基------它应该是不变的规则层，而 User Prompt 是可变的输入层。后面讲 Prompt Injection 时会看到，这两层混在一起就是灾难的开始。

2.2 Zero-shot / One-shot / Few-shot

三个词的区别只在"你给了几个范例"：

类型	范例数	适用场景
Zero-shot	0 个	直接问，不给例子
One-shot	1 个	简单格式引导
Few-shot	2~5 个	格式要求严的任务，准确度提升明显

把以下中文翻译成英文：
中文：你好 → 英文：Hello
中文：谢谢 → 英文：Thank you
中文：再见 → 英文：

Few-shot 的代价是范例本身也占 token。范例不是越多越好------对格式严格的任务 3~5 个就够，多了浪费上下文还容易引入噪声。

2.3 思维链（CoT）：让模型"先想再答"

Chain-of-Thought 的核心是让 LLM 先输出推理过程再给结论，而不是直接蹦答案。两种触发方式：

1. Few-shot CoT：范例里带完整推理步骤，让模型模仿
2. Zero-shot CoT：Prompt 末尾加一句 "Let's think step by step"

代价很实在：CoT 会显著增加输出 token，意味着更慢、更贵。但它对数学、逻辑、多步推理类任务的价值也实打实。生产环境里通常只在需要推理的任务上开，简单任务开着纯属烧钱。

三、Agent：从"对话"到"自主行动"的那一步

3.1 Agent 的三要素

Agent 不是"更聪明的 LLM"，而是以 LLM 为核心的自主系统。三要素缺一不可：

要素	作用
LLM	推理 / 规划 / 决策
Actions	做事的手段（调工具、写代码、查数据库）
Loop	感知 → 决策 → 行动 → 观察 → 重复 的心跳循环

关键区别一句话：纯 LLM 是你问我答，单次交互；Agent 是三要素加持续循环，跑到目标达成或预算耗尽为止。

注意一个常见误区：ReAct 只是 Agent 的一种 pattern，不是 Agent 的定义。 CodeAct、computer-use、planning agent 都是 Agent，只是循环方式不同。

3.2 Tool Use / Function Calling

让 LLM 调用你定义好的外部函数。LLM 返回的不是文字，而是一段结构化调用指令：

{
  "function": "search_weather",
  "args": { "city": "北京" }
}

你的程序执行函数，把结果丢回给 LLM，LLM 基于结果继续推理。把 LLM 想成大脑，Tool Use 就是它的手脚和感官。

两个实战提醒：

1. 厂商命名不同：Anthropic 叫 "Tool Use"，OpenAI 叫 "Function Calling"，API schema 有差异，写跨厂商 SDK 时要对齐。
2. 工具描述就是 Prompt：模型靠 description 选工具，写清楚"这个工具干什么、参数是什么、失败时怎么办"，比任何代码层兜底都管用。

3.3 ReAct：最经典的 Agent 模式

Reasoning + Acting，思路就是显式的"想→做→看"循环：

Thought（思考）→ Action（调用工具）→ Observation（观察结果）→ Thought → ...

一直 Loop 到能给出最终答案。大多数 Agent 框架内部都在实作这个模式，理解它是理解一切 Agent 框架的钥匙。

3.4 Structured Output：和 LLM 通信的"协议层"

强制 LLM 按固定 schema（如 JSON）输出，而非自由文字。各家 API 的 response_format 参数都干这个。

Agent 框架几乎全靠它跟 LLM 沟通------Agent 循环里每一步的状态传递、工具调用的参数解析，都依赖结构化输出。写 Agent 的第一课就是：永远别让 LLM 返回自由文本当协议，JSON schema 强制校验是底线。

3.5 Self-Refine：最简单的"反思"模式

Actor 出答案 → Critic 找问题 → Actor 看 feedback 再答

Self-Refine 让 Agent 自我评估上一轮输出并修订，不需要持久记忆层。Cursor、Cline 这类工具每天都在跑这种变体（一个是写代码的 Actor，一个是 review 代码的 Critic）。它本质上是 ReAct 的兄弟模式，区别只在于"行动"是"重新生成答案"而非"调用工具"。

四、记忆与检索：让 AI 真的"有记性"

4.1 Memory 的两种正交分类

"Memory" 被用得又烂又混，拆开其实是两条独立的轴：

时效轴：

• Short-term：当前对话上下文
• Long-term：跨 Session 持久保存

内容轴（CoALA 框架）：

类型	含义	例子
Working	暂存信息	当前任务步骤
Episodic	过去经历	用户上次说过的偏好
Semantic	事实知识	公司产品的技术参数
Procedural	怎么做	调用某 API 的标准流程

Long-term memory 里可以同时包含 episodic + semantic + procedural。设计 Agent 记忆系统时，先想清楚你要的是哪一格的记忆，别一上来就"上向量数据库"。

4.2 RAG：给 AI 配外接知识库

RAG（检索增强生成）解决的核心问题：LLM 不知道你的私有资料、变动资料、过期后的最新资料。它不修改模型，而是在推理时把相关资料塞进上下文。两阶段：

阶段一：建库（Ingest）

document → chunk（切块）→ embed（向量化）→ 存入 Vector DB

阶段二：查询（Query）

question → embed → semantic search → top-K chunks → 塞进 Prompt → LLM 回答

RAG 的关键认知：它是"推理时插资料"的架构，不是"训练"。资料更新了，重建索引即可，模型权重完全不用动。

4.3 Embedding 与 Vector DB

Embedding（嵌入）：把文字/图片转成 N 维向量，让"意思接近"的东西在向量空间里距离更近。默认指 dense embedding（稠密向量），另外还有 BM25 / SPLADE 这类 sparse embedding（按字面 token 匹配）。

Vector DB（向量数据库） ：存储并高效查询 embedding 的存储层，核心能力是 ANN（近似最近邻搜索），比暴力全扫快几百倍。代表：Pinecone、Chroma、Qdrant、Weaviate、pgvector。

4.4 Chunking、Hybrid Search 与 Reranking：RAG 质量的三张牌

Chunking（切块）：把长文档切成适合 embedding 的小段（通常 200~1000 token）。切法直接决定 RAG 质量------切太碎丢脉络，切太长相关度模糊。这是新手最容易忽略、却又最影响效果的一步。

Hybrid Search（混合搜索） ：语义搜索 + BM25 关键字搜索一起用，再 merge 排序。生产级 RAG 的默认标配，大多数场景下比单一方法准。

Reranking（重排序）：第一轮检索捞出 top-50，再用更贵但更准的 cross-encoder 模型重排成 top-5 给 LLM。代表：Cohere Rerank、bge-reranker。两段式检索（先快后准）是控制成本与质量的标准打法。

4.5 Contextual Retrieval

Anthropic 2024 年提出的方法：给每个 chunk 加上"整份文件的脉络摘要"再一起 embed，解决"这段文字单独拿出来不知道在讲什么"的问题。当你的文档里充满"如上所述""该方法"这类指代时，这个方案价值很大。

4.6 Fine-tuning vs RAG：黄金法则

方案	本质	适合	不适合
RAG	推理时塞资料进上下文，不改权重	最新事实、私有文档、频繁变动的知识	极度复杂的格式要求
Fine-tune	再训练模型，知识烧进权重	稳定学会某种格式/风格/领域用语	塞"最新事实"（会过期且难更新）

黄金法则：Agent 场景先死磕 Prompt + RAG，真的不够才考虑 Fine-tuning。 大量团队一上来就微调，结果微调完发现知识照样会过期、幻觉照样存在，还多养了一套训练流水线。

4.7 Reflexion：跨 trial 累积教训的"完整版反思"

和 Self-Refine 的区别：Reflexion 需要持久的 episodic memory store。Agent 跑完一次任务，把反思总结写进记忆；下一次任务开始时，把记忆检索进 Prompt。

跨 trial 累积教训，才是 Reflexion 的本质。 如果只是"这轮答错、下轮再试"，那是 Self-Refine；只有当教训能存下来并在未来任务里被检索使用时，才叫 Reflexion。

五、多 Agent 与协议：一个人干不了，一群人怎么协作

5.1 Multi-Agent 的三种典型 pattern

单个 Agent 有单点的能力上限，于是有了多 Agent 协作：

• Supervisor + Worker：一个规划分派，其他执行。最可控，适合流程明确的场景
• Swarm（群集）：平等 Agent 群，无固定主管，靠消息传递协作。灵活但难调试
• Debate（辩论）：多个 Agent 各持立场，最后达成共识。适合需要多角度审视的判断

Handoff（交接）：一个 Agent 把任务交给另一个，涉及上下文传递和失败处理。多 Agent 系统的绝大多数 bug 都出在 Handoff 上------上下文传漏了、失败没人接管。

5.2 A2A：Agent 与 Agent 之间的协议

Google 发起、Linux Foundation 治理的 Agent-to-Agent Protocol ，2026 年已达 v1.0。它是 MCP 的姊妹标准 ：MCP 管 agent ↔ tool，A2A 管 agent ↔ agent。

记住这个分工，后面章节的协议理解就不乱了。单 Agent 接工具用 MCP，多 Agent 互联用 A2A。

六、Claude Code 生态：把 Agent 养在项目里

6.1 MCP：LLM 的 USB 接口

Model Context Protocol ，Anthropic 2024 年推出、2025 年底捐给 Linux Foundation 的开放协议。把它想成 "LLM 的 USB 接口"------统一了外部工具如何接进 LLM，避免每家厂商各写一套适配。

标准化了 3 种原语：

原语	作用
Tools	LLM 可调用的函数
Resources	LLM 可读取的数据
Prompts	可复用的 Prompt 模板

架构是 Server/Client 模式：Server 通过 **stdio（本地）**或 **Streamable HTTP（远端）**暴露。给 Cursor、Claude Desktop、自研 Agent 同时提供同一套工具时，写一个 MCP Server 就够了。

6.2 Skills / SKILL.md：Claude Code 的"行为包"

一个 Skill = 一个文件夹，内含 SKILL.md + 可选参考文件。关键机制 ：Claude Code 每次处理消息前，会扫描所有 Skill 的 frontmatter description------匹配当前情境就自动载入。

所以 description 写得好不好直接决定 skill 会不会被触发。实务上以 "Use when ..." 开头最有效，因为这是描述触发条件的最直接语法。

6.3 CLAUDE.md、Slash Command、Hooks 与 Subagent

• CLAUDE.md：项目根目录的规则文件，Claude Code 每次启动都读，写项目级约定
• Slash Command ：/ 开头的自定义指令，存在 .claude/commands/<name>.md
• Hooks ：在特定事件前后执行脚本（比如工具调用前拦截危险的 rm -rf）
• Subagent：Spawn 出去跑特定任务的子 Agent，有自己的独立上下文窗口

这套组合拳的意义：把"规则、流程、安全、并行"都工程化，而不是靠每次对话临时交代。

七、生产落地：从"能跑"到"能上线"

7.1 Eval：没有评估的 Agent 等于没有测试的代码

针对 Agent 跑一组 test case，量化准确度 / 延迟 / 成本。没有 Eval 的 Agent，等于没有测试的代码------你只是"感觉它还行"。

常用工具：promptfoo、LangSmith、Langfuse。从第一天起就建 eval 集，每次改 Prompt、换模型、调 RAG 都跑一遍，防止"修好一个、打崩三个"。

7.2 Observability：出 bug 能回放的底气

把 Agent 内部每一步都记下来------哪个 LLM call、调了哪个 tool、工具返回了什么、最终答案是什么。出 bug 时能 replay，而不是对着一个错误回答瞎猜中间发生了什么。

这是生产 Agent 与玩具 Agent 的分水岭。我在生产里调 Function Calling 最大的痛苦，就是工具链出错时中间过程完全不透明------可观测性就是治这个的。

7.3 Prompt Caching：省钱的必修课

LLM 把 prompt 前缀缓存起来，下次同前缀只算 cache hit 的便宜价（Anthropic 最高 90% off、OpenAI 50% off）。

Long context + 重复 query 的场景（RAG 场景里系统提示 + 固定文档前缀每次都一样）能省很多钱。代价是缓存有 TTL、有最小长度要求，要在命中率和时效性之间做取舍。

7.4 Computer Use 与 Browser Use：把"看屏幕"也交给 Agent

• Computer Use（屏幕级）：截图 → 视觉理解 → 算坐标 → 模拟键鼠，操作真实桌面应用。不靠 API，像人一样看屏幕。代表：Anthropic Claude Computer Use、OpenAI Codex desktop
• Browser Use（网页级） ：操作网页，主要用 DOM-aware navigation（直接 query CSS selector），必要时视觉 fallback。代表开源：browser-use（GitHub ★ 105k+）

两者都慢、都贵、都可能失败，但它们是 Agent 能力边界的重要延伸------当没有 API 可用时，看屏幕是最后的通用接口。

八、安全与成本：两道不能松的红线

8.1 Prompt Injection：藏在数据里的恶意指令

把恶意指令藏在 LLM 会读到的内容里（网页、文档、工具返回），诱导它无视原任务。

根因很残酷：LLM 分不清"系统指令"和"数据里夹带的指令"。 它读到的都是一段文本。

防御三板斧：最小权限 （Agent 只拿到完成任务的必要权限）、隔离不可信内容 （与系统指令分开处理）、高风险动作人审（删除、转账、外发前必须过人）。

8.2 Lethal Trifecta：致命的三角

Simon Willison 提出的概念：当 Agent 同时具备以下三种能力，就可能被 prompt injection 操控去偷数据外传：

1. 访问私密数据
2. 接触不可信内容
3. 对外通讯

三者齐备 = 危险组合。防御思路是打断至少一环------最常见的是切断对外通讯，或隔离不可信输入。设计 Agent 架构时先对着这个三角过一遍，比事后补一堆规则有效。

8.3 Guardrails：防 LLM 做坏事的规则层

挡掉 prompt injection、PII 外流、有害输出等。注意 Guardrails 不等于安全------它是规则层，好攻击者能绕过规则。Guardrails 是防线的一部分，不是全部。

九、工程化思维：三层架构，从"调 Prompt"到"建产品"

当你从"调 Prompt"走向"建产品"，需要理解三层工程分工------这也是 2026 年 Agent 工程最核心的心智模型：

9.1 Layer 1：Prompt Engineering

工程字符串。怎么写 prompt 让模型输出更好。这是入门层，也是被过度高估的一层------调 Prompt 只能解决 Prompt 层面的问题。

9.2 Layer 2：Context Engineering

工程信息 。每次 LLM call 时，窗口里装什么信息------RAG 结果、记忆、工具定义、对话历史。Karpathy 称之为"把刚好对下一步有用的信息填进窗口的精细艺术"。

2026 年的共识：Context Engineering 比 Prompt Engineering 更决定 Agent 质量。 同一句 Prompt，喂不同质量的上下文，结果天差地别。

9.3 Layer 3：Harness Engineering

工程执行与控制层 。Agent loop、工具注册、上下文管理、权限、安全、重试、熔断------所有不是模型权重、也不是 Prompt 本身的代码。

Simon Willison 的公式：Coding Agent = LLM + Harness。大多数 Agent 产品的护城河不在模型，而在 Harness------同样是 GPT-5.6 或 Claude Opus，Harness 设计决定了它是好用还是折磨人。

9.4 延伸：Loop Engineering 与 Graph Engineering

• Loop Engineering：设计/调校 Agent 的迭代循环本身------目标、工具、context 管理、终止条件、错误处理
• Graph Engineering：把 Agent 执行流程设计成显式的图（node = 步骤，edge = 转移条件），状态可 checkpoint、可 replay

从线性循环走向显式图，是复杂 Agent 系统走向可控的标志。

十、常见坑点：新手最容易踩的五个坑

1. 把 Agent 当 LLM 用：只调一次接口就当"做了 Agent"。没有 Tool、没有 Loop，就只是套了层壳的聊天机器人。
2. 一上来就上向量数据库：两三篇文档、几千 token，直接塞 Prompt 就行。RAG 的复杂度要等知识库真的装不下才值得引入。
3. 不建 Eval 就疯狂调 Prompt：没有评估集的调参是玄学，你只是在记住最近一次失败的那条例子。
4. 忽视工具描述的 Prompt 属性：工具 description 写得随意，模型就会乱选工具、错传参数。把工具描述当 Prompt 来磨，错误率能降一半。
5. Long context 里什么都往前塞：文档、代码、历史一股脑全塞，触发 Lost in the Middle，且 Prompt Caching 失效。按需取用，分级放。

FAQ：AI Agent 入门高频问题

Q1：Agent 和普通 LLM 聊天机器人有什么区别？

Agent 是"LLM + Actions + Loop"的自主系统，能调工具、能循环执行直到目标达成；普通 LLM 是单次问答。判断标准很简单：它有没有 Tool、有没有 Loop。两者都没有，就只是聊天机器人。

Q2：RAG 和 Fine-tuning 怎么选？

先死磕 Prompt + RAG，不够再考虑微调。RAG 适合最新事实、私有文档、频繁变动知识；Fine-tuning 适合稳定格式与领域语感的固化。微调无法解决"知识会过期"的问题，且引入训练流水线成本。

Q3：MCP 和 A2A 有什么区别？

MCP 是 agent 连接 tool 的协议（LLM 的 USB 接口），A2A 是 agent 之间通信的协议。单 Agent 接工具用 MCP，多 Agent 互联用 A2A，两者是配套的姊妹标准。

Q4：ReAct 就是 Agent 的全部吗？

不是。ReAct 只是最经典的 Agent loop pattern（想→做→看），CodeAct、computer-use、planning agent 同样是 Agent。理解 ReAct 是理解框架的钥匙，但别把它当成 Agent 的全部形态。

Q5：生产环境跑 Agent，最该先做哪件事？

先建 Eval 集和可观测性。没有评估集，你无法判断改动是好是坏；没有日志回放，出 bug 只能对着错误回答瞎猜。这两件事做的越早，后面省的时间越多。

总结与学习路径

这篇指南从 LLM 的本质一路走到生产落地，主线只有一条：LLM 是纯函数，Agent 是给这个函数装上的手、脚、记性和控制层。先理解 Token 和 Context Window 的经济学，再理解 Agent 循环，然后用 RAG 补知识、用 Harness 控执行、用 Eval 守质量、用安全红线兜底------30+ 个概念就全部各归其位了。

如果你准备动手，按下面这条路径走，能少走很多弯路：

1. 先用 Claude Code / Cursor 写几个 Skill，感受 Tool Use 是什么
2. 用 LangChain 搭一个 ReAct Agent，跑通"想→做→看"循环
3. 给 Agent 接上 RAG Pipeline，体会 Context Engineering 的分量
4. 加上 Eval 和 Observability，这步做完才算"能上线"的 Agent
5. 尝试 Multi-Agent 协作，理解 A2A 与 MCP 协议的边界

如果这篇帮到你，欢迎订阅 RSS持续获取 AI 工程实战内容，也欢迎在评论区聊聊你在搭第一个 Agent 时踩过的坑。

原创技术博客 · 开源项目分享 · AI全栈创作社区 idao.fun