夜雨聆风SUMMARY · 核心结论
把大模型想成一颗很强的推理引擎，它每轮能「看见」的只有上下文窗口里的信息。工程上叠三层分工：Prompt Engineering 管「怎么说清楚」，Context Engineering 管「此刻给它看什么」，Harness Engineering 管「工具循环怎么在真实世界里长期可靠地跑下去」。三层不是谁取代谁，而是责任边界越来越像正经系统工程。
色块区分引言 / 注意 / 推荐；零基础从阅读指南起读，再按章扫清单与排障表。
READ FIRST
阅读指南：按你的背景跳读
零基础先读「先把地基打稳」，再读「先把边界说清楚」与后文三章（Prompt / Context / Harness），最后看案例、术语表与 FAQ。
进阶地基可快扫；重点看各章清单、失败模式、层间交界。
工程把地基当目录；用术语表对齐语言，用 FAQ 收口争论。
FUNDAMENTALS
先把地基打稳：5 个概念
- LLM 在工程里像什么？
像函数：文本进、文本出。默认没有线程、没有持久内存、不能自己开硬盘——除非你用程序接能力。 - Token
是模型处理文本的基本单位；计费、速度、上下文上限多按 token 计。 - 上下文窗口
是「这一轮推理能同时看见」的上限；超出就要丢、压、拆、外置——正是 Context 与 Harness 要接手的部分。 - Agent（极简定义）
LLM 在循环里自主调用工具。没有工具循环，多数「Agent」只是聊天。 - 为何不是「提示词写长点」就结束？
长任务会产生工具输出、日志、历史，都会挤进窗口；要把「写清楚」（Prompt）与「看得见、传得下去」（Context / Harness）分开治理。
BOUNDARIES
先把边界说清楚
三层为并列职责；窄屏下三列会纵向堆叠，阅读顺序不变。
LAYER 01 Prompt 目标、约束、格式、边界、少量示例。更像一份可执行的说明书。 | LAYER 02 Context 每轮推理前，挑选、裁剪、组织进入窗口的信息。更像内存与缓存策略。 | LAYER 03 Harness 工具、权限、会话、落盘、验收与交接。更像运行时与编排器。 |
词源 Harness 借「托架 / 夹具」意象：模型是零件，harness 是把零件接进流水线的支架。业界讨论长时编码 Agent 时常用 agent harness 指 SDK 与配套机制整体（含工具与上下文管理等）。
TRIAGE
对照表：日常排障
CHAPTER I
Prompt Engineering：重要，但不是万能钥匙
结构化 system prompt、输出契约、少量 few-shot，往往仍是最便宜的增益。任务变长后，prompt 只是进窗口的一部分信息源；把业务流程写成超长规则清单，通常脆弱难维护——那是系统结构，不该硬塞进一段字符串。
它解决什么，不解决什么
IN SCOPE Prompt 主要解决 目标、边界、风格、输出结构；用少量高质量示例把「你想要的形态」钉住。 | OUT OF SCOPE 交给 Context / Harness 证据缺失、长任务状态丢失、工具输出淹没窗口、验收与回归。 |
为什么 system prompt 仍值得认真写
它决定默认行为、风险偏好与输出契约。很多失败是系统侧含糊，模型就用「最安全的通用答案」糊弄过去。
高质量 prompt 硬规则（可当评审表）
- 先成功标准，再约束
— 先定义「完成长什么样」。 - 输出当 API
— JSON/表格写清字段、缺省、排序。 - 少洗衣清单，多代表性示例
— 覆盖典型与反例。 - 分层组织
— 工具规范、输出格式、异常分章。 - 别把业务流程写成超长 if-else
— 外置状态机、清单、工具接口。
常见误区
层间交界
「明明会」却总漏条件：先查证据是否进窗口（Context）。单轮好、多轮崩：先查外部状态与验收（Harness）。
RECOMMENDEDPrompt 把行为讲清楚；「此刻该不该把某段日志、文档、工具输出塞进窗口」交给 Context Engineering。
CHAPTER II
Context Engineering：上下文是会贬值的资产
重心从「只写 prompt」迁到持续策展上下文：凡将进入采样的信息，都在范围内。目标不是措辞玄学，而是证据到位、噪声可控。
ATTENTION
上下文不是越多越好；窗口变长可能带来注意力稀释（业界常谈 context rot）。主目标压成一句：
用尽可能少的高信号 token，提高下一轮做出正确决策的概率。
硬技能常包括：工具返回克制、小集合、语义不重叠；JIT 用路径/链接/查询替代一次性灌满大对象；长时程用压缩摘要、外部笔记、子 Agent 只回传蒸馏结果。context reset + handoff：清空会话并用交接工件续跑。
一句话定义
Context engineering 管每次调用前窗口里拼什么：system prompt、历史、检索、工具输出、结构化数据等一切进入采样的 token。
TWO FACTS
事实 1 上下文会贬值：信息变多 ≠ 更准；要裁剪、外置、压缩与再取回。
事实 2 注意力是预算：低信号挤占关键证据；Context 本质是预算分配。
上下文由哪些部分组成
- 系统提示
· 稳定规则与输出契约 - 用户输入
· 任务与补充材料 - 对话历史
· 最易膨胀 - 工具输出
· 隐形成本大户 - 检索（RAG）
· 相关性、重复、冲突要治理 - 元数据
· 路径、时间戳、环境信息常更能定位下一步
三种策略：预取、JIT、外置记忆
📥 预取 先备好材料，首轮能答；变化慢、边界清晰时优先。 | 🔗 JIT 窗口里先放引用，需要再取；大仓大表大文档。 | 💾 外置记忆 状态落盘再拉回；长跑与跨会话。 |
长时程手段（先记名）
- Compaction
— 摘要续跑；连续但可能丢细节 - Tool result hygiene
— 只留结论与指针 - Structured note-taking
— NOTES / TODO / 决策外置 - Sub-agent
— 深挖在子窗口，主窗口收蒸馏结果
Context checklist
CHAPTER III
Harness Engineering：可接力、可验收
零记忆开工：像轮班开发，新会话默认不知道上一班做了什么——必须把状态写进环境。Harness 把内部状态变成可见、可继承、可验收的外部状态：initializer 搭脚手架，coding 增量推进，清单与端到端测试配合。
「自我打分」不可靠时，要外部回路：生成与评估分离，评估基于可操作证据。Planner / Generator / Evaluator — 做什么、怎么做、做得对不对。
ENGINEERING LENS每个 harness 组件都在编码「假设模型独自做不到什么」。模型变强后假设会过期，要持续做减法实验，避免架得过重。
一句话定义
Harness 是把模型接进真实世界的运行时：工具权限、循环控制、外部工件、跨会话状态、验收方式。
Initializer + Coding
- Initializer
— 脚手架、进度文件、初始提交、条目化需求 - Coding
— 增量推进；提交信息、进度说明、可运行基线
结构化清单对抗「一口吃完」与「过早宣布完成」。
Harness checklist
层间交界
上下文裁得很好但多会话仍失控：基本缺 Harness。Harness 很重仍胡写：回到 Context 证据与 Prompt 契约。
STACK
三层怎么叠（从里到外）
Harness · 编排 / 会话 / 工件 / 验收 ↓ 约束与目标 Context · 每轮上下文策展 ↓ Prompt · 指令与示例
读图规则：外层为内层提供约束与目标。单靠措辞很难解决「跨会话零记忆」这类 harness 问题。
CLOSING
写在最后
别把三件事理解成「互相替代」。Prompt 让模型知道你要什么；Context 让每一轮看得见、看得清；Harness 让系统在长时间尺度上接得住、验得了、传得下去。能把问题准确归类，就从「调模型运气」进入「搭系统能力」。
CASE STUDY
案例：登录页加「记住我」
目标：加复选框，状态写入本地存储
缺什么会痛 缺 Prompt 乱改；缺 Context 改错或漏依赖；缺 Harness 第 N 轮工程不可运行且难定位。
GLOSSARY
术语表（节选）
FAQ
6 个高频争论（极简答）
练习 选最近 3 次 Agent 失败，分别贴上 Prompt / Context / Harness；下一轮每次只修一类问题。
REFERENCES
延伸阅读 · Anthropic Engineering
Effective context engineering for AI agents
Effective harnesses for long-running agents
Harness design for long-running application development
— · —
