上下文管理
③ 上下文管理
Section titled “③ 上下文管理”定位:Context Window 就是模型的「工作台」——越乱越小越失效。128K tokens ≠ 无限注意力。Harness 的职责,是当守门人:让这块有限的空间,永远只装当下最有用的信息。
📎 上级:设计指南/Agent设计;出处:实践分享第一章 P6(4 件事之三)。
一、核心认知:注意力是黄金,不是免费的
Section titled “一、核心认知:注意力是黄金,不是免费的”容量大 ≠ 用得好。两件常被忽略的事实:
- 128K tokens ≠ 无限注意力:窗口能塞下,不代表模型「看得清」——塞得越满,关键信息越容易被淹没(lost in the middle)。
- 工作台越乱越失效:无关材料、过期对话、超大返回,都是噪音;噪音越多,推理质量越往下掉。
一句话:注意力 = 黄金,Harness 是守门人。守门人的任务不是「能放就放」,而是「只放最该放的」。
二、三种守门手段
Section titled “二、三种守门手段”| 手段 | 做什么 | 效果 |
|---|---|---|
| 渐进披露 | 只给当前必须的工具 + 知识,其余按需再加载 | 工作台干净,选择噪音小 |
| 生成 → 评估 → 重来 | 错了就丢掉重试,不把失败过程留在上下文里 | 试错不污染主线 |
| 子 agent 隔离 | 把深挖/调研丢给独立上下文的子 agent,只回结论 | 主线不被一堆中间材料撑爆 |
渐进披露:和 Skill 三级加载同源
Section titled “渐进披露:和 Skill 三级加载同源”只让模型「此刻该看的」进上下文——这正是 Skill 的设计哲学:
- L1 metadata 常驻(判断「该不该用」),L2 正文 / L3 资源按需加载;
- 大段字典、示例外置成 reference,用到才读;
- 脚本只跑不读,只回 stdout。
详见 设计指南/Skill设计。领域知识怎么建模是本体的事,怎么按需喂是渐进披露的事。
三、和「记忆管理」的分工
Section titled “三、和「记忆管理」的分工”| 关注 | 页面 | |
|---|---|---|
| 上下文管理(本页) | 空间维度:这一刻窗口里该放什么 | 本页 |
| 记忆管理 | 时间维度:跨轮/跨天怎么不丢状态 | 设计指南/Agent设计/记忆管理 |
两者咬合:压缩是「时间满了怎么办」,渐进披露是「空间一开始就别乱放」。
四、案例:那个「越问越笨」的问数 Agent
Section titled “四、案例:那个「越问越笨」的问数 Agent”团队上线了一个成本问数 Agent,头几天好用,后来用户抱怨越用越蠢:同一个问题,早上答对、下午答错。
排查发现工作台被堆成了垃圾场:
- 为「省事」一次性挂了 40 个 Skill 的全文进系统提示;
- 每次查询,把整张几千行的成本宽表原样灌回上下文;
- 多轮追问下来,前面失败的试错、过期的中间结果全留在窗口里。
窗口没爆,但关键口径被淹没在噪音里——模型「看不清」,于是把住宅口径套到了商业上。容量够,注意力不够。
改造后(让 Harness 当守门人):
| 改造前 | 改造后 |
|---|---|
| 40 个 Skill 全文常驻 | 只留 metadata,命中才载入正文(渐进披露) |
| 宽表整张灌回 | 工具只回决策所需的几列几行 |
| 试错全留窗口 | 错了就丢,重试不污染主线 |
结果:同样的模型,同样的问题不再飘。这件事最反直觉的一点——没换模型、没加 token,只是把工作台收拾干净,准确率就回来了。注意力是黄金,Harness 是守门人。
- 🚫 一次性灌入所有工具/知识 → 「以防万一」全塞进去,反而每一步都更钝。
- 🚫 长对话从不清理 → 过期材料堆积,模型被旧上下文带偏。
- 🚫 把失败重试留在上下文 → 错误尝试占着窗口,还可能误导后续推理。
- 🚫 该拆子 agent 却硬塞主线 → 深挖材料污染主线,见 设计指南/Agent设计 的「何时自定义子编排」。
- 渐进披露三级加载 → 设计指南/Skill设计
- 跨时间的状态管理 → 设计指南/Agent设计/记忆管理
- 工具返回别灌全量 → 设计指南/Agent设计/感知-行动循环