1. 本章要说的概念
Prompt（提示）、Instruction（指令）、Context（上下文），以及 Token（词元） 和 Context Window（上下文窗口）。
2. 模拟任务：聚会找餐厅
假设你需要和几个朋友在北京聚餐，想找个餐厅。于是你打开 WorkBuddy，新建一个对话，然后输入：
帮我找几家适合朋友聚餐的北京餐厅。人数 6—8 人，预算约 100 元/人，位置在四环以内，最好靠近三环。请列出 3 家候选，整理餐厅名称、地址、菜系、人均消费和推荐理由；不符合条件的信息不要硬凑，不确定的地方请标出来。
于是，WorkBuddy 引导你连接腾讯地图 MCP，用它查找餐厅并整理出 3 家候选，提供餐厅名称、地址、菜系、人均消费和推荐理由，方便你比较选择。
你接着想订座，但 WorkBuddy 反馈，它目前还没有连接美团订座这类服务，无法直接替你订座，于是提供了目标餐厅的订餐电话。你最终自己联系餐厅，确认空位、包间、低消和最终价格。
3. Prompt（提示）：你这次交给 AI 的任务内容
你给 WorkBuddy 输入的这整段文字都是 Prompt。Prompt 可以是一句话，也可以是一份完整任务说明。对 Agent 来说，一份好任务通常包含：
目标：最后要得到什么；
资料与工具：可以使用哪些文件、网页、数据库或外部工具；
边界：时间、地区、预算和排除项；
输出：文件类型、篇幅或结构；
验收：怎样算完成；
确认点：哪些动作要先问你。
System Prompt（系统提示）也是 Prompt 的一种。 区别在于，它不是用户在聊天框里输入的，而是 AI 应用或 Agent 软件在后台先发给模型的。System Prompt 可以装入角色说明、工具说明和 Instructions。新人用户一般看不到全文，只要知道：你在聊天框里写下的内容，并不是模型收到的全部 Prompt。
4. Instruction（指令）：要求 Agent 照着做的内容
Instruction 常译为“指令”，指的是要求 Agent 怎样做、不能怎样做的内容。人数、预算、地点、输出格式、禁止事项和必须暂停确认的动作，都可以写成 Instructions。
找餐厅任务中的 Instructions 包括：
人数按 6—8 人考虑；
预算控制在约 100 元/人；
只找北京四环以内，优先三环附近；
整理 3 家候选及其名称、地址、菜系、人均消费和推荐理由；
找不到足够候选时说明缺口，不要硬凑；
不确定的信息要明确标出。
也就是说，Prompt 是一次送给模型的输入，Instruction 是输入中要求 Agent 照着做的内容。
5. `AGENTS.md`、Skill（技能包）和 Memory（记忆），跟前面两个词是什么关系
Prompt 和 Instruction 说清以后，再简单说几个也跟规则贴边的词，不容易串线。
| 概念 | 它回答什么问题 | 它与 Instruction 的关系 |
|---|---|---|
| Prompt | 这一次，有什么内容被送给模型 | Prompt 里可以包含 Instructions，也可以包含问题、背景资料和工具说明 |
| 项目规则文件 | 长期要求原来保存在哪里 | AGENTS.md、CLAUDE.md 等文件可以保存多条 Instructions，供 Agent 读取和执行 |
| Skill | 某类任务的做法怎样被打包、重复使用 | Skill 可以把 Instructions、步骤、示例、模板和工具说明组织在一起 |
| Memory | 哪些信息被保存下来，供以后再次使用 | Memory 常保存事实、经历或偏好，被读取后会影响后续任务 |
以找餐厅为例：
你在聊天框里输入的整段找餐厅要求，是用户 Prompt；
其中“预算约 100 元/人”“只列 3 家”，是 Instructions；
如果某个项目的
AGENTS.md规定“预订聚餐餐厅前须经领导确认”，这是保存在规则文件里的一条 Instruction。Agent 读取后，应该会在你预订餐厅时主动提出要求，让你提供确认信息；如果启用了“餐厅调研”Skill，其中可能同时提供筛选步骤、输出模板和“不确定信息必须标出”等 Instructions；
Memory 里保存的“用户不吃辣”是一条偏好信息。它被读取后，会影响模型筛选餐厅。
6. Context（上下文）：模型当前可以使用的信息总和
Context 常译为上下文。在找餐厅任务中，它可能包括：
AI 应用在后台预设的 System Prompt；
当前这段找餐厅的 Prompt；
前面关于人数、预算、位置和订座的对话；
腾讯地图 MCP 提供的工具名称和使用说明；
地图工具返回的餐厅名称、地址、人均消费等结果；
WorkBuddy 关于暂不支持直接订座的反馈；
餐厅订餐电话和已经整理好的候选名单。
例如，第一轮搜索返回的餐厅都离三环较远，你补充一句“优先国贸或双井附近”。这条新要求和第二轮搜索结果也会进入 Context，模型再根据更新后的信息调整候选名单。
Context Engineering（上下文工程），就是在任务进行中，持续安排模型每一步实际拿到的信息。在这个案例里，你补充地点要求、保留有效候选、把过长对话整理成摘要，都属于在管理 Context；Agent 软件也会在后台选择需要带入下一轮的规则、对话和搜索结果。
7. Token（词元）与 Context Window（上下文窗口）
Token（词元）是模型处理内容时使用的基本片段。汉字、词的一部分、数字、标点和空格都可能被切成 Token。它常用于计算内容长度，以及某些模型服务的用量和费用，不等于汉字数，也不是网络流量。
Context Window（上下文窗口）是模型一次能够处理的 Token 总量。System Prompt、历史消息、资料、工具结果和准备生成的回答，都要占用这个有限空间。
在找餐厅任务中，你写下的要求、连接工具的过程、腾讯地图返回的餐厅信息、后续订座对话，以及模型整理的候选名单，都要占用 Context Window。搜索结果越多，不等于模型就一定判断得越好；无关或重复信息太多，反而可能挤占真正重要的预算、位置和人数要求。
如何查看上下文使用情况
不同 Agent 软件查看上下文使用情况的方式有所差异，大体可以通过命令或界面按钮查看：
命令查看，比如在 Codex CLI 中输入
/status，在 Claude Code 中输入/context。按钮查看，比如在 WorkBuddy 的输入框旁边，会有一个小圆环。点开或把鼠标移上去，会显示类似“52.3% · 87.8K / 168.0K 上下文已使用”的信息。
上下文快满了，会发生什么
假设你先后查了 20 家餐厅，又反复比较地址、菜系、包间和电话，聊天记录与工具结果会越来越多，小圆环也会越来越满。接近上限时，不同 AI 应用或 Agent 软件可能会压缩较早的对话、舍弃部分旧内容，或者提示无法继续加入更多内容。用户最容易察觉到的表现，就是 AI 好像“失忆了”：忘了最初约 100 元/人的预算，重复推荐已经排除的餐厅，或者漏掉“四环以内”这个条件。
可以这样处理：
先让 WorkBuddy 把当前结论压缩成一份短摘要，保留人数、预算、位置、已排除餐厅和剩余候选；
检查摘要有没有漏掉关键条件；
另开一个新对话，把这份摘要贴进去，再继续筛选或联系餐厅；
如果任务很长，也可以把候选表和关键决定保存成文件，让新对话重新读取。
有些 Agent 会自动进行 Compaction（上下文压缩），把较长的历史记录缩成更短的记录后继续工作；第八章会对 Compaction 进行专门解释。自动压缩也可能漏掉细节，所以关键预算、位置和禁忌仍要重新检查。
8. 一句话释义
Prompt 是提交给模型的内容
Instruction 是要求 Agent 怎样做、不能怎样做的内容
Context 是模型当前可以使用的信息总和
Token 是模型处理内容时使用的基本片段
Context Window 是模型一次能够处理的 Token 总量