夜雨聆风一、LLM 基础
1.1 模型架构
大语言模型(LLM (Large Language Model)) — 基于 Transformer、预测下一个 token 的神经网络▸ 所有 Agent 的"大脑"
Transformer(Transformer) — 2017 Google 提出，用自注意力替代循环/卷积▸ 几乎所有现代 LLM 的架构基础
自注意力(Self-Attention) — 每个词参考输入中所有其他词的权重▸ Transformer 的核心创新
MoE(Mixture of Experts) — 每次推理只激活模型的一小部分参数▸ DeepSeek-V3 的 671B 参数但低成本推理的关键
参数(Parameters) — 模型中可学习的权重数量▸ 模型能力的粗略指标
分词器(Tokenizer) — 将文本切分为 token 的组件▸ 不同模型 tokenizer 不同——同样一段中文 token 数不一致
基础模型(Base Model) — 预训练完成但未经指令微调的模型▸ 微调的起点，不适合直接对话
指令模型(Instruct / Chat Model) — 经过 RLHF/指令微调的模型▸ 日常使用的 GPT-4o、Claude、DeepSeek 都是
推理模型(Reasoning Model) — 回答前自动产生内部推理链——DeepSeek-R1、o1、Claude thinking▸ 2025-2026 最大新范式——复杂任务准确率质变但延迟更高
开源模型(Open-Source / Open-Weight) — 权重公开、可商用（MIT/Apache 2.0）▸ 自部署 + 无 API 费用的前提
闭源模型(Proprietary Model) — 仅通过 API 访问▸ 能力强但数据出网 + 按 token 计费
1.2 推理
Token(Token) — 模型处理的最小文本单元——英文≈0.75词，中文≈1.5字▸ 计费 + 上下文窗口的基本单位
推理(Inference) — 模型根据输入生成输出的过程▸ 区别于训练，Agent 日常全是推理
上下文窗口(Context Window) — 模型单次能"看到"的最大 token 数▸ 决定 Agent 能记住多少历史 + 检索文档
温度(Temperature) — 控制输出随机性（0=确定性，1=创造性）▸ 工具调用设 0-0.3，避免幻觉
流式输出(Streaming) — 模型逐 token 输出而非全量完成▸ Agent UI 体验——打字机效果
系统提示词(System Prompt) — 对话开始时注入的"角色设定"▸ Agent 的"灵魂"
提示模板(Prompt Template) — 可复用的 prompt 结构，含 `{变量}` 占位符▸ 工程化 prompt 管理的基础
少样本提示(Few-shot Prompting) — 在 prompt 中提供少量示例▸ 显著提升小模型或特定任务准确率
思维链(Chain-of-Thought (CoT)) — 要求模型"一步步思考"再回答▸ 提升复杂推理任务准确率
函数调用(Function Calling / Tool Use) — 模型输出结构化 JSON"调用"预定义函数▸ Agent 与外部系统交互的核心
结构化输出(Structured Output) — 强制模型按 JSON Schema 输出▸ Agent 工具调用的工程前提
上下文缓存(Context Caching) — 将重复使用的 prompt 前缀缓存▸ API 模式下省 50-90% token 成本
1.3 训练相关
预训练(Pre-training) — 在海量文本上做"下一个 token 预测"▸ LLM 通用语言能力的来源
微调(Fine-tuning) — 在特定任务数据上进一步训练▸ 让通用模型适应领域需求
RLHF(Reinforcement Learning from Human Feedback) — 用人类偏好训练奖励模型 + 强化学习优化 LLM▸ ChatGPT 类产品"听话"的关键
LoRA / QLoRA(Low-Rank Adaptation) — 只训练少量新增参数的微调方法▸ 个人也能在单 GPU 上微调大模型
量化(Quantization) — 将模型参数从 FP16 压缩到 INT8/INT4▸ 本地部署的前提（GGUF/GPTQ）
模型蒸馏(Distillation) — 用大模型教小模型——小模型模仿大模型输出▸ 保持精度前提下缩小体积
二、Agent 核心
2.1 基础概念
AI Agent(AI Agent / LLM Agent) — LLM 做"大脑"，能感知、规划、调用工具、执行行动的自主软件▸ 区别于 Chatbot
Agent vs Chatbot(Agent vs Chatbot) — Chatbot 一问一答；Agent 观察→思考→行动→观察循环▸ 选型第一问
Agentic AI(Agentic AI) — 2025-2026 热词，泛指具备自主决策行动能力的 AI▸ 行业叙事关键词
ReAct 循环(ReAct Loop) — 思考→行动→观察→再思考，直到完成▸ 几乎所有 Agent 框架的底层模式
Agent Harness(Agent Harness / Scaffolding) — 包围 LLM 的所有软件基础设施——工具执行、记忆、上下文、状态持久化、安全▸ 2026 最重要术语：Agent 的 70% 能力在 Harness 而非模型
单 Agent(Single-Agent) — 一个 LLM + 一组工具▸ 大多数场景起点
多 Agent 系统(Multi-Agent System (MAS)) — 多个 Agent 协同，各有分工▸ 复杂任务拆解
子 Agent(Subagent) — 主 Agent 动态创建和调用的工作 Agent▸ 委派模式
复合 AI 系统(Compound AI System) — 非单一 LLM，而是多个 LLM + Agent + 工作流的结构化组合▸ 2025-2026 架构趋势——不靠一个模型解决所有问题
2.2 Agent 推理模式（Agentic Reasoning Patterns）
ReAct(ReAct (Reasoning + Acting)) — 交错进行推理和行动——想到一步就做一步▸ Yao et al. 2022
反思(Reflection) — Agent 输出后自我评估并修正▸ Shinn et al. 2023
Reflexion(Reflexion) — 反思 + 长期记忆——把失败经验存下来下次回避▸ Shinn et al. 2023
思维树(Tree of Thoughts (ToT)) — 同时探索多条推理路径，选择最优▸ Yao et al. 2023
先规划后执行(Plan-and-Execute) — 先制定完整计划，再逐步执行▸ —
LLM Compiler(LLM Compiler) — 用 LLM 生成"任务 DAG"然后并行执行▸ Kim et al. 2024
2.3 Agent 架构组件
规划(Planning) — Agent 在执行前先分解任务、制定步骤▸ 决定了 Agent 的质量上限
记忆(Memory) — 存储和检索信息——短期（上下文）和长期（跨会话）▸ 没有记忆的 Agent 是金鱼
工具(Tools) — Agent 可调用的外部功能——数据库、API、搜索▸ Agent 的手和脚
感知(Perception) — 接收和理解输入——文本、图像、语音▸ 多模态 Agent 基础
行动空间(Action Space) — Agent 被授权的所有操作集合▸ 安全边界
运行时治理(Runtime Governance) — 运行时的策略执行——能调什么、token 上限、超时熔断▸ 2026 企业 Agent 核心关注
2.4 Agent 类型
简单反应 Agent(Reflex Agent) — 只看当前输入，无记忆无规划▸ 分类、提取、简单问答
目标驱动 Agent(Goal-Based Agent) — 追求特定目标，规划步骤、使用工具▸ 大多数生产 Agent
人在回路(Human-in-the-Loop (HITL)) — 关键决策点暂停等人类审批▸ 涉及资金/删除/发布的必选项
三、Agent 编排
3.1 编排模式
编排(Orchestration) — 管理多个 Agent 的执行顺序、数据传递和决策流转▸ 多 Agent 系统核心设计
顺序编排(Sequential) — A 完成 → B 接结果继续▸ 线性流水线
并行编排(Concurrent) — 多个 Agent 同时处理同一输入，结果汇总▸ 多维度分析
交接编排(Handoff) — 一个 Agent 转给更合适的 Agent▸ 客服：售前→技术支持
群聊编排(Group Chat) — 多个 Agent 在同一对话空间自由交互▸ 头脑风暴
层级编排(Hierarchical) — 顶层编排 Agent 委派给子 Agent▸ 复杂 PM Agent
蜂群模式(Swarm / Swarm Intelligence) — 去中心化多 Agent——无固定编排者，自主协商▸ 动态任务分配
监督者模式(Supervisor Pattern) — LangGraph 经典模式：Supervisor 决定下一步调谁▸ 明确决策层级的 Agent
Map-Reduce(Map-Reduce（Agent）) — 任务拆成 N 份并行处理，最后汇总▸ 大文档分析
3.2 关键框架
LangGraph(LangGraph) — 用有向图定义 Agent 流程的框架▸ 2025-2026 多 Agent 编排事实标准
CrewAI(CrewAI) — 角色扮演型多 Agent 框架▸ 上手简单，快速原型
状态图(State Graph) — LangGraph 核心——节点（操作）+ 边（流转）▸ 可观测、可调试、可持久化
Deep Agent(Deep Agents) — LangChain 长期运行 Agent 框架▸ 跨天/跨进程的"3 小时后出报告"
四、工具与能力
工具调用(Tool Calling) — LLM 决定"该用哪个函数"并输出结构化 JSON▸ Agent 与外界的唯一接口
函数声明(Function Declaration) — 预先定义给模型的函数签名▸ 模型知道"有哪些工具"的前提
工具描述质量(Tool Description Quality) — MCP 工具 name + description + input schema 清晰度▸ 直接决定调工具的准确率
工具超时(Tool Timeout) — 工具调用超过时限自动中断▸ 生产必配
技能(Skill) — 比单个函数更高级的封装——prompt + 工具链 + 知识▸ "合同审核 skill"比"调三个 API"更接近业务
MCP 工具(MCP Tool) — 通过 MCP 协议暴露的标准接口工具▸ 工具生态化关键
代码解释器(Code Interpreter / Sandbox) — Agent 在隔离环境中运行代码并返回结果▸ Agent 的"执行能力"
浏览器使用(Browser Use / Web Agent) — Agent 自主操控浏览器——点击、填表、截图▸ 2025-2026 新方向
Hook / 中间件(Hook / Middleware) — Agent 工具调用前后插入自定义逻辑▸ 审计日志、权限校验的工程化方式
五、协议
5.1 三大核心协议
MCP(Model Context Protocol) — Agent ↔ 工具/数据源的标准连接▸ Anthropic (2024)
A2A(Agent-to-Agent Protocol) — Agent ↔ Agent 的任务委托和通信▸ Google (2025)
AG-UI(Agent–User Interaction Protocol) — Agent ↔ 前端的实时交互▸ CopilotKit (2025)
5.2 MCP 详解
MCP Server(MCP Server) — 暴露 Tools / Resources / Prompts 的服务端▸ 把任何系统包装成 Agent 可用接口
MCP Client(MCP Client) — 连接 MCP Server 的客户端▸ Agent 框架通过它发现工具
MCP Host(MCP Host) — 运行 Agent 的应用程序▸ 终端用户看到的界面
MCP 三大原语(Tools / Resources / Prompts) — Tools=可调用函数，Resources=可读数据，Prompts=预定义模板▸ MCP 三类能力
JSON-RPC 2.0(JSON-RPC 2.0) — MCP 底层通信协议▸ 所有 MCP 消息的格式
MCP 传输(Transport) — stdio（进程间管道）或 Streamable HTTP▸ 本地用 stdio，远程用 HTTP
Streamable HTTP(Streamable HTTP) — MCP 2025 新传输层——取代旧版 HTTP+SSE 分离模式▸ MCP 最新推荐传输方式
工具发现(Tool Discovery) — Server 通过 `tools/list` 宣告能力▸ 即插即用前提
MCP Sampling(Sampling) — MCP Server 反向请求 Host 做 LLM 补全▸ Agentic MCP：Server 也能"思考"
MCP Elicitation(Elicitation) — MCP Server 反向请求 Host 向用户索取输入▸ 交互式 MCP——遇到歧义反问用户
5.3 其他协议
SSE(Server-Sent Events) — 服务端向客户端单向推送——Agent 流式输出标准传输
WebSocket(双向全双工通信) — 实时交互 Agent
A2UI(Agent-to-User Interface) — Google 的 Agent→静态 UI 协议（与 AG-UI 竞争）
ACP(Agent Communication Protocol) — Anthropic Agent 通信协议（与 A2A 竞争）
UCP(Universal Commerce Protocol) — Agent 商业能力发现
AP2(Agent Payment Protocol) — Agent 加密支付授权
六、记忆与知识
6.1 RAG 基础
RAG(Retrieval-Augmented Generation) — 先检索外部文档，再注入 prompt，让 LLM 基于"新鲜证据"回答▸ 解决了知识截止日期 + 幻觉
朴素 RAG(Naive RAG) — 最基础的 RAG：检索 → 拼接 → 生成，无判断、无循环▸ 大多数 RAG 的起点——也是所有高级模式的对比基线
Agentic RAG(Agentic RAG) — Agent 自主决定"何时检索、检索什么、从哪检索"▸ 区别于固定流水线
嵌入(Embedding) — 将文本/图片转成固定长度向量▸ RAG 基础
向量数据库(Vector Database) — 专门存储和检索向量的数据库▸ RAG 存储后端
分块(Chunking) — 将长文档切成小块再嵌入▸ 检索精度的关键调参项
检索器(Retriever) — RAG 中负责"找相关文档"的组件▸ 决定 Agent 拿到什么上下文
6.2 高级 RAG 模式
混合检索(Hybrid Retrieval) — 同时用稠密向量（语义相似）+ 稀疏检索（关键词匹配），结果融合▸ 生产标配——弥补纯向量检索的精确匹配盲区
重排序(Re-ranking) — 初检索 50 条 → 用更强的模型精排 Top 10▸ 提升检索精准度
Cross-Encoder 重排(Cross-Encoder Reranking) — 把 query+doc 一起喂给模型打分（而非分别嵌入），精度更高但更慢▸ 初检索后的第二道过滤
查询分解(Query Decomposition) — 把复杂问题拆成多个子问题，分别检索，汇总▸ "对比 A 和 B 的三季度表现"这种复合问题
Self-RAG(Self-RAG) — LLM 在生成时自我评估"是否需要检索""检索结果是否相关"▸ 需要 LLM 主动判断何时查知识库
CRAG(CRAG (Corrective RAG)) — 检索质量评分 → 如果差就用 Web 搜索兜底▸ 知识库覆盖不全时的自动化降级
自适应 RAG(Adaptive RAG) — 根据问题复杂度自动路由到不同检索管线（简单→直接回答，复杂→多步检索）▸ 混合复杂度场景——客服系统最常见
上下文检索(Contextual Retrieval) — 每块 chunk 嵌入前用 LLM 补上文档上下文（"这段是讲 A 公司 2024 Q3 财报的…"）▸ 单纯 Contextual Embeddings 降检索失败 49%；搭配 Reranking 降 67%（Anthropic 2024, anthropic.com/engineering/contextual-retrieval）
6.3 GraphRAG 生态（知识图谱增强 RAG）
GraphRAG(GraphRAG) — 用知识图谱 + 社区摘要增强 RAG：实体提取→关系构建→社区检测→全局/局部检索▸ 微软 2024 提出，2025-2026 快速普及——解决"跨文档全局总结"的空白
实体提取(Entity Extraction) — 从文档中自动识别人物、组织、地点、事件等实体▸ GraphRAG 第一步：把非结构化文本变成结构化图
关系提取(Relationship Extraction) — 自动识别实体间的关系（"A 收购了 B"→ 收购关系）▸ GraphRAG 第二步：构建图的边
社区检测(Community Detection) — 在图里自动发现紧密连接的节点群▸ GraphRAG 第三步：用Leiden 算法分组——同社区的节点共享"主题"
Leiden 算法(Leiden Algorithm) — 一种图社区检测算法，比经典的 Louvain 更快、质量更高▸ GraphRAG 默认使用的社区检测算法
社区摘要(Community Summary) — LLM 为每个社区生成一段"这个社区在讲什么"的摘要▸ GraphRAG 的核心能力——全局问题（"整个知识库讲了什么"）靠社区摘要回答
全局检索(Global Search) — 用社区摘要回答"全局性"问题（跨文档总结）▸ 传统 RAG 做不到的事——"总结一下整个数据集的主要主题"
局部检索(Local Search) — 用实体 + 邻居关系回答"局部性"问题（某个特定主题的细节）▸ 与全局检索互补——"关于 X 项目，文档里都说了什么"
知识图谱(Knowledge Graph) — 用节点（实体）+ 边（关系）表示知识的结构化数据库▸ GraphRAG 的数据结构基础
图数据库(Graph Database) — 专门存储和查询图结构数据的数据库（Neo4j、ArangoDB）▸ GraphRAG 的存储后端
6.4 向量与搜索内部机制
近似最近邻(ANN (Approximate Nearest Neighbor)) — 在精度和速度间折中的向量搜索算法——不保证找到"最近"但保证"足够近"▸ 所有向量数据库的核心算法
HNSW(HNSW (Hierarchical Navigable Small World)) — 一种高效的 ANN 索引算法——多层图结构▸ pgvector/Qdrant 默认索引——速度快但内存占用大
IVF(IVF (Inverted File Index)) — 先聚类再搜索——只在少数簇里找最近邻▸ 大规模向量库的首选——内存效率高
余弦相似度(Cosine Similarity) — 两个向量的夹角余弦值——衡量"方向有多接近"▸ 最常用的向量相似度指标
稠密检索(Dense Retrieval) — 用嵌入模型把 query 和 doc 都转成稠密向量，算余弦距离▸ 语义搜索（同义词也匹配）
稀疏检索(Sparse Retrieval) — 用 BM25/TF-IDF 等关键词匹配算法▸ 精确匹配——但不懂同义词
6.5 记忆类型
短期记忆(Short-term Memory) — 当前对话窗口内的上下文▸ Conversation history
长期记忆(Long-term Memory) — 跨会话持久化信息——偏好、历史▸ 跨 session 可查
工作记忆(Working Memory) — Agent 多步任务时的中间状态▸ LangGraph state
语义记忆(Semantic Memory) — 事实性知识▸ RAG 检索对象
情景记忆(Episodic Memory) — 过去经历的事件▸ 个性化 Agent
认知架构(Cognitive Architecture) — Agent 记忆 + 推理 + 规划的总组织方式▸ 高于"用哪个向量库"的设计决策
七、评估与可观测性
评测(Evaluation / Eval) — 用量化指标衡量 Agent 质量▸ 没有评测就没有质量保障
LLM-as-Judge(LLM-as-Judge) — 用一个便宜 LLM 评判另一个 LLM▸ 在线评测主力
离线评测(Offline Eval) — 部署前用固定测试集跑▸ CI/CD
在线评测(Online Eval) — 在生产流量中抽样打分▸ 发现部署后才暴露的问题
轨迹评测(Trajectory Evaluation) — 评 Agent 每一步决策——不只是最终结果▸ Agent 评测的特殊性
可观测性(Observability) — 追踪 Agent 每一步▸ Agent 调试核心
Trace / Span(Trace / Span) — Trace=全链路，Span=一步▸ 可观测性基本单位
幻觉(Hallucination) — LLM 编造不存在的事实▸ Agent 最大信任障碍
红队测试(Red Teaming) — 攻击性 prompt 测试安全边界▸ B2B 企业安全审查
Guardrails(Guardrails) — 输入/输出安全检查▸ 安全第一道防线
提示注入(Prompt Injection) — 攻击者通过输入"覆盖" system prompt▸ Agent 最常见攻击
级联失败(Cascade Failure) — 前面微小错误被后续步骤放大▸ 多步 Agent 致命弱点
打分标准(Scoring Rubric) — LLM-as-Judge 的评分维度定义▸ 评测质量的上游
SWE-bench(SWE-bench) — GitHub 真实 issue→自动修 bug 的基准▸ 代码 Agent 标准考试
MMLU(MMLU (Massive Multitask Language Understanding)) — 57 个学科的 14K 道选择题▸ LLM 通用知识的标准基准
HumanEval(HumanEval) — 164 道 Python 编程题▸ 代码生成标准基准
GSM8K(GSM8K) — 8,500 道小学数学应用题▸ 数学推理标准基准
MT-Bench(MT-Bench) — 多轮对话 + LLM-as-Judge 评分▸ 对话质量评测
八、安全
提示注入(Prompt Injection) — 攻击者通过输入"覆盖" system prompt▸ Agent 最常见攻击向量
越狱(Jailbreak) — 绕过模型安全限制▸ 不同于注入——目标是突破安全训练
PII 泄露(PII Leakage) — Agent 输出中暴露个人身份信息▸ 企业客户最关注的安全风险
沙箱(Sandbox) — 隔离的代码执行环境▸ 代码解释器安全前提
审计日志(Audit Log) — Agent 每一步的完整记录▸ B2B 合规硬要求
九、成本与性能
Token 消耗(Token Consumption) — 每次调用消耗的 token 数▸ Agent 最大运营成本
Token 预算(Token Budget) — 对单次任务/单用户/单日设定上限▸ 防止成本失控
延迟(Latency) — 用户发送到收到第一个 token 的时间▸ 推理模型虽准但延迟高
TTFT(TTFT (Time to First Token)) — 第一个字出现之前的等待时间▸ 比总响应更影响用户感知
十、部署与基础设施
10.1 模型服务
模型服务(Model Serving) — 把模型部署成 API（vLLM/Ollama）▸ 自部署核心
推理引擎(Inference Engine) — 高效运行 LLM 推理的底层框架▸ 决定自部署吞吐和延迟
连续批处理(Continuous Batching) — 不等前一批请求全完成就动态加入新请求——比静态 batching 快 2-10x▸ vLLM 的吞吐秘诀——全套优化（含 PagedAttention）可达 23-24x
PagedAttention(PagedAttention) — 像 OS 虚拟内存一样管理 KV Cache——按需分配、动态回收▸ vLLM 的核心创新——显存利用率提升 2-4x
KV Cache(KV Cache) — 缓存 Transformer 每层的 Key-Value 矩阵，避免重复计算▸ 自回归推理的前提——没有 KV Cache 每生成一个 token 就要重算全文
推测解码(Speculative Decoding) — 用一个小模型快速"草稿"几个 token，大模型一次验证▸ 2-3x 推理加速——保持大模型质量的前提下
GGUF(GGUF) — llama.cpp 的量化模型格式——用于 CPU 推理▸ 本地 Mac/Windows 部署的标准格式
GPTQ(GPTQ) — GPU 上的量化格式——更高精度但需要 CUDA▸ GPU 自部署首选格式
冷启动/热启动(Cold / Warm Start) — 冷=从磁盘加载模型到显存（几十秒到几分钟），热=已在显存▸ serverless 部署的主要痛点
10.2 基础设施
API 网关(API Gateway) — 统一入口——限流、鉴权、路由▸ Agent SaaS 第一道防线
GPU / NPU(GPU / NPU) — 推理硬件——NVIDIA GPU 为主，NPU 兴起▸ 本地部署硬件决策
Checkpoint(Checkpoint / Persistence) — Agent 状态的持久化存储▸ 人在回路 + 断点续跑
持久执行(Durable Execution) — 跨进程/跨天任务仍能继续执行▸ 长跑 Agent 基础设施
密钥管理(Secrets Management) — API Key / 密码的安全存储和轮转▸ 硬编码 .env → 泄露
附录 A：术语关系图
┌─────────────────────────────────────────────────────────────┐ │ AI Agent 技术栈 │ ├──────────┬────────────┬──────────────┬───────────┬──────────┤ │ 模型层 │ Agent 层 │ 协议层 │ 记忆/知识 │ 基础设施 │ │ │ │ │ │ │ │ LLM │ ReAct │ MCP │ Naive RAG │ Gateway │ │ MoE │ Harness │ Sampling │ Adv RAG │ Serve │ │ Reason │ Reflection │ A2A │ GraphRAG │ vLLM │ │ Token │ ToT │ AG-UI │ Embedding │ KV Cache │ │ Instruct │ Plan-Exec │ Stream HTTP │ Vector DB │ GPU/NPU │ │ Base │ Swarm │ SSE/WS │ HNSW/IVF │ Durable │ ├──────────┴────────────┴──────────────┴───────────┴──────────┤ │ 评估 · 安全 · 成本 │ │ Eval / LLM-Judge / SWE-bench / Guardrails / Token Budget │ └─────────────────────────────────────────────────────────────┘
| 来源 |