文章

18-从Prompt到Harness-记忆与上下文的设计范式

18|从 Prompt 到 Harness:记忆与上下文的设计范式

概述

建立上下文工程的认知框架:理解记忆的本质、三代演进(Prompt→Context→Harness),以及上下文治理的核心——加法和减法。

核心概念

1. 记忆的本质

关键认知:大模型没有记忆!

真相:每次API调用都是独立的,模型不知道上一句说了什么。所谓”记住”,是因为应用层把之前的对话历史塞进了message list。

# "记忆"的全部真相
messages = [
    {"role": "system", "content": "你是XiaoPaw,飞书工作助手..."},
    {"role": "system", "content": "用户偏好:周报格式先汇总再列计划..."},  # 这就是"记忆"
    {"role": "user", "content": "帮我发周报"},
    {"role": "assistant", "content": "好的,按你喜欢的格式..."},
]

记忆系统的本质:设计一套机制,决定什么时候从”硬盘”加载到”内存”,什么时候从”内存”写回”硬盘”,“内存”满了怎么腾空间。

类比电脑

  • 模型 = CPU(只计算,不存储)
  • 上下文窗口 = 内存RAM(容量有限,断电即失)
  • 外部存储 = 硬盘(持久化但需主动读取)

2. 三代演进

时代时间核心控制权代表
Prompt EngineeringGPT-3时代人写全部写内容早期聊天机器人
Context EngineeringGPT-4时代工程逻辑构建message list建message listWorkflow、单Agent
Harness Engineering2026+预加载索引+模型按需探索造环境Claude Code、Cursor

Harness概念:OpenAI 2026年2月正式提出,字面意思是”马具”(缰绳、鞍具、挽具)。

三代类比

  • Prompt时代:你是骑手,手把手拉缰绳告诉马每一步怎么走
  • Context时代:你是教练,给它规划好赛道和路线
  • Harness时代:你是牧场主,建好围栏、水源、草料站,马自己决定去哪吃草

常见误区纠正:Harness不是”完全放手”。Claude Code依赖CLAUDE.md预加载项目结构、rules/预加载约束、MEMORY.md自动注入记忆索引。正确理解:预加载关键索引 + 模型按需探索的混合模式

3. 治理框架:加法与减法

加法:让模型知道它该知道的

  • 问题:不记得你是谁、说过的话反复提、SOP反复教
  • 手段:
    1. Bootstrap预加载:启动时固定加载(人设、规则、记忆索引)
    2. 工具返回注入:Agent调用工具后结果自动进入上下文
    3. 记忆检索注入:从持久化存储检索相关记忆注入
    4. Skill按需加载:渐进式披露,需要时才加载

减法:让上下文没有不该有的

  • 为什么不能加?上下文窗口有物理上限
  • 为什么不应该加?
    1. Context Rot:上下文越大,注意力越分散
    2. 成本:Transformer复杂度O(n²),上下文翻倍成本翻4倍
  • 手段:
    1. 压缩/截断:旧对话压缩成摘要或直接截断
    2. 选择性遗忘:主动丢弃低价值信息
    3. Sub-agent隔离:任务委派给子Agent,主Agent上下文精简

4. 记忆系统的三大核心问题

  1. 记什么(What):哪些信息值得记忆?
  2. 怎么存(How):存储结构、检索方式
  3. 怎么取(When):什么时候加载、怎么加载

5. Context Rot底层机制

注意力是有限预算

Transformer生成每个token时,会”看一眼”上下文里所有其他token。上下文有1000个token,每个分到1/1000注意力;有100000个token,每个分到1/100000。

Context Rot物理根因:不是模型”忘了”,而是注意力被稀释了

40%警戒线:研究发现,上下文使用量超过约40%时,模型能力显著下降。

U型注意力分布:模型对开头和结尾关注最多,中间最容易被忽略。

  • System Prompt放最前面:利用开头注意力高点
  • 最近对话最重要:利用结尾注意力高点
  • 中间历史对话:最容易丢失信息

Claude Code的System Reminder机制:每次工具调用后,在消息末尾注入关键提醒,把重要信息推到U型曲线的”结尾高点”。

关键要点

  1. 模型没有记忆:你往messages里塞了什么,模型就知道什么
  2. 三代演进:Prompt(写内容)→ Context(建message list)→ Harness(造环境)
  3. 治理核心:加法让模型知道该知道的,减法让上下文没有不该有的
  4. 40%警戒线:上下文超过40%后能力显著下降,要提前管理
  5. U型分布:关键信息放两头,中间要精简

实践示例

Bootstrap预加载

# 启动时固定加载
system_prompt = """
你是XiaoPaw,飞书工作助手。

用户画像:
- 职位:产品经理
- 偏好:周报格式先汇总再列计划
- 常用技能:xlsx分析、飞书文档操作

工作规范:
1. 收到文件先保存到沙盒
2. 分析前先确认数据格式
3. 输出结果优先用飞书文档
"""

记忆检索注入

# 从向量数据库检索相关记忆
relevant_memories = vector_db.search(
    query=user_message,
    top_k=5,
    filter={"user_id": current_user_id}
)

# 注入上下文
messages.append({
    "role": "system",
    "content": f"相关历史记忆:\n{relevant_memories}"
})

常见问题/坑点

误区真相解决方案
模型能记住我模型没有记忆,是应用层塞的历史理解message list机制
窗口越大越好超过40%能力显著下降控制在40%以内,做减法
Harness=完全放手实际是预加载+按需探索混合预加载关键索引(CLAUDE.md、rules/)
只加不减Context Rot导致注意力稀释加法减法必须平衡
均匀分布注意力U型分布,中间容易被忽略关键信息放两头

关联知识

参考资源

  • Andrej Karpathy谈Context Engineering
  • OpenAI Harness Engineering公告(2026年2月)
  • Liu et al. U型注意力分布研究(TACL 2024)

学习时间

  • 课程时长:22:13
  • 笔记整理:2026-04-10

状态

  • 课程学习
  • Context Engineering实践
  • Harness设计

下次复习日期

2026-04-17