LLM&Prompt&Token

返回 Agent 开发笔记合集

LLM、Prompt 和 Token 经常一起出现，但它们不是同一个层面的概念。

LLM 是负责理解、推理和生成的模型；Prompt 是我们交给模型的任务说明；Token 是模型读写信息时使用的基本单位。把这三个概念放在一起看，会更容易理解 AI 应用为什么要写提示词、为什么会有上下文窗口、为什么调用模型会产生费用，以及为什么 Agent 系统需要管理上下文和输出格式。

可以先用一句话建立直觉：

Prompt 把任务交给 LLM，LLM 通过 Token 读取输入并生成输出。

1、LLM：负责理解、推理和生成的模型

LLM 是 Large Language Model 的缩写，也就是大语言模型。它的核心能力是根据上下文理解语言、预测后续内容，并生成新的文本或结构化结果。在这个过程中，它可以表现出总结、翻译、推理、改写、代码生成、信息抽取等能力。

在 Agent 系统里，LLM 更像一个认知核心：它负责理解当前任务，基于上下文做判断，并生成下一步回答、计划或工具调用参数。但 LLM 本身不等于完整的 Agent。一个能稳定干活的 Agent，还需要工具、上下文管理、权限控制、结果校验、日志追踪和人工确认等工程设施。

LLM 大致怎么工作

大多数现代大语言模型都基于 Transformer 架构。Transformer 的关键思想是注意力机制，也就是模型在处理一段上下文时，会动态判断哪些词、句子、代码片段或历史信息更值得关注。

常见的 Transformer 架构可以粗略分成三类：

1. 编码器（Encoder） 编码器接收文本或其他数据作为输入，并输出它的密集表示，也就是 embedding。
   • 示例：BERT
   • 常见用途：文本分类、语义搜索、命名实体识别
2. 解码器（Decoder） 解码器专注于逐步生成 token，直到完成一个序列。
   • 示例：GPT、Llama
   • 常见用途：文本生成、聊天机器人、代码生成
3. 编码器-解码器（Encoder-Decoder / Seq2Seq） 编码器先理解输入，解码器再生成输出。
   • 示例：T5、BART
   • 常见用途：翻译、摘要、改写

对日常使用者来说，不一定要记住所有架构细节。更重要的是理解：模型并不是在数据库里搜索一个固定答案，而是在当前上下文里，根据训练得到的模式和输入信息生成最可能有用的输出。

使用 LLM 时要记住的几件事

LLM 很强，但它不是事实数据库。它的训练知识可能过时，也可能不知道你的私有业务、代码库、产品规则和当前上下文。需要实时事实、内部资料或精确证据时，通常要通过 RAG、搜索、数据库、工具调用或人工输入补足。

LLM 的输出具有不确定性。同一个问题在不同模型、不同上下文、不同温度参数下，可能得到不同答案。所以重要任务不能只看一次输出，而要配合测试集、结构化输出、校验逻辑和人工审核。

LLM 只能基于它本轮看见的上下文工作。它不会天然记得所有历史，也不会自动知道没有放进上下文窗口的信息。所谓“模型记忆”，在工程上通常要靠会话历史、长期记忆、检索系统或外部存储来实现。

LLM 的能力要通过工程系统落地。模型可以生成建议、计划、代码或工具参数，但是否允许执行、如何执行、执行失败怎么办，都应该由 Harness、Runtime、Tool、Sandbox、Approval Gate 等系统设计负责。

多模态

2、Prompt：给模型的任务说明书

Prompt 是给模型看的任务输入。它可以是一句话，也可以是一份结构化任务说明，里面包含目标、背景、输入材料、约束条件、输出格式、示例和失败处理规则。

Prompt Engineering 就是围绕提示词进行设计、调试和评估的方法。它不是写一句“神奇咒语”，而是在设计人、模型和系统之间的任务接口。

在 Agent 系统里，Prompt 像任务说明书：它告诉 LLM 现在要做什么、依据什么做、不能做什么、结果要长什么样、做不了时应该怎么处理。

Prompt 的常见组成

一个 Prompt 不一定要包含所有部分，但可靠的 Prompt 通常会把关键信息分层写清楚。

一个常见的 Agent prompt 不是只有用户问题，而是多层信息叠加后的结果：

系统规则 + 开发者规则 + 用户请求 + 当前上下文 + 可用工具 + 输出格式

用户表面上可能只输入了一句话，但模型实际收到的还可能包括系统指令、检索结果、工具定义、历史摘要、业务规则和结构化输出要求。

一个标准提示词可以怎么写

如果不知道怎么写，可以先使用下面这个结构：

任务：你要完成什么？

背景：为什么要做？有哪些必要上下文？

输入：需要处理的材料是什么？

要求：必须遵守哪些规则、边界和偏好？

步骤：建议按什么顺序处理？

输出：结果要用什么格式？需要包含哪些字段？

失败处理：信息不足、冲突或无法完成时应该怎么说？

这不是唯一模板，但它覆盖了大多数日常任务。写 Prompt 时，最重要的不是句子华丽，而是让模型少猜。

比如一个“写文章摘要”的 Prompt 可以这样写：

任务：请把下面这篇文章总结成一段中文摘要。

背景：摘要会展示在博客列表页，读者需要快速判断要不要点进去。

输入：<文章正文>

要求：
1. 不要添加文章中没有的信息。
2. 保留文章的核心观点和适合的关键词。
3. 语气自然，不要像广告文案。

输出：
一段 80 到 120 字的中文摘要。

失败处理：
如果正文信息不足，请说明“无法生成可靠摘要”，并指出缺少什么。

这个 Prompt 比“帮我总结一下”更稳定，因为它说明了使用场景、信息边界、风格要求和失败行为。

优秀 Prompt 的写法

优秀的 Prompt 通常不是更长，而是更清楚。可以按下面的顺序写。

第一，先写清楚交付物。不要只写“优化一下”“分析一下”“帮我看看”。更好的写法是说明结果形态，比如“找出 3 个主要风险”“改写成适合发布的版本”“输出一个 JSON 分类结果”。

第二，补足必要上下文。模型不会自动知道你的业务、读者、代码库、产品规则和前置讨论。只要这些信息会影响判断，就应该放进 Context。

第三，明确边界和约束。例如“只基于给定材料回答”“不要编造引用”“不要修改无关文件”“只评论本次 diff”“如果不确定就标记为不确定”。这些约束不能替代系统权限，但能减少自然语言层面的误解。

第四，指定输出格式。如果输出要被人读，可以指定 Markdown、表格、标题层级和语气。如果输出要被程序处理，就应该使用 JSON Schema、Zod 或其他结构化输出方式。

第五，说明不确定时怎么办。很多坏结果不是因为模型不会，而是因为信息不足时仍然硬答。可靠的 Prompt 应该告诉模型：缺少关键上下文时先说明缺口；证据不足时不要下结论；多个答案都可能时列出假设；任务不安全时请求确认或拒绝执行。

第六，用示例减少歧义。一个输入输出样例，往往比一大段抽象描述更能让模型理解你想要的结果。示例不必很多，通常一到两个高质量示例就够了。

一个可以参考的优秀 Prompt 示例

下面这个 Prompt 可以作为学习模板。它不是因为“写得长”才好，而是因为它把角色、目标、输入材料、资料边界、输出结构、风格要求、失败处理和自检标准都说清楚了。

角色：
你是一名擅长把 AI 工程概念讲清楚的技术写作者。你的读者是刚开始学习 Agent 开发的初学者，他们懂一点编程，但不熟悉 LLM 应用工程。

任务：
请基于我提供的资料，写一篇介绍“Prompt Engineering”的中文学习笔记。

写作目标：
1. 让读者理解 Prompt Engineering 不是写咒语，而是在设计人与模型之间的任务接口。
2. 让读者知道一个可靠 Prompt 通常由哪些部分组成。
3. 让读者看完后能照着写出一个基本可用的 Prompt。

输入资料：
<这里粘贴文章、课堂笔记、官方文档摘要或你自己的要点>

资料边界：
1. 只能基于输入资料和通用工程常识写作。
2. 不要编造论文、产品功能、数据或引用来源。
3. 如果资料里没有明确提到某个结论，请用“可以理解为”“通常”这类谨慎表达，不要写成绝对判断。

文章结构：
1. 先用 2 到 3 段解释 Prompt Engineering 是什么。
2. 再用一个表格说明 Prompt 的常见组成，包括角色、目标、上下文、约束、输出格式、示例和失败处理。
3. 接着给出一个可直接套用的 Prompt 模板。
4. 然后用一个“坏 Prompt -> 好 Prompt”的对比例子说明区别。
5. 最后用 3 到 5 条要点总结。

风格要求：
1. 使用中文。
2. 语气清楚、直接，像给朋友讲概念，不要像营销文案。
3. 每个小节都要有明确标题。
4. 遇到英文术语时，第一次出现要给出中文解释，例如 Prompt Engineering（提示词工程）。
5. 不要堆砌抽象词，每个关键点尽量配一个简单例子。

输出格式：
使用 Markdown 输出，包含：
- 一级标题
- 二级标题
- 一个表格
- 一个代码块形式的 Prompt 模板
- 一个坏例子和一个好例子
- 结尾总结

失败处理：
如果输入资料不足以完成文章，请先列出缺少的信息，再给出一个“基于现有资料的简版草稿”。不要假装资料完整。

自检标准：
输出前请检查：
1. 有没有添加资料中没有依据的具体事实。
2. Prompt 的组成是否解释完整。
3. 示例是否能被读者直接模仿。
4. 文章是否避免了“只要这样写就一定正确”这类绝对化表达。

这个示例的重点不是让所有 Prompt 都写成这么长，而是提供一个完整骨架。真实使用时，可以按任务复杂度删减：简单任务保留“任务、输入、要求、输出”就够；复杂任务再补充角色、资料边界、失败处理和自检标准。

好 Prompt 和坏 Prompt 的区别

坏 Prompt 通常不是“短”，而是缺少关键决策信息。

更好的写法会把目标、输入、约束和输出放在一起：

任务：请把下面这段产品介绍改写成更适合官网首屏的版本。

目标读者：中小企业的运营负责人。

要求：
1. 保留原文事实，不增加没有依据的承诺。
2. 语气专业、直接，不要夸张。
3. 中文输出，长度控制在 120 字以内。

输出：
只输出改写后的文案，不要解释修改过程。

原文：
<这里放原文>

这个版本并没有复杂很多，但模型已经知道该为谁写、怎么写、写多长、能不能添加新信息，以及最终输出什么。

Prompt 不能替代工程约束

Prompt 负责表达意图，但它不是安全边界。删除文件、付款、发消息、写数据库这类动作，不能只靠一句“不要做危险操作”来约束模型，而应该靠权限、沙盒、审批、Schema 校验、日志和测试来控制。

更准确的理解是：

Prompt 负责告诉模型应该怎么想和怎么说。
Harness 负责决定系统允许做什么、如何验证、如何落地。

3、Token：模型读写信息的基本单位

Token 是模型处理文本时使用的基本单位，也是很多模型 API 的计费单位。它可以近似理解为“字”“词”或“符号片段”，但不完全等同于自然语言里的字或词。

不同模型使用不同 tokenizer，所以同一段文字在不同模型里可能会被切成不同数量的 token。

一般可以粗略理解：

英文：一个单词可能是 1 个或多个 token
中文：一个汉字或词语可能被切成 1 个或多个 token
符号和代码：括号、空格、缩进、标点也可能占 token

实际 token 数量应该以模型 API 返回的 usage 为准。

Token 为什么重要

Token 会影响四件事：上下文容量、调用成本、响应延迟和输出长度。

Agent 系统往往比普通聊天更消耗 token，因为它会包含系统指令、工具定义、历史消息、RAG 材料、代码片段、工具结果和多轮修复过程。

如果不管理 token，Agent 很容易变慢、变贵，甚至因为上下文超限而丢失关键材料。

Token 消耗来自哪里

输入 token 和输出 token 通常会分别计费，输出 token 往往也会影响延迟。长篇输出、反复修复和多 Agent 协作都会增加总成本。

Token 和 Context Window 的关系

Context Window 是模型一次请求最多能处理的 token 容量。

如果上下文超过窗口，系统必须截断、摘要、检索或分块处理。否则模型无法完整看到任务所需信息。

可以这样理解：

Token = 信息单位
Context Window = 本轮能放多少信息单位的工作台

上下文窗口大不代表可以随便塞材料。噪声越多，模型越难抓重点，成本也越高。

Token 预算怎么设计

一个代码修复 Agent 的 token 预算可以这样设计：

固定指令：2K token
用户任务和 PR 描述：1K token
错误日志摘要：2K token
相关源码：8K token
工具定义：2K token
历史摘要：1K token
预留输出：2K token
总预算：18K token

如果错误日志有 50K token，就不应该整段塞进去，而应该先提取关键失败、文件路径、堆栈和命令。Token 管理本质上就是信息取舍：把最有价值的材料放进上下文，把噪声、重复信息和低价值材料移出去。

4、三者的联系

LLM、Prompt 和 Token 可以放进同一条调用链里理解：

用户意图
  -> 写成 Prompt
  -> 被 tokenizer 切成输入 Token
  -> LLM 基于上下文生成输出 Token
  -> 输出 Token 被还原成人能读的文本或程序能处理的结构

三者共同决定了一次模型调用的质量。

Prompt 决定任务表达是否清楚。如果 Prompt 模糊，LLM 就会猜；如果 Prompt 结构清晰，模型更容易稳定输出。

Token 决定模型能看到多少信息，以及这次调用要花多少成本和时间。如果 token 预算不够，再好的材料也放不进去；如果把无关材料塞太多，模型反而更难抓住重点。

LLM 决定理解和生成能力的上限。更强的模型通常能处理更复杂的任务，但仍然需要清楚的 Prompt、合适的上下文和可靠的工程约束。

5、三者的区别

也可以用一个比喻来区分：

LLM 像大脑。
Prompt 像任务说明书。
Token 像说明书和回答里的信息颗粒。

所以，三者不是并列替代关系，而是互相依赖的关系。没有 LLM，Prompt 没有执行对象；没有 Prompt，LLM 不知道本轮任务；没有 Token，模型无法把输入输出计量、放进上下文窗口并计算成本。

6、放到 Agent 开发里怎么看

在普通聊天里，用户经常只关心“我问了什么，模型答了什么”。但在 Agent 开发里，LLM、Prompt 和 Token 会影响整个系统设计。

一个 Agent 可能会这样组织一次任务：

系统规则：你必须遵守哪些安全边界
开发者规则：你应该按什么流程工作
用户请求：这一次用户想完成什么
上下文：相关文件、历史消息、检索资料、工具结果
工具定义：你可以调用哪些工具，参数是什么
输出格式：最终必须返回什么结构

这些内容都会进入模型上下文，都会消耗 token，也都会影响 LLM 的判断。

所以 Agent 工程里常见的设计问题，本质上都和这三者有关：

7、常见误区

误区一：Prompt 越长越好

不是。Prompt 应该足够完整，但也要有信息优先级。把所有材料都塞进去，会增加 token 成本，也会让模型抓不住重点。

误区二：Token 等于字数

不等于。Token 是 tokenizer 的切分结果，和自然语言字数只是近似相关。中文、英文、代码、空格和符号的切分方式都可能不同。

误区三：上下文窗口越大越省心

不是。大窗口能放更多内容，但不解决信息选择、优先级和噪声问题。材料越多，越需要筛选、摘要和结构化。

误区四：模型越强，Prompt 越不重要

模型越强，能做的事越多，Prompt 反而更需要清晰地定义边界。否则系统会把模糊需求放大成不可控行为。

误区五：Prompt 能替代权限控制

不能。模型可能误解或忽略约束。危险动作必须靠系统权限、审批、沙盒和审计控制。

误区六：只控制输入 token 就够了

不够。输出 token 也会影响成本和延迟。长篇输出、反复修复、多轮对话和多 Agent 协作都会增加输出成本。

8、一句话总结

LLM 是模型能力，Prompt 是任务接口，Token 是信息单位。

写 AI 应用时，不要只问“模型强不强”，还要问：

Prompt 有没有把任务说清楚？
上下文有没有放对材料？
Token 预算是否合理？
模型输出能不能被验证和落地？

把这三个问题同时想清楚，才能从“会聊天的模型”走向“能稳定完成任务的系统”。

参考资料

• OpenAI API Documentation
• OpenAI: Tokenizer
• Anthropic: Prompt engineering overview
• Anthropic: Context windows
• Google Machine Learning: Prompt engineering