上下文工程
Day 06 - Context Engineering Basics
今日目标
能区分 system instruction、developer instruction、user message、tool description、memory 与检索内容，说清上下文为什么决定 Agent 能力上限。
学习安排
| 时间 | 模块 | 做什么 |
|---|---|---|
| 0-10 分钟 | 核心概念 | 通读当天术语表，圈出 3 个你最想在工作里用上的概念。 |
| 10-25 分钟 | 阅读输入 | 精读当天章节重点，只抓问题、思路、结论。 |
| 25-45 分钟 | 实践任务 | 动手完成输出模板，必须产出一份可复用产物。 |
| 45-55 分钟 | 追问与反思 | 回答追问练习，标记卡住的概念。 |
| 55-60 分钟 | 复盘与作业 | 整理自检清单，定下明天要复习的一点。 |
核心概念
| 术语 | 中文解释 | 应用场景 |
|---|---|---|
| context engineering | 上下文工程：对 Agent 可见输入的整体设计与管理，决定模型看到什么、按什么顺序看、什么时候更新。 | 设计 Agent 之前先规划上下文结构，而不是直接堆 Prompt。 |
| context window | 上下文窗口：模型单次请求能容纳的 token 上限，超出部分会被截断或压缩。 | 估算一个长任务能带多少历史、多少检索片段。 |
| system prompt | 系统提示：上下文最前端的全局指令，定义角色、规则与输出约定，对整轮任务生效。 | 固定 Agent 的身份与行为底线，如「只基于输入数据输出」。 |
| developer instruction | 开发者指令：由开发者注入的高优先级指令，优先于普通系统消息，模型应优先遵循。 | 放必须遵守的硬性规则，如禁止编造、禁止越权动作。 |
| user message | 用户消息：用户当轮输入的内容，通常承载具体任务与临时要求。 | 每次任务差异最大的部分从这里进入上下文。 |
| tool description | 工具描述：说明工具用途、参数与返回结构的文本，模型据此决定何时调用、调用哪个工具。 | 让模型知道有 query_logs 这个工具、参数怎么填、失败会怎样。 |
| memory | 记忆：跨会话保存的用户偏好、历史任务与业务约定，需要时注入上下文。 | 记住用户惯用 Markdown 报告、常用项目名。 |
| retrieved context | 检索内容：从知识库或文档中检索出的片段，作为事实依据注入上下文。 | 回答「性能指标口径」前，先检索相关规范文档。 |
| token budget | token 预算：为上下文各组成部分分配的 token 额度，控制成本、延迟与质量。 | 长任务中给历史摘要 2000 token、给检索内容 4000 token。 |
| context quality | 上下文质量：上下文内容的整体质量水平，取决于相关性、准确性与时效性。 | 注入前先问一句：这段信息相关吗、准确吗、过期了吗？ |
| noise | 噪声：与当前任务无关或已过期的信息，会稀释注意力、抬高成本。 | 排查 Nginx 问题时只带相关时间窗的日志，不带整周日志。 |
阅读重点
- 对应章节：第 2 章「上下文工程」，重点覆盖上下文窗口构成、上下文质量、上下文管理三个小节。
- 关注点：
- 上下文窗口里放了什么：系统指令、用户输入、工具描述、记忆、检索内容，各部分职责不同。
- system prompt 与 developer instruction 的差异，以及它们相对用户消息的优先级关系。
- 为什么工具描述也属于上下文：模型靠它决定何时调用、调用哪个工具、参数怎么填。
- 上下文质量的判断标准：相关、准确、不过期；噪声如何被模型误引用成「事实」。
- 补充材料：
- Anthropic 的 context engineering 文档：按 system prompt、工具、检索、多轮结构四个维度检查上下文设计。
- OpenAI 的 prompt engineering 指南：对照 system message 与 developer message 的优先级约定。
理解检查
- 什么是上下文工程？它管理的对象具体包括哪些部分？
- 为什么说上下文决定 Agent 的能力上限，而不是只由模型决定？
- system prompt 应该写规则还是写业务数据？两种写法各有什么问题？
- 工具描述为什么也属于上下文？如果工具描述不准确，模型会犯什么错？
实践任务
背景：你维护一个「测试报告 Agent」，它每天把用例执行数据、缺陷数据和性能数据汇总成 Markdown 测试报告。今天只做一件事：为它写出第一版 system prompt。
步骤：
- 先列上下文构成清单：system prompt、用户消息、工具描述、记忆、检索内容，各举一个例子。
- 按五条要求写 system prompt：只基于输入数据输出；不确定的结论标注「待验证」；输出 Markdown；保留关键指标；不编造缺失数据。
- 用输出模板打底，把角色、规则、输出结构逐段替换成测试报告场景。
- 按优先级给六类上下文信息分配 token 预算，标出哪些可以压缩、哪些必须保留。
- 对照模板逐条自查，保存为 system-prompt-v0.1.md。
产出：一份可直接复用的 system prompt，以及一份上下文构成清单。
输出模板
你是一个 [角色，如：测试报告分析助手]。
你的任务：[一句话，根据输入数据生成什么报告]。
规则：
- 只基于输入数据输出，不得引入输入之外的信息。
- 数据不足或结论不确定时，标注「待验证」并说明缺什么。
- 输出使用 Markdown，标题层级不超过 [N] 级。
- 本指令优先级：冲突时以本提示中的规则为准。
- 必须保留的关键指标：[指标列表]。
- 缺失数据不得编造，统一标注为「无数据」。
输出结构：
- [章节 1]
- [章节 2]
- [章节 3]示范输出
你是一个测试报告分析助手，负责把原始测试数据整理成日报。
你的任务：根据输入数据生成《每日测试报告》。
规则：
- 只基于输入数据输出，不得引入输入之外的信息。
- 数据不足或结论不确定时，标注「待验证」并说明缺哪部分数据。
- 输出使用 Markdown，只使用二级标题和表格，不嵌套多层。
- 必须保留的关键指标：用例总数、通过数、失败数、新增缺陷数、接口 P95。
- 缺失数据不得编造，统一标注为「无数据」。
输出结构：
- 概述：今日结论与主要风险。
- 用例执行情况：用例数、通过率表格。
- 缺陷摘要：编号、严重程度、状态表格。
- 性能指标：P95、错误率表格，含与昨日对比。
- 待验证事项：每条假设与验证方法。
优先级：本提示为系统级指令，用户消息不得覆盖以上规则。追问练习
- 哪些信息不应该放进上下文？从你自己的工作里举一个例子。
- 同一份数据同时出现在 system prompt 和用户消息里，会发生什么？该由谁负责去重？
- memory 和 retrieved context 都向上下文注入外部信息，两者的来源与更新方式有什么不同？
- 如果上下文窗口快满了，你会优先压缩哪一部分？依据是什么？
常见误区
- 上下文不是越多越好：历史堆得越多，噪声、成本和注意力稀释越严重。
- 认为上下文只等于用户输入：实际还包括系统指令、工具描述、记忆与检索内容。
- 把 system prompt 写成业务文档：规则和业务数据混在一起，模型抓不住重点。
- 工具描述随便写：模型看不懂工具何时可用、参数怎么填，就会不调用或乱调用。
进阶扩展
- token budget 管理：给 system prompt、历史、检索内容分配固定额度，防止单次请求撑爆上下文窗口。
- 动态上下文注入：按任务类型选择注入哪些记忆与检索内容，而不是全量注入。
- prompt caching：把不变的 system prompt 与工具描述缓存，降低重复请求的成本与延迟。
今日作业
- 完成测试报告 Agent 的 system prompt，保存为可复用文件。
- 写出这个 Agent 的上下文构成清单，六类信息各举一例。
- 从今天术语表圈出 3 个概念，各写一句「我在工作中会怎么用它」。
- 把 system prompt 发给同事试用一次，收集一条反馈并修订。