从提示词->上下文->harness工程的演进
早期的工程重心完全集中在模型本身——如何让它听懂话。然而，当我们将大模型应用于长周期的复杂真实业务（如连续运行数小时的自动编程、深度研究或 Anthropic 提出的 Computer Use/Claude Cowork 级别人机协作）时，我们发现单纯的“沟通”是不够的。
这就催生了AI工程学的三次迭代：从解决表达问题的 Prompt Engineering，到解决信息供给的 Context Engineering，最终走向解决稳定执行的 Harness Engineering。
1.Prompt Engineering —— 解决“如何表达清楚”
在这个阶段，模型被视为一个“拥有海量知识但缺乏常识的超级实习生”。工程的核心挑战是消除人类自然语言中的模糊性，将其转化为模型能够高概率生成正确输出的指令。
a. 核心命题与解决的痛点
- 核心命题：如何精准地向模型表达任务意图？
- 解决痛点：模型“听不懂”或“误解”指令，导致输出格式错误、风格不符或逻辑断层。
- 适用场景：单轮对话、短文本生成、静态的数据提取、翻译等“一问一答”式任务。
b. 关键突破技术
- 角色设定 (Role-playing)：通过赋予模型特定的人设（如“你是一个拥有20年经验的前端架构师”），隐式地激活模型权重中特定领域的知识分布，从而调整输出的专业度和基调。
- 少样本提示 (Few-shot Prompting)：通过提供 2-3 个高质量的输入/输出范例，利用模型的上下文学习（In-context Learning）能力，让它直接“模仿”而非仅仅“理解”规则。
- 思维链 (Chain-of-Thought, CoT)：强制要求模型在给出最终答案前，先输出分布推理过程（“Let's think step by step”）。这不仅是让输出更清晰，本质上是利用模型每生成一个 token 所消耗的算力，为复杂逻辑腾出“思考草稿纸”。
c. 局限性
Prompt Engineering 假设了环境是静态的。当面对需要跨越多个文档、需要调用外部工具或持续数天的任务时，静态的 Prompt 无法应对动态变化的信息流。
2.Context Engineering —— 解决“如何信息供给”
如果说 Prompt 是一封邮件的正文，那么 Context 就是邮件的附件。到了 2025 年前后，随着模型上下文窗口（Context Window）扩展到 1M 甚至 2M tokens（如 Claude 3 系），工程师们发现，一味地扩大窗口不仅极其昂贵，而且会导致模型“注意力涣散”（Lost in the Middle 现象）。因此，Context Engineering 应运而生，它不再关心“怎么说”，而关心“给它看什么”。
a. 核心命题与解决的痛点
- 核心命题：如何在对的时间、以对的密度，向模型提供最相关的背景信息？
- 解决痛点：模型“看不到”关键信息，或者被过载的垃圾信息淹没导致幻觉（Hallucination）。
- 适用场景：企业级知识库问答、长文本代码库分析、多轮复杂交互。
b. 关键突破技术
- 检索增强生成 (RAG, Retrieval-Augmented Generation)：打通外部知识库与模型。通过向量数据库和混合检索技术，只把与当前 query 最相关的 Top-K 信息塞进提示词中。
- 渐进式披露 (Progressive Disclosure)：面对庞大的代码库，不一次性给全，而是先给目录树（Architecture Map），让模型自己决定需要“展开”查看哪个具体文件的代码。
- 分层上下文与状态注入：在多轮任务中动态维护上下文。正如你所指出的，Context Engineering 包含了“Prompt 规划”。它需要决定：System Prompt 里放什么（基础规则），历史消息保留多少（滑动窗口机制），当前执行步骤的上下文如何注入。
c. 局限性与向上的过渡
Context Engineering 保证了模型在单次推理时拥有“完美的情报”。但它仍然是一个静态的切片。当模型需要自主运行 8 个小时去重构一个微服务架构时，谁来决定什么时候去检索？如果检索失败了怎么办？如果模型陷入了死循环怎么办？这就是 Harness 需要接管的地方。
3.Harness Engineering —— 解决“如何稳定执行”
从内容划分上来看，harness engineering相对于context engineering增加了状态管理、智能体编排与效果评估
a. 核心命题与解决的痛点
- 核心命题：如何构建一个鲁棒的运行环境，确保智能体在长周期任务中不脱轨、不遗忘、能自愈？
- 解决痛点：模型在执行长周期复杂任务时“做不对”（状态丢失、陷入死循环、产生滚雪球式的错误）。
- 典型案例：Anthropic 运行 8 小时无错的 Computer Use 智能体。它不是靠一个完美的 Prompt 撑了 8 小时，而是靠底层极其强壮的 Harness 架构。
b. 关键突破技术
- 多智能体编排 (Orchestration)：Harness 将任务拆解，分别派发给“规划者（Planner）”、“执行者（Actor）”和“评审者（Reviewer）”。
- 评估器分离与反馈循环 (Evaluators & Feedback Loops)：这是 Harness 的灵魂。当模型写完一段代码后，Harness 不会立刻相信它，而是自动在沙箱中运行编译、跑测试用例（Sensors）。如果报错，Harness 会将错误堆栈信息打包，重新扔回给模型要求修改。这完全独立于 Context Engineering，这是一种运行时（Runtime）的干预。
- 状态与工作区管理 (State & Workspace Management)：给模型配备持久化的“文件系统”和“记忆库”。让大模型可以将中间结果落盘（保存为文件），这样即使会话中断，Agent 也能读取上一步的工作状态继续执行，真正实现了跨会话的长期任务。
4.边界与总结：如何区分三者的职责？
为了极其清晰地明确你提到的“Harness 包含，但 Context 不包含的是 Orchestration (编排) 和 Validation (验证)”这一观点，我们可以将 Agent 视作一家公司：
| 阶段 | 核心命题 | 关键突破 | 解决的核心痛点 |
|---|---|---|---|
| Prompt Engineering | 如何表达清楚 | 角色设定、Few-shot、CoT | 模型"听不懂"指令 |
| Context Engineering | 如何信息供给 | RAG、渐进式披露、分层上下文 | 模型"看不到"关键信息 |
| Harness Engineering | 如何稳定执行 | 多智能体协作、评估器分离、状态管理 | 模型"做不对"复杂任务 |
5.为什么长周期任务必须依赖 Harness？
如同 Anthropic 团队在构建长时间运行智能体时所发现的：大模型本质上是非确定性的（Non-deterministic），它们只思考下一个 Token。如果你让它连续思考 8 个小时，微小的错误概率会不断累积。
Context Engineering 只能保证每次思考时“手上拿的资料是对的”。 但只有 Harness Engineering 能够保证运行的过程时稳定的