大语言模型（Large Language Model，以下简称 LLM）正在持续影响软件开发与人机交互方式。要在工程场景中稳定使用这类技术，核心前提是理解其“模型能力边界 + 数据处理链路 + 外部扩展机制”。本文从基础原理出发，依次说明 Token、Context、Prompt、Tool、MCP、Agent 与 Agent Skill 的定义、关系与典型工作流。
图 1：从 LM 核心能力到 Agent 执行层的概念链路示意。
一、 底层引擎：大语言模型（LM）
大语言模型是基于大规模语料训练的概率生成模型，主流实现通常建立在 Transformer 架构之上（该架构由 2017 年论文 Attention Is All You Need 提出，论文链接）。
从工程视角看，LLM 可以抽象为“给定上下文后预测下一个 Token 的系统”。模型并不直接“理解”文本含义，而是通过参数化统计规律生成最可能的后续序列。
技术发展里程碑：
- 2017 年： Transformer 架构提出，奠定现代 LLM 技术路径。
- 2022 年起： 对话式大模型进入规模化应用阶段。
- 2023 年以后： 多家厂商持续迭代，模型生态由单点突破转向并行演进。
二、 数据处理单元：Token
Token 是模型处理文本时的基本计算单位。模型接收与输出的是 Token 序列，而不是“词语”本身。文本进入模型前，需要经过 Tokenizer（分词器）切分并映射为数值 ID；输出阶段再反向还原为可读文本（BPE 经典论文：Sennrich et al.；在线分词器示例：OpenAI Tokenizer）。
数据流转过程：
- 编码（Encoding）： 将输入文本切分为 Token，并映射为模型可处理的数字序列（Token ID）。
- 解码（Decoding）： 将模型输出的 Token ID 还原为自然语言文本。
图 2：文本在模型中的编码与解码路径。
Token 与自然语言的映射关系： 由于分词规则与词表设计差异，Token 与自然语言单位通常不是一一对应关系：
- 英文： 常见词可能对应 1 个 Token，复合词可能被拆分。
- 中文： 常见情况是按字或短片段组合切分。
- 特殊符号： Emoji、标点组合或稀有字符可能占用多个 Token。
工程量化参考：
- 1 个 Token 约对应 0.75 个英文单词（粗略估算）。
- 中文场景下，Token 与字数换算受分词器影响较大。
- 预算 Token 成本时，应以目标模型的官方 tokenizer 实测结果为准。
三、 临时记忆体：Context 与上下文管理
Context（上下文） 指模型在一次推理中可见的信息总和，可理解为“临时工作记忆”。典型内容包括：当前用户输入、历史对话、系统指令、工具描述、以及已生成的中间文本。
模型一次可处理的总量由 Context Window（上下文窗口） 限制，即单轮可容纳的最大 Token 数。该数值因模型版本而异，且会随产品迭代变化，实践中应以厂商官方模型文档为准（OpenAI Models、Claude Models、Gemini Models）。
突破窗口限制的技术方案：RAG 在长文档与私有知识场景中，RAG（Retrieval-Augmented Generation） 是常见方案：先检索相关片段，再将 Top-K 片段注入上下文，而不是把全部数据一次性输入模型。这通常可以在回答质量、时延与成本之间取得更可控的平衡（原始论文：RAG for Knowledge-Intensive NLP）。
图 3：全量输入与检索注入两种路径对比。
四、 指令交互与 Prompt 工程
Prompt（提示词） 是输入给模型的指令与上下文组合，对输出结果的可控性有直接影响。
在工程实践中，Prompt 主要分为两类：
- User Prompt（用户提示词）： 面向具体任务的输入内容。
- System Prompt（系统提示词）： 由系统侧配置，用于约束角色、能力边界与输出规则。
Prompt Engineering（提示词工程）： 核心目标不是“堆技巧”，而是提高任务表达的确定性。实践中可优先遵循三点：
- 目标明确：先定义任务边界与预期输出。
- 约束清晰：给出格式、风格、判定标准。
- 上下文充分：提供必要背景与输入样例。
五、 外部能力扩展：Tool 与标准化协议 MCP
LLM 本体并不天然具备实时联网、持久化操作或高精度外部执行能力。Tool（工具） 机制通过函数调用方式把这些能力外接给模型。
标准的 Tool 调用工作流：
- 用户提交请求至平台（平台携带可用的工具列表）。
- 大模型分析请求，生成包含工具参数的调用指令。
- 平台执行具体工具调用并获取返回结果。
- 大模型整理工具返回的数据，生成最终的自然语言回复。
不同模型平台在工具定义与调用协议上存在差异。MCP（Model Context Protocol） 的价值在于提供统一接口语义，降低多平台接入成本与迁移复杂度（MCP 官方文档；Tool Use 概览）。
图 4：请求经 LLM 决策后，通过 MCP 访问工具并回流到 Agent 循环。
六、 自主决策系统：Agent 与 Agent Skill
当模型具备多步规划、工具选择与状态回读能力时，可以构建 Agent（智能体）。Agent 本质上是“以目标为中心的执行控制层”，常见模式包括 ReAct、Plan-and-Execute 等（ReAct 论文：Synergizing Reasoning and Acting in Language Models）。
Agent Skill（任务定制）： Skill 是面向 Agent 的任务说明资产，用于沉淀某类任务的执行规则与输出标准。
- 数据结构： 包含元数据层（name, description）和指令层（执行步骤、判断规则、输出格式）。
- 技术实现： 通常以 Markdown 文档（如
SKILL.md）形式存在，存放于特定目录（如.claude/skills）。 - 加载机制： 采用按需加载策略，仅在用户 prompt 的上下文与 Skill 描述强相关时才会触发加载，避免污染全局 Context 从而节省 Token 消耗。
七、 概念体系全景链路
综合上述概念，可以将现代大模型应用抽象为一条分层调用链：
LM (核心引擎) ➔ Token (数据单位) ➔ Context (记忆空间) ➔ Prompt (交互接口) ➔ Tool (外部能力) ➔ MCP (工具标准) ➔ Agent (决策系统) ➔ Agent Skill (任务定制)
这条链路对应了从“文本生成能力”到“目标导向执行能力”的演进过程。实际工程落地时，建议优先明确任务边界、成本约束与安全策略，再决定是否引入 Tool、MCP 与 Agent 化架构。
本文转载自 PID0-零号进程，更多专业文章欢迎访问。
