跳到主要内容

给模型看什么:提示工程、Skills 与状态栏

这一章讲三件事: 静态指令怎么写(提示工程);专业知识怎么按需加载 (Skills);动态状态怎么实时喂(状态栏)。三者共享一个理论:模型擅长从 上下文里查,不擅长替你算——所以结论要有人提前算好放进去。

1. 这一章讲什么​

03 章解决了「送进去的内容怎么摆放才不破坏缓存」。这一章往里装货:装什么、 装在哪、什么时候装。书里把这部分分成三条线索:优化系统提示词(提示工程)、 按需加载专业知识(Agent Skills)、在轨迹末尾注入动态元信息(Agent 状态栏)。

先记住贯穿全章的一个理论判断,它解释了为什么三件事都成立:上下文学习(模型从输入里的示例与规则现学现用)更像 检索而非推理——模型擅长从已有内容中查找信息,但不擅长在单次处理里主动归纳 总结。

书里有个精确的比方:上下文窗口(模型一次能读进来的全部篇幅)是一台只会查、不会总结的机器:检索那半边 很强,注意力能从几万个 token 里把相关记录捞出来;缺的是提炼层——上下文里的 东西从来不会被自动数一遍、总结成一条结论1。

2. 顶层全景:主走查——数不清打了几次电话​

场景与机制来自原书;对话细节为按原书描述的还原。

任务:系统提示词要求 Agent 给每个商家拨打不超过 3 次电话。实际执行中, Agent 打满 3 次之后,经常数不清到底打了几次,又打了第 4 次,甚至反复拨打 同一个号码2。

没有状态栏:
  轨迹里有 3 条通话记录,但「已经打了几次」这件事没有被提炼过
  → 模型每轮都要花思考 token 重新扫描上下文、从头数一遍
  → 数错,第 4 通电话拨出

加一行状态栏(放在轨迹末尾):
  <status>已呼叫 该商家 3/3 次,达到上限,停止重拨</status>
  → 模型不再扫描、不再数,直接读到结论
  → 同类任务错误率大幅下降(书里的可视化实验显示:
    无状态栏时模型逐个数思考 token,有状态栏时直接采用结论)

病根不在模型笨:关于「打了几次」的知识以原始通话记录的形式散在上下文里, 没有人替它算。状态栏的全部思想就是:把「需要数、需要算、需要归纳」的 结论提前算好,以键值对的形式放在上下文末尾——那里空间上最接近即将生成的 新 token,注意力权重最高(03 章的位置偏好)。这个机制有个统一的名字: 上下文蒸馏(把散落上下文里的隐式状态提前蒸成一条显式结论;Agent 状态栏 是它最日常的形态)3。

3. 核心原理​

3.1 提示工程:检验标准只有一个​

系统提示词该怎么写?书里给了一条一切技巧之上的检验标准:把模型当成一位聪明 的新员工——能力出众,但对你们的工作流程一无所知;它读完不知道怎么做,Agent 也一样不知道4。由此展开五个维度(五个方面),证据强度差别很大:

维度做法效果证据
语气与风格专业中立 / 夸张自信 / 轻松表情包影响相对有限——模型风格适应力强
结构化用 XML 标签,标签名自带语义<working_directory> 一眼可辨,纯文本要模型自己猜冒号关系
组织方式流程驱动,不堆规则3.4 节消融实验:打乱组织,成功率掉超 30%
业务规则细化到可执行3.2 节,Pine 的计费规则
few-shot 示例难以言传的给例子2-3 个高质量例子胜过等量抽象规则

结构化值得多说一句:现代模型对结构化输入敏感,因为训练数据里就有大量结构化 内容;XML 标签名的语义是白送的,不用模型多想一步5。

3.2 业务规则:写得越死,行为越稳​

这是提示工程里最「脏」也最值钱的部分,书里用 Pine 打电话 Agent 的计费规则演示。 模糊规则(「根据情况选择合适的计费类型」)会让行为极不稳定:「帮我退掉上个月 买的衣服」算「帮用户省钱」还是「取回本属于他的钱」?同样的任务换个时间分类就 不同6。书里给出的细化程度值得原样感受:

  • 成功率分步评估,概率(可能性)直接换算成计费模式:高于 60% 用可退款模式, 低于 30% 直接拒绝任务;
  • 通话按每分钟 $0.05 计费,汇总后四舍五入到整美元;
  • 「节省」只基于现有账单计算——不写这条,模型会把「防止明年涨价」也算成 省钱7。

分工也定得干脆:这类规则由产品经理基于线上数据设计,工程师只负责准确编码; 模型的优势是遵循复杂指令,不该在业务规则上获得自由裁量权——好的新员工培训不是 「你很聪明,自己看着办」,而是给标准操作流程8。

3.3 few-shot:什么时候给例子​

规则说不清的(文案风格、报告格式、语气分寸),给两三个高质量输入-输出示例, 效果胜过等量的抽象描述;模型本来就擅长、规则又容易说清的任务,示例纯属浪费。 工程上有两个决策点:示例放系统提示词(静态前缀,全局生效)还是伪造首轮 user/assistant 消息(按会话(一场对话)类型选用);以及示例一旦确定必须字节级稳定—— 按请求动态检索「最相关」的示例,等于每次改前缀,缓存持续失效。生产系统通常 为每类任务准备固定示例集9。

3.4 消融实验:语气不重要,组织才重要​

「以上都有效」是书的判断,书里还真做了消融(基于 Tau-Bench 航空客服与零售场景, 逐个维度改动、其余不动)10:

改动结果
换语气(夸张自信/轻松表情包)影响相对有限
保留全部内容,打乱组织(去标题、拆散流程)成功率下降超过 30%——「先验证身份再退款」被拆散后,Agent 会跳过验证直接退款
移除工具描述文字(保留函数签名)工具调用错误率增加 45%

比结论更有价值的是方法论:Agent 表现不佳时,先做消融实验,别凭感觉重写 提示词——逐项关掉组件看哪个影响最大,比猜测可靠得多11。

3.5 Skills:把专业知识做成按需加载的库​

系统提示词会随着业务膨胀:退款规则、代码规范、格式要求全塞进去,一是浪费 token, 二是稀释注意力。书里给的解法是 Agent Skills——把专业知识组织成文件包, 按「渐进式披露」三层加载:

层内容何时进入上下文
1 元数据(描述技能的简介信息)每个技能的 name + description(共约数百 token)启动时常驻
2 核心流程SKILL.md 正文被选中时用工具加载
3 细则子文档(如 html2pptx.md)需要时再深入12

第一层的 description 是路由决策的关键,写法要像路由条件而非功能介绍: 「Use when / Don't use when」加上反例——缺反例的描述会让路由准确率明显 下降,宽泛描述会在不相关任务上频繁误触发13。

实现方式有三种,书里逐一权衡:内容整体注入系统提示词(遵循最强,但缓存全废); 作为普通文件读进轨迹中间(缓存无恙,但埋在上下文中部,指令遵循变弱);生产 实现(如 Claude Code)走第三条:元数据提前给、完整内容按需加载—— 「路由」与「执行」分离14。

一个必须澄清的账:「对缓存友好」不等于零成本——技能首次被加载的那几百到几千 token 终归要付一次写入(缓存写入还加价)。它的准确含义是一次性写入、永久 受益:之后它并进前缀,持续命中。对比每轮把全文塞进系统提示词的方案,这是 数量级的差距15。顺带一提,Skills+通用执行器的模式让工具数量始终保持很少 (第 09 章的通用配置只要七个核心工具)——工具定义膨胀的问题被整个绕开了16。

3.6 状态栏:提前算好,放在末尾​

回到主走查的那个机制,把它讲全。状态栏的构成有四类信息:任务规划(TODO 列表)、 侧信道信息(当前时间、位置、调用间隔)、环境当前状态、可用能力清单。位置: 以 user 角色的消息插在轨迹末尾(借用户消息的槽位,并非真实用户所说), 紧邻即将生成的新 token17。

效果有多大?书里用专门的基准(三类任务、11 个模型、数万次评测)量化了上下文 蒸馏18:

  • 弱模型补的是准确率:最弱的几个模型准确率上涨 40 到 54 个百分点, 一个 2B 的本地小模型在这类任务上直接追平不带状态栏的前沿大模型;
  • 强模型省的是效率:思考量、延迟、花费各降约一个数量级。

三条能直接照做的经验,第三条最反直觉:

  1. 状态栏用代码维护,别拿大模型维护——实验里 20 行正则达到「标准答案」级 准确度;让前沿模型读历史再总结,反而把下游准确率拖得比不用还差;
  2. 删原始上下文前,确认状态栏覆盖了所有会被问到的问题——状态栏是有损投影, 落在没算过的维度上,问题会急转直下;
  3. 状态栏准确率要当生产指标监控——模型会无条件相信状态栏19。

格式也有讲究:要写成 衣物: 9 件(合格 7、次品 2) 这样可定位的键值对, 写成散文效果明显更差——模型又得把散文解析一遍,等于回到「扫描」20。

更新状态有两种实现,缓存代价不同:每轮替换(上下文永远只有最新一份,但 替换点之后的缓存失效——好在只波及末尾几轮)与持久追加(Claude Code 的 做法:旧状态永不删改,只增不改;缓存完全友好,代价是陈旧状态累积)。长轨迹 选后者,短轨迹或大状态选前者21。

3.7 时间感:光给读数不够,要给操作手册​

实验 2-8 的五种状态栏技术里,有两种值得单独说。工具调用计数器显式标出 「这是对 read_file 的第 3 次调用」,能触发模型的行为模式:第一次失败后查路径, 第二次列目录,第三次主动放弃换方案——深层价值是成本感知。详细错误信息给 四层内容(错误类型/完整参数/调用栈/修复建议),启用后 Agent 在错误场景找到 替代方案的成功率从 60% 升到 95%22。

把时间戳与计数器放在一起看,作者提出 Agent 需要「时间感」三轴:紧迫度(预算 轴:时间紧就果断交付)、坚持度(终点轴:分清真墙假墙,别对着 410 Gone 的接口 重试五次,也别搜两次就断言查无此信息)、警觉度(监控轴:本该 500ms 却跑了 5 秒的调用是信号)23。

然后是本节最反直觉的发现:光把读数摆到模型面前,不足以改变它的行为。四条件 对照实验里,只给原始时间戳那档与什么都不给几乎没差别(相差两三个百分点); 真正把通过率从一成出头拉到四五成(+19 到 +49 个百分点)的,是一份 「这些读数该怎么用」的操作手册。四个厂商家族的六个模型,不加手册时通过率全部 趴在一成出头的地板上——「缺时间感」是当前后训练普遍漏掉的控制,不是某个模型 笨。计数器之所以单靠一行「3/3」就能纠偏,是因为「到顶了就停」这条规则太显然; 「力气该花多少」这类节奏判断不显然,必须把策略和读数成对给24。想把节奏感 蒸馏进小模型的权重,是训练问题——第 11 章会兑现这个伏笔。

4. 作者的判断与证据​

书里给了证据的: 消融实验的三个数字(-30%、+45%、语气影响有限)、上下文 蒸馏基准(40-54 个百分点、2B 追平前沿、一个数量级的效率差)、时间感四条件 实验(+19~+49 个百分点、六模型趴地板)——这些是书里跑过或转引的测量。

是作者的判断: 「上下文学习更像检索而非推理」是作者对机制的解读(书里注明 了边界:不否定模型靠生成思维链(一步步写出推导过程)做多步思考);「提示词由产品经理设计」是从 Pine 实践归纳的分工主张。前者的可证伪条件:若模型能在单次前向里可靠完成跨记录统计, 「只会查、不会总结」之说就过头了——书里打电话数数的反例目前站在作者一边。

5. 边界与局限​

  • 状态栏的前提是状态本身可被可靠计算;状态来自可污染源(比如被注入的内容) 时,高信任位置反而放大污染——书里明确要求状态栏不能来自可污染数据源;
  • 消融实验基于 Tau-Bench 的客服类任务;创作类任务上「组织打乱」的伤害未必同幅;
  • 工具定义按需披露要求模型在训练时见过「工具定义出现在对话中间」,目前只有较新 模型支持——自托管开源模型需专门训练25;
  • 各家 API 的 Skills 机制实现不同,书里反复区分「机制本身」与「Claude Code 的 实现细节」,移植时要重新对照。

6. 可带走的​

  1. 聪明新员工检验:它读完不知道怎么做,Agent 也一样;
  2. 动了内容再谈语气:组织打乱掉 30%,语气换了没多少——先修结构;
  3. 业务规则写到可执行:阈值(预设的止损线)、粒度、「节省」的定义边界,一个都不能含糊;
  4. 难以言传的给 2-3 个固定示例;示例字节级稳定,别动态检索;
  5. 专业知识做成 Skills:元数据常驻、正文按需、细则再深入;description 写成 路由条件并带反例;
  6. 「对缓存友好」= 一次性写入永久受益,不是零成本;
  7. 结论提前算好放末尾:键值对,不是散文;用代码维护,不用 LLM 维护;
  8. 弱模型靠状态栏补准确率(可涨 40-54 个百分点),强模型靠它省一个数量级;
  9. 读数与操作手册成对给——只给读数等于什么都没给;
  10. 状态栏准确率当生产指标:模型无条件相信它。

7. 原文地图​

主题原书章原文位置
三条线索总起2 上下文工程text/04-ch02.txt:551(搜「三条相对独立的线索」)
聪明新员工标准2 上下文工程text/04-ch02.txt:563(搜「聪明的新员工」)
结构化与 XML 语义2 上下文工程text/04-ch02.txt:573(搜「标签名称本身就携带语义」)
模糊规则的不稳定2 上下文工程text/04-ch02.txt:615(搜「退掉上个月买的衣服」)
规则细化到可执行2 上下文工程text/04-ch02.txt:619(搜「60%」) · text/04-ch02.txt:619(搜「四舍五入」)
产品经理设计提示词2 上下文工程text/04-ch02.txt:621(搜「产品经理」) · text/04-ch02.txt:623(搜「自由裁量权」)
few-shot 与字节级稳定2 上下文工程text/04-ch02.txt:627(搜「两三个高质量」) · text/04-ch02.txt:629(搜「字节级稳定」)
工具定义设计2 上下文工程text/04-ch02.txt:635(搜「操作手册」)
按需披露与缓存推论2 上下文工程text/04-ch02.txt:641(搜「因果注意力」) · text/04-ch02.txt:643(搜「固定在轨迹中的原位置」)
模型能力前提2 上下文工程text/04-ch02.txt:645(搜「GPT-5.4+」)
消融实验三结果2 上下文工程text/04-ch02.txt:653(搜「风格适应能力」) · text/04-ch02.txt:655(搜「下降超过 30%」) · text/04-ch02.txt:657(搜「45%」) · text/04-ch02.txt:659(搜「先做消融实验」)
Skills 渐进式披露三层2 上下文工程text/04-ch02.txt:713(搜「第一层」) · text/04-ch02.txt:715(搜「Use when」) · text/04-ch02.txt:717(搜「SKILL.md」) · text/04-ch02.txt:719(搜「第三层」)
三种实现与权衡2 上下文工程text/04-ch02.txt:729(搜「根本性的设计决策」) · text/04-ch02.txt:733(搜「指令遵循」) · text/04-ch02.txt:735(搜「路由」)
一次性写入永久受益2 上下文工程text/04-ch02.txt:751(搜「零成本」)
Skills+通用执行器工具数少2 上下文工程text/04-ch02.txt:755(搜「七个核心工具」)
只有一半的检索引擎2 上下文工程text/04-ch02.txt:791(搜「更像检索而非推理」) · text/04-ch02.txt:793(搜「只有一半的检索引擎」)
打电话数不清2 上下文工程text/04-ch02.txt:795(搜「不超过 3 次」) · text/04-ch02.txt:797(搜「重新统计」)
强制性注意力引导2 上下文工程text/04-ch02.txt:805(搜「强制性的注意力引导」)
上下文蒸馏基准2 上下文工程text/04-ch02.txt:823(搜「上下文蒸馏」) · text/04-ch02.txt:825(搜「40 到 54 个百分点」) · text/04-ch02.txt:827(搜「一个数量级」)
键值对优于散文2 上下文工程text/04-ch02.txt:831(搜「散文」)
三条经验2 上下文工程text/04-ch02.txt:835(搜「用代码维护」) · text/04-ch02.txt:837(搜「有损投影」)
交互第三轴2 上下文工程text/04-ch02.txt:845(搜「第三条路」)
构成与位置2 上下文工程text/04-ch02.txt:853(搜「几种类型的信息」) · text/04-ch02.txt:871(搜「第 N 次 API 调用」)
两种更新与缓存代价2 上下文工程text/04-ch02.txt:897(搜「每轮替换」) · text/04-ch02.txt:899(搜「持久追加」)
计数器与详细错误 60→95%2 上下文工程text/04-ch02.txt:909(搜「成本感知」) · text/04-ch02.txt:913(搜「95%」)
时间感三轴2 上下文工程text/04-ch02.txt:923(搜「物理时间」) · text/04-ch02.txt:927(搜「真墙和假墙」)
读数+操作手册实验2 上下文工程text/04-ch02.txt:931(搜「操作手册」) · text/04-ch02.txt:933(搜「显然」) · text/04-ch02.txt:935(搜「一成出头」)
设计哲学2 上下文工程text/04-ch02.txt:939(搜「没有侵入性」)

Footnotes​

  1. 出处:「2 上下文工程」第 791-793 段(text/04-ch02.txt:791,搜「更像检索而非推理」;text/04-ch02.txt:793,搜「只有一半的检索引擎」)。 ↩

  2. 出处:「2 上下文工程」第 795 段(text/04-ch02.txt:795,搜「不超过 3 次」);机理见第 797 段(text/04-ch02.txt:797,搜「重新统计」)。 ↩

  3. 出处:「2 上下文工程」第 823 段(text/04-ch02.txt:823,搜「上下文蒸馏」)。 ↩

  4. 出处:「2 上下文工程」第 563 段(text/04-ch02.txt:563,搜「聪明的新员工」)。 ↩

  5. 出处:「2 上下文工程」第 573 段(text/04-ch02.txt:573,搜「标签名称本身就携带语义」)。 ↩

  6. 出处:「2 上下文工程」第 615 段(text/04-ch02.txt:615,搜「退掉上个月买的衣服」)。 ↩

  7. 出处:「2 上下文工程」第 619 段(text/04-ch02.txt:619,搜「60%」)。 ↩

  8. 出处:「2 上下文工程」第 621-623 段(text/04-ch02.txt:621,搜「产品经理」;text/04-ch02.txt:623,搜「自由裁量权」)。 ↩

  9. 出处:「2 上下文工程」第 627-629 段(text/04-ch02.txt:627,搜「两三个高质量」;text/04-ch02.txt:629,搜「字节级稳定」)。 ↩

  10. 出处:「2 上下文工程」第 647-649 段(text/04-ch02.txt:647,搜「消融实验」;text/04-ch02.txt:649,搜「Tau-Bench」)。 ↩

  11. 出处:「2 上下文工程」第 655-659 段(text/04-ch02.txt:655,搜「下降超过 30%」;text/04-ch02.txt:657,搜「45%」;text/04-ch02.txt:659,搜「先做消融实验」)。 ↩

  12. 出处:「2 上下文工程」第 713-719 段(text/04-ch02.txt:713,搜「第一层」;text/04-ch02.txt:717,搜「SKILL.md」;text/04-ch02.txt:719,搜「第三层」)。 ↩

  13. 出处:「2 上下文工程」第 715 段(text/04-ch02.txt:715,搜「Use when」)。 ↩

  14. 出处:「2 上下文工程」第 729-735 段(text/04-ch02.txt:729,搜「根本性的设计决策」;text/04-ch02.txt:733,搜「指令遵循」;text/04-ch02.txt:735,搜「路由」)。 ↩

  15. 出处:「2 上下文工程」第 751 段(text/04-ch02.txt:751,搜「零成本」)。 ↩

  16. 出处:「2 上下文工程」第 755 段(text/04-ch02.txt:755,搜「七个核心工具」)。 ↩

  17. 出处:「2 上下文工程」第 853 段(text/04-ch02.txt:853,搜「几种类型的信息」)与第 865-871 段(text/04-ch02.txt:871,搜「第 N 次 API 调用」)。 ↩

  18. 出处:「2 上下文工程」第 823-827 段(text/04-ch02.txt:825,搜「40 到 54 个百分点」;text/04-ch02.txt:827,搜「一个数量级」)。 ↩

  19. 出处:「2 上下文工程」第 833-837 段(text/04-ch02.txt:835,搜「用代码维护」;text/04-ch02.txt:837,搜「有损投影」)。 ↩

  20. 出处:「2 上下文工程」第 831 段(text/04-ch02.txt:831,搜「散文」)。 ↩

  21. 出处:「2 上下文工程」第 895-899 段(text/04-ch02.txt:897,搜「每轮替换」;text/04-ch02.txt:899,搜「持久追加」)。 ↩

  22. 出处:「2 上下文工程」第 909 与 913 段(text/04-ch02.txt:909,搜「成本感知」;text/04-ch02.txt:913,搜「95%」)。 ↩

  23. 出处:「2 上下文工程」第 923-929 段(text/04-ch02.txt:923,搜「物理时间」;text/04-ch02.txt:927,搜「真墙和假墙」)。 ↩

  24. 出处:「2 上下文工程」第 931-935 段(text/04-ch02.txt:931,搜「操作手册」;text/04-ch02.txt:935,搜「一成出头」)。 ↩

  25. 出处:「2 上下文工程」第 645 段(text/04-ch02.txt:645,搜「GPT-5.4+」)。 ↩