LLM 应用层与生态
模型本身只能根据输入接龙输出，要让它在真实业务里有用，还需要在外围搭一层「调用约定 + 执行环境 + 知识来源」。本文聚焦这一层最常见的几个概念。
Function Call（函数调用）
Function Call 指 LLM 在生成自然语言之外，还能按约定输出结构化数据（常见为 JSON），用来表示「要调用哪个外部函数、参数是什么」。借此可以把模型输出接到代码、HTTP API、数据库、脚本等，实现与真实系统的交互。
多数云厂商与开源栈会把它和 JSON Schema（或等价描述）绑定：先声明工具名与参数类型，模型只负责在合法集合里做选择并填参；真正执行仍由宿主程序完成。这是许多「工具使用 / Tool Use」方案的底层能力，Agent、MCP 等往往都建立在这层之上。
Agent
Agent 一般指 LLM + 工具 + 记忆 + 编排逻辑 构成的智能体：不局限于单次问答，而是能在多步里推理 → 选工具 → 执行 → 根据结果再推理，直到任务结束或达到终止条件。
与「只聊天」的用法相比，Agent 强调闭环：模型决定下一步动作，环境返回观测结果，再进入下一轮。记忆可以是会话摘要、向量检索、键值存储等形式，视产品而定。
MCP（Model Context Protocol）
MCP 是一套开放协议，用来把「工具、资源、提示」等能力以标准方式暴露给支持 MCP 的客户端（如部分 IDE、桌面应用）。实现上常见为本地或远程进程，通过约定好的传输层与宿主通信。
对模型侧而言，MCP 服务会提供能力声明：有哪些工具、每个工具的参数与说明。宿主在启动或连接时会拉取这份声明；用户提问时，模型在需要时发起工具调用，由 MCP 执行并返回结果，再用于生成最终回复。可以理解为：把一类集成方式标准化，便于同一套 MCP 被多个宿主复用。
Skill（技能）
Skill 常指可复用的技能说明：不限于「可调用的 API」，也可以描述规范、流程、约定、检查清单等。形式上多为 Markdown 等文档，开头常有摘要，正文展开细节与示例。
与 Agent 结合时，典型做法是：先只把各 Skill 的摘要注入上下文，让模型知道「有哪些技能」；当判断某条用户任务匹配某一 Skill 时，再按需加载该 Skill 全文，并按文档约束调整行为（例如优先用某类工具、遵守某套步骤）。这和单纯堆长提示词的区别在于：分层加载，节省上下文并减少干扰。
RAG（Retrieval-Augmented Generation）
RAG（检索增强生成） 指在生成前，先从外部知识库检索出与问题相关的文档片段，把片段拼进 prompt 再交给 LLM 作答。它解决的是 LLM 自身的两个固有短板：训练数据有截止日期、参数化知识难以精确溯源。
典型流程：
- 索引阶段（离线）：把文档切片（chunking），用专门的 句子 Embedding 模型（如 BGE、text-embedding-3）把每片编码成稠密向量，存入向量数据库（如 Milvus、pgvector）。
- 检索阶段（在线）：用同一个 Embedding 模型把用户问题编码成向量，按余弦相似度从向量库召回 Top-k 片段；常配合关键词检索（BM25）做混合召回，再用 reranker 精排。
- 生成阶段：把召回的片段填入 prompt 模板（"根据下面的资料回答……"），交给 LLM 生成答复，可附上引用出处。
这里的 Embedding 是句子级别的，与
tokenizer.md中模型内部的 token Embedding 不是一回事——前者是把整段文本压成一个向量用于检索，后者是模型查表得到的 token 向量。
与长上下文的关系：当文档总量远超模型窗口时，RAG 是绕开「真长上下文」的常用工程手段（见 inference.md 中的 上下文窗口）；即便模型支持 128K，先用 RAG 召回再生成往往仍是更经济、更可控的做法。